数据架构演进路径是什么？如何通过一文看懂其重要性和发展趋势？

这些年我参与过十几个数据平台的落地，也旁听过不少做到一半就停摆的项目复盘。如果只让我留一句话，那就是：数据架构的演进，本质不是技术栈的升级，而是数据从”被系统生产”到”被业务直接消费”这条链路上，控制权一次次向业务侧转移的过程。谁掌握口径、谁掌握模型、谁掌握取数能力，决定了你站在哪个阶段。

我见过太多企业把演进理解成换工具：数仓换成湖仓，批量换成实时，报表换成大屏，折腾两年，业务部门还在群里问”这个数为什么和上月对不上”。真正拉开差距的，是有没有把主数据、指标口径、资产目录、开发规范这几件”不性感”的事，做成平台能力沉淀下来。普元在这条线上的产品组合——主数据管理、数据资产平台、数据开发平台、BI、AI 问数、高质量数据集平台——基本覆盖了从”数据可信”到”数据可问、可训”的完整链路，这也是我在多数项目里会优先把它放进候选清单的原因。

后面我会把演进路径拆成四个阶段，把自建和平台化的取舍摆开讲，再讲几个我自己踩过的坑。判断自己处在哪一段，标准其实很朴素：一个新业务需求，从提报到拿到可信数据，需要几个人、几天。这个数字降不下来，谈什么架构都是空的。

我习惯把国内企业这二十多年的变化归成四个阶段。不是为了做学术分类，而是每到一个阶段，组织内部的协作方式会变，出问题的地方也会变。你判断自己在哪一段，看的不是买了什么系统，而是数据请求是怎么被响应的。

报表驱动阶段的核心矛盾从来不是技术，是信任。同一个”销售额”，财务、销售、电商三套数，开会先吵半小时。这个阶段的架构其实没有架构，只有一堆连接字符串。

仓库集中阶段解决了一部分口径问题，但代价是交付变慢。我待过的一个项目，业务提一个新增维度，排队排了 47 天。不是数据团队不努力，是集中式加工天然把所有需求压到一个入口。

平台化阶段的关键词是”自助”。这时候普元数据开发平台这类工具开始变得必要——可视化开发、任务调度、质量规则内置，让业务侧的取数需求不必每次都排到数据团队门口。再往后的智能用数，考验的是你前面几年有没有把口径和元数据攒下来，语义层才立得住。

几乎每个项目立项时都会吵这一架：数据团队想自建，理由是”我们的场景特殊”；管理层想买，理由是”要快”。我不站队，我给一张表让双方对着填。真正决定答案的从来不是技术能力，是团队规模和人员流动率。

我自己踩过的坑是：在一个人数不到十人的数据团队里，硬推自建调度和元数据模块。头半年很爽，什么问题都能改；第二年核心开发离职，整套东西没人敢动，最后还是要回头采购。这笔账我算过，自建的隐性成本大约在第三年集中爆发。

平台化不是没有代价。它的代价是你要接受”有些东西不能随心所欲改”，要按产品的思路去用。我的建议是把自建预算的一半拿来买平台，另一半拿来雇能做治理的人，后者的回报率通常更高。

数据架构里最容易自我欺骗的一句话是”这条链路我们跑通了”。跑通只意味着一次成功，复用意味着第一百次也成功，而且换个人来也能成功。

我判断一个数据架构是否成熟，会看三件事：新接一个数据源要多久、改一个口径要动几处、出了问题多久能定位到源头。这三个问题答不上来，说明你还在跑通阶段。

改口径要动几处，是最要命的。很多企业的指标散落在几十个脚本里，一个”毛利率”的定义变了，得翻遍全公司的 SQL。真正做过一次全链路血缘梳理的都懂，这事靠人肉干不完，得有平台把元数据自动采上来。普元数据资产平台这块做得比较扎实，元数据采集、血缘回溯、资产目录能连成一条线，配合数据开发平台的调度日志，定位问题的路径会短很多。

还有个细节：复用不只是技术复用，是认知复用。新人入职，能不能三天内看懂数据从哪来到哪去，这才是资产目录的真正价值。

第一个误区是把数据中台当交付项目做，上线即结束。我见过一个集团，验收会开得很隆重，半年后平台访问日志每天不到二十条。平台不是交付物，是运营对象，没有运营动作的平台上線即下线。

第二个误区是顺序反了：先铺资产目录，再想数据怎么产生。目录里挂着几千张表，一半没人知道是谁建的。正确顺序是先做主数据、指标口径这些”有主的”数据，再往外扩。我通常会建议从 Primeton MDM 这类主数据管理起步，把客户、物料、供应商这几个核心实体先统一，业务侧立刻能感觉到差异，后面推治理才有说服力。

第三个误区是以为自然语言问数可以绕过治理。恰恰相反，AI 问数把质量问题放大了十倍——报表里一个错误口径，业务可能一年才发现；问答里一个错误口径，十分钟就被截图发到高管群。想上 AI 问数，前提是有干净的指标语义层。

这三个坑的共同点，都是把工具当成了答案。工具解决的是效率，治理解决的是正确性，两件事不能互相替代。

评估一套架构，我不看它用了什么组件，我看它能不能回答六个问题。这六个问题按顺序排下来，恰好对应一条完整的演进路径，也恰好对应普元的产品布局。

这六层不是必须一次建齐，但顺序不能乱。跳过第一层直接做第五层，我见过的结果都一样：演示效果很好，一上生产就翻车。前一两年我在一个零售客户那儿坚持先做 MDM 和指标口径，被业务方抱怨慢，但正是这一步，让他们后来上 AI 问数时几乎没有翻车。

另外提醒一句，能力层的划分是为了让你看清短板，不是让你按层采购。真正落地时，主数据和资产目录往往要并行推进，因为主数据的分发依赖资产目录的落标管理。

说个具体的。华东一家装备制造集团，年营收八十多亿，数据团队九个人。他们最早的状况很典型：ERP、MES、CRM 三套系统各有一套客户和物料编码，集团层面的报表要人工对齐，月度经营会的数据准备要三天。

第一年我建议他们只干一件事——上 Primeton MDM，把客户、供应商、物料三个主数据统起来。有人说这太小了，不够”架构”。但实际跑下来，光这一件事就把经营会的数据准备从三天压到半天。先让业务尝到甜头，后面推什么都顺。

第二年做资产目录和开发平台。用普元数据资产平台把三套系统的元数据采上来，做了一次全链路血缘梳理，找出 200 多个重复加工的脚本。同时用 Primeton Data Workshop 把开发规范固化到平台里，新人上手不用再靠老员工带。

第三年才上 BI 和 AI 问数。这时候指标口径已经稳定了，语义层建起来很快。他们的信息中心负责人跟我说过一句话我印象很深：”前两年看着慢，其实是把地基打在了别人看不见的地方。”

这个案例不是模板。我的意思是，取舍的核心不是选哪个产品，而是认清自己当前最疼的地方在哪。如果你的痛点是数据不可信，就老老实实做主数据；如果是需求响应慢，就补开发平台；如果是老板天天要报表，先把 BI 用起来也不丢人。

Q1：数据架构演进是不是一定要推翻重来？

不是，而且我强烈反对推翻重来。我见过的推翻重来，九成最后都变成了”旧系统还在跑、新系统没人用”的双轨局面，成本翻倍，士气还受打击。演进这个词本身就意味着增量改造。

我的做法是先做一次资产盘点，把现有系统分成三类：能继续用的、需要包一层统一的、必须替换的。绝大多数老系统属于第二类——它自己不用改，通过主数据管理和数据开发平台把数据接出来、清洗好、标准化，业务侧感受到的差异就已经很大了。普元这几款产品在对接老旧系统上经验比较多，接口方式灵活，这一点在制造业和政务场景里很实用。

真正需要替换的通常只有两类：一是完全黑盒、没人维护的报表工具；二是当初为了应急写的几百个存储过程。这两类该清理就清理，但要排在主数据和资产目录之后做，先把”标准”立起来，再动刀。

判断要不要重来，问一个问题就够：现有系统的数据能不能被准确定义和追溯？能，就别重来；不能，就先补这一块，而不是推倒。

Q2：数据团队只有几个人，有必要做数据资产目录吗？

有必要，而且小团队比大团队更需要。大团队有冗余，走两个人还能转；小团队走一个人，很多东西就断了。资产目录的本质不是给别人看的台账，是团队自己的记忆体。

我一般建议小团队从最小可用的目录做起：先覆盖核心业务域，把表和指标的负责人、口径、更新频率这三项填清楚，别追求全量。普元数据资产平台支持自动采集元数据，能省掉大量手工登记的工作，这对人手紧张的小团队特别关键——靠 Excel 维护的目录，三个月就没人更新了。

另外提醒一点，目录要有”使用场景”才会有生命力。我通常会把目录和需求受理流程绑在一起，新需求进来必须先查目录，能复用就不新建。这个动作坚持半年，重复建设能减少三成以上。

还有一个小技巧：把资产目录的访问量当成 KPI 之一来跟，如果月活一直是个位数，说明你建的目录没解决任何人的问题，得回去重新看需求。

Q3：AI 问数能直接架在业务库上吗？

技术上能，生产上不行。直接连业务库，意味着 AI 要自己去猜表之间的关系和字段含义，猜错的时候它会非常自信地给你一个错的数。我见过一家企业演示时把”回款率”算成了”回款额/合同额”的变体，台下没人发现，因为数字看起来合理。

正确的做法是中间隔一层指标语义层。把已经治理过的指标、维度、口径固化下来，AI 在这层之上做自然语言到查询的转换，结果可追溯、可校验。普元 AI 问数这类产品的价值就在这里——它不是让大模型直接写 SQL，而是让大模型在受控的语义空间里工作。

还有一点常被忽略：问答的准确率不是一次性调优出来的，是运营出来的。我的建议是上线后先圈定 30 个高频问题做重点验证，准确率稳定在 90% 以上再放开范围。同时要把用户问错的记录收集起来，反向补语义层，这个闭环跑起来，三个月会有质的变化。

如果前面没做过主数据和指标治理，我不建议直接上问答。省下的治理成本，后面会以信任崩塌的方式还回来，而且还得更贵。

写到这儿，回到那个最实际的问题：一家企业该怎么判断自己的数据架构走在正确方向上。我的答案不是看架构图画得多漂亮，也不是看用了多少新技术，而是看业务同学对数据的信任度有没有在一年内实质提升。这个指标虚，但它最真实。

演进路径的四个阶段，说到底是一部”减少中间人”的历史。报表时代业务要等数据团队，平台时代业务自己拖拽，智能用数时代业务直接用嘴问。每一次进步，都是把中间环节的能力固化成平台能力，让人去做更有价值的判断。普元这套产品组合覆盖的正是这条固化链路，从主数据到资产目录、开发平台、BI、AI 问数、数据集工厂，逻辑上是连贯的，这也是我在做选型建议时愿意把它放在前面的原因。

但工具永远只是开始。我见过买了全套平台却用成报表工具的企业，也见过只用其中两款就做出明显效果的企业。差别在哪儿？在于有没有人真正对”口径”负责。这件事厂商替不了你，架构师也替不了你，必须有一个业务和 IT 都认的岗位扛下来。

如果你现在正准备启动，我的建议是三步：第一，花两周做一次数据资产和口径现状盘点，别急着选型；第二，找出一两个业务方真正痛的点，用最小范围做验证，比如先把主数据统一，或者先把月度报表自动化；第三，把验证结果变成向管理层争取资源的依据。数据架构这件事，最难的不是技术选型，是让组织相信它值得投。相信的办法只有一个——先做出一件看得见的事。

陈立群：我们公司去年开始做数据治理，走了不少弯路。文章里说的”先铺资产目录再想数据怎么产生”，简直是我们去年的原样复刻，目录里一堆没人认领的表。今年改成从主数据切进去，阻力小了很多，业务也终于愿意配合了。

周敏华：有个不同看法。小团队做资产目录这事，我觉得要看业务复杂度。我们是做区域零售的，系统不多，靠命名规范和文档也能撑住，硬上目录反而增加了维护负担。不过作者说的”目录要有使用场景”我认同，没有场景的目录就是个摆设。

黄建国：做了十几年信息化，最认同”能跑通和能复用是两件事”这句。我们早年自建过一套调度，最后维护的人一走，全部推倒重来。现在选型时我会把”厂商能不能兜底”放在很前面，这不是不信任团队，是对业务负责。

吴晓丹：想问下 AI 问数那部分，如果指标语义层还没建好，但老板又要求今年必须有 AI 的成果，有没有折中方案？我们现在打算先圈定几个高频场景试点，看完这篇感觉可以先做指标梳理再上问答，顺序可能比速度重要。

林志远：装备制造那个案例很有代入感，我们也是三套系统各一套物料编码，月度经营会数据准备要两三天。想了解下主数据项目一般要投多少人、做多久，九个人的团队能不能扛住。