StarRocks在支付对账领域的应用

原创冯现宽之家技术

2023年11月28日 04:32

关注“之家技术”，获取更多技术干货

总篇234篇 2023年第48篇

1. 前言

对账是企业为了核实财务交易准确性、管理库存和了解业务绩效而进行的核对和调解过程。

因为对账涉及到支付系统、订单系统、财务系统、结算系统和权益系统等多个系统，需要确保这些系统的数据能够有效地对应和匹配，需要一种高效可靠的方式以解决跨系统的数据匹配。

2. 支付闭环

2.1

支付背后隐藏的细节。

一笔订单的完结，C端用户看到的仅仅是下单、支付简单的流程，实际上背后有一套更复杂的流程实现支付的闭环。比如支付成功通知、订单结算分账、结算成功通知、账务处理与报表生成等，以下是一个简化的支付闭环流程：

3. 支付对账架构的演进

3.1

对账1.0，All in MySql

基于Mysql数据库完成对账，将涉及到的分布在不同服务器上的业务库同步到一个大磁盘服务器上的Mysql实例下，在此实例下完成跨库查询、数据的匹配。

此方案虽然解决了跨库查询的问题，但是因为有些表数据量达到亿级别，导致sql查询缓慢，对账效率低下，比如月度退款对账sql查询需要3个小时。

3.2

对账2.0，利用大数据技术提速

使用 ETL（Extract, Transform, Load）方法来实现数据的提取、转换、加载，将对账需要的不同业务系统的表数据同步到数仓，在数仓完成跨库跨表的关联，以便进行有效的对账分析。

3.3

对账2.0的缺陷

这种方式虽然比[对账1.0]方案效率有所提升，但是对账场景中有调账、补账的操作，这部分修改、新增的数据目前只能T+1同步到数仓，导致部分对账场景不适用，需要按照【对账1.0】方案处理。

4. 对账3.0，Starrock极速提效

4.1

引入StarRocks的背景

但随着数据累积和数据量的增长，加之业务线和财务精细化的支付账单需求，当前架构日渐吃力，业务上呈现出以下痛点:

人力成本高，每次对账都需要4人/日，出现问题每次都需要财务人员找开发人员查询，重复的工作浪费人力。
时效性低，基于大数据Hive的查询，虽然解决了大数据量多表关联的问题，但是执行速度的问题没解决。
机器成本高，部分场景仍然需要基于Mysql，需要将多个mySql主库同步到一台高配的机器上的MySql服务上来支持跨表跨库查询。

为了给业务增长提供更强的助力，我们开始寻找一款可以支持更灵活的数据模型、具有高效的并发查询性能、运维可以支持的实时性 OLAP 数据库产品。

通过以上产品能力上的初步对比和查询性能的对比，我们已经比较倾向于选择 StarRocks。支持亿级的大表关联、秒级查询，同时支持实时写入，兼容Mysql协议等特性，符合我们支付对账场景的业务需求。

4.2

基于StarRocks的对账3.0架构

和2.0对账方案比整体架构上变化不大，StarRocks替代了Hive，基于StarRocks的高性能查询特性补充了若干定时任务，并且将原来基于Hive语法的语句调整为SQL语句，基于MySQL语法的语句需要很小的变动（虽然官方兼容MySQL协议，但也发现有些SQL语法不兼容）。

对账任务平台中的任务，主要基于SQL和Python开发，迁移、新增自动化任务也完全基于熟悉的技术栈，学习成本很低。另外为了防止MySQL主库和Starrock库中的数据不一致，新增了数据校验任务，一旦发现存在差异会报警，并触发DataX数据补偿机制。

4.3

对账模型的选择

刚开始就是因为错用了更新模型，产生存在主键重复的数据存在，导致对账数据异常，所以要结合业务数据特性从明细模型、聚合模型、更新模型、主键模型中选择符合业务场景的模型。

4.4

Flink实时数据同步

数据同步工具和中间件，考虑到公司现有的技术支持和业界成熟度，最终选择DataX同步存量数据，DataX的数据同步可以通过页面操作的方式同步，Flink监控binlog同步增量数据，虽然StarRocks 提供了用于和Flink集成的connector，但还是相对复杂一点。

同时要注意，Flink不支持char类型、timestamp类型，要替换成对应的varchar和datetime。下面是实现同步的一些关键步骤：

1. 建StarRocks表db1_flink_table1

2. 定义Flink表（对应StarRocks表）xxxxtable

3. 创建Flink SQL任务，向StarRocks写入数据

如果有些需求无法使用Flink SQL实现，需要Flink 自定义任务向StarRocks写入数据，然后自行编码实现。

4.6

SQL语法的适配

对账有18个场景，每个场景下的SQL都需要适配StarRocks,但因为Starrocks兼容SQL语法，适配成本很低，一天的时间完成了所有的SQL适配。

下面是语法的对比，左侧是MySQL，右侧是Starrocks，基本一直，如果select 字段包含子查询的时候StarRocks不支持，需要调整。

4.5

落地效果

综合比较，相比于之前的架构，现在的架构查询性能方面提升明显。最复杂的一条对账Sql执行时间从1小时缩短到50秒，主键模型下查询，关联查询相较于此前基于 MySQL 的架构，基于 StarRocks 的架构性能平均可以提升50-70倍以上。存储成本相比于 MySQL+Druid，降低2倍以上。由此带来的人力成本也由以前的3人/日缩减到1人/日释放更多人力去完成更有挑战性的工作。

5. 总结

当前，对账工作中涉及多个场景的数据合并仍依赖人工操作，这种方法不仅效率低下，而且容易产生错误。因此，我们计划将这一过程升级为程序定时自动对账、生产报表。此外，利用StarRocks的最新特性，特别是物化视图，能够进一步提高查询的效率，持续提升对账效能。

作者简介

冯现宽

■ 服务端研发部-服务端买用技术团队

■

2016年加入汽车之家，目前任职于服务端研发部-服务端买用技术团队，主要负责保险、支付和结算相关业务。

阅读更多：

▼ 关注「之家技术」，获取更多技术干货 ▼

继续滑动看下一个