离线和实时数仓技术架构梳理
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，对比离线数仓，其分层方式要简单一些。
这里也总结几个经典的技术选型案例：
- Flink+Kafka+ClickHouse
这种架构方案其实是将数据源作为 ods层了，可以看作其实没有存真正完全未处理过的原始数据，对比离线数仓分层，也就少了一层。在 kafka中放 dwd和 dws的数据，使用 redis存放维度数据，再借助 flink实现不同层之间数据的抽取转换。另外，ads层用的 ClickHouse，也可以换成别的支持实时查询的存储，比如 Elasticsearch、Doris、StarRocks。
-
Flink+Kafka+HBase
这种架构方式把 dws层给简化了，目的是缩短数据链条，增强分析结果的实时性。由于 kafka中存储了 ods的数据，对 kafka来说压力就比较大了，需要多注意 kafka集群的设计与后期维护了。另外，这里维度数据存放在 hbase中，适合维度数据较多的业务场景。
-
Flink+Kafka+Iceberg+Presto
这种架构方式对比前两种，变化就比较大了。首先，引入了数据湖的理念和技术。其次，弱化了 kafka的地位，ods、dwd、dws三层的数据全部存在 Iceberg中，由 flink来完成不同层数据之间的流动。最后，由 Presto使用 sql直接查询 Iceberg中的数据，数据链条被进一步缩短了，当然实时性更强了。