百度交易中台作为集团移动生态战略的基础设施，面向收银交易与清分结算场景，赋能业务、提供高效交易生态搭建。目前支持百度体系内多个产品线，主要包括：度小店、小程序、地图打车、文心一言等。本文主要介绍了百度交易中台的交易链路系统数据一致性的对账系统，主要从准实时对账和大数据离线对账两个方向进行介绍。

01前言

交易中台为百度小程序、百度地图打车、百度健康、百度文库、百度电商等业务提供了支付、订单、结算等交易服务能力，随着交易业务的飞速发展，交易订单量逐日增加，同时每日产生的交易GMV和清结算资金也是一个很大的体量。主要涉及交易订单、支付通道账单、交易营销、交易履约、数据中心、结算中心、商家资金池、银行打款、数据账房以及百信银行等交易内部10+的链路系统的交易数据，本篇的系统对账主要介绍了如何去实现和保障交易数据的准确性和一致性。

02系统介绍

交易系统链路核心包括收银台、交易订单、交易营销、交易履约、数据中心、结算中心、资金池及数据账房：

• 收银台：提供聚合支付能力，支持微信、支付宝、银联对公、银联对私、度小满支付、百度闪付、汇付天下和京东支付等通道，产生收银台支付单和收银台退款单；

• 交易订单：打通用户、商家、商品、库存、售后等关键业务，是驱动交易全流程运转的核心。而订单系统承上启下，作为入口，涵盖了订单流程管理、库存与营销管理、算价引擎、履约子流程、售后以及退款信息管理等，产生交易订单和退款订单；

• 交易营销：提供了营销预算、营销库存以及营销活动的能力，旨在通过促销活动和特定的交易条件来吸引顾客并推动销售增长，产生营销订单；

• 交易履约：按照商家签约商品的约束关系，兑现或取消已兑换交易商品提供的对应服务，产生履约订单和取消履约订单；

• 数据中心：收拢交易订单、退款订单、履约订单和取消履约订单，补充结算协议及商家供应商等结算中心依赖的关键数据，产生凭证订单；

• 结算中心：依据结算协议规则将凭证订单的货款结算至对应的商家供应商。产生结算账单，最终汇入商家资金池；

• 资金池：提供商家资金余额、商家资金流水以及商家打款的能力。提供商家资金池交易流水、商家资金池余额和商家付款凭证；

• 数据账房：交易中台数据的统一出口，涵盖订单、结算账单和资金池流水等，商家通过该系统可直接查询收入/其他款项/支出等流水信息，提供按天/月/年的财务对账。

整体概括如下图：

交易中台链接外部核心系统有百信银行和聚合支付渠道：

• 百信银行：承接了交易中台交易的收单、清分以及清算，从而实现了"一清"。提供“一清成交”、“一清核销”、“一清收入”以及“一清打款”的指令账单；

“一清成交”：交易中台与百信银行交互的收款账单和退款账单的指令。

“一清核销”：交易中台与百信银行交互的核销资金流水账单的指令。

“一清收入”：交易中台与百信银行交互的收取结算服务通道费用的指令。

“一清打款”：交易中台与百信银行交互的商家资金池自动打款至银行卡的指令。

• 聚合支付渠道：包括微信、支付宝、银联对公、银联对私、中行数币支付、度小满支付、百度闪付、汇付天下和京东支付等，提供渠道支付账单。

03背景&问题

随着交易中台支付业务的多元化，交易订单量迅速增长且蓬勃发展，交易支付及结算业务的复杂性也在不断的提高，总结下来，有以下几个特点：

1.交易场景多：有带货场景（分销带货和自带货）、购物车场景、多方分账场景、宿主营销场景以及跨境支付业务场景等，每种场景都有独特的交易和结算模式。

2.交易链路长：从支付到清算，需要跨收银台—>交易—>履约—>数据中心—>结算中心—>资金池—>账房，需要保障链路系统的数据一致性。

3.单量大：日订单量，月结算金额等快速增长，月交易数据体量也在不断扩张，达到了TB级别。

在这样的交易背景下，我们要保障交易数据的准确性和时效性，同时还需要保障履约、结算、资金账单以及商家付款的时效性和数据一致性，这就给我们的对账系统带来了巨大的挑战。简单介绍下交易系统运行过程中出现过的问题，如下图：

从上边的问题可以看出，基本上都是系统间数据不一致导致的，当然不仅限于这些场景。凡是有系统交互，数据交互的场景，都会出现此类问题，也就是“数据一致性”的问题。

“数据不一致”的原因有很多，如下：

1.高并发处理不当，接口幂等问题。

2.网络环境故障：机房网络抖动、数据库网络异常、消息中间件服务异常等。

3.线上代码bug, 业务方接入流程不完善等。

“数据不一致”带来的影响，如下：

1.影响用户支付下单，进而给业务方带来用户和订单的损失。

2.结算不及时，带来高客诉，更严重的可能带来资损。

3.影响财务结账，需投入大量人力来解决不一致的数据问题。

关于一致性问题，业内的解决方案已经非常成熟，从百度搜索“一致性问题”，随处都是此类问题的阐述、概念的定义、解决思路以及解决方案，比如：

1.强一致性协议: 两阶段提交、三阶段提交、TCC (Try-Confirm-Cancel)等。

2.最终一致性: 主动轮询、异步确保、可靠消息、消息事务等。

这些方案的目标都是在事中避免问题的发生，但是在现实交易的场景中，无论是系统内部，还是系统与外部环境的交互都是复杂多变、不可预知，很难完全避免“数据不一致”问题的发生。因此在事后对数据问题的发现并及时修复也非常重要。这也是本篇文章要讲述的“对账系统”的核心功能。

本篇介绍的对账系统涵盖了“准实时”对账和“T+1”离线对账两种能力：

1.“准实时”对账系统：监听交易链路系统数据库的binlog文件，上游系统针对下游系统会有数据推送，下游系统会针对上游系统推送的数据进行处理，处理结束之后进行回调或通知。

2.“T+1”离线对账系统：使用大数据计算完成对账，依托ETL工具进行数据同步，SPARK、SPAKR-SQL、AFS等大数据技术完成系统间数据的对账，及时发现数据差异、差异数据预警以及差异数据的自动修复能力。

04对账系统

4.1 “准实时”对账系统

4.1.1 系统概况

“准实时”旨在提供一套可以及时发现数据问题并及时对问题进行修复的自动化对账系统，开发专用平台，实时针对系统间的数据同步问题进行追溯和处理。设计思路如下图：

4.1.2 系统实现

1. 通过DTS平台监听交易链路系统中数据库的binlog文件，将binlog消息发送至BP。

2. 消费BP数据，采集上下游系统的数据集，抽象上下游系统间的数据结构，一次上游系统的推送和下游系统的接收作为一对元信息，进行存储。

3. 依据监控配置信息，定时监控未成对出现的对账元信息，自动调用修复接口并完成异常对账元信息的预警。

4. 对账结果可视化，依托自助化sugar报表平台，完成对账结果的可视化分析报表。

整体架构图如下：

对账服务：

对账配置：实现上下游系统间对账的自动化接入；

生产者服务：完成BP消息上游系统生产数据的解析和处理；

消费者服务：完成BP消息下游系统生产数据的解析和处理；

对账元数据：生成者和消费者产生的成对数据，每一对元数据代表上下游系统之间的一次交互；

对账服务：完成元数据的对账，依据监控配置信息，定时监控未成对出现的对账元信息，自动调用修复接口并完成异常元信息的预警；

可视化报表：基于Sugar报表平台，提供对账结果的可视化分析报表，包括差异数据统计，对账差异率及自动修复结果等。

4.2 “T+1”离线对账系统

4.2.1 系统概况

“T+1”指的是从交易日往后顺延1日，即“T+1”对账是指T+1日完成截止至T日的数据对账。对账系统分为交易链路系统内部对账和交易中台与外接系统对账，主要包括数据准备、数据核对、数据平账以及数据报表等模块。

• 数据准备：顾名思义，获取对账系统依赖的全部数据。

• 数据核对：采用数据比对手段，双方数据未匹配成功的视为差异。

• 数据平账：完成差异数据的二次对账，消除跨账期差异，实现最终差异数据自动修复和预警。

• 数据报表：完成对账结果的数据分析及统计，提供数据报表的可视化展示界面。

4.2.2 交易链路系统内部对账

• 数据准备

通过ETL数据同步工具，T+1日完成T日交易数据到离线AFS文件系统的同步，完成afs文件和hive meta表的绑定。使用Pingo平台完成同步数据任务的调度并例行执行。

• 问题发现

对账系统的目标是发现系统问题，通过系统对账发现数据流转过程中的数据不一致问题，可以归结为丢数据、重复推送、结算协议问题、系统线上功能bug等。

• 数据核对

1.交易链路系统的数据量较大，对账系统依赖的数据量可以达到TB级别，常规服务的对账根本无法完成，基于spark、spark-sql、afs等大数据技术实现系统的对账能力。

2.采用单向对账的方式，以上游系统数据为基准，上游产生了数据，一定会同步到下游，下游会有一条数据与之成对匹配，未完成匹配的订单则为异常订单。

• 差错处理

下游系统提供数据检查和数据修复接口。数据核对完成之后，启动差错处理，调用数据修复接口之后，再次调用数据检查接口，最终完成数据修复；差错处理设置重复3次，处理3次仍未修复的数据会自动进入预警系统，以邮件和短信的方式预警到团队和个人，最终由人工处理解决。

4.2.3 交易中台与外接系统对账

• 数据准备

1.例行下载支付通道、百信银行的交易账单。不同支付通道配置对应的账单模版，依据账单模版解析账单数据，操作账单数据同步到AFS文件系统，同时记录账单同步完成的标记文件。

2.例行同步交易中台交易数据到AFS文件系统，使用ETL数据同步工具完成数据同步，同时记录数据同步完成的标记文件。

• 问题发现

对账的目标是保障双方数据一致，通过系统对账发现：与外接系统的数据不一致可以归结为数据跨账期、外接系统处理异常、状态不一致、丢数据等。

• 数据核对

1.对账系统依赖的数据量较大，数据量达到了TB级别，采用spark、spark-sql、afs等大数据技术实现系统的对账能力。

2.采用双向对账的方式:

①以百度交易中台数据为基准，百度交易中台产生了数据，外接系统应有一条数据与之成对匹配，未完成匹配的数据则为异常数据（百度单边）。

②以外接系统交易数据为基准，匹配百度交易中台的交易数据，包括交易数据金额、交易数据状态等，未完成匹配的数据则为异常数据（外接系统单边）。

③平账服务，消除因为跨账期产生的差异订单。

a.消除百度单边差异，参与平账的外接系统交易账单去除账期的限制，采用近1年的全部账单进行平账。

b.消除外接系统单边差异，参与平账的百度交易数据去除账期限制，同样采用近1年的全部交易数据进行平账。

• 差错处理

多次平账之后仍未消除的差异视为异常数据，异常数据会自动进入预警系统，以邮件和短信的方式预警到团队和个人，最终由人工处理解决。

05结束语

百度交易中台聚合了订单、支付、履约以及结算等交易能力，随着接入的业务方越来越多，交易场景也在多元化，有流量主带货交易、直播带货交易、宿主带货交易、多方分账交易等等。多元化的交易场景带来了复杂的结算流程，交易结算的时效性、准确性需要稳定可靠的交易数据流来保障，百度交易中台的对账系统会不断进行完善和升级，在以保障交易数据流的稳定为前提，输出给业务方稳定、可靠的交易对账后台，助力业务持续发展。

参考注释：

“一清”：央行规定只有银行类机构(银联、网联、银行等)和取得人民银行支付业务许可证的支付机构(第三方支付机构)才能开展收单业务以及进行资金的清算。我们称以上机构为“一清机构”。在互联网支付业务中依托上述拥有支付牌照的机构，在资金结算给商户的过程当中只发生了一次清算，该过程即为“一清”。“一清”业务是合法的，有央行监管的，客户的资金是有保障的。

“DTS平台”：数据库传输服务，提供数据迁移、数据同步、数据订阅于一体的数据库数据传输服务。

“Sugar平台”：智能 BI 及数据可视化工具。Sugar BI 基于百度 Echarts 提供丰富的图表组件，无需SQL、全流程智能化操作，让用户不写一行代码，分钟级即可完成自助 BI 报表分析和可视化大屏。

“Pingo平台”:    是基于Spark引擎提供的集数据导入、数据计算以及工作流服务、交互式开发环境和资源管理服务为一体的大数据处理平台。

“TDS平台”:    是基于图灵的数据建设解决方案，提供 数据开发、数仓管理、监控运维、资源管理等一站式服务的数据开发平台。

“AFS”：AFS（Andrew File System）是一个分布式文件系统，它为大规模数据存储和处理提供了高效、可靠和可扩展的解决方案。