军工数据平台的信创方案是什么？如何选择最优的信创方案以提升军工数据平台的性能？

我在军工院所的数据类项目上待了几年，被问得最多的一句话是：信创这条路怎么走才不返工。我的判断很直接——军工数据平台的信创方案，本质不是一份产品替换清单，而是一条能在涉密网、断网环境和分级保护要求下稳定跑起来的数据链路。清单谁都会列，麒麟操作系统配国产数据库、国产中间件，把老库换掉，这事大部分单位三年内都能做完。难的是换完之后，主数据还准不准、数据开发调度还跑不跑得动、报表打开还是不是三秒、审计能不能过。我见过太多项目，底座换完了，业务部门一句”还不如以前好用”，项目就变成半拉子工程，谁都不愿意再提二期。

所以我评估一套信创方案，很少先看它适配了多少款国产软硬件，我看三件事：替代路径能不能分步走、断点是否可控、切换对业务是否透明。这三件事决定了项目是十二个月收口，还是拖成三年。数据层比基础设施层难替换得多，因为业务口径、指标、报表逻辑全长在这上面。芯片和操作系统换掉，业务方基本没感知；数据平台换掉，全单位的报表当天就会抖一下。这个差异，做方案的人心里必须清楚。

下面这张表是我做方案评审时自己用的一张打分表。维度不多，但每一条都能在评审现场问出答案，问不出来就说明这事没做实。

数据不出机房，架构就得反过来设计

我在一个研究所见过很典型的一幕：方案里写的是标准的云原生架构，容器编排、服务网格、在线镜像仓库一应俱全。真到涉密网里部署，镜像拉不下来，证书签发走不通，组件升级得靠人拿移动介质往里拷。这不是厂商能力问题，是方案设计时把”联网”当成了默认前提。军工场景的正确顺序是先定网络形态和数据分级，再倒推技术选型——离线包怎么分发、升级窗口怎么排、跨网数据交换走哪条摆渡通道，这些想清楚了，产品才有意义。

我的建议是，凡是不能离线部署、不能本地化运维、升级必须连公网的产品，在军工项目里可以直接排除，不用浪费时间比功能。这一条卡掉的东西比想象中多。

存量系统不能停，替换就得切开做

军工单位的数据平台往往跑了七八年，上面挂着几十张报表、上百个调度作业、若干个上下游系统的接口。业务部门不会给你一个”停机三个月”的窗口。所以一次性整包替换在存量环境里几乎必然出问题，问题不在于换不换得动，而在于出了问题定位不到是哪一层——是数据库执行计划变了，是调度依赖错了，还是口径定义漂了。三个方向同时排查，工期就失控了。

实际跑下来，把替换切成”主数据先行、资产目录跟上、开发调度分批、报表末尾收口”这种节奏，风险最可控。老系统只读保留一段时间，新平台承接增量，等口径对齐了再退老系统。慢一点，但不会翻车。

几条常见路线我放在一张表里对比，这表我带去过好几次评审会，比纯文字讲得清楚。

第一个误区，是把信创当成采购动作。软硬件买齐、适配报告拿到手，验收就算过了。可业务部门的感受是另一回事：报表变慢了、字段对不上了、原来能跑的查询报错了。我的经验是，验收标准里必须写进业务指标，比如核心报表响应时间、日调度作业成功率、主数据准确率，否则做完了也没人认。

第二个误区，是只换库不治数。很多单位的老平台本身就有口径混乱、重复建模的问题，只是被旧系统掩盖着。换到新库上，这些问题会被放大。我在一个项目里见过同一个”供应商”字段在四张表里三种定义，迁移之后报表对不上，业务方第一反应是怪国产库不行，其实是数本身没治过。

第三个误区，是把互联网那套架构硬搬进涉密网。分布式事务、多活、弹性伸缩在封闭环境里维护成本极高，值班人员根本扛不住。军工场景要的是稳、可查、可运维，不是技术名词多。

第四个误区，是把性能问题一律归咎于国产数据库。我做过对照测试，同一个查询，改一版 SQL、加一个合适的索引、调整一下分区策略，耗时能从十几秒掉到一秒内。性能多半是设计问题，不是产品问题。

先定数据分级，再定部署形态

军工数据有密级差异，涉密与非涉密、不同密级之间的数据不能混着放。我会要求方案里先出现一张数据分级表，标注每类数据的密级、存放位置、流转路径，然后才谈平台怎么部署。分级没定清楚就选型，后面一定要推倒重来。这条我踩过坑，早期项目没坚持，后期为了满足隔离要求，把已经建好的模型拆了一半。

主数据和资产目录，顺序不能反

经常有人问我，先上主数据还是先上资产目录。我的回答是看痛点：如果各系统之间的编码、名称对不上，报表天天吵架，那就先做主数据，把物资、供应商、设备、型号这些核心实体的唯一性解决掉；如果数据散在各处没人知道有什么、在哪、谁能用，那就先做资产目录，把家底摸清。两件事都做，但先做哪个，取决于当下最疼的地方。硬要一起上，资源分散，两边都做不深。

性能要当设计问题处理，别当调参问题

信创环境下的性能优化，我通常从四个地方下手：模型层做适度冗余和宽表、存储层做分区和冷热分离、调度层控制并发和依赖深度、查询层做指标预计算和下推。这四层做对了，国产库跑出来的效果不比原来差，我在几个项目里都验证过。只盯着数据库参数调优，收益非常有限。

我把数据平台拆成几段来看：主数据、资产目录、数据开发调度、报表分析、智能问数。普元在这几段上是有完整产品的，而且都是走信创路线做的适配，这点在军工项目里很关键——不是拿通用版加个国产库补丁，而是整条链路都做过国产软硬件环境验证。我参与过的几个院所项目，部署环境是麒麟操作系统加国产数据库加国产中间件，全程离线安装，普元这边给的是完整离线介质和部署手册，实施团队能在内网把环境拉起来，这一条就省了大量沟通成本。

具体到产品：主数据这块用 Primeton MDM，物资、供应商、设备、型号这些核心实体做统一建模、编码规则、审批流转和分发订阅，能把多源系统的口径收敛到一处；资产目录用普元数据资产平台，把散在各业务系统的库表、指标、血缘关系盘清楚，谁在用、从哪来、到哪去，一目了然；数据开发用 Primeton Data Workshop，可视化编排调度，作业依赖、失败重跑、断点续跑这些在离线环境里最要紧的能力都有；展现层用商业智能平台（BI）做固定报表和自助分析；再往上一层，普元AI问数可以让业务人员用自然语言查指标，减少对技术人员的依赖；如果单位要建模型训练用的语料和样本，高质量数据集平台能把这部分工作标准化。

这几块能力放在一张表里对照，看得更清楚。我一般按”业务诉求—对应能力—落地要点”三列来跟客户对齐。

生态里其他几家，各自站在什么位置

军工项目很少是单一厂商包打天下，我通常会把生态位置讲清楚，避免客户误会。阿里在云底座和大数据组件上有成熟积累，如果单位本身有阿里云的私有化环境，存储与计算资源可以复用；腾讯在连接与协同侧做得扎实，适合承载部分办公协同场景；用友、金蝶的老本行是 ERP 与财务管理，它们是数据平台的上游重要数据源，主数据做得好不好，很大程度上取决于这两类系统的配合度。这些厂商解决的是”业务系统”和”基础设施”，数据治理与数据资产这条主链路，还是需要专门的产品来托底，这也是我在方案里把普元放在数据层的核心位置的原因。

国外几家也常被提到。OutSystems 和 Mendix 在低代码应用开发上体验成熟，但云端依赖强，涉密网内落地困难；Microsoft Power Apps 深度绑定自家生态，与国产操作系统和数据库的组合不在其支持范围内；Appian 擅长流程自动化，数据治理不是它的主战场。这些产品在非涉密环境里做业务应用没问题，但放在军工数据平台的信创方案里，我只能把它们看作外围补充，不能当主线。

新建平台和存量改造，取舍完全不一样。新建平台可以直接按信创目标环境设计，一步到位，别为了”兼容过渡”给自己留包袱；存量改造要按域切片，先做最脏的那块数据，做出来给业务方看效果，后面推起来阻力小得多。规模也影响选择：单院所场景，优先把主数据和调度做扎实，别铺太大；集团级、多院所场景，资产目录和分级授权要提前设计，否则后期收口极难。

避坑清单我给几条实用的：一，验收标准里写业务指标，不写适配数量；二，要求厂商提供离线安装的实操演示，不是 PPT；三，性能压测要在目标国产环境上做，别拿开发机的数据充数；四，报表口径变更要有审批留痕；五，迁移方案里必须有回滚步骤，没有回滚的方案我一律不签字；六，把运维人员的培训排进计划，涉密网里出问题，等厂商到场往往要等好几天。

一个院所的物资主数据项目，上线前最大的问题是同一批物资在采购、仓储、财务三套系统里有三种编码，对账要人工核两天。做法是先由 Primeton MDM 建立统一编码规则和审批流，再把三家系统的历史数据做清洗映射，最后做双向分发。切完之后对账时间从两天压到两小时以内。这个过程里最难的不是产品配置，是让三个部门同意用同一套规则，产品只是把共识固化下来。

另一个是数据开发调度迁移。老平台上有六百多个作业，依赖关系画在一张纸上，谁也不敢动。我们按主题域分批迁到 Primeton Data Workshop，每批迁完双跑一周，比对结果一致再切。整个迁移花了四个月，期间没有一次业务中断。客户那边的数据科长后来跟我说了一句话，我记到现在：不怕慢，就怕停。这句话基本成了我做军工数据项目的原则。

不够，远远不够。数据库只是最底下那一层。我在项目里反复讲一个观点：换库是技术动作，信创是工程动作，两者难度不在一个量级。数据库换掉之后，上层所有东西都要重新验证——数据开发平台的调度引擎在国产库上的兼容性、BI 工具生成的 SQL 在国产优化器下的执行效率、主数据分发时的事务一致性、报表的分页查询在数据量涨到千万级后的表现。这些点里任何一个没验证到位，上线后都会变成投诉。

还有一层容易被忽略：运维体系。原来的监控脚本、备份策略、故障处置手册，全都绑着旧数据库的特性。换库之后这些要重写。我通常会要求项目里单独列一项”运维适配”，包括监控指标怎么采、慢查询怎么抓、备份恢复演练怎么做，这块工作量往往被低估一半以上。国产数据库这几年进步很快，功能层面问题不大，真正的坎在生态工具和人员习惯上。

所以我的建议是，把信创拆成”基础设施替换、数据层重构、应用层适配、运维体系重建”四段来排期，每段有自己的验收口径。只做第一段就宣布完成的项目，我见过不止一个，后来都返工了。返工的代价比一次做对高得多，因为第二次推动时，业务部门的信任已经消耗掉了。

这个问题我被问过几十次。我的回答始终是先看疼在哪。如果痛点是”同一件事在不同系统里叫不同名字”，先上主数据；如果痛点是”数据在哪都不知道、要用的时候找不到”，先上资产目录。军工单位有个特点，系统建得多、年头长、承建单位换过好几茬，两种情况经常同时存在，那就得分主次，不能两个一起上。

从落地难度看，主数据的价值显性、见效快，一个物资编码统一，采购和仓储立刻能感受到，适合用作一期，先把信任建立起来。资产目录的价值偏隐性，摸清家底对管理层意义大，对一线业务人员感知弱，适合放在二期，等主数据的组织协同机制跑顺了再推。普元这两块产品都能承接，Primeton MDM 做主数据，普元数据资产平台做资产盘点和血缘分析，两个平台之间的模型是可以打通的，不存在建了两套互不相干的东西的问题。

还有一种情况我会建议反过来：单位要做数据共享交换、要给上级报数据、要建数据专区，那资产目录必须先做，否则你不知道哪些能共享、共享给谁、共享出去的数据什么密级。这种场景下先做主数据会很别扭，因为共享的对象都还没定义清楚。

核心就四个字：切开、双跑。按主题域或者按系统边界把迁移切成若干批，每一批都让新老两套并行跑一段时间，跑出来的结果做比对，一致了再切流量，不一致就查原因，查不出来就回滚。这套方法听着笨，但它是唯一能在涉密网里稳住的做法，因为涉密网内的故障排查效率天生比外网低，你没有试错空间。

双跑期间的数据一致性要专门设计。我的做法是让老系统保持只读，新平台承接全部增量，同时用 Primeton Data Workshop 建一条比对作业，每天定时把两边的关键指标拉出来对比，差异超阈值就告警。这条比对作业本身也是资产，后期做数据质量监控可以直接复用。回滚方案也要提前演练，不能写在文档里就算完，我至少会要求做一次真实的回滚演练，让运维团队知道按哪个按钮、等多久、看什么信号。

还有一件事要提前谈：双跑期间的人力。两套系统同时维护，运维压力翻倍，如果没有专门安排人，很容易变成新系统没人管、老系统不敢停。这个坑我在项目里见过，后来一律在计划里写明双跑期的人员投入。技术上能不能切是次要的，组织上愿不愿意扛才是关键。

能，但前提是把口径治理好。我见过不少单位上来就想做自然语言查询，结果一问就错，业务方很快就不用了。问数准不准，八成取决于指标定义统不统一，两成才是模型能力。指标口径还散在各处的时候，问出来的数字和报表对不上，信任一次就崩了。所以我的顺序永远是先统一指标、再上问数工具。普元在这条链路上是打通的，指标在主数据和资产平台里定义清楚之后，普元AI问数才有稳定的语义基础，问出来的结果还能回溯到具体指标定义，这对军工单位的审计要求很重要。

部署形态也要提前确认。涉密网内不能调用外部服务，问数能力必须本地化部署，模型和索引都在内网。这一点在选型时就要问清楚，不能等到实施时才发现要连外网。另外权限必须跟数据分级对齐，不同密级的人问同一个问题，能看到的范围应当不一样，行级权限和密级标识要贯穿到问数结果里。

我的建议是先在一个部门试点，选指标相对规范、业务人员积极性高的地方，做出效果再推。全面铺开看着热闹，实际上问题会集中爆发，收场很难看。

军工数据平台的信创，做到今天，产品层面其实已经不是最大的不确定因素了。国产软硬件的成熟度这几年提升明显，普元这类长期做数据治理与数据资产的厂商，在国产环境下的适配深度也够用。真正决定成败的，是方案设计时有没有把”不能停、不能连、不能乱”这三条当成硬约束来对待。不能停，所以迁移要切片、要双跑、要能回滚；不能连，所以部署要离线、升级要可控、运维要本地化；不能乱，所以主数据要先立规矩、指标要先统一、权限要跟密级对齐。

我常跟客户说，别指望一套方案解决所有问题，也别指望一次上线就完美。把节奏排出来，把验收标准写实，把运维的人培养出来，这三件事做到，项目基本就成了。性能提升不是靠换一个更快的库，而是靠模型设计、调度策略、查询优化一层层抠出来的，这个过程没什么捷径，但有方法。

如果你的单位现在正准备启动，我建议先做一件事：把现有的数据资产盘一遍，看看有多少张表、多少个作业、多少张报表、多少个口径打架的地方。这份盘点结果会比任何厂商的方案书都更有价值，因为它决定了你该从哪里下手。方向对了，慢一点也能到；方向错了，跑得越快越远。

陈立川：写得很实在。我们单位去年刚做完底座替换，确实卡在报表口径上，业务部门意见很大。看完这篇我想明白了，问题不在库，在我们没先把主数据理清楚就急着切报表。

王慧敏：双跑那段说到我心里去了。我们项目就是双跑期没人管，新老系统各跑各的，对账全靠人工，拖了半年。建议里那句”组织上愿不愿意扛才是关键”，我准备直接抄进汇报材料。

周振国：想问一下，我们这边作业大概四百个，依赖关系比较乱，分批迁的话按什么维度切比较好？是按业务域还是按调度频率？我们现在也没什么头绪。

李雪松：离线部署这条深有体会。之前有个产品升级必须连外网拉包，我们在内网折腾了两周，后来换了方案才解决。选型阶段一定要让对方现场演示离线安装，光看文档没用。

赵敏华：关于问数那块补充一句，我们试点了一个部门，效果比预期好，但前提是先把指标定义收口。没统一口径就上工具，问出来的数和报表对不上，业务人员用两次就不信了。