这两年数据中台很火，从互联网大厂到传统企业，都在谈数据中台，都在建数据中台。各种概念满天飞：数据资产化、数据服务化、数据治理、一数一源、指标平台，听起来都很美好。

我们团队也花了一年多时间搭建数据中台，从0到1建了数据仓库、指标平台、数据服务、数据治理体系。过程中踩了无数坑，熬了无数夜，有成功的经验，也有失败的教训。

本文不空谈概念，只记录数据中台建设过程中遇到的典型问题，包括数据质量、指标口径、架构设计、团队协作等方面。每个问题都是我们真实踩过的，每个解决方案都是用熬夜换来的。希望能给正在建或准备建数据中台的朋友一些参考。

一、先说说我们为什么建数据中台

在说踩坑之前，先简单说说我们为什么建数据中台。

我们公司业务线比较多，每个业务线都有自己的数据团队，各自建了自己的数据仓库。时间长了，问题越来越多：

  • 同一个指标，不同业务线算出来的结果不一样，老板开会的时候各说各的数，不知道该信谁
  • 数据重复开发，每个业务线都在算同样的用户画像、订单统计，浪费人力
  • 数据质量差，经常出现数据不准、数据延迟、字段缺失的问题，业务方不信任数据
  • 数据取数难，业务方想看个数据，要找数据团队提需求，等好几天才能拿到
  • 数据资产沉淀不下来，人员流动之后，很多数据逻辑没人知道

为了解决这些问题，公司决定建数据中台，统一数据标准、统一数据仓库、统一指标口径、统一数据服务，让数据真正成为资产，赋能业务。

理想很丰满，现实很骨感。真正开始建的时候，才发现坑比想象的多得多。

二、坑一：指标口径不统一，越统一越乱

这是数据中台建设中最核心、最头疼的问题，没有之一。

建数据中台的目标之一是"统一指标口径"，让同一个指标在全公司只有一个定义、一个数值。听起来很简单，不就是把大家的指标拉通对齐吗？但真正做起来，才发现这是一个无底洞。

我们踩过的坑：

刚开始的时候，我们拉了各个业务线的数据分析师，一起梳理指标口径。开了无数次会，吵了无数次架，终于把核心指标的口径统一了，写进了指标平台。

结果上线之后，问题来了：

  • 业务方说："这个'活跃用户'和我们以前用的不一样，我们以前的活跃用户是登录就算，你们这个是要停留超过30秒，数据对不上，我们不用。"
  • 运营说："这个'转化率'的分母是所有访问用户，但我们的转化率分母是加购用户，你们这个口径不符合我们的业务场景。"
  • 财务说："这个'GMV'的统计范围和财务系统对不上，财务要扣除退款和优惠券，你们这个没扣，不能用。"

统一了口径之后，反而没人用了。因为每个业务线的业务场景不同，对同一个指标的定义本来就不一样，强行统一成一个口径，结果就是谁都觉得不符合自己的需求。

我们的解决方案：

后来我们调整了思路，不再追求"一个指标全公司只有一个定义"，而是建立了"指标分层"体系：

  1. 原子指标：最基础的指标，定义明确，没有歧义，比如"订单数""支付金额""用户数"。这些指标是统一的，全公司只有一个定义。
  2. 派生指标：在原子指标的基础上，加上维度、过滤条件、计算方式，比如"近7天活跃用户数""APP端支付转化率""新用户首单金额"。派生指标可以有多个，根据业务场景不同而不同。
  3. 业务指标：各个业务线自己的业务指标，在派生指标的基础上进一步加工，满足特定业务场景的需求。

这样一来，底层的原子指标是统一的，保证了数据来源的一致性；上层的派生指标和业务指标是灵活的，可以满足不同业务场景的需求。既保证了"一数一源"，又兼顾了业务的多样性。

同时，我们在指标平台上明确标注了每个指标的口径、计算逻辑、数据来源、负责人，业务方可以清楚地知道每个指标是怎么算出来的，选择适合自己的指标。

这个调整之后，指标平台的使用率明显提升，业务方的抱怨也少了很多。

经验总结： 指标口径统一不是"一刀切"，而是要分层。底层统一，上层灵活。不要试图用一个指标满足所有业务场景，那是不可能的。

三、坑二：数据质量问题，救火救到崩溃

数据质量是数据中台的生命线，数据不准，一切都是白搭。但数据质量问题，是我们熬夜最多的地方。

我们踩过的坑：

数据中台刚上线的时候，数据质量问题层出不穷：

  • 上游业务系统改了字段，没通知数据团队，ETL任务跑出来的数据全错了，业务方用了一天才发现
  • 某个ETL任务失败了，没有告警，第二天早上业务方发现数据没更新，才知道任务挂了
  • 数据重复了，因为上游系统重发了数据，ETL没有去重，导致指标翻倍
  • 数据延迟了，因为上游数据导出慢了，ETL等不到数据，一直卡住，早上8点该出的数据到中午才出
  • 维度关联错了，因为某个编码字段上游改了编码规则，关联出来的数据全是null

那段时间，我们团队基本上是"救火队"，每天都在处理各种数据质量问题，经常熬夜修数据。业务方对数据中台的信任度越来越低，甚至有人说"数据中台的数据还不如我自己Excel算的准"。

我们的解决方案：

痛定思痛，我们建立了一套完整的数据质量保障体系：

  1. 数据质量监控：对每一张核心表、每一个核心指标，都配置了数据质量监控规则，包括：

- 完整性监控：字段空值率、数据量波动 - 准确性监控：指标波动范围、和上游系统对账 - 及时性监控：任务完成时间、数据产出时间 - 一致性监控：不同表之间相同指标的一致性 监控发现异常立刻告警，通过短信、邮件、企业微信通知到负责人。

  1. 数据血缘追踪：建立了完整的数据血缘体系，从上游业务系统到数据仓库各层，再到指标和报表，每一个数据的来龙去脉都清清楚楚。出了问题可以快速定位影响范围，追溯到源头。
  1. 变更管理流程：上游业务系统的表结构变更、字段变更、编码规则变更，必须提前通知数据团队，评估对数据中台的影响，制定应对方案，才能上线。变更之后要验证数据是否正常。
  1. 数据回滚机制：每一批数据入库之前，先做质量校验，校验不通过就不入库，保留上一批正确的数据。如果已经入库了才发现问题，可以快速回滚到上一个正确的版本，避免错误数据被业务方使用。
  1. 数据质量报告：每周出一份数据质量报告，统计本周数据质量问题、影响范围、处理情况、改进措施，让团队和管理层都知道数据质量的状况，推动问题的解决。

建立了这套体系之后，数据质量问题明显减少，从以前的每周十几个问题，降到了现在的每月两三个。业务方对数据的信任度也慢慢恢复了。

经验总结： 数据质量不是靠人盯出来的，是靠体系保障出来的。监控、血缘、流程、回滚，一个都不能少。数据质量建设要趁早，不要等出了大问题才开始做。

四、坑三：架构设计，过度设计和设计不足并存

数据中台的架构设计，是另一个让人头疼的问题。我们在这上面走了两个极端：一开始过度设计，后来又设计不足。

过度设计的坑：

刚开始建数据中台的时候，我们想做得"高大上"，参考了各种大厂的架构，设计了一套非常复杂的架构：

  • 数据仓库分了五层：ODS、DWD、DWS、ADS、DIM，每一层都有严格的规范
  • 搞了实时和离线两套体系，Lambda架构，实时用Flink，离线用Spark
  • 数据服务搞了微服务，每个数据域一个服务，服务之间互相调用
  • 搞了数据资产目录、数据标签体系、数据沙箱、数据开发平台，各种系统一大堆

结果呢？架构太复杂了，团队根本维护不过来。

  • 五层数据仓库，很多表不知道该放哪一层，规范执行不下去，最后乱了
  • 实时和离线两套体系，同一个指标要写两套代码，维护成本翻倍，而且实时和离线的数据经常对不上
  • 微服务拆分太细，服务之间调用关系复杂，出了问题排查半天，性能也不好
  • 各种系统一大堆，每个系统都要有人维护，团队人手不够，很多系统半吊子，没人用

那段时间，团队大部分精力都花在维护复杂的架构上，反而没有时间去做真正有价值的事情，比如数据治理、指标建设、业务赋能。

设计不足的坑：

后来我们意识到过度设计的问题，开始做减法，把架构简化了。但简化的时候又走了另一个极端，设计不足。

  • 数据仓库从五层简化成了三层，但没有明确的规范，大家随便建表，表名、字段名、分层都很乱
  • 实时和离线合并了，但合并的方式很粗糙，有些实时任务直接写离线表，导致数据冲突
  • 数据服务从微服务改成了单体服务，但没有做好模块化，代码耦合严重，改一个地方影响一片
  • 砍掉了一些"不重要"的系统，比如数据血缘、数据质量监控，后来发现这些系统是刚需，又得重新建

我们的最终方案：

经过反复折腾，我们终于找到了一个平衡点：

  1. 数据仓库分三层：ODS（贴源层）、DWD（明细层）、ADS（应用层）。不再搞那么多层，简单清晰。DWD层做统一的清洗和标准化，ADS层面向业务场景做加工。维度表单独管理，不单独分层。
  1. 实时离线一体化：采用流批一体的架构，用Flink同时处理实时和离线任务，同一套代码、同一套逻辑，保证实时和离线数据的一致性。实时数据写入实时表，离线数据写入离线表，通过统一的数据服务层合并，对下游透明。
  1. 数据服务模块化单体：不搞微服务，用模块化的单体架构，按数据域划分模块，模块之间通过内部接口调用，降低耦合。部署简单，维护方便，性能也好。等以后规模大了，再考虑拆微服务。
  1. 核心系统必须有：数据血缘、数据质量监控、指标平台、数据开发平台，这些是数据中台的核心系统，必须有，而且要做好。其他锦上添花的系统，根据团队能力和业务需求，有精力再做，没有精力就先不做。
  1. 架构演进式发展：不追求一步到位，先做最小可用版本，跑通核心流程，然后根据业务需求和团队能力，逐步演进、逐步完善。每一步都要能落地、能产生价值，不要为了架构而架构。

调整之后，架构简单清晰了很多，团队的维护成本降下来了，有更多精力去做业务赋能的事情。

经验总结： 数据中台架构不要追求大而全，要适合自己的团队和业务。过度设计比设计不足更可怕，因为过度设计会消耗大量的维护成本，让团队疲于奔命。先做最小可用版本，再逐步演进，是更务实的做法。

五、坑四：团队协作，数据中台不是数据团队一个人的事

数据中台建设涉及到很多团队：数据团队、业务团队、后端开发、产品、测试，团队协作是个大问题。

我们踩过的坑：

  1. 业务团队不配合：数据中台需要业务团队提供业务逻辑、确认指标口径、配合数据校验，但很多业务团队觉得数据中台是数据团队的事，和自己没关系，不配合。问他们业务逻辑，说"你们自己看代码"；让他们确认指标口径，说"你们定就行"；数据出了问题，又说"数据中台怎么这么不靠谱"。
  1. 后端开发不重视数据：后端开发在做业务系统的时候，只考虑业务功能，不考虑数据怎么统计。字段设计不合理、没有状态变更日志、关键操作没有记录、数据删除不做软删除，这些都给数据统计带来了很大困难。等数据团队发现问题去找后端，后端说"业务系统已经上线了，改不了"。
  1. 数据团队内部沟通不畅：数据团队内部，数据开发、数据分析师、算法工程师、数据产品经理，各干各的，沟通不够。数据开发建的表，分析师不知道；分析师提的需求，开发不理解；算法用的数据，和报表用的数据对不上。
  1. 需求管理混乱：业务方提需求很随意，今天要这个报表，明天要那个指标，需求变来变去。数据团队没有统一的需求管理流程，谁喊得凶就先做谁的，优先级混乱，很多需求做了一半又改，浪费人力。

我们的解决方案：

  1. 争取高层支持：数据中台是"一把手工程"，没有高层的支持，根本推不动。我们花了很多时间和管理层沟通，让管理层理解数据中台的价值和难度，争取到了高层的支持。高层在各种会议上强调数据中台的重要性，要求各业务团队配合，这给了我们很大的帮助。
  1. 建立跨团队协作机制：成立了数据中台虚拟项目组，成员包括数据团队、各业务线的接口人、后端开发代表、产品代表。定期开会，同步进展，讨论问题，协调资源。每个业务线都有专门的数据接口人，负责和数据团队对接，确认业务逻辑和指标口径。
  1. 推动数据意识建设：在公司内部做数据培训，给业务团队和后端开发讲数据中台的价值、数据统计的原理、为什么要重视数据设计。让大家理解，数据不是数据团队一个人的事，是全公司的事。后端开发在设计表结构的时候，要考虑数据统计的需求；业务团队在定义指标的时候，要和数据团队一起确认口径。
  1. 建立需求管理流程：建立了统一的需求提报和管理流程，所有数据需求都要通过统一的渠道提报，经过评估、排期、开发、测试、上线，全流程跟踪。需求优先级根据业务价值和紧急程度来定，不是谁喊得凶就先做谁的。需求变更也要走流程，评估影响之后再决定是否变更。
  1. 数据团队内部加强沟通：数据团队内部建立了定期的沟通机制，每周开一次周会，同步各自的工作，讨论遇到的问题。建立了统一的文档库，所有的表结构、指标口径、业务逻辑、开发规范，都写在文档里，大家共享。重要的设计和决策，集体讨论，避免一个人拍脑袋。

经验总结： 数据中台不只是技术项目，更是组织和文化项目。技术再好，团队协作跟不上，也做不成。争取高层支持、建立协作机制、推动数据意识建设，这些和技术建设一样重要。

六、坑五：价值衡量，做了很多事但说不清价值

这是一个很现实的问题：数据中台做了一年多，投入了很多人力物力，但怎么衡量它的价值？怎么向管理层证明这些投入是值得的？

我们踩过的坑：

刚开始的时候，我们没有想清楚怎么衡量数据中台的价值，只是埋头做事。建了数据仓库、做了指标平台、搞了数据治理，觉得做了很多事。

但到了年底复盘的时候，管理层问："数据中台投入了这么多，带来了什么价值？"我们答不上来。

  • 说"数据质量提升了"，但没有具体的数据，以前多少问题，现在多少问题，说不清楚
  • 说"取数效率提高了"，但没有统计，以前取数要多久，现在要多久，省了多少人力，说不清楚
  • 说"赋能了业务"，但没有案例，哪个业务因为用了数据中台的数据，提升了多少业绩，说不清楚
  • 说"沉淀了数据资产"，但数据资产值多少钱，怎么量化，说不清楚

管理层听了之后很不满意，觉得数据中台是"自嗨"，投入产出不清晰。第二年的预算审批也遇到了困难。

我们的解决方案：

后来我们认真思考了数据中台的价值衡量问题，建立了一套价值衡量体系：

  1. 效率价值：衡量数据中台提升了多少效率。

- 取数效率：统计业务方自助取数的比例，以及平均取数时间。以前业务方取数要找数据团队，平均3天；现在通过指标平台自助取数，平均10分钟。效率提升了多少，一目了然。 - 开发效率：统计数据需求的平均开发周期。以前一个需求从开发到上线平均5天，现在因为有了统一的数据仓库和指标平台，平均2天。开发效率提升了多少，可以量化。 - 人力节省：统计数据团队因为数据中台节省了多少重复开发的人力，可以投入到更有价值的事情上。

  1. 质量价值：衡量数据中台提升了多少数据质量。

- 数据质量问题数：统计每月数据质量问题的数量，从以前的每月十几个，降到现在的两三个。 - 数据准确率：抽样统计核心指标的准确率，从以前的90%提升到现在的99%。 - 数据及时性：统计核心数据的产出时间，从以前的上午10点，提前到现在的早上6点。

  1. 业务价值：衡量数据中台对业务的实际贡献。

- 业务案例：收集因为使用数据中台的数据而带来业务提升的案例。比如，运营团队通过指标平台实时监控活动数据，及时调整策略，活动转化率提升了15%；产品团队通过用户行为数据优化了产品流程，用户留存提升了8%。每个案例都有具体的数据支撑。 - 业务覆盖：统计有多少业务团队在使用数据中台的数据，使用频率如何，覆盖了哪些业务场景。 - 用户满意度：定期做用户满意度调研，了解业务方对数据中台的满意度和改进建议。

  1. 资产价值：衡量数据中台沉淀了多少数据资产。

- 数据资产目录：统计数据中台有多少张表、多少个指标、多少个数据服务，覆盖了哪些业务域。 - 数据复用率：统计数据资产的复用情况，有多少数据被多个业务场景使用，避免了重复开发。 - 知识沉淀：统计数据中台沉淀了多少文档、规范、方法论，这些是团队的知识资产。

建立了这套价值衡量体系之后，我们每个季度都会出一份数据中台价值报告，用数据说话，向管理层展示数据中台的价值。管理层对数据中台的认可度明显提升，预算审批也顺利了很多。

经验总结： 做数据中台，不能只埋头做事，还要抬头看路，想清楚怎么衡量价值。价值衡量不是为了邀功，而是为了明确方向，知道哪些事情有价值，哪些事情是白忙活。用数据证明数据的价值，是数据团队的基本功。

七、给准备建数据中台的朋友的建议

说了这么多坑，最后给准备建数据中台的朋友一些建议：

  1. 想清楚为什么建：在建数据中台之前，先想清楚你们公司为什么要建数据中台，要解决什么问题，目标是什么。不要因为"大家都在建"就跟风建，也不要因为"概念很火"就盲目建。没有明确的目标，建到一半就会迷失方向。
  1. 从小处着手，不要贪大求全：不要一开始就想建一个大而全的数据中台，覆盖所有业务、所有场景。先选一个业务线、几个核心场景，做最小可用版本，跑通流程，验证价值，然后再逐步扩展。小步快跑，快速迭代，比一步到位更靠谱。
  1. 重视数据治理，不要只做技术建设：数据中台的核心不是技术，而是数据治理。数据质量、指标口径、数据标准、数据血缘，这些治理工作比搭技术架构更重要，也更难。不要把大部分精力都花在技术架构上，而忽视了数据治理。
  1. 争取业务团队的参与，不要数据团队单打独斗：数据中台不是数据团队一个人的事，需要业务团队的深度参与。从一开始就要让业务团队参与进来，一起定义指标、确认口径、验证数据。没有业务团队的参与，数据中台建出来也没人用。
  1. 建立价值衡量体系，用数据证明价值：从第一天开始，就要想清楚怎么衡量数据中台的价值，建立价值衡量体系。定期向管理层和业务方展示数据中台的价值，争取更多的支持和资源。不要等做了一年多才想起来要证明价值。
  1. 做好长期作战的准备：数据中台建设不是一朝一夕的事情，是一个长期的过程。不要期望三个月半年就能建成，要有长期作战的准备。在这个过程中，会遇到各种困难和挑战，要有耐心，要有韧性，一步一个脚印地往前走。

八、写在最后

数据中台是一个好东西，但它不是银弹，不能解决所有问题。它更像是一个基础设施，建好之后能让数据的流通更顺畅、数据的使用更高效、数据的价值更容易释放。但建的过程很艰难，需要技术、组织、文化多方面的配合。

我们团队花了一年多时间，踩了无数坑，熬了无数夜，才把数据中台初步建起来，跑通了核心流程，得到了业务方的认可。现在回头看，那些熬夜踩坑的经历，都是宝贵的财富。

本文记录的这些坑，只是其中的一部分，还有很多细节没有展开。希望这些经验能给正在建或准备建数据中台的朋友一些参考，让你们少走一些弯路，少熬一些夜。

最后用一句话结束本文：数据中台建设，道阻且长，行则将至。愿每一个数据人都能在踩坑中成长，在建设中收获价值。