聊聊计算存储分离

背景

今天看到了云版本的 HBase2.0 上线了，其中使用了计算存储分离。

这里的计算存储分离只是云 Hbase 2.0 中不起眼的一个小细节，但是其做为一种思想，已经用在了绝大多数的云服务中。

这里简单记录一下计算存储分享的实践过程。

发展过程

网络 IO 瓶颈阶段

以前，计算和存储是放在同一台机器上的，计算直接操作本机的存储，来避免网络 IO 对性能的影响。

然后，随着数据量的增加，单机无法提供横向扩展性，因此有了分布式的应用，引入了跨机器复制数据的操作。但是这里的操作原则依然是尽量的本地化，来避免跨节点网络 IO 对性能的影响。

资源使用率瓶颈阶段

当前，数据中心已经有了 25G, 50G 和 100G 的网络，网络 IO 已经不再是瓶颈了。

此时，关注点变为了减少低资源使用率的机器，同时服务可以云化。最终实现初期流量低时，使用少量资源，流量上升后，可以动态增加机器，来扩充服务能力的目标。

怎么实现这个目标呢？即计算存储分离，按需使用资源。

• 存储端有状态，只存储数据，不处理业务逻辑。
• 计算端无状态，只处理逻辑，不持久化存储数据。

实现方式

通过学习 HBase 2.0 的架构图，来学习一般的实现方式。

计算存储分离

第一步是实现计算层和存储层的分离。如图所示：

• 计算层：负责逻辑运算，读写远程的存储
• QOS 层：保证数据读写质量，保障性能和安全要求
• 存储层：通过副本形式保障数据安全，能够容忍单节点的不可用

通过这种方式，实现了按需使用，弹性扩充。

冷热数据分离

第二步是冷热数据分离，分级存储。

这个通常是在实现了第一步的基础上进行的。

即把不常访问的数据放在成本较低的存储上，被访问时延时会稍微高一些，但是也能满足业务需求。

这种方式，最重要是可以实现把读写较快的存储，用来存放对于实时性要求高的数据，来提高性能，同时降低成本。

技术难点

计算存储分离中，有状态的数据均放在了存储层。因此难点都落在了存储层上。

下面是几个常见的方面：

单机 failover

如何保证存储层的高可用性和数据一致性呢？

目前互联网中通用的解决方案是使用 Paxos/raft 强一致性协议，来实现 5 秒级别的 failover 自动恢复。

与一般方案不同的是 Cassandra，其使用的是 gossip 协议来进行节点发现，用户来配置读和写的一致性级别[4]。

毛刺优化

在读写中，常常会遇到毛刺现象，即部分长尾请求的响应时间偏长。一般是网络抖动、磁盘抖动、负载、GC 等原因。

这种情况的解决方法，也是上面提到的解决方法，即使用多数节点读取写入成功时即认为成功的策略(commit majority feature)。

流控

在负载高时，适应降低后台同步服务的资源占用，来降低读写的毛刺。

当然更好的解决方法是，优化后台同步逻辑，来进一步资源占用。

高可用部署

数据至少部署在两个 DC，Zookeeper 类似的服务部署在三个 DC。

参考

1. 八年磨一剑，阿里云 ApsaraDB for HBase2.0 正式上线
2. 容器化 RDS｜ 计算存储分离架构下的 IO 优化
3. 2017 双 11 技术揭秘—阿里数据库计算存储分离与离在线混布
4. How is the consistency level configured?