Python 从数据流管道对BigQuery的流式写入速度缓慢？

在使用流式插入和Python SDK 2.23编写BigQuery时，我遇到了意想不到的性能问题

如果没有写入步骤，管道将在一个工作进程上运行，CPU约为20-30%。添加BigQuery步骤后，管道最多可扩展到6个工人，所有工人都使用70-90%的CPU

我对Dataflow和Beam非常陌生，可能这种行为很正常，或者我做错了什么，但在我看来，使用6台机器每秒向BigQuery写入250行有点重。我想知道如何达到每秒10万行的插入配额

我的管道如下所示：

p
    | "Read from PubSub" >> beam.io.ReadFromPubSub(subscription=options.pubsub_subscription) # ~40/s
    | "Split messages" >> beam.FlatMap(split_messages) # ~ 400/s
    | "Prepare message for BigQuery" >> beam.Map(prepare_row)
    | "Filter known message types" >> beam.Filter(filter_message_types) # ~ 250/s
    | "Write to BigQuery" >> beam.io.WriteToBigQuery(
          table=options.table_spec_position,
          schema=table_schema,
          write_disposition=beam.io.BigQueryDisposition.WRITE_APPEND,
          create_disposition=beam.io.BigQueryDisposition.CREATE_NEVER,
          additional_bq_parameters=additional_bq_parameters,
      )

管道使用这些选项运行，尽管我在没有使用流引擎的情况下也经历了类似的行为

--enable_streaming_engine \
--autoscaling_algorithm=THROUGHPUT_BASED \
--max_num_workers=15 \
--machine_type=n1-standard-2 \
--disk_size_gb=30 \

指标截图：

我的问题是，这种行为是否正常，或者我能做些什么来减少管道所需的工人数量。谢谢

更新： 下面是数据流图最后一步的图像，显示了墙时间。（作业运行1小时后拍摄）。之前的所有其他步骤的壁时间都非常低，只有几秒钟

---

调试一段时间后，我发现有一些无效消息无法写入BigQuery（并且没有记录错误）。因此，对于任何遇到类似问题的人：

将

beam.io.WriteToBigQuery的
insert\u retry\u策略
更改为
retry\u NEVER
并打印出死信pCollection后，我修复了格式错误的消息，提高了性能。
我猜由于默认策略
RETRY\u ALWAYS
您是否尝试为您的场景使用专用解决方案，即数据流模板：如果您尝试过，请告诉我。谢谢您的回复！我已经看到了模板，但我们无法使用它们，因为传入的PubSub消息包含多条需要提取的消息（实际上由“\n”分割）。此外，我们还希望构建并理解一个定制管道，以便更好地理解Beam和数据流。这是一个令人惊讶的缓慢过程。你能看看你的msec计数器，看看管道在什么阶段花费时间吗？谢谢你的回复！我不知道你说的毫秒计数器是什么意思。我更新了问题，并添加了最后一步的图像和相应的墙时间，希望这就是你所要求的。似乎是最终写入导致了延迟。但我不知道如何从这里进一步调查。您是否也尝试过在临时错误上重试？它应该忽略带有无效消息的失败，但在出现其他错误时仍会重试。不，还没有，但听起来这是我真正想要使用的重试策略。谢谢你指出！很乐意帮忙。您可能需要记录失败的行，这里有一个关于如何做的介绍。