湖仓结果全面对齐 Doris：这套电商数仓项目完成了一次关键收口

这套项目到底是干什么的

初次接触这个 data-warehouse-learning 项目，很多人可能会误以为它只是一个 SQL 代码库，或者某个特定引擎的练习场。其实不然。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

它的本质，是一套以电商业务为蓝本的、集学习与实战于一体的数据仓库体系。它并非只讲解某一层的建模理论，也不仅仅展示如何在单一引擎上运行任务，而是将数据生成、采集、分层建模、任务调度到最终可视化，串联成一条完整的、可闭环的数据链路。

更关键的是，这个项目采用了多线并行的设计思路。它既涵盖了基于 Doris 的传统离线数仓链路，也完整实现了基于 Flink 搭配 Paimon、Hudi 或 Iceberg 的湖仓一体架构。正因为它同时维护着多条技术实现路径，所以“湖仓链路产出的结果，能否与 Doris 这个基准真正对齐”才成为一个必须被厘清的核心问题。

为什么这次更新值得单独讲

架构总览

简单来说，这个项目致力于一件相当完整的事：构建一个围绕电商场景，既能用于学习理解，又能进行真实演练的数据仓库系统。

从架构上看，它至少包含了四个核心模块：

• 数据源与模拟层：通过 Ja va 程序模拟生成电商业务数据，将业务库数据写入 MySQL，日志类数据写入 Kafka。
• 数据采集层：利用 Flink SQL、Flink CDC、SeaTunnel 等工具，将数据接入不同的存储与计算链路。
• 数仓分层层：遵循 ODS、DIM、DWD、DWS、ADS 的标准分层模型，分别构建 Doris 路线和三条湖仓路线。
• 调度与展示层：通过任务编排和可视化工具，将上层计算出的指标和结果有效地组织与呈现出来。

也就是说，这个项目想解决的，远不止“某个 SQL 怎么写”的语法问题，而是“同一套电商业务逻辑与口径，能否在不同的技术栈实现下，稳定地交付出一致的结果”。

这正是本次更新最具价值的地方。

这不是一次小修补，而是一次全域口径审计

对于这样一个同时集成 Doris、Paimon、Hudi、Iceberg 多种组件的项目而言，最困难的部分从来不是让某条链路跑通。

真正的挑战在于：当面对不同引擎、不同的执行语义、不同的表格式实现时，最终交付到 DIM、DWD、DWS、ADS 各层的数据，是否还能坚守同一套结果标准。

换句话说，核心问题不是“湖仓这条线能不能算出数据”，而是“湖仓算出来的数据，最终能不能和 Doris 保持毫厘不差”。

本次更新的目标，正是攻克这个问题。重点不再是局部 SQL 的优化，而是将三条湖仓实现路径的结果，真正收口到与 Doris 基准完全一致的标准上。

范围盘点

从覆盖范围来看，这次工作绝非小打小闹的修补。它是一次系统性的“审计”，涉及：

• 3 套湖仓实现：Hudi、Paimon、Iceberg，一个不漏。
• 4 个核心分层：DIM、DWD、DWS、ADS，全线覆盖。
• 243 个 SQL：全部进入审计范围。
• 12 个本轮重点调整的业务 SQL：主要集中在 4 张关键的 DWD 表上，并且同步修正了三套湖仓的实现。

如果从分层视角看，这相当于完成了一次完整的数据仓库结果治理：

• DIM 层共 18 个 SQL
• DWD 层共 90 个 SQL
• DWS 层共 75 个 SQL
• ADS 层共 60 个 SQL

这意味着，这次更新的意义超越了“修了几张表”，而是将整套湖仓结果体系重新拉回到了一个可以与 Doris 统一对照、统一验证、统一交付的可信状态。

四层结果，已经从“可运行”走到“已收口”

四层结果矩阵

本次更新带来的最根本变化，是四个分层都跨越了“逻辑通顺”的阶段，进入了“结果一致”的稳定态。

• DIM 层：过去维度结构完整、结果可用，但缺乏明确的收口验证。现在，它已完成真实任务验证，三套湖仓实现结果一致。
• DWD 层：过去大量逻辑正确，但少数关键表存在运行时结果漂移的风险。现在，关键表的时间等口径已经稳定，三套湖仓实现结果与 Doris 完成收口。
• DWS 层：过去能够产出汇总结果，但尚不能直接证明最终一致性。现在，汇总层也完成了真实任务验证，可无缝纳入统一结果体系。
• ADS 层：过去业务指标已可计算，但未能完全证明与 Doris 的最终指标等价。现在，应用层同样通过真实验证，最终指标结果已与 Doris 一致。

这件事的价值在于，后续再审视湖仓部分的代码时，开发者无需再心存疑虑地问“这套实现和 Doris 到底差多少”，而是可以直接将其置于统一的、可信的结果基线中进行理解和评估。

关键变化，集中体现在 4 张 DWD 表上

关键 DWD 表前后对比

这轮结果收口工作，最直接、最显著的变化集中体现在 4 张关键的 DWD 宽表上：

• dwd_inventory_stock_full
• dwd_product_category_full
• dwd_product_spu_info_full
• dwd_user_address_full

这四张表的共性是，其业务逻辑本身并不复杂，真正的问题出在结果表达的层面，尤其是时间字段的语义、批处理任务的批次一致性，以及在跨引擎执行时的稳定性保障上。

更新之后，这 4 张表的状态已经从“运行时存在不确定性”转变为“具备批次确定性的稳定输出”：

• 库存表的时间字段不再受运行时环境扰动。
• 类目表的类目路径与时间结果保持同步稳定。
• SPU 表具备了可跨引擎统一的稳定批次口径。
• 用户地址表中 create_time 与 operate_time 两个时间字段也统一到了稳定的语义下。

简而言之，这次调整不是让 SQL 代码看起来更整洁，而是让最终产出的数据真正具备了可对齐、可比对、可复验的特性。

最终一致，不是推断出来的，而是跑出来的

验证闭环

本次更新遵循一个关键原则：不接受“理论上应该一致”，只认可“实际任务执行后结果一致”。

因此，验证方式并非静态地检查 SQL 结构，而是在 PowerShell 环境下进行了真实的任务执行与结果比对，并保留了完整的输出记录以供复核，具体包括：

• 明细数据行的逐条对比
• 结果行数的统计对比
• 分层数据的结果闭环验证
• 最终跨引擎与 Doris 结果的统一收口确认

结论非常明确：在将 243 个 SQL 全部纳入审计范围后，三条湖仓实现路径首先完成了内部结果的统一，进而与 Doris 基准完成了最终的结果收口。

这标志着项目已经从“多种实现并存”的阶段，迈入了“多种实现共用同一套结果标准”的新阶段。

相关代码已沉淀在项目仓库中

项目仓库入口

这轮统一工作并非停留在理论讨论，所有改动均已沉淀至项目仓库中。

对于希望继续深入研究分层实现、湖仓三套方案的组织方式，以及各层 SQL 具体结构的读者，可以直接访问 GitHub 仓库进行探索。

项目仓库地址：https://github.com/Mrkuhuo/data-warehouse-learning

从仓库结构中，可以清晰地看到本项目两个最具代表性的特点：

• Doris 与 Hudi、Paimon、Iceberg 三条实现路径并行存在。
• 多条实现路径最终严格落在同一套结果标准之上。

最后总结

如果用一句话来概括这次更新，那就是：这并非一次普通的“湖仓代码补丁”，而是标志着这套同时覆盖 Doris 与多种湖仓实现的电商数仓项目，在最终交付结果上，完成了一次真正意义上的统一收口。

在此之前，项目中的 Doris 更像是一个结果基准，而湖仓实现则更偏向于“可运行”的示例。现在，湖仓实现已经与 Doris 共同进入了一个统一、可信的结果体系。这对于项目后续的开发、验证和功能扩展而言，无疑是一个至关重要的转折点。

因为从此刻起，项目讨论的重点将发生转移：不再是谁的实现更接近正确，而是在统一的、高标准的结果基线之上，谁能够持续交付更稳定、更可复验的数据结果。