Python 从PubSub读取数据流作业：减少积压工作大小和最旧的未确认消息？

我们正在探索用数据流作业替换部分数据处理过程。我们已经使用Google PubSub管理和分发工作流，但是我们自己的代码运行在Kubernetes集群上

我使用一个简单的数据流作业进行了初始测试，该作业只读取PubSub订阅并丢弃消息

它工作得很好，并且自动缩放到2个工作人员（即使在我最初使用3个工作人员时也是如此）。它可以很好地跟上消息流，但是PubSub未确认的消息数量徘徊在4500左右，最早的未确认消息时间平均约为5秒

我们当前的（非数据流）处理器将未确认的消息计数保持在1700左右，最早的未确认消息保留时间为2-3秒

我怀疑这是因为提供的Apache Beam

io.ReadFromPubSub

可能正在使用持久性存储进行某些处理，而我们自己的代码只在内存中运行

测试代码很简单：

def noop(element):
    pass

def run(input_subscription, pipeline_args=None):
    pipeline_options = PipelineOptions(
        pipeline_args, streaming=True, save_main_session=True
    )

    with Pipeline(options=pipeline_options) as pipeline:
        (
            pipeline
            | "Read from Pub/Sub" >> io.ReadFromPubSub(subscription=input_subscription, with_attributes=True)
            | "noop" >> Map(noop)
        )

虽然这些指标没有实质性差异：

作为一个组织，我们对延迟非常敏感，如果能够解释为什么数据流会以这种方式运行，那就更好了，这样我们就有信心转向更基于数据流的基础架构

我们是否可以进行配置更改以减少积压工作和延迟