OceanBase 在滴滴大规模运维经验以及新功能落地实践

作者：吴其朋，滴滴分布式存储运维负责人
滴滴出行（下文简称“滴滴”）作为涵盖#网约车、#出租车、#顺风车、#代驾 等业务的一站式多元化出行平台，拥有全球客户6.5亿。自2024年应用OceanBase以来，已在多个场景落地并替换RocksDB、TokuDB，包括网约车增长服务、中台核心归档库、代驾核心归档库、EP、无人车服务等。本文以网约车增长服务、归档库等核心业务为例，阐述滴滴的数据库技术经验以及新功能实践。
滴滴出行的数据库使用场景及技术方案

场景一：核心归档库

滴滴的归档库承载着线上业务的高访问量，更接近于线上冷库，而非冷数据归档。目前，归档库的最大集群为100TB，QPS（每秒查询率）最高峰值达到八千（8000/s）。由于持续且高频访问的业务特征，传统的分表模式难以满足快速扩容需求，因此我们认为，将核心归档库迁移至OceanBase成为关键路径。
现状：使用大磁盘机型降低成本

得益于OceanBase先进的高压缩比与原生分布式架构，在100+TB数据量的归档场景中，相较于TokuDB分库分表架构，存储成本降低20%。另外，由于OceanBase可以使用更大磁盘的机型，进一步为我们节省了业务成本。
这里涉及一个问题：为什么TokuDB不能使用大磁盘机器呢？ 原因有二：

• 一是若TokuDB使用大磁盘的机器，它的实例就大，会导致备份与拆分的时间过长，进而影响服务可用性；
  
• 二是如果大磁盘机器部署过多的Toku小实例，一旦出现单机故障，影响范围扩大的风险是成倍的。
  

相较之下，OceanBase依赖于Unit拆分的快速扩容模式，能够在分钟级完成节点的扩散、小时级实现Unit的拆分。这不仅极大提升了运维效率，也增加了服务的稳定性。
那么，我们在使用大磁盘机器时，如何选择合适的规格？
评估使用多大磁盘的机型，以单机故障恢复时长为依据，其中磁盘性能和网络带宽的差异都是影响恢复时间的相关指标，所以具体使用多大磁盘机型还需因地制宜。
举个例子：以MySQL 3TB服务恢复时长为基准，在进行备份故障恢复时，大约需要 7~ 8 个小时。而选用OceanBase大磁盘机器时，就可以根据7~8小时的标准来制定大磁盘机器容量。
挑战：百TB数据迁移延时高

由于归档库数据量大，业务侧担心从TokuDB迁移至OceanBase会存在稳定性风险，包括性能、数据一致性校验、迁移效率，因此我们进行了针对性的测试和验证。
首先，在性能方面，为了确保响应延迟可控，我们进行了灰度测试，从上游归档库的几千张表中，对每张表选取一小部分数据进行数据迁移，速度快、成本低。但当业务侧进行流量测试时，延时上涨了十几倍甚至几十倍。我们根据SQL分析发现，当面对几千张表，SQL第一次访问都会执行硬解析模式。那么，如何避免这种情况？经过和业务侧沟通，我们的策略是将上游的数千张表合并为下游的几张表，业务侧只需简单修改后缀就能够有效减少硬解析的次数。大大减少业务响应延迟，99分位保持在十几毫秒以内。
其次，迁移效率与数据一致性校验相关。我们以5TB数据测试迁移为参考值，判断业务整体迁移节奏。但在迁移过程中发现，数据校验非常耗时，几TB的数据校验长达几天，极大地影响了迁移效率。随后在OceanBase社区的帮助下，我们通过升级OMS并使用OMS数据校验过滤表字段的功能解决了该问题。其本质是过滤大字段，而这些大字段通常都是非核心场景，对业务没有影响，却可以将数据校验时长从天级别降低到小时级别。
还有一个小技巧，在OMS进行数据的全量与增量迁移过程中，多使用OMS Diagnose功能。该功能可以根据当前的迁移速度发掘迁移瓶颈，并依据系统承载能力给出合理的迁移方案，比如修改下游的并发数、提高上游的并发数，进而提升迁移效率。
场景二：网约车增长服务

现状：百亿数据高效率运行

网约车增长业务即俗称的特征库。特征库的特点是表级别映射到业务线，导致其单表字段非常多，数据达百亿。而且，因为单行宽度大，并且伴有特定范围的数据查询，线上QPS最高为2.5w/s。由于业务侧依赖特征库进行数据聚合与数据分析，要求特征库的响应延迟控制在80ms内,因此，单SQL执行超过200ms时，业务会进行熔断重试，以免出现故障进而造成更大的负面影响。
起初，我们计划使用MySQL分库分表支撑特征库的业务需求，不过，最终没有落地。这是因为：

• 上文提到该业务伴有不同维度的范围查询，所以我们无法对单表进行拆分；
  
• 特征库单行过大，MySQL的性能不足，验证不通过。
  

目前，特征库在OceanBase运行情况如下：

• OceanBase的日常响应延迟在30ms左右，满足业务诉求。
  
• 秒级DDL可以满足业务快速迭代的需求，极大地提升了业务的迭代效率。如果我们使用MySQL copy的方式，一个单表需要几天才完成。
  
• OceanBase的分区表和全局索引功能非常好用，可以根据字段进行分区，增加单表的并发度，提高百亿大表的访问效率；全局索引可以在单表上满足业务不同维度的范围查询，比如按司机查询、按订单查询等。不仅查询效率高，还降低了运维复杂度。
  

挑战：高并发业务场景

特征库上游对接的业务线比较广，各业务线会依赖它进行数据聚合+数据分析。当上游业务线有一个分析需求时，特征服务会对该需求进行模型拆分。例如，上游的一个查询会被特征服务拆成多个SQL并发访问OceanBase，如此一来，处在下游的OceanBase其实是流量放大的。并且业务存在超200ms的熔断重试机制，以满足对上游的SLA保障。
然而在这样的高压场景中，风险是时时存在的，比如：

• 业务流量突增或波动，可能导致重试风暴，影响系统稳定性。
  
• 如何合理设定限流阈值，与系统在高并发时稳定运行息息相关。
  
• 根据 OCP SQL 诊断观察，业务 SQL 模板高达几千个，可能导致限流失效。
  

面对上述挑战，我们采取了针对性措施。
1.业务重试逻辑修改。
我们的做法是，和业务侧沟通，将重试机制调整为阶梯式，从固定的200ms重试，设置为渐进的200ms、400ms、800ms。
举个例子，假设一个SQL执行的正常时间是100ms，当它超时达到200ms，那一定是某个环节出现了问题：网络问题、单机故障或其他问题。此时如果还在不断进行200ms的重试其意义不大，只会给数据库增加额外的压力。反而，阶梯式的重试能够减少重试风暴带来的压迫感。
2.限流阈值实施。
解析业务高峰期 SQL audit，获取并发度，设置合理阈值。同时也能发现那些超高并发 SQL，提前防患。
对于高并发业务线的SQL进行限流，多少阈值合适？
“拍脑袋”式的设置5或10，是没有根据的。我们可以通过解析业务高峰期 SQL audit，获取并发度。比如以30ms为区间，这是因为业务的日均响应延迟为30ms，就可以判断该区间内单个SQL模板有多少并发。我们选择以90%以上并发度的基准对业务进行限流。超过90%的并发度的SQL则通知业务侧调整，降低其并发。
3.海量 SQL 优化。
开启限流后，我们发现了一个问题：限流的模板达到上千个，影响限流效率。我们根据SQL分析，这些被限流的模板都有一个共同点，它们的访问条件一致、访问的数据一致，只是语法的顺序颠倒而已。对于OceanBase的SQL限流来说，过多的SQL模板可能会导致限流失效。因此，我们通知业务侧修改逻辑，将SQL模板从数千个缩减为100个以内，大大降低了限流失效的风险。
4.尝试OceanBase4.3.5 bp3版本。
前面提到SQL模板级别的限流方案，其实只能防止服务因为某几个问题SQL(慢查询、流量突增等)，导致线程被大量占用，最后造成整体服务不可用的情况。
举个例子：我们有一个10C 50G UNIT租户，最大单机并发数可以达到40。当一个SQL的并发数限制为10时，最多能防止3条以内的问题SQL。当超过3条SQL时，线程依旧会被占满，仍旧无法保证整个服务可用性。
OceanBase4.3.5全新版本可以完美的支持库、表级别限流。这样我们就可以设置多层限流规则，以有效避免SQL级、表级出现问题，导致整个服务不可用的情况。
数据库运维体系建设及实践

1.监控告警定制化

其一，基于机型的阈值告警。在一个OCP管理多套OceanBase集群的情况下，集群中可能包含了归档库或流量较高的高并发库。对此，滴滴的策略是：在归档库中使用计算资源少的大磁盘存储；在特征库中使用计算资源较多的机型。
而这会面临一个问题：若两个业务的告警配置一致，会造成大磁盘机型的资源浪费。因此，我们需要根据不同的机型配置不同的告警，以实现资源的最大化利用。此外，在机型置换的过程中，也需要根据机型定制告警策略。
我们根据不同的物理机配置设置ob_server_sstable_percent_over_threshold 告警阈值，避免统一标准导致的误报或漏报。例如大容量归档机型允许更高的 SSTable 占比，而高并发特征库机型则设定更严格阈值，确保集群稳定性。
其二，ZONE级交换机隔离告警。OceanBase是基于Paxos协议实现了多副本容灾。当多数派出现故障时会导致业务的部分数据或整套集群不可用。因此，我们针对不同ZONE内部署在相同 TOR 下的 UNIT，建立网络拓扑告警机制。避免单一交换机故障引发部分业务数据失效的情况。此告警已经成为核心高优先级项，必须第一时间响应处置。
2.上线Binlog Server 4.x 高可用版本

在滴滴业务链路中，无论是SQL还是OceanBase，都需要把上游数据同步到下游的MQ或Kafka，以提供给不同的业务线或者业务场景进行使用分析，所以导致binlog同步链路对于某些业务来说是强依赖的。
在上线Binlog Server高可用版的过程中，我们验证了其语法兼容、高可用性、数据一致性，均符合预期。不过在进行多次高可用切换时，会把所有的实例切换到一台机器上，虽然不影响高可用的链路，但可能会造成资源的不均衡，希望后续版本能够改善。
3.SOP与防火演练

SOP是一个慢慢叠加、累积的过程，需经过故障的洗礼，以及在OceanBase官方人员的耐心指导下，增长运维经验，进而沉淀为SOP。带来的益处也是显而易见的：不仅提升工作的一致性、效率和准确性，还为团队运维提供了重要支撑。但是，仅有SOP不足以应对生产环境中的风险，还需要通过防火演练验证SOP的可用性。二者相辅相成，不断提高组织在面对各种紧急情况时的整体应急能力。
4.成立运维小组

你可能会质疑，有必要成立专门的运维小组吗？
成立运维小组的意义在于：

• 避免单点风险。除了24小时告警外，当我们面临重大故障时，希望能够分工合作，快速止损。
  
• 帮助团队增加技术储备，更好地提供业务服务。
  
• 群策群力，助力 OceanBase 在滴滴的发展中走得更远，飞得更高。
  

在小组中，我们会做几件事：

• 定期组织架构解析会，比如内核技术解析、源码解析、技术方案分享。
  
• 建立知识传承机制，比如整理方案、故障复盘，让组内同学融入运维体系，快速成长。
  
• 线上故障模拟训练。借助SOP模拟线上环境的运维操作，不断进行防火演练，才能在遇到故障的时候处事不慌，井井有条的解决故障。
  
• 参与重大变更实施。
  

尾声：对数据库的期待

在使用OceanBase的过程中，我们有两个非常直观的感受。

• OCP白屏化工具，大大降低了运维难度，让从前复杂的操作变得简单、便捷。即使在管理上百台物理机时，也能做到游刃有余。并且通过OCP接口，还可以快速实现一些定制化功能。
  
• Oceanbase数据库可以满足多维度的业务需求，使业务侧得到了“既要又要”。
  

但数据库升级方面，我们仍有期待。目前OceanBase基于OB Server滚动升级，并且无法长期保持每个OB Server版本不一致的情况，无法满足我们对于重大操作的灰度运维标准。当然也可以依托主备库或OMS同步链路的方式进行升级，这种方式虽然稳健，但如果一个集群涉及上百台机器，会有较大的资源浪费。
因此，希望OceanBase不仅提供小流量灰度升级，还能支持回滚操作，便于用户在升级数据库时万一遇到线上业务不匹配或其它未知问题时，实施相应的止损手段。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！