订购消息发布/订阅GCP

Question

我是GCP中Dataflow和pub-sub工具的新手。

需要将当前的prem过程迁移到GCP。

当前过程如下：

我们有两种类型的数据供稿

1. 完整Feed –临时工作–完整XML的大小约为100GB（单个XML –非常复杂的一个–完整数据– ETL Job处理该xml并将其加载到约60个表中）

• 单独的ETL作业在那里处理完整的提要。 ETL工作流程 完整提要并创建可加载的文件，所有表将被截断 然后重新加载。

1. 增量Feed-每30分钟需要处理增量文件（XML文件-仅在最近30分钟内更改）

• 源系统每30分钟（不止一个，文件带有时间戳）推送XML文件，计划的ETL过程将选择源系统生成的所有文件并处理所有xml文件，并创建3个可加载的文件插入，删除并更新每个表
• 计划– ETL作业计划每5分钟运行一次，如果当前进程的运行时间超过5分钟，则直到当前进程完成后才会触发下一次运行
• 文件处理的顺序非常重要（ETL Job会处理这个问题）。需要按顺序处理所有文件。
• 在ETL过程结束时，将已准备好加载的文件加载到表（大型机）中

我被要求提出将其移植到GCP的设计。需要在GCP中有两个流程以及完整流程和增量流程。我建议的解决方案应该适用于两种提要。

最初我认为是下面的设计。

Pub / sub-> DataFlow-> mySQL / BigQuery

然后知道pub / sub不能保证按顺序/顺序处理文件。经过研究后，Google最近为pub / sub引入了订购关键概念，该概念将确保按顺序处理消息。在Google云文档中，有人提到此功能是Beta版。

我有两个问题：

• 在生产环境中，是否有人在pub / sub中使用了订购关键概念。如果是，您在实施此方法时是否遇到任何挑战
• 此设计是否适合上述要求？或者在GCP中有更好的解决方案
• DataFlow是否有其他选择？
• 很高兴知道pub / sub最多可以处理10MB的消息，对我们而言，每个XML大小都超过5G。

Answer 1

正如@guillaume blaquiere所述，Beta产品的发布阶段带来了一些限制，但它们主要与产品支持有关：

在测试版中，产品或功能已准备就绪，可以进行更广泛的客户测试 和使用。 Beta版通常是公开宣布的。没有SLA或 Beta版本中的技术支持义务，除非另有说明 以产品术语或特定Beta程序的术语指定。 Beta期平均持续约六个月。

常见的Cloud Pub / Sub message ordering功能可按预期工作，一旦您引起开发人员注意，便可​​以通过Google Issue tracker发送报告。