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) 错误并提高稳定性：
    • 使用具有更多内存的工作器机器类型。
    • 减少每个工作器的线程数。
    • 设置更高的工作器数量，以更均匀地分配工作负载，并减少频繁的自动扩缩事件对性能的影响。

后续步骤