FSI Meetup 2025 Q4 - PayPal 金融交易数据对账系统

场次笔记

PayPal 简介：

PayPal 是一家全球支付服务提供商，年支付处理额达 1.7 万亿。
业务覆盖全球 200 个市场，拥有 4.3 亿个活跃账户。
每秒处理约 900 笔交易，在黑色星期五和网络星期一等节假日期间达到峰值。

关键问题：

确保海量交易的准确性并完成对账。
对 PayPal 内部多个系统、外部处理机构和网络之间的交易进行核对。
匹配交易，确保不存在数据或资金差异。
验证财务记录是否准确反映客户的实际付款。

对账流程：

交易流经 PayPal 系统，并记录在多个内部账本中。
交易被发送至外部处理机构进行清算，并由网络确认。
PayPal 将交易款项结算给商户。
对账需要匹配 PayPal 内部系统、处理机构确认信息以及资金结算汇总（当日结束、T+1、T+2）中的交易。
主要目标：确保交易不丢失且不存在差异。

对账的重要性：

三方匹配问题：PayPal 内部账本、外部处理机构记录和网络确认信息。
对财务准确性和客户信任至关重要。
确保财务记录反映客户的实际付款。

高层架构：

重点介绍 PayPal 如何实现近实时对账。
用于应对问题规模和复杂性的技术与策略。

业务影响：

对账时间从 24 小时缩短至 15 分钟。
准确性得到提升，差异降至最低。
增强了客户信任并提高了运营效率。

PayPal 对账系统的进一步讨论

三方匹配问题： PayPal 内部账本：

记录 PayPal 系统内的交易。

外部处理机构：

在其本地系统中登记交易。

网络确认：

确认交易是否已成功完成。

职责：

PayPal 负责匹配从交易进入系统到与商户完成结算的每个阶段。
由于交易量巨大，人工对账并不可行。

带规则引擎的自动状态机：

使用自动状态机和高层规则引擎。
配置为处理与外部供应商的交易处理流程，以及确认信息和资金汇总的时间要求。
确保高效完成交易对账。

对账的重要性：

对于了解“记录中发生了什么与实际发生了什么”至关重要。
确保交易可审计，并符合监管标准（PCI DSS）。
清晰记录交易的入账和结算时间。

遗留系统目前的不足：

遗留系统依赖日终批处理。
使用“存储后处理”机制，交易全天累积，到日终才进行对账。
为避免影响性能和延迟，事实来源并非直接来自运营数据存储。
使用从 Oracle GoldenGate 获取数据的 ETL 系统。
ETL 流水线涉及转换和格式化，可能导致数据不匹配或不一致。

改进需求：

从批处理转向近实时处理。
减少对 ETL 系统的依赖，尽量降低数据转换问题。
加强自动化，确保对账准确且及时。

遗留系统的问题：

由于需要等到日终再处理所有交易，系统存在延迟。
交易匹配和账簿关账只能在日终完成。
这种延迟是一个严重问题。

目标：

迁移到云端的新一代平台。
利用 AWS 基础设施解决上述问题。

新解决方案的关键目标：覆盖支付生命周期的端到端数据完整性：

从记录进入实时支付处理系统的那一刻起确保数据完整性。
跟踪 PayPal 内部多个系统中的交易。
使用正确的标识符和时间戳关联所有交易。
将发送给处理机构的出站文件与从网络或供应商收到的入站记录进行匹配。

自动化的状态驱动匹配逻辑：

从“存储后处理”机制转向“流式处理”机制。
缩短整个对账周期。

实时监控：

在匹配内部系统交易或外部供应商记录时识别异常。
记录所接收记录与本地账本交易匹配失败的异常。
由运营团队处理这些已记录的异常。

技术架构：数据注入：

向对账系统注入数据的数据源。

对账流程：

执行对账所涉及的方法和流程。

对账结果存储：

对账结果的存储方式。

运营团队的使用方式：

运营团队如何利用对账异常并采取行动。

高层技术对账概览范围限定：

对上游支付处理系统进行了抽象，不在讨论范围内。
重点从实时支付卡处理系统开始。

实时支付卡处理系统：

使用 EKS 服务每天接收数百万笔交易（预计每日约 3 亿笔交易）。
每笔交易都记录在 AWS DynamoDB 中，后者作为事实来源和运营数据存储。

数据流：

[ 1 ] 从 DynamoDB 到 Kinesis Data Stream：
DynamoDB 中记录的交易通过 Kinesis Data Stream 进行流式传输。
Kinesis 管理交易顺序。
[ 2 ] Amazon Data Firehose：
根据不同业务参数对交易进行分桶和分块。
[ 3 ] AWS S3：
交易记录在 AWS S3 中。
S3 是交易的辅助数据存储，但对于文件处理而言是主要存储。

对账流程：

[ 1 ] PayPal 中的入站交易：
PayPal 中已处理的交易会转换为文件格式并存入 AWS S3。
[ 2 ] 外部合作伙伴处理：
分块文件被转换为相应文件，并由外部合作伙伴处理。
外部合作伙伴返回的入站记录会存入 S3。

以 AWS S3 为中心数据源：

S3 同时保存内部交易痕迹，以及以入站文件形式接收的外部已处理交易。

数据处理：

EventBridge 调度：
每 15 分钟触发 AWS EMR 集群上的 Apache Spark。
使用预配置的规则引擎，对 S3 中的交易进行分布式处理。

规则引擎：

由多个状态图组成。
对交易进行分类并确定终止状态。
包含基于市场运营、外部合作伙伴以及数据导出/导入截止时间的复杂规则。

技术对账架构 Apache EMR 集群和规则引擎：

Apache EMR 集群利用规则引擎匹配交易。
对账成功的结果会写回 AWS S3。
异常会发送至 AWS EventBridge，由其触发 Lambda 函数，对异常进行信息补充并将报告写回 S3。

存储和运营方面：

数据以 parquet 文件形式存储在 S3 中。
在 parquet 文件之上配置 Apache Glue Catalog。
运营团队可以使用 Amazon Athena 以 SQL 方式查询数据。
基于 Glue Catalog 构建的定制 UI 门户，可提供特定日期、结算或合作伙伴的详细对账状态和结果。

架构亮点：双活架构：

跨多个 AWS 区域运行。
以零恢复点目标（RPO）和零恢复时间目标（RTO）确保高可用性。
如果一个区域宕机，另一个区域可以无缝处理交易。
使用 Amazon Kinesis Data Stream 和 DynamoDB 管理进行中的交易，以确保跨区域一致性。

技术和架构决策：

AWS EMR 与 Redshift 的比较：
曾考虑使用 Redshift 构建数据湖解决方案，但出于成本效益考虑选择了 AWS EMR。
将 EMR 集群作为核心处理系统的扩展，利用现有的 S3 数据存储。
通过使用 AWS EMR，以低成本实现了问题所要求的解决方案。

新对账解决方案的业务影响准确性：

从三个 9 提升到四个 9。

速度：

对账时间从 24 小时缩短至 15 分钟一个周期。
无论交易量是 100 万笔还是 3 亿笔，横向扩展集群均可确保处理时间稳定（最长 30 分钟）。

风险降低：

更快的对账速度（15 分钟内）最大限度地降低了潜在欺诈和风险。
可以更快地处理系统或外部问题。

成本优化：

出于成本效益考虑，选择 AWS EMR 集群而非数据湖解决方案。
EMR 集群和 Lambda 函数按需运行，而非持续运行。
计算实例的生命周期有限，处理完成后会释放资源并尽量降低成本。

FSI Meetup 2025 Q4 - PayPal 金融交易数据对账系统

回顾系列

场次笔记