转载 大数据批流处理之Lambda架构学习

大数据批流处理之Lambda架构学习，Lambda架构是当前大数据中批流处理方向影响较为深刻且应用广泛的架构。对于在云端的数据中心实现针对海量历史数据的批量计算及优化需要分别在云端、边缘端实现针对流数据的实时处理。

在实际生活中数据处理系统的能力亟待提高。最为迫切的便是如何利用云边协同计算平台的环境优势实现高效的批流融合处理系统，从而低延迟、高吞吐地对全量历史数据与实时的流数据进行融合计算，为各行业的新型应用提供有力支撑。

Lambda架构是什么？

对于在云端的数据中心实现针对海量历史数据的批量计算及优化，同时需要分别在云端、边缘端实现针对流数据的实时处理的场景。换言之为了达到全量数据批处理的准确性与实时数据流处理的低延迟的兼具，Nathan Marz基于他在Backtype和Twitter公司中对大数据处理系统的设计、开发经验，于2013年提出了批流处理系统架构Lambda。

Lambda架构是当前大数据中批流处理方向影响最为深刻、应用最为广泛的架构，主要分为以下3个组成部分：

(1)批处理层(batch layer)

该层负责两方面的内容：管理“主数据库”，即保存有完整的历史数据、持久化存储的、不可变的、仅支持追加的数据仓库;计算批处理视图，即通过批处理的方式对全量数据进行分析所得出的视图。

可见，批处理部分类似于其他专用批处理系统对大规模的数据在保证准确性和完整性的前提下，利用批处理优化技术进行全局分析。

(2)服务层(serving layer)

该层与批处理层一同工作功能上作为应用程序进行查询的服务器，负责对批处理层中产生的批处理视图建立索引以便应用程序能够根据用户的指定进行低延迟的、点对点(ad-hoc)的查询。需要注意的是，这里的“低延迟”指的是用于进行查询(query)时系统响应结果的延迟，这个时间会因为索引的建立而大大降低，但并不会改变批处理层中对全量数据进行计算更新的时间开销。

(3)流处理层(speed layer)

由批处理层与服务层组成的批处理部分能够对离线的历史数据进行完整的分析，但如同传统的批处理专用系统，这个处理过程将会遍历所有已存在的数据，将不可避免地造成较大的计算开销，并占用较长的处理时间。那么为了实现对实时数据的流式处理，便需要“流处理层”与它相结合。流处理层即基于流式处理建立的数据处理模块，弥补了批处理部分的高延迟更新缺陷，仅用于接收最近产生的流数据，并根据它进行计算得出即时结果。

这里的“计算”更准确而言应是“近似计算”，因为流处理部分并不能够获知全局的数据，而仅仅能够获取刚刚发生的事件及最近的状态信息，但同时也由于这个原因，流处理层具备批处理模块无法达到的视图更新速度，能够以高出数个数量级的响应效率，支撑用户对于最新数据的分析要求。

在上述批处理层、服务层和流处理层的基础上，Lambda架构的核心思想便是将数据输入到了批处理、流处理两个数据链路中，分别并行地进行计算，并在用户进行查询的阶段，将两个数据链路产生的结果(视图)进行融合，返回给用户。这样，一方面，批处理模块基于全量数据计算得出的结果保证了最终响应结果的完整性与准确性;另一方面，流处理模块基于实时数据进行流处理获得的即时更新保证了用户查询的极低延迟。

缺陷：设计和实现该架构的过程中，存在一些无法避免的问题，其中最为主要的便是开发和维护的复杂性。对于开发人员而言，实现一个较为完善的分布式处理系统需要付出很大的精力，这不仅表现在设计、编码的过程中，更表现在效率优化、后期维护升级等方面，每一个细节的调整都可能会导致设计思路的转变，从而造成较大的更新代价。

那么是否能够在尽量避免同时开发批、流两个系统的复杂性的同时，实现基于云边协同平台的批流融合处理呢?换言之能否改进批处理或流处理其中一个以使它不足的方面达到或接近另一模块的水平?