第 3 章 · 从一张报表到一套能力：大数据与数据中台

数据团队最怕听到的一句话，不是“这个数错了”，而是“这个需求跟上次差不多”。

跟上次差不多，通常意味着不能直接用。

上次按自然月，这次按促销周期；上次看支付金额，这次要扣掉退款；上次只看直营网点，这次还要加经销商。表、脚本、接口、权限，样样都像做过，拼起来又得重新来一遍。

做得越久，重复的东西越多。客户、商品、组织、时间、地区，每个项目都在接；清洗、去重、汇总、权限，每个团队都在做。业务抱怨数据部门慢，数据部门觉得业务永远说不清。

于是，一个很自然的念头出现了：

能不能别再一张报表一张报表地做，干脆把公共能力先建好？

大数据先改变了“装得下”

数据仓库并没有因为大数据出现就失效。它仍然擅长管理结构化、经过整理、需要稳定分析的数据。

变化来自企业开始面对另一批东西。

网站点击流、搜索日志、图片、文本、传感器数据不断涌进来，数据量更大，来得更快，格式也更杂。传统架构并非一条都处理不了，只是成本、扩展方式和处理速度越来越吃力。

NIST 对大数据的定义没有规定一个固定容量，而是强调数据的规模、速度、种类和变化性迫使系统采用可扩展的新架构。这个说法比“数据超过多少 TB 就叫大数据”靠谱，因为今天的大，几年以后可能只是普通。

大数据那一轮首先解决的是“装得下、跑得动”。分布式存储和计算把任务拆到很多机器上，便宜硬件也能处理过去价格高得吓人的数据规模。

但企业很快发现，装得下不等于用得好。

数据湖里什么都有，找一个能放心使用的数据集却越来越难。日志进来了，业务含义没进来；字段保存了，口径没有人负责；团队可以自由加工，也可以自由制造另一套答案。

技术扩大了供给，管理问题跟着一起放大。

从资源共享，到语义共享

平台化最早容易做的是共享资源。

大家共用一套存储、一套计算集群、一套开发工具，至少不用每个部门重复采购。再往后，企业会希望共享数据加工能力：同一个源只接一次，清洗规则不要各写一套，常用数据能按权限直接申请。

再往后就难了，因为共享开始碰到语义。

“客户”能不能全公司共用？零售里的会员、酒店里的住客、保险里的投保人和被保险人，都是人，却不是同一个业务对象。即使在同一家公司，市场部门想认识“可以触达的人”，财务关心“产生收入的人”，客服关心“正在服务的人”。

平台如果抽象得太少，就只是把表集中存放；抽象得太多，又可能造出一套谁都觉得不像自己的标准。

主数据、指标平台、数据服务和数据治理，都是在处理这层矛盾。它们试图把反复出现的连接、口径和服务沉淀下来，让下一次需求站在上一次的肩膀上。

这也是“中台”最有吸引力的地方。

互联网公司的中台，为什么看起来那么顺

阿里巴巴官方在回顾自身组织变革时，把 2015 年描述为推动“中台战略”的年份，形成“大中台、小前台”的模式。后来，这套说法迅速走出阿里，成了中国企业数字化里最热闹的一批词。

它会流行，不只是因为大公司会讲概念。互联网平台当时确实有一个很现实的问题：多个业务快速试错，但用户、商品、交易、支付、营销等基础能力不能每次从头建设。

前台要快，中间就得有人把共性接住。

更关键的是，互联网公司的业务本来就在软件里发生。

一个用户从看到商品、点击、下单、支付到评价，过程大多能被平台记录。运营改了推荐策略，数据很快回来；产品换了页面，转化率马上给反馈。数据团队提供的不只是事后报表，也可能直接进入产品实验和流量分配。

在这种环境里，数据是业务的组成部分。平台能力被调用一次，往往就能在用户行为和收入上留下痕迹。

传统企业的情况不同。

工厂的产品要经过设备和产线，酒店的服务发生在房间和前台，供应链的履约横跨仓库、车辆和合作伙伴。软件能记录其中很多环节，却很难天然拥有整个过程。

数据平台告诉工厂某种物料周转慢，不能自己修改采购制度；告诉酒店某个渠道利润低，也不能越过经营负责人调整房价；指出一批客户可能流失，更不能自动改变销售的奖金和跟进方式。

互联网公司里，数据平台与业务动作可能只隔一个接口。传统企业里，中间还隔着组织、权限、现场和利益。

把同一套架构搬过去，搬走的是技术形状，未必是它生效的条件。

传统企业买到的，常常是“建设中台”

一个平台要有价值，必须不断有人使用它。

这句废话在项目里经常被忘掉。

平台型项目很容易先列能力清单：数据接入、开发工具、指标管理、资产目录、标签平台、服务接口、权限审计。清单越完整，方案越像一件大事，也越容易获得预算。

可业务不会因为平台功能齐全就自动来用。

如果一个新需求走原来的项目流程只要两周，接入中台反而先填表、申请、等排期，业务会继续绕开平台。数据团队说这是治理，业务觉得只是多了一道门。

反过来，如果平台为了拉使用量什么都接，所有临时口径都变成公共资产，没多久又会堆成另一片没人敢动的旧系统。

中台难就难在这里：它既不能只当基础设施，也不能变成一个接单部门。它必须知道哪些能力值得复用，还得有权推动业务真的使用。

这已经不只是技术架构问题。

阿里后来也在调整

把中台说成一场彻底失败，并不公平。

它解决过真实的重复建设问题，也帮助很多团队建立了平台化和资产复用意识。今天大家习惯谈公共数据模型、指标服务、数据产品，其中有不少思路正是在那一轮被普及。

但把中台当作一劳永逸的组织答案，同样站不住。

2023 年阿里巴巴启动新的组织变革时，官方提到集团中后台将做轻、做薄，让部分能力被更有力的前台吸收。这不等于宣布过去全部错误，更像是在承认一个长期存在的摆动：集中可以复用，分散可以响应；平台太弱，大家重复造轮子，平台太强，前台又觉得被拖慢。

没有一个组织结构能把这个矛盾永久消灭。

技术人喜欢画一张稳定架构图，企业却一直在变化。业务增长时希望放权，成本上升时又想集中；新业务刚开始需要速度，规模起来以后又需要治理。

平台不是终点，只是一种阶段性的分工办法。

从“有没有”回到“值不值”

数据中台热的时候，很多项目争论的是有没有：有没有统一数据层，有没有指标平台，有没有资产目录，有没有服务市场。

老板最后问的却是另一件事：有了以后，经营到底哪里变了？

这不是老板不懂技术。恰恰是他把问题拉回了生意。

互联网公司容易回答，因为调用、行为和收入可能就在一条回路里。传统企业难一些，平台能力只是走到业务门口。门里面还有人要判断，有人要拍板，有人要改流程，也有人要承担失败。

我们用了很多年让企业变得可见，又用了很多年让数据能力可以复用。可“看见问题”和“解决问题”之间，仍然隔着一段路。

下一部要讲的，就是这段路为什么这么难走。

本章资料

场景说明：本章数据团队与传统企业场景为多类项目中常见矛盾的复合表达，不指向特定客户。