Fusion-NewSQL是由滴滴自研的在分布式KV存储基础上构建的NewSQL存储系统。Fusion-NewSQL兼容了MySQL协议，支持二级索引功能，提供超大规模数据持久化存储和高性能读写。

一. 遇到的问题

滴滴的业务快速持续发展，数据量和请求量急剧增长，对存储系统等压力与日俱增。虽然分库分表在一定程度上可以解决数据量和请求增加的需求，但是由于滴滴多条业务线（快车，专车，两轮车等）的业务快速变化，数据库加字段加索引的需求非常频繁，分库分表方案对于频繁的Schema变更操作并不友好，会导致DBA任务繁重，变更周期长，并且对巨大的表操作还会对线上有一定影响。同时，分库分表方案对二级索引支持不友好或者根本不支持。

鉴于上述情况，NewSQL数据库方案就成为我们解决业务问题的一个方向。

二. 开源产品调研

最开始，我们调研了开源的分布式NewSQL方案：TiDB。虽然TiDB是非常优秀的NewSQL产品，但是对于我们的业务场景来说，TiDB并不是非常适合，原因如下：

我们需要一款高吞吐，低延迟的数据库解决方案，但是TiDB由于要满足事务，2pc方案天然无法满足低延迟（100ms以内的99rt，甚至50ms内的99rt）
我们的多数业务，并不真正需要分布式事务，或者说可以通过其他补偿机制，绕过分布式事务。这是由于业务场景决定的。
TiDB三副本的存储空间成本相对比较高。
我们内部一些离线数据导入在线系统的场景，不能直接和TiDB打通。

基于以上原因，我们开启了自研符合自己业务需求的NewSQL之路。

三. 我们的基础

我们并没有打算从0开发一个完备的NewSQL系统，而是在自研的分布式KV存储Fusion的基础上构建一个能满足我们业务场景的NewSQL。Fusion是采用了Codis架构，兼容Redis协议和数据结构，使用RocksDB作为存储引擎的NoSQL数据库。Fusion在滴滴内部已经有几百个业务在使用，是滴滴主要的在线存储之一。

Fusion的架构图如下：

我们采用hash分片的方式来做数据sharding。从上往下看，用户通过Redis协议的客户端就可以访问Fusion，用户的访问请求发到proxy，再由proxy 转发数据到后端 Fusion 的数据节点。proxy 到后端数据节点的转发，是根据请求的key计算hash值，然后对slot分片数取余，得到一个固定的slotid，每个slotid会固定的映射到一个存储节点，以此解决数据路由问题。

有了一个高并发，低延迟，大容量的存储层后，我们要做的就是在之上构建MySQL协议以及二级索引。

需求

综合考虑大多数用户对需求，我们整理了我们的NewSQL需要提供的几个核心能力：

高吞吐，低延迟，大容量
兼容MySQL协议及下游生态
支持主键查询和二级索引查询
Schema变更灵活，不影响线上服务稳定性。

架构设计

Fusion-NewSQL由下面几个部分组成：

1.解析MySQL协议的DiseServer
2.存储数据的Fusion集群-Data集群
3.存储索引信息的Fusion集群-Index集群
4.负责Schema的管理配置中心-ConfigServer
5.异步构建索引程序-Consumer负责消费Data集群写到MQ中的MySQL-Binlog格式数据，根据schema信息，生成索引数据写入Index集群。
6.外部依赖，MQ，Zookeeper

架构图如下：

技术挑战及方案

1.SQL表转Hashmap

MySQL的表结构数据如何转成Redis的数据结构是我们面临的第一个问题。

如下图：

我们将MySQL表的一行记录转成Redis的一个Hashmap结构。Hashmap的key由表名+主键值组成，满足了全局唯一的特性。下图展示了MySQL通过主键查询转换为Redis协议的方式：

除了数据，索引也需要存储在Fusion-NewSQL中，和数据存成hashmap不同，索引存储成key-value结构。根据索引类型不同，组成key-value的格式还有一点细微的差别(下面的格式为了看起来直观，实际上分隔符，indexname都是做过编码的)：

1.唯一索引：

Key: table_indexname_indexColumnsValue Value: Rowkey

2.非唯一索引：

Key: table_indexname_indexColumnsValue_Rowkey Value：null
造成这种差异的原因就是非唯一索引在加入Rowkey之前的部分是有可能重复的，无法全局唯一。另外，唯一索引不将Rowkey编码在key中，是因为在查询语句是单纯的“=”查询的时候直接get操作就可以找到对应的Rowkey内容，而不需要通过scan，这样的效率更高。

后面会在查询流程中重点讲述如何通过二级索引查询到数据。

2.数据和索引一致性

因为数据和索引分别存储在不同Fusion集群，数据和索引的一致性保证就成了Fusion-New系统面临的一个关键点，在没有分布式事务的情况下，我们当前选择了保证数据索引的最终一致性。用户写入数据在数据集群中开启RocksDB的单机事物，同时按链接保序，这样数据流入MQ的时候就是有序的。异步模块从MQ中消费出来再批量写入到索引集群，整个流程就保证的索引数据的构建与数据集群真实的顺序一致。当然，这中间存在一个时间窗口的数据不一致，这个时间取决于MQ的吞吐能力。

3.二级索引查询

下面是一个使用二级索引查询数据的案例：
dise-server会根据用户查询条件和当前所有索引做匹配，找到符合的索引，然后通过Redis的scan命令，按前缀搜索index集群的数据，获取符合条件的主键。

如下图：

通过主键，可以直接到Data集群查到相应的数据。

根据上面索引数据的格式可以看到，scan范围的时候，前缀必须固定，映射到SQL语句到时候，意味着where到条件中，范围查询只能有一个字段，而不能多个字段。

比如：

索引是age和name两个字段的联合索引。
如果查询语句如下：
select * from student where age > 20 and name >‘W’;
scan就没有办法确定前缀，也就无法通过index_age_name这个索引查询到满足条件的数据，所以使用KV形式存储到索引只能满足where条件中有一个字段是范围查询。当然可以通过将联合索引分开存放，多次交互搜索取交集的方式解决，但是这就和我们减少RPC次数，降低延迟的设计初衷相违背了。为了解决这个问题，我们引入了Elastic Search搜索引擎。

架构图如下：

我们建议用户将需要复杂查询的字段设置为ES索引，consumer消费MQ的时候将这些字段数据写一份到ES中，这样对于对查询条件简单，延迟敏感的查询，使用Index集群的数据；对条件复杂，延迟不敏感的查询使用ES。这样解决了二级索引功能丰富性问题。

4.生态构建

一个单独的存储产品解决所有问题的时代早已经过去，数据孤岛是没有办法很好服务业务的，如何与滴滴现有个各个数据系统打通数据，成了我们必须面对的问题。下面分数据流出到其他系统和从其他系统导入两个方面来阐述Fusion-NewSQL的数据流动方案。

4.1. Fusion-NewSQL到其他存储系统

Fusion-NewSQL是一个新系统，没办法短时间让各个数据系统为我们做适配。既然Fusion-NewSQL已经有了Schema信息，那么通过兼容MySQL的Binlog格式，将Fusion-NewSQL在数据链路中伪装成MySQL，就可以直接使用Mysql的下游数据流动链路。这样的方式用最小的工作量最大程度做到了兼容。

4.2.Hive到Fusion-NewSQL

Fusion-NewSQL还支持将离线的Hive表中的数据通过Fusion-NewSQL提供的FastLoad（DTS）工具，将Hive表数据转入到Fusion-NewSQL，满足离线数据到在线的数据流动。

如果用户自己完成数据流转，一般会扫描Hive表，然后构建MySQL的写入语句，一条条将数据写入到Fusion-NewSQL，

流程如下面这样：

从上面的流程可以看出这种迁移方式有几个问题：

1.每条Hive数据都要经过较长链路，数据导入耗时较长。

2.离线平台的数据量大，吞吐高，数据导入直接大幅提升在线系统的QPS，对在线系统的稳定性有较大影响。

从上面的痛点可以看出来，主要的问题是离线数据导入使用了在线系统复杂的IO链路。所以如何绕过在线的长IO链路，做批量导入就成了解决这个问题的关键。我们设计了Fastload数据导入平台，绕过在线IO路径

流程如下：

通过Hadoop并行计算，将需要导入的Hive数据直接构建成Fusion-NewSQL能识别的sst文件。Fusion-NewSQL直接将sst文件从远端下载到本地，然后使用存储节点通过Rocksdb提供ingest功能，直接将sst文件加载到Fusion-NewSQL中，用户可以读到加载到sst文件中的数据。通过这样的预先构建sst文件，直接文件网络传输和存储引擎直接加载的步骤，就避免了数据导入走在线IO复杂流程，解决了稳定性问题，同时将数据导入耗时减少到原来的1/10。

总结

通过解决上面的技术点，我们用了较小的代价，构建了一个基于KV存储的NewSQL系统，并且快速将Fusion-NewSQL系统接入到滴滴整体的数据链路中。虽然这不是一个完备的NewSQL系统，但已经可以满足大多数业务场景的需要，切实实现了20%工作量满足80%功能的需求。当前Fusion-NewSQL已经接入订单、预估、账单、用户中心、交易引擎等核心业务，总的数据如下图：

后续工作

有限制的事物支持，比如让业务规划落在一个节点的数据可以支持单机跨行事务；
实时索引替代异步索引，满足即写即读。目前已经有一个写穿+补偿机制的方案，在没有分布式事务的前提下满足正常状态的实时索引，异常情况下保证数据索引最终一致的方案；
更多的SQL协议和功能支持。

作者介绍：李鑫，滴滴出行资深工程师，曾就职蘑菇街，海康威视。多年分布式存储领域设计及开发经验。曾参与NoSQL/NewSQL数据库Fusion，分布式时序数据库sentry，NewSQL数据库SDB等系统的设计开发工作。

想了解更多关于架构技术相关专题的同学，可以关注12月6日在北京·国际会议中心举办的【2019 ArchSummit 北京站】会议
https://archsummit.infoq.cn/2019/beijing/track

创作场景

滴滴从 KV 存储到 NewSQL 实战