如果我现在正在构建一个应用 Lambda 架构的项目，我是否应该将批处理层和服务层分开，即程序 A 做批处理层的工作，程序 B 做服务层的工作？它们在物理上是独立的，但在逻辑上是相关的，因为程序 A 可以在 A 完成预计算工作后告诉 B 工作。
如果是这样，请告诉我如何实现它？我在考虑IPC。如果IPC有帮助，具体方法是什么？
顺便说一句，“批处理视图”到底是什么意思？服务层为什么以及如何对其进行索引？
【问题讨论】：
实现 Lambda 架构 batch_layer 和 serving_layer 的最佳方式是什么？这完全取决于具体要求、系统环境等。不过，我可以解决如何设计 Lambda 架构 batch_layer 和 serving_layer。
顺便说一句，我昨天刚刚和一位同事讨论了这个问题，这是基于那个讨论。我将分 3 部分进行解释，为了便于讨论，假设我们有兴趣设计一个系统来计算阅读次数最多的故事 (a) 一天中、一周中 (b) 中、一年中 (c) 中：
首先，在 lambda 架构中，将您尝试解决的问题划分为时间第一和功能第二是很重要的。因此，如果您将数据建模为传入流，则速度层处理流的“头部”，例如当天的数据；批处理层处理'head' + 'tail'，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 视图以及处理可能花费的任何额外时间。这个额外的时间需要包括批处理层中的任何停机时间。
希望这会有所帮助！
注意事项：
【讨论】：