Pub/Sub 到 BigQuery 最佳实践

本页面概述了优化从 Pub/Sub 读取数据并向 BigQuery 写入数据的 Dataflow 流水线的最佳实践。根据您的应用场景，以下建议可能会带来更好的性能。

流水线积压的初始解决方案

如果 Pub/Sub 到 BigQuery 流水线的积压不断增加，无法及时处理传入消息，您可以立即采取以下措施：

延长 Pub/Sub 确认时限：对于关联的 Pub/Sub 订阅，将确认时限延长到略长于预期最长消息处理时间的值。这样可防止在消息仍在处理时过早地重新传送消息。
扩容工作器：如果未确认的消息数量和订阅积压迅速增加，则流水线的处理能力可能不足。请增加 Dataflow 工作器数量以处理消息量。
启用指数退避算法：启用指数退避算法可改进流水线针对暂时性问题处理重试的方式，从而提高流水线的弹性。

为保持性能和稳定性，建议进行以下架构和代码更改：

减少对 BigQuery 的 getTable 调用次数：过多的 getTable 方法调用可能会导致速率限制和性能瓶颈。如需缓解此问题，请执行以下操作：
- 在工作器内存中缓存表存在信息，以避免对同一表进行重复调用。
- 对每个包（而不是每个单独元素）批量调用 getTable。
- 重构流水线代码，以便无需对每个消息都检查表是否存在。
使用 BigQuery Storage Write API：对于向 BigQuery 写入数据的流处理流水线，请从标准流式插入迁移到 Storage Write API。Storage Write API 可提供更好的性能和显著更高的配额。
为高基数作业使用旧版 Dataflow Runner：对于处理大量唯一键（高基数）的作业，旧版 Dataflow Runner 的性能可能比 Runner v2 更好，除非需要使用跨语言转换。
优化键空间：当流水线处理数百万个活跃键时，性能可能会下降。请调整流水线的逻辑，以便在更小、更易于管理的键空间中执行工作。

正确的资源分配和配置对于流水线健康状况至关重要：

主动管理配额：监控配额，并针对在扩缩事件期间可能达到的任何配额申请增加。例如，请考虑以下扩缩事件：
- 频繁调用 TableService.getTable 或 tabledata.insertAll 方法可能会超出每秒查询次数 (QPS) 上限。如需详细了解限制以及如何申请更多配额，请参阅 BigQuery 配额和限制。
- 使用中的 IP 地址和 CPU 的 Compute Engine 配额可能会超出上限。如需详细了解限制以及如何申请更多配额，请参阅 Compute Engine 配额和限制概览。
优化工作器配置：为了防止内存不足 (OOM) 错误并提高稳定性，请执行以下操作：
- 使用具有更多内存的工作器机器类型。
- 减少每个工作器的线程数量。
- 设置更高的工作器数量，以更均匀地分配工作负载，并减少频繁自动扩缩事件对性能的影响。