上个月和一家制造企业的数据负责人聊天，他说了一句话让我印象很深：
"我们公司现在有三个数据仓库、五个数据集市，老板去年又拍板上了数据中台。结果上个月经营分析会，财务给的管理利润是2300万，销售系统算出来是3100万，供应链那边又是1800万。三个数对不上，老板问到底信谁的，没人敢回答。"
这不是个例。过去几年，数据仓库、数据集市、数据湖、数据中台这些概念轮番登场，每来一个新词，就有人急着立项、采购、上线。但很少有人真正停下来问一句：我们当前最需要解决的究竟是什么问题？
这篇文章不讲概念定义，我们从一家企业的真实成长路径出发，看看这四种架构分别对应什么阶段、解决什么问题。
从一栋"烂尾楼"说起
想象一下，你接手了一家开了十年的连锁超市。
公司有收银系统、会员系统、采购系统、仓储系统、财务系统、外卖平台、小程序商城……每个系统每天都在产生数据。但当你想要一份"上个月各品类毛利率报表"时，你发现：
采购系统里的商品编码是"SP20240518-003"；
收银系统里同一个商品是"6901234567890"（条码）；
仓储系统里叫"500ml农夫山泉（新包装）"；
外卖平台上的名字是"农夫山泉矿泉水500ml"。
同一个东西，四种叫法。你想算毛利率？先花三天手工对编码。
更糟的是，财务说毛利率应该用"不含税收入 / 不含税成本"，运营说应该用"实收金额 / 含税成本"，市场部说你们都不对，还要扣掉满减补贴和平台佣金。
这就是大多数企业的起点：数据散落在各个系统里，不是说拿不到，而是拿到以后根本没法用。
这个时候，你要解决的核心问题只有一个：把各处的数据收集起来，按照统一规则整理好，让所有人用同一个口径看同一件事。
数据仓库，解决的就是这件事。
✦ ✦ ✦
第一阶段：建一个"数据总装车间"
数据仓库的工作逻辑，有点像汽车工厂的总装车间。
发动机、底盘、车身、内饰来自不同供应商（相当于ERP、CRM、MES等业务系统），规格不统一，接口也不一样。你不能直接把零件堆在车间里让工人自己拼——你得先定好每种零件的检验标准，规定好装配工序，再上流水线。
数据仓库的"流水线"就是ETL过程：从各个系统抽取数据（Extract），按统一规则清洗转换（Transform），最终装载到分析库中（Load）。
举个例子。同样是"客户年龄"这个字段：
CRM里存的是出生日期"1990-05-20"；
小程序里存的是"35岁"（用户自己填的）；
客服系统里根本没有年龄，只有一张身份证照片。
数据仓库要把这三种来源统一成"年龄（截至统计日）"这一个标准化字段，并且明确：当多个来源冲突时，以哪个为准。
没有经过这道工序的数据，各部门各自出一版报表，对不上是必然的。
这个阶段的另一个关键动作是"主题建模"——不再按"订单表""客户表""商品表"这种源系统的维度来组织数据，而是围绕业务主题重新梳理。比如"销售主题"下面，会整合订单流水、支付记录、退货明细、客户信息、商品信息，形成一套完整的分析视图。
这个工作很重。企业如果有几十个业务系统、上千张表，光是把它们接进来、清洗干净、建好模型，就需要持续投入。很多公司数据仓库建了两年还没上线，不是技术不行，是源头太乱。
在这个环节，如果能用工具替代手工写脚本，效率会高很多。亿信华辰的数据工厂支持30多种数据源的即插即用接入，通过可视化拖拽完成ETL开发和调度，让数据的"入仓"过程从手工作坊升级为流水线作业。
不过，建好数据仓库只是第一步。很快你会发现一个新问题——
✦ ✦ ✦
第二阶段：总部有了数，部门怎么办？
数据仓库建起来以后，财务部终于可以按月出利润表了，供应链也能看到库存周转率了。
但销售部不满意。他们说："我们要的是每个销售个人的周业绩排名、客单价趋势、新客转化率，你们总部的报表半年才更新一次，等不起。"
市场部也说："我们要看每个渠道的投放ROI，按天维度，还要分城市、分广告位。你们的汇总表粒度太粗了。"
这就是数据仓库的边界：它能很好地解决"企业级统一口径"的问题，但在响应具体部门的个性化需求时，速度往往跟不上。
于是，数据集市就登场了。
可以把数据集市理解为：从企业数据仓库这个大"总装车间"里，拉出一部分成品零件，在部门旁边搭个小"加工站"。这个加工站只服务这一个部门，可以根据部门需求做更灵活的组装。
比如销售数据集市，它的数据底座来自数据仓库（客户、订单、商品的标准口径已经统一过），但查询逻辑完全按销售团队的习惯来组织：按人、按区域、按产品线、按时间周期，想看什么维度自己组合。
这里有一个关键前提：数据集市如果直接跳过数据仓库，从业务系统裸拉数据自己建，那就是在制造新的数据孤岛。
销售自己拉订单表，财务自己拉结算表，运营自己拉流水表——三套数据、三个口径，你说谁的对？到时候又回到文章开头那个场景：三个利润数字，没人敢认。
数据集市的正确打开方式是：在统一的数据仓库底座之上，按部门需求快速交付。你可以把它理解成"大超市"和"便利店"的关系——大超市品类全、价格统一，便利店就在楼下、想买什么随时能拿到，但便利店的货是从大超市的仓库出的。
当企业需要把数据集市的分析结果以可视化报表、看板、驾驶舱的形式呈现给管理层时，可以借助亿信华辰亿信ABI一站式数据分析平台，它提供从数据接入、主题建模到报表设计、酷屏大屏的完整能力，支持拖拽式操作和零SQL开发，让业务人员也能快速搭建部门级分析应用。
有了数据仓库和数据集市，企业通常能做到"报表自己跑、口径不乱套"。但新的麻烦很快又来了——
✦ ✦ ✦
第三阶段：当数据不再是"表格"一种形态
前面讲的所有场景，处理的都是结构化数据——订单、客户、库存、财务凭证，清一色是表格。
但今天的企业，数据形态早已不是表格一种了。
比如你经营一家连锁餐饮企业：
▸ 每家门店的摄像头每天都在录视频（可以做人流分析、排队时长分析）；
▸ 外卖平台的用户评价是文字（包含菜品偏好、服务投诉、竞品对比）；
▸ 后厨的IoT设备实时回传温度、能耗、设备运行日志；
▸ 小程序上有几十万条用户浏览和点击行为数据；
▸ 企微群里每天几百条客户聊天记录。
这些数据能不能用？当然能用。但问题是，你在建数据仓库的时候，根本不知道这些数据将来会怎么用。
两年前建仓的时候，你不会想到今天需要做"根据后厨设备运行数据预测故障"。如果当时没把这部分数据存下来，现在就只能看着设备在报表之外"裸奔"。
这就是数据湖的用武之地。
数据湖做的事情很朴实：先把所有数据原样存起来，不急着定义用途。不管是结构化表格、半结构化日志还是非结构化的图片视频，统统收进来，等将来哪个部门需要分析什么了，再从湖里按需取用。
打个比方。数据仓库像中药铺的药柜——每种药材分类、称重、标注用法；数据湖更像一个大型冷库——生鲜、干货、冻品都往里放，将来要做哪道菜，再从冷库里取原料加工。
冷库听起来很实用，但它有个天大的坑：如果你只管往里塞，不登记、不分类、不标保质期，过两年就变成一个谁也不敢碰的"僵尸库"——这就是业内常说的"数据湖变数据沼泽"。
怎么避免？关键不是存不存，而是存的同时有没有做好三件事：
避免"数据沼泽"的三件事
编目
湖里到底有什么数据？能不能快速检索到？
标记
这份数据从哪来、什么时候入库的、谁负责维护？
管控
哪些数据有权限限制？哪些会定期更新？哪些一年没人访问就该归档？
这些工作的专业术语叫元数据管理。做不好，数据湖就是个黑洞；做好了，它才是真正的数据"宝藏库"。
近几年业内又提出了湖仓一体的概念，就是为了解决"湖是湖、仓是仓、数据两头搬"的问题。湖仓一体的目标很明确：让低频冷数据躺在低成本的湖存储里，需要分析时无缝拉入计算引擎；高频热数据在仓里做高性能查询，两部分数据统一管理、统一权限。
亿信华辰的PetaBase就是按这个思路设计的，不走"先建湖再上仓"的冤枉路。
到此为止，数据仓库统一了口径，数据集市响应了部门需求，数据湖存下了全量原始数据。看起来该有的都有了。但很多企业会卡在下一个关口——
✦ ✦ ✦
第四阶段：数据"通"了，但没"用"起来
前面三个阶段解决的是"数据从哪来、怎么存、怎么查"。但数据中台要回答的问题是另一些：
▸ 销售部定义了一次"高价值客户"标签，市场部能不能直接复用，而不是再跑一遍SQL？
▸ 财务部沉淀了一套"客户信用评级模型"，风控部能不能直接调用，而不是自己从头建模？
▸ 数据团队做好了"同店增长率"指标，各业务线的报表、看板、推送能不能统一用同一个计算结果？
如果每个部门都在重复建标签、算指标、写接口，那花大价钱建设的数据仓库和数据湖，最终只服务了寥寥几张报表。这就是典型的"数据通了，但能力没沉淀下来"。
数据中台解决的不是"存"的问题，而是"复用"的问题。
数据中台的三件"调度"工作
可以把前面几个阶段理解成建立了一套城市供水系统：数据仓库是水厂（统一净化处理），数据集市是各小区的二次供水站（按片区调配），数据湖是水库（蓄存所有水源）。数据中台更像市政管网调度中心——不生产水，但决定哪个区域用哪条管道、水压多少、出了故障怎么自动切换备份。
统一主数据
客户、供应商、物料、组织这些核心实体，必须在全公司层面统一编码和属性，不能在A系统叫"张三"、B系统叫"张 三"、C系统叫"张三疯"。这件事做好了，所有分析才有根基。亿信华辰的睿码主数据管理平台做的就是这件事。
沉淀可复用的数据资产
指标体系、标签体系、算法模型、数据API，这些不是一次性消耗品，建好了就应该变成公司级的"公共服务"。新项目要上线一个BI看板，不用从取数开始做，直接在已有的指标和标签上组装就行。
治理闭环
数据质量、数据标准、数据安全不是运动式的"搞一次检查"，而是融入日常运营的长效机制。亿信华辰的睿治数据治理平台覆盖了元数据、数据标准、数据质量、数据安全的全链路，让治理不再是"项目"，而是一种"能力"。
✦ ✦ ✦
回到最初的问题：到底该建哪个？
四种架构没有绝对的"谁比谁好"，只分"当前阶段谁更适合"。以下是几条基本判断：
对照你的实际情况，对号入座
如果你现在的情况是——
各业务系统数据分散，财务和运营看的是两套数，每次出月报都要手工对账两三天。
→ 优先搞好数据仓库，把口径先统一起来。没有这个底座，后面一切免谈。
如果你现在的情况是——
公司已有基础数仓，但业务部门抱怨看数据太慢，IT跟不上需求响应。
→ 在现有数仓基础上建设数据集市，让各部门在统一口径下自主分析。注意：别让部门直接从源系统自己拉数据。
如果你现在的情况是——
企业有大量IoT设备数据、用户行为日志、非结构化文件，预见到未来会做算法训练或深度分析。
→ 考虑数据湖或湖仓一体方案。但必须同步投入元数据管理，否则大概率会变成沼泽。
如果你现在的情况是——
底层数据已经打通了，但数据能力（指标、标签、模型、API）没有沉淀，每次做新项目都是"从零开始"。
→ 重点建设数据中台。先做统一主数据，再做指标和标签体系，最后打通数据服务。
写在最后
回到文章开头那家制造企业。
三家各自的数据仓库也好，五个部门数据集市也好，新上的数据中台也好——问题的根源不在于"建少了"，而在于建之前没想清楚一块数据到底要经过几道工序：采集归拢是第一道，清洗标准化是第二道，按主题建模是第三道，沉淀为可复用资产是第四道，这些步骤没办法跳过。
建平台只是手段，解决业务问题才是目的。
亿信华辰在这条链路上覆盖了从数据采集、数据存储与计算、数据治理、主数据管理到数据分析与应用的完整能力。企业可以根据自己所处的阶段，选择最迫切的一个环节先做实，再逐步延伸。
数据架构这件事，真正重要的不是叫什么名字，而是每建一个环节，能不能让下一个环节少走弯路。
（部分内容来源网络，如有侵权请联系删除）
