数据仓库、数据湖、湖仓一体，在数据架构里分别干什么？- 大数跨境

首页

数据仓库、数据湖、湖仓一体，在数据架构里分别干什么？

商业智能研究

2026-09-30

导读：很多人第一次看企业数据架构图，最容易被三个词绕晕：数据仓库、数据湖、湖仓一体。

很多人第一次看企业数据架构图，最容易被三个词绕晕：

数据仓库、数据湖、湖仓一体。

因为它们最后看起来都在“放数据”，所以很容易形成一个错误理解：

数据仓库是上一代架构，数据湖是升级版，湖仓一体又是更新一代。

但企业真正做数据建设时，三者并不是简单的前后替代关系。

它们出现，本质上是因为企业的数据问题在不断变化。

一开始，企业要解决的是：

不同业务系统里的结构化数据，怎么统一起来做经营分析？

后来数据越来越多，日志、埋点、图片、文件、IoT 数据也开始进入企业，又出现第二个问题：

大量暂时还不知道怎么建模的数据，应该放在哪里？

再往后，湖里一套、仓里一套，数据不断复制，治理和计算体系越来越复杂，于是才有了第三个问题：

能不能让湖和仓尽量共享一套数据底座？

所以理解这三个概念，不能只背定义，而要把它们放回整个数据架构里看。

在正式展开前，我整理了一份《数据仓库建设解决方案》。里面把企业数据建设中常见的数据架构、数据开发、集成治理等内容做了比较系统的整理。

尤其是刚开始接触 ODS、DWD、DWS、数据湖、实时数仓这些概念时，建议不要一个名词一个名词孤立地学，而是先建立“数据从哪里来—经过什么处理—存到哪里—最后服务谁”这条完整链路，再去理解每一层的职责。

需要自取：https://s.fanruan.com/xwgup

下面我们就沿着这条链路，把数据仓库、数据湖和湖仓一体一次讲清楚。

一、数据仓库：解决的不是“存数据”，而是“把数据变成可分析资产”

ERP 里有订单，CRM 里有客户，WMS 里有库存，财务系统里有凭证。

这些数据虽然都存在，但直接拿来分析通常会遇到几个问题：

字段结构不同、编码体系不同、统计时间不同、业务口径不同。

更重要的是，业务系统本身是为了完成交易设计的。

订单系统关心的是：

订单能不能创建、修改、付款、发货。

分析系统关心的却是：

销售额为什么下降？
哪些区域毛利异常？
哪些客户正在流失？

两者的数据组织方式完全不同。

所以数据仓库真正做的事情，是把交易数据重新组织成分析数据。

常见架构会形成：

源系统 → ODS → DWD → DWS → ADS

ODS 尽量保存接近源系统的数据；
DWD 按业务过程沉淀标准明细；
DWS 对高频分析主题进行汇总；
ADS 再服务具体报表、看板和分析应用。

这里最关键的其实不是“分了几层”，而是三个动作：

统一事实、统一维度、统一口径。

比如订单金额，到底按下单还是付款统计？
客户数量按账号、手机号还是企业主体去重？
收入是否含税？
退款发生以后历史销售额是否回冲？

只有这些规则稳定下来，数据才能真正成为可以长期复用的分析资产。

而在仓库前面，还存在一个非常容易被忽视的环节：

数据怎么稳定地进仓。

这也是 FineDataLink 5.0 在整条链路里的位置。

不同数据库、API、文件等来源的数据进入统一的数据开发流程后，可以继续完成字段映射、清洗转换、增量同步和任务调度，再持续写入 ODS、DWD 等目标层。

所以做数据仓库时，至少要同时设计两件事：

一套是模型体系，决定数据进入仓库以后怎么组织；

另一套是数据链路，决定上游数据能不能准确、及时、持续地到达这些模型。

很多企业数仓表建得很漂亮，真正上线以后却天天在补数，本质上就是只设计了“仓”，没有设计好“流”。

二、数据湖：先保留数据，再决定未来怎么加工

随着企业数字化越来越深入，数据开始变得越来越“不像表”。

服务器会产生日志；
APP 会产生埋点；
设备会持续上传传感器数据；
业务部门还会产生 JSON、图片、视频、文档等大量数据。

这时候传统“先建模型，再入仓”的方式会遇到一个问题：

很多数据在进入系统的时候，根本还不知道以后怎么用。

如果每一种数据都必须先设计好结构、字段和模型，建设成本会越来越高。

所以数据湖采用了另一种思路：

先把数据以更接近原始形态的方式保存下来，需要使用的时候再解析、加工和建模。

这就是数据湖最重要的特点。

它降低了数据进入统一平台的门槛。

所以可以简单理解：

数据仓库偏向：

Schema on Write——写入之前先明确结构。

数据湖更强调：

Schema on Read——使用的时候再根据需求解释结构。

但这并不意味着：

“数据湖就是把所有文件扔进去。”

恰恰相反。

一个缺少治理的数据湖，很容易迅速变成“数据沼泽”。

几年以后你会发现：
文件名没人看得懂；
同一份数据保存了五个版本；
字段没有说明；
责任人找不到；
更新频率不知道；
有没有下游使用也没人清楚。

所以数据湖真正的建设难点，后期往往不是存储，而是：

元数据、目录、权限、质量、血缘和生命周期。

湖解决了“数据先放哪里”的问题，但并没有取消治理。

数据越多，治理反而越重要。

三、湖仓一体：真正想解决的，是湖和仓之间的割裂

很多企业后来形成了一套典型结构：

原始数据先进入湖。

需要 BI、经营分析的数据，再从湖里加工一遍，进入数据仓库。

这套方式本身没有错。

真正的问题出现在规模越来越大以后。

一份订单数据可能：

业务库里一份；
数据湖里一份；
数仓里一份；
专题库里又一份。

数据科学团队维护一套处理逻辑，BI 团队又维护另一套。

慢慢就会出现一个非常现实的问题：

复制的数据越来越多，但企业并没有因此获得更多“信息”。

反而出现：

存储重复；
任务重复；
口径重复；
权限重复；
质量规则重复。

湖仓一体真正想减少的，就是这种重复。

它不是简单把“数据湖 + 数据仓库”写成一个新名字。

更核心的变化是：

在开放、低成本的数据存储之上，继续补齐表管理、事务能力、元数据、治理和查询优化，让同一份底层数据能够同时服务不同类型的计算。

换句话说：

以前的思路可能是：

不同场景，复制一份数据。

湖仓一体更希望做到：

同一份数据，不同计算方式按需读取。

这也会反过来改变数据集成层。

因为数据不再只是每天凌晨批量搬一次。

订单、库存、设备状态等数据可能需要持续更新，API 和文件又可能按照不同周期进入底座。

在这种链路里，FineDataLink 5.0 的实时管道、定时任务和数据转换可以分别衔接不同的数据时效要求：

稳定变化的数据持续同步，周期性数据按照调度进入目标端，需要加工的数据再完成清洗和转换。

因此湖仓统一以后，并不是“不需要 ETL 了”。

真正发生变化的是：

数据少搬一次，不代表数据不用流动。

湖仓解决的是底层存储和计算体系的统一，数据集成解决的仍然是来源、变化、加工和交付。

这两个层次不能混在一起。

四、真正放回架构图里，三者其实是三种建设路线

企业实际做架构设计时，很少是在三个名词里硬选一个。

更常见的是下面三种路线。

第一种：以数据仓库为核心

链路通常是：

业务系统 → 数据集成 → ODS → DWD → DWS → ADS → BI

这种架构对大量传统企业依然非常有效。

如果企业主要数据来自 ERP、CRM、供应链、财务等结构化系统，主要需求又是经营分析、管理报表、财务分析，那么成熟的数据仓库完全可以支撑大多数场景。

第二种：数据湖 + 数据仓库

数据量越来越大、类型越来越复杂以后，可以把原始数据先进入湖。

真正进入稳定分析的数据，再加工进入仓库。

于是：

湖负责广泛承接数据；

仓负责高质量分析。

很多企业其实长期都会处于这个阶段。

需要关注的并不是“为什么还没有湖仓一体”，而是：

湖和仓之间的数据复制、加工和治理成本是否已经不可接受。

第三种：湖仓一体

当企业同时存在 BI、实时分析、数据科学、AI 等大量数据消费场景以后，就开始希望不同工作负载共享更统一的数据底座。

这时候架构关注点从：

“我要再建一个什么系统”

逐渐变成：

一份数据怎样被多个计算场景复用。

而不管最终落到仓、湖还是湖仓，前面的数据来源永远不会自动变整齐。

ERP、CRM、SaaS、数据库、文件、接口依旧同时存在。

因此企业做架构设计时，往往还需要在这些存储体系之前建立统一的数据流动层。

通过 FineDataLink 5.0 把多源数据接入、同步、转换、调度和运行管理串起来以后，下游存储架构可以变化，但不必每新增一个目标端，就重新手搓一套采集程序。

这里其实体现了一个非常重要的架构原则：

存储层可以演进，数据链路不要反复推倒重来。

五、企业到底应该选哪个？不要先看技术名词，先看这四个问题

很多企业做架构选型，一上来就问：

“我们是不是应该上湖仓一体？”

这个问题其实问反了。

先回答下面四件事。

第一，你的数据到底是什么类型？

如果 80% 以上都是数据库里的结构化业务数据，核心需求也是财务、经营、销售分析，那么传统数据仓库往往已经足够。

如果日志、IoT、埋点、文件等数据越来越多，再去考虑湖。

第二，你的数据主要被谁使用？

如果主要是财务、管理层和业务分析人员，他们更关注的是：

指标稳定、响应速度、口径统一。

如果还有大量算法、数据科学、机器学习团队，他们往往更需要：

原始数据、灵活计算和大规模数据访问。

第三，一份数据被复制了多少次？

这是判断是否需要向湖仓方向演进的一个重要信号。

如果数据已经长期在：

源系统 → 湖 → 数仓 → 专题库 → 数据集市

之间层层复制，而且每份副本都需要维护口径、权限和质量规则，那么架构复杂度已经开始超过业务收益。

第四，团队有没有能力驾驭复杂度？

架构不是名词越多越先进。

如果公司数据量只有几百 GB，核心需求就是十几个经营报表，却一次性引入湖、仓、流批一体、多个计算引擎，最后可能只是把技术复杂度提前买回来了。

真正值得优先建设的，是一套清晰的数据链路。

这一层可以通过 FineDataLink 5.0 把“从哪里来、怎么同步、经过什么转换、流到哪里、多久执行一次、任务失败以后怎么恢复”逐步固化下来。

等这些基础问题稳定以后，再决定：

哪些数据进入仓；
哪些原始数据长期留在湖；
哪些场景值得进一步统一到湖仓底座。

这种顺序通常比一开始追求最新架构更稳。

六、最后记住：仓、湖、湖仓，本质上解决的是三个不同阶段的问题

如果一定要用最简单的话总结：

数据仓库解决的是：怎样把数据整理成稳定、可信、可重复使用的分析资产。
数据湖解决的是：怎样先承接大量、多类型、暂时还不知道怎么建模的数据。
湖仓一体解决的是：怎样减少湖和仓之间重复存储、重复加工、重复治理的问题。

它们背后其实对应着企业数据建设不断变化的三个阶段：

最开始担心的是：

数据不统一。

后来担心的是：

数据装不下、类型太复杂。

再后来担心的是：

数据存了太多份，整个架构越来越难维护。

所以判断一套数据架构是否先进，不应该看图上有没有“Data Lakehouse”。

真正值得看的，是下面几个问题：

数据能不能稳定进入平台？
关键口径是否一致？
一份数据有没有被无意义地复制很多遍？
上下游关系能不能追踪？
异常能不能快速定位？
新的业务需求来了，已有数据能不能直接复用？

这些问题解决得越好，数据架构才越成熟。

因为对企业来说，仓也好、湖也好、湖仓一体也好，最终都只是技术形态。

真正要建设的，是一套能够让数据持续流动、可靠沉淀、统一理解、反复复用的数据体系。

点击【阅读原文】，体验文中同款资料包

【声明】内容源于网络

商业智能研究

帆软旗下机构「帆软数据应用研究院」专注于企业数据化应用、大数据BI技术和理论观点研究，向业界输出前沿的研究与洞察，帮助企业把握商业智能趋势，提升管理与商业战略认知，让数据成为生产力。

内容 1140

粉丝 0

商业智能研究帆软旗下机构「帆软数据应用研究院」专注于企业数据化应用、大数据BI技术和理论观点研究，向业界输出前沿的研究与洞察，帮助企业把握商业智能趋势，提升管理与商业战略认知，让数据成为生产力。

总阅读16.7k

粉丝0

内容1.1k