流水线输出数据镜像流水线的体系结构

Question

我正在构建一个管道，用于在实体上刮取数据，为了保持通用，我们称它们为Widgets。有关小部件的数据目前是无组织的，并且分布在各种来源，包括源代码、电子表格和发布/项目跟踪软件(如JIRA )。管道将在某些时间运行，并定期更新小部件上的数据表。

我设计了这条管道，把它分成几个小的单独测试的阶段。这些阶段是连接在一起的，它们所抓取/查询的数据最终被连接在一起。例如，类似于：

• A阶段刮取数据A。
• B阶段获取数据A并检索数据B。
• 阶段C接受数据A并检索数据C。
• 阶段D获取数据B并检索数据D。
• 阶段E获取数据A、B、C、D，并将其合并到最终的Widget数据中。

如你所知，各个阶段是相互依赖的。我这样做是为了避免一个需要重新抓取/处理已经被前一阶段处理过的数据的阶段(例如，阶段B不需要重新刮取数据A，而是对数据A进行操作)。

目前主要的开放设计问题使我无法入睡。E阶段。我反复讨论了如何将最终完成的Widget数据反映出不同来源的数据A、B、C、D的现有结构。另外。在创建Widget数据之前，E阶段应该完成多少处理/转换(如果有的话)？举个简单的例子，如果数据A和数据B中存在与标识相关的信息，那么我的Widget模式应该有一个由A和B中的数据组成的identification字段，还是应该同时包含identification信息的A和B字段。换言之：

模式#1:

Widget {
  A a {
    string id
  }
  B b {
    string name
  }
}

优点：

• 对消费者来说，数据来自何方？
• 更容易实现，阶段E基本上只是连接。
• 完全不固执己见。如何最终使用Widget数据。

模式#2:

Widget {
  Identification identification {
    string id
    string name
  }
}

优点：

• 更容易查询相关信息(例如，所有标识信息都在一个字段中)。
• 管道的结构不会“泄漏”到Widget模式，对管道结构的更改不会更改Widget模式(对Widget数据的使用者有利)。

我很好奇SE专家对这个整体架构的看法和上面的问题。我猜答案将是“这取决于”，但我对上述方法至少有更多的利弊感兴趣。任何学习资源的链接也是非常感谢的！

Answer 1

我会提出一个稍微不同的架构，这也将避免意外地暴露数据处理的管道性质。

有两个数据结构

1. 中间Widget数据:这包含在处理过程中收集和/或生成的所有Widget数据。有些数据可能只与处理阶段之间的通信相关。
2. 定稿Widget数据:这是在管道末尾出现的数据结构，它只包含打算提供给客户/用户的数据。

管道步骤将被这样修改。

• 阶段A抓取数据A并将其放入中间Widget数据中。
• 阶段B采用中间Widget数据，并使用数据B对其进行扩展。
• 阶段C采用中间Widget数据，并使用数据C对其进行扩展。
• 阶段D采用中间Widget数据，并使用数据D对其进行扩展。
• 阶段E接受中间Widget数据并将其过滤到最终的Widget数据中。

由于每个阶段都在中间Widget数据上工作，所以哪个阶段提供哪些数据就变得不那么重要了，以后更容易添加一个新的附加阶段。例如，阶段之间仍然存在依赖关系，因为阶段D需要先前填充的数据，但是阶段D的实现不需要知道特定于阶段的数据结构才能检索它需要的数据。

在构建管道的时候，您需要知道每个阶段需要什么，并提供什么，以便您能够以正确的顺序构造它。

这样做的好处是，您可以在不影响下游阶段的情况下拆分或重新排列管道中的各个阶段。例如，如果您发现阶段B和C所做的某些工作实际上是重复的(但结果是填充了不同的字段)，则可以将重复的工作重构到一个新的阶段BC和阶段D(该阶段使用由重复工作填充的字段之一)不会受到任何影响。