携程金融基于 obkv 的千亿级指标数据存储方案-c7电子娱乐

作者简介：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团队在我们项目落地的过程中全力支持。