上一期讲了Lambda架构，对于实时数仓而言，Lmabda架构有很明显的不足，首先同时维护两套系统，资源占用率高，其次这两套系统的数据处理逻辑相同，代码重复开发。
能否有一种架构，只需要维护一套系统，就可以同时完成流处理、批处理任务呢？当然，那就是Kappa架构。
Kappa架构是真正意义上的流批一体的处理方式。它是随着流处理引擎的逐步完善后，由LinkedIn公司提出的一种实时数仓架构。
这种架构，相当于在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这种支持数据直接持久化到磁盘中的消息队列，可能是更好的选择，但相应的会牺牲数据实时性和吞吐量。
Kappa架构和Lambda架构，并没有优劣之分，只是适用场景不同而已。
下一期，我们来讲讲在流处理架构中，进行实时数仓的建模方案。如果喜欢，可以点赞、关注，我们在数舟再会！
往期推荐
扫描二维码
获取更多精彩
数 舟
