《HBase架构简介》.pdf

HBase 架构简介 一、概览 图 1 图1 指出了在HBase 中其实有两种文件，一种是write-ahead log ，而另一种 则是真正存储数据的地方。而这些文件都被HRegionServers 来处理。从图中可以 看出，文件最后在HDFS 中存在不同的block 中。 基本的通信流程是这样的：当一个client 需要查询某一特点的row 时，它会 先连到Zookeeper （事实上是ZK 管理的集群），并且从zookeeper 获取持有-ROOT- 的region 的server name ，有了这个信息以后，我们就可以去寻找包含刚刚我们 查询的row 的.META.的region 的server name 。这些信息都会被客户端缓存下来。 最后，我们可以通过.META.找到持有我们所查询的 rowkey 的 region。一旦获取 了这个row 在哪个 region 中，这个信息也会被客户端缓存下来，所以下次再访 问的时候，就可以直接访问那个region 了。过了一段时间后，客户端就会搜集到 相当全面的信息：查询某row 时应到哪个region 去找，从而不需要去查询.META. 了。 当HBase 启动时，HMaster 负责向各个 RS 分配 region，其中当然也包括了 -ROOT-和.META.某 RS 打开一个 Region，这时会创建一个相应的 HRegion 对象， 当HRegion 打开时，它会为每一个HColumnFamily 创建一个Store ，每一个Store 都会有一个或者多个StoreFile 的实例，它是对真正的存储文件HFile 的轻量级封 装。每一个Store 都会有一个MemStore，并且整个RS 会共享一个HLog 实例。 二、写 当一个client 向RS 发起一个HTable.put(Put)的请求时，第一步先把数据写入 write-ahead-log(WAL),被HLog 所表示，这个WAL 是一个标准的Hadoo SequenceFile， 当Server 挂掉以后再重启， WAL 可以继续将未被持久化的数据持久化。 一旦数据被写入WAL ，它就被放到MemStore 中，与此同时，会检查MemStore 是否已经满了，假如已经满了，那么就需要把 MemStore 中的数据flush 到磁盘 上，这个动作由 RS 中一个独立的线程来完成，它会把数据存入HDFS 上的一个 新的 HFile 中。同时它也会记录最后一次被写入的Sequence number，这样就能 知道到目前为止，哪些数据已经被持久化了。 HBase 在HDFS 有一个可配置的目录，默认是/hbase ，你可以使用hadoop fs –lsr 查看hbase 所存储的各个文件。 首当其冲的就是 WAL 文件，它们被放在根目录下的.logs 文件夹下，假如我 这边有6 台rs 组成的测试环境，结构如下： 每个rs 的子目录中存有若干个HFiles。为什么会有多个？（答：log rotation） 这台rs 上的所有region 共享相同的HLog files。我们注意到有log 文件的大小为0， 这其实是在这个文件刚刚创建时相当正常的情况。因为hdfs 用它内置的append 操作来向文件里写，只有当这个block 写完的时候才会让客户端看到。 当一个 log 文件的所有数据都被持久化后而不再需要被使用时，它就会被放 到.oldlogs 中，同样的，这个目录也在根目录下。 Master 十分钟后就来删除这些oldlogs ，并且每分钟都会检查（可配置）。 在hbase 中的每一个表都会在根目录下有一个自己的目录。在每个目录下存 有组成该table 的region 当一个region 中的storefiles 的大小大于hbase.hregion.max.filesize 的值时(或 者通过FColumnDescriptor 来设置column family 大小)，region 就会被分裂成两个 （在原region 目录下直接生成），理论上来讲，这个过程非常快，因为只是为两 个新的region 指定了到stoefiles 的不同引用。完后，rs 就会把原来的那个region 给关掉，不会再响