从 pubsub->bigquery 移动到 pubsub->gcs (avro)->bigquery

Question

我们当前的数据管道将我们的事件 "directly" 流式传输到 bigquery。
我们在 pubsub 中有一个消息流，我们首先使用数据流读取、丰富并写入其他 pubsub 主题，然后我们使用另一个数据流作业读取它，然后写入 bigquery。
它工作正常，但不支持正确的错误处理 - 我们只是丢弃无效消息，而不是处理它们，或者至少保存它们以备后用。
我们正在考虑改进流程，将无效消息放在一边，并允许稍后对其进行简单修复。
我的第一种方法是将那些有问题的消息写入不同的 pubsub 主题，并从那里处理它们，但很少有人建议将它们保存到 GCS（可能是 AVRO 文件）中。
问题是：如果我们使用 GCS 和 AVRO，为什么不对所有消息都这样做？为什么不丰富和写入 GCS，而不是丰富和写入 pubsub？
如果我们这样做，我们可以使用 AVROIO() 和 watchForNewFiles()，这看起来很简单。
但这听起来太简单了，也太好了。在开始编码之前，我担心以下几点：

• 我知道在数据流上使用 windows 会使流成为批处理数据， 但它比每 X 检查一次新文件要灵活得多 分钟。例如，我将如何处理延迟数据等？
• 作业无休止地运行，AVRO 文件将被堆放在一个桶中，并且 watchForNewFiles() 假设可以完美地工作？ 它会基于文件时间戳吗？命名格式 ?保持 "list" 已知的旧文件 ??阅读 FileIO 代码，似乎方法是 很天真，这意味着桶越大，时间越长 比赛将进行。

我错过了什么吗？这个解决方案不是比 pubsub 更适合无休止的流媒体吗？

Answer 1

• 有a set of APIs控制如何处理迟到的数据
• 我想如果你用 watchForNewFiles() 轮询一个无限增长的 GCS 桶会有问题。我找不到官方文档提到 list API 调用的可伸缩性，但认为它具有 O(n) 复杂性是合理的。如果您想在生产环境中使用管道并订阅 GCP 支持，我建议您与 GCP 支持人员讨论轮询大型 GCS 存储桶的可伸缩性。