航空公司双中台落地指南：边界划分、数据治理与避坑实践

简介：面向企业数字化转型规划者、中台架构师及大数据/AI从业者的《中国南方航空数字化和双中台方案》PPT资源，聚焦航空业如何通过业务中台+数据中台整合全生命周期航班数据，解决重复建设与响应慢等痛点，兼具战略规划与落地实践。压缩包仅含1个pptx文件，包体1.1MB，轻量易读，适合快速掌握南航数字化框架。内容完整呈现数字化管办体系、创新体系、流程管理体系、人才培养体系等四大成绩，并深入拆解以航班中心为核心的业务中台，以及通过《大兴机场转场通告》报表快速响应、业务人员自助分析等案例展示的数据中台价值。同时提炼了“为什么转、转什么、怎么转”三个关键问题的思考路径，可帮助企业管理者理解中台建设的顶层设计与实施要点。已有98人浏览/学习，适合作为数字化转型规划、中台方案设计的参考资料。

1. 数字化转型的低垂果实摘完了，双中台扛起剩下的活儿

“数字化”这三字在航空公司喊了快十年，官网、App、小程序、自助值机都铺完以后，IT部门手里捏着一堆“上不了台面”的账：营销部门要实时会员画像，财务要渠道成本明细，运价要按航线做收益分析，地面服务要查航班保障节点——每张表都散落在订座、离港、常旅客、运价、结算七八套老系统里。数据拿不出来，新业务就上不去，这才是南航这类企业把“数字化和双中台方案”做成立项PPT的核心动机：不是再买一套系统，而是把散装的老系统重新整理成可复用的能力。

这份方案要回答的，说白了就三件事：业务中台怎么把订单、会员、运价这些公共动作沉淀成标准化服务；数据中台怎么把分布在各个孤岛里的数据变成一张干净、口径一致的表；以及这两个台分家之后怎么协同，别建成两张新的孤岛。适合的读者是做企业架构、数据平台、应用集成的一线工程师，也包括要给这类项目立项写汇报材料的技术负责人。文章接下来就按双中台的拆分逻辑、落地顺序、数据中台和业务中台各自的最小可跑通路径来展开，最后一章讲一个验证中台是否真实生效的自检手段。

2. 双中台怎么切：业务中台与数据中台的边界划分与落地顺序

双中台最容易踩的第一个坑，是团队在立项阶段就把边界吵没了。业务中台和技术中台大家都熟，业务中台和数据中台的分工却常常含糊：订单中心算业务中台，还是算数据中台？会员画像归谁建？指标口径归谁定？这里有个从业者普遍认可的分法，我一般用一句话给团队立规矩：业务中台管“瞬时动作”，数据中台管“长周期沉淀”。

2.1 业务中台管“简短的瞬间”，数据中台管“拉长的时间线”

订单创建、支付回调、退改签申请、会员积分变更，这些都是具体的动作，要求毫秒级响应、强一致性、事务回滚，属于业务中台的管辖范围。它对外输出的是API，内部依赖的是订单库、会员库这类在线交易库。而“这个月会员复购率是多少”“暑期哪条航线收益崩了”“高价值旅客的流失预警”，这些是分析命题，依赖的是清洗后的宽表、指标、标签，允许秒级甚至分钟级延迟，属于数据中台的管辖范围。

边界一旦划成这个逻辑，很多纠缠就自动解开。订单中心绝无可能放在数据中台里，因为那是一个事务性的业务服务；而“订单主题宽表”也绝无可能交给业务中台维护，因为它服务的不是在线流程，而是分析场景。业务中台对数据中台的输出方式是“数据同步任务”，而不是“API调用”；数据中台对业务中台的输出方式是“标签查询接口”和“指标订阅”，而不是“直接改库”。这套约定我在多个项目里沿用，几乎没有再为边界问题开过会。

2.2 落地顺序之争：先业务后数据还是先数据后业务

行业中常见的顺序有两种，一种是先做业务中台，把订单、会员、支付这些能力API化，同时把数据同步管道搭好，再做数据中台；另一种是先做数据中台，把主数据、指标口径、数据模型定清楚，再反过来指导业务中台的服务设计。以我的经验，航空公司这种业务复杂度高的场景，推荐走一条折中路线：先以数据中台的主数据治理打底，跑3个月，同时启动业务中台订单与会员两个中心。

理由很朴素：航空业务的“会员”“航班”“航线”“机场”这些主数据不统一，业务中台做出来也是建在流沙上。我一个项目里见过，同一个旅客在常旅客系统里叫“旅客编号”，在电商订单里叫“用户ID”，在离港系统里叫“证件号”，数据中台不先把这三者的映射关系整理干净，业务中台的会员中心连“这个旅客是不是金卡”都要查三个系统。反过来，如果只做数据中台不做业务中台，数据中台建出来的指标没人消费，三个月后就会被业务方判定为“烧钱项目”，这个风险在航空业尤其高，因为IT预算的每一分钱都要在年度经营会上过堂。

2.3 双中台的组织归属与一个运维责任矩阵

中台类项目失败，往往是组织问题大于技术问题。业务中台如果挂在传统应用开发部门下面，会被当成“又一个项目组”，做出来的服务只管自己的KPI，不顾复用；数据中台如果挂在数据中心下面，会沦为“报表组”。常见做法是设立一个独立的中台团队，直接对CIO或数字化转型办公室汇报，同时从业务部门和IT部门各抽调接口人组成“中台需求委员会”，每双周评审一次需求优先级，避免中台团队闭门造车。

运维责任也必须在立项PPT里写死。我习惯于用一张责任矩阵把边界钉住：业务中台负责在线服务的可用性和性能，数据中台负责数据同步链路的稳定性和数据质量，而双方交叉的部分，例如用户行为埋点日志，由数据中台负责采集和清洗，业务中台只消费结果。表格里“R”表示负责、“A”表示审批、“C”表示被咨询，别看这个纸面功夫简单，它能让上线后扯皮的概率下降一半，属于投入产出比极高的前置动作。

3. 数据中台先行：从数据地图到指标字典的最小可跑通方案

数据中台如果一上来就铺几十个主题域，大概率半年见不到成果。航空公司的数据起步应该窄而深：先把航班、旅客、订单、收入这四个主题做透，其他的往后放。这四件事是航司经营分析的命根子，也是领导层最常问的数据。这个选择不是拍脑袋，业务中台的会员中心和订单中心上线后，第一批要喂的数据也正是这四块。

3.1 数据分层：ODS、DWD、DWS、ADS在航空场景里怎么摆

行业内关于数据分层的叫法不统一，但大部分数据中台落地时都逃不开四层：ODS贴源层、DWD明细层、DWS汇总层、ADS应用层。航司场景里的分法，我习惯这样做。

ODS层只做两件事：把订座、离港、常旅客、运价系统的表原样同步过来，加上数据日期和同步批次两个字段，不做任何加工。DWD层做清洗和标准化，比如把散落在三个系统里的旅客ID统一成“客户统一编号”，把航班号、舱位代码、航线方向这些维度对齐。DWS层面向业务过程做汇总，比如“航班日收入汇总表”“航线月度承运人数汇总表”“会员复购周期汇总表”。ADS层直接服务报表和应用，例如“领导驾驶舱”“营销活动效果分析”，这一层允许按报表需求做宽表，甚至可以冗余计算好的指标结果。

我一般建议用一行SQL来验证分层是否合理：从ADS层往回追溯，每一条数据都能沿着“ADS到DWS到DWD到ODS”的血缘链找到原始来源，且链路里每一层都有明确的所有者。如果某张ADS表直接来自ODS表，就要问一句：中间两层为什么空转？这种情况在项目初期特别常见，团队为了赶进度把DWS层跳过了，结果后来每个报表都要重复计算一遍同样的汇总逻辑，开发效率断崖式下跌。

3.2 指标口径的单一事实来源：一份能落库的指标字典DDL

很多航司的“数据口径不统一”病根，在于指标定义散落在Excel、PPT和个别开发者的脑子里。订单部门说“销售额”是含税票面价，财务部门说是扣除退票费后的净收入，两边都有自己的道理，但BI系统只能给一个数。解决这个问题的标准动作是建一张指标字典表，把每个指标的归属域、计算公式、取数来源、更新频率、负责人全部固化下来，并且这张表本身就是数据中台的一张物理表。

CREATE TABLE dim_metric_dictionary ( metric_code STRING COMMENT '指标编码，如 revenue_net', metric_name STRING COMMENT '指标名称，如净收入', biz_domain STRING COMMENT '业务域：收益/营销/地面服务/财务', auth_org STRING COMMENT '口径归口部门，如财务部', calc_logic STRING COMMENT '计算逻辑，用白话+表达式描述', source_system STRING COMMENT '源系统清单，如订座系统+结算系统', fact_table STRING COMMENT '事实表名，如 dws_flight_revenue_di', granularity STRING COMMENT '粒度，如航班/航线/日', update_frequency STRING COMMENT '更新频率，如天/小时/实时', data_owner STRING COMMENT '数据负责人，填写员工编号', status STRING COMMENT '有效/失效', create_time TIMESTAMP, update_time TIMESTAMP ) WITH ( 'connector' = 'jdbc', 'url' = 'jdbc:mysql://10.20.30.40:3306/data_govern', 'table-name' = 'dim_metric_dictionary' );

这段建表语句的作用不只是建一张表，而是把“口径管理”变成一个有主键、有时间戳、有审批流的线上协作过程，而不是群里的一句话。参数说明：granularity字段极其关键，不写粒度，指标就是废的；source_system决定了对账时该去哪个源头查数据；update_frequency属于后期数据质量稽核的重要参照，一个声明“每日更新”的指标，三天没刷就应该报警。这张表上线后，产品经理提数据需求时会先查字典，开发做ETL时会先读字典，连财务审计时都把这张表打印出来当附件——它事实上成了数据中台的宪法。

3.3 数据质量与血缘：用SQL做最廉价的口径对账

数据中台建好之后，最怕的不是没数据，而是数据不准没人知道。我通常会在数据中台里专门建一个“质量稽核库”，里面放十几张对账表，用定时任务每天跑SQL，把ODS到DWD到DWS的关键环节做数据比对。

-- 每早6点对昨日航班收入进行分层对账 WITH ods_rev AS ( SELECT flt_date, SUM(amt) AS ods_amt FROM ods_tkt_sales WHERE flt_date = DATE_SUB(CURRENT_DATE, 1) GROUP BY flt_date ), dwd_rev AS ( SELECT flt_date, SUM(net_amt) AS dwd_amt FROM dwd_flt_revenue_detail WHERE flt_date = DATE_SUB(CURRENT_DATE, 1) GROUP BY flt_date ), dws_rev AS ( SELECT flt_date, SUM(rev_net) AS dws_amt FROM dws_flt_revenue_di WHERE flt_date = DATE_SUB(CURRENT_DATE, 1) GROUP BY flt_date ) SELECT 'ODS-DWD' AS chk_layer, ABS(a.ods_amt - b.dwd_amt) AS diff_amt FROM ods_rev a JOIN dwd_rev b ON a.flt_date = b.flt_date UNION ALL SELECT 'DWD-DWS' AS chk_layer, ABS(b.dwd_amt - c.dws_amt) AS diff_amt FROM dwd_rev b JOIN dws_rev c ON b.flt_date = c.flt_date;

这个对账SQL的核心逻辑是“层间差值暴露问题”：如果ODS和DWD的差异超过阈值，说明清洗逻辑有Bug或源系统数据被回刷；如果DWD和DWS差异过大，说明汇总层口径有误或重复计算。参数上，flt_date是航班日期，必须用航班日期而不是数据写入日期，因为航司常有补录数据；阈值建议按航班收入总量的万分之五起步，运营稳定后再收紧到万分之一。对账过程不需要Flink也不需要数据质量平台，一个调度平台加几张结果表就能跑起来，是投入最小、见效最快的数字化建设动作。

4. 业务中台接棒：订单、会员、运价的API化与组装编排

数据中台跑通以后，业务中台才有底气动手。业务中台的落地，核心不是把老系统的接口用新壳子包一遍，而是把“能力”从业务流程里抽出来，做到一次建设、多处复用。航司场景里最常见的三大业务中台中心是会员中心、订单中心和运价中心，其中订单中心最复杂，因为一张机票订单要关联旅客、航班、舱位、价格、支付、退改签，还要兼容官网、App、OTA、差旅平台多种渠道来源。

4.1 业务中台能力的三种粒度：查询、事务、流程

业务中台对外暴露的服务不能只有一种形态。查询类的，比如“查会员等级”“查航班动态”，要求高吞吐、允许缓存、不涉及数据变更，适合走独立的查询服务，用Redis做一级缓存。事务类的，比如“创建订单”“扣减积分”，要求强一致、有事务边界、有幂等控制，这类服务必须走独立的交易服务，数据库层面要用本地事务或分布式事务框架兜底。流程类的，比如“退改签申请”，涉及订单状态变更、退款处理、舱位释放、通知发送多个步骤，适合用流程引擎做编排，常见的做法是BPMN模型加状态机，也有人直接用工作流框架硬编码。

很多业务中台翻车都是因为把三类服务混在一个服务里。一个“查询订单详情”的接口内部居然调了改签流程引擎，查询量一大，整个中台跟着抖动。立项阶段的PPT里就应该把这三种粒度画出来，并明确各自的服务等级协议：查询服务可用性99.95%，事务服务99.99%，流程服务99.9%。别小看这三个数字，它直接决定了运维团队要不要为每个中心准备独立集群。

4.2 以退改签流程为例：中台流程编排的一个可跑通示例

退改签是航空公司业务中台最典型的编排场景，它要同时联动订单中心、支付中心、库存中心和通知中心。传统做法是两个系统之间写死调用链，改一个规则要动三个系统。中台化之后的常见做法是把流程定义与业务代码分离，流程引擎负责编排，各中心只提供原子服务。

process: id: refund_apply_v2 name: 退票申请流程 version: 2.1.0 start: validate_order nodes: - id: validate_order type: service_task service: order_center.validateRefundable input: { orderNo: "${req.orderNo}", channel: "${req.channel}" } on_failure: end_with_error - id: calc_refund_fee type: service_task service: fare_engine.calculateRefundFee input: { orderNo: "${req.orderNo}", ticketNo: "${req.ticketNo}" } - id: check_balance type: exclusive_gateway condition: "${calc_refund_fee.refundFee > 0}" true_branch: create_refund_order false_branch: notify_no_refund - id: create_refund_order type: service_task service: payment_center.createRefundOrder input: { orderNo: "${req.orderNo}", amount: "${calc_refund_fee.refundFee}" } retries: 3 retry_interval_sec: 30 - id: release_seat type: service_task service: inventory_center.releaseSeat input: { segId: "${req.segmentId}" } - id: notify_no_refund type: service_task service: notify_center.sendMessage input: { userId: "${req.userId}", template: "refund_none" } end: done

这个流程定义里每个节点都是一个原子服务，不掺任何业务规则。参数说明：retries和retry_interval_sec控制失败自动重试；exclusive_gateway是排他网关，退票费为零时直接跳到通知节点，不走支付流程，这是航司特有的场景——不少特价票退票无退款，但必须发通知闭环；version字段标识流程版本，线上流程变更时用版本灰度，而不是直接改线上流程，这是保障稳定性的关键手段。这样一个流程跑起来以后，无论是官网还是App发起退票，走的都是同一套编排，后端服务只用维护一份。

4.3 能力开放网关：限流、鉴权与版本策略

业务中台的API不能裸奔，前面必须架一层能力开放网关，现有开源网关组件基本都能胜任。真正要设计的是限流和鉴权策略。限流要按调用方维度做，而不是全局一个阈值，OTA渠道的峰值是官网的几十倍，不能因为一个渠道的流量把其他渠道拖死。我一般按渠道维度设配额，再配一个全局兜底阈值。

routes: - id: member-info-query uri: lb://member-center predicates: - Path=/api/member/info/** filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 200 redis-rate-limiter.burstCapacity: 400 key-resolver: "#{@channelKeyResolver}" - name: JwtAuthentication - name: ApiVersion args: versionHeader: X-API-Version

这里两个参数值得细说：replenishRate是令牌桶每秒补充的令牌数，结合burstCapacity控制突发流量，按200与400起步通常够用；key-resolver指定了按渠道区分限流维度，这样即使某个渠道出现异常流量，也只是它自己的配额被耗尽，不会影响其他渠道。鉴权方面用JWT是标配，但要留意航司和OTA之间常常是服务端到服务端调用，用client_credentials模式生成长期令牌更合适，别让用户登录态掺和到服务间鉴权里。版本策略坚持一个原则：只加新版本，不改旧版本。老接口至少保留三个月的兼容期，到期后通过网关的灰度流量逐步切走，坚决不留“双版本同时改”的负债。

5. 双中台落地避坑：数据口径撕裂与组织三权分治的五个教训

双中台建设最大的风险不在技术，在治理。这一章把我这些年见过的翻车现场整理成五条血泪经验，每一条都是“现象→原因→解决”的结构，希望后来者少交点学费。

5.1 现象：营销和财务对“会员数”各执一词

项目上线两个月，营销部门说会员总数是4500万，财务部门说是2680万，两边拿着各自的数据在经营会上吵了一架，数据中台被点名批评。查到最后，差异来自“有效会员”的定义：营销部门把注册即算会员，财务要求必须有乘机记录或有积分变动的才算活跃会员。原因不是中台算错了，而是口径管理没有前置到业务源头，指标字典是数据团队自己闭门造的，业务方根本没参与。解决的办法是：指标字典必须由业务部门认领，数据中台只做执行。数据团队把指标字典表开放给业务方填写最初版本，再由中台需求委员会逐条评审，评审通过的才允许进BI系统。这个流程虽然慢，但能让后续的对账扯皮大幅减少——因为每个指标的来源和公式在表里白纸黑字写明了。

5.2 现象：中台团队变成业务方的“接口外包”

业务中台刚上线时业务方觉得真好用，后来慢慢变味：每来一个活动需求，业务方直接提给中台团队，要求几天内出一个新接口。中台团队疲于奔命，半年交付了几十个一次性接口，真正被复用的没几个。原因是中台缺少“产品化”意识，把自己当成了开发部门而不是能力运营部门。解决的方法是引入“能力生命周期管理”：新接口上线时必须回答“有多少潜在调用方”，回答不出的，不允许进中台目录，只能作为项目私有服务存在调用方自己的应用里。我在实践里还会加一条规矩：如果中台对外暴露的接口数量超过某个数，而其中复用率低于三成的比例过高，中台团队的KPI直接扣分。

5.3 现象：数据中台建好以后没人用

数据中台投入了大半年，数仓建了主题域和指标体系，结果业务方的分析师还是习惯性地去老系统的生产库写SQL，一边写一边骂“数据中台不准”。这个问题的根子在于缺乏信任——业务方发现中台某个指标跟老系统对不上之后，就不敢再用了。解决的要点不是“提高数据准确性”，而是“建立数据可信的反馈闭环”：数据中台建设一个数据质量公示看板，把每个主题域的对账通过率、上次更新时间和问题工单数全部公开，让业务方看到中台在持续治理数据，而不是捂着盖子。同时设立数据服务台，业务方收到任何“疑似数据不准”的反馈，48小时内必须给出排查结论，即使最终发现是老系统数据本身错了，也要出报告证明中台的数据是对的。这套机制跑三个月，业务方的信任度会显著上升。

5.4 现象：双中台之间出现“第二张网”

数据中台和业务中台分别建设之后，团队各自按自己的理解接数据：业务中台为了给App提供“用户画像标签”，自己同步了一份数据中台的标签表副本；数据中台为了做实时指标分析，又直接从业务中台的在线库拉Binlog。结果就是两者之间形成了无数条点对点的数据链路，跟老系统之间的蜘蛛网别无二致，双中台成了“第二张网”。解决的方案是立规：数据中台和业务中台之间的数据流向，只允许通过统一的数据同步平台走，并且必须在数据地图里注册链路；业务中台需要的数据标签，只能通过数据中台订阅接口获取，不得私自拉取。这条规矩执行起来有阻力，但必须坚持，否则双中台就白建了。

5.5 现象：业务中台的响应速度比老系统还慢

某个接口在单体老系统里50毫秒返回，中台化以后变成了500毫秒，业务方直接炸锅。排查下来原因是链路太长：网关鉴权、安全扫描、多级缓存都没问题，最后定位到订单中心为了“保证数据一致性”，每个查询操作都走了分布式事务框架，反复确认多个分库的状态，性能自然降下来了。解决的办法是“查询与事务分离”：把读操作和写操作拆成不同的服务路径，读路径只查本地缓存和只读副本，不碰任何事务协调器；写路径才走分布式事务。这个教训适用于所有做中台微服务化改造的项目，不要因为追求架构上的“统一”，把简单查询也拖进复杂事务里。

6. 用链路断点核对验证双中台绩效：一个可以复用的自检技巧

双中台上线一段时间后，老板总会问一句：“中台到底有没有用？数字化到底创造了什么价值？”这个问题很难用“上线了多少个API”“建了多少张宽表”来回答，因为那是投入不是产出。我的习惯是做一个“链路断点核对”的自检动作：挑一条真实的业务链路，沿着用户触点一步一步走完，把每一段耗时和数据来源都记录下来，找出“旧链路”和“新链路”的差异点。虽然不能覆盖所有场景，但能证明“某一条关键的、高频的业务链路确实因为双中台变快了”。

具体做法是这样的：选一条“常旅客查询行程单并补打行程单”的链路，这在航司属于高频简单场景。旧链路的调用是App→电商后端→常旅客系统→行程单系统，四次HTTP调用，其中常旅客系统的接口要查Oracle老库，平均耗时800毫秒。新链路里，会员中心的查询服务从数据中台的DWS层预取旅客行程摘要，缓存到Redis，前端接口直接被网关路由到会员中心，不触达常旅客老系统，平均耗时120毫秒。两个数字并列放在汇报PPT里，价值一目了然。这个对比动作还有一层更深的含义：它暴露了数据中台预计算逻辑是否正确、缓存策略是否生效、网关路由是否合理。链路断点核对做完，通常会顺手清掉一批“看起来有用其实没人调用的中台服务”，这不一定是坏事——砍掉冗余能力本身就是在降低成本。

我在负责过的中台项目里，一直保留“每双周挑一条链路做断点核对”的毛病，看起来不起眼，但它逼着团队去理解业务真实路径，而不是停留在自己的技术舒适区里。中台建设的价值最终体现在业务方感知到的“变快”和“变准”上，而不是架构图上的方块数量。这条自检习惯是我保留至今的后悔药，也是我判断一个中台是真的在支撑业务、还是只是有基建无产出的唯一可靠办法。希望帮到你。

本文还有配套的精品资源，点击获取