实时数仓V1版本

下面滴滴打车实时数仓的架构v1版：

优势：相较于单个业务需求开发效率高，快速完成业务需求

不足：数据复用性差，相较于整个业务大盘来说开发效率低，资源浪费严重，可维护性差，口径变更需要多出修改，复杂的业务逻辑，需要在多个任务中去实现，尤其是实时去重复，实时维度关联等场景。

实时数仓V2版本

下面滴滴打车实时数仓的架构v2版：

优势：初步体现了数仓分层，数据实现了复用，整个业务单开发效率有明显提升，由于对数据实现了复用，整体计算资源也有了明显的下降30%+

不足：没有进行指标层面的沉淀，每个同学各自实现各自的字表，会出现指标口径不统一，并且还不容易维护，如果指标变动，同步不到位，还会带来口径差异，提供服务依赖于OLAP引擎

实时数仓V3版本

下面滴滴打车实时数仓的架构v3版：

优势：完成整体数据分层，包含明细数据和汇总数据，统一DWD层，降低资源浪费，提高数据服用行，完成指标口径沉淀，保证数据质量

A&Q-问题1

狗哥，复杂的业务逻辑在哪里处理

比如我们需要实时关联kv维度数据，实时去重复的逻辑等等

这个需要提前在DWD层进行收口，也就是充分利用flink的能力，进行提前预处理，参考《阿里菜鸟实时数仓》

A&Q-问题2

狗哥，为啥实时数仓的存储引擎都喜欢用OLAP做存储呀？我们选什么引擎比较好呢？

因为即可以做实时计算，又可以做实时数据分析，还可以方便查看历史明细数据，方便快速定位线上问题，并且机遇olap引擎，使用通用的sql语句，可以更高效的支持线上的业务，狗哥建议你使用doris，谁用谁知道，用完感觉好到爆哈哈。

A&Q-问题3

狗哥，为啥doris好呢？为啥不用clickhouse呢？

首先clickhouse很好，我相信它可以找到更好的使用方。doris实时多表本地join，实时shema变更，标准sql，算法，工程，bi取数据上手快，有些不紧急的需求，让他们写sql就行了，解放了劳动力。

A&Q-问题3

狗哥，有实时数仓ppt吗？

有，关注下方公众号，回复：实时数仓。如果你经常点外卖，记得关注我的《外卖助手奇奇》，每天都可以另取叠加外卖券。