复杂Dataflow作业的体系结构

Question

我们正在从流媒体源中构建相当复杂的Dataflow作业.特别是,我们有两个模型,它们共享一组指标,并且大致使用相同的数据源计算得出.作业对稍大的数据集执行连接.

你有关于如何设计这类工作的指导方针吗？任何指标,行为或我们在做出决定时必须考虑的任何事项？

以下是我们想到的几个选项,以及我们如何比较它们:

选择1:一份大工作

在一个大型工作中实施一切.考虑常见指标,然后计算特定于模型的指标.

优点

• 写得更简单.
• 工作之间没有依赖关系
• 减少计算资源？

缺点

• 如果一个零件断裂​​,则无法计算两个模型.

选项2:使用Pub/Sub管道的多个作业

将公共度量计算提取到专用作业,从而产生3个作业,使用Pub/Sub连接在一起.

优点

• 如果其中一个模型工作失败,则更具弹性.
• 可能更容易执行持续更新.

缺点

• 需要启动所有作业才能拥有完整的管道:依赖关系管理.

Answer 1

您已经提到了许多关键的权衡 - 模块化和较小的故障域与运营开销和单片系统的潜在复杂性.需要注意的另一点是成本 - 发布/订阅流量将增加多个流水线解决方案的价格.

如果不能更好地了解您的操作细节,我的建议是选择#2.这听起来像有在具有高达模型的一个子集至少部分价值,并在严重的bug或回归的情况下,你就可以使局部的进展,同时寻找定位.