如何避免Lambda体系结构中的代码冗余？

Question

我们有一个正在处理的批处理，如下所述

• Hive SQL正在用于每日批处理。
• 正在从文件或RDMBS中提取数据
• 数据被导入到 Raw-> Staging-> Mart 中，其中，stall到mart是所有业务转换，而到staging的原始操作只是清理和格式化数据。

现在，作为获取实时或接近实时数据的一部分，我正在评估 Lambda体系结构，这是什么计划？

• 所有源系统都将登陆Kafka。
• 同一批处理系统将使用Kafka主题。
• 新的Spark应用程序将使用kafka主题进行流式传输。
• 服务层将创建视图，这些视图将结合流和批处理的汇总数据以进行实时（近实时）处理。

问题是，逻辑将在HiveQL（批处理）和Spark（流式传输）中重复。有什么方法可以避免这种情况或将其最小化吗？

Answer 1

You can build your processing stages using Spark SQL and Spark Structured Streaming: https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html. Depending on your needs there can be some incompatibilities. But I´d try to build the Spark Aggregations + Transformations using the Dataset[_] api and then try to spawn in both ways, batch and streaming.

Answer 2

代码库重复的问题是lambda体系结构固有的。在wikipedia page

的“批评”部分中有提及

另一个问题是批处理和流之间的数据不同步，因此在将数据组合在一起时可能导致意外结果。例如，当键尚未成批存在时，跨流和成批加入。

我认为lambda体系结构是基于这样一种信念，即流传输既复杂又昂贵，因此请尽可能保留批处理，并仅为那些需要近实时的元素添加流传输。我们已经有了批处理，让我们添加一些流式传输内容。

另一种体系结构是对所有内容使用流传输。这是基于以下认识：批处理是流的一种特殊情况，因此在单个流平台上进行批处理和流处理也是如此。

use spark structured streaming for batch

lambda architecture issues and how only using streaming solves them

questioning the lambda architecture