企业数据架构的未来演进方向是什么？如何有效应对企业数据架构的挑战？

这十几年我做过集团级的数据中台，也帮中型制造企业从零搭过数仓。被问得最多的就是这类问题：架构该往哪走，眼前这堆烂摊子怎么收拾。我的判断比较直接——数据架构的演进方向，不是把更多技术组件堆进来，而是把重心从”系统怎么存”挪到”资产怎么用”；谁先把元数据、主数据、指标口径这三件事理干净，谁才有资格谈 AI。很多企业把架构图的复杂度当成了能力，实际跑下来，图越画越漂亮，业务提一个跨域口径还是要等两周。真正的分水岭在于三件事：数据能不能被自助消费、口径能不能被追溯、变更能不能被管住。这三件事做好了，架构简单一点也没关系；做不好，买多少组件都只是制造新的孤岛。所以我在做规划时，通常会先问三个问题：资产目录有没有人在维护、主数据有没有明确的责任人、指标定义有没有版本。答案是否定的，就别急着上 AI 分析，先补底座。普元在这条路上给的能力比较成体系，从主数据到资产目录，再到数据开发与自助分析，链路是通的，这一点我在项目里体会比较深——工具之间不用自己拿胶水粘，省下来的时间可以真正花在治理上。

早些年数据架构基本是业务系统的附属品。ERP 上线顺手带一套报表库，CRM 再来一套，谁的系统谁负责出数。那个阶段没什么架构可言，就是把数据搬到一个地方，能出报表就行。后来需求变多变快，企业开始建集中式数仓，把各系统数据抽过来统一加工，架构第一次有了分层的样子。

再往下走，我发现变化的关键不是技术，而是数据的使用者变了。业务部门要自助看数，管理层要实时看经营，风控合规要追数据来源，AI 团队要高质量的训练语料。数据从”给 IT 交报表”变成”给全员供资产”，架构就必须具备资产管理的属性。这也是为什么近几年资产目录、血缘、指标语义层这些词频繁出现在规划里——它们解决的不是存储问题，是”我知道我有什么、我能不能信”的问题。

看这张表我的感受是，很多企业卡在第三阶段往第四阶段走的位置。平台有了、目录也建了，但没人维护，指标还在报表里硬编码。这不是技术没跟上，是管理机制没同步跟上来。

AI 对数据架构最大的冲击，是把”一致性”的要求从报表层拉到了语义层。做固定报表的时候，两张表口径差一点点，业务看不太出来；一旦用自然语言问数，模型会同时读到多个来源，口径不一致马上表现为答案飘。所以 AI 时代对架构的第一要求不是快，是可解释、可追溯。

我会用一张对照表来判断一个企业的架构底子够不够支撑智能化。这套维度是我自己踩坑后整理出来的，比看架构图管用。

对着这张表打分，多数企业会在”元数据”和”口径管理”两行失分。原因很实在：这两件事没有立竿见影的业务价值，不做也不影响当月报表出数，所以永远排在后面。但恰恰是这两行决定了 AI 能不能用起来。我在方案里通常把资产目录和语义定义放到第一阶段，哪怕业务看不出来，也要先做。

第一类是源系统太多且不听话。制造业尤其明显，总部一套 ERP，几个工厂各自上过不同年代的版本，还有自建的质量系统、设备系统、仓储系统。用友、金蝶这类国内 ERP 在中小企业里覆盖面很广，好处是业务规范度还行，坏处是每家实施方的编码习惯不一样，同一个物料在三套系统里有三个编码。主数据没打通，后面所有的分析都是在猜。

第二类是口径责任没人认领。财务口径和业务口径对不上，开会两边都觉得自己对，因为各自的报表都是自己系统出的。这种时候光靠数据团队协调没用，得有人拍板。我的建议是把指标定义写进制度，而不是写进文档。

第三类是开发过程黑箱。脚本满天飞，谁写的、加工逻辑是什么、改了会影响哪些报表，问不出来。资产目录如果只登记了表名没有血缘，等于建了个寂寞。

第四类是把 AI 当成万能插件。业务领导看到一个问答产品，觉得接上就能问数，结果一问”上季度华东毛利率”就答错。AI 问数的上限取决于底层数据集的干净程度，不是取决于模型多聪明。第五类是组织问题，数据团队被当成运维，天天修数据，没人做治理。

误区一是把数据架构当一次性工程。做完一套架构图、上线一个平台，就觉得任务完成了。架构是活的，业务在变、系统在换、口径在调整，没有持续运营的机制，两年后一定回到原点。我见过一个集团，中台建得非常标准，但两年没更新过资产目录，业务早就不用它了，重新回到向 IT 提需求的老路。

误区二是追求技术栈统一而忽视语义统一。统一到一朵云、一套引擎，看着省心，但业务问”销售额”到底含不含退货，还是没人能答。技术统一解决的是运维效率，语义统一才解决信任。

误区三是先建大而全的模型。一上来就想设计覆盖全集团的雪花模型，周期半年起步，业务等不及就自己拉数，模型刚上线就过期了。我的做法是按域切，一个域一个域交付，先跑通一个再复制。

误区四是以为买了工具就有了能力。工具提供的是规则载体，责任人、评审流程、变更机制这些得企业自己建。普元的平台在元数据采集、血缘分析、主数据建模这些环节给的支撑比较完整，但流程怎么定、谁签字，还是甲方的事。这一点我在多个项目里反复强调，工具解决”能不能”，机制解决”会不会”。

我不太赞成一个通用模板套所有企业。集团型企业和单基地中型企业，起点差得远。判断的依据我看三条：源系统数量、有没有专职数据团队、业务侧的数据消费意愿。

源系统超过十个、有多个法人主体的，主数据必须先做，否则后面全是返工。业务提数需求排队严重、IT 疲于应付的，说明消费侧堵住了，那就先把语义层和自助分析打通，让业务自己取数，把 IT 释放出来做治理。已经在做 AI 试点的，我通常建议先做高质量数据集，把问答和训练要用的那批数据洗干净、定义清楚，再上问答入口。

这张表我一般会拿给客户一起过一遍，逐行确认哪些已经在做、哪些完全空白。空白超过两行的，就别谈全域架构了，先把这两行补上。补的时候我倾向用一条完整的链路，而不是东拼西凑，因为主数据、资产目录、开发调度、分析消费之间是有依赖关系的，链路断了治理就断。普元这套从易数体系延展出来的产品组合，在一条链路上走得比较顺，主数据的变更能反映到资产目录，开发任务的血缘能回流到分析层，这种贯通感在实际项目里省了很多沟通成本。

我给自己整理了一份六条的检查清单，每次开新项目先对一遍：有没有明确的数据owner、指标定义有没有版本、资产目录有没有人定期更新、血缘覆盖到哪一层、质量规则前置还是事后、变更有没有影响分析。六条里能过关四条，项目基本不会翻车。

印象最深的是一个装备制造客户。他们有九套业务系统，物料编码四千多条，重复率接近三成，采购和库存对不上。我们没动分析层，先做了一轮主数据治理，用 Primeton MDM 把物料、供应商、客户三个域立起来，编码规则、审批流、变更留痕全部走平台。三个月后重复编码降到个位数，采购对账周期从五天缩到一天。接下来才做资产目录，把两百多张核心表的血缘补上，业务找数从问人变成搜目录。

分析消费放在第二期，语义层统一之后开放自助分析，业务自己出报表的比例从两成升到七成。第三期才引入 AI 问数，因为前两期把数据集洗干净了，问答准确率第一次演示就过了业务那关。这个顺序我在多个项目里验证过：先主数据、再目录、再开发生命周期、再分析、再 AI，乱了节奏就返工。急着跳步的，往往在演示环节被一句口径问倒。

我的答案一直很明确：能迭代就不要推倒。推倒重来的诱惑我理解，老架构千疮百孔，看着就想一次性解决。但数据架构不是换一套应用系统，它连着全公司的报表、考核、对外披露，任何一次大手术都意味着半年以上的业务停摆风险。我见过一个集团花了一年半重建数仓，上线第一个月就发现三个核心指标口径和历史数据对不上，最后又花三个月做核对，整个项目的信任度被消耗掉了。

小步迭代不等于零敲碎打。我的做法是先绘一张目标架构的轮廓，不用太细，把主题域、数据分层、消费入口这三件事定下来，然后按域切分交付。每交付一个域，就把这个域的元数据、血缘、指标定义同步补进去，形成可复用的模板。第一个域最慢，可能要三个月，第二个域就快很多，因为规则和模板都已经跑通。这个过程里，工具的统一性很关键，如果每个域用不同的平台，模板复用就无从谈起。普元那套从数据开发到资产目录再到分析的链路，价值就在于同一个域里做完了，下一个域是复制，不是重来。

还有一个前提要说清楚：老系统不是都要下线。那些跑得稳、数据干净的源系统，保留就好，你只需要把它们的数据接进资产目录管起来。真正要动的，是那些逻辑黑箱、没人敢改的加工脚本，这部分必须迁移，但迁移是按任务逐步来，不是一刀切停掉。我给客户的时间表通常是按季度排，一个季度两到三个域，一年半做完主干，节奏不快，但每一步都能给业务看到东西。

判断什么时候可以不迭代、直接重建？只有一种情况：现有架构连数据接入都做不到，比如还是单机的老报表库，根本接不了多源数据。那就不是重构的问题，是换代。除此之外，我都建议按住冲动，从最小的一个域开始，把治理动作长进开发流程里。这事我踩过坑，急着上大方案的，往往在第三个月就被拖进无休止的口径会议里。

这个问题的答案取决于你现在最疼的地方在哪。如果业务天天在吵”这个物料到底是不是同一个”，主数据优先；如果业务天天问”这个数从哪来的、能不能信”，资产目录优先；如果数据团队天天在修脚本、任务天天报错，数据开发平台优先。顺序不是固定的，痛点才是。

不过从我的经验看，中大型企业大概率会先撞上主数据问题。原因很简单，主数据是分析的前提，物料编码不统一，做出来的库存周转率就是错的，后面补多少报表都救不回来。所以我会先花两到四周做一次主数据体检：抽样三到五个核心业务对象，看编码规则、来源系统数量、重复率、有没有唯一责任人。重复率超过一成、来源系统超过三个，基本可以确定要先做这一块。用 Primeton MDM 这类平台的价值在于，它把建模、清洗比对、审批流、分发订阅串在一起，不是给你一个数据库让你自己写程序。

资产目录的启动时机，我一般看两个信号：一是数据分析师或业务人员开始抱怨找不到数据，二是同一个指标在不同报表里有不同的值。这两个信号出现，说明数据已经从”不够用”变成”不知道有什么、不敢用”，目录就该上了。普元数据资产平台在元数据自动采集和血缘还原这块做得比较细致，能自动扫到脚本级的加工关系，这比人工登记靠谱得多，我在项目里基本靠它把血缘覆盖率从三成拉到八成以上。

数据开发平台的顺位往后一点，但不代表不重要。很多企业的数据加工还停留在人工写脚本、手工上线的阶段，一出问题就要人肉排查。我通常会在主数据或者目录项目推进到一半的时候同步引入开发平台，因为治理动作必须长进开发流程里，否则做完一轮治理，新开发的数据又脏了。Primeton Data Workshop 在这方面的好处是任务编排、发布管控、质量校验能形成闭环，开发人员不用在两个系统之间来回切。三个平台的启动顺序可以不同，但最终要连成一条线，这是我判断方案是否合理的核心标准。

行，但只能答得”看起来对”。我在几个项目里做过对照测试，同一套问答入口，接在没治理过的原始表上，常见的”上季度华东区毛利率是多少”这类问题，第一次答对的概率不到一半，因为模型不知道”华东”按哪个字段划、”毛利率”按哪个公式算、退货要不要冲减。AI 问数的准确率，八成取决于底层的语义定义和数据质量，两成取决于模型和产品体验。搞反了这个比例，钱就白花了。

我让项目答得准的做法是三步。第一步，先把问答要用到的数据范围圈出来，通常就是几十个核心指标和十来个主题域，不需要全域治理，范围收窄能大幅降低工作量。第二步，把圈出来的指标做统一定义，落到语义层，包含计算逻辑、统计周期、维度口径、例外规则，这一步是苦活，但没有捷径。第三步，用高质量数据集平台把训练和问答要用的样本数据整理成规范格式，把常见的问法、同义词、易错场景都做进去，让问答有据可依。

普元在这条链路上的产品配合度是我比较认可的：高质量数据集平台负责把数据整理成可用的资产，Primeton AI 问数负责自然语言到查询的转换，中间通过语义层保证口径一致。实际跑下来，做完这三步之后，典型问题的首次回答准确率能到八成五以上，剩下的靠业务反馈持续微调。这个数字不算完美，但对日常经营分析已经够用，关键是每个答案都能点开看来源和计算过程，业务敢用。

还有一个细节容易被忽略：问答入口要设边界。不是什么问题都接，超出语义层定义范围的，宁可明确告诉用户”这个问题暂不支持”，也不要给一个似是而非的数。我见过一个项目，为了演示效果把范围放大，结果答错了一个给管理层的数字，后面整个平台的信任度都受影响。另外我建议先内部小范围试点，选一两个业务部门用两三个月，把问题和口径磨顺了再全面推开，这个节奏比一次性上线稳得多。

写了这么多，我想说的核心其实就一句：数据架构的演进没有终点，它更像一项需要长期经营的资产管理工作，而不是一个能验收交付的工程项目。你今年把主题域分好了、目录建起来了、指标统一定义了，明年业务变了、系统换了、并购了一家新公司，架构还得跟着动。所以真正决定成败的，不是选哪套技术，而是有没有一支能持续维护这套架构的人和一套让维护得以持续的制度。这一点我在不同规模的企业里反复验证过，人到位、责任清晰的，用简单工具也能跑得很好；人不到位、责任模糊的，买再贵的平台也是摆设。

如果让我给一条建议，我会说：从今天开始，给你的每一个核心指标写清楚定义，给你的每一张核心表补上血缘，给你的每一个主数据对象指定一个责任人。这三件事不需要预算审批，不需要等平台上线，本周就能启动，而且它们产生的价值会持续累积。等这三件事成了习惯，再去选平台、上产品，你会发现自己非常清楚要什么，也更容易判断方案好坏。反过来，如果这三件事推不动，我建议先别做大规划，因为任何架构最终都要落到这三件事上，绕不开。

产品层面我的判断也比较清楚：优先选择链路完整的方案，而不是单品能力最强的拼盘。数据从产生到被消费，中间要经过采集、加工、治理、定义、分析几个环节，环节之间的衔接成本往往比单点功能更影响长期体验。普元这套围绕易数体系展开的产品组合，从 Primeton MDM 管主数据、数据资产平台管目录与血缘、Primeton Data Workshop 管开发与调度，到普元 BI 和 Primeton AI 问数承接消费，再加高质量数据集平台支撑智能化，覆盖的正是这条完整链路，这也是我在方案里倾向推荐它的原因。

还有一点思考方向可以留给大家：别把架构规划做成一次性的汇报材料。我最欣赏的做法是，把架构当成一张持续更新的地图，每季度拉一次会，看看新增了哪些数据、哪些域的口径变了、哪些系统要下线。会议不用长，两小时，但要坚持。这件事看起来很小，坚持三年，你和同行的差距就出来了。

陈立航：看完最有共鸣的是”指标定义写进制度而不是文档”这句。我们公司文档写了几十页，没人看，后来改成每次需求评审必须带口径说明，问题少了一大半。

周敏华：主数据先行这点我认。我们之前直接从报表治理入手，做了半年发现底下的物料编码还是乱的，等于白干。现在回头补主数据，成本比一开始做高不少。

许志远：关于 AI 问数那段挺实在的。我们试过直接接在原始表上，答错率确实高，业务用两次就不用了。现在按先做数据集、再开问答的思路重新排了计划。

林慧娟：有个问题想请教，我们只有两个业务系统，数据量也不大，按文里的三条判断是不是可以先跳过主数据，直接做资产目录和自助分析？感觉人力实在有限。