老板问"能不能搞数据中台"，我从6个维度把话说明白了

上周，老板突然问我：

“我看集团那边数据中台搞得挺好，我们能不能也搞一个？”

我当时心里一紧。我们用的是集团的平台——底层计算引擎、调度系统、存储集群全是集团的，我们只有使用权限，连个参数都改不了。换句话说，房子是别人建的，我们只是租客。

回到工位我翻翻《大数据之路》，阿里从2011年三板斧到2014年登月项目，10年演进。书里写得很清楚：阿里巴巴从未有一个名为"数据中台"的团队，那个团队叫"数据技术及产品部"，几百号人。

我们呢？3个人，租的房子，老板问能不能搞中台。

我得把这话说清楚。周末花了两天，从6个维度剖析——到底能不能做、要不要做、可不可以做。

---

第1问：老板，你说的"中台"是哪个中台？

这个问题不搞清楚，后面全是废话。

数据中台至少有三层含义：

说法	本质	谁在干
技术中台	计算引擎+调度+存储底座	集团（我们动不了）
数据资产中台	统一指标体系+规范建模+数据治理	数仓（我们能干）
服务中台	API网关+数据服务化+报表平台	集团+我们协作

老板说的"集团搞得挺好"，大概率指的是技术中台——大屏好看、查询快、调度稳。但这玩意儿集团已经搭好了，我们不用再搭一遍。

真正缺的是什么？我们指标口径不统一、模型没人管、取数靠手工——这是数据资产中台的事。这一层，集团管不了也不想管，因为它跟业务强绑定，只有我们自己的数仓团队才能做。

所以第一句话我得跟老板说清楚：技术底座不用搞，集团有了；我们要搞的是数据资产中台——统一口径、规范建模、数据治理。这事儿，3个人能干。

---

第2问：底座是别人的，我们能动什么？

这是最现实的约束。

刚接到这个任务的时候我有点懵——中台的书我看了不少，但书上讲的都是怎么搭引擎、怎么选架构，没人告诉我"如果引擎是别人的你该怎么办"。

后来我想通了：中台不是一层，是两层。底座是一层，应用是一层。我们做不了底座，但应用层全是我们的活。

集团平台给我们的能力边界：

说白了：我们能建库、建表、写SQL、做报表，不能改引擎参数、不能动调度策略、不能扩存储。

这够不够？我仔细想了一下——够了。

数据资产中台的核心不是改底层，是管好上面那层。就像你租了个写字楼，不能拆承重墙，但办公区怎么分区、工位怎么摆、文件怎么归档，全是你的事。

但有一个前提：集团的ODS层数据我们得能拿到。如果连原始数据都拿不到，那中台就是空中楼阁。这个得跟集团谈，谈不下来就别往下走了。

---

第3问：我们的数据够不够撑起一个中台？

中台不是搭架子，是管数据。数据不够，架子再漂亮也是空的。

我盘了三本账：

数据量：我们每天运单量10万+，3条业务线（快递/快运/供应链），ODS层150+张表。够不够？够了。数据量不是中台的前提，数据域的覆盖才是。

数据域：我按业务过程梳理了一遍——

数据域	业务过程	核心表
运单域	下单→揽收→运输→派送→签收	运单表、轨迹表、签收表
网点域	入库→分拣→出库	入库表、分拣表、出库表
时效域	承诺时效→实际时效→偏差分析	静态路由表、时效规则表
财务域	结算→对账→开票	结算明细表、对账表

4个数据域，覆盖了80%的业务场景。够。

数据质量：这个最头疼。运单表的揽收时间有空值（占3%），签收状态有脏数据（"已签收"但签收时间为空），网点编码和主数据对不上（差了200+个编码）。数据质量不过关，中台上线就是给自己挖坑。

所以第三本账的结论：数据量够、数据域够、数据质量不够。质量是第一个要补的课，不然后面建模全白搭。

---

第4问：没有OneData体系，指标会不会越做越乱？

答案是：一定会。

我翻了翻我们现有的报表——签收及时率，运营算出来96%，客服算出来91%。同样的指标，两个口径：

-- 运营口径：所有签收运单
SELECT COUNT(CASE WHEN sign_time <= promise_time THEN 1 END) * 1.0 
     / COUNT(*) AS sign_timely_rate
FROM dw.ewb_sign_detail
WHERE dt = '${bizdate}';

-- 客服口径：排除拒收和破损
SELECT COUNT(CASE WHEN sign_time <= promise_time THEN 1 END) * 1.0 
     / COUNT(CASE WHEN sign_status NOT IN ('拒收','破损') THEN 1 END) AS sign_timely_rate
FROM dw.ewb_sign_detail
WHERE dt = '${bizdate}';

差了5个点，就是拒收和破损件的占比。

说实话，发现这个问题的时候我有点后怕。这5%的差距在经营分析会上被业务追着问了半小时，运营总监当场拍桌子——"你们数仓到底准不准？"我回去翻SQL才发现，两个部门用的是完全不同的分母，之前竟然没人发现。

这不是个例。我盘点了一下，50+报表里，口径冲突的指标有8个。每个冲突背后都是一次跨部门吵架，吵完没人改，下次开会继续吵。

OneData体系要解决的就是这个问题——数据域、业务过程、原子指标、修饰词、时间周期，组合成派生指标，每个指标只有一个定义。

但OneData不是买来的，是一行行写出来的。我们需要：

1. 指标字典：每个指标一页纸——名称、口径、数据域、负责人、创建时间
2. 指标评审：新指标上线前必须过评审，不通过不准建表
3. 口径唯一：同一个指标只能有一个SQL，贴在指标字典里

这套东西，3个人能做。不用集团配合，纯数仓内部的事。

---

第5问：业务真的需要吗？3个信号

不是所有公司都需要中台。我梳理了3个信号，同时出现才动手：

信号1：同一指标三个数。 运营说签收及时率96%，客服说91%，数仓说94%——三个口径三个数，经营分析会上吵半小时谁都不认谁的。

信号2：取数排号。 运营小姑娘每周五来敲门："哥，帮我拉一下各网点签收明细。"我写SQL→导CSV→发邮件→下周一她回来说字段不对→改了再发。一个需求3天，每天3个需求排着队。

信号3：经营分析会翻车。 老板问"上个月发了多少单"，运营说287万，客服说292万，财务说281万。三个数字三个口径，数据在，没人信。

如果你公司只有一条业务线、报表不到20张——加人就够了，别上中台。

我们当时3条线 + 50+报表 + 每天3个取数需求，够了。

---

第6问：3个人，从哪下手？

老板问"能不能做"，我最后给了他一张表：

维度	能不能	说明
技术底座	❌ 不能也不需要	集团有了，我们用就行
数据同步	⚠️ 依赖集团	ODS数据必须能拿到
数据质量	✅ 能做	入库校验+空值处理+编码对齐
规范建模	✅ 能做	OneData体系+指标字典
报表服务	✅ 能做	先出报表再补模型
API服务化	⚠️ 依赖集团	需要集团开放接口

结论：6成能做，2成依赖集团，2成做不了。能做的那6成，才是我们应该做的。

怎么下手？我踩过的坑告诉我——先出报表再补模型，别倒着来。

上一家公司我就是先建模型，建了2个月没产出，老板质疑价值。这次我学乖了：

第1-2周：ODS数据拉通 + 数据质量摸底
第3-4周：从最急的5张报表开始，直接ODS→ADS，先让业务看到东西
第5-8周：回头补CDM，按数据域建模，统一口径
第9周起：指标字典+评审机制，口径卡点
每季度回头看：沉默表清不掉、数据域该拆就拆、指标字典更新

业务2周看到东西，信任建起来了，后面建模阻力小得多。

---

周一我把这6个维度写在一张A4纸上递给老板。

他看了5分钟没说话。我当时心里在打鼓——是不是说太直了？毕竟他问的是"能不能搞"，我给了他一张"6成能做"的表。

结果他抬头说：“那就先搞数据质量那块，其他的找集团谈。”

我说行。

这6个问题不是标准答案，每家公司情况不同。但有一点是确定的：不是能不能搞中台的问题，是搞哪一层的问题。底座别人盖了，我们管好里面的东西，这才叫务实。