大数据架构之-- Lambda架构

一、什么是Lambda架构

Lambda架构由Storm 的作者 [Nathan Marz] 提出，根据维基百科的定义，Lambda 架构的设计是为了在处理大规模数据时，同时发挥流处理和批处理的优势。通过批处理提供全面、准确的数据，通过流处理提供低延迟的数据，从而达到平衡延迟、吞吐量和容错性的目的。为了满足下游的即席查询，批处理和流处理的结果会进行合并。

二、Lambda架构组成

Lambda 架构包含三层，Batch Layer、Speed Layer 和 Serving Layer。架构图如下：

1. 基本概念

Batch Layer：批处理层，对离线的历史数据进行预计算，为了下游能够快速查询想要的结果。由于批处理基于完整的历史数据集，因此准确性可以得到保证。批处理层可以用 Hadoop、Spark 和 Flink 等框架计算
Speed Layer：加速处理层，处理实时的增量数据，这一层重点在于低延迟。加速层的数据不如批处理层那样完整和准确，但是可以填补批处理高延迟导致的数据空白。加速层可以用 Storm、Spark streaming 和 Flink 等框架计算
Serving Layer：合并层，计算历史数据和实时数据都有了，合并层的工作自然就是将两者数据合并，输出到数据库或者其他介质，供下游分析。

这里涉及到数据合并的问题，如果查询函数满足Monoid性质（结合律，（a+b）+c = a + (b + c)），只需要简单的合并Batch View和Realtime View中的经过数据集。否则，需要把查询函数转换为多个满足Monoid性质的查询函数的运算，单独对每个满足Monoid性质的查询函数进行Batch View和Realtime View中的结果数据集合并，然后再计算得到最终的结果数据集。也可以根据业务自身特性，运用业务自身的规则来对Batch View和Realtime View中的结果数据集合并。

2. lambda架构优点

职责边界清晰。Speed Layer处理数据为最近的增量数据流，Batch Layer处理的是全体数据集。Speed Layer为了效率，接收到新数据时不断更新Realtime View，而Batch Layer根据全体离线数据集直接得到Batch View。Speed Layer是一种增量计算，而非重新计算（recomputation）。

容错性。Speed Layer中处理的数据也不断写入Batch Layer，当Batch Layer中重新计算的数据集包含Speed Layer处理的数据集后，当前的Realtime View就可以丢弃，这意味着Speed Layer处理中引入的错误，在Batch Layer重新计算时都可以得到修正。这点也可以看成是CAP理论中的最终一致性（Eventual Consistency）的体现。

复杂性隔离。Batch Layer处理的是离线数据，可以很好的掌控。Speed Layer采用增量算法处理实时数据，复杂性比Batch Layer要高很多。通过分开Batch Layer和Speed Layer，把复杂性隔离到Speed Layer，可以很好的提高整个系统的鲁棒性和可靠性。

3. lambda架构缺点

实时与批量计算结果不一致引起的数据口径问题：因为批量和实时计算走的是两个计算框架和计算程序，算出的结果往往不同，经常看到一个数字当天看是一个数据，第二天看昨天的数据反而发生了变化。
批量计算在计算窗口内无法完成：在IOT时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成白天20多个小时累计的数据，保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
开发和维护的复杂性问题：Lambda 架构需要在两个不同的 API（application programming interface，应用程序编程接口）中对同样的业务逻辑进行两次编程：一次为批量计算的ETL系统，一次为流式计算的Streaming系统。针对同一个业务问题产生了两个代码库，各有不同的漏洞。这种系统实际上非常难维护
服务器存储大：数据仓库的典型设计，会产生大量的中间结果表，造成数据急速膨胀，加大服务器存储压力。

三、Lambda架构选型

1. Lambda架构模型

数据流进入系统后，同时发往Batch Layer和Speed Layer处理。Batch Layer以不可变模型离线存储所有数据集，通过在全体数据集上不断重新计算构建查询所对应的Batch Views。Speed Layer处理增量的实时数据流，不断更新查询所对应的Realtime Views。Serving Layer响应用户的查询请求，合并Batch View和Realtime View中的结果数据集到最终的数据集。

2. Lambda逻辑架构

数据从底层的数据源开始，经过各种各样的格式进入大数据平台，在大数据平台中经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算。一条线是进入流式计算平台（例如 Flink或者Spark Streaming），去计算实时的一些指标；另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔日才能看见。同时实时数据和离线数据进行合并，提供全量（含当天）的指标数据展示。

3. 组件选型

数据流存储可选用基于不可变日志的分布式消息系统Kafka；Batch Layer数据集的存储可选用Hadoop的HDFS，或者是阿里云的ODPS；Batch View的预计算可以选用MapReduce或Spark；Batch View自身结果数据的存储可使用MySQL（查询少量的最近结果数据），或HBase（查询大量的历史结果数据）。Speed Layer增量数据的处理可选用Flink或Spark Streaming；Realtime View增量结果数据集为了满足实时更新的效率，可选用Redis等内存NoSQL。

Batch Layer数据集的存储可选用Hadoop的HDFS，存储在HDFS的数据不再转存到其它组件，而是采用impala/sparkSQL基于内存查询的SQL引擎直接读取HDFS中的数据。Speed Layer增量数据的处理可选用Flink或Spark Streaming处理后存储到支持高吞吐低延时的列式存储系统中，比如HBase。ServingLayer阶段，数据在HDFS中进行合并，最终由impala负责提供即时查询。

四、Amazon AWS 的 Lambda 架构

Batch Layer：使用 S3 bucket 从各种数据源收集数据，使用 AWS Glue 进行 ETL，输出到 Amazon S3。数据也可以输出到 Amazon Athena （[交互式查询])工具）

Speed Layer：从上图看加速层有三个过程

Kinesis Stream 从[实时数据流])中处理增量的数据，这部分数据数据输出到 Serving Layer 的 Amazon EMR，也可以输出到 Kinesis Firehose 对增量数据进行后续处理

Kinesis Firehose 处理增量数据并写入 Amazone S3 中

Kinesis Analytics 提供 SQL 的能力对增量的数据进行分析

Serving Layer：合并层使用基于 Amazon EMR 的 Spark SQL 来合并 Batch Layer 和 Speed Layer 的数据。批处理数据可以从 Amazon S3 加载批处理数据，[实时数据]可以从 Kinesis Stream 直接加载，合并的数据可以写到 Amazone S3。下面是一段[合并数据代码]

参考文章：

Lambda架构 - 简书

深入理解大数据架构之——Lambda架构 - Heriam - 博客园