python - 遇到从 Dataflow 管道向 BigQuery 进行缓慢流式写入的问题？

Question

在使用流式插入和 Python SDK 2.23 写入 BigQuery 时，我遇到了意外的性能问题。
如果没有写入步骤，管道会在一个具有约 20-30% CPU 的工作线程上运行。添加 BigQuery 步骤后，管道最多可在 70-90% 的 CPU 上扩展到 6 个工作线程。
我对 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 \

指标截图:

我的问题是这种行为是否正常，或者我可以做些什么来减少此管道所需的 worker 数量。谢谢!
更新:
这是带有墙时间的数据流图的最后一步的图像。 (在作业运行 1 小时后拍摄)。之前的所有其他步骤的墙时间都很短，只有几秒钟。

Answer 1

经过一番调试后，我发现有一些无效消息无法写入 BigQuery(并且没有记录错误)。因此，对于遇到类似问题的任何人:
更改后insert_retry_strategy的 beam.io.WriteToBigQuery至 RETRY_NEVER并打印出死信 pCollection 我修复了错误格式的消息并提高了性能。
我猜由于 RETRY_ALWAYS 的默认策略，一些无效的消息被卡住了。 .