复杂Dataflow作业的体系结构

Question

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

您对如何设计这类工作有任何指导方针吗？我们必须考虑任何指标，行为或任何我们做出决定的事情吗？

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

选项1：一个大型工作

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

赞成

• 更容易写。
• 工作之间没有依赖关系。
• 减少计算资源？

缺点

• 如果一个部件损坏，则无法计算两个模型。

选项2：使用Pub / Sub

管道的多个作业

将常用指标计算提取到专用作业，从而产生3个作业，使用Pub / Sub连接在一起。

赞成

• 如果其中一个模特工作失败，会更有弹性。
• 可能更容易执行ongoing updates。

缺点

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

Answer 1

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

如果不了解您的操作细节，我的建议是选择＃2。听起来至少部分价值在于模型的子集，并且在发生严重错误或回归的情况下，您可以在寻找修复时取得部分进展。