本文介绍了实时数仓的架构设计，对比了Lambda和Kappa架构的优缺点。Lambda架构需要维护批处理和流处理两套计算引擎，而Kappa则主张全流式计算。目前多数大厂依然采用Lambda架构，但Flink在流批一体中受到关注。实时计算产品选型涉及数据源、通道、计算引擎和存储，如Kafka、Flink、Redis、Hbase等。文章列举了美团、字节跳动和有赞的实时数仓实践，强调选型应考虑具体需求和应用场景。
这是彭文华的第99篇原创
好几位朋友在后台留言，说要看看各大厂都是咋玩实时数仓的。其实，实时数仓和离线数仓在模型设计的时候是一样一样的，只是需要计算引擎和存储不太一样而已。然后再解决实时计算场景中的几个问题就齐了。今天给大家分享实时数仓的架构。
实时计算架构选型
目前实时架构方法是Lambda和Kappa。
1、Lambda 架构
Lambda架构核心就三个：批数据处理层、流数据处理层和服务层。批数据处理层应对历史长时间数据计算，流数据处理层应对短时间实时数据计算。如果一个需求要历史到当前所有数据的累加结果，那就在服务层将两部分数据进行累加就好了。
Lambda架构需要维护两套计算引擎，如果需要历史到现在实时数据的累加，则需要在两边同时做相同的计算，然后还得加总一下，非常麻烦。因此就有了最近非常火热的Kappa架构。
appa 架构
Kappa架构的设计很有意思。Lambda架构反正还是分离线和实时两部分的，所以可以从离线库和实时消息队列取数，分别计算后，在服务层加总就可以了。
Kappa的设计理念是：干脆不要离线了，全部都进行流式计算。流式计算的数据来源是消息队列，那我把所有需要计算的数据放在消息队列里就好了，然后让流计算引擎计算所有数据不就好了？
因为所有数据都存在Kafka，上面接Flin
最低0.47元/天 解锁文章
扫一扫
566
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
