当数据处理做不到实时，应该怎么办？
在很多业务场景中，我们会要求查询或计算的结果能够实时返回。比如火灾预警、贷前风险检测、量化交易等。如果事后再分析数据，这个时候火灾已经发生，骗子已经卷款而逃，市场机会已经错过，分析数据带来的价值也只限于“前事不忘，后事之师”了。
因此，对实时流数据的计算和分析一定要在其实时价值消退之前完成。这就要求计算的时延必须小。有时候因为数据量大、计算复杂的原因，实时计算无法完成，这时甚至会牺牲部分结果的准确性，保证误差在可接受范围的前提下，能偶优先满足计算的实时性。
但是不得不承认的是，即使我们已经采取了各种极富创造性和技巧性的优化手段，有些问题在当前普遍的硬件计算能力下，采用分布式、大数据、内存计算等技术，也不能直接得到实时计算的结果。那是不是说面对这些问题，就该彻底放弃实时计算的念头呢？
不是的。虽然不能直接实时计算出问题的答案，但是我们还是可以通过增量计算的方式来间接获得问题的实时答案。即使有时候这些答案具有稍微的迟滞性和近似性，但是只要它们能够带来尽可能最新的信息价值，那它们也是有用的。
Lambda架构正是这样一种用来处理不能够直接实时计算问题的通用架构。Lambda架构最初由Storm流计算框架的作者Nathan Marz为构建大数据场景下低延时计算和查询的通用架构模式而提出。Lambda架构总体上分为三层：批处理层（batch layer）、快速处理层（speed layer）和服务层（serving layer）。其中批处理和快速处理层分别处理历史全量数据和新入系统的增量数据，而服务层用于将批处理和快速处理层的结果合并起来，以提供最终用户或应用程序的查询服务。
Lambda架构
在Lambda架构中，各层的具体功能如下。
批处理层。批处理层是为了存储主数据集和预计算各种批处理视图。当数据进入批处理层时，数据被存储下来，并作为数据系统的主要数据集。由于全量的数据会很大，计算比较耗时，所以批处理层的主要作用就是对预定的查询进行预计算，并将计算结果保存下来。如果做得更精细些，可以在计算结果上生成各种视图，并构建相应的索引，以供后续快速检索和查询。
快速处理层。在最标准的Lambda架构中，快速处理层的作用是实时计算在批处理层两次调度执行期间新到的增量数据，并将计算结果保存下来。在这种标准架构下，理论上快速处理层的输出结果与批处理层的输出结果在业务意义上应该是完全相同。换言之也就是，如果我们分别用两张数据库的表来存储批处理层和快速处理层的计算结果，那么这两张数据库表的表结构应该是相同的。只是因为分析的时间段不同，这两张表里的数据记录不一样而已。但Lambda架构并非铁板一块的“定式”，在很多场景下我们可以根据自己的需求对快速处理层做出改动。比如，既然前一次的批处理层计算结果已经存储在数据库中了，那为什么快速处理层就不可以直接使用这次的批处理层计算结果呢？事实上我们经常这样做，比如用批处理层学习统计模型或机器学习模型，将模型结果保存到数据库，然后快速处理层从数据库中定期更新模型，并根据模型做出实时预测。
服务层。服务层用于将批处理层和快速处理层各自计算所得结果合并起来，从而能够实时提供用户或应用程序在全量数据集上的查询结果。服务层对外提供的查询接口是只读的，这对于实现高性能、无状态、高可靠的查询服务非常有用。所以服务层在技术实现上结构相对简单，但它与具体的业务查询会结合得更加紧密。
Lambda架构是一种架构设计思想，针对每一层的技术组件选型并没有严格限定。所以我们可以根据自己公司和项目的实际情况选择相应的技术方案。批处理层的数据存储，可以选择HDFS、S3等大数据存储方案。批处理层的任务执行框架，则可以选择MapReduce、Hive、Spark等大数据计算框架。批处理层的计算结果（比如数据库表或者视图），由于需要被服务层或快速处理层高速访问，所以可以存放在诸如MySQL、HBase等能够快速响应查询请求的数据库中。对于快速处理层，这就是各种实时流计算框架的用武之地了，比如Flink、Spark Streaming和Storm等。快速处理层由于对性能要求更加严苛，它们的计算结果可以写入像Redis这样具有超高性能表现的内存数据库中。在服务层，当接收到查询请求时，就可以分别从存储批处理层和快速处理层计算结果的数据库中，取出相应的计算结果并做出合并，作为最终的查询输出。
Lambda架构为开发大数据量下的实时应用提供了一种切实有效的通用模式。通过将数据和处理分为批处理层、快速计算层和服务层三个相对独立的层次，Lambda架构降低了大数据在持续更新过程中问题的复杂性，并能够实时获得在全部数据集合上的查询结果。不过Lambda架构也存在一些问题。其中最主要的就是，对于同一个查询目标，需要分别为批处理层和快速计算层开发不同的算法实现。也就是说，对于同一套大体相同的逻辑，需要开发两种完全不同的代码，这对开发、测试和运维都带来一定的复杂性和额外工作量。
为了解决Lambda架构中因为批处理层和快速计算层“异质”带来的复杂性问题，LinkedIn的Jay Kreps在Lambda架构的基础上提出了Kappa架构。Kappa架构的核心思路就是，将批处理层也用快速处理层的流计算技术替换。这样一来，批处理层和快速处理层都是使用了相同的流处理逻辑，在开发、测试和运维上都有一个更统一的框架，从而降低了开发、测试和运维的成本。
Kappa架构
从Lambda架构上演进而来的Kappa架构，通过流来统一编程界面，确实极大简化了数据系统的构建过程。虽然在架构体系和实际代码开发过程中，Kappa相比Lambda具有更好的一致性。但是这并不意味着Kappa比Lambda架构更好，它们有各自的意义和价值。Lambda架构代表的是一种更通用的架构思想，指导我们在碰到不能直接用实时计算方式解决大数据问题时，不妨尝试采用这种离线和实时相结合的折衷方案。而Kappa架构的最大价值，则是启发我们尽量用流式计算框架来统一离线计算和实时计算。
作者：周爽，本硕毕业于华中科技大学，先后在华为2012实验室高斯部门和上海行邑信息科技有限公司工作。开发过实时分析型内存数据库RTANA、华为公有云RDS服务、移动反欺诈MoFA等产品。目前担任公司技术部架构师一职。著有《实时流计算系统设计与实现》一书。
☞两成开发者月薪超 1.7 万、算法工程师最紧缺！| 中国开发者年度报告
☞Libra为何而生？Facebook为何要给 Libra创建Move语言？Calibra技术负责人给出了回答