另一方面，Lambda架构Lambda架构是Storm的作者[Nathan Marz]提出的，根据维基百科的定义，Lambda架构在处理大数据时，需要流处理和条形通过批处理提供完整准确的数据，通过流处理提供低延迟的数据，可以在延迟、吞吐量和容错之间取得平衡。 为了满足下游即席查询，将合并批处理和流处理的结果。
二、Lambda框架构成Lambda框架，包括底层、速度层和服务层三层。 体系结构图如下：
1 .基本概念Batch Layer:预先计算离线历史数据，以便在下游快速查询想要的结果。 批处理基于完整的历史数据集，从而保证准确性。 批处理层可以在Hadoop、Spark、Flink等框架中计算
Speed Layer:加速处理层并处理实时增量数据。 这一层侧重于低延迟。 虽然加速层中的数据不像批处理级别那么完整和准确，但它可以填补由于批处理的高延迟而导致的数据空白。 可以在Storm、Spark streaming、Flink等框架中计算加速层
Serving Layer:合并图层时，既有计算历史数据，也有实时数据。 合并层的工作当然是将两者的数据合并并输出到数据库或其他介质，然后在下游进行分析。
这里涉及数据合并的问题，只要查询函数满足Monoid的性质(结合规则，(a b ) c=a (BC ) )，就可以简单地合并Batch View和Realtime View中的经过数据集。 否则，必须将查询函数转换为满足Monoid性质的多个查询函数的运算，为每个满足Monoid性质的查询函数分别集成Batch View和Realtime View结果数据集，然后计算最终结果数据集根据业务本身的特点，Batch View和实时视图的结果数据集还可以使用业务本身的规则进行集成。
2. lambda结构优势职责边界清晰。 Speed Layer处理的数据是最近的增量数据流，而Batch Layer处理的是整个数据集。 为了提高效率，Batch Layer会在收到新数据时继续更新实时视图，而Batch Layer会直接从整个脱机数据集获取Batch View。 Speed Layer是增量计算，而不是“重新计算”。
容错。 由“Speed Layer”处理的数据也继续写入“Batch Layer”。 如果Batch Layer重新计算的数据集包含由Speed Layer处理的数据集，则可以销毁当前实时视图。 也就是说，在Batch Layer中重新计算时，Speed Layer处理中引入的错误将得到修复。 这也被认为是CAP理论中最终一致性的体现。
复杂性隔离。 Batch Layer正在处理脱机数据，可以很好地控制。 Speed Layer采用增量算法处理实时数据，复杂度比Batch Layer高很多。 通过将Batch Layer和Speed Layer分离，将复杂度分离为Speed Layer，可以提高整个系统的鲁棒性和可靠性。
3. lambda体系结构缺点
实时与批量计算结果不一致引起的数据口径问题批量计算和实时计算进行了两个计算框架和计算程序，因此计算结果往往不同，一个数字当天是一个数据，第二天看昨天的数据往往相反。
33558 www.Sina.com/:在IOT时代，数据量越来越大，经常发现晚上只有四五个小时的时间段，无法完成白天20小时以上的累计数据，保证早上上班前按时发出数据
http://www.Sina.com/:在lambda体系结构中，在两个不同的应用程序编程接口(API )中使用相同的业务逻辑2 一个是批量计算的ETL系统，一个是流计算的streaminface。为同一业务问题生成两个代码库，每个代码库都有不同的漏洞。 这个系统实际上非常难维护
批量计算在计算窗口内无法完成:典型的数据仓库设计会生成大量的中间结果表，使数据快速膨胀，增加服务器存储压力。
三、Lambda体系结构选型1. Lambda体系结构模型
数据流进入系统后，同时发送到“Batch Layer”和“Speed Layer”进行处理。 Batch Layer在不变模型中脱机存储所有数据集，并不断重新计算与跨数据集构建查询相对应的Batch 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 - 博客园