什么是Kappa架构?
一、简介
相当于在Lambda架构上去掉了批处理层(Batch Layer),只留下单独的流处理层(Speed Layer)。通过消息队列的数据保留功能,来实现上游重放(回溯)能力。
当流任务发生代码变动时,或者需要回溯计算时,原先的Job N保持不动,先新启动一个作业Job N+1,从消息队列中获取历史数据,进行计算,计算结果存储到新的数据表中。
当计算进度赶上之前的Job N时,Job N+1替换Job N,成为最新的流处理任务。然后程序切换为从新的数据表中读取数据,停止历史作业Job N,并删除旧的数据表。
当然这种架构可以进行优化,将两张输出表合并为一张,减少运维部分的工作。
与Lambda架构相比,这种架构在吞吐和性能上要低于Lambda架构,因为Lambda架构的批处理是整个吞吐与性能的核心部分。
但Kappa统一了数据处理架构,减少了计算资源的浪费,降低了运维成本。而且使得代码只需要编写和维护一次,但Kappa无法解决流处理和批处理在部分处理逻辑不一致的情况。
二、架构技术选型
Kappa架构在选型上,消息队列常选择Kafka,因为它具有历史数据保存、重放的功能,并支持多消费者。
![](https://img2023.cnblogs.com/blog/2350829/202310/2350829-20231017115323437-811679338.png)
而流处理集群,一般选择Flink,因为Flink支持流批一体的处理方式,并且对SQL的支持率逐渐提高,所以可以尽量减少流处理和批处理逻辑代码不一致的情况。
对于数据服务,依然是需要实时读写的数据库产品,常见的有HBase、Druid、ClickHouse等。
但使用Kafka作为消息队列时要注意,Kafka因为消息是先存储到内存中,然后再落盘,所以可能会存在数据丢失的情况发生。
如果需要金融级别的数据可靠性,使用Rabbit MQ或者Rocket MQ这种支持数据直接持久化到磁盘中的消息队列,可能是更好的选择,但相应的会牺牲数据实时性和吞吐量。
原文链接:https://juejin.cn/post/7094459597737426981