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

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

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

（1）批处理层（batch layer）

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

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

（2）服务层（serving layer）

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

（3）流处理层（speed layer）

上述由批处理层与服务层组成的批处理部分能够对离线的历史数据进行完整的分析，但如同传统的批处理专用系统，这个处理过程将会遍历所有已存在的数据，将不可避免地造成较大的计算开销，并占用较长的处理时间。那么为了实现对实时数据的流式处理，便需要“流处理层”与它相结合。流处理层即基于流式处理建立的数据处理模块，弥补了批处理部分的高延迟更新缺陷，仅用于接收最近产生的流数据，并根据它进行计算得出即时结果。这里的“计算”更准确而言应是“近似计算”，因为流处理部分并不能够获知全局的数据，而仅仅能够获取刚刚发生的事件及最近的状态信息，但同时也由于这个原因，流处理层具备批处理模块无法达到的视图更新速度，能够以高出数个数量级的响应效率，支撑用户对于最新数据的分析要求。

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

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

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

Kappa架构由来自于LinkedIn公司的Jay Kreps在2014年提出，这一架构不仅大大降低了开发人员的负担，而且更为重要的是，使得在更高程度边缘化的云边协同平台上，利用边缘端的计算，使得批流一体化处理成为可能。

该架构提出输入数据只通过流计算一条链路进行处理，并生成待查询的视图。它的核心是数据以日志（log）的形式，以追加（append-only）且不可变的方式，存储在数据仓库中。换句话说，它要求长期存储的历史数据能够以有序日志流重新流入计算引擎，以备需要重新计算全局视图时，从数据仓库中取出这些数据进行全量计算，直到该数据副本的进度赶上当前事件发生的进度，丢弃原有视图，将新的副本视图作为主要结果。

利用这一架构，不仅能够在边缘端实现低延迟的流处理，同时也能够实现历史数据的批量处理。这为主要依赖于边缘计算能力的诸多应用场景提供了有力的技术支撑。

在对基于云边协同环境下数据处理方案以及数据系统架构的研究外，相关的其他研究也在不断尝试、探索。其中，一个方向便是将传统系统（例如MapReduce）中基于硬盘的存储改进为基于内存的存储。一方面，借助内存在硬件上天生具有的低延迟、高吞吐等特性，不论是实时的自动驾驶行车数据，还是短时高密度的健康行为统计数据，都能够避免大量的I/O（输入/输出）开销，支撑批流数据处理的速度要求；另一方面，通过检查点（checkpoint）备份算法、自动恢复（recovery）机制等补充，实现硬盘持久化存储的稳定性，保证了数据的可追溯、可恢复。目前，相关的研究人员已经在该研究方向上进行了长久的探索，并取得了较好的成效，实现了包括Spark在内的多个系统。