vivo 数据库与存储平台的建设和探索

PingCAP 2022-03-01

916

vivo 是一个专注于智能手机领域的国际化品牌，市场不断变化，新零售热潮扑面而来。在数字化转型过程中，vivo 的基础平台架构也面临着更多的挑战。在自主研发的同时，vivo 依托包括 TiDB、TiKV 在内的众多开源项目进行迭代和设计，打造了全新的数据库与存储平台，覆盖通用存储产品运维和研发需求。

本文根据 vivo 存储技术团队研发总监肖博在 2021 vivo 开发者大会上的分享整理而成，从数据库与存储平台的建设背景、能力介绍、探索思考、未来展望四个角度进行了整体的介绍。

一、数据库与存储平台建设背景

以史为鉴，可以知兴替，做技术亦是如此，在介绍平台之前，我们首先回顾下 vivo 互联网业务近几年的发展历程。

我们将时间拨回到三年前，2018 年 11 月，vivo 移动互联网累计总用户突破 2.2 亿；2019 年应用商店、浏览器、视频、钱包等互联网应用日活突破千万大关；2020 年浏览器日活突破 1 亿，2021 年在网总用户（不含外销）达到 2.7 亿，数十款月活过亿的应用，数据库和存储产品也达到了 4000 + 服务器和 5 万 + 数据库实例的规模。

那三年前的数据库和存储平台是什么样呢?

2018 年的数据库服务现状如果用一个词形容，那我觉得“危如累卵”最适合不过了，主要表现为以下几点：

• 数据库线上环境的可用性由于低效的 SQL、人为的误操作，基础架构的不合理，开源产品的健壮性等问题导致可用性经常受到影响。

• 变更不规范，变更和各种运维操作的效率低下，没有平台支撑，使用命令行终端进行变更，导致数据库使用的成本极高，为了应对日益复杂的业务场景，增加了很多额外的成本。

• 安全能力不够健全，数据分类分级、密码账号权限等缺乏规范。

我们再看看这些年 vivo 数据库运营数据上的变化趋势。

从 17 年底，18 年初开始计算，这三年时间里数据库实例的规模增加了接近 5 倍，维护的数据库服务器规模增加了 6.8 倍，数据库实例的单机部署密度增加了 5 倍以上，DBA 人均运维的数据库实例规模增加了 14.9 倍。

通过以上这些数字，我们可以发现，近几年 vivo 互联网业务正处于一个高速发展的状态，在这个过程中无论是从用户感受到的服务质量上来看还是从内部的成本效率来看，解决数据存储的问题都是迫在眉睫的，于是我们在 2018 年启动了自研数据库与存储平台的计划，通过几年时间的建设，我们初步具备了一些能力，现在就这些能力给大家做下简单的介绍。

二、数据库与存储平台能力介绍

数据库与存储平台产品主要分为 2 层。底层是数据库和存储产品，包括关系型数据库、非关系型数据库和存储服务三大块。上层主要是工具产品，包括提供的数据库和存储、统一管控的研发和运维平台、数据传输服务、运维白屏化工具，还有一些 SQL 审核，SQL 优化，数据备份等产品。工具产品主要以自研为主，下面一层的数据库和存储产品我们会优先选用成熟的开源产品，同时也会在开源产品的基础上或者纯自研一些产品，以更好地满足业务发展。

DaaS 平台

vivo 的 DaaS 平台旨在提供高度自助化、高度智能化、高可用、低成本的数据存储使用和管理的平台，涵盖了数据库和存储产品从服务申请、部署、维护直至下线的全生命周期。主要从四个方面为公司和用户提供价值。

第一是提升数据库产品的可用性，通过巡检、监控、预案、故障跟踪等对故障进行事前防范、事中及时处理、事后复盘总结进行全流程闭环；第二是提升研发效能，研发自助使用数据库，提供变更检测、优化诊断等功能，减少人工沟通流程，项目变更规范流程清晰，提升研发效率；第三是提升数据安全性，通过权限管控、密码管控、数据加密、数据脱敏、操作审计、备份加密等一系列手段全方位地保障数据安全性；第四是降低数据库和存储产品的运营成本，首先通过自动化的流程减少 DBA 的重复工作，提高人效，其次通过服务编排和资源调度，提升数据库和存储服务的资源使用效率，持续降低运营成本。

通过几年时间的建设，以上工作取得了一些进展，其中每月数以千计的需求工单，90% 以上研发同学可以自助完成，服务可用性最近几年都维持在 4 个 9 以上，平台对 6 种数据库产品和存储服务的平台化支持达到了 85% 以上，而且做到了统一能力的全数据库场景覆盖，比如数据变更，我们支持 MySQL、ElastiSearch、MongoDB、TiDB 的变更前语句审查，变更数据备份，变更操作一键回滚，变更记录审计追踪等。

DTS

vivo 的 DTS 服务是基于自身业务需求完全自研的数据传输服务，主要提供 RDBMS、NoSQL、OLAP 等数据源之间的数据交互。集数据迁移、订阅、同步、备份的一体化服务，从功能上来看，主要有三个特性：第一是同步链路的稳定性和数据可靠性保障，通过结合各个数据源产品的自身特性可以做到数据不重不丢，给业务提供 99.99% 的服务可用性保障；第二是功能层面支持异构的多种数据库类型，除了同步、迁移、订阅等这些通用功能外，我们还支持变更数据的集中化存储和检索；第三是故障容灾层面，支持节点级别故障容灾，可以做到同步链路秒级恢复，也支持断点续传，可以有效地解决因硬件、网络等异常导致的传输中断问题。

MySQL 2.0

MySQL 作为最流行的开源数据库，在 vivo 同样承担了关系型数据库服务的重任，上图的 MySQL 2.0 是我们内部的架构版本。

vivo 为了快速解决当时面临的可用性问题，基于 MHA+ 自研组件做了MySQL 1.0 版本。目前已经演化到了 2.0 版本，MHA 等组件依赖已经没有了，从架构上看，2.0 版本的服务接入层我们支持业务使用 DNS 或者名字服务接入，中间加入了一层自研的代理层 Proxy，这一层做到了 100%与 MySQL 语法和协议兼容，在 Proxy 上面我们又实现了三级读写分离控制，流量管控，数据透明加密，SQL 防火墙，日志审计等功能。

Proxy 层结合底层的高可用组件共同实现了 MySQL 集群的自动化、手动故障转移，通过 Raft 机制保障了高可用管控组件自身的可用性，当然 MySQL 用的还是主从架构，在同地域可以跨 IDC 部署，跨地域同步可以用前面提到的 DTS 产品解决，跨地域多活目前还未支持，这部分将在规划中的 3.0 架构实现。

Redis 服务

Redis 作为非常流行和优秀的 KV 存储服务，在 vivo 得到了大量的应用，在 vivo 互联网的发展历程中，有使用过单机版的 Redis，也有使用过主从版本的 Redis。到目前为止，已经全部升级到集群模式，集群模式的自动故障转移，弹性伸缩等特性帮我们解决了不少问题。

但当单集群规模扩大到 TB 级别和单集群节点数扩展到 500+以后还是存在很多问题，基于解决这些问题的诉求，我们在 Redis 上面做了一些改造开发，主要包括三部份：

第一是 Redis Cluster 的多机房可用性问题，为此我们研发了基于 Redis Cluster 的多活版本 Redis。

第二是对 Redis 的数据持久化做了加强，包括 AOF 日志改造，AEP 硬件的引入，包括正在规划中的 Forkless RDB 等。

第三是 Redis 同步和集群模式的增强，包括异步复制，文件缓存，水位控制等，还有对 Redis Cluster 指令的时间复杂度优化，Redis Cluster 指令的时间复杂度曾经给我们的运维带来了很多的困扰，通过算法的优化，时间复杂度降低了很多，这块的代码目前已经同步给社区。

磁盘 KV 存储服务

我们在 Redis 上做了这些优化后，发现仅仅有内存型的 KV 存储是无法满足业务需要，未来还有更大的存储规模需求，必须有基于磁盘的 KV 存储产品来进行数据分流，对数据进行分层存储，为此我们基于 TiKV 研发了磁盘 KV 存储产品。

我们在启动磁盘 KV 存储服务研发项目时就明确了业务对存储的基本诉求。第一是兼容 Redis 协议，可以很方便地从原来使用 Redis 服务的项目中切换过来；第二是存储成本要低，存储空间要大，性能要高，结合运维的一些基本诉求比如故障自动转移，能够快速地扩缩容等。最终我们选择了以 TiKV 作为底层存储引擎实现的磁盘 KV 存储服务，我们在上层封装了 Redis 指令和 Redis 协议。其中选择 TiKV 还有一个原因是 vivo 整体的存储产品体系中有使用到 TiDB 产品，这样可以降低运维人员学习成本，能够快速上手。

我们还开发了一系列周边工具，比如 Bulk load 批量导入工具，支持从大数据生态中导入数据到磁盘 KV 存储，数据备份还原工具，Redis 到磁盘 KV 同步工具等，这些工具大大地降低了业务的迁移成本，目前我们的磁盘 KV 存储产品已经在内部广泛使用，支撑了多个 TB 级别的存储场景。

对象存储服务

我们知道业务运行过程中除了需要对一些结构化或者半结构化的数据有存取需求之外，还有大量的非结构化数据存取需求。vivo 的对象与文件存储服务正是在这样的背景下去建设的。

对象和文件存储服务使用统一的存储底座，存储空间可以扩展到 EB 级别以上，上层对外暴露的有标准对象存储协议和 POSIX 文件协议，业务可以使用对象存储协议存取文件、图片、视频、软件包等，标准的 POSIX 文件协议可以使得业务像使用本地文件系统一样扩展自己的存取需求，比如 HPC 和 AI 训练场景，可以支撑百亿级别小文件的 GPU 模型训练。针对图片和视频文件，还扩展了一些常用的图片和视频处理能力，比如水印、缩略图、裁剪、截帧、转码等。

前面简单介绍了 vivo 数据库与存储平台的一些产品能力，那么下面我们再来聊聊在平台建设过程中，我们对一些技术方向的探索和思考。

三、数据库与存储技术探索和思考

运维研发效率提升

在平台建设方面，运维研发效率提升是老生常谈的话题，在业内也有很多建设得不错的平台和产品，但是关于如何在数据存储这一层提升运维研发效率相关的探索还比较少。

我们的理解是：首先是资源的交付要足够敏捷，要屏蔽足够多的底层技术细节，为此我们将 IDC 自建的数据库、云数据库、云主机自建数据库进行云上云下的统一管理，提供统一的操作视图，降低运维和研发的使用成本；同时要提升效率就不能只关注生产环境，需要使用有效的手段将研发、测试、预发、生产等多种环境统一管控起来，做到体验统一，数据和权限安全隔离。

此外，我们运用 DevOps 解决方案的思想，将整个平台在逻辑上分为两个域，一个是研发域，一个是运维域。

在研发域，我们需要思考如何解决研发同学关于数据库和存储产品的效率问题。交付一个数据库实例和支持他们在平台上可以建库建表是远远不够的，很多操作是发生在编码过程中的，比如构造测试数据，编写增删改查的逻辑代码等等。我们希望在这些过程中就和我们的平台发生交互，最大程度的提升研发效率。

在运维域，目前有一个比较好的衡量指标就是日常运维过程中需要登录服务器操作的次数，现在我们在做的工作就是将运维的动作全部标准化、自动化，并且未来有一些操作可以智能化。

在研发和运维交互的部分，我们的建设目标是减少交互，流程中参与的人越少效率就越高，让系统来做决策，实现的方案是做自助化。

数据安全管理

安全无小事，为此我们将数据库安全和数据安全的部分单独拿出来进行规划和设计，基本的原则就是权责分明。数据库体系涉及到账号密码等，我们联合 SDK 团队共同研发了密码加密传输使用方案，数据库的密码对研发、运维而言都是密文，在项目的配置文件中依然是密文，使用时对接公司的密钥管理系统进行解密。

针对数据的部分，我们联合安全团队对敏感数据做了自动标注识别，分类分级，对敏感数据的查询、导出、变更上做了严格的管控，比如权限管控、权限升级、通过数字水印技术进行使用追踪，通过事后的审计可以追溯到谁在什么时刻查看了什么数据。针对敏感数据我们也做了透明加解密操作，落盘到存储介质的数据是经过加密存储的。

同理，备份的数据和日志也做了加密存储，这些是目前我们做的事情，未来在安全上我们还有很多的工作要做。

数据变更管理

针对数据变更的场景，我们关注的主要有两点：

第一是数据变更本身会不会影响已有的业务，为此我们建设了不锁表结构、不锁表数据的变更能力，针对上线前、上线中、上线后三个环节设置三道防线。杜绝一些不好的 SQL 或者 Query 流入到生产环境，针对变更过程中或者变更结束后如果想回滚，我们也做了一键回滚方案。

第二是变更效率问题，针对多个环境、多个集群我们提供了一键同步数据变更方案，同时为了更好地提升用户体验，我们也提供了 GUI 的库表设计平台。有了这些基础之后，我们将整个场景的能力全部开放给研发同学，现在研发同学可以 24 小时自助进行数据变更操作，极大地提升了变更效率。

数据存储成本管控

关于成本我们主要从四个方面进行管理：

第一是预算的管控，资源去物理化，业务以资源为粒度进行预算提报，在预算管控层面对服务器的消耗进行预测和不断的修正，保证水位的健康。

第二是数据库服务的部署，这块我们经历了几个阶段，最早期是单机单实例，浪费了很多资源，后面发展为标准化套餐部署，同一类型的存储资源不同的套餐混合，通过算法的优化不断的提升资源的使用效率。

第三是不同属性资源的混合部署，比如数据库的代理层和对象存储的数据节点混合部署，这两种资源一个是 CPU 型的，一个是存储型的，正好可以互补，再往后发展的下一个阶段应该是云原生存储计算分离，还在探索中。

第四是服务部署之后还需要不断的关注运行中的状况，对容量做巡检和预警，对集群及时的做升降配操作，保障整个运行状态有序。同时需要关注业务运行状态，及时回收下线数据存储集群，减少僵尸集群的存在。

成本部分还有一个重点就是硬件资源的迭代，这里就不做展开了。

对象与文件储存建设与思考

对象与文件存储这块我们主要关注的有两点：

• 第一是成本，关于成本这块我们在数据冗余策略这块使用了 EC，并且做了跨 IDC 的 EC，单个 IDC 全部故障也不会影响我们的数据可靠性。我们还引入了高密度大容量存储服务器，尽可能多地提升单机架存储密度，需要注意的是服务器采购之后的运行成本也不可忽视，依然有很大的优化空间。我们还提供了数据无损和透明压缩的能力和生命周期管理的能力，及时清理过期数据和对冷数据进行归档。通过多种手段持续降低存储成本。

• 第二是性能，关于性能这块我们提供了桶&对象粒度底层存储引擎 IO 隔离，通过引入一些开源组件如 alluxio 等提供了服务端+客户端缓存，提升热点数据读取性能，在底层存储引擎我们引入了 opencas 和 IO_URING 技术，进一步提升整机的磁盘 IO 吞吐。

以上就是我们目前在建设的能力的一些探索和思考，最后再来看下我们未来的规划。

四、数据库与存储平台规划

在整个存储服务层，我们会不断地完善存储服务矩阵，打磨产品，提供更多元的存储产品，更好地满足业务发展诉求。同时在存储服务层会基于现有存储产品做一些 SAAS 服务来满足更多的业务诉求。在功能层，我们拆解为 4 部分：

• 数据基础服务，这部分提供存储产品基本功能，包括部署、扩缩容、迁移、监控告警、备份恢复，下线回收等等。

• 数据服务，存储产品本质上是存储数据的载体，针对数据本身我们也有一些规范，最基本的比如数据的查询变更性能优化，数据治理和如何深入到业务编码过程中去。

• 存储自治服务，初步划分为性能自治、容量自治、智能诊断、场景服务四大块，通过自治服务一方面可以提升 DBA 工作的幸福感，一方面也可以大大的提升我们系统本身的健壮性和稳定性。

• 数据安全服务，目前虽然建设了一些能力，但是不够体系化，未来会继续加大投入。

未来整个存储服务体系会融入到公司整体的混合云架构中，给用户提供一站式和标准化的体验。

数据库

文章转载自PingCAP，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

vivo 数据库与存储平台的建设和探索

评论