如何避免 Lambda 架构中的代码冗余？

Posted 2023-04-18

【中文标题】如何避免 Lambda 架构中的代码冗余？

【英文标题】：How to avoid Code Redundancy in Lambda Architecture?

【发布时间】：2018-09-18 22:56:41

【问题描述】：

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

Hive SQL 用于日常批处理。 正在从文件或 RDMBS 中提取数据 数据在

Raw --> Staging --> Mart

中提取，从 staging 到 mart 是所有业务转换，从 raw 到 staging 只是对数据进行清理和格式化。

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

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

问题是，Logic 会在 HiveQL (Batch) 和 Spark (Streaming) 中复制。有什么办法可以避免或减少这种情况？

【问题讨论】：

如果数据来自RDBMS，则表明它至少在NF3中。您是否需要进行大量连接才能获得可用的业务对象？连接的记录多久更新一次？您能否提供有关数据性质的更多信息？是只追加数据源还是可以在源系统中删除和更新记录。

【参考方案1】：

您可以使用 Spark SQL 和 Spark Structured Streaming 构建处理阶段：https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html。根据您的需要，可能会有一些不兼容的地方。但我会尝试使用 Dataset[_] api 构建 Spark Aggregations + Transformations，然后尝试以批处理和流式两种方式生成。

【参考方案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

【讨论】：

最初我想只使用流式传输并删除批处理。但是，我们需要历史数据（原始数据）进行审计。还有其他项目共享数据，因此需要在清理后存储数据以避免开销。这让我想到了 lambda 架构。

如果您使用的是 Cloudera（CDH5 或 CDH6）而不是结构化流，请参阅 cloudera.com/documentation/enterprise/6/release-notes/topics/…

@alexeipab 我认为 cloudera 的“支持”意味着他们的支持人员不会接受它的问题。他们不能只是从 Spark 2 中删除 API。如果您尝试在 YARN 中运行这些 Spark 作业，它仍然“有效”

您会使用不受支持的功能构建生产管道吗？如果 Cloudera 补丁或升级到下一个版本会对其进行制动并且他们不会修复它会发生什么？过去 Azure Event Hub 连接器（Cloudera 不支持）也存在问题，当由于 Spark 2.2 包括 CDH 与 Spark 2.2 的 Apache 版本不具有相同签名时，结构化流引发异常:(