从传统大数据架构到Lambda架构到Kappa架构

为什么要总结这个?

工业互联网中，有些场景需要对数据实时分析和预测，另外对于工业的数据湖或数据中台也需要对数据整合。

其中再连接E-MapReduce、MaxCompute、DataHub之前需要先了解大数据架构，比如DataHub是基于Kappa架构，而E-MapReduce基于Hadoop生态则基于Lambda或traditional。

 

先整理一下traditional、Lambda架构和Kappa架构的优缺点：

	优点	缺点
Traditional	传统大数据平台架构由大数据组件与业务应用组成。可以分为分为三大部分：数据采集、数据处理、数据输出与展示。 1、灵活：基于hadoop的各类组件。 2、架构简单：传统大数据架构主要应对的是Batch processing和离线数据进行分析。 3、为理解Lambda架构奠定基础。	1、组件多，版本多，不易维护。 2、对运维人员要求高 3、对应用开发和数据科学能力要求高 4、高可用的架构比较复杂，比如如何解决双Master的脑裂问题。
Lambda	1、很好的结合了离线批处理和实时流处理的优点 2、稳定且实时计算成本可控 3、离线数据易于订正	1、大量在不同存储系统和数据格式中数据迁移和转换，造成维护困难和额外成本。 2、数据结构重新声明或者数据就该导致的数据运维很困难。 3、Batch Layer和Speed Layer需要维护两套代码，同时要确保实现逻辑一致性。 4、异常错误的捕获、处理和修正更为复杂。 5、前端查询的复杂度非常大、往往需要通过联邦计算来合并数据集，时效性受到数据集合并的效率限制。
Kappa	1、实时性高 2、只需要维护实时处理模块 3、可以通过消息重放 4、无需离线实时数据合并	1、只有speed layer 处理大规模离线数据，数据更新容易出现异常。 2、实时数据处理时存在丢失数据可能。 3、强依赖消息中间件缓存能力

 

Traditional architecture：

​

 

传统大数据平台架构由大数据组件与业务应用组成。可以分为分为三大部分：数据采集（同步）、数据处理、数据输出与展示

数据库同步Sqoop、日志同步Flume, 消息同步Kafka等。

• 数据采集（同步）

数据同步系统导入的数据存储在 HDFS。MapReduce、Hive、Spark 等计算任务读取 HDFS 上的数据进行计算，再将计算结果写入 HDFS。

• 数据处理

MapReduce、Hive、Spark 等进行的计算处理被称作是离线计算，HDFS 存储的数据被称为离线数据。

除了离线计算，还有一些场景，数据规模也比较大，但是要求处理的时间却比较短。比如淘宝要统计每秒产生的订单数，以便进行监控和宣传。这种场景被称为大数据流式计算，通常用 Storm、Spark Steaming 等流式大数据引擎来完成，可以在秒级甚至毫秒级时间内完成计算。

• 数据输出与展示

大数据计算产生的数据还是写入到 HDFS 中，但应用程序不可能到 HDFS 中读取数据，所以必须要将 HDFS 中的数据导出到数据库中。数据同步导出相对比较容易，计算产生的数据都比较规范，稍作处理就可以用 Sqoop 之类的系统导出到数据库。

将上面三个部分整合起来的是任务调度管理系统，不同的数据何时开始同步，各种 MapReduce、Spark 任务如何合理调度才能使资源利用最合理、等待的时间又不至于太久，同时临时的重要任务还能够尽快执行，这些都需要任务调度管理系统来完成。

lambda architecture：

 

Lambda 架构（Lambda Architecture）是由 Twitter 工程师南森·马茨（Nathan Marz）提出的大数据处理架构。这一架构的提出基于马茨在 BackType 和 Twitter 上的分布式数据处理系统的经验。

Lambda 架构使开发人员能够构建大规模分布式数据处理系统。它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性。可集成Hadoop, Kafka, Spark，Storm等各类大数据组件。

Lambda 架构总共由三层系统组成：批处理层（Batch Layer），速度处理层（Speed Layer），以及用于响应查询的服务层（Serving Layer）

 

Batch Layer : 存储数据集，在数据集上预先计算查询函数，并构建查询所对应的View。Batch Layer可以很好的处理离线数据，但有很多场景数据是不断实时生成且需要实时查询处理，对于这情况， Speed Layer更为适合。

Speed Layer : Batch Layer处理的是全体数据集，而Speed Layer处理的是最近的增量数据流。Speed Layer为了效率，在接收到新的数据后会不断更新Real-time View，而Batch Layer是根据全体离线数据集直接得到Batch View。

Serving Layer : Serving Layer用于合并Batch View和Real-time View中的结果数据集到最终数据集。

那我们能不能改进其中某一层的架构，让它具有另外一层架构的特性呢？

例如，改进批处理层的系统让它具有更低的延时性，又或者是改进速度层的系统，让它产生的数据视图更具准确性和更加接近历史数据呢？

虽然 Lambda 架构使用起来十分灵活，并且可以适用于很多的应用场景，但在实际应用的时候，Lambda 架构也存在着一些不足，主要表现在它的维护很复杂。

使用 Lambda 架构时，架构师需要维护两个复杂的分布式系统，并且保证他们逻辑上产生相同的结果输出到服务层中。

我们都知道，在分布式框架中进行编程其实是十分复杂的，尤其是我们还会针对不同的框架进行专门的优化。所以几乎每一个架构师都认同，Lambda 架构在实战中维护起来具有一定的复杂性。

那要怎么解决这个问题呢？我们先来思考一下，造成这个架构维护起来如此复杂的根本原因是什么呢？

维护 Lambda 架构的复杂性在于我们要同时维护两套系统架构：批处理层和速度层。我们已经说过了，在架构中加入批处理层是因为从批处理层得到的结果具有高准确性，而加入速度层是因为它在处理大规模数据时具有低延时性。

那我们能不能改进其中某一层的架构，让它具有另外一层架构的特性呢？

例如，改进批处理层的系统让它具有更低的延时性，又或者是改进速度层的系统，让它产生的数据视图更具准确性和更加接近历史数据呢？

Kappa architecture：

Kappa 架构是由 LinkedIn 的前首席工程师杰伊·克雷普斯（Jay Kreps）提出的一种架构思想。克雷普斯是几个著名开源项目（包括 Apache Kafka 和 Apache Samza 这样的流处理系统）的作者之一，也是现在 Confluent 大数据公司的 CEO。

Lambda 架构的一个很明显的问题是需要维护两套分别跑在批处理和实时计算系统上面的代码，而且这两套代码得产出一模一样的结果。，要面对的问题是：为什么我们不能改进流计算系统让它能处理这些问题？为什么不能让流系统来解决数据全量处理的问题？流计算天然的分布式特性注定其扩展性比较好，能否加大并发量来处理海量的历史数据？基于种种问题的考虑，Jay提出了Kappa这种替代方案。

与 Lambda 架构不同的是，Kappa 架构去掉了批处理层这一体系结构，而只保留了速度层。

 

 

 

那如何用流计算系统对全量数据进行重新计算，步骤如下：

1. 用Kafka或类似的分布式队列保存数据，需要几天数据量就保存几天。（Retention Period）180day or Forever.
2. 当需要全量计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个结果存储中。(Replay+incoming use stream process)
3. 当新的实例完成后，停止老的流计算实例，并把老的一引起结果删除(停止old version instance job and delete old view)。

 

参考文献：

https://developer.aliyun.com/article/752406

https://www.cnblogs.com/xiaodf/p/11642555.html

https://www.cnblogs.com/zz-ksw/p/12434916.html

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

标签：Layer,Kappa,离线,Batch,架构,数据,Lambda
来源： https://blog.51cto.com/u_13746986/3006710