简介面向企业数字化转型规划者、中台架构师及大数据/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”表示被咨询别看这个纸面功夫简单它能让上线后扯皮的概率下降一半属于投入产出比极高的前置动作。运维事项业务中台数据中台基础设施团队订单API可用性RIC会员主数据一致性RCIODS层数据同步链路CRI指标字典口径修订ARC3. 数据中台先行从数据地图到指标字典的最小可跑通方案数据中台如果一上来就铺几十个主题域大概率半年见不到成果。航空公司的数据起步应该窄而深先把航班、旅客、订单、收入这四个主题做透其他的往后放。这四件事是航司经营分析的命根子也是领导层最常问的数据。这个选择不是拍脑袋业务中台的会员中心和订单中心上线后第一批要喂的数据也正是这四块。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里价值一目了然。这个对比动作还有一层更深的含义它暴露了数据中台预计算逻辑是否正确、缓存策略是否生效、网关路由是否合理。链路断点核对做完通常会顺手清掉一批“看起来有用其实没人调用的中台服务”这不一定是坏事——砍掉冗余能力本身就是在降低成本。我在负责过的中台项目里一直保留“每双周挑一条链路做断点核对”的毛病看起来不起眼但它逼着团队去理解业务真实路径而不是停留在自己的技术舒适区里。中台建设的价值最终体现在业务方感知到的“变快”和“变准”上而不是架构图上的方块数量。这条自检习惯是我保留至今的后悔药也是我判断一个中台是真的在支撑业务、还是只是有基建无产出的唯一可靠办法。希望帮到你。本文还有配套的精品资源点击获取
