一、简介
相当于在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，因为它具有历史数据保存、重放的功能，并支持多消费者。
而流处理集群，一般选择Flink，因为Flink支持流批一体的处理方式，并且对SQL的支持率逐渐提高，所以可以尽量减少流处理和批处理逻辑代码不一致的情况。 对于数据服务，依然是需要实时读写的数据库产品，常见的有HBase、Druid、ClickHouse等。 但使用Kafka作为消息队列时要注意，Kafka因为消息是先存储到内存中，然后再落盘，所以可能会存在数据丢失的情况发生。 如果需要金融级别的数据可靠性，使用Rabbit MQ或者Rocket MQ这种支持数据直接持久化到磁盘中的消息队列，可能是更好的选择，但相应的会牺牲数据实时性和吞吐量。 原文链接：https://juejin.cn/post/7094459597737426981 标签：架构,队列,什么,批处理,Job,Kappa,Lambda From： https://www.cnblogs.com/robots2/p/17769376.html