【附下载】实时数仓架构设计与选型

这是彭文华的第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，做一些开发工作，直接兼容。

存储引擎就根据前端的应用来选择了，前面有介绍，我这里就不重复了。

最后，给大家总结了一下各大厂实时数仓的建设架构：

还有东西都给您准备好了，后台回复“实时数仓”即可下载全部资料。

配合以下文章享受更佳

干货 | 什么才叫做懂业务？分析的5个层次

一口气系列 | 一口气说透中台

一口气系列 | 一口气说透数据中台

一口气系列 | 一口气说透大数据计算引擎

一口气系列 | 一口气讲完数据仓库建模方法

我需要你的点赞，爱你哟