数据中台是什么？从OneData到数据服务，讲透中台建设本质

1. 为什么大家都在聊数据中台——先搞清楚它到底在解决什么坏问题我最早听到数据中台这个词是2019年前后。当时所在的公司刚完成一轮数字化转型规划CTO在年度大会上拍了板说我们要建数据中台。台下各部门负责人表情各异但没人敢问数据中台究竟是什么它和我们已经用了五年的大数据平台有什么区别这个问题在当时说实话真正能讲清楚的人不多。连很多做数据的老兵第一次听到这个名词第一反应也是换了个新瓶子。直到我自己完整走完一个中台项目从0到1的建设过程踩过调研、建模、治理、服务化各个阶段的坑才慢慢明白数据中台这个词虽然被市场炒作得厉害但它背后确实有一组清晰的、有别于传统数仓建设的核心问题需要解决。先把话说在前面数据中台不是一套软件不是一个平台不是一个部门它本质上是一套通过组织机制和技术工具把数据变成可持续复用、可治理、可服务化的企业能力的建设方法。这句话是全文的底色后面所有章节都是它的展开。1.1 报表做不完、口径对不齐传统数据建设的三座大山想理解数据中台建议先回到最原始的业务痛点。我服务过的一家零售企业年营收大概在几十亿规模IT部门下设一个数据组满编只有12个人。每天打开工作群看到的请求大概长这样数据组同学帮我拉一下上周华东区各门店的销售明细要Excel。咚咚昨天的实时销售大屏怎么数据没更新月度经营分析会要开了各BU的GMV口径麻烦核对一下还有XX部门的离职率报表什么时候给你注意看这些需求里销售GMV门店这些词反复出现但实际上每一次提需求的业务方对同一个词的理解都不一样。市场部说的GMV是订单原价口径财务部说的GMV是扣除退货退款后的实收口径运营部说的GMV又要剔除刷单和测试订单。数据组每次都要挨个跟业务确认一遍然后手工在SQL里写一堆过滤条件。这种情况下哪怕底层数据是准确的顶层报表也一定是一团乱麻。更致命的是每次对接新业务或者新项目历史数据模型根本没法直接复用ETL脚本改来改去数据组的大部分人力都被这种低水平重复消耗掉了。这就是传统数据建设经常遇到的三座大山第一座山烟囱式建设。每个业务系统、每个部门、甚至每个报表需求都独立抽取数据、独立建表、独立加工。同一个客户活跃概念在三个系统中可能有三种不同的SQL查询逻辑。从全局看数据链路纵横交错、接口混乱运维人员根本说不出某张报表的数据来源是谁。第二座山指标口径混乱。同样一个销售额财务口径、运营口径、管理层口径天然有差异但传统模式没有机制去统一维护这些口径定义各个报表各说各话开会的时候大家吵的不是业务问题而是你的数跟我的数为什么对不上。第三座山数据资产无人负责。数据模型是谁建的、建完有没有人在用、用的人知不知道它的准确度、它的血缘清楚不清楚——这些在传统模式下几乎没人专门管理。我见过很多公司的数仓底层表几百上千张将近一半是没人知道用途的孤儿表但大家都不敢删因为删了万一哪天某个报表挂了背锅的就是自己。这三座山综合起来造成的实际后果就是数据组常年疲于接单业务满意度却一直垫底管理层想看一个统一的经营全景永远要等几天才可能拿到一份各方都不完全认可的数字。等数据量越来越大、业务变化越来越快这套模式必然走向崩溃。数据中台这个概念的兴起本质上就是对这种集体痛苦的一次系统性回应。1.2 数据中台的本质定位不是技术平台是组织协同机制很多人把数据中台当成一个技术架构名词实际上它更接近一个组织和管理学名词。业界流传比较广的一个说法是中台是一种组织机制而不是一套系统。我非常认可这个判断但需要补充一点如果完全没有工具承载这套机制就会退化成又厚又没人看的规范文档。所以数据中台必须同时解决组织怎么协同和工具怎么支撑两个问题。从组织协同的角度看数据中台要把原本散落在各个业务线、各个部门的数据建设角色——比如数据工程师、数据分析师、BI工程师——部分地抽出来形成一个横向的、服务于全公司的数据团队。这个团队的核心KPI不是交了多少张报表而是沉淀了多少可复用的数据资产支撑了多少业务场景。注意这个KPI的转移它是中台和传统数据部门的根本区别。从工具支撑的角度看中台需要一套覆盖数据采集、数据开发、数据治理、数据服务的全链路平台能力让数据团队能够以较低成本完成标准化建模、口径管理、质量监控和API发布。工具层面的中台化目标只有一个把数据建设从项目制变成产品制。1.3 什么情况下引入数据中台才是合理的数据中台不是万能药这一点必须泼盆冷水。如果你的公司还处于每天数据量只有几十GB、业务部门不到十个、报表需求一只手数得过来的阶段那郑重建议你先别碰中台这个词老老实实把数仓规范做好就够了。中台的投入产出比在数据基础薄弱、组织协同意愿不强的公司里会非常难看。那么什么阶段适合启动我个人总结了三个信号信号一多个业务线比如三条以上都开始按各自的思路建设数据体系公司层面的口径对齐成本已经高到难以忍受。信号二相同或高度相近的数据需求在不同部门被重复开发和加工了不止一遍你明显感觉这活好像到处都在干。信号三管理层对数据的需求已经从看报表升级为用数据辅助决策和运营但现有数据体系完全无法跟上这种需求和变化。当这三个信号同时出现说明组织已经为数据中台准备好了业务土壤。这时候讨论中台建设才是有意义的事。2. 定义数据中台OneData、OneService与数据治理的三位一体说清楚了背景我们来正面回答数据中台到底是什么。我给过一个自己一直在用的定义数据中台是围绕数据资产以OneData方法论统一数据标准与模型以OneService方法论统一数据服务出口并依靠贯穿始终的数据治理机制保障数据质量与安全的可持续建设体系。这一定义里有三个关键词值得逐字拆解。2.1 三段式定义OneData、OneService与治理体系OneData核心解决的是数据怎么组织的问题。它要求企业基于统一的视角对全域数据进行主题域划分、指标体系设计、模型分层建设和规范约束。举个例子同样是用户这个概念电商业务可能叫customer会员业务可能叫member客服系统可能叫account在OneData方法论下这些分散的定义会被收敛到一个统一的客户主题域生成唯一的客户主数据模型和全局唯一的客户ID。后续所有分析、所有报表、所有应用只要涉及客户都从这套统一模型取数。OneService核心解决的是数据怎么被用的问题。它要求所有数据能力通过统一的、标准化的服务接口对外输出而不是让各个业务方直接绕过中台去提数、连库、跑SQL。数据被封装成API或者逻辑视图统一鉴权、统一限流、统一审计消费者不需要关心数据在哪里、底层怎么存储只要按照约定好的接口规范取数即可。OneService不是简单的数据API网关它更重要的工作是把口径和模型下沉到服务层消费者拿到的一定是经过统一口径处理的结果。数据治理不是某一个模块而是贯穿在采集、建模、加工、服务全生命周期里的常态化行为。具体包括元数据管理和血缘追踪解决数据从哪来、到哪去数据质量规则解决数据是不是可信的数据安全和权限管控解决谁可以看什么、用到什么程度。没有治理体系加持的OneData和OneService短期可能很快见效但时间一长模型会重新变乱服务口径会重新分叉。2.2 数据中台不是软件产品而是一套建设方法市面上的数据中台产品五花八门厂商们喜欢把中台打包成一堆功能组件数据集成、数据开发、数据资产、数据服务、数据质量管理、数据安全中心……听起来买了这套平台就等于建了中台。我见过不少企业踩过这个坑花了上千万买了一整套商业产品结果半年后除了BI报表切换了工具业务部门并没有感觉到任何实质改变。为什么因为中台最核心的部分——统一模型、统一指标、统一服务——不是靠某个产品就能自动生成的。厂商平台提供的只是生产工具和规范模板真正的中台内容需要你对自己公司的业务全域做一次又深又透的梳理然后由数据团队一点一点地构建出来。打个比方买了一套顶级精装修工具不等于你拥有了一栋装修好的房子房子还得你一块砖一块瓦地盖。工具只是加速器不等于最终交付物。所以我的判断一向是选择数据中台平台重点看三件事——是否支持完善的数据模型管理、是否具备灵活的指标注册与口径配置能力、数据服务发布与管控是否足够简单。至于那些炫酷的数据可视化大屏、花哨的AI算法模块不是不可以但绝对不是选型时的核心决策项。2.3 中台的边界哪些数据往里放哪些不该往里放中台被滥用的另一大现象是什么都往里装。一些企业把所有数据一股脑采集进来不管有没有用、不管有没有人去消费先建了再说。这种做法最后基本都会拖垮整个中台项目因为资产数量一多治理成本指数级上升但又没人能说清楚这些资产到底值不值得沉淀。建中台之前先立两条边界规矩业务边界只有跨业务线共用的高频数据才值得放入中台公共层。某个业务线内部独有、其他团队基本不会用到的数据留在业务线自己的数仓里即可没必要上升到中台层面。价值边界判断一个数据资产是否纳入中台可以问一句如果把它统一建模、统一服务未来一年能省掉多少重复开发和口径对不齐的沟通成本。省不了多少的优先级往后放。中台建设资源永远是稀缺的把资源投入到复用率最高的数据域上回报最好。3. 从数据源到数据服务——数据中台核心链路拆解想动手规划一套数据中台脑子里先要有一张清晰的链路图。这张图我从实践者的视角用四段来描述采集、开发、治理、服务。每一段都有对应的核心任务和常见工具选择下面逐个讲透。3.1 数据采集实时与批量同步怎么做取舍数据中台的底座是数据采集。很多人低估这一环节的复杂度觉得不就是把数据库的数据抽过来吗实际做起来要考虑的问题很多源端类型五花八门关系型数据库、消息队列、日志文件、第三方API、SaaS应用同步延迟要求各不相同T1、分钟级、秒级对源库的压力限制各有差异。从同步方式上主流选择可以分成三类同步方式适用场景典型工具注意事项批量抽取离线数仓、T1报表DataX、Sqoop对源库压力较大尽量避开业务高峰实时流同步监控大屏、实时风控Flink CDC、Canal、Debezium需要评估日志解析对源库的影响消息队列接入埋点日志、系统事件Kafka、Pulsar需要统一消息格式规范实操中我强烈建议不要一上来就追求全链路实时化。实时链路的运维成本、数据一致性处理成本都比离线链路高一个量级。初期阶段优先保证离线链路稳定可靠把业务实时性要求最明确的少数场景拿出来单独做实时同步这样投入产出比最高。另外采集环节别忘了源端变更的问题。业务系统的表结构不是一成不变的一旦源端字段调整下游同步任务极容易挂掉或者产出脏数据。成熟的实践是给每个采集任务配置结构变更告警并且所有同步任务必须做到字段可映射变更可追溯。3.2 数据开发与建模分层架构和维度建模怎么落到中台里采集完的数据经过清洗处理后进入数据公共层。公共层的设计是数据中台最见功力的地方。业界最成熟的做法是参考阿里巴巴在OneData方法论中提出的分层架构ODS层贴源层与源系统结构保持一致的原始数据落地区做好全量/增量分区管理原则上只做照搬不做转换。DWD层明细层以业务过程为核心进行清洗、去重、维度退化、规范化处理后的明细数据这一层是事实的真相层。DWS层汇总层按主题如销售主题、流量主题、会员主题进行轻度汇总面向通用分析场景提供服务。DWS层要尽量减少开发了一张汇总表却只服务一个报表的情况。ADS层应用层面向具体应用和报表需求的个性化数据属于冗余度最高的层原则上尽量少放避免烂尾脏表积累。这套分层本身并不复杂复杂的是在分层内部如何做到模型复用度最大和口径统一成本最小。我的核心体会是DWD和DWS层一定要做宽表化和主题化并且做之前先拉一个全局的维度字典和指标体系。比如门店维度、时间维度、商品维度、员工维度这些公共维度先统一建模保证每个事实表关联出来都是同一套维度属性。否则各团队自己建维度表内部编码都不同后面做关联分析会非常痛苦。维度建模上星型模型是最推荐的中台建模模式。它足够直观业务人员理解成本低查询性能也较好。那些复杂的雪花模型、高度规范化的3NF模型在维护成本和查询效率上都不太适合大规模分析场景中台建设里要克制使用的冲动。3.3 数据治理元数据、血缘、质量、安全四件事数据治理是最容易被低估、也最容易被形式化的环节。很多人觉得治理就是写规范、贴标签、上权限做完之后束之高阁。实际一个有生命力的治理体系必须嵌在数据开发的核心链路里让治理行为本身不成为开发者的负担。元数据管理是最基础的。一张表是谁建的、有什么字段、字段的业务含义是什么、属于哪个主题域、负责人是谁——这些信息必须随着建模动作同步登记。我见过有些团队把元数据录入当成额外负担拖到最后全部堆在月末补录补录质量又差最后血缘也画不清、影响分析也做不了治理体系名存实亡。正确做法是把元数据采集嵌入到数据开发平台中表结构变更、任务提交时自动更新元数据人是次要的机制才是主要的。血缘分析解决的是数据从哪里来、到哪里去的问题。做字段级血缘也好、表级血缘也好核心目的是支撑三个日常场景某个上游字段变更了下游哪些表和任务会受影响出报表时数据有异常能不能快速从结果反查到底哪个环节出了问题每年数据治理盘点时哪些表是无人消费的僵尸表。血缘能力做扎实之后中台运维效率会有质的提升。数据质量方面不用一开始追求复杂的质量规则引擎先把四类最基本的质量场景覆盖了数据完整性空值率、缺失率、准确性数值阈值、枚举值校验、一致性跨表同一口径比对、及时性任务是否按时产出。质量规则要做到让数据开发在提交任务时自行配置并且质量结果要跟任务调度状态联动——质量不过关不向下游开放。再来说安全和权限管理。中台服务全公司数据权限必须细到表和字段级别尤其是经营核心数据建议对敏感字段做脱敏处理后再开放给低权限角色。权限的申请流程也要尽量自动化、可审计避免申请靠邮件、审批靠催的低效状态。3.4 数据服务把数据从取数变成要数数据中台和传统数仓在消费端最大的区别在于服务化程度。传统模式下业务方要数据一般走流程提需求给数据组数据组排期开发交付可能是一张表、一个文件、一个报表。这个过程往往要跨越数天甚至数周。中台模式想改变的是将沉淀好的公共数据封装成通过API、逻辑视图等方式提供的标准化数据服务业务方自助申请、即调即用。OneService落地的关键一环是对服务管理API做统一接入、鉴权、限流和监控。比如某数据服务单日调用量暴涨到某个阈值系统自动告警某个新业务要接入客户标签服务只需要申请权限、拿到Key、按文档调用即可不用在中台侧单独开发。数据服务化带来的直接收益是数据团队的工作模式从被动接单变成主动供给业务方自助取数的能力大幅提升数据部门的精力可以更多地放在新建模型、优化口径、挖掘更高质量的数据资产上。这里也提醒一句服务化早期不要急着包装几十上百个API选定5到10个高频、稳定的公共数据服务先跑起来形成标准范式后再横向铺开阻力会小很多。4. 别再混淆了数据中台、数据仓库、数据湖、BI到底是什么关系和中台这个词一起常常被摆上台面的还有数据仓库、数据湖、BI。它们经常出现在同一个PPT里很多人把它们当成同义词或者互相替代的选项但事实上它们解决的问题完全不是一个层面。这一章我把几个概念掰开说清楚。4.1 数据仓库是存储计算数据中台是能力服务数据仓库的核心价值是把分散在业务系统中的数据经过ETL处理后形成统一的、面向分析的结构化数据集合。它是一个技术层面的数据组织和处理体系。数据中台不是要替代数据仓库恰恰相反中台的公共层模型很大程度上建设在数仓技术之上。如果用一句话区分数据仓库回答的是一组技术问题数据怎么存、怎么算数据中台回答的则是一组管理问题数据怎么管、怎么服务。数仓是里子中台是面子和命脉两者是承继关系不是互斥关系。很多企业做中台的第一步其实是先把数仓的规范补齐模型分层、命名规范、调度治理。中台建设过程的一个重要组成部分就是把散落的数仓整合成一套规范化数仓。4.2 数据湖与中台的关系原始数据的大后方数据湖的思路是先把所有数据以原始格式结构化、半结构化、非结构化集中存储起来后续再按需解析和处理。数据湖的优点是开发门槛低、存储成本便宜能容纳各种格式的数据特别适合作为数据探索和实验的原料库。中台与数据湖的关系主要体现在中等前置环节。数据湖可以理解为中台体系的大后方源端数据先入湖湖里存着所有原始素材中台从湖里按需取材将高价值数据进行规范化建模后再放入中台公共层。两个体系可以非常自然地结合。需要注意的坑是数据湖如果缺乏治理非常容易变成数据沼泽——大量不知道内容是什么、原始格式千奇百怪的文件堆在廉价存储上既没人消费又占空间还让成本失去控制。所以如果你有数据湖务必配一份清晰的湖内目录归档和生命周期管理策略。4.3 BI与中台的关系消费端的一环BI商业智能指报表、多维分析、可视化看板等工具是数据消费的具体工具层。中台建设好了BI就是最主要的受益者和使用窗口之一。但BI本身不等于中台它也替代不了中台。比较常见的误区是企业引入一套新的BI工具挂上几个数据源画几个好看的大屏然后对外宣称自己建成了数据中台。这种项目一年后回头看不难发现底层数据链路没有任何改变口径混乱的老问题原封不动只是换了一层皮。数据中台带来的价值必须要在消费侧被感知到。BI是感知的出口之一但它绝不是中台的全部。真正的中台消费场景还包括算法模型、经营管理驾驶舱、移动端数据推送、嵌入业务流程的实时决策服务等等。5. 建设数据中台的第一步别急着买产品先做现状盘点和顶层设计每次听到我们决定上数据中台了下周厂商来招投标这种话我都想说慢一点先想清楚你要解决什么问题。中台项目失败率高排第一的原因往往不是技术选型而是业务和现状调研没有做到位顶层设计一塌糊涂就匆匆开工。5.1 现状盘点不是收集表格是理解业务现状盘点通常分成业务盘和技术盘两条线。业务盘的核心任务是摸清指标体系。把公司现有的重要业务报表收集齐按领域归堆然后逐一拆解每个核心指标的计算逻辑、数据来源、统计维度、负责人。你会发现一个非常残酷的现实同一指标在不同报表里的计算逻辑可能完全不同。这些差异就是后续中台建设要收编和统一的对象。业务访谈的建议是访谈对象不要只盯着各业务线的负责人一定要包含一线的运营和财务人员。因为他们才是真正在手工用Excel整理数据的人他们对数据不好用的感受最具体、最真实。访谈清单里务必包含这几个问题你最常使用的三张报表是什么这些报表里的数据你敢直接拿去决策吗不能直接用的时候你通常自己怎么修正多问几轮业务痛点自然会浮出来。技术盘要摸清现有数据资源。核心看四张清单数据源清单有哪些业务系统及其数据库、数据同步链路清单现在怎么取数、用的什么工具、数据存储和计算资源清单Hadoop集群规模、计算引擎、存储量、现有加工任务和报表清单数仓里有几张表哪些是活跃的哪些基本无人访问。技术盘点结果出来后中台建设的资源和工作量就有了初步的锚点。5.2 顶层设计主题域划分和指标体系是灵魂现状盘点完成后进入顶层设计。这一阶段产出的核心内容包括中台建设的目标范围、主题域模型、指标体系、数据分层规范和初步的治理框架。主题域划分建议以业务为视角而不是以系统为视角。例如一个零售企业可能会划分出客户域、商品域、门店域、渠道域、订单/交易域、营销域、供应链域、财务域等。每个主题域定义好边界、责任团队和数据模型规划。主题域的数量控制在8到12个以内就可以了不要搞出几十个域那样管理成本和协同难度都会非常高。指标体系的建设是顶层设计的重中之重。我的建议是建立一套三级指标管理结构——原子指标、派生指标、复合指标。原子指标不可再拆分的度量比如订单金额含税。派生指标在原子上叠加统计周期、统计粒度、业务限定后的指标比如华东区本周订单金额含税。复合指标多个指标间的运算比如毛利率复购率。所有核心指标都必须在指标字典中登记计算公式、数据来源、适用范围和更新频率并且全公司只能有一个权威定义。指标口径的统一是整个中台后续能不能让业务信得过的基石。5.3 团队与组织谁来建、谁来用、谁说了算启动中台建设前需要先把组织问题谈拢。我见过不少项目技术团队热热闹闹干了大半年但业务方始终觉得这是IT的事情最后数据模型出来了治理也做了却没有业务愿意用。原因就在于组织层面没有明确谁要对中台的业务价值负责。比较稳妥的组织方案是设置一个跨部门的数据中台建设委员会成员包括数据团队负责人、各业务线的数据接口人、财务/运营等核心数据消费方的代表。委员会的职责有三件第一决策指标口径的最终统一认定第二评审数据资产的优先级排序第三追踪中台在业务侧的落地效果和使用率。中台建设团队内部建议至少包含这几类角色数据产品经理负责需求提炼和指标管理、数据架构师负责模型分层和标准制定、数据开发工程师负责建模和任务开发、数据治理专员负责元数据、血缘、质量规则的推进。如果公司已有BI分析团队则建议BI团队和中台团队保持紧密的协作机制——BI负责消费端报表开发中台负责供给端模型统一。6. 中台落地避坑我亲历过和见到过的典型失败模式最后说说踩坑。中台圈子里失败案例太多很多人把失败归因于技术难度大但以我的观察真正干黄的项目绝大多数都栽在方法和管理上而不是代码上。6.1 坑一把中台做成大型数仓项目最普遍的一种失败模式是把数据中台建成了超大号的数仓。团队埋头做ETL、做分层、做模型管道做得漂漂亮亮但业务需求方完全感受不到变化。最后中台团队自己验收自己的数据模型非常满意业务线却说这些数据我也不关心啊。形成这个局面的原因往往是中台团队在立项时就没有想清楚要服务哪些业务场景。要避免它一定要坚持场景驱动建设的原则先锁定两到三个管理层和业务方当前最头疼的数据场景比如统一经营日报、客户全生命周期分析、实时库存监控用中台的方法把它们完整打穿、上线、给业务看到效果再逐步扩展建设范围。6.2 坑二指标口径依然对不齐做中台最核心的价值之一就是统一口径但这个目标极其顽固。原因是业务方天然有各自的立场和视角财务算利润和运营算流水本来就存在合理差异。如果不建立机制去平衡很容易出现中台定了一套口径各业务线自己又私下保留了一套口径的结局。推动口径统一的实际经验是不要追求用一套口径包打天下而是允许在统一指标定义下存在多口径派生指标但必须明确主口径是谁并公开口径差异及使用场景。比如GMV主口径由财务部认定活跃用户主口径由运营部认定中台负责将主口径固化到统一的指标字典和公共模型里各业务侧的个性化口径统一作为派生指标登记在案不脱离中台体系独立存在。这样一来口径对不齐的矛盾不会消失但至少从线下吵架转移到了体系内管理。6.3 坑三中台团队变成了新的ETL外包还有一种情况也容易出现中台建到一半组织层面的协调机制失效各业务线发现找中台排期比自己拉数据更慢后重新回到各自为政的状态。与此同时源源不断的临时取数需求仍然砸向中台团队团队根本没有精力推进统一的模型和服务化最终退化成一个规模更大的取数外包组。要避免这个结果一定要把需求入口管好。中台应该只承接有复用价值的、面向多业务场景的数据需求单次性的、个性化极强的一次性取数需求应该引导到自助分析工具去解决或者明确走项目制而非中台常态化通道。中台的价值在于沉淀不在于接单比武。6.4 破局建议小步快跑选定一两个场景打样最后分享一个个人实践中比较有效的启动思路也是我认为风险最低的路径选一个最痛、最通用、最容易量化价值的场景作为第一个试点。比如一家连锁零售企业可以先做全域客户主题域——打通线上商城、线下门店、会员系统、客服工单的数据形成统一的客户ID和标签体系再输出几个标准客户分析服务让市场部和运营部直接在营销活动中用起来。这个场景业务价值明确数据链路覆盖完整采集、建模、治理、服务全都要走一遍又是典型的跨系统共用数据非常适合作为中台样板间。样板间跑通之后再把顶层设计里规划好的方法论复制到其他主题域扩充资产、扩大服务范围。这种情况下中台的价值是逐步显现、逐步放大的即便中间有波折也不会出现一次性推倒重来的灾难性局面。数据中台这条路说起来是技术工程实际上更像一次组织级的数据认知升级。工具是买得来的方法论是学得来的最难的是让公司里每一个数据相关的人都真正理解和认可统一模型、统一服务、统一治理这套逻辑。我个人的体会是别指望一两年就建成一个完美无缺的中台把目标设成让数据资产的复用率每年稳定提升让业务用数的体验越来越好这个方向永远是对的。至于那些五花八门的新概念听听就好踏踏实实把地基打好比什么都要紧。