沃尔沃拆出一家公司，数据系统崩了3年才搞懂

一个做发动机的老牌制造商，被母公司切割后，才发现自己连数据仓库都租不起——这种剧情，放在云计算时代是不是有点魔幻？

Anurag Kale在InfoQ慕尼黑峰会上讲了个故事：Horse Powertrain（马动力传动系统公司）从沃尔沃汽车拆分独立后，被迫在3年内从零搭建了一套数据网格（Data Mesh）架构。没有现成的数据中台，没有母公司的AWS账号，只有Azure和一堆亟待回答的业务问题。

1. 为什么"数据中台"成了新公司的第一个坑

拆分前的Horse Powertrain习惯了"饭来张口"——数据分析师向沃尔沃总部提需求，几周后报表送到。独立后，这套保姆式服务断了，而业务部门的提问速度翻了十倍：这台发动机的故障率曲线呢？那个变速箱的供应链瓶颈在哪？

传统的中央数据团队成了单点瓶颈。 Kale打了个比方：以前像去餐厅点菜，现在要自己种地、养猪、开灶。中央团队排期三个月才能交付的需求，产线经理等不了三天。

更麻烦的是组织惯性。工程师们习惯了"数据是别人的事"，业务专家懂流程但不懂SQL，IT团队懂管道但不懂发动机。Kale的团队试过强化中央团队，结果是人越招越多，队列越来越长——典型的"用人力填架构的坑"。

2. 数据网格的四个柱子，哪根最难打

Data Mesh的核心是四根柱子：领域所有权、数据即产品、自助服务平台、联邦治理。Kale说他们在Horse Powertrain的实践里，最难的不是技术，是让业务团队相信"数据归你管"这件事。

第一根柱子"领域所有权"要求把数据责任下沉到业务域。发动机团队管发动机数据，变速箱团队管变速箱数据。听起来合理，执行时却遭遇沉默抵抗——"我们是造发动机的，不是搞数据的。"

Kale的解法是用领域驱动设计（DDD）做桥梁。先不聊数据，先聊业务边界：你们这个"发动机性能分析"子域，到底包含哪些实体？事件？聚合根？把业务语言理顺后，数据所有权自然浮出水面。换句话说，这不是IT项目，是组织重构。

第二根"数据即产品"更扎心。Kale要求每个领域把数据集当产品运营——要有文档、有SLA、有版本管理、有用户反馈渠道。一个产线工程师的吐槽很典型："我以前Excel丢共享盘就行，现在要我写产品说明书？"

但三个月后，这位工程师成了最积极的推广者。因为他的"产品"被三个其他团队订阅，他第一次在公司内部有了"客户"视角。

3. 自助平台：别让工具成为新瓶颈

第三根柱子"自助服务平台"是Kale投入最深的部分。他的信条：平台团队存在的意义是让用户忘记平台团队的存在。

Horse Powertrain选了Azure作为基础设施（尽管Kale本人是AWS Data Hero）。平台层抽象了数据摄取、存储、计算、治理的复杂度，暴露给领域团队的接口极度克制：上传数据、定义schema、设置访问策略，三步完成。

Kale展示了他们的平台工程实践——基础设施即代码（IaC）、GitOps工作流、可复用的Terraform模块。一个领域团队从申请资源到产出第一个数据集，从原来的6周压缩到2天。

但自助不等于放任。平台内置了硬性约束：数据必须带业务元数据、必须注册到数据目录、必须满足基础质量检查。Kale称之为"有护栏的自主"——你可以开快车，但得系安全带。

4. 联邦治理：最难的是"不做什么"

第四根柱子"联邦治理"最容易被误解为"中央管控的变种"。Kale强调区别：中央治理是"我定规则你执行"，联邦治理是"共同商定规则，各自负责执行"。

实践中的关键决策是划定边界。哪些必须全局统一？数据安全策略、公司级主数据定义、跨域数据契约格式。哪些可以领域自治？字段命名习惯、内部数据模型、分析工具选型。

Kale分享了一个踩坑案例：早期他们试图统一所有数据产品的文档格式，结果陷入无穷尽的评审会议。后来改为"必须包含这5个字段，其余自由发挥"，效率陡升。治理的精髓是减少协调成本，而非增加。

5. 三年后的账单：值不值

演讲末尾，Kale给了组对比数字。实施Data Mesh前，Horse Powertrain的数据需求交付周期中位数是11周，现在降至4天；数据产品数量从个位数增长到200+；最意外的是，平台团队规模反而缩小了——从15人减到8人，因为大量工作被自助化和自动化吸收。

但Kale没有渲染胜利。他提到仍在挣扎的问题：老旧系统的数据如何纳入网格？如何量化"数据质量"的投资回报？当业务团队 churn 率高时，领域知识如何传承？

演讲结束后有人问他：如果重来一次，最先做什么？Kale的回答带着产品经理式的冷幽默："先确认老板真的想要分布式，而不是只想让IT背锅更快一点。"