最近和一位传统大型企业的数据架构师深入交流，他抛出了一连串直击灵魂的问题：

“数据湖、湖仓一体不就是给数仓加了流式存储和非结构化支持吗？”

“MPP数据库（Greenplum、Doris）到底算RDBMS还是湖仓一体？”

“DWD层在湖仓一体里还有没有存在的必要？”

“海外大企业到底在用啥？”

这些问题看似基础，却恰恰是很多企业在数据平台选型时最容易踩的坑。今天我们就从头到尾把这些概念掰开揉碎，讲清楚本质区别，并给出落地的建议。

一、数据湖、湖仓一体与传统OLAP RDBMS的本质区别

l 数据湖：对象存储 + 分布式计算框架（Spark）+ 流处理引擎（Flink）

存储层：没有RDBMS。数据直接以文件形式放在对象存储里，格式可以是Parquet、ORC、JSON、CSV甚至视频文件。

计算层：用Spark或Flink来读取这些文件做处理。Spark擅长批量，Flink擅长流式。

l 湖仓一体：数据湖的存储（对象存储）+ 表格式层（Iceberg/Delta Lake/Hudi）+ SQL引擎（Trino/Spark SQL）

表格式层不是RDBMS，而是一套开放的文件组织规范，作用是在对象存储的文件之上模拟出“表”的行为。

l MPP架构的分析型RDBMS（如Greenplum、Doris）

这类产品本质上仍然是“数据仓库”这一大类，不是数据湖，也不是湖仓一体平台本身。它们的特点是：存储+计算一体，数据以私有格式存储在自己的节点上，外部无法直接读取。但它们可以通过外部表/外部数据源的方式对接数据湖和湖仓，扮演“查询引擎”的角色。

二、数据湖/湖仓一体是不是一种“退化”？

客观地说，如果只看纯结构化数据的SQL查询性能，湖仓一体确实像是“倒退”：

· 查询性能下降：同样的SQL，在Teradata上跑1秒，在Spark SQL/Trino上可能要10秒。因为湖仓一体的存储是廉价的分布式对象存储，没有本地缓存，也没有数仓那样的列存索引和物化视图优化。

· 运维复杂度增加：传统数仓是“交钥匙”系统，而湖仓一体需要维护对象存储、表格式（Iceberg/Hudi）、计算引擎（Spark/Trino）、元数据服务等多个组件，团队技能要求更高。

· 事务能力减弱：虽然Iceberg提供了ACID，但在高并发更新场景下远不如传统数仓的行级锁高效。

但这不是真正的退化，而是用一部分查询性能换取更大的灵活性、更低的成本和更广的数据覆盖范围。就像从专业赛车（Teradata）换成越野车（湖仓一体）：在赛道上赛车更快，但越野车能走烂路、拉更多货。

三、海外大型企业的真实选型：云数仓为主，湖仓一体为辅

海外大型传统企业的主力仍是“数仓范式”，已经从本地Teradata/Netezza大规模迁移到云上，Snowflake是最大赢家。这种迁移的本质是“传统数仓的云原生化”，而非转向开源湖仓。

湖仓一体（Databricks/Iceberg）在海外大企业中是重要补充，主要服务于数据科学和ML场景，并未取代云数仓的核心BI地位。大企业选Snowflake是为了降低TCO和获得敏捷性，不是为了省软件授权费；真正用免费开源MPP的主要是成本极度敏感或技术团队极强的公司（部分互联网公司、科技公司）。

四、技术架构在变，但DWD层和ER图的本质价值从未改变

因此，数据湖和湖仓一体技术架构的演进改变的是存储和计算的方式，但并未改变数据治理的本质需求。​ 回到DWD层（公共明细层）的建设、企业级数据模型（ER图）的设计与管控，在任何现代数据架构中——无论是传统数仓、云数仓还是湖仓一体——始终是决定成败的重中之重。这不是过时的教条，而是被无数次实践证明的真理。

1. DWD层是企业数据资产的“唯一真相”

· 解耦：DWD层将源系统的异构数据（不同业务系统、不同编码规则、不同粒度）转化为企业级统一明细模型。下游（DWS、ADS、BI、ML）不再依赖源系统的变化。

· 复用：一个精心设计的DWD层，可以被数百个下游应用共用，避免“烟囱式”开发——每个团队各自从源系统拉数据、各自清洗，造成数据冗余和不一致。

· 质量：DWD层是数据质量管控的核心阵地。脏数据在这里被拦截、清洗、标准化，下游才能信任数据。

2. ER图是DWD层的“骨架”

· 沟通语言：ER图（实体关系模型）是业务人员、数据工程师、分析师之间唯一通用的语言。没有ER图，大家各自理解“客户”“订单”的含义，必然产生歧义。

· 一致性保证：通过ER图定义的维度、事实、度量、关系，确保了全企业对同一业务概念的理解一致。例如，“活跃客户”的定义在DWD层统一后，所有报表才不会打架。

· 变更影响分析：当源系统或业务规则变化时，ER图帮助快速定位受影响的下游表和指标，降低变更风险。

3. 湖仓一体下，DWD层依然不可或缺

湖仓一体的Schema on Read特性允许数据以原始格式入湖，但这绝不意味着不需要DWD层。恰恰相反，如果没有DWD层的清洗和建模，数据湖很快就会退化为“数据沼泽”——每个人都在用自己的方式解读原始数据，无法形成企业级共识。

湖仓一体下的DWD层实现方式变了，但目标不变：

· 传统数仓：DWD层通过ETL写入数据库表，强约束。

· 湖仓一体：DWD层通过增量Merge写入Iceberg/Delta表，利用表格式的ACID和Schema演化能力，实现相同的标准化和一致性。

ER图仍然是设计DWD表的依据，只是物理实现变成了开放格式的Iceberg表。

4. 实时数仓下，DWD层同样是必需

即使追求毫秒级响应，DWD层依然是必需的。实时流处理（Flink）写入的明细数据，同样需要经过标准化、去重、维度关联后才能成为可靠的DWD层。ER图帮助定义流处理过程中的字段映射和业务规则。

五、现代实践中，ER图设计的演进

虽然核心思想不变，但现代数据架构对ER图的设计提出了更高的要求：

六、忽视DWD层和ER图的代价

许多企业在转向数据湖或湖仓一体时，误以为“灵活”意味着“不需要建模”，结果：

· 数据沼泽：每个团队各自从原始数据湖拉取数据，各自清洗，形成新的数据孤岛。

· 指标打架：同一个“销售额”，不同团队的计算口径不同（含税/不含税、退货扣除/不扣除），管理层无法信任数据。

· 开发效率低下：每次新需求都需要从原始数据重新清洗，重复劳动，上线周期长。

· 治理失控：没有统一的ER图，数据血缘混乱，出了问题不知道影响范围。

最终，这些企业不得不回头重建DWD层和ER模型，付出的代价远高于一开始就做好设计。

七、落地建议

1. 无论选什么技术栈，DWD层必须单独建设：把它当作企业最重要的数据资产来对待，投入足够的建模资源和治理力量。

2. ER图是DWD层的灵魂：坚持用ER图（或维度建模）指导设计，不要因为技术先进就放弃业务建模。

3. 拥抱现代工具辅助建模：使用Datablau DDM/SQLink等工具管理ER图和数据血缘。

4. 区分逻辑模型和物理实现：逻辑ER图保持稳定，物理表可以根据性能需求灵活调整（如合并宽表、拆分分区）。

5. 建立数据治理委员会，发布数据模型管控制度：确保ER图的变更经过评审，避免随意修改导致下游混乱。

结语

DWD层和ER模型，不是传统数仓的“遗产”，而是现代数据平台的“基石”。​ 无论技术如何演进，只要企业需要“可信的、一致的数据”，这两样东西就永远不会过时。