360 海量数据存储 Zeppelin 设计与实现

直播实录

360 海量数据存储 zeppelin 设计与实现

我们先来谈谈在线存储和离线存储的区别

离线存储的需求很统一, 就是离线数据分析, 产生报表等等. 也因为这统一的需求, 所以目前hdfs 为首的离线存储基本统一了离线存储这个平台. 离线存储最重要的就是吞吐, 以及资源的利用率. 对性能, 可靠性的要求其实并不多. (所以这也是为什么 java 系在离线存储这块基本一统的原因, java提供的大量的基础库, 包等等. 而离线存储又对性能, 可靠性没有比较高的要求, 因此java GC等问题也不明显)

所以我们可以看到虽然现在离线的分析 工具 一直在变, 有hadoop, spark, storm 等等, 但是离线的存储基本都没有变化. 还是hdfs 一统这一套. 所以我认为未来离线存储这块不会有太大的变化

在线存储

指的是直接面向用户请求的存储类型. 由于用户请求的多样性, 因此在线存储通常需要满足各种不同场景的需求.

比如用户系统存储是提供对象的服务, 能够直接通过HTTP接口来访问, 那么自然就诞生了对象存储s3这样的服务

比如用户希望所存储的数据是关系性数据库的模型, 能够以 SQL 的形式来访问, 那么其实就是mysql, 或者现在比较火热的NewSql

比如用户只希望访问key, value的形式, 那么我们就可以用最简单的kv接口, 那么就有Nosql, bada, cassandra, zeppelin 等等就提供这样的服务

当然也有多数据结构的请求, hash, list 等等就有了redis, 有POSIX文件系统接口了请求, 那么就有了cephfs. 有了希望提供跟磁盘一样的iSCSI 这样接口的块设备的需求, 就有了块存储, 就是ceph.

从上面可以看到和离线存储对比, 在线存储的需求更加的复杂, 从接口类型, 从对访问延期的需求, 比如对于kv的接口, 我们一般希望是2ms左右, 那么对于对象存储的接口我们一般在10ms~20ms. 对于SQL, 我们的容忍度可能更高一些, 可以允许有100 ms. 处理延迟的需求, 我们还会有数据可靠性的不同, 比如一般在SQL 里面我们一般需要做到强一致. 但是在kv接口里面我们一般只需要做到最终一致性即可. 同样对于资源的利用也是不一样, 如果存储的是稍微偏冷的数据, 一定是EC编码, 然后存在大的机械盘. 对于线上比较热的数据, 延迟要求比较高. 一定是3副本, 存在SSD盘上

从上面可以看到在线存储的需求多样性, 并且对服务的可靠性要求各种不一样, 因此我们很难看到有一个在线存储能够统一满足所有的需求. 这也是为什么现在没有一个开源的在线存储服务能够像hdfs 那样的使用率. 因此一定是在不同的场景下面有不同的存储的解决方案

总结一下在线存储的要求

同样google 的F1 是基于spanner 的key-value 接口实现了SQL了接口. 就封装成了NewSql

因此其实我们也可以这么说对于这么多接口的实现, 其实后续都会转换成基于key-value 接口实现另一种接口的形式, 因为key-value 接口足够简单, 有了稳定的key-value 存储, 只需要在上层提供不同接口转换成key-value 接口的实现即可. 当然不同的接口实现难度还是不太一样, 比如实现SQL接口, POSIX文件系统接口, 图数据库肯定要比实现一个对象存储的接口要容易很多

所以**zeppelin 定位的是高可用, 高性能, 可定制一致性的key-value 服务**, 上层可以对接各个协议的实现, 目前zeppelin 已经实现支持key-value 接口, 用于线上搜索系统中. 标准的S3 接口实现, 并且用于公司内部存储 docker 镜像, 代码发布系统等等

这个是目前360 的存储体系

数据分布

* 均匀性(uniformity)

* 稳定性(consistency)

所有的分片策略都是在均匀性和稳定性之间的折衷

常见策略

* 一致性Hash

* 固定Hash 分片

* Range Hash

* crush

zeppelin 的选择

固定Hash 分片

有中心节点的设计.

* 为什么这么做?

* 目前主流的设计一般是两种

* Bigtable 为代表的, 有MetaServer, DataServer的设计, MetaServer存储元数据信息, DataServer存储实际的数据. 包括 百度的Mola, bigtable, Hbase等等

* Dynamo 为代表的, 对等结构设计. 每一个节点都是一样的结构, 每一个节点都保存了数据的元信息以及数据. 包括 cassandra, Riak 等等

zeppelin 的选择

有中心节点优点是简单, 清晰, 更新及时, 可扩展性强. 缺点是存在单点故障

无中心节点优点是无单点故障, 水平扩展能力强. 缺点是消息传播慢, 限制集群规模等等

因为后续我们会考虑支持zeppelin 到千个节点的规模, 因此无中心节点的设计不一定能够满足我们后期的扩展性, 所以zeppelin 是有中心节点的设计, 那么我们就需要做大量的事情去减少对Meta Server 的压力

zeppelin 选择有中心节点的设计,  但是我们操作大量的优化去尽可能避免中心节点的压力, 同时通过一致性协议来保证元数据更新的强一致

1. Client 缓存大量元信息, 只有Client 出错是才有访问Meta Server

2. 以节点为维度的心跳设计

副本策略

1. Master - Slave

   以MongoDB, redis-cluster, bada 为主的, 有主从结构的设计, 那么读写的时候, 客户端访问的都是主副本, 通过binlog/oplog 来将数据同步给从副本

2. Quorum(W+R>N)

   以cassandra, dynamo 为主的, 没有主从结构的设计, 读写的时候满足quorum W + R > N, 因此写入的时候写入2个副本成功才能返回. 读的时候需要读副本然后返回最新的. 这里的最新可以是时间戳或者逻辑时间

3. EC (erasure code)

   EC 其实是一个CPU 换存储的策略, ec 编码主要用于保存偏冷数据, 可以以减少的副本数实现和3副本一样的可用性. ec编码遇到的问题是如果某一个副本挂掉以后, 想要恢复副本的过程必须与其他多个节点进行通信来恢复数据, 会照成大量的网络开销.

zeppelin 的选择

目前zeppelin 只实现的Master-Slave 策略, 后续会根据业务场景, 存储成本的需求实现EC, Quorum.

存储引擎

Manos Athanassoulis  [**Designing Access Methods: The RUM Conjecture**](http://101.96.8.165/stratos.seas.harvard.edu/files/stratos/files/rum.pdf)

RUM 是 写放大, 读放大, 空间放大 之前的权衡

• 写放大: 写入引擎的数据和实际存储的数据大小比

• 读放大: 读放大是一次读取需要的IO 次数大小比

• 空间放大: 实际的数据总量和引擎中存储的数据总量关系大小比

当然这里主要根据DAM 模型(disk access model), 得出结论

当然这里并没有考虑 LSM Tree 里面场景的 bloom filter 等等

这里B+ tree 主要用在 数据库相关, 支持范围查找的操作, 因为B+ Tree 在底下有序数据是连续的

zeppelin 的选择

zeppelin 目前使用的是改过的rocksdb, nemo-rocksdb.  nemo-rocksdb 支持TTL, 支持后台定期compaction 等等功能

https://github.com/Qihoo360/nemo-rocksdb

一致性协议

floyd 是c++ 实现的raft 协议, 元信息模块的管理主要通过floyd 来维护.

1. 关于paxos, multi-paxos 的关系

其实paxos 是关于对某一个问题达成一致的一个协议. paxos make simple 花大部分的时间解释的就是这个一个提案的问题, 然后在结尾的Implementing a State Machine 的章节介绍了我们大部分的应用场景是对一堆连续的问题达成一致, 所以最简单的方法就是实现每一个问题独立运行一个Paxos 的过程, 但是这样每一个问题都需要Prepare, Accept 两个阶段才能够完成. 所以我们能不能把这个过程给减少. 那么可以想到的解决方案就是把Prepare 减少, 那么就引入了leader, 引入了leader 就必然有选leader 的过程. 才有了后续的事情, 这里可以看出其实lamport 对multi-paxos 的具体实现其实是并没有细节的指定的, 只是简单提了一下. 所以才有各种不同的multi-paxos 的实现

那么paxos make live 这个文章里面主要讲的是如何使用multi paxos 实现chubby 的过程, 以及实现过程中需要解决的问题, 比如需要解决磁盘冲突, 如何优化读请求, 引入了Epoch number等, 可以看成是对实现multi-paxos 的实践

2. 关于 multi-paxos 和 raft 的关系

从上面可以看出其实我们对比的时候不应该拿paxos 和 raft 对比, 因为paxos 是对于一个问题达成一致的协议, 而raft 本身是对一堆连续的问题达成一致的协议. 所以应该比较的是multi-paxos 和raft

那么multi-paxos 和 raft 的关系是什么呢?

raft 是基于对multi paxos 的两个限制形成的

* 发送的请求的是连续的, 也就是说raft 的append 操作必须是连续的. 而paxos 可以并发的. (其实这里并发只是append log 的并发提高, 应用的state machine 还是必须是有序的)

* 选主是有限制的, 必须有最新, 最全的日志节点才可以当选. 而multi-paxos 是随意的 所以raft 可以看成是简化版本的multi paxos(这里multi-paxos 因为允许并发的写log, 因此不存在一个最新, 最全的日志节点, 因此只能这么做. 这样带来的麻烦就是选主以后, 需要将主里面没有的log 给补全, 并执行commit 过程)

基于这两个限制, 因此raft 的实现可以更简单, 但是multi-paxos 的并发度理论上是更高的.

可以对比一下multi-paxos 和 raft 可能出现的日志

**multi-paxos**

3. 关于paxos, multi-paxos, raft 的关系

所以我觉得multi-paxos, raft 都是对一堆连续的问题达成一致的协议, 而paxos 是对一个问题达成一致的协议, 因此multi-paxos, raft 其实都是为了简化paxos 在多个问题上面达成一致的需要的两个阶段, 因此都简化了prepare 阶段, 提出了通过有leader 来简化这个过程. multi-paxos, raft 只是简化不一样, raft 让用户的log 必须是有序, 选主必须是有日志最全的节点, 而multi-paxos 没有这些限制. 因此raft 的实现会更简单.

因此从这个角度来看, Diego Ongaro 实现raft 这个论文实现的初衷应该是达到了, 让大家更容易理解这个paxos 这个东西

zeppelin 的选择

zeppelin MetaServer 一致性是由自己实现的raft 库floyd 来保证. 写入和读取可以通过raft 协议实现强一致, 同时为了性能考虑我们在读取的时候还提供DirtyRead 的接口, floyd 已经在github上面开源, 是用c++实现的raft 协议, 实现的非常的简介明了

https://github.com/Qihoo360/floyd

floyd 的压测报告

https://github.com/Qihoo360/floyd/wiki/5-性能测试

1.整体实现

4，后台工作线程，包括BGSave and DBSync Thread，Binlog Purge Thread

- Binlog Purge Thread：为了减少对磁盘空间的占用，Binlog Purge Thread会定期删除过期的Binlog

- BGSave and DBSync Thread：建立主从关系时，如果主Partition发现同步点已经落后于当前保留的最早的binlog，则需要进行全量同步。该线程会首先将整个数据内容dump一份并发送给对应从Partition。全同步过程利用Rsync实现。

4. 客户端请求

客户端需要访问针对某个业务Table进行操作时，会先向Meta Server请求改Table的元信息。之后每个访问请求，都会根据key计算出其所属于的Partition，通过元信息计算器Master所在的Node Server。直接请求改Node Server

5. 故障检测及处理

Node Server定期向Meta Server发送PING消息，当节点宕机或者网络中断发生时。Meta Server会感知并修改其维护的元信息，并将元信息Epoch加一。元信息修改后，其他Node Server会从PING消息的回复中获得新Epoch，由于与本地记录不同，Node Server会由MetaCmd Thread向Meta Server 发送PULL消息主动拉去最新元信息。

元信息中记录各个Table中每个Partition所负责的Master Node Server及两个Slave Node Server。Node Server获得最新的元信息，并根据该信息修改自己维护的Partitions的主从角色，建立主从关系，提供服务。