如果我现在正在构建一个应用 Lambda 架构的项目，我是否应该将批处理层和服务层分开，即程序 A 做批处理层的工作，程序 B 做服务层的工作？它们在物理上是独立的，但在逻辑上是相关的，因为程序 A 可以在 A 完成预计算工作后告诉 B 工作。
如果是这样，你能告诉我如何实现它吗？我在考虑IPC。如果IPC可以帮助，具体方法是什么？
顺便说一句，“批处理视图”到底是什么意思？为什么以及如何服务层索引它？
问问题
704 次
1 回答
3
实现 Lambda 架构 batch_layer 和 serving_layer 的最佳方式是什么？这完全取决于具体要求、系统环境等。不过，我可以解决如何设计 Lambda 架构 batch_layer 和 serving_layer。
顺便说一句，我昨天刚和一位同事讨论这个问题，这是基于那个讨论。我将分 3 部分进行解释，为了便于讨论，假设我们有兴趣设计一个系统来计算阅读次数最多的故事 (a) 一天、一周 (b) 和一年中 (c)：
首先，在 lambda 架构中，重要的是先将您要解决的问题划分为时间优先和特征其次。因此，如果您将数据建模为传入流，那么速度层会处理流的“头部”，例如当天的数据；批处理层处理“头”+“尾”，即masterset。
其次，在这些基于时间的线之间划分特征。例如，某些功能可以单独使用流的“头”来完成，而其他功能需要比“头”更广泛的数据，例如 masterset。在我们的示例中，假设我们定义了速度层来计算一天的数据。然后 Speed 层将在所谓的 Speed View 中计算当天阅读次数最多的故事 (a)；而批处理层将在所谓的批处理视图中计算最多阅读的故事 (a) 天、一周 (b) 和一年中 (c)。请注意，是的，可能看起来有点冗余，但请坚持这个想法。
第三，服务层响应来自客户端关于 Speed View 和 Batch View 的查询，并相应地合并结果。Speed View 和 Batch View 的结果必然会有重叠。无论如何，这是速度与批处理的区别，除其他好处外，还使我们能够最大程度地减少风险，例如 (1) 推出错误，(2) 损坏的数据交付，(3) 长时间运行的批处理等。理想情况下，问题将在速度视图中发现，然后在批处理视图重新计算之前应用修复。如果是，那么一切都很好。
总之，不需要使用 IPC，因为它们完全相互独立。所以程序 A 不需要与程序 B 通信。相反，系统依赖于处理的一些重叠。例如，如果程序 B 基于每天计算其 Batch 视图，则程序 A 需要计算当天的 Speed 视图以及处理可能花费的任何额外时间。这个额外的时间需要包括批处理层中的任何停机时间。
希望这可以帮助！
笔记：
- 批处理层的冗余——批处理层必须至少有一些冗余，因为服务层必须能够为查询提供单个内聚的结果视图。至少，冗余可能有助于避免查询响应中的时间间隔。
- 评估速度层中的功能——这一步并不总是像这里的“阅读次数最多的故事”示例中那样方便。这更像是一种艺术形式。
于 2015-05-21T15:08:58.767 回答