将宕机时间缩减到5分钟，Facebook揭露下一代数据存储_最新动态

您所在的位置：程序员俱乐部 > 新闻资讯 > 最新动态 > 将宕机时间缩减到5分钟，Facebook揭露下一代数据存储

将宕机时间缩减到5分钟，Facebook揭露下一代数据存储

2014/6/9 22:42:18 程序员俱乐部我要评论(0)

摘要：英文原文：HydraBase–TheevolutionofHBase@Facebook作为社交巨头，Facebook数据增长的速度可想而知，因此，在选择了适合的技术后，他们还必须根据业务需求、数据增长情况等不停的优化，因此就有了之前的WebScaleSQL。而本次我们要说的是该公司HBase内部衍生版本HydraBase，虽然并未开源，但是我们不妨从Facebook博文中一睹社交巨头的设计理念。以下为译文自2010年将SMS、chat
标签：Facebook 数据宕机

class="topic_img" alt=""/>

　　英文原文： HydraBase – The evolution of HBase@Facebook

　　作为社交巨头，Facebook 数据增长的速度可想而知，因此，在选择了适合的技术后，他们还必须根据业务需求、数据增长情况等不停的优化，因此就有了之前的 WebScaleSQL。而本次我们要说的是该公司 HBase 内部衍生版本 HydraBase，虽然并未开源，但是我们不妨从 Facebook 博文中一睹社交巨头的设计理念。

　　以下为译文

　　自 2010 年将 SMS、chat、email 及 Facebook Messages 整合到 1 个收件箱后，我们就开始使用 HBase。自此之后，社交巨头 Facebook 就一直扩展这个基于 HDFS 的分布式价值存储系统以满足自己的业务需求。基于其高写入和低随机读取延时，那个时候 HBase 被选择作为 Messages 平台的潜在持久数据存储系统。此外，HBase 还具备一些其他优点，比如纵向扩展、强一致性以及自动故障转移带来的高可用。从那时起，Facebook 就开始重度使用 HBase，比如 Messages 这样的在线事务处理以及一些经常用到在线分析的地方，当下 HBase 已用于内部监视系统、Nearby Friends 功能、索引查询、流数据分析以及为内部cangku.html" target="_blank">数据仓库抓取数据。

　　HBase 可靠性

　　在 Facebook 通常会出现这样一个情况，选择一个潜在满足需求的技术堆栈，然后不停的去优化。对于 Facebook 来说，可靠性尤为重要，而当下我们使用 HBase 需求面临的挑战是单主机失败、机架级故障以及秘籍存储之间的细微差别。解决这些方法的途径之一就是使用主从设置，在两个集群之间做异步更新。然而，这样做的话，我们需要面对集群级别的故障转移，如此主从故障转移将会花费数分钟的时间，而异步操作毫无疑问会带来数据丢失，HydraBase 帮我们解决了这一问题。

　　HBase 基础

　　在了解 HydraBase 之前，首先解释一些 HBase 的基础概念。在 HBase 中，数据是物理共享的，也就是所说的 regions。regions 通过 region 服务器管理，每个 region 服务器会负责一个或以上的 region。当数据被添加到 HBase，它首先会被写到一个 write-ahead log（WAL），即 HLog。一旦写入，这个数据会被随之存储到一个内存 MemStore 中。一旦数据超过了某个阈值，它们就被持久化到磁盘。随着 MemStore 持久化到磁盘的 HFiles 数量增多，HBase 会将几个小的文件合到一些大的文件中，来减少读的开销，这就是所谓的压缩。

　　当某个 region 服务器发生故障，这个服务器负责的所有 region 都会转译到另一个服务器，执行故障转移。鉴于 HBase 故障转移中的实现方式，这将需要做 WAL 的分割和复制，这将大大的延长故障转移的时间。

　　HydraBase 相关

　　上文所说正式 HydraBase 与之最大的区别，取代 region 都只被单一的 region 服务器控制，在 HydraBase 中，每个 region 可以被一群 region 服务器控制。当某个 region 服务器发生故障，备用的 region 服务器会立刻接手服务它所控制的 region，这些备用的 region 服务器可能横跨不同的机架甚至是数据中心，通过不同的故障域来提供高可用。控制每个 region 的服务器会形成一个 quorum，每个 quorum 都有 1 个负责 region 服务来自客户端的读和写请求。HydraBase 使用 RAFT 一致协议来保证跨 quorum 的一致性，每个 quorum 都使用 2F+1，HydraBase 可以承受F级故障。region server 通过同步写入 WAL 来保障一致性，但是只有一部分的 region server 需要完全的写入来保证一致性。

　　quorum 中的成员只存在 active 或 witness 两个模式，active 模式成员会写入到 HDFS，期间会执行数据持久化和压缩。witness 成员智慧参与复制 WAL，但是在负责 region 服务器失败时可以立刻使用。

　　HydraBase 部署模型

　　HydraBase 部署

　　在这个情况下，HydraBase 的部署跨越了 3 个数据中心，quorum 的大小为5。通过这样的设置，负责 region server 可以转移到该区域的任何一个成员。如果只是图 1 中的 Active Leader 失败，同一个数据中心的 Witness Follower 将取而代之，客户端的请求将给它发送。如果丢失的是整个数据中心，见第二张图，第二个数据中心的 Active Follower 会取而代之，鉴于数据中心 2 的 region server 仍然可以给 HDFS 中写数据，因此即使是数据中心 1 不可见，数据仍然可以访问。