陶玉印的博客

为什么企业需要数据仓库？

发表于 2026-06-16

在和一些年轻的数据工程师交流时，我发现一个有趣的现象。

很多人每天都在开发ODS、DWD、DWS、ADS。

熟悉Hive、Spark、Flink、ClickHouse。

却很少认真思考过一个问题：

为什么企业需要数据仓库？

尤其是在AI快速发展的今天。

越来越多的人开始提出类似的问题：

有了湖仓一体，还需要数据仓库吗？
有了ChatBI，还需要数据仓库吗？
Agent能够自动生成SQL，还需要数据仓库吗？

在回答这些问题之前，我们需要先回到数据仓库诞生的那个时代。

因为只有理解它为什么出现，才能理解它为什么至今仍然存在。

企业最早并没有数据仓库

今天很多企业的数据架构看起来似乎理所当然：

1	ERP → 数据仓库 → BI → 报表

但实际上，大多数企业最初并没有数据仓库。

在信息化建设初期，企业通常只有几个核心业务系统：

ERP
财务系统
CRM
HR系统

当管理层需要数据时，往往直接从业务系统查询。

例如：

销售总监问：

“本月销售额是多少？”

技术人员登录ERP数据库。

执行一条SQL。

得到结果。

似乎没有任何问题。

因为那时：

数据量不大
系统数量不多
分析需求简单

业务系统同时承担：

交易处理
数据存储
数据分析

三种职责。

但随着企业规模扩大，问题开始逐渐暴露。

第一个问题：业务系统不是为分析而设计的

ERP最重要的任务是什么？

是保证订单能够正常流转。

CRM最重要的任务是什么？

是保证客户管理流程正常运行。

MES最重要的任务是什么？

是保证生产过程可控。

这些系统有一个共同特点：

它们都属于OLTP系统（联机事务处理系统）。

其核心目标是：

快速写入
快速更新
高并发事务

而数据分析恰恰相反。

分析系统更关注：

大量历史数据
多表关联计算
聚合统计分析

例如：

业务系统可能需要快速保存一笔订单。

而分析系统则希望统计：

过去三年各区域产品销售趋势。

这是两种完全不同的工作模式。

如果直接在ERP上执行复杂分析：

轻则查询缓慢。

重则影响业务运行。

因此：

业务系统适合处理交易，不适合处理分析。

这是数据仓库存在的第一个原因。

第二个问题：企业的数据是分散的

很多企业管理层都喜欢问这样的问题：

“哪个客户最赚钱？”

看起来很简单。

但实际计算往往涉及多个系统：

销售额来自CRM。

成本来自ERP。

回款来自财务系统。

物流费用来自供应链系统。

如果没有统一的数据平台。

每次分析都需要跨系统取数。

不仅效率低。

而且很容易出现口径不一致的问题。

例如：

销售部门说客户A贡献利润500万元。

财务部门说只有350万元。

双方都认为自己正确。

问题出在哪里？

不是数据错了。

而是计算逻辑不同。

企业真正需要的不是更多数据。

而是统一的数据语言。

这正是数据仓库解决的核心问题之一。

第三个问题：业务系统只关心现在

业务系统关注的是当前状态。

例如ERP中的库存表。

今天库存100件。

明天库存80件。

后天库存120件。

ERP只需要记录当前库存。

但管理层更关心：

库存变化趋势
历史库存水平
周转率变化

这些分析都需要历史数据。

而历史数据往往不会长期保存在业务系统中。

于是企业开始把业务数据持续同步出来。

形成历史快照。

构建分析主题。

这也是数据仓库的重要价值。

它不仅存储数据。

更保存企业经营过程中的历史记忆。

第四个问题：企业需要统一指标

很多企业都有一个经典现象。

开会时讨论同一个指标。

不同部门拿出不同数字。

例如：

“上个月销售额是多少？”

销售部门：

1.2亿元。

财务部门：

1.05亿元。

运营部门：

1.1亿元。

数据部门：

1.15亿元。

每个人都能解释自己的计算逻辑。

但最终没人知道哪个数字才是正确的。

问题本质上不是数据问题。

而是指标问题。

数据仓库建设过程中。

企业第一次开始系统化思考：

什么是销售额？
什么是利润？
什么是客户数？
什么是新增用户？

通过统一口径。

企业建立起共同的数据语言。

从某种意义上说：

数据仓库最大的价值不是存储数据，而是统一认知。

数据仓库真正解决了什么？

如果把前面的问题总结一下。

数据仓库解决的并不是简单的数据存储问题。

而是四个核心问题：

第一：

让业务系统专注交易处理。

第二：

打通企业数据孤岛。

第三：

沉淀历史数据资产。

第四：

统一企业指标体系。

因此。

数据仓库的本质不是一个数据库。

而是一套数据组织方法。

是一种让企业能够理解自身经营状况的基础设施。

AI时代，数据仓库为什么依然重要？

数据仓库最大的价值，其实是降低沟通成本

很多人认为数据仓库的价值在于技术。

我越来越觉得不是。

数据仓库最大的价值其实是：

降低组织沟通成本。

当企业拥有统一的数据口径时：

销售和财务不再争论数字。

业务和技术不再争论规则。

管理层不再争论结果。

大家能够把精力放在真正重要的问题上：

为什么会这样？

应该怎么办？

而不是：

数字到底哪个对？

从这个角度看。

数据仓库从来不是技术项目。

而是企业管理能力建设的一部分。

写在最后

过去二十年。

数据仓库之所以能够成为企业数据体系的核心。

并不是因为它拥有最先进的技术。

而是因为它解决了企业最本质的问题：

让企业能够用统一的语言理解自己的经营状况。

AI不会改变这一点。

ChatBI不会改变这一点。

Data Agent也不会改变这一点。

未来发生变化的。

只是数据被消费的方式。

而不会是数据被组织的逻辑。

下一篇文章，我们继续讨论另一个关键问题：

BI为什么成为企业数据消费的主流模式？

从报表到Agent：企业数据开发范式的二十年演进

发表于 2026-06-06 更新于 2026-06-08

过去二十年，企业数据领域发生过很多变化。

数据库、数据仓库、大数据平台、数据治理、BI、数据中台、湖仓一体、ChatBI、Data Agent……

新概念层出不穷，新技术不断涌现。

但如果站在更高的视角来看，这二十年的变化，本质上是在解决同一个问题：

如何更快、更准确地获得答案。

今天很多人在讨论AI、Agent、ChatBI。

有人说数据仓库会消失，有人说BI将被取代，还有人认为未来根本不需要数据开发工程师。

这些观点听起来很有冲击力，但如果不了解企业数据体系的发展历程，就很容易得出片面的结论。

因此，在讨论AI会带来什么变化之前，我们不妨先回顾一下企业数据开发范式过去二十年的演进历程。

第一阶段：数据库时代——直接从业务系统取数

大约在2000年前后，大多数企业的信息化建设刚刚起步。

企业中的核心系统主要是：

ERP
财务系统
进销存系统
人事系统

那时的数据分析需求并不复杂。

业务人员提出问题：

“这个月销售额是多少？”

技术人员登录数据库，写一条SQL。

很快就能得到结果。

那时的数据开发范式可以简单概括为：

1	业务系统 = 数据源 = 分析系统

所有分析工作直接基于业务数据库完成。

这种模式在企业规模较小时运行良好。

但随着企业发展，问题逐渐出现。

例如：

ERP关注交易处理
财务系统关注账务处理
CRM关注客户管理

每个系统的数据标准不同。

每个系统的数据口径不同。

每个系统都只关注自身业务。

当企业希望回答：

“某客户的销售额、利润和回款情况如何？”

就需要跨多个系统进行关联分析。

此时，数据库时代开始暴露出局限性。

企业需要一种新的数据组织方式。

数据仓库由此诞生。

第二阶段：数据仓库时代——让数据形成统一语言

从2005年前后开始，越来越多企业开始建设数据仓库。

数据仓库的核心思想并不复杂：

把分散在各业务系统中的数据统一汇集起来。

通过清洗、转换、整合。

形成统一的数据资产。

此时，企业数据架构开始演变为：

1	业务系统 → 数据集成 → 数据仓库 → 数据应用

对于很多企业而言，这是一次巨大的进步。

数据仓库解决了几个关键问题：

第一，统一数据口径。

同一个指标不再出现多个版本。

第二，沉淀历史数据。

业务系统可能只保留当前状态。

数据仓库可以保留完整历史轨迹。

第三，提高分析效率。

复杂分析不再直接访问业务数据库。

第四，实现跨系统分析。

企业第一次能够从全局视角看待经营数据。

也正是在这一时期，维度建模、星型模型、事实表、维度表等概念开始广泛普及。

很多企业的数据团队开始形成：

ETL开发工程师
数据仓库工程师
BI工程师

等专业岗位。

数据开发开始进入工程化时代。

第三阶段：BI时代——从数据到决策

如果说数据仓库解决的是“数据从哪里来”的问题。

那么BI解决的是：

“数据如何被使用”的问题。

从2010年以后，越来越多企业开始建设：

经营驾驶舱
管理看板
KPI体系
数据分析平台

FineBI、Tableau、Power BI等产品快速发展。

企业开始尝试用数据驱动决策。

此时的数据开发范式变成：

业务系统

↓

数据仓库

↓

OLAP

↓

BI

↓

决策分析

这也是很多企业今天仍然在采用的主流架构。

这一模式极大提升了企业的数据使用效率。

但与此同时，一个新的问题开始出现。

所有答案都需要提前准备。

业务提出需求。
数据团队开发ETL。
开发指标。
开发报表。
测试上线。

最终才能看到结果。

很多企业都经历过这样的场景：

业务部门提出一个分析需求。

排期两周。

开发一周。

测试三天。

上线一天。

最后花费近一个月时间。

而业务真正关心的问题，可能只需要一个答案。

问题并不在于技术。

而在于这种模式本质上属于：

先开发答案，再提出问题。

这也为下一轮变革埋下伏笔。

第四阶段：AI时代——从开发答案到生成答案

2022年以后，大模型开始快速发展。

ChatGPT、Claude、DeepSeek等产品让自然语言交互成为现实。

与此同时，企业数据领域也开始出现新的变化。

ChatBI开始流行。

智能问数开始普及。

企业知识库快速增长。

Data Agent不断涌现。

过去的数据分析过程通常是：

提出问题

↓

提交需求

↓

开发模型

↓

开发报表

↓

获得答案

而今天越来越多企业开始尝试：

提出问题

↓

Agent理解问题

↓

自动检索数据

↓

自动生成SQL

↓

自动分析

↓

获得答案

两种模式最大的区别在于：

过去是开发答案。

现在是生成答案。

这是企业数据开发范式过去二十年来最重要的一次变化。

AI会取代数据仓库吗？

这是最近两年被问得最多的问题之一。

我的观点很明确：

不会，至少在可预见的未来不会。

因为AI解决的是答案生成问题，而数据仓库解决的是数据组织问题。两者并不是替代关系。

Agent越强，越依赖高质量的数据基础。

ChatBI越智能，越需要统一的数据口径。

企业知识库越丰富，越需要高质量的数据治理。

未来消失的不会是数据仓库，而是数据仓库作为最终消费终端的角色。

它会逐渐退居幕后，成为Agent的数据底座。

下一代企业数据体系正在形成

回顾过去二十年。

企业数据体系经历了四次重要演进：

数据库时代：

解决数据存储问题。

数据仓库时代：

解决数据整合问题。

BI时代：

解决数据消费问题。

AI时代：

解决答案生成问题。

每一次演进，都不是推翻上一代体系。

而是在上一代基础上的能力扩展。

因此，我并不认为AI会终结企业数据体系。

AI正在推动企业数据体系进入一个新的阶段。

未来五年。

真正值得关注的问题不是：

“数据仓库会不会消失？”

而是：

“企业如何构建能够支撑Agent的数据体系？”

这也是本专栏接下来希望持续探讨的话题。

下一篇，我们将从一个最基础的问题开始：

为什么企业需要数据仓库？

从报表到数据资产：企业数据能力的演进路径

发表于 2026-06-02 更新于 2026-06-01

这些年，无论是数字化转型、智能制造，还是人工智能，几乎都绕不开一个关键词：

数据。

很多企业也确实投入了大量资源：

上ERP
建MES
做数据仓库
上BI平台
搭数据中台

但如果认真观察会发现，不同企业的数据建设效果差异非常大。

有的企业：

报表越来越多
数据越来越全
但业务依然靠经验决策

而有的企业：

数据已经成为经营管理的重要组成部分
甚至开始驱动业务创新

同样是数据建设，为什么会出现如此大的差异？

因为企业之间最大的区别，往往不是技术水平，而是：

数据能力所处的发展阶段不同。

数据治理的本质，不是建设几个系统，也不是做几个项目。

从更长周期来看，它实际上是在推动企业完成一次能力升级：

从报表驱动，走向数据驱动；从数据资源，走向数据资产。

一、企业数据能力的发展，往往会经历四个阶段

过去十多年，我参与过互联网企业的数据平台建设，也参与过制造业数据仓库和数据治理项目。

回头来看，大多数企业的数据能力演进路径其实非常相似。

大致可以分为四个阶段。

第一阶段：报表时代

这是绝大多数企业数字化建设的起点。

企业建设ERP、财务系统、进销存系统之后，最直接的需求就是：

我要看报表。

于是开始建设：

日报
周报
月报
经营分析报表

这个阶段最大的特点是：

数据用于展示结果。

例如：

本月销售额是多少
本月生产多少产品
库存还有多少

企业开始拥有数据，但数据主要承担的是：

统计和汇报功能。

这个阶段的典型问题

每个部门都有自己的报表：

财务有财务报表
销售有销售报表
生产有生产报表

结果经常出现：

同一个指标，不同部门算出来的结果不一样。

于是管理层开始产生疑问：

到底哪个数据是真的？

这时候企业会发现：

问题已经不是没有数据，而是数据不一致。

于是进入第二阶段。

第二阶段：数据整合时代

为了统一数据，企业开始建设：

数据仓库
数据平台
BI系统

通过整合ERP、MES、CRM等系统数据：

形成统一的数据出口。

这一阶段解决的是：

数据集中问题。

企业开始拥有：

统一指标
统一报表
统一分析平台

相比第一阶段，这是一次巨大进步。

但新的问题出现了

很多企业走到这里后会发现：

虽然数据统一了，但业务依然不完全信任数据。

原因很简单：

客户编码不统一
物料编码不统一
指标口径不统一

于是：

数据仓库建好了，但数据治理的问题开始暴露出来。

企业进入第三阶段。

第三阶段：数据治理时代

这个阶段，企业开始意识到：

数据问题不是技术问题，而是管理问题。

开始关注：

数据标准
数据质量
主数据管理
元数据管理
数据责任体系

企业不再仅仅关注：

数据怎么存。

而开始关注：

数据是否可信。

这是一个重要转折点。

在这个阶段

企业逐步建立：

Data Owner
Data Steward
数据治理委员会

建立：

数据标准体系
数据质量机制
主数据管理体系

经过一段时间后，企业内部会出现一个明显变化：

大家开始逐步相信同一套数据。

这其实是数据治理最大的价值之一。

因为：

信任，才是数据价值释放的前提。

第四阶段：数据资产时代

这是很多企业努力的方向，也是数据治理真正想达到的目标。

什么叫数据资产？

简单来说：

数据能够持续创造价值，并且被企业主动运营。

这时候数据已经不仅仅是：

报表来源
分析依据

而成为企业的重要生产要素。

数据开始支撑经营

例如：

销售预测
库存优化
采购计划
生产排程
渠道管理
客户运营

数据开始驱动决策

管理层讨论问题时：

不再是：

“我觉得……”

而是：

“数据告诉我们……”

数据开始创造新的价值

例如：

数据产品
数据服务
数据运营
AI应用

尤其在人工智能时代。

企业会越来越深刻地认识到：

AI的上限，很大程度取决于数据的质量和治理水平。

二、为什么很多企业始终停留在“报表阶段”？

这是一个值得思考的问题。

很多企业投入了大量资金：

买系统
建平台
招团队

但几年之后：

依然停留在做报表。

原因往往不是技术。

而是缺少三个关键能力。

第一：统一标准

没有统一标准：

指标无法统一
数据无法复用
资产无法沉淀

第二：治理机制

没有治理机制：

数据质量无法持续改善
主数据无法长期维护

第三：业务参与

数据治理从来不是IT部门的事情。

真正的数据资产：

一定是业务和技术共同建设的结果。

三、制造业企业的数据资产化，更应该关注什么？

结合大量制造业实践，我认为有三个优先方向。

优先做好主数据

重点包括：

物料
客户
供应商

这是所有分析和决策的基础。

优先做好核心指标

重点包括：

收入
库存
订单
产量
交付

不要一开始追求几千个指标。

先把最关键的几十个指标做好。

优先做好治理闭环

重点：

发现问题
解决问题
防止重复发生

形成持续改进机制。

四、AI时代，数据治理正在被重新定义

过去很多企业认为：

数据治理是成本。

今天越来越多企业开始意识到：

数据治理是能力建设。

尤其随着生成式AI的发展。

企业逐渐发现：

如果：

数据标准不统一
主数据混乱
数据质量不稳定

那么：

企业知识库效果差
AI问答不可信
智能分析结果不准确

换句话说：

AI不是替代数据治理，而是在倒逼企业重视数据治理。

未来企业之间的竞争，很可能不只是：

谁拥有AI

而是：

谁拥有更高质量的数据资产。

五、写在最后

回顾整个系列，我们讨论了：

为什么数据治理项目会失败
制造业数据治理难在哪
ERP与MES如何打通
数据仓库为什么建而不用
数据质量如何持续改善
什么是真正的数据治理体系
数据标准为什么是起点
主数据管理到底要不要做
数据治理组织如何设计

最终，其实都在回答同一个问题：

企业为什么要做数据治理？

我的答案是：

数据治理从来不是为了治理而治理。

它真正的意义在于：

让企业的数据，从记录业务，走向支撑业务；从支撑业务，走向驱动业务；最终成为企业持续创造价值的数据资产。

而这，或许才是数据治理最值得投入的地方。

系列结语

如果把企业数据建设比作盖房子：

数据平台是钢筋水泥
数据仓库是主体结构
数据标准是设计图纸
数据治理是施工管理
数据资产则是最终建成并持续创造价值的大厦

很多企业已经拥有了砖瓦。

接下来更重要的，是把这些砖瓦真正组织起来，形成能够长期支撑企业发展的数据能力体系。

因为未来企业的竞争，不仅是产品的竞争、效率的竞争，更是数据能力的竞争。

而数据治理，正是这场竞争的起点。

数据治理组织，应该怎么设计？

发表于 2026-05-26

很多企业在推进数据治理时，前期往往会投入大量精力在：

数据平台
数据仓库
BI系统
数据质量工具

这些都很重要。

但真正做一段时间后，很多团队会慢慢发现：

技术问题其实没那么难，真正难的是:事情到底谁来推动？问题到底谁来负责？

你会看到很多熟悉的场景：

数据有问题，但没人认领
规则定了，但没人执行
报表对不上，部门之间互相解释
数据治理开会很热闹，落地却很慢

最后项目进入一种状态：

“大家都知道重要，但就是推进不动。”

而这背后，真正缺少的，往往不是技术，而是：

数据治理组织机制。

一、很多企业的数据治理，为什么越做越累？

因为它通常是这样开始的：

第一阶段：IT部门发起

企业想做数字化，于是：

建数仓
做BI
做指标

数据治理也顺理成章交给IT团队。

刚开始问题不大。

但随着推进深入，很快会发现：

IT能处理“数据”，却很难决定“业务”

例如：

什么是营收收入？
哪个库存口径用于经营分析？
客户怎么分类？

这些问题，本质上都是：

业务规则问题。

IT可以实现，但不能替业务拍板。

于是项目慢慢进入一种尴尬状态：

IT在推进
业务在观望
管理层偶尔关注
但没人真正“负责治理”

最后：

数据治理变成了一项“长期协调工作”。

二、为什么说“数据治理本质是组织问题”？

因为数据天然具有一个特点：

它是“跨部门”的。

例如：

一个订单，会经过：

销售
财务
生产
仓储
供应链

每个部门：

都会产生数据
都会使用数据
也都会定义数据

于是问题就来了：

谁说了算？

如果没有组织机制，最后通常会变成：

各自维护自己的口径
各自相信自己的数据

最终：

企业内部形成多个“数据世界”。

三、数据治理组织，到底在解决什么？

很多人会把“数据治理组织”理解成：

成立一个数据治理部门。

但真正核心的，其实不是“部门”，而是：

责任机制。

它要解决的是：

1️⃣ 谁定义数据？

例如：

收入口径谁定？
客户分类谁定？
物料编码规则谁定？

2️⃣ 谁维护数据？

例如：

数据错误谁修复？
主数据谁审核？
指标变更谁管理？

3️⃣ 谁对结果负责？

例如：

报表不一致怎么办？
数据质量下降怎么办？

👉 如果这些问题没有明确答案：

那么数据治理一定会越来越难推进。

四、一个比较实用的数据治理组织模型

很多企业一听“组织建设”，容易想到：

大规模组织调整
新成立部门
复杂管理体系

其实未必需要。

对于大部分企业，更现实的方法是：

在现有组织上，建立“数据治理责任体系”。

这里分享一个比较通用、也比较容易落地的模型。

五、三个核心角色（非常关键）

1️⃣ Data Owner（数据Owner）

这是整个治理体系里最核心的角色。

通常由：

业务负责人
部门负责人

担任。

例如：

销售数据 → 销售负责人
库存数据 → 仓储负责人

Owner负责什么？

核心只有一句话：

对数据结果负责。

包括：

数据定义
指标口径
数据准确性

👉 注意：

Owner一定是业务角色，而不是IT。

因为：

业务最懂业务数据。

2️⃣ Data Steward（数据管理员/数据管家）

这个角色更偏执行与运营。

通常来自：

业务骨干
数据团队
信息化团队

Steward负责什么？

例如：

数据维护
规则执行
数据问题跟踪
数据质量监控

如果说Owner负责“方向”，那么Steward负责：

“日常运行”。

3️⃣ 数据治理委员会（很多企业忽略）

这是跨部门协调的关键。

因为很多问题：

不是某一个部门能决定的
而是涉及多个业务口径

例如：

收入口径
订单定义
库存规则

这些问题，必须有：

企业级协调机制。

委员会不需要天天开会

但需要具备几个能力：

标准审批
冲突协调
优先级决策
重大问题推动

六、一个特别容易被忽略的问题

很多企业会任命：

数据负责人
数据管理员

但最后发现：

角色有了，事情还是推进不动。

为什么？

因为：

“责任”没有真正进入业务流程。

举个典型例子：

如果：

数据质量问题
不影响绩效
不影响业务流程
不影响结果考核

那么再强调“重要”，也很难长期执行。

所以数据治理组织真正有效，往往需要：

数据责任“进入管理体系”

例如：

数据质量纳入部门考核
核心指标必须统一口径
主数据变更必须审批

👉 当数据开始影响业务运行时，治理才会真正发生。

七、很多企业治理推进不下去，其实是“节奏错了”

还有一种常见问题：

一开始就想搭建“大而全”的治理体系。

结果：

会议越来越多
规则越来越复杂
业务越来越疲惫

最后：

大家逐渐失去耐心。

更合理的方式通常是：

1️⃣ 先明确关键领域

例如：

销售
库存
生产

不要一开始覆盖全公司。

2️⃣ 先解决关键问题

例如：

指标不一致
主数据混乱
数据质量问题

先做出“可见效果”。

3️⃣ 用结果建立信任

这是非常重要的一步。

当业务看到：

数据开始可信
报表开始统一
协同效率提升

治理体系才会真正获得支持。

八、一个很现实的理解

很多企业会认为：

数据治理是“IT升级”。

但真正成熟之后会发现：

数据治理其实是“管理升级”。

因为它最终改变的是：

企业内部协同方式
数据责任机制
决策运行模式

九、写在最后

很多数据治理项目，最后真正拉开差距的，并不完全是：

技术平台
工具能力
系统架构

而是：

在上面的基础之上，有没有形成一套真正能持续运行的组织机制。

因为：

技术可以快速建设，
但“组织共识”和“责任体系”，才决定数据治理能走多远。

主数据管理（MDM），做还是不做

发表于 2026-05-20 更新于 2026-05-19

在数据治理领域，“MDM（主数据管理）”一直是一个很有意思的话题。

一方面，很多企业一提数据治理，就会想到MDM；
另一方面，也有不少企业在做过之后，留下了一句评价：

“投入很大，但效果并没有想象中明显。”

于是问题就来了：

主数据管理，到底有没有必要做？
什么企业适合做？
又为什么很多MDM项目最后做得很“痛苦”？

这篇文章，我们不讲概念堆砌，而是站在企业真实落地的角度，聊聊MDM这件事。

一、很多企业，其实已经“被主数据问题困扰很久了”

只不过，他们未必意识到：

这些问题，本质上是“主数据问题”。

来看几个制造业里非常常见的场景。

场景1：同一个物料，不同的系统里有多个名字

ERP里叫：

“一次性无菌导管”

MES里可能叫：

“无菌导管”

仓库系统里又叫：

“导管A型”

结果：

库存统计对不上
采购分析混乱
BI报表无法统一

最后只能靠人工“猜”。

场景2：同一个物料，同一个系统里有多个

这种情况属于物料编码在进行 MDM 管理，不过后续操作层面存在问题。

比如物料编码最初由 ERP 同步过来，所以

物料编码在 ERP 是唯一
初始化同步到SRM时也是唯一
但是 SRM 又生成了自己系统的唯一ID，SRM 内部关联使用的是本身系统的唯一ID

后续物料规格有调整，SRM 采用的是新增数据行的方式，导致

ERP 的唯一物料编码在 SRM 系统不唯一了。

这种情况在企业内部还比较常见。

场景3：客户重复、分裂

CRM有一套客户；
ERP有一套客户；
财务系统还有一套客户。

甚至：

同一个客户有多个编码
名称还不完全一致

例如：

“XX医疗科技有限公司”
“XX医疗”
“XX医疗科技有限公司(河北)”

系统看起来是三个客户，但业务知道：

其实是同一家。

场景3：供应商无法统一分析

采购部门想分析：

某供应商全年采购额。

结果发现：

不同系统编码不同
历史数据不一致
公司名称变化过

最后：

根本无法准确汇总。

这些问题，看起来像：

系统问题
数据问题
历史问题

但如果抽象一下，你会发现它们有一个共同点：

同一个“核心业务对象”，在企业内部没有统一身份。

而这，就是MDM要解决的问题。

二、那什么是“主数据”？

很多人第一次接触MDM，会觉得概念有点抽象。

其实可以简单理解：

主数据，就是企业里“被反复使用、跨系统共享”的核心业务对象。

例如：

物料
客户
供应商
组织
员工

这些数据有几个共同特点：

1️⃣ 使用范围广

不仅一个系统使用，而是：

ERP在用
MES在用
SRM也在用

2️⃣ 生命周期长

不像订单、库存这种“交易数据”会不断变化。

主数据通常长期存在。

例如：

一个物料可能使用几年
一个客户可能合作十几年

3️⃣ 一旦混乱，影响会被不断放大

这点非常关键。

如果一个物料编码错了：

采购会错
库存会错
生产会错
分析也会错

👉 主数据问题，会“传染”。

三、为什么很多企业“越数字化，主数据越乱”？

这是个很现实的问题。

理论上：

系统越多，数据应该越规范。

但现实往往相反：

系统越多，主数据越混乱。

为什么？

因为很多企业的信息化建设，是“分阶段成长”的。

第一年，上ERP
第二年，上MES
第三年，上CRM
后面又上：

WMS
SRM
BI

每套系统：

厂商不同
设计不同
编码规则不同

早期可能还能靠人工维持。

但随着系统越来越多，就会逐渐出现：

“同一个东西，在不同系统里长得完全不一样。”

四、那MDM到底在做什么？

很多人以为：

MDM = 做一个主数据系统

其实这只是表象。

MDM真正做的事情是：

1️⃣ 建立统一的数据身份

例如：

一个客户，全公司只有一个主身份
一个物料，全系统只有一个标准编码

2️⃣ 建立统一标准

包括：

命名规则
分类规则
编码规则

3️⃣ 建立数据同步机制

让各业务系统：

使用同一套主数据
保持一致更新

4️⃣ 建立管理机制

包括：

谁创建？
谁审核？
谁变更？

👉 这其实已经不只是技术问题，而是：

企业管理问题。

五、很多MDM项目为什么失败？

这是最值得聊的一部分。

因为很多企业不是没做MDM，而是：

做完之后，发现很难真正运行下去。

常见原因有几个。

1️⃣ 一上来就“全量建设”

一开始就想统一：

所有物料
所有客户
所有供应商
所有组织

结果：

周期特别长
协调成本巨大
业务逐渐失去耐心

最后项目变成：

“一直在建设，但始终没上线。”

2️⃣ 过于技术化

很多MDM项目：

重点在系统
重点在平台
重点在同步接口

但真正困难的是：

业务规则统一。

比如：

客户到底怎么分类？
物料编码谁说了算？

这些问题，不是技术能决定的。

3️⃣ 没有业务推动

如果业务部门认为：

“这是IT项目”

那么MDM大概率很难成功。

因为主数据本身就是：

业务数据。

最终一定需要：

采购参与
生产参与
销售参与

4️⃣ 想一步做到“绝对统一”

这是很多企业容易陷入的理想化状态。

现实里：

历史数据一定有问题
不同系统一定存在差异
一次性完全统一几乎不可能

所以：

MDM不是“世界瞬间完美”，而是“逐步减少混乱”。

六、那企业到底要不要做MDM？

我的观点其实很明确：

大部分制造企业，最终都需要做MDM。

尤其是：

系统越来越多
数据分析越来越深入
想真正做经营决策

因为没有统一主数据，后面会越来越痛苦：

数据越来越难对
系统越来越难集成
报表越来越难统一

但这里有个关键前提：

不要把MDM理解成“大系统项目”。

很多时候，更合理的做法是：

从“小而关键”开始。

七、一个更现实的MDM落地路径

这是我更推荐的一种方式。

第一步：先统一最关键的主数据

优先级通常是：

物料
客户
供应商

第二步：先建立“标准”，再谈“平台”

很多企业顺序反了。

其实应该先明确：

编码规则
命名规则
分类规则

然后再考虑系统实现。

第三步：建立映射关系（非常重要）

现实里，不可能一下完全替换历史数据。

所以很多时候需要：

“主数据映射层”

例如：

ERP编码 → 标准编码
MES编码 → 标准编码

这一步非常实用。

第四步：逐步治理，而不是一次革命

真正成熟的MDM，往往是：

一边运行
一边优化
一边统一

而不是：

停下来重建整个世界。

八、一个很重要的理解

很多企业把MDM理解成：

“数据治理高级阶段”

但其实：

MDM本质上是在解决企业“语言不统一”的问题。

它统一的不是数据本身，而是：

企业对业务对象的认知
企业内部的业务语言
企业跨系统的协同方式

九、写在最后

如果你的企业已经出现：

多系统数据难以统一
指标反复对不上
主数据大量重复混乱

那么很可能说明：

你已经到了必须认真面对MDM的时候。

但也不必把它想得太重。

因为真正有效的MDM，从来不是：

“一套宏大的系统工程”

而是：

从一个关键对象开始，逐步建立统一与秩序。

数据标准，为什么是数据治理的起点？

发表于 2026-05-11

很多企业在做数据治理时，最先关注的往往是：

数据仓库
BI报表
数据平台
数据质量工具

但真正做一段时间后，几乎都会碰到同一个问题：

为什么系统越来越多，数据反而越来越乱？

有时候甚至会出现一种情况：

两张报表的数据都没错
但结果就是对不上

继续往下追，最后发现：

原来大家说的根本不是同一个东西。

而这背后真正缺失的，往往就是：

数据标准。

一、很多企业的数据问题，本质是“标准问题”

举几个非常常见的场景：

场景1：什么叫“订单”？

销售部门认为：

客户下单就算订单。

财务部门认为：

完成审核才算订单。

生产部门认为：

下发生产计划才算订单。

结果：

同样是“订单数”，三个部门三种结果。

场景2：什么叫“库存”？

仓库看的是：

实物库存。

财务看的是：

可结算库存。

生产看的是：

可领用库存。

最后：

数据都是真的
但口径完全不同

场景3：组织架构不统一

人力系统一套组织编码；
ERP另一套；
财务系统可能还有第三套。

于是你会发现：

同一个部门，在不同系统里是“不同的组织”。

这些问题表面看是：

系统问题
数据问题

但本质上，其实是：

没有统一的数据标准。

二、什么是“数据标准”？

很多人会把“数据标准”理解成：

字段命名规范
表结构规范
技术文档

这些当然属于标准的一部分，但还不够。

真正的数据标准，核心解决的是：

同一个数据，在全公司范围内“怎么理解、怎么算、怎么使用”。

它至少包括几个层面：

1️⃣ 业务标准

例如：

什么是订单？
什么是收入？
什么是有效的组织？

👉 这是最核心的一层。

2️⃣ 指标标准

例如：

收入怎么算？
库存周转率怎么算？
产能利用率怎么算？

👉 保证报表之间一致。

3️⃣ 主数据标准

例如：

物料编码规则
组织编码规则
供应商编码规则

👉 保证系统之间一致。

4️⃣ 技术标准

例如：

字段命名
数据类型
接口规范

👉 保证技术实现统一。

三、为什么说“数据标准”是治理起点？

因为数据治理后面所有工作，都建立在“统一标准”之上。

没有标准，数据仓库会越来越乱

不同系统：

名称不同
含义不同
口径不同

你只能不断做：

转换
映射
特殊处理

最终数据模型会越来越复杂。

没有标准，数据质量无法真正做好

你会发现：

连“什么叫正确”都不清楚。

例如：

什么叫异常订单？
什么叫有效库存？

没有标准，就没有判断依据。

没有标准，BI一定会“打架”

很多企业都有这种场景：

财务报表一个数
经营分析另一个数
业务部门还有第三个数

大家都觉得自己是对的。

其实问题不是谁错了，而是：

大家用的不是同一套标准。

四、为什么很多企业“标准做不下去”？

这也是一个很现实的问题。

很多企业其实不是没做过数据标准，而是：

做完之后，没人用。

常见原因包括：

1️⃣ 只停留在文档层面

做了一套：

Excel
Word
标准手册

然后放进共享目录。

几个月后，没人再打开。

2️⃣ 业务没有参与

很多标准是IT自己定义的。

结果：

业务不认可
实际流程不适配

最后只能“形式存在”。

3️⃣ 标准和系统脱节

文档是一套；
系统实现又是另一套。

最终：

标准只是“参考资料”。

五、那数据标准应该怎么做？

这里不讲“大而全”，讲几个真正能落地的方法。

1️⃣ 先统一“关键指标”

不要一上来做几千个字段标准。

建议优先统一：

收入
订单
库存
销量

这些真正影响经营的数据。

2️⃣ 先解决“争议最大”的问题

因为这些问题：

最容易引发冲突
最影响业务信任

例如：

到底什么叫“有效订单”？
到底哪个库存口径用于经营分析？

3️⃣ 标准必须“进入系统”

这是关键。

真正有效的标准，不应该只存在于文档里，而应该：

进入数据模型
进入接口规则
进入报表逻辑

👉 只有系统真正执行，标准才算落地。

4️⃣ 建立“标准变更机制”

业务一定会变化。

所以标准不能：

一次制定，永久不变。

而应该有：

申请
评审
发布
生效

这样才能持续演进。

5️⃣ 数据标准，本质是“业务共识”

这一点特别重要。

很多人以为：

数据标准是技术工作。

但实际上：

它更像是“业务语言统一”。

所以真正推动标准落地的关键，不是技术，而是：

业务参与
管理推动
跨部门协同

六、一个很现实的理解

很多企业的数据治理推进不下去，并不是因为：

技术能力不够
平台能力不够

而是因为：

大家对“同一个数据”没有形成共识。

而数据标准，解决的正是这个问题。

七、写在最后

数据治理有很多内容：

数据仓库
数据质量
主数据
BI分析

但如果一定要问：

哪件事最适合作为起点？

我的理解始终是：

数据标准。

因为只有先说清楚：

数据是什么
怎么计算
怎么使用

后面的治理，才真正有基础。

什么是“真正的数据治理体系”？

发表于 2026-05-06

在很多企业里，“数据治理”这个词并不陌生。

但如果你深入问一句：

什么才算是一个“真正的数据治理体系”？

往往很难得到一个清晰、统一的答案。

有人说是数据仓库，有人说是BI系统，也有人说是数据标准、数据质量工具。

这些都对，但又都不完整。

因为从本质上看：

数据治理不是一个系统，而是一套能够长期运行的体系。

这篇文章，我们尝试把这件事讲清楚。

一、先说一个常见误区

很多企业在做数据治理时，会走一条看似合理的路径：

建数据仓库
上BI系统
做报表

然后就认为：

“我们已经完成了数据治理。”

但现实是：

数据口径依然不一致
报表之间依然冲突
业务依然不信数据

👉 这说明一件事：

你做的是“数据建设”，而不是“数据治理”。

二、那什么才是“体系”？

要理解“数据治理体系”，可以先看一个问题：

如果没有专门项目，这套数据能力还能不能持续运行？

如果答案是“不能”，那它大概率不是体系。

真正的体系，应该具备三个特征：

1. 有结构（分层清晰）

不是一堆系统拼在一起，而是有清晰的层次划分。

2. 有规则（标准统一）

数据有统一定义，有一致口径，有明确规范。

3. 有机制（长期运行）

有人负责，有流程保障，有持续优化能力。

👉 简单来说：

结构解决“怎么建”，规则解决“怎么算”，机制解决“怎么长期做好”。

三、一个可落地的数据治理模型（核心）

结合制造业实践，可以用一个“五层模型”来理解数据治理体系。

🧠 数据治理五层模型

1️⃣ 数据源层（业务系统）

包括：

ERP（经营/财务）
MES（生产）
SRM（供应链/采购）

这一层的特点是：

数据产生的源头，也是问题的起点。

如果源头不规范，后面再怎么治理都会很困难。

2️⃣ 数据整合层（数据仓库）

这一层主要解决：

多系统数据整合
数据清洗与加工
统一数据结构

常见形态：

ODS / DWD / DWS

👉 很多企业做到这里，就以为完成了数据治理。

但实际上，这只是“基础设施”。

3️⃣ 数据治理层（体系核心）

这是整个模型中最关键的一层。

主要包括四个核心能力：

① 数据标准

指标口径统一
命名规范统一
编码规则统一

② 数据质量

数据完整性
一致性
准确性

③ 主数据管理（MDM）

物料
客户
供应商

👉 保证“同一对象，全公司一致”。

④ 元数据管理

数据定义
血缘关系
数据说明

👉 让数据“可理解、可追溯”。

👉 可以理解为：

这一层，决定数据“能不能被信任”。

4️⃣ 数据服务层（对外输出）

这一层的作用是：

把数据能力“交付出去”

包括：

BI报表
数据接口（API）
数据服务

👉 数据如果只停留在仓库里，是没有价值的。

5️⃣ 数据应用层（业务价值）

这是最终目标层：

经营分析
生产优化
决策支持

👉 所有数据治理，最终都要落到这一层。

四、一个关键理解（很多人忽略）

很多企业的问题在于：

做了1、2、4层，却忽略了第3层。

也就是：

有数据
能展示
但不可信

于是出现：

报表很多，但没人用
数据很多，但没人信

👉 本质原因是：

缺少“数据治理层”这个核心能力。

五、体系如何真正落地？

讲完模型，更重要的是怎么做。

这里给你一个“现实可执行”的路径：

1️⃣ 不要一上来做“全体系”

可以按顺序推进：

先打基础（数据整合）
再补治理（标准 + 质量）
再做服务（BI/API）

2️⃣ 从“关键业务场景”切入

例如：

销售分析
库存管理
生产效率

👉 用一个场景，把五层模型“跑通”。

3️⃣ 建立治理机制（不是文档）

包括：

数据Owner
数据Steward
问题处理流程

👉 没有机制，体系无法持续。

4️⃣ 持续运营，而不是一次性建设

数据治理不是项目，而是：

长期运营能力

需要：

持续优化规则
持续修复问题
持续提升数据质量

六、一个总结

如果用一句话总结“真正的数据治理体系”：

它不是一个系统，而是一套从数据产生到数据应用的完整运行机制。

它解决的不是：

数据有没有

而是：

数据是否一致
是否可信
是否能支撑业务

七、写在最后

很多企业的数据问题，不是因为技术不够，而是因为：

缺少一个完整的数据治理认知框架。

当你有了体系，再去做具体工作：

数据仓库
数据质量
主数据

这些事情才会真正“连起来”。

概念

数据管理

wikipedia

The concept of data management arose in the 1980s as technology moved from sequential processing (first punched cards, then magnetic tape) to random access storage. Since it was now possible to store a discrete fact and quickly access it using random access disk technology, those suggesting that data management was more important than business process management used arguments such as “a customer’s home address is stored in 75 (or some other large number) places in our computer systems.” However, during this period, random access processing was not competitively fast, so those suggesting “process management” was more important than “data management” used batch processing time as their primary argument. As application software evolved into real-time, interactive usage, it became obvious that both management processes were important. If the data was not well defined, the data would be mis-used in applications. If the process wasn’t well defined, it was impossible to meet user needs.

从上面的定义可以看出，数据管理是针对数据或信息的活动或能力集合，为了交付、控制、保护并提升数据和信息资产的价值，在其整个生命周期中制定计划、制度、规程和实践活动，并执行和监督的过程。
从商业的角度看，通过对数据进行资产化管理，提升数据质量和数据效率，提升企业利用数据变现的能力。

数据资产

资产的定义为

资产是指由企业过去的交易或事项形成的、由企业拥有或者控制的、预期会给企业带来经济利益的资源。

数据作为一种特殊的资产形式，企业和组织可以依靠数据资产做出更高效的决定，运用数据理解客户，创造出新的产品和服务，并通过削减成本和控制风险的手段来提高运营效率，通过数据产生价值，以达到把数据做为资产进行直接或间接变现。

数据管理目标

理解并支撑企业及其利益相关方的信息需求得到满足
获取、存储、保护数据和确保数据资产的完整性。
确保数据和信息的质量。
确保利益相关方的数据隐私和保密性。
防止数据和信息未经授权或被不当访问、操作及使用。
确保数据能有效地服务于企业增值的目标。

数据管理原则

数据是有独特属性的资产
数据的价值可以用经济术语来表示
管理数据意味着对数据的质量管理
管理数据需要元数据
数据管理需要规划
数据管理须驱动信息技术决策
数据管理是跨职能的工作
数据管理需要企业级视角
数据管理需要多角度思考
数据管理需要全生命周期的管理
数据管理需要纳入与数据相关的风险
有效的数据管理需要领导层承担责任

数据管理框架

DAMA-DMBOK 框架

数据架构（Data Architecture）
数据建模和设计（Data Modeling and Design）
数据存储和操作（Data Storage and Operations）
数据安全（Data Security）
数据集成和互操作（Data Integration and Interoperability）
文件和内容管理（Document and Content Management）
参考数据和主数据（Reference and Master Data）
数据仓库和商务智能（Data Warehousing and Business Intelligece）
元数据（Metadata）
数据质量（Data Quality）

DMBOK 金字塔

第一阶段：构建数据库功能和应用

数据存储和操作
数据安全
数据建模和设计
数据集成和互操作

第二阶段：保障数据质量

数据架构
数据质量
元数据

第三阶段：为数据管理活动提供体系性支持

数据仓库和商务智能
参考数据和主数据
文件和内容管理

第四阶段：利用数据管理好处，提升分析能力

大数据分析
数据挖掘
高级实践

税收定义和特点

对于非财会的大多数人一般会关心个税，还有相当一部分人不用缴纳个税，会认为税跟自己没关系。
其实不然，消费即纳税，而且消费产生的增值税是我国税收的大项，只要在社会上生存，就跟税脱不开关系。
先看下税的定义和分类。

定义

百度百科的定义

税收是指国家为了向社会提供公共产品、满足社会共同需要、按照法律的规定，参与社会产品的分配、强制、无偿取得财政收入的一种规范形式。税收是一种非常重要的政策工具。

税收除了增加财政收入，可以起到调节收入，收入再分配的作用，在一定程度上实现“劫富济贫”。
另外特定的税收还有特定的作用，比如关税还承担着保护国内市场、维护贸易秩序的重要作用。
近几年的贸易战，被当做贸易战武器的相互提高关税税率，其中的关税税率就是关税中的进口税。

现代税收三大特点

固定性
无偿性
强制性

税收分类

按课税对象，划分为

流转税类
所得税类
资源税类
财产税类
行为税类

增值税和营业税都属于流转税。
增值税是以商品（含应税劳务）在流转过程中产生的增值额作为计税依据而征收的一种流转税。
营业税是对在中国境内提供应税劳务、转让无形资产或销售不动产的单位和个人，就其所取得的营业额征收的一种流转税。

增值税针对增值部分征收，营业税针对营业额征收，营业税存在重复征收的情况。

按照税负的实际承担人是否为纳税人，划分为

直接税
间接税

按税收的管理和使用权限，划分为

中央税
地方税
中央与地方共享税

用图表示更直观

税收数据

数据源于国家统计局2018年度。
2018年国家税收收入156402.86亿元，占国家财政收入的85.3%。
增值税和企业所得税是我国的税收大项，分别占税收总收入的39.34%和22.59%，合计占比的61.93%。
大家关心的个税占税收总收入的8.87%。

税类	收入	占比
国家国内增值税(亿元)	61530.77	39.34%
国家国内消费税(亿元)	10631.75	6.80%
国家企业所得税(亿元)	35323.71	22.59%
国家个人所得税(亿元)	13871.97	8.87%
国家资源税(亿元)	1629.9	1.04%
国家城市维护建设税(亿元)	4839.98	3.09%
国家房产税(亿元)	2888.56	1.85%
国家印花税(亿元)	2199.36	1.41%
国家证券交易印花税(亿元)	976.88	0.62%
国家城镇土地使用税(亿元)	2387.6	1.53%
国家土地增值税(亿元)	5641.38	3.61%
国家车船税(亿元)	831.19	0.53%
国家船舶吨税(亿元)	49.78	0.03%
国家车辆购置税(亿元)	3452.53	2.21%
国家关税(亿元)	2847.78	1.82%
国家耕地占用税(亿元)	1318.85	0.84%
国家契税(亿元)	5729.94	3.66%
国家烟叶税(亿元)	111.35	0.07%
国家其他税收收入(亿元)	0.04	0.00%

税制改革与调整

分税制财政管理体制

是指在合理划分各级政府事权范围的基础上，主要按税收来划分各级政府的预算收入，各级预算相对独立，负有明确的平衡责任，各级次间和地区间的差别通过转移支付制度进行调节。它是市场经济国家普遍推行的一种财政管理体制模式。

主要内容

中央与地方的事权和支出划分
中央与地方的收入划分
政府间财政转移支付制度
预算编制与资金调度

1994年的分税制改革，增强了中央财政能力，但是给地方造成支出和收入不平衡的问题，由此带来了土地财政的副作用，在一定程度上推动房价上涨。

营业税改增值税

2016年3月18日召开的国务院常务会议决定，自2016年5月1日起，中国将全面推开营改增试点，将建筑业、房地产业、金融业、生活服务业全部纳入营改增试点，至此，营业税退出历史舞台。

增值税2016年5月之前中央75%，地方25%，2016年5月1日全面营改增之后中央50%，地方50%；企业所得税与个税，中央60%，地方40%。

个人所得税调整

我国个税自1980年9月开始征收，截止到目前历经四次调整。

年份	起征点（元）
1980	800
2006	1600
2008	2000
2011	3500
2018	5000

个税除了起征点的调整，还有相关项附加扣除、级距调整的补充和调整。
根据相关部门和媒体的数据2018年个税调整后，纳税人数由1.87亿减少到6400万。

其他

农业税是国家对一切从事农业生产、有农业收入的单位和个人征收的一种税，俗称“公粮”。
2006年1月1日起废止《农业税条例》。这意味着，在我国沿袭两千年之久的这项传统税收的终结。

参考

数据仓库（Data Warehouse）与数据湖（Data Lake）

发表于 2020-09-12 更新于 2020-09-20 分类于技术

数据仓库（Data Warehouse）与数据湖（Data Lake）

看维基百科的定义

Data Lake

A data lake is a system or repository of data stored in its natural/raw format, usually object blobs or files. A data lake is usually a single store of all enterprise data including raw copies of source system data and transformed data used for tasks such as reporting, visualization, advanced analytics and machine learning. A data lake can include structured data from relational databases (rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data (emails, documents, PDFs) and binary data (images, audio, video). A data lake can be established “on premises” (within an organization’s data centers) or “in the cloud” (using cloud services from vendors such as Amazon, Google and Microsoft).

Data Warehouse

In computing, a data warehouse (DW or DWH), also known as an enterprise data warehouse (EDW), is a system used for reporting and data analysis, and is considered a core component of business intelligence. DWs are central repositories of integrated data from one or more disparate sources. They store current and historical data in one single place that are used for creating analytical reports for workers throughout the enterprise.

从定义来看，数据湖和数据仓库都是可以存储数据的系统，对所存储数据的结构和方式不同，应用场景也有区别。

关键区别

特征	数据湖	数据仓库
起源年代	2011年	20世纪80年代
数据结构	原始数据，非结构化的，没有经过设计的，Schemaless	结构化的，提前预设计和预处理的
用户	专业数据人员，数据科学家、数据工程师、数据分析师	数据分析师、业务分析师
可访问性	更灵活	更易于理解
应用场景	机器学习、数据发现、数据分析	数据分析、分析报告、报表、BI、数据可视化

从目前发展和应用来看，最首要的区别体现在结构化上，数据仓库是预设计处理后的结构化数据，写入时Schema，更易于读取和理解，数据湖是写入时Schemaless，读取时进行Schema设计，所以后期对数据处理的的技能要求相对高。

发展趋势

分别用GoogleTrends和百度指数看下数据湖和数据仓库的关注趋势，因为Google和百度的受众用户不同，也可以大概看出国内外的趋势区别。

GoogleTrends近5年的趋势

百度指数近5年的趋势

可以明显看出国内外对数据仓库的关注度都高于数据湖。从GoogleTrends长期看Data Lake的关注趋势持续走高，Data Warehouse关注趋势呈下降趋势，尤其是几年Data Lake的关注度快要赶上Data Warehouse。
Data Warehouse 这一概念的提出需要追溯到20世纪80年代，Data Lake 这个概念相对Data Warehouse 比较晚，是在2011年由Pentaho CTO James Dixon提出。
可以看出国外对Data Lake的关注比较早，国内在2018年初开始有关注。
按照这种趋势，国外会有大量的产品或服务让Data Lake逐步落地，国内目前还是以数据仓库为主导，等数据湖相关产品和配套服务成熟，趋势上可能会发生变化。

行业发展

各大云计算供应商AWS，Microsoft Azure，阿里云也有针对Data Lake的云产品和服务，目前主要以降低成本为主要卖点，把数据采用对象存储，同时把存储和计算分开，对需要使用的数据分配计算资源，以达到降低存储和计算的资源总成本。
随着企业内数据种类的增多和数据规模的提升，长期看这种商业模式的数据湖会逐渐成为企业数据解决方案的选择。