复杂数据流作业的架构

Posted 2023-02-16

【中文标题】复杂数据流作业的架构

【英文标题】：Architecture of complex Dataflow jobs

【发布时间】：2016-08-02 19:51:31

【问题描述】：

我们正在通过流式源在该计算模型中构建相当复杂的 Dataflow 作业。特别是，我们有两个模型共享一堆指标，并且根据大致相同的数据源进行计算。 这些作业在稍大的数据集上执行连接。

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

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

选项 1：一项大型工作

在一项大型工作中实现所有内容。考虑通用指标，然后计算模型特定指标。

优点

写起来更简单。 作业之间没有依赖关系。 计算资源更少？

缺点

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

选项 2：使用 Pub/Sub 管道传输多个作业

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

优点

在模型作业之一失败的情况下更具弹性。 可能更容易执行ongoing updates。

缺点

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

【参考方案1】：

您已经在这里提到了许多关键的权衡 - 模块化和较小的故障域与运营开销和单体系统的潜在复杂性。需要注意的另一点是成本——Pub/Sub 流量会增加多管道解决方案的价格。

如果不更好地了解您的操作细节，我的建议是选择选项 #2。听起来，建立模型的子集至少有部分价值，如果出现严重的错误或回归，您将能够在寻找修复的同时取得部分进展。