携程金融：如何用 OBKV 构建千亿量级的数据存储方案

本文作者：gaosf，携程高级开发经理。

携程金融，作为携程集团旗下的金融服务平台，自2016年成立以来，凭借强大的数字科技实力，为广大用户提供了包括旅游分期消费、小微企业主金融等在内的多样化便捷的旅途金融服务，助力用户在旅行消费过程中轻松获取资金支持。

作为支撑携程金融业务平稳运行的研发团队，我们在2024年上半年成功实施了一项数据存储升级实践——采用OBKV构建了千亿级指标的数据存储方案。本文将从项目背景概述、实施方案设计以及项目成果这三个维度分享这一项目的推进历程与经验。

项目背景

在金融场景下，非常依赖用户指标数据做一些核心业务逻辑的决策，比如风险决策、个性化服务等，而这些数据都是纯KV对的形式。数据由大数据平台产出，通过离线计算任务的方式生成，落到Hive表中，之后将数据从Hive表再导入MySQL等存储引擎中，供业务进行实时调用。

总体数据规模在几千亿+KV对，采用增量更新的方式，每天的更新规模为数百亿个KV对。

部门几乎所有的核心业务系统都依赖于这项服务，业务方对我们提出了两个诉求：

• 针对写入，要尽可能快，尤其是高优任务2小时内写入完成，所有写入任务不允许超过24小时。
• 针对查询，要求在50ms内完成，查询耗时越短越好。

因此我们需要一个能够支持快速写入且查询性能稳定的KV存储方案。

起初（2016~2019年），我们使用 HBase 存储，因为 GC 停顿等问题，无法满足业务查询性能的需要。2020年，我们开发了一套 MySQL 存储方案，查询性能满足要求，并且稳定运行了近4年。直到2023年新需求上线，需要写入的数据量翻倍，单表数据总量达到300亿个KV对，每日例行更新的数据峰值达到500亿，且类似这样的业务需求还在增加。此时MySQL方案写入能力已经到达上限，扩容也比较困难，且IT成本较高，于是开始了新一代KV存储方案的探索。

项目方案

2024年初，我们开始了整个应用架构改造和存储方案的探索和引入。

1.在应用架构方面的改造。

（1）  将存储引擎进行业务层抽象，以便快速接入新的存储引擎。

（2）  对数据消费队列改进，将基于Kafka的消费队列改为基于文件的消费队列，以便对导入任务进行灵活的暂停、续写、重试、终止等控制。

（3）  自研了轻量级的任务调动框架，以实现对数据导入任务进行全生命周期的管理，如通过api进行任务的启停、依赖配置、优先级动态调整等。

最终，在应用侧，可同时引入多种存储引擎，且各个引擎间读写相互隔离，实现了存储引擎的快速、低成本的扩展接入，并且有比较灵活的运维能力。

2.存储引擎的探索。

在存储方面，我们需要存储容量可动态扩展，写入性能高，至少满足历史峰值需求（500亿kv/天），查询要快且稳定。

2024年7月份我们将OBKV快速接入系统。下图是我们在生产环境中的验证结果，并和此前的MySQL方案进行了对比，

针对我们的场景，将“每分钟能写入的kv对数量”作为业务侧的一个重要衡量指标。

在使用MySQL存储方案时，部署了64个节点，采用分库分表方案，写入速度（仅写入）的历史最大值达到 6000w(kv对)/min（连续运行1小时后，server cpu 告警），读写都开启且不影响查询的状态下写入速度是2000w(kv对)/min（连续运行24小时后，server cpu 告警）。

上线OBKV后，部署了一个9节点的集群，为了探索写入能力上限，在不考虑读性能的前提下，最大的写入速度达到9600w(kv对)/min，不影响查询性能的前提下可以达到6000w(kv对)/min的写入速度。

在响应时间方面：在同等条件下，OBKV批量写入速度是1.3w/s，批量查询速度1.8w/s；由于MySQL的分库分区方式，导致批量写入和批量查询的数据相差较大，分别是5300/s、41.7w/s。在响应时间方面，OBKV写入的平均速度是15ms，P99能够达到20ms，查询响应时间平均3ms，P99时10ms；MySQL写入比较吃力，达到900ms，查询的性能与OBKV相差不大。

在稳定性方面： OBKV写入限流6000w/min，连续写入24小时，查询没有任何波动，而MySQL在写入速度超过3000w/min后，查询时间飙升。

在存储空间层面：在单副本维度，全量数据OBKV的空间占用是MySQL的1/5。

3.OBKV双集群部署。

OBKV于我们而言是一个比较新的产品，在携程集团内部也是首次引入，相关的运维经验缺乏。可MySQL方案已经无法很好支撑业务需求，能尽快把OBKV用起来。

综合考虑下，在业务层又设计了一套双机房部署方案，来尽可能增加可靠性。核心思路是两个对等的机房进行双写，任何一个集群单次写入失败，都使两个集群重试，来保证两个集群间数据的一致性。在查询时，优先查询同机房的集群，超过指定时间（如20ms）后降级查询另外的机房。

该方案的优势在于：

• 在成本可控范围内，最大化提升整个服务的可靠性。因为OBKV集群只需要9个节点，即使部署两份集群，节点数也远远少于MySQL单个集群，从成本角度考虑完全可以接受。
• 可以减少DBA的运维压力。DBA进行单集群的运维、增删节点、更换磁盘或进行其他的操作都可以直接进行，整体服务不会受到影响，为DBA进行后续OBKV性能调优、运维预留了充分的探索空间。

项目成果

自2024年7月17日起，OBKV在携程金融生产环境正式应用，已稳定运行至今。原来在MySQL的流量100%切换至OBKV，取得的成效显著。 

• 写入性能优秀：限流6000w/min，每天可写入864亿数据，远高于业务需求的500亿，高优任务2小时完成率从60%提升到了近100%。
• 查询性能稳定：限流的上限持续写入，查询无明显波动，p99约10ms，p999低于30ms几乎维持在15~20ms。针对查询和写入性能，未来也可以通过集群扩容进一步提升性能，
• l存储成本骤降：OBKV和 MySQL的数据压缩比为1:5，存储总空间降低72%，硬件成本降低近60%。
• 应用架构精简：得益于OBKV天然的分布式能力，我们无需处理复杂的分库分表逻辑，应用逻辑被极大简化，换算成应用的机器数量也极大减少，应用CPU核数精简了50%。

本次数据存储方案探索较为成功，感谢OceanBase开源团队和OBKV团队在我们项目落地的过程中全力支持。