数仓、中台、数据湖，到底啥区别

 

这三个词被问烂了，但十个人里有八个答不对。大多数人的答案是把它们当成三代产品，数仓过时了，要上数据湖，中台是升级版。今天用三个真实项目把这三者的关系掰开。

---

上个月一个朋友拉我给他公司做咨询，一坐下他们CIO就问，我们已经有数仓了，服务商说还要建数据湖，互联网公司又都讲中台，这三个到底啥关系，是不是买一个就能替代另外两个。

我说你们先把这三个词的定义说给我听听。CIO看了眼旁边的IT经理，IT经理说，数仓就是存数据的地方，数据湖是更大的存数据的地方，中台是阿里的东西。

我当时就想，完了，这单咨询的钱太好挣了。

这三个词被问烂了，但答对的没几个。问题出在哪，出在大多数人把三者当成了一条时间线上的三代产品，好像数仓是诺基亚，数据湖是苹果，中台是华为，一代换一代。这个理解从根上就错了。

数仓、数据湖、中台，根本不在一个维度上。一个是加工方法，一个是存储架构，一个是组织能力。它们不是互相替代的关系，是分工协作的关系。这篇用我做过的三个项目把它们讲透。

数仓，一间加工厂

先说数仓，因为它是三者里最老、定义最清晰的一个。

数仓的官方定义是面向主题的、集成的、相对稳定的、反映历史变化的数据集合。这句话念三遍也没感觉，换个说法，数仓是一间加工厂，把原材料加工成标准件。

原材料是什么，是各业务系统的原始数据。销售系统的订单、售后系统的工单、财务系统的发票，这些数据散落在几十个系统里，口径不一、格式不一、脏乱差。加工厂把它们收进来，清洗、标准化、按主题重新组织，最后产出能直接用的结果。

我写过一篇四层数仓分层的文章，ODS贴源、DWD明细、DWS汇总、ADS应用，这四层就是加工厂的流水线。G企有个经典案例，同一个销售额指标，销售系统按下单时间算，财务按开票时间算，物流按发运时间算，三张报表对不上，开会能吵一小时。数仓把这些原始数据统一加工一遍，后面所有人用同一份数据，口径自然就统一了。

数仓的关键词是加工。进来的数据是乱的，出去的数据是标准的。代价是慢和贵，每来一种新数据都要设计表结构、写清洗逻辑、定口径，灵活性差。

一句话记住数仓，先想清楚再存，schema on write，写的时候就定好结构。

数据湖，一个原料仓库

数据湖是2010年以后被热炒的概念，背景是大数据时代数据类型爆炸了。

以前的数仓只处理结构化数据，就是能写成二维表的那种。后来日志、图片、语音、传感器信号、互联网行为埋点全来了，这些数据有两个特点，量大，格式乱。你根本没法提前设计好表结构，因为很多数据你都不知道将来怎么用。

这时候有人提出，别加工了，先原样存下来再说。这就是数据湖，一个原料仓库，什么都能往里扔，扔的时候不做任何加工。

FT企上华为云那个项目，数据入湖用的是OBS对象存储加MRS大数据平台。一百多个业务系统的数据，结构化的、半结构化的、日志文件，全部按原样落到OBS里。这就是湖，先囤着，要用的时候再从里面捞出来加工。

数据湖的关键词是囤积。好处是灵活、便宜，什么数据都能存，存的时候不用想清楚用途。代价是治理跟不上就是灾难，这一点我后面细说。

一句话记住数据湖，先存下来再想怎么用，schema on read，读的时候才定结构。

数仓和湖的区别，一句话概括，数仓是先想清楚再存，湖是先存下来再想。就这一句，其他区别都是这句话的延伸。

中台，一套复用机制

中台是最容易被误解的一个，因为它压根不是个技术架构，是个组织概念。

中台这个词2015年从阿里火起来，背景是阿里内部各业务线各建各的数据体系，淘宝一套、天猫一套、支付宝一套，同一套用户数据被重复开发了十几遍。后来阿里把公共的数据能力抽出来统一建设，统一用户识别、统一商品体系、统一数据服务，各业务线按需调用。这个「公共能力层」就是数据中台。

所以中台的关键词是复用。它回答的问题不是数据怎么存怎么算，而是数据能力谁来建、怎么共享。

C企的CDP项目是中台思路的典型落地。C企有会员、商城、社区、客服一堆业务线，每条线都要用「用户画像」。没有中台的时候，每条线自己建用户标签，会员线算自己的RFM，商城线算自己的购买偏好，算出来的用户分层互相打架。建了CDP之后，标签体系统一建设，三层分类，事实类、规则类、模型类，各业务线直接订阅使用。一个「高价值用户」标签，会员的权益运营用，商城的精准推送用，客服的服务策略也用，一处建设多处复用。

这就是中台。它可以是CDP，可以是标签平台，可以是一套数据服务API，形式不限，内核只有一条，把重复建设的公共数据能力收拢起来统一供给。

中台不神秘也不高级，它就是数据领域的「共享服务中心」，和HR共享服务中心、财务共享服务中心一个逻辑。

三者不是三代产品，是一条流水线

好，三个词分别说完了，现在回到那个核心问题，它们是什么关系。

答案是，湖存原料，仓做加工，中台管复用，三者是一条流水线上的三段。

用一张完整的数据流走一遍。

FT企的一百多个业务系统，数据先原样落到OBS数据湖，这是第一段，囤原料。需要分析的数据从湖里抽出来，进DWS数仓做分层加工，ODS到DWD到DWS到ADS，清洗、标准化、聚合，这是第二段，做标准件。加工出来的标签、指标、用户画像，通过数据服务统一供给各业务系统调用，这是第三段，管复用。

三段可以全要，也可以只要一段。数据量小、业务单一的企业，一个数仓就够，湖和中台都是奢侈品。数据类型复杂、多业务线重复建设严重的大集团，三段全上才划算。

那个CIO问我买一个能不能替代另外两个，答案就在这。三者不在一个维度，怎么替代。你去问供应商，数仓产品和数据湖产品当然会互相说自己能替代对方，因为它们确实在「存储和计算」这一层有重叠。但中台替代不了，因为中台买不来，DataWorks、DataArts Studio这些平台只是工具，中台的内核是组织方式和建设方法，工具只是载体。这也是为什么很多企业花大几百万买了中台产品，最后只得到一个更贵的ETL工具。

三个常见误区

误区一，数仓过时论。

最流行的说法是，都2026年了还建数仓，直接上数据湖。

这个说法的坑在于，湖解决的是存储问题，不解决加工问题。数据原样躺在湖里，不会自动变成口径统一的报表。FT企入湖的时候推了一套数据入湖标准，一百多个系统各写各的，字段命名、编码标准全不一样，标准推了好几轮落不下去，湖差点变沼泽。

湖里的数据最终要支撑业务分析，中间还是要有加工这一层，这个加工层的成熟方法论就是数仓分层。所以现实的架构普遍是湖仓并存，湖管原始数据，仓管加工数据，这就是这两年热炒的湖仓一体。湖仓一体不是把湖和仓捏成一个东西，是让湖和仓共享一份数据和元数据，别两套存储两份数据反复搬。

误区二，中台产品化。

第二个坑，把买平台当成建中台。

中台失败案例里最常见的一种，是老板拍板建中台，采购了一套平台产品，部署完发现没人会用，也没有统一建设的机制，最后各业务线还是各抽各的数据各算各的指标，平台沦为摆设。

中台的前提有两个，一是业务线足够多，重复建设确实存在，二是组织上有强有力的推动方，能把「各建各的」改成「统一建、共享用」。缺一个，中台就只是PPT里的词。没有多业务线的企业硬上中台，相当于三口之家建了个食堂中央厨房。

误区三，先把湖建起来再说。

第三个坑最隐蔽，技术团队驱动的大数据项目特别容易踩。

先建个湖，把所有系统的数据都囤进来，囤完再想怎么用。听着很有前瞻性，实际结果是数据囤了几百TB，没人访问，治理成本倒是实打实在烧。数据湖的成本不只是存储费，元数据管理、权限、数据质量监控，全是持续投入。

正确的顺序是反过来，先有明确的分析场景和消费方，再倒推需要什么数据、要不要建湖。我见过最惨的一个湖，囤了三年，唯一的作用是给管理层汇报PPT提供一个「数据总量突破XXTB」的数字。

怎么判断自己需要什么

三个问题过一遍。

第一问，数据类型复杂吗。如果90%以上都是结构化业务数据，报表需求为主，一个传统数仓足够，别碰湖。如果日志、埋点、物联网信号占了很大比例，湖才有必要。

第二问，业务线之间在重复建设吗。同一个指标各算各的，同一个用户画像各建各的，而且这种重复正在拖慢业务，中台才值得建。没有这个痛点，中台就是成本中心。

第三问，团队养得起吗。湖和仓可以共存，但湖仓一体架构对团队要求不低，元数据、血缘、多引擎适配，都是活。团队五六个人，老老实实把一个数仓建好比什么都强。

这三问答完，大部分企业会得出一个朴素的结论，先不用想那么大，把数仓的分层和口径做扎实，比追任何概念都值钱。

写在最后

数仓、数据湖、中台这三个词，会继续被混着用下去，供应商的PPT会继续把它们包装成一代更比一代强的产品。

但你自己得清楚，湖是原料仓库，仓是加工厂，中台是共享厨房。仓库讲究囤得全，工厂讲究做得精，厨房讲究复用得多。一个企业数据体系做得好不好，从来不是看用了哪个概念，是看这三段分工清不清楚，每一段做没做到位。

概念会过时，分工逻辑不会。从N企2017年用SAP BO做报表算起，我看了快十年，工具换了一茬又一茬，湖仓一体之前还有Lambda架构，中台之前还有SOA，但「存原始、做加工、管复用」这三件事，从来没变过。

把这三件事想明白，下一个新概念出来，你自己就能判断它是真东西还是旧酒新瓶。

---

作者 凌波，18年汽车行业数字化老兵，CDGP数据治理专家。从DMS运维到数据中台架构，干过甲方也干过乙方。

完整系列目录和资料包在公众号「凌波微数」，微信搜一搜就能找到。

下一篇预告 数据团队怎么搭，招人顺序、岗位配比和能力模型，一个踩过所有坑的老兵的答案。