促科技创新：高德数据优化篇之OceanBase最佳实践

本文作者：

振飞（高德地图总裁）

炳蔚（高德技术服务平台负责人）

福辰（高德服务端架构师）

背景

高德成立于2002年，是中国领先的移动数字地图、导航及实时交通信息服务提供商，向终端用户提供包括导航、本地生活、叫车等服务的一站式入口。从拥有甲级测绘资质的领先地图厂商，到首家成功转型移动互联网的地理信息企业，再到国民出行平台，以及出门好生活开放服务平台。业务一直在进化，但高德“让出行和生活更美好”的初心未变，本质的核心专注点一直没有改变，就是地图导航，拥有从数据到软件到互联网的完整研发能力和经验，同时在人工智能、大数据、计算机视觉等一系列新技能方面也拥有深厚的积累。

地图是什么？它是真实（物理）世界在网络空间的数字化映射；高德的目标就是“连接真实世界，做好一张活地图”。作为如今各行各业都非常关注的一个概念，“数实融合”代表大家对于实体经济进一步升级发展的期望，代表着能力和效率的现象级提升，以及面向用户和消费者的更优质产品和服务。而要做到这一点，其中的关键在于推动实体经济和数字经济的高度融合，对于高德地图所在的交通出行行业来说，也是如此。我们致力于用“促科技创新、与生态共进”的方针，助力交通产业更好的实现数实融合。

从高德的视角，对于“数实融合”的理解是什么样的？一方面，我们明确了包括人、车、路、店等在内的实体要素，才是交通出行产业中的真正主体，相关领域中耕耘多年的企业和机构，才是真正值得尊重的老师傅，他们在各自领域的专业度和经验不可或缺；另一方面，科技创新平台提供了交通服务和海量用户之间的连接能力、数字化的展示平台，提供了产业要素转化为数据的能力，并且还能为各类新型交通服务提供强大的计算能力。高德的二十余年，始终与大交通产业中其他领域的老师傅携手共进，尊重他们的专业领域，尊重他们的不可或缺，才得以与他们建立起了深厚的合作关系，成为他们服务的科技标配。2022年10月1日，中国国庆黄金周假期的首日，高德实现了创纪录的2.2亿日活跃用户。在2023年3月，受到日益增长的同城通勤和城际出行需求推动，高德的日均活跃用户数量达到了1.5亿的新纪录。

高德一直不断地探索和应用新的技术，以持续提升用户体验、提高效率和降低成本。

首先是北斗高精度定位。作为一家科技企业，高德有幸见证了北斗从起步到世界一流的发展历程。尤其是2020年的北斗三号全球组网成功，客观上帮助我们在产品研发上迅速打开了新局面，车道级导航、智能红绿灯、绿色出行和位置共享报平安等一系列基于北斗高精尖技术的服务得以在手机上落地，并获得了行业内外的好评。如今，高德地图调用北斗卫星日定位量已超过3000亿次，且在定位时北斗的调用率已超越了GPS等其他卫星导航系统。

互联网地图用户高并发访问和随之而来的海量数据存储处理，是我们必须应对的技术难题。其中，云原生和行业无关化架构是高德地图服务端未来的努力方向。云原生是一个新的软件架构模式，它将应用程序和系统环境抽象化，并将它们封装到容器中，以实现快速、可靠和可扩展的部署和管理；云原生是未来软件架构的发展趋势，它的本质是更高维度的抽象、封装和屏蔽，高德地图服务端会聚焦于把云原生相关技术用到日常应用研发，以提高生产力，快速迭代产品，跟业务一起给用户最好的体验。行业无关化架构是针对高德应用的特点提出的，核心是解决研发效率的问题，业务上让更多的行业快速接入高德，技术上尝试元数据驱动+多租户隔离，屏蔽行业变化对底层的影响，做到行业无关化架构，以进一步提高生产力。

随着“高德地图”成为用户出行必备工具之一，其中数据的存储、加密、快速检索和绝对安全就非常重要，是我们工作的重点，目的是让用户在任何时刻、不同的端设备上都能快速的获得自己想要的真实世界的信息，让用户出行更美好。随着业务后续发展很快就会进入万亿时代，无论是存储成本，还是针对数据查询的性能来讲，数据治理对我们来说显得尤其重要，我们要让数据快速发挥出价值，带给用户最真实最实时的数据，还不会过度的浪费成本。

OceanBase是由蚂蚁集团完全自主研发的国产原生分布式数据库，始创于2010年。OceanBase已连续10年稳定支撑双11，创新推出“三地五中心”城市级容灾新标准，在被誉为“数据库世界杯”的TPC-C和TPC-H测试上都刷新过世界纪录。自研一体化架构，兼顾分布式架构的扩展性与集中式架构的性能优势，用一套引擎同时支持OLTP和OLAP的混合负载，具备数据强一致、高扩展、高可用、高性价比、高度兼容Oracle/MySQL、稳定可靠等特征，不断用技术降低企业使用数据库的门槛。

经过长时间的调研和测试对比，我们决定采用性价比最佳的OceanBase来迎接高德万亿（条）数据时代！

读者收益

正因为真实世界的数据存储量大，高德采用的OceanBase来解决，此篇文章会让大家看到OceanBase在高德的实践体会，我们会从不同的视角去诠释整篇文章。整体如下：

服务端的视角

1）我们为什么选择OceanBase？

2）OceanBase在高德落地过程中分应用的融合方案、痛点和收益？

3）OceanBase在高德应用中未来的规划？

读者的视角

1）高德为什么选择OceanBase，背后选择的原因是什么？

2）高德怎么用OceanBase的，方案是什么，遇到了哪些问题，解决方案是什么？

3）OceanBase在高德应用场景中，表现结果怎么样，稳定性和性能怎么样，降本效果怎么样？

4）结合我们自己的场景哪些可以用OceanBase帮我们解题？

以下用OB代替“OceanBase”，整篇文章也会围绕几点来贯彻核心思想：

1）了解选择OceanBase的原因，了解OB的落地实践

2）了解分布式数据库和OB相关技术内幕

3）作为工具文章，在犹豫是否选择OB的时候会给大家一些思路

1.为什么选择OB

阿里云提供的数据存储产品有很多， 简单罗列几个常用的(排名不分先后，没写进来的不代表不好)

• PolarDB

• Lindorm

• OB

• ES

• MongoDB

• ...

每种存储都有自己的特色，有关系型数据库，有分布式数据库，有列族数据库等在不同的场景都表现十分出色。然而我们为什么选择了OB呢？ 

其实从21年开始，我们就一直在做一个事，就是去MongoDB。过去高德有一些业务服务用的MongoDB做存储，由于MongoDB的特性和设计特点，导致它偶尔会出现CPU占用很高，服务Pause无法正常提供服务。 对于上游来说体现就是超时问题了，如果访问量大且重试带来的阶梯效应就是毁灭的，服务基本被打垮。很多时候不是MongoDB本身的问题，它定义是分布式文档存储系统，通过Documents的方式来维护数据，理论上在关系型比较重的场景上确实不太适合。

后来我们服务就相继的迁移到XDB、Lindorm、ES。选择ES是因为成本低和稳定性高；选择Lindorm是因为对于我们的异构场景、Key Value场景和减少请求穿透到XDB的场景非常合适。那么就剩下数据库选型了，虽然OB是NewSQL数据库，但是他保留了关系型数据库的特性，让我们以NewSQL的方式去管理数据，但不是说明任意场景都比较适合，在结构化数据量大的体系中，OB在降本上非常具有优势。

那么这里又有一个疑问？Lindorm和ES不也可以做这种存储吗？ 存储和检索都非常高效。 但是从工具的角度Lindorm和ES对我们来说都是加快检索和异构检索使用的，无法真正像关系型数据库那样去使用，往往后面都会存在一个数据库，会严重增加数据沉余和成本。

针对数据库的场景，我们其实都关注两点：OLTP和OLAP。PolarDB是天然的OLTP，分布式MySQL引擎后续架构也支持了OLAP设计。 然而OB本身设计就是NewSQL模式，天然具备OLTP和OLAP两种场景，而且针对大数据有自己的压缩体系，在降本和应用都有天然的优势。

1.1 OB基础属性信息

图 1.1 OB的基础属性信息

1.2 经过多方面平衡，解释下我们为什么要选择OB？

1）OB是基于Paxos一致性协议实现的数据多副本存储(多版本并行提交)，满足多数派即可返回，最终一致性。

2）采用无共享的多副本架构，系统没有单点障碍，保证系统持续可用。即使单副本出现故障，也可以达到多数派可用。

3）OB是可以动态扩容的，扩容后分区表的数据会自动均衡到新节点上，对上层业务透明，节省迁移成本。

4）OB存储具有高度压缩的能力，数据可以压缩到原有数据到三分之一，对于存储量大的业务会极大降低存储成本。

5）OB作为准内存数据库，采用LSM-Tree存储引擎，增量数据操作内存，减少随机写，读写性能超传统关系型数据库，而且支持Hash和B+Tree。

6）比较重要的是OB也支持MySQL的协议，可以直接使用MySQL驱动访问，可以基本完全的将OB当成分布式的MySQL使用。

在布式数据库出来之前，针对大数据量的读写场景广泛采用分库分表方案，也由此诞生了很多分库分表、读写分离中间件。这些方案虽然能带来一定的效果，也会引发一些后遗症，比如：

• 需要提前规划好分片规则，一旦定好规则就难以移动，扩展困难

• 分得太细会浪费资源，分得太粗会导致二次拆分

• 数据迁移困难

说到这里，大家应该还没太多体感，那么我们会从分布式数据库和OB的一些技术角度去诠释上面的决策点（为方便更好的做决策，主要讲一些相应的分布式数据库和OB技术原理，了解的同学可以直接跳过）。

2. 云原生分布式数据库和OB技术内幕

2.1 云原生数据库的发展历程   

云原生分布式数据库发展历程，经历以下3个阶段。

• 单机：传统单机数据库、依赖高端硬件、系统难以扩展、成本高。

  • PG-XC：基于中间件的分布式数据库(TDDL)。待解决全局一致性、跨库事务、复杂的SQL等问题。

  • NewSQL：高可用、水平扩展、分布式事务，全局一致性、复杂SQL、自动负载均衡、OLAP等。

图 2.1 数据库发展历程 (图片引自OceanBase)

3个阶段衍生出3种架构，但是统一被归整为NewSQL和PG-XC的2大类风格

• Sharding on MySQL：一般我们可以在应用侧或者代理层做分片来管理多个MySQL物理库，以解决单机容量和性能不足的问题。现在正在使用的TDDL就是该架构，虽然计算存储资源可扩展，但在扩展和数据迁移时，业务系统层面需要做不少改造和业务数据的灰度，为了保证业务不停机会产生比较大的改造成本和数据迁移的风险。(PG-XC风格)

  • NewSQL：国内以TiDB和OceanBase为代表的原生支持分布式的关系型数据库，主要也是为了解决MySQL的问题。和Sharding on MySQL不同的是，NewSQL将分片功能作为数据库的一部分来实现，并提供了动态扩缩容的能力，且对上层业务透明，具备透明可扩展性。

  • Cloud Native DB：云原生数据库国内以PolarDB为代表，具备池化的资源，也可以实现存储资源的动态扩缩容，其一般采用的主备方式来实现高可用，同时其扩容和主备探活等功能需要大量依赖外部系统。(PG-XC风格)

图 2.2 数据库3种架构 (图片引自阿里云[1])

从架构体系又分为2种流派

• Shard-Nothing：架构的每个节点有独立的计算和存储功能并且节点之间不共享数据

  • 无状态SQL计算节点，无限水平扩展

  • 远程存储，共享存储节

  • 强SQL支持( 系统自动扩展路由 )

  • 和单机一样的事务支持

  • 跨数据中心故障自动恢复

  • 无限的弹性水平扩展

  • Shard-Everying：也叫Shard-Storage，即Shared-Disk，架构是在存储层做了统一和共享，但计算节点是独立节点

图 2.3 数据库架构的2种流派 (图片引自论文Survey of Large-Scale Data Management Systems for Big Data Applications)

从上述图可以看出来，Shard-Everying的存储是共享的，前面计算节点多，查询量极大的情况下就会造成共享存储压力过大，导致查询性能非常低下。Shard-Nothing的则不然，有独立的计算和存储节点，数据不共享性能可靠，市面上的NewSQL大多数都是依照Google 的Spanner/F1来进行设计的，这里先简单介绍下Spanner/F1职责：

• F1设计的目标

  • 无限弹性水平扩展

  • 跨数据中心故障自愈

  • 事务的ACID一致性

  • 全面的SQL支持，支持索引

• Spanner设计的目标

  • 管理跨数据中心复制的数据

  • 重新分片和平衡数据的能力

  • 跨数据中心迁移数据

到这里想必大家都知道什么是NewSQL了， 完美的具备关系型数据库的基因且具备更加强的扩展性和性能，其实NewSQL跟分布式数据库不能完全画等号的。NewSQL还是遵循事务ACID，SQL引擎那一套，保证的是无缝迁移。但是分布式数据库强调的是最终一致性，也是NewSQL要体现的，所以NewSQL是在原生分布式数据库上构建而成的“云原生分布式数据库”，有点绕嘴，用简单的描述来阐述下两种事务模型，大家平时用的最多的也是事务相关。

2.2 OB的技术内幕

数据库有3大特征，上文介绍了OLTP 3大特征(SQL解析、事务、存储)中的2种，分别为事务&存储。 接下来会介绍OB的技术内幕。然后也会介绍下OB在OLAP上的表现。 

先介绍OLAP 3个特性：列存(解决宽表)、压缩(减少存储空间)、向量化SIMD (Single Instruction Multiple Data) 即单条指令操作多条数据——原理即在CPU寄存器层面实现数据的并行操作

2.2.1 OB存储引擎

图 2.4 OB存储引擎架构 (图片引自OceanBase)

关键设计：

1）基于LSM理念自研底层存储引擎，未选择RocksDB

2）宏块与微块存储介质，微块是数据的组织单元，宏块则是由微块组成。Compact操作时可以在宏和微块两个级别判断，是否复用

3）多Parttion多副本解耦Compact操作，避免磁盘IO竞争

4）控制User IO/System IO，减少前台请求影响

5）按行存储，按列编码，减少体积

6）三副本Compaction的Checksum防止静默错误

7）支持分布式事务

8）支持B+Tree和Hash索引模式，针对热数据做了很多优化，查询效率很高，本身也通过Bloom Filter Cache来加速查询

特性：

• 低成本，自研行列混存的压缩算法，压缩率较传统库提高10+倍。

• 易使用，支持活跃事务落盘来保证大事务的正常执行和回滚。多级转储和合并来平衡性能和空间。

• 高性能，提供多级缓存保证低延时。OLAP操作提供向量化支持。

• 高可靠，全局合并时多副本比对和主表与索引表比对校验和来保证用户数据正确性。

多类型缓存， 覆盖数据访问全链路 

• 数据缓存：

  • Bloom Filter Cache：维护缓存静态数据的Bloom Filter，快速过滤无需访问的数据。当一个宏块上的空查次数超过某个阈值时，就会自动构建BloomFilter Cache。 

  • Row Cache：数据行缓存，在进行单行或多行访问时构建并命中。 </