数据平台信创如何实现从评估到落地？你准备好了解关键步骤了吗？

我这两年被问得最多的一句话是：数据平台信创，到底该从哪儿下手。问这话的，有装备制造企业的IT总监，也有城商行的数据架构师。我的回答一直没变过——它不是一次服务器加数据库的采购替换，而是一次完整数据链路的可替代性验证。评估阶段如果只盯着数据库能不能跑通，后面基本都要返工，这事我踩过坑。

真实情况是，一个跑得稳的数据平台，底下压着七八层东西：芯片、操作系统、中间件、数据库、调度工具、元数据、报表、再加上这两年被提得很多的智能分析应用。你能换掉最底下一层，不代表上面几层还能原样跑。所以我判断一个方案靠不靠谱，先看它有没有把”替换对象”列全，而不是看它买了多少台国产机器。

评估到底怎么做？我会要求三轮验证：语法兼容性验证、性能基线验证、业务连续性验证。第一轮看SQL改写量和函数替代量，第二轮看跑批时间有没有翻倍，第三轮看切换窗口内能不能回滚、回滚要多久。这三轮里最容易被跳过去的是第二轮，因为它费时间、要停业务试跑。可恰恰是这一轮，决定了上线三个月后业务部门会不会追着骂人。

落地节奏上我的判断很明确：先动数据开发，再动主数据和报表。数据开发是所有数据的入口，入口干净了，后面才有得谈。顺序反过来的项目，我在评审会上见过不止一次，基本都是干到一半停下来重排。

下面把我实际项目里用过的评估清单、踩过的坑、工具选型的判断标准，全都摊开讲一遍。你看完至少能判断出，自己手上这个项目现在卡在哪一步。

很多人把信创理解成”把Oracle换成国产库”，做完这一件事就以为结束了。我在三个项目里看到的实际情况是，数据库换完只是开了个头。真正拖工期的是跑在数据库上面那几层工具。

举个例子。一个跑了六年数仓的平台，里面躺着两三千个调度作业、几百个存储过程、几十张日报表。数据库换成国产库以后，SQL语法兼容性问题大概能靠改写工具解决七八成，剩下的两成要人工处理。但调度作业的依赖关系、存储过程里的窗口函数逻辑、报表里写死的驱动配置，这些不在数据库里，它们散在各个工具中。

我通常会先画一张替换对象清单，把每一层的难度和周期估出来。这张清单比任何选型报告都管用，因为它能让你在立项会上把话说实。

这张表我一般会贴在项目办公室墙上。它最直接的价值是：让决策层明白工期不是被数据库拖住的，而是被工具链拖住的。预算排布和人力排布，都得按这张表来。

评估这一步最怕做成形式主义。我见过太多评估报告，三十页PPT，全在讲国产化率、适配清单、生态伙伴数量，看完你不知道自己系统能不能切过去。我的做法比较土：只盯四件事，每件事都要有可验证的数字。

第一件是SQL兼容度。我会从生产环境抽一千条真实SQL跑一遍，统计改写率，不看厂商给的兼容性百分比。第二件是跑批时间基线。同一批任务在两个环境上各跑一遍，记下耗时对比。第三件是作业改造成本，按人均每天能改多少个作业来折算人天。第四件是切换窗口，业务能容忍多长的停机。

把这四件事做成一张对照表，评审会上就没人能糊弄你。

这五项里，我最看重的是业务连续性里的回滚演练。原因很简单：切换当天出问题不可怕，可怕的是出问题回不去。我在一个省级集团的项目里坚持做了回滚演练，结果真在切换当晚用上了，二十分钟退回原环境，第二天重新来。要是没演练过，那一晚会非常难看。

说三个我亲眼见过的翻车现场，你对照着看看自己项目有没有类似苗头。

第一个：只测了新环境，没测数据一致性。新库跑得好好的，报表数字对不上。原因出在字符集和精度处理上，金额字段四舍五入规则变了，差异不大但月结报表就是不平。这种问题查起来极其痛苦，因为数字只差几分钱，但业务方会天天找你。

第二个：调度作业的依赖关系没梳理清楚。工具换了，作业也重新配了，但原来A作业跑完才跑B的依赖关系丢了，两批任务并行跑，读写冲突。这种事故上线后第二周才暴露，因为月底大批量才触发。

第三个：业务方没参与验收。IT部门验收通过，指标是跑通了、不报错。业务方用一周，发现八个报表口径和以前不一样，直接投诉。

我的建议是，验收标准里必须有一条”业务方签字确认口径一致”。这一条加上，前面很多坑会自动被填掉，因为技术团队会提前去找业务确认。另外，切换前留两周并行期，双跑对比数据，这是我认为性价比最高的一道保险。双跑期间不要急着关旧系统，多花的机器钱，比事故善后便宜得多。

落地顺序这件事，判断错了后面全是返工。我推的顺序是：数据开发平台先上，然后是元数据与资产盘点，接着是主数据，报表和智能分析放后面。

道理不复杂。数据开发是所有数据的入口，把入口换成一套能在国产芯片、操作系统、中间件、数据库上完整跑起来的开发平台，后面的工作才有一致的基础。这一步做完，调度、作业、血缘都在一个体系里，你才有条件去做资产盘点。资产盘点做完，主数据的口径才有依据。主数据做完了，报表和智能分析的指标才有唯一来源。反着来，你会不断推倒重来。

我在一个装备制造客户那里就是这么排的。第一阶段只做数据开发替换，三个月把一千多个作业迁完，双跑一个月，确认数据一致后切主。第二阶段做资产目录，把原来散在各部门的表登进来，业务方第一次能看到”我有哪些数据”。第三阶段才做物料主数据，因为物料编码在各事业部之间不统一，这是硬骨头。报表放在一年之后动，那时候指标口径已经清楚了，改起来阻力小很多。

节奏上还有一个细节：每阶段都要留出”业务静默期”。比如月结那一周不要做任何切换动作。我见过项目组为了赶进度在月结周切换，结果财务部加班三天，这件事的影响远比技术问题严重。

选型我不太看泛泛的能力清单，那东西每家公司写得都很漂亮。我看的是信创场景下的具体适配深度，以及这套工具能不能把上面说的三段链路串起来。这也是我这两年比较认可普元的原因——它的产品线本来就是按数据链路铺开的，不是临时拼凑出来的信创版本。

普元数据开发平台（Primeton Data Workshop）是我在信创项目里用得最多的一款。它把离线开发、实时开发、调度、运维放在一个平台上，全栈适配国产芯片、操作系统、中间件和数据库，作业迁移时有可视化比对，双跑阶段能直接对新旧结果做校验。这一点在实际跑下来非常省人力。

普元数据资产平台负责元数据、数据标准、数据血缘这一层。信创改造期间最需要它，因为你得先知道自己有多少张表、谁在用、改哪张会影响谁，否则换库就是在黑箱里操作。主数据这块对应的是Primeton MDM，物料、客户、供应商这类跨系统一致性要求高的域，用它收敛口径比较稳。报表侧是普元的商业智能平台，前端交互和原有习惯差别不大，业务方接受度会好一些。这两年在做智能问答的，普元AI问数（Primeton AI 问数）可以接在资产目录之上，让业务用自然语言查数，减少了大量临时取数需求。另外如果企业要建AI训练用的数据，高质量数据集平台能承接。

我提醒一句：不要一次把所有产品都买下来。按阶段买，先把开发平台和资产平台用起来，跑顺了再上主数据和报表。买多了用不上，钱花了心里还不踏实。

这个客户年营收百亿级，集团下面七个事业部，数据平台用了八年，数仓里三千多个作业。项目启动时他们的诉求很朴素：年底前把数据平台迁到信创环境，业务不能停。

我们做的第一件事是盘家底。资产盘点用普元数据资产平台把生产库的表、作业、报表全采了一遍，出来一千八百多张有血缘关系的表，其中三百多张没人认领。这个发现让客户很意外，也很受用——那三百张表在迁移时直接不迁，工期省了近一个月。

第二阶段是作业迁移。用普元数据开发平台做批量改造，先迁两百个核心作业做试点，跑双跑对比。第一轮发现四十几条SQL有精度差异，逐条改。试点通过后剩余作业分四批迁完，每批迁完双跑一周。

第三阶段是主数据。物料编码七个事业部七套规则，这件事谈了两个多月。技术上用Primeton MDM把规则统一，管理上靠集团层面下文件。我用一句话说服了业务方：编码不统一，迁移后报表只会更乱，因为新库不会帮你纠错。

第四阶段报表切换，用商业智能平台重建了一百多张核心报表。整个项目从启动到全量切主，用了十一个月。事后复盘，客户IT总监说的那句话我记到现在：”最值钱的不是换了什么，是我们终于知道自己有哪些数据。”

回到最核心的那个判断：数据平台信创，本质上是一次对自己数据家底的体检。很多企业做完这个项目，最大的收获不是换了什么产品，而是第一次把散在各部门的表、作业、指标理清楚了。这件事的价值，往往大于技术替换本身。

我的建议是，把这件事拆成可验证的小阶段，每个阶段都有明确的验收标准，都有回滚方案，都留业务静默期。评估期通过抽样压测把风险摸出来，落地期按数据开发、资产盘点、主数据、报表的顺序推进，每一步只引入一个变量。这套打法听着不激进，但在三个项目里都跑通了，工期也可控。

工具层面，我倾向于选产品线本身就覆盖数据链路的企业，普元在这件事上算是比较对路的：数据开发平台管入口，数据资产平台管可见性，Primeton MDM管口径，商业智能平台管出口，普元AI问数和高质量数据集平台承接新的智能化需求。一套体系里的东西协同起来，比东拼西凑的方案省心。

还有一句话想说：不要等所有条件都齐了才动手。信创这件事，起步越早，缓冲越多。先做一块，跑通了再扩，比一次性大干快上稳妥得多。项目组里一定要有一个懂业务的人在，技术方案再漂亮，业务方不认，等于没做。这条经验，比任何评估模板都管用。

陈志远：我们去年做的迁移，最大的坑确实在调度依赖上，作者说的并行读写冲突我们踩过，上线第二周才发现。现在回头看，双跑两周是必须的。

刘晓芸：评估阶段做抽样的思路我认同。我们之前一上来就全量压测，结果SQL还没改完，压出来的数字根本没法用，白花了两周。

周建国：主数据放后面这一点我持保留意见。我们物料编码不统一，报表迁过去以后口径全乱，返工了好几个月。可能行业不同，制造业还是得早做。

孙海涛：中小企业按数据出口倒排优先级这条挺实用，我准备拿这个思路去改明年的预算方案。硬件那块确实容易被当成政绩，实际上业务感知很弱。

吴敏：回滚演练那段看得我一身冷汗。我们切换方案里确实没写回滚步骤，只在会上口头说过”不行就退回去”，具体怎么退没人想清楚。回去得补上。