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

前言

我们在10月10日推送的文章《深入浅出解析大数据Lambda架构》中，详细分析了Lambda架构的技术背景，架构原理，并对基于Lambda架构设计的智慧交通系统案例进行了分析，得到了众位读者的热烈反响。

为了进一步探讨这种批处理和实时处理有效整合在同一系统的架构，我们将在今天的文章中分析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的整体架构图：

图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所示：

图2  Kappa架构图

和Lambda架构相比，在Kappa架构下，只有在有必要的时候才会对历史数据进行重复计算，并且实时计算和批处理过程使用的是同一份代码。或许有些人会质疑流式处理对于历史数据的高吞吐量会力不从心，但是这可以通过控制新实例的并发数进行改善。上面架构图中，新老实例使用了各自的结果存储，这便于随时进行回滚，更进一步，假如我们产出的是一些算法模型之类的数据，用户还可以同时对新老两份数据进行效果验证，做一些A/B test或者使用bandit算法来最大限度的使用这些数据。

两个架构的对比

优缺点对比

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

表1  Lambda和Kappa优缺点对比

如上表所示，Kappa架构相对来说有更多的优点，目前也被更多的厂商用于构建商业项目。第一，Lambda架构不仅需要维护两套分别跑在批处理和实时计算系统上面的代码，还需要批处理和全量计算长时间保持运行；而Kappa架构只有在需要的时候才进行全量计算。第二，Kappa架构下可以启动很多个实例进行重复计算，因此在需要对一些算法模型进行调优时，Kappa架构下只需要更改一套系统的参数即可，并且允许对新老数据进行效果比对；但是在Lambda架构下，需要同时更改流计算系统算法模型和批处理系统算法模型，调参过程相对比较复杂。第三，从用户开发、测试和运维的角度来看，Kappa架构下，开发人员只需要面对一个框架，开发、测试和运维的难度都会相对较小，这是个非常重要的优点。

如何选择

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

1. 业务需求

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

2. 开发测试难易程度

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

3. 运维成本

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

StreamSQL与Lambda架构

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

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

图3  StreamSQL作为流处理引擎搭建的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中的列式数据进行统计分析。

StreamSQL对Kappa架构的改进之处，包括如下：

1. 上述提到，原本的Kappa架构把历史数据保存在Kafka或类似的分布式消息队列，这样的特性导致了一个缺点就是它只能保存几天或几个月的数据，并且只能以流的形式保存，因此对于历史数据的处理能力有限；而StreamSQL支持输出到多种格式，既允许输出到Kafka，也可以将结果以各类格式（TEXT表、ORC表、Holodesk表、HBase表）保存在Inceptor，实现更长期的存储，因此它可以应对更大数据规模的业务需求。

2. StreamSQL支持在实时计算时或历史数据分析时将流数据和Inceptor表的数据做关联，大大增强了它的历史数据处理能力。

3. StreamSQL另一特色功能就是它可以完美兼容SQL标准和PL/SQL，使得用户可以通过SQL的方式实现业务逻辑，极大降低了流应用开发的门槛。

4. StreamSQL还增加了Application管理的功能，运行时各个Application之间相互隔离并需要权限验证，很大程度上提高了系统的安全性和可用性。

Kappa架构案例分析

下面我们以StreamSQL作为流处理引擎来搭建一个基于Kappa架构的智慧交通系统，并对其中的套牌车辆实时预警业务场景进行详细的数据流分析，架构图如图4所示：

图4  智慧交通系统架构图    

当前端卡口将监控到的车辆信息接入Kafka分布式消息队列后，总线会对这些数据进行归类分拣，分发给不同的服务集群，比如实时入库服务集群、未年检车监控服务集群等。

假设部分数据被送入到了违法车辆监控服务集群中，该集群其中一个业务是对车辆进行套牌分析。前面的章节提到Kappa架构方便进行算法模型的调优，下面我们来看一下具体是怎么做的。

首先，假如我们创建了一个UDF函数DectectCloneVehicle(param1, param2)，用于检查待检测牌照是否为套牌车辆。该UDF接收两个输入参数：当两辆相同牌照的车直线距离超过param1公里且出现时间低于param2分钟时，则被视为套牌车。该函数有两种返回结果：如果是套牌车则输出1，否则输出0。

假设我们起初设定的套牌分析策略是，如果某两辆相同牌照的车直线距离超过20公里，出现时间小于2分钟, 那么判定该车牌被套牌。启动一个Stream Job实例，并按照该策略进行分析的StreamSQL语句如下：

CREATE STREAM vehicle_stream1(license STRING, location STRING, time TIMESTAMP)

    ROW FORMAT DELIMITED FIELDS TERMINATED BY ','

    TBLPROPERTIES ("topic"=fakeLicense", kafka.zookeeper"="172.16.1.128:2181",

    "timefield"="time", "timeformat"="yyyy-MM-dd HH-mm-ss.SSS);

CREATE TABLE clone_vehicle_result_app1(license STRING,location STRING, time TIMESTAMP);

INSERT INTO clone_vehicle_result_app1

SELECT DetectCloneVehicle(20, 2) as cloned

FROM vehicle_stream1

HAVING cloned>0;

但是通过实践并且考虑到一些现实情况（如直线距离是否合理，当前路段高速类路段多还是低速路段多等），我们发现如果按照此参数执行检测，套牌排查效率会很低。假如把套牌车辆的判定标准调整为：直线距离超过10公里，出现时间小于5分钟的两辆相同牌照的车，效率就会有极大幅度的提升。现在重新启动一个Stream Job实例，执行如下的StreamSQL语句：

CREATE STREAM vehicle_stream2(license STRING, location STRING, time TIMESTAMP)

    ROW FORMAT DELIMITED FIELDS TERMINATED BY ','

    TBLPROPERTIES ("topic"=fakeLicense", kafka.zookeeper"="172.16.1.128:2181",

    "timefield"="time", "timeformat"="yyyy-MM-dd HH-mm-ss.SSS);

CREATE TABLE clone_vehicle_result_app2(license STRING,location STRING, time TIMESTAMP);

INSERT INTO clone_vehicle_result_app2

SELECT DetectCloneVehicle(10, 5) as cloned

FROM vehicle_stream2

HAVING cloned>0;

该Stream Job的效率高于之前所选用的参数，这样我们就进行了一步UDF模型参数的调优。所以在做实际分析时，业务执行效率的提升不能单纯的依靠系统提供的优化帮助，用户需要能够根据所采用的架构和所处理的问题、应用的模型方法，结合实际外部限制选择最有效的模型参数。

结语

Lambda架构和Kappa架构是常用的两个大数据系统架构，它们都意在解决批处理和实时计算相结合的问题。对于Lambda架构，如何简化其开发方式，降低运维成本，是一件值得考虑和继续研究的事情。Kappa架构非常显著的改进了Lambda需要维护两套系统的缺点，但是在做服务选型的时候，仅仅使用开源Spark和Kafka接合还并不能设计出非常好的业务方案。为此，星环科技基于Kappa的架构设计了StreamSQL，通过高效的性能处理、HA保证、统一的SQL编程、允许流上数据和历史数据关联等创新技术，有效的解决了Kappa对一些复杂场景处理能力不足的问题，是一个理想的构建Kappa系统的服务组件。

对此篇文章如有任何问题，欢迎以邮件形式联系我们：[e-mail]

最后祝广大程序猿媛欢度佳节！

---

往日原创文章

大数据开放实验室由星环信息科技（上海）有限公司运营，专门致力于大数据技术的研究和传播。若转载请在文章开头明显注明“文章来源于微信订阅号——大数据开放实验室”，并保留作者和账号介绍。