我正在参与掘金创作者训练营第6期，点击了解活动详情
前言
随着大数据技术的发展，各种各样不同的技术层出不穷，任何时候都不可能只使用一个大数据组件解决业务上面临的所有问题。在合适的地方使用合适的大数据组件，并且能够充分的利用每一个大数据组件优点，才是数据平台所需要的架构设计。Lambda架构是由Storm的作者Nathan Mar提出的一个实时大数据处理框架，目标是设计出一个能满足高容错，低延时，可扩展的多个特性的大数据架构。
什么是 Lambda 架构
Lambda 架构并不是指单一性质的一个工具或者组件来解决具体的业务问题，而是利用多种类的不同组件，一系列的大数据技术来构建一个多层级的数据平台。Lambda架构的最主要的思想就是将大数据系统分层，每一层分别做好自己的功能：
- Speed Layer（加速层）
- Serving Layer（服务层）
- Batch Layer（批处理层）
大数据系统常常需要处理多达pb级别的数据量，那么如何去支撑在pb级的数据处理，清洗，应用？在Lambda架构上使用 T+1的预计算来应对巨大数据量的计算和处理。
传统的批量数据处理结构：hdfs和 MapReduce作业，在大量数据的低成本规模化作业上表现的非常不错，但是在数据的及时性上有着没有办法改变的缺点。新一代的流式数据处理框架，比如Nathan Mar创立的storm，在时间语义和 Exactly-once语义上都有一些问题。那么，通过混合使用strom 流式引擎以及mapreduce的批处理系统的 lamdba架构，既能保证低延迟，又能保证正确性，无疑是一种比较合适的架构方案
Batch层
Lambda 架构的创作者说过：大部分的大数据查询都可以归纳为一个函数：Query = Function(All Data)。如果对大量数据进行实时查询，就需要耗费大量的资源。其中解决的一个方式就是precomputed query function，对于大量数据进行拆解，分布式的运用不同的计算机进行计算，然后再汇总整个查询的结果，达到减少时间和加速处理的方法。实现这种预处理函数的部分叫做batch layer，主要实现 batch view = function(all data），第一步是 存储 master dataset（不变的持续增长的数据集），第二部是在元数据集上进行预选计算，构建查询所对应的view。
存储数据集
由于数据量很大，可以使用HDFS这样的大型数据存储方案。如果需要按照数据产生的时间顺序来存储数据，可以考虑采用时间序列数据库（TSDB）的存储方案，如InfluxDB。
构建查询View
如果我们事先在数据集上计算并保存查询函数的结果，我们就可以在查询时直接返回结果（或者通过简单处理得到结果），而不需要再次进行完整的、耗时的计算，而是把批处理层看作是一个数据预处理过程。我们把预先计算并保存的查询结果称为View（视图），这是Lambda架构的一个核心概念，并针对查询进行了优化。
Speed 层
Batch层主要是用来处理离线数据，但是大数据场景下很多时候需要处理实时的数据并且实时的给予处理结果。Speed Layer正是用来处理增量的实时数据，在结构上和bathc相似，都是根据数据进行计算产生view，主要区别在于：speed layer是增量的，实时性的数据集计算，而Batch layer则是全数据集的，耗时更长，更准确的计算。 Lambda架构将数据处理分解为Batch处理层和Speed层，具有以下优势。
- 容错性。在Speed层中处理的数据也会被持续写入Batch处理层。当在Batch Layer中重新计算的数据集包含在Speed Layer中处理的数据集时，当前的Realtime View就可以被修复。 这意味着在Speed Layer处理中引入的任何错误可以在Batch Layer重新计算时得到纠正。这一点也可以看作是CAP理论中 Eventual Consistency的体现。
- 复杂度隔离。Batch处理层处理的是离线数据，Speed层使用增量算法来处理实时数据，其复杂性比Batch处理层高得多。通过分离Batch处理层和Speed层，并将复杂性隔离到Speed层，整个系统的稳健性和可靠性可以得到很好的改善。
Serving层
Serving层 合并Batch View和Realtime View中的结果并且合并到最终的数据集。Serving层是一个逻辑概念，只要实现以下两个功能就可以：
- Serving层为视图建立索引，并提供接口，以便快速查询预计算的数据。
- Serving层是Lambda架构中批处理部分的最后一个组件。它与批处理层紧密相连，因为batch处理层负责不断地更新服务层的视图。由于batch处理计算的高延迟性，这些view会是过时的，但是问题不大。speed层将负责服务层中及时数据的更新和生成。
Lambda 架构的优点和缺点
优点： 最大的优点是可以保证整个计算数据在speed层处理问题后不会出错，并能保证最终的一致性。实时层的计算量比较小，计算成本比较低。实时计算和离线计算是分开的，可以节省服务器压力。
缺点： 业务方发现每天的数据可能会对不上，T+1和实时结果不能完全的保障一致，会导致实时数据被批次处理的数据回滚。 两种数据处理的架构的格式大相径庭，导致最后平台还需要额外的成本处理两种不同的格式进行统一化。 不论使用的是任何一种大数据组件，flink，spark，strom，开发的成本都会比较高，再修改和变更需求的时候，都需要重写原有的etl组件。 最致命的缺点是在越来越巨大的每日数据流的产生情况下，t+1的数据及时性可能都没有办法保证，在早上上班前的几个小时，可能根本没有办法处理完昨天产生的全部数据量，导致数据不准确，或者效率降低。
简单设计一个Lambda 架构：
