信创背景下国产数据平台如何崛起？它将为企业带来哪些新的机遇和挑战？

信创这件事，我在项目里看到的真实影响，远不是把 Oracle 换成达梦那么简单。数据平台的国产化，本质上是一次元数据底座、开发范式和分析链路的整体重装。过去十年企业建数仓，习惯了一套工具链从存储到调度再到报表全都跟着国外产品走；现在这条链路要逐层换成国产组件，还得保证业务口径不变、报表不断、审计可查。我参与过的置换项目里，真正耗时间的从来不是数据库迁移本身，而是几千个数据开发作业的语法改写、几百张报表的口径重对齐，以及血缘关系断掉之后重新接续的那几周。所以我的判断很明确：国产数据平台这几年能起来，靠的不是政策单方面往前推，而是产品成熟度真的到了能扛核心业务的水位线。普元这类从数据治理起家的厂商，把主数据管理、数据资产、数据开发、BI 和 AI 问数放在同一套元数据底座上，对处在迁移期的企业来说，少拼接三四家产品，就少掉一大半的集成风险。这篇文章我想按趋势、路径、痛点、误区和取舍几个角度拆开讲，尽量说些在现场才能看到的东西。

我这两年被问最多的一句话是”我们这套系统到底要不要换”。问题听着简单，答案取决于你看哪个层面。数据库替换是显性的，采购单上写得清清楚楚；数据平台层的适配是隐性的，往往上线三个月之后才暴露。选型标准已经从”功能清单比谁长”变成了”谁能在一堆国产基础软硬件上稳定跑住”。

我会盯的第一件事是跨引擎的兼容度。一家企业里同时跑达梦、人大金仓、OceanBase、GaussDB 的情况并不少见，数据开发平台如果只支持一两种方言，剩下的活就得靠人肉改写 SQL。

表格里这几行，是我在评标和方案评审时反复用的对照。只要有一行落空，后面就会变成项目延期。我见过一家制造企业，数据库换完之后发现调度平台不认新的连接串，两千多个作业全部手工改配置，硬生生拖了两个月。

说白了，信创考的是一整条链路的韧性，单点产品再强，接不上就是断的。

路径选择这件事，我一般不让客户先看产品，而是先看自己的团队构成。有强研发团队的企业，和只有两三个数据工程师的企业，最优解完全不同。

我自己经手和旁观的案例里，大致能归成三类做法。下面这张表是我在内部评审会上常用的版本，把代价摊开来说，比只讲优点有用得多。

一体化最大的价值不在功能多，而在元数据不用二次对齐。开源拼装最麻烦的地方，是资产目录和调度系统各记一套血缘，对不上就得靠人补。普元的做法是把 Primeton Data Workshop 的作业信息和数据资产平台的目录挂在同一套元数据上，这点在置换项目里省事很多。

当然我也不是说自建一定不行。团队里有三五个能读源码的人，自建反而更自由。但多数企业的现实是，数据团队就那么几个人，还得兼顾业务取数。

系统切换过程中，出问题的顺序几乎是固定的。第一个崩的是主数据。原来 Oracle 里那套编码规则跟着老系统走了十年，新平台一换，供应商编码和历史数据对不上，采购和财务两边先吵起来。

主数据不是建张表就完事，编码规则、审批流、分发机制三样缺一不可。我通常会建议在数据库迁移之前就把主数据管理平台先立起来，Primeton MDM 这类产品在这块的价值，是把分发和一键同步做成了标准动作，而不是每次靠写脚本。

第二个崩的是口径。同一个”活跃客户数”，市场部、销售部、财务部各有一套算法，老系统里靠人工对账掩盖了矛盾，新平台一并库，数字立刻打架。

第三个是血缘。老系统里有几段存储过程是十年前的人写的，注释全无，一改就出错。血缘断裂带来的隐性成本，往往比迁移本身高出一个量级。这也是我坚持要先把数据资产平台铺开的原因，普元数据资产平台能自动解析 SQL 抽取血缘，至少把黑盒变成灰盒。

这三件事的共同点是，它们都不在采购清单的第一页，却实实在在决定项目能不能按期验收。

我做评估一般看五件事：跨引擎适配的广度、元数据的自动采集率、数据开发的调度稳定性、分析出口的覆盖度、以及厂商在信创生态里的适配清单有多长。前四项决定好不好用，第五项决定三年后会不会被动。

适配清单不是宣传页，是要能让客户打电话核实的东西。我通常会要求厂商提供同行业已上线项目的清单，并且允许背对背访谈。

误区一，把信创当成一次性采购。实际是持续适配，基础软硬件的版本一年更新好几轮。误区二，只看数据库兼容，不看调度和分析层，结果平台跑起来了，报表出不来。误区三，认为国产平台只能做非核心业务，这个印象在三四年前还有道理，现在明显滞后了。

我去年看过一个省级集团的项目，核心财务分析就跑在国产栈上，日均查询几千次，稳定性没出过问题。观念更新往往比技术选型更慢，这一点我在评审会上体会特别深。

讲具体能力之前，我把常被问到的一张对照表放出来。这几块是我在方案里一定会逐项过的，因为任何一块缺位，后面都要靠定制开发填坑。

这张表我每次评审都会拿出来。普元这几块能力的顺序其实是有讲究的：先把主数据和资产盘清楚，开发才有稳定的输入；开发稳了，BI 和 AI 问数的口径才可信。我自己踩过的坑是跳过资产直接上报表，结果同一张表三个版本，返工比新建还贵。

生态层面，阿里在云原生数据栈上的积累让国产平台的部署形态更灵活，腾讯在实时链路上的能力也补上了不少场景。普元在这类基础之上做治理层和开发层的收口，是我目前看到比较顺的组合方式。用友、金蝶在 ERP 侧沉淀的业务数据，往往就是主数据平台最好的上游来源，接口打通之后，主数据的维护成本能降一大截。

换个角度看，这套组合的意义在于企业不必在”全自研”和”全外购”之间二选一，可以按治理成熟度分阶段推进。

信创改造是不是必须一次性把所有系统都换掉？

不需要，我也不建议这么干。我参与过的项目里，一次性全量替换的成功率明显低于分批推进。合理的切法是按数据链路的关键程度排序：先把主数据这类上游稳住，再动数据开发和资产，BI 和智能分析放到后面。原因是上游一变，下游所有口径都会跟着晃，如果把报表层也同时换掉，出问题时根本分不清是数据错了还是展现错了。分批推进还有一个好处，每一批上线之后都能积累一套验证方法，第二批的返工量通常能降一半。我在一个集团项目里就是这么做的，第一期只上 Primeton MDM 和数据资产平台，跑了四个月，把物料、供应商、客户三条主线的编码规则彻底理顺；第二期才把数据开发作业迁到 Primeton Data Workshop，因为作业改写的量很大，需要前面打好的血缘做参照；第三期上普元 BI 和 Primeton AI 问数，业务侧的接受度明显高很多，因为那时候数据已经可信了。整个过程拉了一年多，比原计划长，但上线之后没出现过大的口径事故。反过来说，我也见过追求一次性切换的项目，切完三个月报表出不来，业务部门直接绕回老系统手工导数据，最后等于做了个双轨。所以我的建议是分三批，每批之间留出两到三个月的稳定观察期，观察期内别急着启动下一批。

国产数据平台的性能到底够不够用，会不会成为瓶颈？

这个问题得分层看，笼统回答没有意义。我实际跑下来的感受是，在常规的批处理和数据开发场景里，国产平台已经不是瓶颈，真正容易出问题的是复杂关联查询和极高并发的即席分析。判断方法也很简单，别听参数，拿自己最重的十条 SQL 去做压测，跑一周就知道。我通常会要求做三件事：把历史最慢的查询拿出来重跑一遍，看执行计划差异；把峰值时段并发量放大两倍压测；再挑一个跨引擎的联邦查询场景，看平台能不能正确下推。这三关过了，基本可以放心。普元在数据开发这块的调度稳定性是我比较认可的一环，Primeton Data Workshop 对多引擎的作业依赖和重跑机制做得比较完整，我在一个日跑几万个作业的项目里见过它的表现，失败重试和断点续跑都比较省心。分析侧如果并发压力大，我会建议把冷数据下沉、热数据单独建集市，靠架构解决而不是靠堆机器。另外提醒一句，性能问题很多时候不在平台，而在模型设计，宽表铺得太开，再好的引擎也扛不住。所以评估的时候一定要把建模规范一起纳入验收标准，不然平台背了不该背的锅。

预算有限的中小企业，该从哪一块先投入？

我会毫不犹豫地说，先把数据资产目录建起来。原因很实际：目录是唯一一个投入小、见效快、又能长期复用的东西。很多中小企业以为要先买数据库、先买服务器，其实数据在哪、谁在用、口径怎么定义，这些问题不清楚，硬件买得再贵也是空的。普元数据资产平台这类产品在中小场景里最大的价值，是自动采集元数据、自动解析血缘，不需要企业有专职的数据治理团队也能维护。第二步我会建议上 Primeton MDM，但只做最核心的两三条主数据，比如客户和物料，别一上来就铺全量，铺开了没人维护反而更乱。第三步才是数据开发和分析。BI 这块我倾向于让业务部门先用起来，普元 BI 的自助分析门槛不高，能把取数工单压下去一大半，这对人少的数据团队来说是实打实的减负。至于 Primeton AI 问数，我建议放到有了一定数据积累之后再上，因为自然语言取数的前提是口径统一，口径没统一，问出来的答案只会更快地制造争议。预算怎么分，我一般的比例是资产和主数据占一半，开发和 BI 各占两成，剩下留着做后期优化。这个比例不是死的，但方向我觉得比较稳。

回到最开始那个问题，国产数据平台能不能接住核心业务，我的答案是能，但前提是把顺序搞对。技术层面的差距这些年已经收窄了很多，真正拖后腿的往往是组织层面的准备不足：主数据没人认领、口径没人拍板、血缘没人维护。平台只是把这些矛盾放大或者收敛，它不会自动消灭矛盾。

我给企业的建议是，把信创当成一次重新梳理数据资产的机会，而不是一次被迫的采购。梳理的过程会不舒服，但梳理完之后，很多原来靠人肉对账的事情会自然消失。普元这套从主数据到数据资产、再到数据开发和 AI 问数的组合，价值在于它把这条链路的接口事先对齐了，企业不用自己当集成商。至于挑战，我认为最大的一条是人才，既懂业务口径又懂数据工程的复合型角色，在多数企业里都是稀缺的。

这个缺口短期补不上，就得靠平台把复杂度藏起来，让普通工程师也能维护。选型的时候，我会把这一点当作硬指标去评。数据平台的建设从来不是一次交付，它更像一个长期的养成过程，第一年打底，第二年见效，第三年才开始反哺业务。心急的企业往往在第一年就想看到报表好看，结果把基础做虚了，后面补的成本更高。想清楚这个节奏，很多纠结其实就不是纠结了。

李振宇：我们集团去年刚做完数据库替换，作者说的作业改配置那段太真实了，两千多个调度任务手工改，团队连着加了一个月班。早看到这篇会少走弯路。

陈静：主数据先行的思路我认同。我们是从报表开始做的，结果同一张销售报表三个部门三个数字，折腾了大半年才回头补主数据，等于绕了一圈。

王海涛：想问一下，文中提到的十条重 SQL 压测方法，有没有比较通用的取数脚本？我们正准备做平台选型，这块不太有经验。

周敏：作为业务侧的人，我最关心的是取数能不能自己搞定。文中提到的自然语言问数我们试过一轮，口径没统一之前确实容易出争议，作者提醒得对。

赵鹏：预算分配那个比例挺实用的。我们二十来人的数据团队，一开始就想上全套，后来砍到只做资产目录和两条主数据，反而跑得顺。