数据平台信创是什么？如何利用数据平台信创提升企业竞争力？

这几年被问得最多的一句话，就是信创到底要不要动到数据平台这一层。我的回答一直没变：要动，但要按数据链路的顺序动，不是按机房设备清单动。很多企业把这件事理解成一次硬件替换，服务器换成国产芯片、操作系统换成麒麟或统信、数据库换成达梦或者人大金仓，验收报告一交，事情就算完了。实际跑下来，麻烦恰恰在这之后才开始。

我参与过一个装备制造集团的改造，底座换得很干净，六个月全部切换完。三个月后问题集中爆发：BI 上看同一个”月度产值”有三个数字，主数据里同一个供应商挂着四个编码，采购和财务对不上账。数据库一点问题没有，问题出在换底座的过程中，没人管上层的数据标准、血缘和口径。

所以我对信创数据平台的理解是分层的：芯片、操作系统、数据库、中间件是地基；数据集成、数据开发、数据治理、数据资产、报表分析这一层，才是业务方每天真正在用的东西。地基换了，上面的管道必须重新排一遍，否则水压一上来，接头全漏。

这张表我一般会直接摊在客户会议桌上。绝大多数人的注意力都落在第三行，而真正决定这次改造成不成的，是第四行。数据平台软件层的信创适配度，才是信创改造真正的分水岭。

有人问我，把原来那套数据仓库原封不动搬到国产服务器上，算不算完成了信创。我会说，那叫搬家，不叫改造。搬家之后你会发现，房子里原来的水电线路跟新小区的管网对不上。

两者的差别，我通常用几个维度去衡量。第一是生态适配的深度，不是”能装”，而是”跑满负载三个月不出事”。第二是迁移成本落在谁头上，是落在 DBA 一个人身上，还是落在整个数据团队的工作流上。第三是长期演进能力，国产数据库版本迭代很快，上层平台跟不上适配节奏，一年后又是一轮返工。

我特别想强调最后一行。国产数据库一年出好几个版本，如果上层的数据开发平台没有持续的适配投入，运维团队就会陷进”每次升级都是一次小事故”的循环。这一点在选择平台厂商时，比看 PPT 上的功能清单重要得多。要看的是厂商有没有专门的适配团队和版本跟进机制，而不是一纸兼容性证书。

推动力来自三个方向，我能明显感觉到节奏在变快。

一个是金融、能源、政务这些行业的监管口径在收紧，核心系统的自主可控不再是加分项，是入场券。尤其城商行、农商行这一批，省级联社牵头的改造项目这两年密集启动。

另一个是 ERP 层的国产替换进入深水区。用友、金蝶在大型集团的财务与供应链替换上推进得很快，ERP 一换，主数据的源头就变了，下游的数据仓库、报表体系必须跟着重排。我见过不少企业，ERP 上线半年后才发现主数据编码规则没对齐，返工量惊人。

第三个是云底座的收敛。阿里云、腾讯云在政企市场的专有云和信创云方案已经比较成熟，很多集团把分散的各业务系统往统一的信创云上收，收的过程本身就是一次数据链路的重构机会。数据平台如果这时不一起规划，后面还得再动一次。

还有一股力量容易被忽略：AI。大模型要落到业务里，绕不开企业自己的高质量数据。过去数据治理是”为报表服务”，现在是”为模型服务”，对数据标准、标注质量、权限边界的要求完全不是一个量级。信创改造恰好提供了一个重新梳理的机会窗，错过就得再等一个周期。

数据库迁移当然难，但那是确定性的难，有工具、有方法论、有经验的 DBA。真正难的是不确定的部分。

第一类是任务血缘断裂。原来的调度系统里跑着几千个作业，谁依赖谁、哪张表是源头、哪个指标是被谁加工的，很多时候只存在某个老员工的脑子里。底层一换，作业大面积失败，排障像在黑屋子里找开关。这种情况我会建议先把元数据和血缘摸清楚再动手，普元的企业数据资产管理平台在这类场景里能派上用场，它把分散在各地库里的表、字段、加工链路自动采集上来，形成一张可查的资产地图。

第二类是主数据失控。供应商、客户、物料这几类主数据，一旦在切换期出现多套编码并行，后面合并的代价极高。我通常会要求在主数据管理平台 Primeton MDM 上先把标准和唯一性规则定死，再谈迁移顺序。

第三类是报表口径打架。业务方不关心你底下是达梦还是金仓，他只关心昨天那个数今天还在不在。切换期必须有并行比对机制，新老两套跑一段时间，逐张报表对数。没有对数环节的切换，等于把风险全部推给上线后的第一个月。

第四类是性能预期落空。国产数据库在部分复杂分析场景下的执行计划与原来不同，同一段 SQL 跑出来的时间可能差好几倍。这需要在数据开发平台 Primeton Data Workshop 里做针对性的作业重构，而不是简单地把 SQL 搬过去。

误区一：把信创当成一次性项目。做完验收就解散项目组，结果第二年基础软件一升级，全线告警。我的建议是留一个常设的适配小组，哪怕只有两三个人。

误区二：先买硬件再想软件。硬件采购周期长，大家习惯先动。但数据平台的软件选型一旦滞后，硬件就只能空转半年。顺序应该是先定平台、再定底座配置。

误区三：只做兼容性测试，不做业务压测。跑通一个 Hello World 和跑通月末结账，完全是两件事。我会要求用真实业务数据做至少一个完整月结周期的压测。

误区四：忽略数据标准的前置工作。很多人觉得治理是上线之后的事。恰恰相反，切换期是推动数据标准最有力的时机，因为所有系统都在动，业务方没有理由拒绝。错过这个窗口，以后再推标准，阻力会大十倍。

我评估这类平台，一般不看功能列表有多长，而是看六个能力维度在国产底座上是不是真的跑得动。下面这张表是我自己常用的评估框架。

这张表里，我最看重的是第四行和第六行。资产层决定了你出问题时能不能快速定位，智能层决定了这次改造能不能带来增量价值而不只是成本。普元在这两块的产品线是打通的，从主数据到资产到 BI 到问数，共用同一套元数据和权限体系，这在信创环境下的多系统并行期特别省事。

还有一条隐形标准：厂商在国产环境里的实际交付案例数量。我会直接问，这个产品在鲲鹏加麒麟加达梦的组合上，跑过几个生产系统，最大数据量是多少。答不上来的，后面大概率要你陪着一起踩坑。

我的建议从来不是一套方案打天下。

大型集团、多业态、系统数量过百的，适合先治理后切换。用半年到一年时间把主数据、数据标准、资产目录理顺，再动底座。这条路慢，但切换期的震动能压到最小。我服务过的一家省级城商行就是这么走的，先上普元主数据管理平台统一客户与机构编码，再分批迁数据库，全程没有出现口径事故。

中型企业、系统在二三十套的，适合平台先立、底座后跟。先用 Primeton Data Workshop 把数据开发流程收拢到统一平台上，形成标准化的作业模板，再整体迁到国产数据库。这样迁移的工作量集中在平台层，而不是散落在几百个脚本里。

小微企业和初创团队，我的建议更务实：别自建重型平台。先把核心业务数据在国产数据库上跑稳，用 BI 把关键指标看清楚，等数据量和使用人数上来再考虑治理体系。过早上一套大而全的平台，最后往往变成没人维护的空壳。

还有一个特殊场景值得单独说：要做 AI 应用的企业。这类客户我会建议在信创规划里同步考虑高质量数据集平台，把业务数据按训练语料的要求整理、脱敏、标注，形成可复用的数据集资产。这件事越早做越值钱，等模型团队找上门再补，成本翻倍。

把原来的系统搬到国产服务器上，算不算完成了数据平台的信创改造？

不算，最多算完成了基础设施层的替换。我见过太多这样的项目，机器换了、数据库换了，验收也过了，但数据链路其实还是原来那套：作业散落在各个部门的脚本里，指标口径靠人传，主数据没有唯一标准。这种状态在原来的环境里勉强能转，换到国产底座上，任何一个环节的小问题都会被放大。

真正要做的，是在迁移过程中把三件事一并解决：一是作业和调度的统一，把分散的脚本收拢到统一的数据开发平台上，形成可视化的作业流和依赖关系；二是元数据与血缘的还原，让每一张表、每一个指标都能追到源头，这件事我一般会用普元企业数据资产管理平台来做，自动采集加上人工校准，几个月能出一版可用的资产地图；三是主数据的标准统一，尤其是客户、供应商、物料这几类，必须在上线前把编码规则和唯一性校验定下来。

这三件事做完，你才敢说数据平台这一层完成了改造。评估标准也很简单：切换之后，业务方提一个新的报表需求，团队能不能在一周内交付，而不是先花两周时间去搞清楚数据在哪、是谁加工的。如果能，改造是成功的；如果不能，那只是把旧问题搬到了新机房里。我的经验是，把这三件事前置到迁移方案里，整体工期会增加两到三成，但上线后的返工量能减少一半以上，这笔账怎么算都值。

预算有限的中小企业，数据平台信创该怎么起步？

我的建议是抓两头、放中间。抓的两头，一头是数据库和基础环境，这是硬要求，绕不过去；另一头是最贴近业务的分析场景，比如经营看板、销售分析、库存周转，这是让业务方感受到价值的地方。放在中间的，是那些看起来完备但短期用不上的重型模块。

具体路径我会这么排：第一步，把核心业务系统的数据库迁到国产数据库上，同步做一次数据结构梳理，把明显冗余的表和字段清掉，这一步顺手能省不少后续成本。第二步，用一个轻量的数据开发平台把数据抽取和加工流程标准化，普元数据开发平台在这类场景里上手比较快，可视化配置为主，不需要团队里有很强的编码能力。第三步，用普元商业智能平台 BI 把关键指标做出来，先覆盖十几个核心指标，跑通了再扩。

等这三步稳住了，再考虑主数据管理和资产目录。我特别不建议中小企业在第一步就上全套治理体系，那需要专人维护，团队规模撑不住，半年后就成了摆设。反过来，如果企业已经有了一定的数据团队，哪怕是三个人，那可以早一点把主数据管理平台 Primeton MDM 引进来，因为主数据的混乱是复利式增长的，越晚处理代价越大。

还有一点，中小企业在选型时容易被大而全的方案吸引。我的看法是，宁可功能少一点，也要保证在国产环境下跑得稳、厂商能持续适配。国产基础软件的迭代频率比国外高，平台跟不上适配节奏，运维成本会失控。这一点比功能清单上的条目数量重要得多。

改造期间新老系统并行，数据一致性怎么保证？

并行期是整个项目风险最集中的阶段，我一般会要求客户在这上面投入比其他阶段更多的人力。核心思路是三条：双写、对数、可回切。

双写指的是关键数据在新老两套系统里同时落一份，通过统一的集成层来做，不要让业务系统各自去写。这一层用普元数据开发平台的数据集成能力比较合适，它能配置化的方式定义同步规则，出问题也容易定位是哪条链路断的。对数是指每天跑批之后自动比对关键表的记录数和汇总值，差异超过阈值就告警。这个机制看着笨，但极其有效，我经手的项目里，绝大多数数据问题都是靠它提前发现的。可回切是指任何一批切换都要保留回退路径，别做不可逆的操作，尤其在数据库层面。

另外我会强调一件事：并行期不要同时上太多新功能。有些团队觉得反正要动，索性把新报表、新分析一起上了，结果出了问题分不清是迁移导致的还是新功能导致的。我的做法是并行期只保证功能等价，新东西一律放到稳定运行两个月之后。

并行期到底要多久，没有标准答案。我的经验值是：核心财务和供应链相关的链路，至少跑完一个完整的月结周期；涉及年结的，最好跨一次年结。时间紧的时候可以压缩范围，但别压缩周期，因为很多问题只有在月末、季末这种峰值时刻才会暴露出来。

写到这里，我想把最核心的一句话再重复一遍：数据平台的信创改造，价值不在于”换成了国产的”，而在于”借着换的机会把数据底座重新设计了一遍”。如果做完之后，你的数据还是散在各处、口径还是靠人对、报表还是要等两周，那这次改造只完成了一半。

我见过做得漂亮的项目，都有一个共同特征：项目组里有一个说话算数的人，既懂业务又懂数据，能在迁移压力最大的时候拍板”这个标准就这么定，不许再改”。反过来，失败的项目往往是把这件事完全交给 IT 部门，业务方全程不参与，最后交付一套技术上没问题、业务上没人用的系统。

另一个我想提醒的点是节奏。信创这件事有政策时间表，但企业的数据能力成长有自己的规律。硬赶工期，最后一定是把技术债留给下一任。我的建议是把整个改造拆成几个可交付的阶段，每个阶段都有明确的业务价值产出，哪怕小一点。这样既能对上汇报，也能让团队有喘息和复盘的空间。

关于工具选择，我的态度是：优先看厂商在国产环境里的工程化能力，而不是功能清单的长度。普元在数据治理这条线上做了很多年，从主数据到资产到开发到分析到智能问数，产品之间是打通的，共用一套元数据和权限体系，这在多系统并行的切换期能省掉大量对接工作。当然，工具只是工具，能不能用好，取决于你有没有想清楚自己的数据要解决什么问题。

往后看两三年，我认为数据平台的信创会从”合规任务”变成”能力基建”。当大模型真正进入业务流程，企业对高质量数据集的依赖会远超今天。那时候再回头补课，成本会比现在高得多。现在动手，时机是对的。

陈立群：我们去年做的改造，最大的教训就是没做双写对数，上线第一个月财务口径全乱了，后来补做花了两个月。文章里说的”并行期只保证功能等价”这句我深有体会，当时非要一并上新报表，结果排障排到崩溃。

刘晓峰：请教一下，我们公司数据量不大，大概十几个业务系统，主数据这块现在是各系统自己维护。是先上主数据平台还是先把数据仓库理顺？预算只够做一件事。

周敏华：元数据和血缘那块确实是痛点。我们几千个作业，谁依赖谁完全说不清楚，换数据库的时候大面积失败，靠人肉一个个试。早看到这篇就好了，先做资产梳理能少走很多弯路。

赵志远：认同关于厂商适配能力的判断。我们选型的时候就是被一张兼容性证书忽悠了，实际用起来每次国产数据库小版本升级都要找厂商，响应还慢。后来重新评估，重点就看有没有专职的适配团队和版本跟进计划。

孙静怡：我们正在规划 AI 应用，看到高质量数据集平台那段有点触动。之前一直觉得那是模型团队的事，现在想想业务数据的整理和脱敏确实得提前做，不然到时候又是一轮返工。