现代数据仓库架构演进：从 Kimball 到 Lakehouse 的范式迁移

一、数据仓库的本质是决策引擎

数据仓库与业务数据库的本质区别在于：业务数据库为"某用户今天的订单是什么"这种点查询优化，数据仓库为"华东区域过去三个月 A 类产品销售额的变化趋势"这种聚合分析优化。前者追求毫秒级响应和高并发，后者追求海量数据下的快速扫描和复杂 Join。

Kimball 的星型模型和 Inmon 的三范式建模是数据建模的两大流派。Kimball 的维度建模更贴近业务需求——事实表记录"发生了什么事"，维度表回答"谁、什么时候、在哪里"。一个良好的星型模型让数据分析师能用 SQL 直接回答 90% 的业务问题。

二、Lakehouse 架构的三板斧

一）数据湖和数据仓库的融合

过去十年数据架构经历了"数据仓库→数据湖→湖仓一体"的演进。DW 结构清晰查询快但只能处理结构化数据；Data Lake 通吃所有格式但变成了数据沼泽。Lakehouse 通过 Delta Lake 或 Iceberg 等表格格式给数据湖加上 ACID 事务支持，让数据湖获得了数据仓库的可靠性。

二）Delta Lake 的版本控制

Delta Lake 的时间旅行功能让数据仓库第一次有了版本管理能力——你可以查询三小时前甚至三天前的数据。这个能力在监管审计和事故恢复场景下价值连城。结合 Schema 强制和 Schema 演进，Delta Lake 解决了数据湖最让人头疼的数据格式混乱问题。

三、查询引擎选型

Presto/Trino 是联邦查询的首选——一个 SQL 可以同时查 MySQL、HDFS 和 Kafka。ClickHouse 在实时 OLAP 场景下全面碾压——单表百亿行数据秒级出结果。Doris 和 StarRocks 则是国产替代的后起之秀。选型的关键不是性能参数，而是你的团队能否独立运维这套系统。