乐趣区

关于大数据:HBase-底层原理详解深度好文建议收藏

作者：

jiezi

在

HBase简介

HBase 是一个分布式的、面向列的开源数据库。建设在 HDFS 之上。Hbase的名字的起源是 Hadoop database，即 Hadoop 数据库。HBase 的计算和存储能力取决于 Hadoop 集群。

它介于 NoSql 和 RDBMS 之间，仅能通过主键(row key)和主键的 range 来检索数据，仅反对单行事务(可通过 Hive 反对来实现多表 join 等简单操作)。

HBase中表的特点：

  1. 大：一个表能够有上十亿行，上百万列
  2. 面向列：面向列(族)的存储和权限管制，列(族)独立检索。
  3. 稠密：对于为空(null)的列，并不占用存储空间，因而，表能够设计的十分稠密。

HBase底层原理

零碎架构

依据这幅图，解释下HBase中各个组件

Client

  1. 蕴含拜访hbase的接口，Client保护着一些cache来放慢对hbase的拜访，比方regione的地位信息.

Zookeeper

HBase能够应用内置的Zookeeper，也能够应用外置的，在理论生产环境，为了放弃统一性，个别应用外置Zookeeper。

Zookeeper在HBase中的作用：

  1. 保障任何时候，集群中只有一个master
  2. 存贮所有Region的寻址入口
  3. 实时监控Region Server的状态，将Region server的上线和下线信息实时告诉给Master

HMaster

  1. 为Region server调配region
  2. 负责region server的负载平衡
  3. 发现生效的region server并重新分配其上的region
  4. HDFS上的垃圾文件回收
  5. 解决schema更新申请

HRegion Server

  1. HRegion server保护HMaster调配给它的region，解决对这些region的IO申请
  2. HRegion server负责切分在运行过程中变得过大的region

从图中能够看到，Client拜访HBase上数据的过程并不需要HMaster参加（寻址拜访Zookeeper和HRegion server，数据读写访问HRegione server）

HMaster仅仅维护者table和HRegion的元数据信息，负载很低。

HBase的表数据模型

行键 Row Key

与nosql数据库一样,row key是用来检索记录的主键。拜访hbase table中的行，只有三种形式：

  1. 通过单个row key拜访
  2. 通过row key的range
  3. 全表扫描

Row Key 行键能够是任意字符串(最大长度是 64KB，理论利用中长度个别为 10-100bytes)，在hbase外部，row key保留为字节数组。

Hbase会对表中的数据依照rowkey排序(字典程序)

存储时，数据依照Row key的字典序(byte order)排序存储。设计key时，要充沛排序存储这个个性，将常常一起读取的行存储放到一起。(地位相关性)。

留神：
字典序对int排序的后果是
1,10,100,11,12,13,14,15,16,17,18,19,2,20,21 … 。要放弃整形的天然序，行键必须用0作左填充。

行的一次读写是原子操作 (不管一次读写多少列)。这个设计决策可能使用户很容易的了解程序在对同一个行进行并发更新操作时的行为。

列族 Column Family

HBase表中的每个列，都归属于某个列族。列族是表的schema的一部分(而列不是)，必须在应用表之前定义。

列名都以列族作为前缀。例如 courses:history ， courses:math 都属于 courses 这个列族。

**访问控制、磁盘和内存的应用统计都是在列族层面进行的。
列族越多，在取一行数据时所要参加IO、搜查的文件就越多，所以，如果没有必要，不要设置太多的列族。**

列 Column

列族上面的具体列，属于某一个ColumnFamily，相似于在mysql当中创立的具体的列。

工夫戳 Timestamp

HBase中通过row和columns确定的为一个存贮单元称为cell。每个 cell都保留着同一份数据的多个版本。版本通过工夫戳来索引。工夫戳的类型是 64位整型。工夫戳能够由hbase(在数据写入时主动 )赋值，此时工夫戳是准确到毫秒的以后零碎工夫。工夫戳也能够由客户显式赋值。如果应用程序要防止数据版本抵触，就必须本人生成具备唯一性的工夫戳。每个 cell中，不同版本的数据依照工夫倒序排序，即最新的数据排在最后面。

为了防止数据存在过多版本造成的的治理 (包含存贮和索引)累赘，hbase提供了两种数据版本回收形式：

  1. 保留数据的最初n个版本
  2. 保留最近一段时间内的版本（设置数据的生命周期TTL）。

用户能够针对每个列族进行设置。

单元 Cell

由{row key, column( =<family> + <label>), version} 惟一确定的单元。
cell中的数据是没有类型的，全副是字节码模式存贮。

版本号 VersionNum

数据的版本号，每条数据能够有多个版本号，默认值为零碎工夫戳，类型为Long。

物理存储

1. 整体构造

  1. Table 中的所有行都依照 Row Key 的字典序排列。
  2. Table 在行的方向上宰割为多个 HRegion。
  3. HRegion按大小宰割的(默认10G)，每个表一开始只有一 个HRegion，随着数据一直插入表，HRegion一直增大，当增大到一个阀值的时候，HRegion就会等分会两个新的HRegion。当Table 中的行一直增多，就会有越来越多的 HRegion。
  4. HRegion 是 HBase 中分布式存储和负载平衡的最小单元。最小单元就示意不同的 HRegion 能够散布在不同的 HRegion Server 上。但一个 HRegion 是不会拆分到多个 Server 上的。
  5. HRegion 尽管是负载平衡的最小单元，但并不是物理存储的最小单元。

事实上，HRegion 由一个或者多个 Store 组成，每个 Store 保留一个 Column Family。
每个 Strore 又由一个 MemStore 和0至多个 StoreFile 组成。如上图。

2. StoreFile 和 HFile 构造

StoreFile以HFile格局保留在HDFS上。

HFile的格局为：

首先HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。正如图中所示的，Trailer中有指针指向其余数 据块的起始点。

File Info中记录了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等。

Data Index和Meta Index块记录了每个Data块和Meta块的起始点。

Data Block是HBase I/O的根本单元，为了提高效率，HRegionServer中有基于LRU的Block Cache机制。每个Data块的大小能够在创立一个Table的时候通过参数指定，大号的Block有利于程序Scan，小号Block利于随机查问。 每个Data块除了结尾的Magic以外就是一个个KeyValue对拼接而成, Magic内容就是一些随机数字，目标是避免数据损坏。

HFile外面的每个KeyValue对就是一个简略的byte数组。然而这个byte数组外面蕴含了很多项，并且有固定的构造。咱们来看看外面的具体构造：

开始是两个固定长度的数值，别离示意Key的长度和Value的长度。紧接着是Key，开始是固定长度的数值，示意RowKey的长度，紧接着是 RowKey，而后是固定长度的数值，示意Family的长度，而后是Family，接着是Qualifier，而后是两个固定长度的数值，示意Time Stamp和Key Type（Put/Delete）。Value局部没有这么简单的构造，就是纯正的二进制数据了。

HFile分为六个局部：

  1. Data Block 段–保留表中的数据，这部分能够被压缩.
  2. Meta Block 段 (可选的)–保留用户自定义的kv对，能够被压缩。
  3. File Info 段–Hfile的元信息，不被压缩，用户也能够在这一部分增加本人的元信息。
  4. Data Block Index 段–Data Block的索引。每条索引的key是被索引的block的第一条记录的key。
  5. Meta Block Index段 (可选的)–Meta Block的索引。
  6. Trailer–这一段是定长的。保留了每一段的偏移量，读取一个HFile时，会首先读取Trailer，Trailer保留了每个段的起始地位(段的Magic Number用来做平安check)，而后，DataBlock Index会被读取到内存中，这样，当检索某个key时，不须要扫描整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个 block读取到内存中，再找到须要的key。DataBlock Index采纳LRU机制淘汰。

HFile的Data Block，Meta Block通常采纳压缩形式存储，压缩之后能够大大减少网络IO和磁盘IO，随之而来的开销当然是须要破费cpu进行压缩和解压缩。
目前HFile的压缩反对两种形式：Gzip，Lzo。

3. Memstore与StoreFile

**一个 HRegion 由多个 Store 组成，每个 Store 蕴含一个列族的所有数据
Store 包含位于内存的 Memstore 和位于硬盘的 StoreFile。**

写操作先写入 Memstore，当 Memstore 中的数据量达到某个阈值，HRegionServer 启动 FlashCache 过程写入 StoreFile，每次写入造成独自一个 StoreFile

当 StoreFile 大小超过肯定阈值后，会把以后的 HRegion 宰割成两个，并由 HMaster 调配给相应的 HRegion 服务器，实现负载平衡

客户端检索数据时，先在memstore找，找不到再找storefile。

4. HLog(WAL log)

WAL 意为Write ahead log，相似 mysql 中的 binlog,用来 做劫难复原时用，Hlog记录数据的所有变更,一旦数据批改，就能够从log中进行复原。

每个Region Server保护一个Hlog,而不是每个Region一个。这样不同region(来自不同table)的日志会混在一起，这样做的目标是一直追加单个文件绝对于同时写多个文件而言，能够缩小磁盘寻址次数，因而能够进步对table的写性能。带来的麻烦是，如果一台region server下线，为了复原其上的region，须要将region server上的log进行拆分，而后散发到其它region server上进行复原。

HLog文件就是一个一般的Hadoop Sequence File：

  1. HLog Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包含 sequence number和timestamp，timestamp是”写入工夫”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。
  2. HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue，可参见上文形容。

读写过程

1. 读申请过程：

HRegionServer保留着meta表以及表数据，要拜访表数据，首先Client先去拜访zookeeper，从zookeeper外面获取meta表所在的地位信息，即找到这个meta表在哪个HRegionServer上保留着。

接着Client通过方才获取到的HRegionServer的IP来拜访Meta表所在的HRegionServer，从而读取到Meta，进而获取到Meta表中寄存的元数据。

Client通过元数据中存储的信息，拜访对应的HRegionServer，而后扫描所在HRegionServer的Memstore和Storefile来查问数据。

最初HRegionServer把查问到的数据响应给Client。

查看meta表信息

hbase(main):011:0> scan 'hbase:meta'

2. 写申请过程：

Client也是先拜访zookeeper，找到Meta表，并获取Meta表元数据。

确定以后将要写入的数据所对应的HRegion和HRegionServer服务器。

Client向该HRegionServer服务器发动写入数据申请，而后HRegionServer收到申请并响应。

Client先把数据写入到HLog，以避免数据失落。

而后将数据写入到Memstore。

如果HLog和Memstore均写入胜利，则这条数据写入胜利

如果Memstore达到阈值，会把Memstore中的数据flush到Storefile中。

当Storefile越来越多，会触发Compact合并操作，把过多的Storefile合并成一个大的Storefile。

当Storefile越来越大，Region也会越来越大，达到阈值后，会触发Split操作，将Region一分为二。

细节形容：

HBase应用MemStore和StoreFile存储对表的更新。
数据在更新时首先写入Log(WAL log)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到肯定阈值时，就会创立一个新的MemStore，并且将老的MemStore增加到flush队列，由独自的线程flush到磁盘上，成为一个StoreFile。于此同时，零碎会在zookeeper中记录一个redo point，示意这个时刻之前的变更曾经长久化了。
当零碎出现意外时，可能导致内存(MemStore)中的数据失落，此时应用Log(WAL log)来复原checkpoint之后的数据。

StoreFile是只读的，一旦创立后就不能够再批改。因而HBase的更新其实是一直追加的操作。当一个Store中的StoreFile达到肯定的阈值后，就会进行一次合并(minor_compact, major_compact),将对同一个key的批改合并到一起，造成一个大的StoreFile，当StoreFile的大小达到肯定阈值后，又会对 StoreFile进行split，等分为两个StoreFile。

因为对表的更新是一直追加的，compact时，须要拜访Store中全副的 StoreFile和MemStore，将他们按row key进行合并，因为StoreFile和MemStore都是通过排序的，并且StoreFile带有内存中索引，合并的过程还是比拟快。

HRegion治理

HRegion调配

任何时刻，一个HRegion只能调配给一个HRegion Server。HMaster记录了以后有哪些可用的HRegion Server。以及以后哪些HRegion调配给了哪些HRegion Server，哪些HRegion还没有调配。当须要调配的新的HRegion，并且有一个HRegion Server上有可用空间时，HMaster就给这个HRegion Server发送一个装载申请，把HRegion调配给这个HRegion Server。HRegion Server失去申请后，就开始对此HRegion提供服务。

HRegion Server上线

HMaster应用zookeeper来跟踪HRegion Server状态。当某个HRegion Server启动时，会首先在zookeeper上的server目录下建设代表本人的znode。因为HMaster订阅了server目录上的变更音讯，当server目录下的文件呈现新增或删除操作时，HMaster能够失去来自zookeeper的实时告诉。因而一旦HRegion Server上线，HMaster能马上失去音讯。

HRegion Server下线

当HRegion Server下线时，它和zookeeper的会话断开，zookeeper而主动开释代表这台server的文件上的独占锁。HMaster就能够确定：

  1. HRegion Server和zookeeper之间的网络断开了。
  2. HRegion Server挂了。

无论哪种状况，HRegion Server都无奈持续为它的HRegion提供服务了，此时HMaster会删除server目录下代表这台HRegion Server的znode数据，并将这台HRegion Server的HRegion调配给其它还活着的节点。

HMaster工作机制

master上线

master启动进行以下步骤:

  1. 从zookeeper上获取惟一一个代表active master的锁，用来阻止其它HMaster成为master。
  2. 扫描zookeeper上的server父节点，取得以后可用的HRegion Server列表。
  3. 和每个HRegion Server通信，取得以后已调配的HRegion和HRegion Server的对应关系。
  4. 扫描.META.region的汇合，计算失去以后还未调配的HRegion，将他们放入待调配HRegion列表。

master下线

因为HMaster只保护表和region的元数据，而不参加表数据IO的过程，HMaster下线仅导致所有元数据的批改被解冻(无奈创立删除表，无奈批改表的schema，无奈进行HRegion的负载平衡，无奈解决HRegion 高低线，无奈进行HRegion的合并，惟一例外的是HRegion的split能够失常进行，因为只有HRegion Server参加)，表的数据读写还能够失常进行。因而HMaster下线短时间内对整个HBase集群没有影响。

从上线过程能够看到，HMaster保留的信息全是能够冗余信息（都能够从零碎其它中央收集到或者计算出来）

因而，个别HBase集群中总是有一个HMaster在提供服务，还有一个以上的‘HMaster’在期待机会抢占它的地位。

HBase三个重要机制

1. flush机制

1.（hbase.regionserver.global.memstore.size）默认;堆大小的40%
regionServer的全局memstore的大小，超过该大小会触发flush到磁盘的操作,默认是堆大小的40%,而且regionserver级别的flush会阻塞客户端读写

2.（hbase.hregion.memstore.flush.size）默认：128M
单个region里memstore的缓存大小，超过那么整个HRegion就会flush,

3.（hbase.regionserver.optionalcacheflushinterval）默认：1h
内存中的文件在主动刷新之前可能存活的最长工夫

4.（hbase.regionserver.global.memstore.size.lower.limit）默认：堆大小 0.4 0.95
有时候集群的“写负载”十分高，写入量始终超过flush的量，这时，咱们就心愿memstore不要超过肯定的平安设置。在这种状况下，写操作就要被阻塞始终到memstore复原到一个“可治理”的大小, 这个大小就是默认值是堆大小 0.4 0.95，也就是当regionserver级别的flush操作发送后,会阻塞客户端写,始终阻塞到整个regionserver级别的memstore的大小为 堆大小 0.4 0.95为止

5.（hbase.hregion.preclose.flush.size）默认为：5M
当一个 region 中的 memstore 的大小大于这个值的时候，咱们又触发了region的 close时，会先运行“pre-flush”操作，清理这个须要敞开的memstore，而后 将这个 region 下线。当一个 region 下线了，咱们无奈再进行任何写操作。 如果一个 memstore 很大的时候，flush 操作会耗费很多工夫。”pre-flush” 操作意味着在 region 下线之前，会先把 memstore 清空。这样在最终执行 close 操作的时候，flush 操作会很快。

6.（hbase.hstore.compactionThreshold）默认：超过3个
一个store外面容许存的hfile的个数，超过这个个数会被写到新的一个hfile外面 也即是每个region的每个列族对应的memstore在flush为hfile的时候，默认状况下当超过3个hfile的时候就会对这些文件进行合并重写为一个新文件，设置个数越大能够缩小触发合并的工夫，然而每次合并的工夫就会越长

2. compact机制

把小的storeFile文件合并成大的HFile文件。
清理过期的数据，包含删除的数据
将数据的版本号保留为1个。

split机制

当HRegion达到阈值，会把过大的HRegion一分为二。
默认一个HFile达到10Gb的时候就会进行切分。

搜寻公众号“五分钟学大数据”，深刻钻研大数据技术

更多文章