从v3.1到v4.3，OceanBase稳定支撑快手PB级核心业务场景

从v3.1到v4.3，OceanBase稳定支撑快手PB级核心业务场景

本文摘自《OceanBase社区版在泛互场景的应用案例研究》电子书，点击链接即可获取完整版内容。
作者：胡玉龙，快手运维负责人
快手APP是中国流行的短视频和直播应用之一。作为普惠数字社区，快手不仅让数亿普通人记录和分享生活，更帮助人们发现所需、发挥所长。平台汇集内容涵盖生活方方面面，用户可以通过照片和短视频记录自己的生活点滴，也可以通过直播与粉丝实时互动，在技术赋能基础上提升用户幸福感。
那么，像这样一款日均访问人次超千万的短视频App，当面对高并发流量时该如何及时有效地处理用户请求？我们早期的做法是：通过在后端配置多套MySQL 集群来支撑高流量访问，从而解决大数据量存储和性能问题，但这种传统的MySQL分库分表方案存在不少问题。而在引用OceanBase后，核心业务场景中的技术兼容性、运维便捷性、数据同步性、业务稳定性、资源扩展能力等性能都有了极大提升。同时，在使用OceanBase过程中，我们对版本进行了持续更新，积累了不同版本的实践经验。
一、从MySQL分库分表到“增强版MySQL”

自2011年成立至2021年上市期间，快手日活用户突破数亿。如此大规模的流量，一方面推动了直播、电商等业务飞速增长；另一方面，却给底层存储系统带来了前所未有的压力。虽然通过传统数据库分库分表方案在一定程度上缓解了压力，性能得以提升，但运维的复杂性和不可持续性为系统埋下了更大的隐患。
以App负载的“订单业务”为例，当业务总数据量超过150TB时，MySQL的存储瓶颈和性能短板越来越明显。为缓解这些问题对业务带来的影响，我们选择通过分库分表方案应对。然而，业务持续增长使底层数据库的分片数不断增加，以至于线上MySQL分片数达到300+，不仅没能彻底解决存储问题，还引起了更大的运维复杂度。我们需要不断对应用进行改造和适配以解决分库分表带来的难题。
短视频App的业务峰值QPS（每秒查询率）能达到百万以上，对性能要求极高。在此情况下，单个集群需要很多的MySQL节点，无法做到在业务高峰期保证业务请求及时返回，并且不论是中间件还是数据下游所有链路，都需要高性能硬件以支撑产品稳定性方案。
此外，我们的TP业务不仅要求具备强事务和实时读写的能力，同时伴有AP需求，为了保证系统稳定可靠，需要采用MySQL结合 ClickHouse、Elasticsearc或Doris的方案，且可能需要增加更多数据副本，这无疑会带来更高的硬件成本。
我们意识到，分库分表方案只能尽可能缓解而无法从根本上解决问题，亟需一款既能满足业务需求，又具备高性能、灵活扩展，还能降低运维复杂度的分布式数据库解决方案。
在分布式数据库的探索之路上，我们最初尝试了某品牌的分布式数据库。但在使用过程中发现其在写入性能、运维方式等方面存在问题，比如运维平台比较简单、 难以满足DBA的需求，且很多内核问题难以得到解决。因此，我们尝试选择了 OceanBase。
通过对比测试发现，当单表数据量超过10TB且不断增长时，某品牌分布式数据库架构进行DDL操作预计需要一周时间，而OceanBase仅需不到一天即可完成。由于部分业务持续增长，需不断加表和添加源数据，导致DDL操作繁多。该分布式数据库采用小分区的方式，在数据量大的情况下会致使整个region数量显著增加，一旦出现宕机、扩缩容或节点替换需求时，很可能影响业务稳定性。相比之下，OceanBase采用大分区，上述的业务操作可以在小时级甚至最多天级单位内完成。
二、核心业务场景应用 OceanBase的收益

截至2023年年底，快手短视频App有8个OceanBase集群，机器规模超过200台物理机，数据量超800T，其中最大的集群数据量超400T。最初，我们使用OceanBase 3.1版本，后期升级到4.3版本。所有集群都提供线上服务，涵盖核心系统交易核对系统、支付网关业务系统，以及替换MySQL主库以承担高并发写入的业务。在迁移到OceanBase4.1版本后，集群在业务收益和稳定性方面均得到显著提升。下面以两个核心业务场景为例，介绍OceanBase的实际落地效果。
（一）交易核对场景

作为短视频平台，电商是快手最重要的业务组成之一。通常情况下，该业务日均流量QPS保持在8-9万的平稳水平 。当进行大型直播期间，用户流量会急剧增长，QPS会迅速飙升至平时的十倍甚至百倍，达到百万级别，此时数据量即便经过压缩，也会达到百余TB，这就要求数据库的快、稳和抗压。

• 毫秒级延迟。业务对延迟极度敏感，对TPS有着极高的要求，通常情况下要求延迟为毫秒级，如无法在规定时间内完成请求则会影响核对结果，出现数据不准确问题。
  
• 稳定性更强。如果数据库抖动会导致大量的核对失败，在交易核对场景下，数据库不仅需要在日常流量峰值时保持长期稳定，还需要在流量高峰时没有抖动。
  
• 抗压力强。当数据量超百TB，单集群数据的单副本达到20TB左右时，随着单表数据的增大，对系统资源消耗会越来越多，进而影响数据库的响应时间。因此，读写请求峰值达到QPS百万级要求数据库足够平稳，响应时间不受影响。
  

在引入OceanBase之前，交易核对场景的读写操作均在MySQL上进行。针对大表问题，我们采用了传统的分库分表方案，将大表拆成多个小表，并将业务读写流量拆分到多个MySQL实例中。然而，分库分表方案在跨库数据一致性和跨库事务原子性等方面存在局限，容易在复杂和异常情况下导致数据不一致问题，进而使得数据核对结果不准确。例如，可能出现没有记录退款以及扣款金额不准确等现象，最终引发经济损失。
经过方案调研和选型，由于OceanBase分布式架构具备天然的水平扩展能力，因此在数据量不断增长时，只需要水平扩展集群的存储和计算能力，即可解决大表查询和存储问题；同时，本身具备原生分布式能力，更擅长处理分布式事务。使用OceanBase后，上游业务直接写入MySQL集群中，每一条数据在写入上游MySQL分片时，会通过Binlog实时同步到OceanBase中。在数据核对查询时，系统会同时对上游MySQL和下游OceanBase进行相同的查询，并对查询结果进行比对，从而保证整个账务系统中订单状态的正确性。
图1显示了“交易核对业务线上表现”，日常QPS在左上侧，数据量约为9万左右，右上侧为响应时间, 平均时延不超过10ms, 峰值时延达到1万毫秒，这是由于每晚凌晨全量合并后，业务会额外启动一个特定线程去删除大量历史数据, 导致此时时延偏高, 但业务方对此可以接受。下方的两个曲线图是写入量，按事务统计的日均TPS在1万左右，响应时间为5-10毫秒，OceanBase响应时间满足业务对延迟的要求，同时系统稳定性得到保障。

图1 交易核对业务线上表现
（二）支付业务场景

支付业务是电商的实时业务，一方面是面向商家、客服查询直播收益，另一方面是支付网关相关的聚合查询，该业务有三个显著的特点。
（1）数据量大。 支付业务的数据量较交易核对业务更为庞大，单集群数据量可达百余TB，最大集群数据量已超400TB，单表数据量也达到10TB以上。
（2）复杂聚合。 该业务写入流量远高于查询流量，且所有后台查询均需通过支付网关，涉及对大量数据进行聚合查询，可能会聚合数十甚至上百张表，业务对查询性能要求高。
（3）频繁DDL。 因查询不具备固定性，为提升速度，业务需要频繁加索引。此前方案是在数据写入MySQL集群的同时，同步数据到Elasticsearch集群，借助Elasticsearch的搜索能力，为业务提供复杂的AP查询分析。虽然新方案在一定程度上能满足业务的需求，但仍存在以下3个问题。

• 数据实时性不够好：数据在写入MySQL之后再同步到Elasticsearch，实效性较差，可能因为MySQL的持续大量写入而产生了数据延迟。
  
• 成本高：因为接入了Elasticsearch集群，业务不仅仅需要考虑MySQL的成本，同时还有Elasticsearch集群的硬件成本和维护成本。
  
• 运维更复杂：需要同时兼顾MySQL集群和Elasticsearch集群的运维。
  

在引入OceanBase之后，其在线扩展性轻松解决了大数据量的存储问题，HTAP能力在保证数据写入的同时提供实时查询分析。在该业务场景中，OceanBase的复杂SQL分析能力不弱于Elasticsearch。此外，OceanBase的在线加索引能力支持业务可以随时进行DDL变更。采用OceanBase替换原MySQL+Elasticsearch方案后，不仅省去Elasticsearch服务及硬件，还大幅降低MySQL硬件成本，整体机器资源节省达50%，且性能满足业务查询要求。如图2左侧为MySQL+ Elasticsearch方案，右侧为OceanBase方案。

图2 数据写入和查询分析的MySQL+ Elasticsearch和OceanBase方案
图3是支付业务的线上表现，写入量在5-7万之间，查询不到1万。蓝色的线表示在删数据，绿色的线是写和读的响应时间。

图3 支付业务线上表现
基于OCP能便捷完成集群扩缩容、监控与告警，其管理着多套OceanBase集群。此外，业务侧非常喜欢使用ODC，这是OceanBase的一个查询平台，用于验证数据是否写入成功以及写入结果是否正确。因其界面操作满足日常数据库访问需求，且版本更新迅速、问题处理及时，所以百人级别的业务都在使用。
三、从OceanBase3.1版本升级至4.3版本的经验和效果

到了2024年9月，快手的数据量快速增至PB级，并从原来OBServer 190多个节点增长到近300个，线上共部署9套OceanBase集群。在数据量剧增的情况下，我们开始升级至OceanBase4.x版本。其中，数据量较大（20T以上）的集群已经升级至4.2或4.3，还有一半数据量较小的集群（10T以下）仍在3.x版本中。那么，相较3.x版本来看，4.x版本性能有哪些提升呢？
从图4来看，4.x版本的数据似乎没有增长。但如果在3.x版本不升级的情况下，随着近一年业务的发展，数据量会增长约1.5TB，数据节点数量也会提高一倍。这就体现了版本升级的妙处，OceanBase4.x版本相较于3.x版本能够更极致地压缩数据，节省存储空间，从而节约存储和机器成本。

图4 4.x版本和3.x版本集群列表对比
此前，我们使用分布式数据库某DB来支撑支付业务，它使用range分区，每个表自动分裂，在写数据量较大时无法利用所有机器的性能，导致在流量较大的情况下性能较差，如果遇到流量高峰，就需要业务限流才能保证底层查询的稳定性。
在引入OceanBase 3.1版本后，使用hash分区，写入性能大幅提升；DDL速度更快，至少能保证业务流量高峰时不再限流。升级到OceanBase 4.3版本后，成本收益进一步提升，复杂查询速度更快，基本在10ms内完成。我们支付业务中还有一些AP查询需求，在使用OceanBase 3.1版本时，只有行存，业务需要忍耐一定的查询延迟，OceanBase 4.3版本的行列混存特性使查询更实时，写入延迟在1ms以内。
图5是支付业务在升级到OceanBase 4.x版本后的线上表现。

图5 支付业务在升级到OceanBase 4.x版本后的线上表现
此外，在使用OceanBase 3.x版本时，业务人员希望将不完美的功能进行优化，例如非分区表。当业务量小时，单表很小也无需分区，随着业务量的增长，单分区表可能会把单CPU打满，或者磁盘占用较满导致单副本变得庞大。此时OceanBase3.x版本不支持从单分区变为多分区，而4.x版本能够做到。同时，业务人员希望数据库的查询速度可以更快，OceanBase 4.3版本的行列混存特性可以极大提升复杂查询的性能。
除解决业务需求外，我们升级OceanBase版本的重要因素还包括跟随版本迭代积累运维经验，保持业务版本不会落后太多。
总的来说，快手在升级OceanBase4.x版本后成本更低、查询更快。以支付网关为例，在 3.1.x 版本中，该集群规模为65节点，是线上环境规模最大的集群。升级前数据量450TB，升级后机器规模缩减为45台，数据量压缩至330TB。机器成本降低了31%，数据量比之前压缩了约27%。
在一些TP+AP场景下，最初我们使用OceanBase 3.1版本替换MySQL，满足业务的HTAP需求。升级为OceanBase 4.3版本后，更加稳定、性能更高、分析耗时更快。另外，在OceanBase 3.x版本里面，我们需要将OceanBase数据同步到下游对接大数据生态，但受限于Binlog不支持所以操作起来不太方便。在OceanBase 4.2版本中，Binlog兼容了MySQL Binlog，这个问题得到了解决。
同时，我们也感受到了OceanBase生态工具侧的迭代升级。例如OCP、ODC等在2022年之前容易出现升级、扩容方面的问题，现在我们用OCP集群12台机器运维管理9套集群都没有出现扩缩容或监控告警等相关问题，当OCP诊断到问题时能够自动解决，无需人工干预。
四、使用OceanBase后的六大收益

从上述两个核心业务场景可以看出，使用OceanBase后，快手取得的收益显著，总结而言包括以下六点。
（1）OceanBase高度兼容MySQL引擎，极大降低了开发和使用的门槛。业务人员可以沿用MySQL的使用方式来使用OceanBase，无需改变使用习惯。同时，由于OceanBase兼容MySQL协议与语法，能够平滑地进行数据迁移，大幅降低业务迁移和改造成本。
（2）运维更加高效便捷，单集群可替换300+套MySQL环境，显著降低运维管理成本，提升管理效率。
（3）数据同步性能提升，从上游写入到下游OceanBase的响应延迟更小，数据同步速度更快，延迟时间减少3/4。

（4）OceanBase的同城三机房部署架构实现RPO=0，RTO