文章前言介绍Lambda体系结构Lambda体系结构关键Lambda三层体系结构Lambda三层体系结构Speed Layer速度层Serving layer服务层Lambda缺点kappa体系结构
首先，数据湖内的数据一般按照Lambda架构、Kappa架构、IOTA架构等数据处理的架构思想来利用。
当然，可以不遵循这两种体系结构思想，也可以有自己的想法进行设计。 不过，典型的Lambda和Kappa架构作为成熟的大数据分析架构，也很适合用于处理数据湖中的数据。
Lambda体系结构介绍Lambda体系结构Lambda体系结构是Storm作者Nathan Marz提出的实时大数据处理体系结构。 Marz在推特工作中开发了知名的实时大数据处理框架Storm。 Lambda体系结构是根据多年来进行分布式大数据系统的经验总结而成的。
Lambda体系结构的目标是设计一种体系结构，以满足实时大数据系统的关键特性，包括高容错、低延迟和可扩展性。 Lambda体系结构集成了离线计算和实时计算，融合了不变性(Immunability )，集成了读写隔离和复杂性隔离等一系列体系结构原则，以及Hadoop、Kafka
在Lambda体系结构的重要Robust and fault-tolerant ((容错和鲁棒性(注1 ) )大型分布式系统中，机器不可靠，可能会停机，但即使发生机器错误除了机器的错误，人很可能会犯错误。 软件开发难免有错误，系统必须对有错误的程序写入的错误数据有充分的适应性，因此比机器容错性更重要的容错性是人为操作的容错性。 对于大型分布式系统来说，人与机器的错误每天都有可能发生，如何应对人与机器的错误，使系统能够迅速从错误中恢复尤为重要。
低等待时间(低等待时间和更新)许多APP应用程序需要非常高的读和写等待时间，并且对更新和查询的响应需要很低的等待时间。
横向扩展：随着数据量/负载的增长，可扩展系统将通过增加机器资源来保持性能。 也就是说，常见的系统需要线性可扩展性，通常采用scale out (比例输出)而不是scale up (通过提高机器性能)。
通用(通用)系统必须能够处理广泛的APP应用，包括金融领域、社交网络和电子商务数据分析。
可扩展性：需要添加新功能、新功能时，可扩展系统可以以最低的开发成本添加新功能。
Allows ad hoc queries :数据必须有价值，并且必须能够方便快捷地查询所需的数据。
为了便于维护(Minimal maintenance )系统，控制复杂性很重要，越复杂的系统越容易出错，维护起来越困难。
易于调试(出现问题时，系统必须调试错误并具有足够的信息以确定问题的根本原因。 重要的是，可以跟踪每个数据生成点。
Lambda的三层体系结构Lambda的三层体系结构通常可以在任何查询中表示为query=function(alldata )，但如果在数据量非常大时还支持实时查询，则系统会非常庞大
在中，一种解决方法是“预计算查询函数”
预运算查询函数可以在系统空闲时根据业务所需的设计执行查询分析工作并生成结果。 这叫做Batch view
现在，有了这个Batch view，您可以修改对我们数据的查询，如下所示：
batch view=查询功能(alldata ) )。
查询=功能(batch view ) )。
从表达式中可以看到，真正的业务查询实际上是查询的批处理视图，即预先准备的数据内容。
该步骤也可以被称为中间数据生成
那么，在Lambda架构中，生成Batch view的步骤被称为Batch Layer批处理层。
Batch Layer具有两个特性：
保存主数据。 这是一个不断增加的数据集。 这对应于All data，即数据湖上需要使用的数据集。
在主数据集中运行预计算函数，以生成查询所需的相应视图
预处理结果称为视图，可以在视图中快速获得结果(或者与查询所有数据进行比较太简单了)。
可知预期计算函数本质上是批处理，适用于使用MR、Spark等计算引擎的处理。
并且，以这种形式生成的view都支持重新计算，如果对view不满意或者执行错误，再执行一次就可以了。
这项工作看起来很简单，实质上非常强大。 人为或机械发生的错误可以通过修正错误并重新计算得到正确的结果。
速度lay
er 速度层Batch Layer可以很好的处理离线数据，但是在我们的系统中，有许多的实时增量数据，而Speed Layer这一层就是用来处理实时增量数据的。
Speed Layer和Batch Layer比较类似，Speed Layer层是对数据进行计算并生成一个Realtime View，其主要区别在于：
Speed Layer处理的数据是最近的增量数据流，Batch Layer处理的全体数据集
Speed Layer为了效率，接收到新数据时不断更新Realtime View，而Batch Layer根据全体离线数据集直接得到Batch View。
Speed Layer是一种增量计算，而非重新计算（recomputation）
Speed Layer因为采用增量计算，所以延迟小，而Batch Layer是全数据集的计算，耗时比较长
综上所诉，Speed Layer是Batch Layer在实时性上的一个补充。Speed Layer可总结为：
realtime view＝function(realtime view，new data)
Lambda架构将数据处理分解为Batch Layer和Speed Layer有如下优点：
容错性。
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，可以很好的提高整个系统的鲁棒性和可靠性。
通俗的说，也就是Batch Layer根据其执行的时间间隔，不断的将Batch View 涵盖的范围覆盖到新数据上。而一旦Batch View执行到了某个时间点，这个时间点之前的Realtime View就会被丢弃。也就是说，由于Batch View的高延迟，在需要得到最新数据结果的时候，由Realtime View做补充，然后再后方，Batch View不断的追赶进度。
Serving layer 服务层Lambda架构中的最高层：Serving Layer层，可以理解为用户层，即响应用户的查询需求的层。
在Serving Layer中，将合并Batch View 以及Realtime View的结果，作为最终的View提供给用户查询。
那么，换算为前面的表达式为：Query = Function(Batch View + Realtime View)
上面分别讨论了Lambda架构的三层：Batch Layer，Speed Layer和Serving Layer。总结下来，Lambda架构就是如下的三个等式：
batch view = function(all data)realtime view = function(realtime view, new data) # 其中参数中的Realtime view就是不断的对以后的Realtime View进行迭代更新，直到被Batch View追上丢弃。query = function(batch view, realtime view) Lambda的缺点Lambda架构经过这么多年的发展，已经非常的成熟，其优点是稳定，对于实时计算部分的成本可控，而批处理部分可以利用晚上等空闲时间进行计算。这样把实时计算和离线处理的忧虑的雪糕错开来。
这种架构支撑了数据行业的早期发展，但也有一些缺点：
实时和批量结果不一致引起的冲突：由架构中可以得知，架构分实时和离线两部分，两边结果的计算要保持一致就比较困难。理论上来说，对于一些需要全量数据才能计算出的结果，90%的数据计算已经由离线负责完成，剩下10%是当前实时的计算结果，对两个结果合并就能做到100%全量的处理，并且保证低延迟。
但是，这仅仅是理论上以及我们所期望达到的，实际在应用的过程中因为各种原因导致这个时间没有对的上，导致衔接处出现了一些数据遗漏或者数据重复，就会让结果不准确。
并且，当过了一段时间后，离线部分追了上来，对错误进行了修正，又会导致在前端页面导致结果被修改的问题。
也就是说：理论是OK的，实施起来比较复杂，难免出现问题，对技术团队的能力有要求
批量计算无法在时限内计算完成：在IOT时代，数据量越来越多，很多时候的凌晨空闲期有的时候都不够用了，有的计算作业甚至会计算到大中午才结束，这样的话离线部分就大大了落后进度了，这导致实时的压力越来越大，其不断递归迭代的更新数据view越来越困难。
开发和维护的问题：由于要在两个不同的流程中对数据进行处理，那么针对一个业务就产生了两个代码库（一个离线计算、一个实时计算），那么这样的话会让系统的维护更加困难。
服务器存储开销大：由于View也就是中间数据的存在，会导致计算出许多的中间数据用来支撑业务，这样会加大存储的压力。（ps: 目前存储的成本越来越低，这个问题越来越不重要了）
也即是由于Lambda架构的这些局限性，Kappa架构应运而生，它比Lambda架构更加的灵活，我们在下面来看一下Kappa架构的相关细节。
kappa架构针对Lambda架构的需要维护两套程序等以上缺点，LinkedIn的Jay Kreps结合实际经验和个人体会提出了Kappa架构。
Kappa架构的核心思想是通过改进流计算系统来解决数据全量处理的问题，使得实时计算和批处理过程使用同一套代码。
此外Kappa架构认为只有在有必要的时候才会对历史数据进行重复计算，而如果需要重复计算时，Kappa架构下可以启动很多个实例进行重复计算。
一个典型的Kappa架构如下图所示：
Kappa架构的核心思想，包括以下三点：
1.用Kafka或者类似MQ队列系统收集各种各样的数据，你需要几天的数据量就保存几天。
2.当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
3.当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。
Kappa架构的优点在于将实时和离线代码统一起来，方便维护而且统一了数据口径的问题。而Kappa的缺点也很明显：
● 流式处理对于历史数据的高吞吐量力不从心：所有的数据都通过流式计算，即便通过加大并发实例数亦很难适应IOT时代对数据查询响应的即时性要求。
● 开发周期长：此外Kappa架构下由于采集的数据格式的不统一，每次都需要开发不同的Streaming程序，导致开发周期长。
● 服务器成本浪费：Kappa架构的核心原理依赖于外部高性能存储redis,hbase服务。但是这2种系统组件，又并非设计来满足全量数据存储设计，对服务器成本严重浪费。
而在IOT大潮下，智能手机、PC、智能硬件设备的计算能力越来越强，而业务需求要求数据实时响应需求能力也越来越强，过去传统的中心化、非实时化数据处理的思路已经不适应现在的大数据分析需求，提出新一代的大数据IOTA架构来解决上述问题
整体思路是设定标准数据模型，通过边缘计算技术把所有的计算过程分散在数据产生、计算和查询过程当中，以统一的数据模型贯穿始终，从而提高整体的预算效率，同时满足即时计算的需要，可以使用各种Ad-hoc Query(即席查询)来查询底层数据：
IOTA整体技术结构分为几部分：
● Common Data Model：贯穿整体业务始终的数据模型，这个模型是整个业务的核心，要保持SDK、cache、历史数据、查询引擎保持一致。对于用户数据分析来讲可以定义为“主-谓-宾”或者“对象-事件”这样的抽象模型来满足各种各样的查询。以大家熟悉的APP用户模型为例，用“主-谓-宾”模型描述就是“X用户 – 事件1 – A页面(2018/4/11 20:00) ”。当然，根据业务需求的不同，也可以使用“产品-事件”、“地点-时间”模型等等。模型本身也可以根据协议(例如 protobuf)来实现SDK端定义，中央存储的方式。此处核心是，从SDK到存储到处理是统一的一个Common Data Model。
● Edge SDKs & Edge Servers：这是数据的采集端，不仅仅是过去的简单的SDK，在复杂的计算情况下，会赋予SDK更复杂的计算，在设备端就转化为形成统一的数据模型来进行传送。例如对于智能Wi-Fi采集的数据，从AC端就变为“X用户的MAC 地址-出现- A楼层(2018/4/11 18:00)”这种主-谓-宾结构，对于摄像头会通过Edge AI Server，转化成为“X的Face特征- 进入- A火车站(2018/4/11 20:00)”。也可以是上面提到的简单的APP或者页面级别的“X用户 – 事件1 – A页面(2018/4/11 20:00) ”，对于APP和H5页面来讲，没有计算工作量，只要求埋点格式即可。
● RealTime Data：实时数据缓存区，这部分是为了达到实时计算的目的，海量数据接收不可能海量实时入历史数据库，那样会出现建立索引延迟、历史数据碎片文件等问题。因此，有一个实时数据缓存区来存储最近几分钟或者几秒钟的数据。这块可以使用Kudu或者Hbase等组件来实现。这部分数据会通过Dumper来合并到历史数据当中。此处的数据模型和SDK端数据模型是保持一致的，都是Common Data Model，例如“主-谓-宾”模型。
● Historical Data：历史数据沉浸区，这部分是保存了大量的历史数据，为了实现Ad-hoc查询，将自动建立相关索引提高整体历史数据查询效率，从而实现秒级复杂查询百亿条数据的反馈。例如可以使用HDFS存储历史数据，此处的数据模型依然SDK端数据模型是保持一致的Common Data Model。
● Dumper：Dumper的主要工作就是把最近几秒或者几分钟的实时数据，根据汇聚规则、建立索引，存储到历史存储结构当中，可以使用map-reduce、C、Scala来撰写，把相关的数据从Realtime Data区写入Historical Data区。
● Query Engine：查询引擎，提供统一的对外查询接口和协议(例如SQL JDBC)，把Realtime Data和Historical Data合并到一起查询，从而实现对于数据实时的Ad-hoc查询。例如常见的计算引擎可以使用presto、impala、clickhouse等。
● Realtime model feedback：通过Edge computing技术，在边缘端有更多的交互可以做，可以通过在Realtime Data去设定规则来对Edge SDK端进行控制，例如，数据上传的频次降低、语音控制的迅速反馈，某些条件和规则的触发等等。简单的事件处理，将通过本地的IOT端完成，例如，嫌疑犯的识别现在已经有很多摄像头本身带有此功能。
IOTA大数据架构，主要有如下几个特点：
● 去ETL化：ETL和相关开发一直是大数据处理的痛点，IOTA架构通过Common Data Model的设计，专注在某一个具体领域的数据计算，从而可以从SDK端开始计算，中央端只做采集、建立索引和查询，提高整体数据分析的效率。
● Ad-hoc即时查询：鉴于整体的计算流程机制，在手机端、智能IOT事件发生之时，就可以直接传送到云端进入realtime data区，可以被前端的Query Engine来查询。此时用户可以使用各种各样的查询，直接查到前几秒发生的事件，而不用在等待ETL或者Streaming的数据研发和处理。
● 边缘计算(Edge-Computing)：将过去统一到中央进行整体计算，分散到数据产生、存储和查询端，数据产生既符合Common Data Model。同时，也给与Realtime model feedback，让客户端传送数据的同时马上进行反馈，而不需要所有事件都要到中央端处理之后再进行下发。
如上图，IOTA架构有各种各样的实现方法，为了验证IOTA架构，很多公司也自主设计并实现了“秒算”引擎
在大数据3.0时代，Lambda大数据架构已经无法满足企业用户日常大数据分析和精益运营的需要，去ETL化的IOTA大数据架构也许才是未来。