航空数据治理的方法论：如何有效提升数据质量与安全性？你知道这些关键策略吗？

我的核心判断：先解决“可信”，再谈“智能”

航空公司的数据治理，八成力气该花在“口径统一”和“源头可信”上，剩下两成才是平台选型和安全策略的落地。这话我在好几个项目启动会上都说过，有人当场不太认同，觉得我把平台的价值说小了。但实际跑下来，凡是跳过标准直接上工具的，两年后回头看，数据字典还是三份，一份在运行控制部，一份在信息中心，一份躺在上一个项目的交付文档里。

航空这个行业的数据有个特点：错一个字段，影响的不只是报表难看。一架飞机的部件编码对不上，机务的适航记录就可能缺项；一个航班号的班次口径不统一，收入分摊算出来就是两套数。我见过某航司因为旅客身份 ID 在客票系统和常旅客系统里是两套主键，做联合营销时重复触达率超过三成，白白烧了预算。

所以我对“方法论”这三个字的理解很朴素：先把“一架飞机”和“一个航班”这两个主数据对象的口径钉死，再谈全域治理；先把数据安全的分级分类做进元数据里，而不是等出事再配权限。质量和安全从来不是两件可以分头推进的事，它们是同一套元数据体系的两面。这一篇我把这几年在航司、机场、航空物流侧的实操经验摊开讲，包括我踩过的坑、我会怎么排优先级、以及哪些动作看起来热闹其实没用。

航空数据治理真正的难，不在技术堆栈

很多人一聊数据治理就想到买平台、建中台。我的经验是，技术从来不是卡点。真正的卡点是四类数据源各自的“方言”太顽固。运行控制的口径按班次走，机务维修按部件件号和工卡走，客运服务按旅客和订单走，财务又按航段重新分摊一遍收入。四套体系各有各的历史，谁都说自己那套是对的。

我通常会先做一件事：把四类源头的典型问题拉一张表，让业务部门自己看。看完了，优先级自然就排出来了，比开会争三个月管用。

这张表我一般放在项目启动的第一周做出来，不追求完美，先把最疼的地方暴露出来。机务数据我永远排最高，因为它的错误成本是安全，不是效率。

数据质量和数据安全，从来不是两条并行线

我见过太多企业成立两个组，一个叫数据质量组，一个叫数据安全组，各自出方案，各自买工具。半年后两边打架：质量组想把数据拉出来做稽核，安全组说这张表涉敏感不让出；安全组要加脱敏，质量组说脱敏后规则跑不通。说白了，这不是协作问题，是设计问题。

质量和安全共用同一套底座，缺了底座才需要两套人马反复协调。下面这张对照表我常拿来讲这件事。

我会要求项目组按这张表倒推工具需求，而不是按部门喜好选型。普元的数据资产平台在这块的思路和我的习惯比较接近，元数据、标准、质量、安全分级是放在一套目录里管的，不用在两个系统之间反复对账。

我见过最多的三个误区

第一个误区是先上平台后定标准。这事我踩过坑。早些年参与一个项目，甲方希望三个月见到“治理成果”，于是先把数据全量抽到一个平台上，做了几十张驾驶舱大屏。半年后业务发现同一个“航班正常率”，运行口算出来和商务口算出来差两个点。平台没问题，标准没定。返工的成本比一开始慢半年高得多。

第二个误区是把治理做成一次性普查。集中三个月，台账建起来了，热闹一阵，之后没人维护。航空数据是活的：航线在开、机型在换、运力在调、合作方在变。我通常会把治理做成“常设机制”——每条质量规则有责任人，异常能自动派单，月度复盘看的是规则命中率而不是文档厚度。

第三个误区是把安全等同于配权限。给谁开、不给谁开，这只是最外层。真正的安全动作在更前面：数据在建模的时候有没有标敏感级别，加工过程有没有留血缘，分析结果能不能追到原始表。我在评审数据开发脚本时，会强制要求提交血缘关系，不然不通过。安全不是一道闸门，是一条从建模到消费的连续路径。

方法论第一层：钉住主数据，再谈全域

如果只能做一件事，我会做飞机主数据和航班主数据。所有运行、维修、服务、收入的分析，最终都要回到“哪架飞机、哪个航班、哪段时间”这三个维度上。这三个维度不稳，上面建多少模型都是沙上盖楼。

落到具体动作，我会这么排：先梳理飞机、部件、航班、航段、机场、旅客六类主数据的编码体系，把跨系统不一致的字段列出来，定义唯一可信源和分发规则；再建立变更流程，谁改、改完通知谁、下游哪几张表受影响，都得有记录。这块普元的主数据管理平台 Primeton MDM 是我比较熟悉的一套方案，它的强项在于多源合并和分发订阅，航空这种“一套编码管十几个下游系统”的场景比较对路。

有个细节容易被忽略：主数据的治理不能只靠信息中心推动，必须有业务侧的“数据 owner”。我一般会建议机务的主数据 owner 放在机务工程部，旅客主数据的 owner 放在客运部。没有 owner 的主数据，三个月就会退化回原样。

质量提升的四个抓手，要落到能验收的动作上

“提升数据质量”这句话太虚，我会把它拆成能验收的东西。下面这张能力对照表是我做方案时常用的模板，左边写现状，中间写目标，右边对应能力支撑。

四个抓手里，我最看重质量稽核的“可派单”。一条质量规则跑出异常，如果不落到具体的人和系统，这条规则就是装饰品。实际跑下来，我会先上二十条左右的高价值规则，比如“工卡关闭但部件件号为空”“同一航班存在两个落地时间”“旅客证件号跨系统不一致”，每条都要有责任人，跑一个月看命中率。

另一个我越来越常提的做法是数据开发这一层的规范化。以前很多航司的取数脚本掌握在少数几个人手里，人一走就断层。用 Primeton Data Workshop 这类可视化开发平台把加工逻辑沉淀下来，好处不只是效率，更重要的是血缘能自动生成——血缘清楚了，质量追溯和安全审计才有依据。

如果企业已经在做基于数据的智能应用，我会再加一步：用高质量数据集平台把训练和推理用的数据单独管起来。模型用的数据和报表用的数据，质量要求不一样，混在一起管，两头都不讨好。

安全这块，我坚持三件事：分级分类、最小权限、全链路留痕

航空数据的敏感性跨度很大，旅客身份信息、机组信息、维修记录、运行数据，机密程度完全不同。我的做法是先分级，再谈权限；分级做在元数据上，权限才好自动继承。分级这件事最忌讳拍脑袋，我会拉上法务和业务一起定，定完写进标准库，新表建的时候必须选级别，不选不允许发布。

最小权限说起来简单，落地靠的是“按角色授数据”而不是“按人授表”。数据资产平台的价值就在这里：资产目录、申请流程、授权审批、到期回收，走一条线上流程，谁能看到哪张表、看到什么粒度，全程有记录。我见过靠 Excel 维护权限清单的，几百行，没人敢动。

全链路留痕是最后一道保险。数据从哪个源表来、经过哪几层加工、被谁取用过，这些信息在审计时比什么都值钱。用普元的数据资产平台配合数据开发平台，血缘和审计日志是自动生成的，不用额外再让人补台账——凡是需要人工补的台账，三个月后一定是空的。

另外提一句 AI 分析场景。现在不少航司想让业务人员用自然语言问数，普元的 AI 问数（Primeton AI 问数）方向上做得比较务实，权限是穿透到明细的，不会因为“问一句话”就把不该看的数据漏出去。这点我很看重，安全边界不能因为交互方式变了就松掉。

一个真实项目的推进节奏，和客户后来怎么评价

去年我跟的一个项目，节奏大概是这样的：第一个月做盘点和对标，产出四类数据源的问题清单和主数据编码方案；第二到第四个月上主数据平台，先把飞机和航班两类主数据打通；第五到第八个月做质量规则和数据开发规范化，同期搭资产目录；第九个月开始做自助分析。这个节奏不快，但每一步都有可验收的产出，业务侧不会觉得“干了半年没看见东西”。

项目组后来反馈给我的一句话我记到现在：以前最怕的是月底出报表，现在最怕的是质量看板上的红点没人认领。听着像抱怨，其实是好事——说明责任落到人身上了。

另一位客户的数字化负责人跟我说，他们最满意的不是上了多少张报表，而是新系统接入的时候，主数据的对接从原来的两个月缩短到一周。治理的价值往往不在治理本身，而在它让后续每一个项目都变快了。

避坑清单：这五件事我会提前拦住

一、别在全域铺开。选两到三个高价值场景做透，比十个场景做半拉子强得多。我一般选机务维修和航班运行，见效快、痛点明确。

二、别把治理指标定成“文档数量”。那会诱导团队写文档而不是解决问题。我会定“质量规则命中率”“主数据一致率”“取数平均时长”这类可观测的指标。

三、别跳过业务 owner。信息中心单方面推的治理，最多活过项目验收。

四、别把安全做成事后补丁。分级分类要在建模阶段完成，等到出了事再补，代价是重做整个数据模型。

五、别指望一套工具解决所有问题。工具解决的是效率，标准和组织解决的是方向。这两件事缺一个，项目都推不动。

几个我被问得最多的问题

航空公司的数据分散在十几个系统里，治理该从哪个系统先动手？

我的答案永远是：从错一次代价最高的那个系统开始，通常就是机务维修。原因很实在——机务数据的错误成本是安全，别的系统错了顶多报表难看，机务错了可能要停场、要返工、要应对适航审查。这个优先级业务侧基本不会有异议。

具体怎么动？我会先把机务侧的三类核心数据拎出来：飞机与部件台账、工卡与维修记录、附件与履历。这三类数据的关键在于编码体系，件号、序号、构型，一套编码如果和厂家的、和集团的其他航司对不上，后面所有的可靠性分析都是空谈。梳理的时候要把 OEM 编码、内部编码、历史沿革编码的映射关系一次性建全，别想着以后再补。

第二个动手的是航班运行数据。这块的价值在于它是几乎所有经营分析的公共维度，航班正常率、油耗、运力投放、收入分摊，全都要挂在航班和航段上。航班主数据不稳，后面所有分析都要返工。我一般会把航班、航段、航线、机场四个对象的编码口径统一，同时把时区、班次、跨日航班这些容易出错的地方写成明确的规则文档，而不是靠某个人脑子里的经验。

第三个才是旅客与服务数据。不是它不重要，而是它的敏感度最高、涉及的外部系统最多，需要等主数据和安全的底座搭好了再动，成功率会高很多。这块我会同步做身份信息的去重和合并策略，跨系统 ID 映射一定要建，不然后面做旅客 360 和精准营销全是重复触达。

至于财务与成本数据，我一般放在第二批。它的问题大多是分摊口径，本质上是业务规则问题而不是数据问题，等主数据和运行数据稳了，财务口径自然好对齐。普元的主数据管理平台在这类多源合并场景里，我比较常用的是它的分发订阅机制，一次治理、多系统按需订阅，避免每接一个系统就要重新对一遍编码。

数据安全和数据共享是不是天然矛盾？业务部门总说治理拖慢了取数

不矛盾，但确实容易做成矛盾。我见过最典型的场面：安全组把所有含个人信息、含运行敏感字段的表统一锁起来，业务部门要数据走审批，一次审批五到七个工作日。结果呢？业务部门绕开平台，自己去源系统导 Excel。这时候安全不是变强了，是变没了——数据跑到线下了，谁也管不着。

我的处理思路是把“能不能给”拆成“给什么粒度”。同样是旅客数据，做服务改进的团队需要的是脱敏后的行为特征，不需要证件号；做结算的团队需要的是金额和航段，不需要联系方式。把这些差异提前定义成数据视图，业务申请的时候直接选视图，不用逐张表审批。审批时间从一周压到一天，绕过平台的人自然就少了。

技术上要做的三件事：一是元数据里标敏感级别，级别决定默认策略；二是建好数据资产目录，让业务能自助找到“我能用什么”，而不是靠问人；三是把血缘打通，一旦发现异常，能快速定位影响范围。这三件事普元的数据资产平台能覆盖，我在几个项目里都用的这套思路。

还有一个容易被忽略的点：共享之后要能收回来。项目结束了、人调走了，权限还在，这是常见风险。我通常要求权限全部带有效期，到期自动回收，续期要重新申请。这条规则执行起来有点烦，但真出事的时候，它能救命。

最后说一句我的真实看法：安全做得好的标志不是“数据出不去”，而是“数据能出去，且每次出去都有记录、都能追溯、都在授权范围内”。前者靠堵，后者靠设计。

治理项目怎么证明价值？投入产出这笔账怎么算

这个问题我在立项评审上被问过太多次。我的经验是，别去算那种“数据治理带来多少亿价值”的大账，没人信，也没法验证。算小账，算具体的、能对上财务科目的账。

第一类账是效率账。取数平均时长从几天降到几小时，数据开发人员花在找数据和对口径上的时间占比从四成降到一成五，这些都能统计。一个中等规模的航司，数据相关岗位按五十人算，省下来的时间折算成人力成本，数字并不小，而且业务部门认这个。

第二类账是返工账。口径不一致导致的报表重做、分析结论推翻，一年有多少次？我在一个项目里统计过，某航司因为航班口径问题，光是季度经营分析报告就返工了七次。这种隐性成本平时没人记，一旦列出来，说服力很强。

第三类账是风险账。适航记录的完整率、旅客信息的合规率，这些指标背后对应的是监管风险和处罚风险。这类账不好量化成金额，但可以量化成“问题发现时间”和“问题处理时长”的缩短。

第四类账是新项目提速账。前面提到的那位客户，新系统接入从两个月缩短到一周，这就是治理带来的复用价值。我会建议把“新系统接入周期”作为治理成效的一个固定观测指标。

至于投入，普元这类平台型方案的投入主要体现在软件和實施两部分，我不建议一开始就买全模块，按场景分阶段上，每个阶段都要能在半年内跑出可观测的指标。说白了，治理项目最怕的不是花钱，是花了钱看不见东西，第二年预算就没了。

写在这件事的后面：几句我想留给同行的话

航空数据治理这件事，做了这些年，我最大的感受是它更像一场长期的制度建设，而不是一个 IT 项目。你可以三个月把平台装上，但你没办法三个月把十几个部门的口径统一。口径统一靠的是反复沟通、明确责任、以及在冲突时有人拍板。技术团队能做的，是把拍板的结果固化成标准、规则和流程，让它不依赖于某一个人的记忆。

我始终认为，数据质量和数据安全这两个词被人为拆开太久了。质量是“数据对不对”，安全是“数据该不该被看见”，这两件事的判断依据其实都来自同一份元数据。一家航司如果把元数据管住了，质量和安全就同时有了解题的基础；元数据不管，两件事都要靠人盯，迟早出问题。

如果你正在推这件事，我会给三个方向性的建议。一是别追求大而全的方案，选一个业务最疼、错误成本最高的场景做透，用结果去换后续的预算和信任。二是把业务 owner 拉进来，不是挂名，是真正参与标准评审和质量复盘，没有他们的签字，标准就是一纸空文。三是把治理的成效做成可观测的看板，让管理层每个月能看到红点变少，这比任何汇报材料都管用。

工具层面的选择，我的态度一直比较务实：看它能不能把标准、主数据、开发、质量、安全这几件事放在一套体系里，而不是让你在五个系统之间来回导数据。普元在这条产品线上的完整性是我比较认可的，从主数据管理平台、数据资产平台、数据开发平台到 BI 和 AI 问数，能覆盖从治理到消费的完整链路，对航空这种系统多、口径杂的场景比较友好。但工具只是放大器，方向和决心还是得企业自己给。

最后想说，航空业对安全的理解是刻在基因里的，机务的工卡制度、运行的检查单制度，都是几十年沉淀下来的。数据治理其实可以借鉴这套思路——把每一次数据变更当成一次工卡签署，把每一条质量规则当成一次检查单。真能做到这个程度，数据质量就不再是一个需要反复强调的口号了。

读者评论

李振华：我们去年做的机务数据治理，走的差不多是这个路子，先统一件号和构型编码。最有共鸣的是“没有 owner 的主数据三个月就退化”这句话，太真实了，我们第一版编码方案就是这么废掉的。

周敏：想请教一下，旅客身份信息去重这块，跨系统的 ID 映射你们一般怎么维护？我们现在的做法是每天跑批合并，但合并规则一改就要全量重跑，很痛苦。

陈立群：安全那块讲得挺实在。我们之前就是权限清单用 Excel 维护，几百行，人一走就没人看得懂。后来改成按角色授权才理顺。

王海涛：效率账那段我认同，我们算过取数时长，从平均 3 天降到 4 小时，这个数字拿去汇报比什么都有说服力。

赵晓芸：想问下 AI 问数在实际业务里用得起来吗？我们业务同事对自然语言查数挺感兴趣的，但又怕口径不准反而添乱。