这是彭文华的第99篇原创
好几位朋友在后台留言，说要看看各大厂都是咋玩实时数仓的。其实，实时数仓和离线数仓在模型设计的时候是一样一样的，只是需要计算引擎和存储不太一样而已。然后再解决实时计算场景中的几个问题就齐了。今天给大家分享实时数仓的架构。
实时计算架构选型
目前实时架构方法是Lambda和Kappa。
1、Lambda 架构
Lambda架构核心就三个：批数据处理层、流数据处理层和服务层。批数据处理层应对历史长时间数据计算，流数据处理层应对短时间实时数据计算。如果一个需求要历史到当前所有数据的累加结果，那就在服务层将两部分数据进行累加就好了。
Lambda架构需要维护两套计算引擎，如果需要历史到现在实时数据的累加，则需要在两边同时做相同的计算，然后还得加总一下，非常麻烦。因此就有了最近非常火热的Kappa架构。
appa 架构
Kappa架构的设计很有意思。Lambda架构反正还是分离线和实时两部分的，所以可以从离线库和实时消息队列取数，分别计算后，在服务层加总就可以了。
Kappa的设计理念是：干脆不要离线了，全部都进行流式计算。流式计算的数据来源是消息队列，那我把所有需要计算的数据放在消息队列里就好了，然后让流计算引擎计算所有数据不就好了？
因为所有数据都存在Kafka，上面接Flink批流一体数据处理引擎将kafka的数据计算好存在服务层的table n中。如果需求有变化了，就讲kafka的offset调整一下，Flink则重启一个任务重新计算，存在table N+1中，当N+1的数据进度赶上table n了，就停掉table n的任务。
最后对比一下两种架构的优劣势：
没有最好的架构，只有最合适的架构。目前虽然流批一体的Kappa架构是最新最火的架构模式，但是绝大多数大厂现在仍然采用批流分离的Lambda架构。Lambda架构的问题不仅是要维护两套代码，更关键的是这两套代码跑出来的数据压根就不一致！误差率再少，乘以一个很大的基数，这差别就大了。我关注到微信公众号后台的实时数据和离线结果就不一样，应该就是用的Lambda架构。
不是因为技术能力不行，而是因为Kappa也有他的一些问题，在批处理上比较弱，数据回溯也比较费劲，所有应用场景有限。即便Kappa能解决这些问题，想要全面替换原有体系，也是需要时间和人力成本的。
所以即便是用了Flink，也都是作为Lambda架构中流式计算的一个分支，或者在特定场景中才使用流批一体。
实时计算产品选型
不管是Lambda还是kappa架构，实时计算都需要有数据源、数据通道、实时计算引擎和存储引擎这几个部分。
数据源基本都是各种日志，有些时候也需要读取一些离线存储的数据，比如各种维度信息等。
数据通道基本就是Kafka、RocketMQ等消息中间件。
实时计算引擎目前只有Storm、SparkStreaming和Flink。
存储就比较多了，分为类型也不一样，可以分为面向查询的各种存储、面向维度分析的OLAP、面向大型应用的数据湖。
所有的组件都已经给你梳理了一下，供各位参考：
这里重点说一下存储。如果算完之后直接接大屏等应用，建议用redis；如果要快速查询，建议接Hbase、ES等，如果还有后续操作，建议扔kafka里，如果要结构化落地，建议MySQL里。
如果要接OLAP，做多维分析，可以在OLAP里选，准实时多维用Impala、GP、Presto、Doris、kudu等都行，大宽表就用ES、CK、Druid。
如果要接后续大量应用，就用数据湖，目前基本就Hudi、IceBerg、Delta三种，字节用Hudi，腾讯在推IceBerg。
其实OLAP还有一个比较出名的Kylin，但是这玩意要预计算，实在不太适合实时数仓，所以就没列。
另外，超大厂还会自研一些组件，比如阿里的Hologres，滴滴的ddmq，美团的celler、mkafka等，这就不往里写了，没有参考意义。
各大厂实时数仓实践
美团外卖实时数仓选型及分层架构：
美团的这张图看起来很舒畅，数据源是各种log，通过消息队列（kafka、mafka）流向实时和准实时两条线，实时用Flink、Storm，最后扔到redis、durid、Hbase里面，准实时用Doris。详情可见附件。
字节跳动实时数仓选型及分层架构：
其实每个大厂都会尝试很多技术。比如字节就有批、微批和流式三种处理。字节的实时走的是Flink，整个架构采用Lambda。
有赞实时数仓选型及分层架构：
有赞用的是kafka+Storm/Flink+Druid/Redis/Hbase的架构，而且有赞的这篇文章详细的阐述了实时数仓的迭代过程，很有参考意义。
这里就不再多放了，至于实时数据湖，目前也没几个能用上的，我就直接忽略了。感兴趣的可以下载文档自己研究一下。
总结
实时数仓的建模逻辑跟普通数仓建模逻辑一样一样，该分领域分领域，该分主题分主题，该分几层分几层，该建款表建款表，该做多维做多维。
变化的是原有的数据落地变成不落地，所以要解决各种流式数据中会面临到的各种问题。
数据源我们没有太多的可选范围，基本上就是Kafka、RocketMQ等消息中间件；
计算引擎建议SparkStreaming或者Flink，相比前者，Storm不太友好。如果你公司现在就有Storm，可以参考58和字节，用Flink-Strom，做一些开发工作，直接兼容。
存储引擎就根据前端的应用来选择了，前面有介绍，我这里就不重复了。
最后，给大家总结了一下各大厂实时数仓的建设架构：
