跨越速运：使用OceanBase弥补MySQL与StarRocks的空白

导语：本文整理自DTCC大会中跨越速运大数据架构师张杰的演讲，主要介绍跨越速运数据分析的痛点及其在制定查询引擎选型方案时的思考与实践。

大家好，我是跨越速运的大数据架构师张杰，我将从四方面和大家分享跨越速运 HTAP 场景的思考与选型。

1. 物流行业日常做数据分析的业务背景及痛点。
2. 跨越速运对查询引擎的选型思考与产品测试。
3. 跨越速运使用OceanBase的收益。
4. 跨越速运对 OceanBase社区版4.0的尝试。

物流行业运单分析的业务背景

互联网行业的数据服务对象可能是直接面向 C 端用户，但在跨越速运，我们主要面向企业内部用户使用。每天有100+位 BI 开发人员重度使用我们的大数据平台进行开发，已经累计构建了 10000+ 数据服务接口，而这些接口被各类生产系统通过数据网关调用，每天的调用次数达到数千万次，提供的各种数据服务支撑了整个集团 50000+员工日常工作。为了保障用户的友好体验，我们对接口时延要求很高，对 99^th 的时延基本都要求小于1秒。

除了 AP 分析场景外，我们的数据服务还提供了如绩效工资查询、运单成本分摊、运单实效跟踪等核心业务流程中的关键数据。因为每一笔运单都需要统计实际收益，所以大量的用户（如司机、操作工）通过我们的接口查询其每天的收入，包括每一笔运单的成本折算、每一笔运单的时效跟踪，这些数据都来源于大数据平台。

在物流行业，最核心的分析场景，一定是围绕运单展开，而运单分析，需要将上游 ERP 几十个业务系统（包括运输管理、客户管理、绩效管理等）汇聚到大数据平台上，收集、合并、计算上游的所有运单相关数据，并经过复杂的分析处理形成我们数仓运单域的数据，再经大数据的各类平台服务提供给用户使用。

而随着公司业务的快速发展，数据库的应用场景越来越复杂。在早期用户有固定的需求，按照固定维度（天、周、月）或固定条件去查询相关结果时，我们可以做数据的预处理，把数据汇聚的结果放在 MySQL，以便用户直接查到相对应的结果。但如今，用户的需求越来越复杂，他们不再满足于通过固定条件查询，而是要求任意字段、任意时间都可以查询。当用户场景越来越复杂后，我们发现，MySQL已经不能满足需求了。

具体的业务场景变化参考以下三点：

1. 表关联增多。以前我们可以提前做一些宽表的场景，用单表为用户提供服务，随着需求变化越来越快，一个查询接口可能有一二十个表关联。
2. 对数据实时性的要求提高。以前用户可以接受我们离线、批量做数据更新，现在用户要求数据实时更新，比如每一笔运单的实时状态。这就要求下游数据库的数据处理更实时。
3. 对时延的要求越来越高。以前用户可以接受3秒到4秒看到数据结果，现在用户要求其数据请求被亚秒级响应。

面对新的业务问题，我们需要重新选择更合适的数据库解决方案。为了提升用户体验，我们需要数据库有极致的查询性能；为了让数据处理更实时，我们需要数据库支持实时写入、更新、删除。当然，还要考虑数据库的易用性，因此标准SQL和丰富的函数必不可少。如果能高度兼容MySQL的协议则更好。同时，数据要能进能出，数据集成支持的数据源要满足我们的使用场景。数据库的稳定性和可维护性，也是我们考虑的重要因素。

选型测试：五款数据库的性能、功能对比

基于我们的业务背景，再从性能测试和功能测试这两方面和大家分享为什么跨越速运会在众多分布式数据库中选择 OceanBase。

性能测试对比

为了选择一款合适的数据库，必然要参考统一的测试对比标准。业界常见的标准测试方法有 TPC-H、TPC-DS、SSB，各数据库产品的官方文档都有类似测评，这是我们选型参考的标准之一。但是，也不能只依赖这些测试结果，原因有两点，一是不符合我们自身的业务实际场景需求，二是这些测试集可以被针对性地优化。因此，我们根据自身的分析需求，自建了一套 Benchmark 标准。这套 Benchmark 使用统一的测试机型和环境，并基于阿里云的 SSD 盘机型去做统一测试。

我们将运单相关的十几个表做了一个标准的数据集，并基于运单分析实际案例，通过日常使用的场景设计了一套标准的 SQL 集，我们也设计了一套基于实际需要的功能测试集。接着我们就开始用这些测试数据集对市面上的数据库做标准测试。

经过初步的筛选，我们选择了市面上较为流行的五款查询引擎进行测试对比，分别是： TiDB、OceanBase、StarRocks、Doris、Trino，性能测试结果如下图所示。

我们可以看到，在纯 AP 分析场景中，StarRocks 的性能最好，其次是 OceanBase，这超乎了我们的预期。在没有接触 OceanBase 之前，我们测试过 TiDB，当时的 TiDB 和 StarRocks 相比，性能存在着很大的差距。因此，我们一开始对 HTAP 数据库的性能没有过多期望。但当我们测试完 OceanBase 后，意外发现它在 AP 场景中的性能也非常不错。

功能测试对比

除了性能测试外，我们也对数据库的常用功能做了测试与验证，结果如下图所示。

通过测试结果，我们看到 HTAP 数据库的功能更加丰富，基本上可以看作是一套分布式的 MySQL。常见数据库的更新、删除、自定义索引列、一致性保障都支持，但各数据库产品之间也有一些差异。

• 大数据生态集成。因为我们的业务场景主要是运单分析，所以一定会考虑数据库与大数据平台的集成度，在这方面，StarRocks 和 Doris 表现更好。
• 可维护性。我们主要关注在线扩容、在线升级、自动均衡、资源隔离、管理工具几方面，HTAP数据库在这方面的表现更好，其中OceanBase 和 TiDB 相对更优，比如 OceanBase 有 OCP，TiDB 有 TiUP，都能帮我们便捷的完成部署、升级及日常监控维护工作。

在综合对比中，我们考虑到MySQL 是我们业务中大量使用的 TP 数据库，稳定性、事务处理及并发能力是它的强项。而StarRocks则是我们分析场景下大量使用的 AP 数据库，StarRocks分布式的架构、较好的 AP 分析性能及列存所带来的高压缩比都是优势。利用 StarRocks 能很好地解决我们纯分析的业务场景需求，但在 TP 场景与 AP 场景之外，还有很多业务需要使用同时具备TP与AP能力的数据库，比如实时运单分析场景，需要数据库能同时具备这两种能力。此时，OceanBase 和 TiDB 这样的 HTAP 数据库就能给予弥补和支撑。

我们对OceanBase 和 TiDB 做了近一步的对比，通过测试：

• 在各场景下 OceanBase 的性能对 TiDB 呈碾压之势，基本高出4-5倍，
• OceanBase 的架构更简单，存算一体，只需 OBServer、OBProxy 两个服务，但 TiDB 要部署 PD、TiDB、TiKV、TiFlash 等多个服务，增加了后续维护和问题排查的难度。
• OceanBase 的数据存储空间优势更明显，因为 OceanBase 是行列混存，AP 与 TP使用同一份数据，而 TiDB支持 AP 场景时还需要单独使用 TiFlash 存一份列存数据，数据存储占用直接翻倍。

基于此，我们最终选择使用 OceanBase 来帮我们解决实时分析场景下的业务痛点。

使用 OceanBase的实际应用与收益

当我们决定使用 OceanBase 后，做了以下两件事。

第一，数据集成链路验证

验证离线数据。我们使用 Sqoop 工具从 Hive 将数据批量同步到 OceanBase，在50 并发下，220字段宽表，写入3节点 OceanBase 性能达到200W行/min，满足我们离线批量数据同步的性能要求。

验证实时数据。我们基于自己的实时计算平台使用 Flink JDBC Connector，将上游 Kafka 等多源数据实时写入OceanBase，10 partition 实时写入220字段宽表，性能为15W行/min。受限于JDBC Connector 的实现方式，实时性能与离线性能相比差距较大，但基本也能满足我们增量数据实时同步的需求。据了解，OceanBase 社区计划在2023年1月开放Flink OceanBase Connector，做了很多写入和并发的优化，我们将第一时间去验证，相信该工具的性能会强于原生 Flink JDBC Connector。

另外，OceanBase 还提供了 OMS 工具，能够以 Canal 格式将其增量数据实时同步到 Kafka，供下游系统使用。这个功能是我们当前在使用的AP数据库不具备的能力，非常有利于我们做数据的二次实时计算、数据备份容灾等。

第二，探索运单分析架构升级

在完成数据链路验证后，我们要做的第二件事是探索运单分析架构升级。下图是跨越速运最老的运单分析架构，基本是离线处理的架构，上游运单基础数据通过 Canal 同步 binlog 到 Kafka，多个 topic 的数据通过自建平台写入 Hive 不同的表，以2H/天为周期进行表的合并和加工处理，最终产出运单宽表供业务方使用。

该架构存在的关键问题有两个：一是数据实效性差，因为数据是采用离线处理的逻辑，导致数据时效最快只能2小时；二是分析性能差，我们以前基于 Presto分析，性能一般在1秒到10秒左右，涉及更复杂的分析则会更慢，难以让业务方接受，但当时的技术只能做到这种程度。

目前，我们使用的架构是基于上述架构的改造版，引入了 HBase 做运单宽表的实时聚合，并利用 HBase 的 CDC 能力将数据合并后实时同步到 StarRocks 中。效果较为明显，数据从离线变成了实时，基于SR的实时运单分析性能也大幅提升。

但是，在上线后遇到了一些问题：

• 方案过于复杂，可复用性门槛较高。
• 链路比较长，排查数据同步问题环节多。
• 维护成本大。

当我们看到 OceanBase 拥有不错的 AP 能力后，就开始尝试优化现有架构。利用 OceanBase 帮我们进一步解决实时运单分析的问题。在测试过程中，我们利用 Flink JDBC Connector 直接将上游运单多表数据写入OceanBase，在 OceanBase 中完成运单宽表的多字段实时合并。

同样基于 OceanBase 出色的 AP 能力，我们将运单宽表对接外部分析系统，也能保证用户分析的性能不变差（实际验证，220字段宽表，2千万行数据规模下，500行的同环比复杂分析SQL，性能在4s左右，还有提升空间）。经过测试，我们发现不再需要一整套 HBase后，实时运单分析的架构被大幅简化，少了1/3，成本也降低了50%。

• 合并不需要过多的组件，数据链路减少了一半环节，数据处理更实时，以前需要5秒现在两秒就能在OceanBase 中查到实时数据。
• 数据同步的环节变少了，可维护性更高，排查分析问题时也更方便。
• 服务器成本也省下来了，省掉了一整套HBase集群的成本。
• 整个方案可复制性变高了，类似的其他分析场景，能快速复用整套方案。

OceanBase 社区版4.0 尝鲜

在11月3日OceanBase 社区版4.0上线后，跨越速运也进行了很多功能尝鲜。OceanBase 社区版4.0 实现了全新的分布式代价模型和分布式查询优化框架，开发了一套非常完善的并行下压技术，开启了自适应技术的开发，相比其3.x版本，性能明显提升，具体可参考以下 TPC-DS 100GB 的不同版本测试图。

跨越速运也曾经测试过 OceanBase 社区版3.2，与 OceanBase 社区版4.0 的测试数据对比如下

我们可以看到几乎所有 SQL 都在新版本中得到了提升，部分 SQL 提升了4-5倍，部分高基数列聚合场景，提升3-4倍。整体AP性能提升非常明显。

相比3.2版本，OceanBase发挥极致性能也无需做太多优化调参，只需要简单几步。

• 手动完成一次 major compaction，让数据合并落盘
• 手动收集一次表统计信息，让执行计划更准确
• 根据机器的CPU核数设置合理分区数和并行度，充分发挥CPU能力

给OceanBase的建议

我们在使用 OceanBase 的过程中，也发现了一些问题并反馈给 OceanBase 社区。第一个问题是周边工具的适配问题，如OBLoader、OMS等工具还不能完全适配4.0版本。第二个问题是部分聚合场景下的性能问题，这个问题分析后可通过hint方式来解决。与社区沟通后，也了解到这些问题会在OceanBase的下一个版本中得到解决。

最后，感谢 OceanBase社区的同学对我们在使用 OceanBase 过程中给予的帮助和支持。

以上就是我的分享，谢谢大家。

企业简介：跨越速运集团有限公司创建于2007年，是一家主营“限时速运”服务的现代化综合速运企业，提供当天达、次日达、隔日达、同城当日、同城次日、陆运件，及生鲜速运等服务，以及24小时夜间取派与1对1的尊享服务。

欢迎持续关注 OceanBase 技术社区，我们将不断输出技术干货内容，与千万技术人共同成长！！！

搜索🔍钉钉群（33254054），或扫描下方二维码，还可进入 OceanBase 技术答疑群，有任何技术问题在里面都能找到答案哦～