0.dim层组件的选择

dim层存储要求：需要满足永久存储（需要长期保存历史数据）和支持根据主键查询单条数据明细，所以排除Kafka（时效短）；

候选框架：MySQL、Redis、Hive、Doris、HBase ？
（1）mysql：合适，但是大数据量要分库分表；
（2）Redis：内存成本高，千万级用户数据全部存储在内存不划算，而且利用率低，通常只有约10%的数据会被频繁访问；
（3）Hive：基于HDFS的随机读效率低，查询效率低，需要从大文件中按主键查找特定记录，属于随机IO操作；
（4）Doris： 列式存储，擅长列聚合查询，行查效率低，不适合单条明细查询场景；
（5）HBase ：

• List 行存模式（重点使用）: 使用单个列族时，所有列存储在一起，形成行存；
• 列存模式: 每个列使用独立列族时，形成类似列存的结构；

1.为什么没有做维度表的整合操作？

在实时数仓的维度层（dim层）设计中，选择不整合维度表（即采用雪花模型而非星型模型）

• 如果两张维度表需要整合（Join），任何一张表的更新都会触发重新计算。
• 每次Join都需要关联其他表的历史数据，导致​​状态必须长期保留​​，无法清理（TTL难以设置）。
• 状态数据的膨胀会显著增加​​存储压力​​、​​Checkpoint时长​​和​​故障恢复时间​​，甚至影响实时处理的稳定性。
• 示例：
  （1）假设有用户维度表（user_dim）和商品维度表（product_dim），若整合成一张大表，则每次用户信息或商品信息变更时，都需要重新Join并更新结果。
  （2）流处理引擎需要缓存两个表的全量历史数据，以支持任意时间点的Join操作，这对内存和磁盘是巨大挑战。

2.为什么不做拉链表？

（1）因为实时数仓本来就是支持实时更新、实时同步，一直保持的是全量最新；
（2）比如说如果我们需要用到用户维度的历史状态，我们可以到我们离线数仓dim层里面去查询，但基本上不会用到。