1. HBase 有两张特殊的表:
.META.: 记录了用户所有表拆分出来的 Region 映射信息,.META. 可以有多个 Region
-ROOT-(新版中已去掉这一层): 记录了 .META. 表的 Region 信息,-ROOT- 只有一个 Region,无论如何都不会分裂
2. Client 访问用户数据前需要首先访问 ZooKeeper,找到 -ROOT- 表的 Region 所在的服务器位置,然后访问 -ROOT- 表,接着访问 .META. 表,最后才能找到用户数据的服务器位置,并访问。在这期间会有多次网络操作,不过 Client 端会做 cache 缓存。
可以看出,Client 访问 HBase 上数据的过程并不需要 Mster 的参与(寻址访问 ZooKeeper 和 RegionServer,数据读写访问 RegionServer),Master 仅仅维护着 Table 和 Region 的元数据信息,负载较低。
.META. 存储的是所有的 Region 的位置信息,那么 RegionServer 当中的 Region 在进行分裂之后新产生的 Region 是由 Master 来决定存储到哪个 RegionServer,这就意味着,只有 Master 知道 new Region 的位置信息,所以,由 Master 来管理 .META. 这个表当中数据 CRUD(Create, Read, Update, Delete)。
所以,结合以上两点:在没有 Region 分裂的情况下,Master 宕机一段时间是可以忍受的。
StoreFile 以 HFile 格式保存在 HDFS 上,如下图所示:
HFile 是不定长的,长度固定的只有其中的两个部分:Trailer 和 FileInfo
如图所示:
HFile 分为六个部分:
HFile 的 Data Block,MetaBlock 通常采用压缩方式存储,压缩之后可以大大减少网络 IO 和磁盘 IO,但是这样会增加 CPU 的开销,用来进行压缩和解压。目标 HFile 支持两种压缩方式:GZIP, LZO
Data Block 和 Meta Index 块记录了每个 Data 块和 Meta 块的起始点。
Data Block 是 HBase I/O 的基本单元,为了提高效率,HRegionServer 中有基于 LRU 的 Block Cache 机制。每个 Data 块的大小可以在创建一个 Table 的时候通过参数指定,大号的 Block 有利于顺序 Scan,小号 Block 利于随机查询。每个 Data 块除了开头的 Magic 以外就是一个个 Key-Value 对拼接而成,Magic 内容就是一些随机数据,目的是防止数据损坏。
HFile 里面的每个 KeyValue 对就是一个简单的 byte[] 数组。但是这个 byte 数组里面包含了很多项,并且有固定的结构。具体结构如下:
开始是两个固定长度的数值,分别表示 Key 的长度和 Value 的长度,后面是 Key,Row Length 是固定长度的数值,表示 RowKey 的长度,Row 表示 RowKey,再后面是 Column Family Length,表示列簇的长度,然后是 Column Family,再后面是 Column Qualifier,表示列,然后是两个固定长度的数值,分别是 Time Stamp 和 KeyType(Put/Delete 添加或删除)。Value 部分没有这么复杂的结构,就是纯粹的二进制数据。
一个 HRegion 由多个 Store 组成,每个 Store 包含一个列簇的所有数据, 一个 Store 对应一个 Region 中的一个 ColumnFamily,每个 Store 包含多个 StoreFile。
Store 由位于内存的一个 MemStore 和位于磁盘的多个 StoreFile 组成。
写操作先写入 MemStore,当 MemStore 中的数据量达到某个阈值时候,HRegionServer 启动 FlushCache 进程将数据写入 StoreFile,每次写入形成一个单独的 HFile。
当总 StoreFile 大小超过一定阈值后,会把当前的 Region 分割成两个,并由 HMaster 分配给相应的 Region 服务器,实现负载均衡。
客户端检索数据时,先在 MemStore 中查找,找不到再从 StoreFile 中查找。
WAL 意为 Write Ahead Log,类似于 MySQL 中的 binlog,用来做灾难恢复,HLog 记录数据的所有变更,一旦数据修改,就可以从中进行恢复。
每个 RegionServer 维护一个 HLog,而不是每个 Region 维护一个 HLog,这样,不同的 Region(来自不同的 Table)的日志会混在一起,这样做的目的是不断追加单个文件,相对于同时写多个文件而言,可以减少磁盘寻址次数,因此可以提高对 Table 的写性能。同样,带来的麻烦是,如果一台 RegionServer 下线,为了恢复其上面的 Region,需要将 RegionServer 上的 HLog 文件进行拆分,然后分发到其它 RegionServer 上进行恢复。
HLog 文件就是一个普通的 Hadoop Sequence File:
数据的访问路径分为 3 步:
老版本的寻址方式中有个 -ROOT- 环节,新版中已经去掉,去掉 -ROOT- 的原因如下:
Note: Client 会缓存 .META. 的数据,用来加快访问。问题随之而来,那它什么时候更新?如果 .META. 更新了,比如 Region1 不在 RegionServer2 中了,被转移到其他 RegionServer 上了,Client 的缓存没有更新会有什么情况发生?
其实,Client 的元数据缓存不更新,当 .META. 的数据发生更新后,Client 再次根据缓存去访问的时候,就会出现错误,当出现异常达到重试次数上限后就会去 .META. 所在的 RegionServer 获取最新的数据,如果 .META. 所在的 RegionServer 也变了,Client 就会去 ZooKeeper 上获取 .META. 所在的 RegionServer 的最新地址。
为了能快速的判断要查询的数据在不在这个 StoreFile 中,应用了 BloomFilter
BloomFilter, 布隆过滤器:迅速判断一个元素是不是在一个庞大的集合内,但是它有一个缺点:有一定的误判率 --> 原来不存在于该集合的元素,布隆过滤器有可能会判断说它存在,但是,如果布隆过滤器判断说一个元素不存在于该集合,姥这个元素一定不存在于这个集合。
HBase 在做数据插入操作时,首先要找到 RowKey 所对应的 Region,如何查找 --> 去 ZooKeeper 中查找存储 .META. 文件的 RegionServer,然后再从 .META. 中查找存储了要找的 Region 的 RegionServer,因为 .META. 表中存储了每张表每个 Region 的起始 RowKey。
建议:在做海量数据的插入操作时,避免出现递增 RowKey 的 put 操作
如果 put 操作的所有 RowKey 都是递增的,那么,当插入一部分数据的时候刚好进行分裂,之后所有的数据都开始往分裂后的第二个 Region 插入,就造成了数据热点现象。
细节描述:
HBase 使用 MemStore 和 StoreFile 存储对表的更新。
数据在更新时首先写入 HLog(WAL Log),再写入内存(MemStore)中,MemStore 中的数据是排序的,当 MemStore 累计达到阈值(默认是 128M)时,就会创建一个新的 MemStore,并且将老的 MemStore 添加到 Flush 队列,由单独的线程 Flush 到磁盘上,成为一个新的 StoreFile。与此同时,系统会在 ZooKeeper 中记录一个 Redo point,表示这个时刻之前的变更已经持久化了。当系统出现意外时,可能导致内存(MemStore)中的数据丢失,此时使用 HLog(WAL Log) 来恢复 Checkpoint 之后的数据。
MemStore 执行 Flush 操作的触发条件:
HBase 的有三种默认的 Split 策略:
StoreFile 是只读的,一旦创建后就不可以再修改。因此 HBase 的更新/修改其实是不断追加的操作。当一个 Store 中的 StoreFile 达到一定的阈值后,就会进行一次合并(minor_compact, major_compact),将对同一个 RowKey 的修改合并到一起,形成一个大的 StoreFile。由于对表的更新是不断追加的,compact 时,需要访问 Store 中全部的 StoreFile 和 MemStore,将他们按 RowKey 进行合并,由于 StoreFile 和 MemStore 都是经过排序的,并且 StoreFile 带有内存中的索引,合并的过程还是比较快的。
Minor_Compact 和 Major_Compact 的区别:
Client 写入数据 --> 存入 MemStore,一直到 MemStore 写满 --> Flush 成一个 StoreFile,直至增长到一定阈值 --> 触发 Compact 合并操作 --> 多个 StoreFile 合并成一个 StoreFile,同时进行版本合并和数据删除 --> 当 StoreFile 经过 Compact 之后,逐步形成越来越大的 StoreFile --> 单个 StoreFile 大小超过一定阈值后,触发 Split 操作,把当前 Region Split 成 2 个 Region,原来的 Region 会下线,新 Split 出来的 2 个子 Region 会被 HMaster 分配到相应的 RegionServer 上,使得原先的一个 Region 的压力被分流到 2 个 Region 上,由此过程可知:HBase 只是增加数据,所有的更新和删除操作,都是在 Compact 阶段做。所以,用户写操作只需要进入到内存即可立即返回,从而保证 I/O 的高性能。
写入数据的过程补充:
工作机制:每个 RegionServer 中都会有一个 HLog 对象,HLog 是一个实现 WAL 的类,每次用户将数据写入到 MemStore 的同时,也会写一份数据到 HLog 文件,HLog 文件定期会滚动更新,并删除旧的文件(已持久化到 StoreFile 中的数据)。当 RegionServer 意外终止的时候,HMaster 会通过 ZooKeeper 感知,HMaster 首先处理遗留的 HLog 文件,将不同 Region 的数据拆分,分别放到对应的 Region 目录下,然后再将失效的 Region(带有刚刚拆分的 HLog)重新分配,领取到这些 Region 的 RegionServer 在 Load Region 的过程中,会发现有历史 HLog 需要处理,因此会 Replay HLog 中的数据到 MemStore 中,然后 Flush 到 StoreFile,完成数据的恢复。
任何时刻,一个 Region 只能分配给一个 RegionServer。Master 记录了当前有哪些可用的 RegionServer,以及当前哪些 Region 分配给了哪些 RegionServer,哪些 Region 还没有分配。当需要分配新的 Region,并且有一个 RegionServer 上有可用空间时,Master 就给这个 RegionServer 发送一个装载请求,把 Region 分配给这个 RegionServer。RegionServer 得到这个请求后,就开始对此 Region 提供服务。
Master 使用 ZooKeeper 来跟踪 RegionServer 状态。当某个 RegionServer 启动时,会首先在 ZooKeeper 上的 server 目录下创建一个代表自己的临时 ZNode,由于 Master 订阅了 server 目录下的变更消息(Watcher),当 server 目录下的文件出现新增或删除操作时,Master 可以得到来自 ZooKeeper 的实时通知。因此一旦 RegionServer 上线,Master 就能马上得到消息。
当 RegionServer 下线时,它和 ZooKeeper 的会话就会断开,ZooKeeper 自动删除代表这台 RegionServer 的 ZNode,Master 就可以确定这台 RegionServer 节点挂了。
无论出现哪种情况,RegionServer 都无法继续为它的 Region 提供服务了,此时, Master 就会将这台 RegionServer 上的 Region 分配给其它的 RegionServer。
Master 启动步骤如下:
由于 Master 只维护表和 Region 的元数据,而不参与表数据 I/O 的过程,Master 下线仅导致所有元数据的修改被冻结(无法创建、删除表,无法修改表的 Schema,无法进行 Region 的负载均衡,无法处理 Region 的上下线,无法进行 Region 的合并,唯一例外的是 Region 的 Split 可以正常进行,因为只有 RegionServer 参与),表的数据读写还是可以正常进行。因此,Master 下线短时间内对整个 HBase 集群并不一定会产生影响。
从 Master 的上线过程可以看到,Master 保存的信息全是可以冗余的信息(都可以从系统其它地方收集或者计算得到)。因此,一般 HBase 集群中总是有一个 Master 在提供服务,还有一个以上的 Master 在等待时机抢占它的位置。