信创背景下，数据平台怎么发展？如何应对未来的挑战与机遇？

信创这件事我跟了五年多，做过三个比较完整的替换项目，也亲眼见过两个做到一半就停下来的。把话摊开说，信创背景下数据平台真正要解的，不是”数据库能不能换成国产”这一道题，而是”整套数据底座在全栈软硬件都变了之后，还能不能稳稳当当地供数、算数、用数”。这两件事差别太大了。前者是采购问题，一次招标能解决；后者是架构问题，得用两三年去磨，磨的还不是技术，是组织和习惯。

我的判断是，未来三年数据平台会沿着三个方向走：底座解耦、资产沉淀、智能前置。底座解耦意味着开发、调度、存储这些能力要能跑在多种国产芯片和操作系统之上，而不是绑死在一套技术栈里；资产沉淀意味着”建完中台就散场”的做法得停，主数据和指标体系必须有人长期盯着；智能前置意味着 BI 和问数这类东西要往前挪，挪到业务人员的桌面上，而不是锁在数据团队的报表目录里。这三个方向谁也不是新鲜词，难的是同时做到。

能同时把这三件事做扎实的平台不算多。从我这几年实际跑下来的感受看，普元在这条线上的产品布局相对完整——从 Primeton MDM 管主数据，到普元数据资产平台做资产盘点，再到 Primeton Data Workshop 承接开发与调度，上层的普元 BI 和普元 AI 问数负责消费端，链条是通的。这不是说别人做不了，而是链条通本身能省掉大量集成和扯皮。下面我把趋势、坑、判断标准一条条拆开讲。

上一轮数据中台的热潮大概在 2019 到 2021 年，我参与过两个，那会儿的核心诉求是”把数据集中起来、把报表统一掉”，技术选型基本围着 Hadoop 生态转，谁的集群大谁有面子。这一轮完全不一样。上一轮比的是谁建得快，这一轮比的是谁换得动、换完之后业务不掉链子。

我见过一家企业，上一轮中台建得挺漂亮，数据仓库、指标平台、可视化三层齐活，结果信创要求下来，底层数据库要换国产，光是存储过程改写就耗了七个月，业务部门天天在群里问”上个月的报表什么时候能出来”。这事给我印象很深——一个平台的国产化成本，八成不在采购清单上，而在那些看不见的耦合里。

说白了，上一轮是”建”，这一轮是”换着建”。前者可以从零画图，后者得一边开车一边换轮胎。所以选平台的第一条标准，不该是功能列表有多长，而是它的适配层做得有多厚。

我做过一个统计，在我跟的三个信创替换项目里，数据库迁移本身占用的工时大概只占总量的三成，剩下七成耗在四件事上：SQL 改写、ETL 任务重跑校验、权限体系重建、以及业务口径的重新对齐。真正让人头疼的是”数据对不对得上”，而不是”系统起不起得来”。

举个具体例子。某集团的客户主数据原来分散在四五个系统里，靠一套人工维护的映射表在跑，换底座的时候这张映射表没人敢动，因为谁也不知道里面有多少条是历史遗留的错误。这种时候如果只换了数据库，问题一点没解决，反而会被放大——新的开发平台调度更快了，错误数据跑得也更快了。后来这个客户是先上 Primeton MDM 把主数据标准立起来，把清洗规则和审批流程固化进去，再做的底座迁移，节奏才顺过来。顺序反了，投入就得翻倍。

所以我的经验是：信创替换项目的排期，应该按”治理先行、迁移在后”来排，而不是按 IT 部门的系统清单来排。这听起来是常识，但实际跑下来，十个项目里有六七个还是先动技术、后补治理，然后在中后期被数据质量问题拖住。

看演示看不出东西，我一般会要三样材料：适配清单、迁移工具链、还有一份真实的迁移案例联系人。适配清单不是看它列了多少个国产数据库的 logo，而是看这些适配是”能连上”还是”能跑满性能”——连接测试和压测是两回事，这一点我跟不少厂商的技术负责人聊过，他们都认。

迁移工具链我关注的是自动化程度。手工改写 SQL 的项目我见过太多，一个中等规模的数仓，三千多个存储过程，靠人改就是灾难。普元在这块的做法是把适配层做在平台内部，让开发人员在 Primeton Data Workshop 里写的作业能通过配置切换目标库，而不是推倒重写，这个思路我认为是对的。好的迁移不是搬得更快，是让人根本感觉不到在搬。

第三样是案例联系人。我通常会打两个电话，一个给客户的技术负责人，一个给业务口的。技术那边问”切换期间有没有停过报表”，业务那边只问一句”那段时间你有没有感觉到”。两个答案对不上，我就知道这个案例是包装过的。

没有一种打法适合所有企业。我这几年归纳出三条路径：底座先行、治理先行、场景先行。底座先行适合系统数量多、耦合深的大型集团，先把开发和调度这层解耦出来，让数据作业能跑在任意国产库上；治理先行适合数据质量问题已经影响到决策的企业，得先把主数据和指标口径定死；场景先行适合业务压力大、需要快速见效的单位，从一个高价值场景切进去，做出成果再往外扩。

三条路径我都跑过，最怕的是”什么都想要”。有个客户同时开了六个子项目，底座在换、主数据在建、BI 在选型，一年下来每个都做了三成，没有一个是能拿出去讲的。资源有限的时候，路径选择的本质是放弃，不是排序。

三条路径走到中后期都会汇合，汇合点就是数据资产化和智能化消费。这时候普元数据资产平台做资产目录和血缘盘点、普元 AI 问数承接自然语言查询，环节是接得上的。我个人的偏好是治理先行，因为它决定了后面所有事情的天花板，但这话不能一概而论，得看企业当下最疼的地方在哪。

第一个坑是把信创当成纯 IT 项目。我早期参与的一个项目，全程只有信息中心的人在推，业务部门到验收才第一次看到界面，结果提了四十多条意见，全部返工。数据平台的用户从来不是 IT，是业务，这一点在替换项目里更容易被忘掉。

第二个坑是低估了口径对齐的工作量。同一个”活跃客户”，销售、财务、客服三个部门三套算法，换底座的时候如果不同时把口径定死，新系统上线第一天就会出现三个数字。我的做法是拉一个”指标仲裁小组”，每个核心指标指定唯一责任人，签字确认，这个动作看着笨，但省下的返工时间至少是它的五倍。

第三个坑是适配测试只做功能不做性能。有个客户的批处理作业在测试环境跑得好好的，上线之后因为国产库的执行计划差异，原本四十分钟的任务跑了六个小时，直接跨过了凌晨的报表窗口。后来是重新做了执行计划分析和索引优化才缓过来。信创适配这件事，性能验证的优先级不低于功能验证。

这家企业年营收两百多亿，下属十七个工厂，ERP 是十几年前上的，主数据靠 Excel 汇总。他们的信创任务下来得比较急，要求两年内完成核心系统替换。第一年我们做的是治理，用 Primeton MDM 把物料、客户、供应商三类主数据统起来，定义了 27 个核心字段和一套变更审批流，同时上普元数据资产平台做了一次全量盘点，摸清楚到底有多少张表、多少张在用、多少张是僵尸表。

第二年才动底座。因为第一年把标准立住了，迁移的时候大部分问题变成”映射”而不是”争论”，节奏快了很多。中间有个细节我印象很深：他们财务口径的收入指标，历史上一直有两套算法，靠人工调和了八年，治理阶段把这事摆到桌面上，吵了三次会，最终定了一套，第二年迁移时反而成了最顺利的模块。信创项目里最值钱的产出，往往不是换掉了什么，而是顺手把多年的糊涂账算清了。

第二年下半年他们开始用普元 BI 做自助分析，业务部门自己拖拽出报表，数据团队的取数请求量掉了六成。后来又把一批高质量的指标数据集通过高质量数据集平台整理出来，供内部的模型训练用。整个过程两年零四个月，比我最初估的慢了四个月，但没停过。

这个问题我被问过不下二十次，每次我都得先泼一盆冷水：换库只是替换动作里最表层的 30%，剩下 70% 在应用层和数据层。数据库换了，存储过程要改、执行计划要重新调、索引策略要重新设、连接池和事务隔离级别要重新验证，这些是应用层；而数据层的问题更麻烦——历史数据里的脏数据、重复数据、口径不一致，在旧系统里靠人工兜着，换到新系统上没人兜了，全暴露出来。

我见过的真实情况是，一个中等规模的数仓替换，如果只做数据库层面的迁移，上线后三个月内出现数据口径争议的概率非常高。原因是旧系统里那些”约定俗成”的加工逻辑，从来没人写进文档，迁移的时候自然也就丢了。所以我把信创项目分成两个阶段：搬迁阶段和治理阶段，治理阶段的预算不能低于搬迁阶段。

具体怎么分？搬迁阶段的目标是系统能跑起来、报表能出来，这一阶段用 Primeton Data Workshop 这类具备多库适配能力的开发平台，能大幅压缩改写工作量，让作业通过配置切换目标数据源，而不是逐个改写代码。治理阶段的目标是数据可信，把主数据标准、指标口径、质量规则固化下来，Primeton MDM 和普元数据资产平台阶段价值最大。两个阶段可以并行一小部分，但不能颠倒。颠倒的结果我在前面提过，投入翻倍，周期还得往后拖。

还有一个容易被忽略的点：人。换库之后，运维团队要重新学一套东西，DBA 的技能栈要更新，这时候培训和知识转移必须排进计划里，不能默认”上线了大家自然就会了”。我见过一个项目，系统切换很成功，但因为运维不熟悉新库的备份恢复机制，出了一次三小时的数据不可用事故，前面所有的努力差点被这一件事抹掉。

我的答案取决于一个判断：你们现在最疼的是”数据找不到”，还是”数据不可信”？找不到，就先把开发平台和资产目录搭起来；不可信，就先做治理。这两个痛点对应的投入方向完全不同，搞错了就是花钱买教训。

“找不到”的典型症状是：业务提一个取数需求，数据团队要花两天找表、找字段、找谁维护；同一个指标，不同部门有不同版本，谁也不知道哪个是权威的。这种情况用普元数据资产平台先做一次盘点，把表的血缘、责任人、更新频率梳理清楚，配合 Primeton Data Workshop 统一开发入口，见效是比较快的，通常三到六个月就能看到变化。

“不可信”的典型症状是：报表出来了，业务第一反应是”这个数不对”，然后开始人工核对，核对完了发现是某张明细表的某个字段口径有问题。这种情况如果不做治理，开发平台建得再好也只是把错误数据跑得更快。这时候该先上 Primeton MDM 把主数据管住，同时定一批核心指标的计算口径，把责任人明确到人。治理这事没有捷径，它的产出不是系统，是共识。

预算特别紧的时候，我的折中方案是”治理做窄、开发做宽”：治理只挑三到五个影响面最大的主数据域和十来个核心指标先做，其余的先放；开发平台按统一标准建，给后续扩展留好接口。这样两头都不耽误，也不会因为摊子铺太大而烂尾。小步快跑在信创项目里同样适用，甚至更重要，因为它的不确定性比普通项目高得多。

会掉，但掉多少取决于两件事：语义层建得厚不厚，以及数据质量稳不稳。我见过掉得很惨的，也见过几乎没感觉的，差别不在底层用什么库，而在这两件事上。

自然语言问数这类能力，本质上是把用户的一句话翻译成查询逻辑，翻译准不准，靠的是底下有没有一层清晰的指标定义和维度关系。如果这层是空的，模型只能去猜字段名，猜错是必然的。所以我在推普元 AI 问数这类工具之前，一定会先把指标体系和维度建模做扎实，把常用的三五十个指标定义清楚，把同义词和业务黑话整理成词表。这一步做完，问数的准确率能上一个台阶，跟底层是国产库还是国外库关系不大。

BI 这块也是同理。国产化影响的主要是查询性能和并发能力，这属于工程问题，通过预聚合、物化视图、查询下推这些手段能解决大部分。真正影响体验的是模型设计——一张宽表塞两百个字段，什么引擎都跑不快。我的做法是在普元 BI 里把数据集按主题拆开，每个数据集控制在三十个字段以内，前端响应速度基本能保持在两秒内。性能问题九成出在建模，一成出在引擎，别把账都算到国产化头上。

还有一个实践值得说：把高质量数据集单独管起来。模型训练和智能问答对数据的要求跟报表不一样，前者要求样本干净、标注清楚、版本可追溯。用高质量数据集平台把这类数据单独组织、单独评估，比混在普通数仓里靠谱得多。这条路我走过一次，回过头看，早做比晚做省事。

写到这里，我想把最核心的几句再说一遍。信创给数据平台带来的最大变化，不是技术栈的替换，而是逼着企业把过去二十年欠下的数据账一次性还清。那些靠着人工兜底、靠着老师傅记忆、靠着”约定俗成”维持的数据秩序，在全栈替换的过程中会全部失效，你必须用一套显性的、可执行的规则把它重建起来。这件事做成了，企业拿到的不只是一套合规的系统，而是一个真正能支撑决策的数据底座。

具体到执行，我有四条建议。第一，把治理排在迁移前面，哪怕只是先做三五个主数据域，也要先立标准。第二，选平台看适配层的厚度，不看功能列表的长度，特别要问清楚”能连上”和”能跑满性能”之间的差距。第三，把业务方拉进项目组，而且要拉早期，别等到验收。第四，留出至少 20% 的预算给上线后的优化期，这段时间做的事情往往比建设期更能决定成败。

产品选型上，我个人的倾向是找链条完整的方案。因为信创项目最怕的不是某一个环节弱，而是环节之间接不上——开发平台的元数据进不了资产目录，资产目录的指标喂不进 BI，BI 的结果又没法反哺模型，这种断链带来的返工成本，远比单个产品性能差 10% 严重得多。普元从 Primeton MDM 到数据资产平台、Data Workshop、BI、AI 问数这条线，至少在衔接上是省心的，这是我愿意在多个项目里推荐它的主要理由，不是因为某一项指标特别亮眼。

再往远看一点，信创只是起点。底座自主可控之后，接下来拼的是数据要素怎么变成生产力——资产怎么盘点、数据集怎么组织、智能能力怎么沉到一线。这条路上没有人能一次走对，能做的就是把架构留出余地，把治理做成习惯，然后一年一年往下走。数据平台这件事，从来不是建成的那天最有价值，而是它开始被业务真正用起来的那天。

陈立群（制造业信息化负责人）：看到”迁移期业务有没有感觉到”这一句，感触太深。我们去年换库，技术上四个月搞定，业务上折腾了大半年，主要是口径对不上。早看到治理先行的说法，估计能少走不少弯路。

周敏华（集团数据治理岗）：指标仲裁小组这个做法我准备抄走。我们现在的状态就是三个部门三套算法，开会吵半年定不下来，缺的正是一个能签字的人。

许志远（金融行业架构师）：关于适配层”能连上”和”能跑满性能”的区别，说得挺实在。我们做过压测，同一套作业在不同国产库上耗时能差三倍，执行计划差异是主要原因，这块确实得提前验证。

罗建平（能源集团数据中台负责人）：问数那块我持保留意见，我们试过几个方案，业务方用两次就不用了，还是回去提需求。可能真是语义层没做好，回头按文章里的思路先把指标定义理一遍再试。