离线和实时数仓技术架构梳理

1.离线数仓

离线数仓架构基本都是基于 Hive进行构建，数据分层方式如下：

• ODS
  Operational Data store，贴源层（原始数据层）

  从各个业务系统、数据库或消息队列采集的原始数据，只做简单处理，尽可能维持数据原貌

• DWD

  Data Warehouse Detail，数据明细层

  将贴源层的原始数据进行清洗补全后存入该层，数据粒度保持不变

• DIM
  Dimension，维度层

  根据数据的实际情况抽取不同的维度数据，比如 人员维度、产品维度

• DWS

  Data Warehouse Detail，数据服务层

  基于明细层和维度层的数据，按业务需要汇总成一个个的主题数据，供数据分析使用

• ADS

  Application Data Service，应用数据层

  根据业务需求形成了可供直接查询和使用的数据，可以存放在ES、HBase、Redis和MySQL等中

一个较为通用的离线数仓架构如下：

2.实时数仓

通过阅读多家业内头部公司的实时数仓建设方案，总结下来其核心都是 flink+kafka，对比离线数仓，其分层方式要简单一些。

这里也总结几个经典的技术选型案例：

1. Flink+Kafka+ClickHouse

这种架构方案其实是将数据源作为 ods层了，可以看作其实没有存真正完全未处理过的原始数据，对比离线数仓分层，也就少了一层。在 kafka中放 dwd和 dws的数据，使用 redis存放维度数据，再借助 flink实现不同层之间数据的抽取转换。另外，ads层用的 ClickHouse，也可以换成别的支持实时查询的存储，比如 Elasticsearch、Doris、StarRocks。

2. Flink+Kafka+HBase

   

   这种架构方式把 dws层给简化了，目的是缩短数据链条，增强分析结果的实时性。由于 kafka中存储了 ods的数据，对 kafka来说压力就比较大了，需要多注意 kafka集群的设计与后期维护了。另外，这里维度数据存放在 hbase中，适合维度数据较多的业务场景。

3. Flink+Kafka+Iceberg+Presto

这种架构方式对比前两种，变化就比较大了。首先，引入了数据湖的理念和技术。其次，弱化了 kafka的地位，ods、dwd、dws三层的数据全部存在 Iceberg中，由 flink来完成不同层数据之间的流动。最后，由 Presto使用 sql直接查询 Iceberg中的数据，数据链条被进一步缩短了，当然实时性更强了。