促科技创新：高德数据优化篇之OceanBase最佳实践
作者介绍
振飞（高德地图总裁）、炳蔚（高德技术服务平台负责人）、福辰（高德服务端架构师）
高德成立于 2002 年，是中国领先的移动数字地图、导航及实时交通信息服务提供商，向终端用户提供包括导航、本地生活、叫车等服务的一站式入口。从拥有甲级测绘资质的领先地图厂商，到首家成功转型移动互联网的地理信息企业，再到国民出行平台，以及出门好生活开放服务平台。业务一直在进化，但高德
“让出行和生活更美好”
的初心未变，本质的核心专注点一直没有改变，就是地图导航，拥有从数据到软件到互联网的完整研发能力和经验，同时在人工智能、大数据、计算机视觉等一系列新技能方面也拥有深厚的积累。
地图是什么？它是真实（物理）世界在网络空间的数字化映射；高德的目标就是 “连接真实世界，做好一张活地图”。 作为如今各行各业都非常关注的一个概念，“数实融合”代表大家对于实体经济进一步升级发展的期望，代表着能力和效率的现象级提升，以及面向用户和消费者的更优质产品和服务。而要做到这一点，其中的关键在于推动实体经济和数字经济的高度融合，对于高德地图所在的交通出行行业来说，也是如此。我们致力于用“促科技创新、与生态共进”的方针，助力交通产业更好的实现数实融合。
从高德的视角，对于 “数实融合” 的理解是什么样的？一方面，我们明确了包括人、车、路、店等在内的实体要素，才是交通出行产业中的真正主体，相关领域中耕耘多年的企业和机构，才是真正值得尊重的老师傅，他们在各自领域的专业度和经验不可或缺；另一方面，科技创新平台提供了交通服务和海量用户之间的连接能力、数字化的展示平台，提供了产业要素转化为数据的能力，并且还能为各类新型交通服务提供强大的计算能力。
高德的二十余年，始终与大交通产业中其他领域的老师傅携手共进，尊重他们的专业领域，尊重他们的不可或缺，才得以与他们建立起了深厚的合作关系，成为他们服务的科技标配。2022 年 10 月 1 日，中国国庆黄金周假期的首日，高德实现了创纪录的 2.2 亿日活跃用户。在 2023 年 3 月，受到日益增长的同城通勤和城际出行需求推动，高德的日均活跃用户数量达到了 1.5 亿的新纪录。
高德一直不断地探索和应用新的技术，以持续提升用户体验、提高效率和降低成本。
首先是北斗高精度定位。作为一家科技企业，高德有幸见证了北斗从起步到世界一流的发展历程。尤其是 2020 年的北斗三号全球组网成功，客观上帮助我们在产品研发上迅速打开了新局面，车道级导航、智能红绿灯、绿色出行和位置共享报平安等一系列基于北斗高精尖技术的服务得以在手机上落地，并获得了行业内外的好评。如今，高德地图调用北斗卫星日定位量已超过 3000 亿次，且在定位时北斗的调用率已超越了 GPS 等其他卫星导航系统。
互联网地图用户高并发访问和随之而来的海量数据存储处理，是我们必须应对的技术难题。其中，云原生和行业无关化架构是高德地图服务端未来的努力方向。云原生是一个新的软件架构模式，它将应用程序和系统环境抽象化，并将它们封装到容器中，以实现快速、可靠和可扩展的部署和管理；云原生是未来软件架构的发展趋势，它的本质是更高维度的抽象、封装和屏蔽，高德地图服务端会聚焦于把云原生相关技术用到日常应用研发，以提高生产力，快速迭代产品，跟业务一起给用户最好的体验。行业无关化架构是针对高德应用的特点提出的，核心是解决研发效率的问题，业务上让更多的行业快速接入高德，技术上尝试元数据驱动+多租户隔离，屏蔽行业变化对底层的影响，做到行业无关化架构，以进一步提高生产力。
随着“高德地图”成为用户出行必备工具之一，其中数据的存储、加密、快速检索和绝对安全就非常重要，是我们工作的重点，目的是让用户在任何时刻、不同的端设备上都能快速的获得自己想要的真实世界的信息，让用户出行更美好。随着业务后续发展很快就会进入万亿时代，无论是存储成本，还是针对数据查询的性能来讲，数据治理对我们来说显得尤其重要，我们要让数据快速发挥出价值，带给用户最真实最实时的数据，还不会过度的浪费成本。
经过长时间的调研和测试对比，我们决定采用性价比极高的 OceanBase 来迎接高德万亿（条）数据时代！
正因为真实世界的数据存储量大，高德采用 OceanBase 来解决，此篇文章会让大家看到 OceanBase 在高德的实践体会，我们会从不同的视角去诠释整篇文章。整体如下：
-服务端的视角
1）我们为什么选择 OceanBase？
2）OceanBase 在高德落地过程中分应用的融合方案、痛点和收益？
3）OceanBase 在高德应用中未来的规划？
-读者的视角
1）高德为什么选择 OceanBase，背后选择的原因是什么？
2）高德怎么用 OceanBase 的，方案是什么，遇到了哪些问题，解决方案是什么？
3）OceanBase 在高德应用场景中，表现结果怎么样？稳定性和性能怎么样？降本效果怎么样？
4）结合我们自己的场景哪些可以用 OceanBase 帮我们解题？
-本文围绕以下几点来贯彻核心思想：
1）了解选择 OceanBase 的原因，了解 OceanBase 的落地实践；
2）了解分布式数据库和 OceanBase 相关技术内幕；
3）作为工具文章，在犹豫是否选择 OceanBase 的时候会给大家一些思路。
市场上提供的数据存储产品有很多， 简单罗列几个常用的(排名不分先后，没写进来的不代表不好)。
- PolarDB
- Lindorm
- OB
- ES
- MongoDB
- ...
每种存储都有自己的特色，有关系型数据库，有分布式数据库，有列族数据库等在不同的场景都表现十分出色。然而我们为什么选择了 OceanBase 呢？
其实从 2021 年开始，我们就一直在做一个事，就是去 MongoDB。过去高德有一些业务服务用的 MongoDB 做存储，由于 MongoDB 的特性和设计特点，导致它偶尔会出现 CPU 占用很高，服务Pause无法正常提供服务。 对于上游来说体现就是超时问题了，如果访问量大且重试带来的阶梯效应就是毁灭的，服务基本被打垮。很多时候不是 MongoDB 本身的问题，它定义是分布式文档存储系统，通过 Documents 的方式来维护数据，理论上在关系型比较重的场景上确实不太适合。
后来我们服务就相继的迁移到 XDB、Lindorm、ES。选择 ES 是因为成本低和稳定性高；选择 Lindorm 是因为对于我们的异构场景、Key Value 场景和减少请求穿透到 XDB 的场景非常合适。那么就剩下数据库选型了，虽然 OceanBase 是 NewSQL 数据库，但是他保留了关系型数据库的特性，让我们以 NewSQL 的方式去管理数据，但不是说明任意场景都比较适合，在结构化数据量大的体系中，OceanBase 在降本上非常具有优势。
那么这里又有一个疑问？Lindorm 和 ES 不也可以做这种存储吗？ 存储和检索都非常高效。 但是从工具的角度 Lindorm 和 ES 对我们来说都是加快检索和异构检索使用的，无法真正像关系型数据库那样去使用，往往后面都会存在一个数据库，会严重增加数据沉余和成本。
针对数据库的场景，我们其实都关注两点：OLTP 和 OLAP。PolarDB 是天然的 OLTP，分布式 MySQL 引擎后续架构也支持了 OLAP 设计。 然而 OceanBase 本身设计就是 NewSQL 模式，天然具备 OLTP 和 OLAP 两种场景，而且针对大数据有自己的压缩体系，在降本和应用都有天然的优势。
1.1 OceanBase 基础属性信息
图 1.1 OceanBase的基础属性信息
1.2 多方权衡后，为什么选择 OceanBase？
1）OceanBase 是基于 Paxos 一致性协议实现的数据多副本存储(多版本并行提交)，满足多数派即可返回，最终一致性。
2）采用无共享的多副本架构，系统没有单点障碍，保证系统持续可用。即使单副本出现故障，也可以达到多数派可用。
3）OceanBase 是可以动态扩容的，扩容后分区表的数据会自动均衡到新节点上，对上层业务透明，节省迁移成本。
4）OceanBase 存储具有高度压缩的能力，数据可以压缩到原有数据到三分之一，对于存储量大的业务会极大降低存储成本。
5）OceanBase 作为准内存数据库，采用 LSM-Tree 存储引擎，增量数据操作内存，减少随机写，读写性能超传统关系型数据库，而且支持 Hash 和 B+Tree。
6）比较重要的是 OceanBase 也支持MySQL的协议，可以直接使用 MySQL 驱动访问，可以基本完全的将 OceanBase 当成分布式的 MySQL 使用。
在布式数据库出来之前，针对大数据量的读写场景广泛采用分库分表方案，也由此诞生了很多分库分表、读写分离中间件。这些方案虽然能带来一定的效果，也会引发一些后遗症，比如：
- 需要提前规划好分片规则，一旦定好规则就难以移动，扩展困难
- 分得太细会浪费资源，分得太粗会导致二次拆分
- 数据迁移困难
说到这里，大家应该还没太多体感， 那么我们会从分布式数据库和 OceanBase 的一些技术角度去诠释上面的决策点 （为方便更好的做决策，主要讲一些相应的分布式数据库和 OceanBase 技术原理，了解的同学可以直接跳过）。
2.1 云原生数据库的发展历程
云原生分布式数据库发展历程，经历以下 3 个阶段。
- 单机：传统单机数据库、依赖高端硬件、系统难以扩展、成本高。
- PG-XC：基于中间件的分布式数据库(TDDL)。待解决全局一致性、跨库事务、复杂的 SQL 等问题。
- NewSQL：高可用、水平扩展、分布式事务，全局一致性、复杂 SQL、自动负载均衡、OLAP 等。
