怎么掌握HBase架构

共计 3569 个字符，预计需要花费 9 分钟才能阅读完成。

本篇内容介绍了“怎么掌握 HBase 架构”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

HBase 读的实现

通过前文的描述，我们知道在 HBase 写时，相同 Cell(RowKey/ColumnFamily/Column 相同) 并不保证在一起，甚至删除一个 Cell 也只是写入一个新的 Cell，它含有 Delete 标记，而不一定将一个 Cell 真正删除了，因而这就引起了一个问题，如何实现读的问题？要解决这个问题，我们先来分析一下相同的 Cell 可能存在的位置：首先对新写入的 Cell，它会存在于 MemStore 中；然后对之前已经 Flush 到 HDFS 中的 Cell，它会存在于某个或某些 StoreFile(HFile) 中；最后，对刚读取过的 Cell，它可能存在于 BlockCache 中。既然相同的 Cell 可能存储在三个地方，在读取的时候只需要扫瞄这三个地方，然后将结果合并即可 (Merge Read)，在 HBase 中扫瞄的顺序依次是：BlockCache、MemStore、StoreFile(HFile)。其中 StoreFile 的扫瞄先会使用 Bloom Filter 过滤那些不可能符合条件的 HFile，然后使用 Block Index 快速定位 Cell，并将其加载到 BlockCache 中，然后从 BlockCache 中读取。我们知道一个 HStore 可能存在多个 StoreFile(HFile)，此时需要扫瞄多个 HFile，如果 HFile 过多又是会引起性能问题。

Compaction

MemStore 每次 Flush 会创建新的 HFile，而过多的 HFile 会引起读的性能问题，那么如何解决这个问题呢？HBase 采用 Compaction 机制来解决这个问题，有点类似 Java 中的 GC 机制，起初 Java 不停的申请内存而不释放，增加性能，然而天下没有免费的午餐，最终我们还是要在某个条件下去收集垃圾，很多时候需要 Stop-The-World，这种 Stop-The-World 有些时候也会引起很大的问题，比如参考本人写的这篇文章，因而设计是一种权衡，没有完美的。还是类似 Java 中的 GC，在 HBase 中 Compaction 分为两种：Minor Compaction 和 Major Compaction。

Minor Compaction 是指选取一些小的、相邻的 StoreFile 将他们合并成一个更大的 StoreFile，在这个过程中不会处理已经 Deleted 或 Expired 的 Cell。一次 Minor Compaction 的结果是更少并且更大的 StoreFile。（这个是对的吗？BigTable 中是这样描述 Minor Compaction 的：As write operations execute, the size of the memtable in- creases. When the memtable size reaches a threshold, the memtable is frozen, a new memtable is created, and the frozen memtable is converted to an SSTable and written to GFS. This minor compaction process has two goals: it shrinks the memory usage of the tablet server, and it reduces the amount of data that has to be read from the commit log during recovery if this server dies. Incom- ing read and write operations can continue while com- pactions occur.  也就是说它将 memtable 的数据 flush 的一个 HFile/SSTable 称为一次 Minor Compaction）

Major Compaction 是指将所有的 StoreFile 合并成一个 StoreFile，在这个过程中，标记为 Deleted 的 Cell 会被删除，而那些已经 Expired 的 Cell 会被丢弃，那些已经超过最多版本数的 Cell 会被丢弃。一次 Major Compaction 的结果是一个 HStore 只有一个 StoreFile 存在。Major Compaction 可以手动或自动触发，然而由于它会引起很多的 IO 操作而引起性能问题，因而它一般会被安排在周末、凌晨等集群比较闲的时间。

更形象一点，如下面两张图分别表示 Minor Compaction 和 Major Compaction。

HRegion Split

最初，一个 Table 只有一个 HRegion，随着数据写入增加，如果一个 HRegion 到达一定的大小，就需要 Split 成两个 HRegion，这个大小由 hbase.hregion.max.filesize 指定，默认为 10GB。当 split 时，两个新的 HRegion 会在同一个 HRegionServer 中创建，它们各自包含父 HRegion 一半的数据，当 Split 完成后，父 HRegion 会下线，而新的两个子 HRegion 会向 HMaster 注册上线，处于负载均衡的考虑，这两个新的 HRegion 可能会被 HMaster 分配到其他的 HRegionServer 中。关于 Split 的详细信息。

HRegion 负载均衡

在 HRegion Split 后，两个新的 HRegion 最初会和之前的父 HRegion 在相同的 HRegionServer 上，出于负载均衡的考虑，HMaster 可能会将其中的一个甚至两个重新分配的其他的 HRegionServer 中，此时会引起有些 HRegionServer 处理的数据在其他节点上，直到下一次 Major Compaction 将数据从远端的节点移动到本地节点。

HRegionServer Recovery

当一台 HRegionServer 宕机时，由于它不再发送 Heartbeat 给 ZooKeeper 而被监测到，此时 ZooKeeper 会通知 HMaster，HMaster 会检测到哪台 HRegionServer 宕机，它将宕机的 HRegionServer 中的 HRegion 重新分配给其他的 HRegionServer，同时 HMaster 会把宕机的 HRegionServer 相关的 WAL 拆分分配给相应的 HRegionServer(将拆分出的 WAL 文件写入对应的目的 HRegionServer 的 WAL 目录中，并并写入对应的 DataNode 中），从而这些 HRegionServer 可以 Replay 分到的 WAL 来重建 MemStore。

HBase 架构简单总结

在 NoSQL 中，存在著名的 CAP 理论，即 Consistency、Availability、Partition Tolerance 不可全得，目前市场上基本上的 NoSQL 都采用 Partition Tolerance 以实现数据得水平扩展，来处理 Relational DataBase 遇到的无法处理数据量太大的问题，或引起的性能问题。因而只有剩下 C 和 A 可以选择。HBase 在两者之间选择了 Consistency，然后使用多个 HMaster 以及支持 HRegionServer 的 failure 监控、ZooKeeper 引入作为协调者等各种手段来解决 Availability 问题，然而当网络的 Split-Brain(Network Partition) 发生时，它还是无法完全解决 Availability 的问题。从这个角度上，Cassandra 选择了 A，即它在网络 Split-Brain 时还是能正常写，而使用其他技术来解决 Consistency 的问题，如读的时候触发 Consistency 判断和处理。这是设计上的限制。
从实现上的优点：

HBase 采用强一致性模型，在一个写返回后，保证所有的读都读到相同的数据。

通过 HRegion 动态 Split 和 Merge 实现自动扩展，并使用 HDFS 提供的多个数据备份功能，实现高可用性。

采用 HRegionServer 和 DataNode 运行在相同的服务器上实现数据的本地化，提升读写性能，并减少网络压力。

内建 HRegionServer 的宕机自动恢复。采用 WAL 来 Replay 还未持久化到 HDFS 的数据。

可以无缝的和 Hadoop/MapReduce 集成。

实现上的缺点：

WAL 的 Replay 过程可能会很慢。

灾难恢复比较复杂，也会比较慢。

Major Compaction 会引起 IO Storm。

“怎么掌握 HBase 架构”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！