数据仓库与数据中台最大的区别是什么？终于有人讲明白了

数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，用于对管理决策过程的支持，有四个特征：

（1）面向主题：数据仓库都是基于某个明确主题，仅需要与该主题相关的数据，其他的无关细节数据将被排除掉

（2）集成：从不同的数据源采集数据到同一个数据源，此过程会有一些 ETL 操作

（3）随时间变化：关键数据隐式或显式的基于时间变化

（4）数据不可更新：数据装入以后一般只进行查询操作，没有传统数据库的增删改操作。

数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据，而不是联机处理的数据。数据仓库一般是分层的，目的是为了解耦和共享，从而提升对应用的支撑效率，这其实非常符合中台的沉淀共性能力的理念：

（1） ODS（Operation Data Store），操作数据层，即原始数据层，又叫贴源层，与业务系统基本同构（可能会增加管理字段），目的是保留历史，解耦业务数据库，这样整个数据平台只需要访问一次业务数据库即可。所以 ODS 层存在的意义是尽可能减少对业务数据库的访问压力。ODS 层有些时候会细分为两层，一个 STG 数据缓冲层，存原始数据，一个 ODS，存简单清洗的数据。

（2）DWD（Data Warehouse Detail），明细数据层，对数据进行清洗、代码统一、字段统一、格式统一、简单聚合等工作。DWD 层存在的意义是做数据的标准化，为后续的处理提供干净、统一、标准的数据。

（3）DWB（Data Warehouse Base），基础数据层，又叫轻度汇总层，遵照维度模型的原理，将数据拆成维度和事实，进行维度、事实的统一。对数据进行轻度汇总，形成指标结果。

（4）DWS（Data Warehouse Service），服务数据层，按照业务目标，对已经处理好的数据进行横向汇聚、纵向汇总。按照宽表模型进行数据冗余和预计算，以空间换时间。

数据仓库刚起步的时候，目的是融合整个企业的全部数据，打通数据之间的隔阂，消除数据标准和口径不一致问题，从而做好决策支持，表现形式一般是报表和指标，BI 是其升级版本，从本质的角度来讲，数据仓库是面向业务主题的，其符合数据中台的标准（1），即为业务服务。

可惜的是，数据仓库恰恰也被困在决策支持这个业务上，其对业务系统很少直接提供数据服务的支持，数据仓库对于业务的价值，大多需要通过管理者的决策体现出来，偶偶的侵入业务系统，也是做做亮点，比如搞个数据挖掘。数据仓库跟数据中台很难说有本质区别，这是数据中台被数据仓库从业者诟病的原因，但两者对业务的支撑广度和深度不在一个级别上，数据仓库仅仅赋能决策支持，而数据中台对业务的支持是全方位的，其不仅通过 API 等形式直接嵌入到业务流程中发挥作用，而且还能通过数据产品直接创造价值。

由于数据仓库以前局限于决策支持这个业务，反倒限制了数据价值的发挥，管理者又对报表和指标这个业务特别敏感，因此元数据和数据质量管理成了数据仓库最核心的工作，而数据中台所倡导的模型开放、共享复用并不为老的数据仓库时代所重视。现在很多人把汇聚全域数据作为数据中台与数据仓库的区别，显然没有抓住本质的东西，其实只有更多的前端业务需要数据仓库提供数据服务，才能驱动数据仓库去真正的汇聚全域数据，否则领导关注的 KPI 指标就那几个，汇聚全域数据对于这些 KPI 指标来说，其实没有那么高的价值。

量变导致质变，数据中台的提出有进步意义，它让我们基于业务的需要去打造数据仓库，而不是倒过来，即建了数据仓库然后再想着业务场景，数据中台与数据仓库的区别也不在于技术本身，而在于有没有业务思维。从技术角度上去否认数据中台意义不大，其实如果有了业务思维，不建数据仓库又如何？你提供一个位置 API 服务了很多前端应用，那这个 API 就可以称为微型的数据中台，从这个角度看，由于业务的牵引，数据中台又是超越数据仓库的。

因此，虽然数据仓库表面上符合数据中台特征的（1）（2）（3）（4），但如果你的企业建设数据仓库的业务思维没有转变，没有建立其之适配的业务运营体系，你建的数据仓库就不能称为数据中台。

业务思维的不同也影响到了数据仓库和数据中台技术实现的差异，以前的数据仓库虽然也在业务建模，但由于出口有限，因此打造 API 服务的必要性不是很大，因此，大多数据仓库其实都在做 One-Data，One-ID 的事情，但 One-Service 鲜有提及，阿里显然对于这个有更深入的认识，数据中台其实更应关注 One-Service 的实现和运营。

阿里提出数据中台这个概念的时候，很多数据仓库摇身一变成了数据中台，但这些数据仓库其实仍是 20 年前的那个数据仓库。