如果我现在构建一个应用Lambda架构的项目，我应该拆分批处理层和服务层，即程序A执行批处理层的工作吗，程序B是否执行服务层？它们在物理上是独立的但在逻辑上相关，因为程序A可以告诉B在A完成预计算工作之后工作。
如果是的话，请您告诉我如何实施它？我正在考虑IPC。如果IPC可以提供帮助，具体方法是什么？
顺便说一句，“批量视图”到底意味着什么？为什么以及服务层如何将其编入索引？答案 0 :(得分：3)
实施Lambda Architecture batch_layer和serving_layer的最佳方法是什么？这完全取决于具体要求，系统环境等。我可以解决如何设计Lambda Architecture batch_layer和serving_layer的问题。
顺便说一句，我昨天刚与同事讨论这个问题，这是基于这个讨论。我将分三部分进行解释，为了便于讨论，我们可以说我们有兴趣设计一个系统来计算一天中最常读的故事（a），（b）本周，（c）：< / p>
首先，在lambda体系结构中，重要的是将您尝试解决的问题首先划分为时间，然后是第二个问题。因此，如果您将数据建模为传入流，则速度层将处理流的“头部”，例如当天的数据;批处理层处理'head'+'tail'，即masterset。
其次，在这些基于时间的线之间划分要素。例如，某些特征可以仅使用流的“头部”来完成，而其他特征需要比“头部”更宽的数据宽度，例如， masterset。在我们的示例中，假设我们定义了速度层来计算一天的数据量。然后Speed层将在所谓的Speed View中计算当天的大多数阅读故事（a）;批处理层将计算大多数阅读故事（a）的日期，（b）的一周，以及（c）所谓的批处理视图。请注意，是的，可能看起来有点冗余，但坚持这个想法。
第三，为客户关于速度视图和批处理视图的查询提供层响应，并相应地合并结果。速度视图和批处理视图的结果必然会有重叠。无论如何，这是速度与批次的划分，除了其他好处之外，还允许我们最大限度地降低风险，例如：（1）推出错误，（2）腐败数据传递，（3）长期批处理等。理想情况下，问题将在速度视图中捕获，然后将在批量视图重新计算之前应用修复。如果是，那么一切都很好。
总之，不需要使用IPC，因为它们彼此完全独立。因此，程序A不需要与程序B通信。相反，系统依赖于处理的一些重叠。例如，如果程序B基于每天计算其批处理视图，则程序A需要计算当天的速度视图以及处理可能花费的任何额外时间。这个额外的时间需要包括批处理层中的任何停机时间。
希望这有帮助！
注意：