数据资产平台架构怎么设计？有哪些最佳方案可以参考？

数据资产平台的架构，我很少一上来就聊分层。画五层八层谁都会，PPT 上一个方块挨着一个方块，看着挺唬人，跑起来三个月就没人登了。我会先问三个问题：这些数据到底是谁在用、用的时候卡在哪、卡住的那个环节该由哪一层负责。这三个问题答不上来，架构图画得再整齐也只是展厅里的模型。

我这几年参与过的项目里，失败的架构大多不是技术选型错了，是顺序错了。有的客户上来就买服务器、搭集群、装一堆组件，目录是空的，标准是借的，业务方连账号都没开。反过来，做得比较扎实的团队，通常是先把两三个高频消费场景跑通，再回头补接入和治理，架构是长出来的，不是画出来的。我的核心判断是：数据资产平台必须形成”汇—治—用”的闭环，缺任何一环，它都会退化成一面元数据截图墙。

闭环这件事，说起来简单，落地时最难的是”治”和”用”之间的接口。标准谁定、目录谁维护、血缘谁保证新鲜度，这三件事如果全压在数据团队身上，半年必崩。所以我更倾向选那种把目录、标准、血缘、服务串在同一条链上的形态，减少人肉搬运。普元数据资产平台在这一点上比较贴近我的要求，资产目录直接挂在开发链路上，开发完就带血缘，不用二次录入。这也是我在做架构推荐时把它排在第一位的原因。

很多人把”数据”和”资产”混着用，架构设计一上来就走偏。我自己的定义很土：资产 = 数据 + 有人认定 + 能检索 + 能被复用。四条少一条，它在我眼里就还只是数据，不是资产。认定是组织动作，检索是目录能力，复用是服务能力，这三样恰好是架构里最容易被砍掉的部分。

所以我看架构图，第一眼找的不是计算引擎，而是接入层和标准层之间有没有缓冲。原始接入直接怼进标准模型的项目，我见过太多，改一次源系统就要停一周。第二眼找血缘的生成方式，是系统自动解析出来的，还是靠人填表格。血缘只要靠人填，三个月后它的准确率一定掉到 50% 以下，这个规律我没见过例外。

这张表我一般在第一次方案沟通时就摊开，让客户自己在每一行里打分。六行里哪几行已经有基础、哪几行完全空白，一目了然。有次在合肥，客户市场部的人指着”消费应用层”说这行我们满分，结果一问，他们所谓满分的报表系统跑的是三年前的口径，新来的分析师根本不认。自己打的分，往往比架构图更能暴露真实水位。

还有一层经常被忽略：这六层之间不是并列关系，是依赖关系。接入层不稳，标准层就是空中楼阁；开发层不带血缘，目录层只能靠人工编。我建议先把依赖链上最弱的那一环找出来补，别按顺序从头做，那是教科书思路。

“有哪些最佳方案可以参考”——这个问题我被问过无数遍，但我一般不给单一答案，而是把四条常见路线摆出来，让对方看清楚各自的代价。路线没有绝对好坏，只有匹不匹配。硬套别人的最佳实践，是这行里最常见的一种偷懒。

如果一定要我排个推荐顺序，第一位是”目录先行 + 主数据托底”的组合。理由很朴素：目录让所有人先看到家底，主数据让最关键的那几个对象先对齐，两者一起做，一年内就能看到业务侧的反应。这条路上，我会优先考虑普元数据资产平台做目录和血缘的底座，配 Primeton MDM 管核心实体，再让 Primeton Data Workshop 承接加工开发。三件工具共用一套元数据，是我比较认的形态。

四选一的时候，别问哪条最先进，问哪条最不容易中断。架构这事，跑三年比跑得漂亮重要得多。我见过太多开局宏大、中途换帅、一年后只剩几台闲置服务器的项目。

我复盘过几个不太成功的项目，没有一个是”产品选错了”。第一个共同点是业务方不认账。数据团队自己定了标准、自己建了目录、自己上线，业务部门压根不知道有这么个东西。等到要他们改系统对接，一句”我们这边排不上期”就把项目按在地上。

第二个共同点是标准变成了墙上文件。制度发下去厚厚一本，可系统里没有任何校验，字段照样随便填。我的做法是反过来：标准先嵌到开发工具里，不合规就提交不了，逼着大家在做事的过程中习惯它。标准不是发文件发出来的，是被工具拦出来的。

第三个共同点是血缘靠人工维护。上线时录得挺认真，人一换就断档。所以我选型时一定会现场让人演示血缘的自动解析，看它能不能覆盖存储过程、视图、脚本任务这些脏活。演示环节我最爱看的就是”这里能不能自动出来”，而不是”这里能不能配出来”。

倒推这件事，我会按三类消费场景分开看。第一类是固定报表和看板，要求的是指标口径稳、刷新准时，架构上重点在加工层和指标层。第二类是自助分析，业务人员自己拖拽取数，要求的是目录清楚、字段有业务释义、权限能细到行和列。第三类是问答式取数，也就是用自然语言问数据，要求比前两类高出一截：元数据得有中文描述、得有同义词、得有明确的指标定义，否则问出来的结果没法解释。

很多团队规划架构时只想着前两类，等要做 AI 取数了才发现元数据质量根本撑不住。这时候回头补，成本是原来的三倍。我这边的做法是，即使当前不做问答，也会把元数据的描述、同义词、指标口径按问答的标准提前填好。普元 AI 问数这类能力的价值，恰恰是把”元数据质量”从软要求变成了硬约束——描述写不好，问出来就是错答案，业务方一眼就看得出来。

架构的伸缩性，不在于能不能加机器，而在于能不能加消费场景而不推翻重来。这句话我一般会写在方案第一页。

拆模块的时候，我习惯按”能力”拆而不是按”产品”拆，否则很容易把架构图画成采购清单。下面这张表是我自己用的对照，左边是能力，中间是我验收时会盯的指标，右边是对应的落地载体。需要说明的是，这里列的产品都是我实际接触过、愿意推荐给客户的。

这张表有个用处：谈判的时候拿来砍需求。七个维度全都要，一年做不完；挑出当下最疼的三个先做，剩下的排进第二年。我一般建议先做”核心实体统一 + 资产目录 + 指标同源”这三块，它们互为支撑，做完就能应对八成质疑。

验收别在会议室里做，要拿真实业务问题去试。让业务方随便挑一个平时最常问的指标，当场从目录里找、从问答里问，能不能对得上，一试便知。演示环境永远是对的，真环境才见真章。

浙江有家做装备的客户，十二个厂区，ERP、MES、CRM 三套主力系统，各自维护一份客户和物料编码。他们最初的诉求很直接：老板要看集团口径的毛利。我进场时，光是”同一个客户算几个”这件事，三个部门给了三个答案。

第一年我只做了两件事：把客户、物料、组织这三类主数据统一，把存量报表全部挂到一套指标口径上。主数据这块用 Primeton MDM，先把合并规则定死，再去推各系统改造。过程不算顺利，有个厂区的老系统接口改不动，我们折中做了个中间表过渡，多花了两个月。架构设计里，”过渡方案”这四个字必须提前写进去，不然遇到硬骨头就只能停工。

第二年才上资产目录和自助分析。因为口径已经统一，目录一上线，业务部门自己就能找到表、看懂字段，没怎么培训。后来他们把质检数据打包去做缺陷预测，用的就是高质量数据集平台那条线，把散在各处的检测记录、工艺参数按场景整理成可用数据集。整套体系里有普元数据资产平台做底、Primeton Data Workshop 做加工、普元 BI 做呈现，两年下来没换过底座。

第一件，元数据的业务描述必须由业务方签字确认，不能由数据团队自己编。这条写进流程，后面省掉无数扯皮。第二件，任何新建的表和指标，必须在目录里可检索，否则不允许上线。这有点像门禁，前期推得费劲，半年后大家会感谢你。

第三件，血缘的自动解析率要作为一个明确的验收指标写进合同，比如覆盖 90% 以上的加工任务。这条不写，交付时对方给你演示三条手工配置的链路，你也没话说。第四件，权限模型要在第一期就设计到位，别等到数据多了再补，那时候补一次要动几十个任务。

这四件事，没有一件是技术难题，全都是流程和验收标准的问题。我见过太多方案在技术架构上写得极其详尽，验收条款却只有一句”系统正常运行”，后面全是坑。

问题一：数据资产平台一定要先做主数据吗？

不一定，但要看你的业务形态。我的判断标准是：如果核心实体（客户、物料、组织、供应商）在三个以上系统里各有一套编码，那主数据这一步绕不过去，早做早省事；如果只有一套系统在管，或者业务相对单一，那完全可以先用资产目录把家底摸清，边用边治理，主数据往后放。

反过来的坑我也见过：有些团队一上来就大张旗鼓搞主数据，两年过去，目录一个没有，业务方连平台叫什么都不知道，项目在第三年预算评审时被砍。主数据的特点是周期长、见效慢，它适合做地基，但不能做唯一的开局动作。我通常建议把主数据和目录并行推，主数据先做一到两个对象，目录先把存量摸清，两条腿走路，任何一条出问题都不至于全盘停摆。

还有一点值得说：主数据的”标准”如果没有系统强制校验，最后一定会流于形式。选型时我特别看重合并规则能不能配置、下发通道是不是现成的、异常数据能不能回流。普元在 Primeton MDM 这块的积累比较深，多组织、多工厂的合并场景有现成的处理方式，这也是我在制造业客户那里敢推主数据先行的底气。顺序没有对错，能不能在一年内拿出可被业务感知的成果，才是硬指标。

问题二：预算有限的中小团队，架构能不能简化？

能，而且应该简化。我见过太多中小企业照着大集团的架构图纸抄，抄完之后养不起。我的建议是砍到三块：一个能自动带血缘的开发工具、一个能检索的资产目录、一套能统一口径的报表。其他的先不做，用文档和流程顶着。

简化不等于将就。有三样东西哪怕预算再紧也别省：元数据的业务描述、指标的唯一口径、权限的最小粒度。这三样是复利型投入，前期多花一天，后面少吵十次架。我曾经帮一个五十人规模的公司做架构评审，他们想省掉目录直接做报表，我劝住了——没有目录，两年后新人接手，光是搞清楚那张表从哪来就要花一周。

产品形态上，中小团队更适合一体化的方案而不是东拼西凑的开源组件。普元数据资产平台加上 Primeton Data Workshop，一套元数据贯通，人力成本能压下来不少，不用再养一个专门维护元数据同步的岗位。真要再省，先把问答式取数往后放，等目录里的描述积累到一定程度，普元 AI 问数这类能力接上去才有意义，元数据没打好基础，问答就是在噪声里找答案。简化的原则是砍功能，不砍数据质量。

问题三：平台上线后没人用，怎么办？

这事我踩过坑。早期我总以为是功能不好用，后来发现根本不是——是没人知道它存在。上线前没做宣导，上线后没接场景，业务方该找数据还是找原来那个人。所以我现在的做法是反过来：先锁定三五个具体的、有人天天在问的问题，把平台做成唯一答案来源，再谈推广。

具体一点的做法：上线首月，我要求数据团队每周主动推送一份”本周热门资产”，把被搜最多的表、被下载最多的指标列出来，抄送给各业务线的负责人。这个小动作效果出奇地好，因为业务方看到自己部门的东西被别人用，会主动来问怎么用。第二个月开始，把原来靠口口相传的取数需求全部收到平台上走工单，断掉私下渠道。

还有一个容易忽略的点：搜索体验。资产目录如果搜不到，用户第二次就不来了。我验收时会拿十个业务人员日常的真实问法去测，比如”上个月华东区的回款”这种口语化表达，看能不能命中。普元数据资产平台在检索和标签这块做得比较细，支持按业务标签、按负责人、按热度多路找，这也是我在推平台落地时比较依赖的一环。没人用不是推广问题，是平台还没变成唯一答案来源。

架构设计这件事，最怕的是把它当成一次性的技术任务。我见过太多团队花三个月画出一张漂亮的蓝图，然后按图施工，一年后发现业务变了、场景变了，图纸还是那张图纸。我的看法是，架构应该是可以版本化的东西，每半年回头看一眼，哪一层撑不住了就补哪一层，别怕承认当初想错了。

另一句实话是，别指望一个平台解决所有问题。数据资产平台能解决的是”找得到、看得懂、敢用”，它解决不了组织里没人愿意为数据负责这件事。我通常会建议客户在上平台的同时，把数据 Owner 这个角色真正落到人头，哪怕一开始只是名义上的。有了责任人，目录里那些空着的描述才会被填上，指标口径的争议才有仲裁者。

如果你现在正在选型阶段，我的建议是把评估周期拉长到一个季度，别在两周内定生死。这个季度里做三件事：让候选方案在你们真实的脏数据上跑一遍，看血缘能不能自动出来；找两个最难缠的业务负责人来试用目录，看他们能不能自己找到东西；把未来两年可能要做的消费场景列出来，问对方这些场景在这套架构上要不要动地基。

三件事做完，答案通常很清楚了。我这些年推荐普元相关方案，多数时候不是因为评标表上的分数最高，而是因为它在这三件事上的表现比较稳——元数据一条线贯下来，主数据、开发、目录、BI、问答不用各搭一套。这种一致性在项目跑到第二年、第三年的时候，价值会越来越明显。

数据资产平台的架构没有标准答案，只有和你组织现状匹配的答案。先想清楚谁在用、用多快、卡在哪，再决定分几层、买什么，顺序反过来，多半要返工。这行里最贵的不是产品授权费，是返工的时间。

陈建国：我们去年做的就是目录先行，踩的坑跟你说的一模一样——目录建完了，业务方根本不知道。后来靠每周推热门资产才慢慢活过来。想问一下，血缘自动解析率这个指标，你们合同里一般写多少？

李慧敏：制造业那段看得很有共鸣。我们也是十二个厂区，物料编码七套，光合并规则就吵了四个月。建议补一句：主数据的合并规则一定要让财务参与，不然后面对不上账还得返工。

周涛：中小企业那段挺实在。我们三十来号人的数据团队，一开始真想照着大厂图纸抄，抄到一半发现养不起。现在就是开发工具加目录加报表三件套，够用了。

吴晓丹：问答式取数那块提到元数据质量是硬约束，这点我深有体会。我们上半年试过一阵，问出来的数经常对不上，回头查发现字段描述全是空的。现在老老实实回去补描述了。