Kappa:比Lambda更好更灵活的实时处理架构

转自：http://bigdata.51cto.com/art/201702/531038.htm

 

本篇文章中分析Lambda三层结构模型的适用场景，同时暴露出Lambda架构一个最明显的问题：它需要维护两套分别跑在批处理和实时计算系统上面的代码，而且这两套代码需要产出一致的结果。根据对此缺点的分析，我们引出当时还在LinkedIn的大神Jay Kreps提出的Kappa架构，本文会对Kappa架构原理进行介绍，并讨论两个架构的优缺点，最后给出一个Kappa架构的案例分析。

对Lambda架构不熟悉或者希望了解Lambda架构应用案例的读者，请回顾历史文章中的《深入浅出解析大数据Lambda架构》一文。

Lambda架构回顾Lambda架构的核心思想是把大数据系统拆分成三层：Batch Layer，Speed Layer和Serving Layer。其中，Batch Layer负责数据集存储以及全量数据集的预查询。Speed Layer主要负责对增量数据进行计算，生成Realtime Views。Serving Layer用于响应用户的查询请求，它将Batch Views和Realtime Views的结果进行合并，得到最后的结果，返回给用户。图1给出了Lambda的整体架构图：

Kappa架构上述提到，为了将批处理和实时处理相结合，Lambda设计了Batch Layer和Speed Layer两层结构，分别用于批处理和实时计算，因此需要维护两套分别跑在批处理和实时计算系统之上的代码。面对这个问题，有人会有这样的疑问，为什么不用流计算系统来进行全量数据处理从而去除Batch Layer这一层?

可能有这样回答：流计算给人的印象是对一些流式的、临时的数据进行计算，将结果保存后就将原始数据丢弃了，因此它不适合用来处理历史数据。其实这种答案并不完全正确，对于基于Lambda架构实现的Storm框架确实是这样的，但对于后来出现的Spark并不是。

Storm是在2011年7月开源的，Spark是在2012年之后逐渐为人们所知的，因此在Nathan Marz设计Lambda架构的时候，当时还并没有一个框架既可以用于离线处理，又可以进行实时计算。但随着Spark技术的发展，这一想法成为了可能，Spark本身可以用于批处理，而构建在Spark之上的Spark Streaming又可以用于实时计算，因此利用一套系统来应对批处理和实时计算相结合的业务完全是可行的。

Kappa架构的核心思想包括以下三点：

1. 用Kafka或者类似的分布式队列系统保存数据，你需要几天的数据量就保存几天。
2. 当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
3. 当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。

Kappa的架构图如图2所示：

和Lambda架构相比，在Kappa架构下，只有在有必要的时候才会对历史数据进行重复计算，并且实时计算和批处理过程使用的是同一份代码。或许有些人会质疑流式处理对于历史数据的高吞吐量会力不从心，但是这可以通过控制新实例的并发数进行改善。

上面架构图中，新老实例使用了各自的结果存储，这便于随时进行回滚，更进一步，假如我们产出的是一些算法模型之类的数据，用户还可以同时对新老两份数据进行效果验证，做一些A/B test或者使用bandit算法来最大限度的使用这些数据。

优缺点对比

对比项	Lambda架构	Kappa架构
数据处理能力	可以处理超大规模的历史数据	历史数据处理的能力有限
机器开销	批处理和实时计算需一直运行，机器开销大	必要时进行全量计算，机器开销相对较小
存储开销	只需要保存一份查询结果，存储开销较小	需要存储新老实例结果，存储开销相对较大
开发、测试难易 程度	实现两套代码，开发、测试难度较大	只需面对一个框架，开发、测试难度相对较小
运维成本	维护两套系统，运维成本大	只需维护一个框架，运维成本小

表1 Lambda架构和Kappa架构优缺点对比

如上表所示，Kappa架构相对来说有更多的优点，目前也被更多的厂商用于构建商业项目。

第一，Lambda架构不仅需要维护两套分别跑在批处理和实时计算系统上面的代码，还需要批处理和全量计算长时间保持运行;而Kappa架构只有在需要的时候才进行全量计算。

第二，Kappa架构下可以启动很多个实例进行重复计算，因此在需要对一些算法模型进行调优时，Kappa架构下只需要更改一套系统的参数即可，并且允许对新老数据进行效果比对;但是在Lambda架构下，需要同时更改流计算系统算法模型和批处理系统算法模型，调参过程相对比较复杂。

第三，从用户开发、测试和运维的角度来看，Kappa架构下，开发人员只需要面对一个框架，开发、测试和运维的难度都会相对较小，这是个非常重要的优点。

如何选择

从上述的优缺点对比来看，业务需求、开发测试难易程度和运维成本为三个主要的框架选择考虑因素，而机器开销和存储开销，虽然存在一定差别，但是差别不是很大，所以这里我们也主要从业务需求，开发测试难易程度和运维成本三方面来考虑如何对上述两个架构做出选择。

业务需求

用户需要根据自己的业务需求来选择架构，如果所需要处理的历史数据规模较大，比如某省智慧交通系统几年达TB级的数据，那么选择Lambda架构可能较为合适;如果处理的数据量较小，比如分析某电商网站近30天的数据，那么选择Kappa架构可能更为合适。

开发测试难易程度

如果项目中需要频繁的对算法模型参数进行调优，Kappa架构要来的更为便捷;另外还有一个判定依据就是你设计的算法是否同时适合批处理和实时计算，如果同一份代码可以很好地处理两者，那么可以选择Kappa架构;但是针对某些复杂的案例，其实时计算的结果和批处理的结果是不同的，比如某些机器学习的应用，由批处理生成预测模型，再交由实时计算系统进行实时分析，那么这种情况下，批处理层和实时计算层不能进行合并，因此应该选择Lambda架构。

运维成本

Kappa架构的运维成本较低，比较适合技术人力资源有限的团队或企业。

StreamSQL与Lambda架构Transwarp StreamSQL是星环科技专门为企业级用户打造的流计算引擎，主要应用于实时性较强的应用场景。比如，金融行业需要对市场波动进行实时预警;银行业务需要在线分析业务等。它对于SQL和PL/SQL的支持使得用户可以通过SQL的方式实现复杂业务逻辑，大大降低了流应用开发的门槛，也使得基于一套SQL程序开发离线和实时业务成为可能。

图3为利用Kafka和StreamSQL搭建的一个Kappa架构系统，并且对原有的Kappa架构的缺点做了改进。

StreamSQL每隔100ms会从Kafka消息队列中接收一批时序数据，如t0-tn时刻的数据，其中t0的数据为(0,1,2,3,4)，t1的数据为(5,6,7,8,9)…。当前批次的数据会被映射成一张二维关系表，通过SQL进行变换并转成内存列式存储，变换后的数据会实时写入Holodesk以持久化到SSD上，通过此方式永久保留或者保留最近一个月的数据。应用程序可以通过Inceptor SQL或者R语言对Holodesk中的列式数据进行统计分析。