HBase的学习笔记（1）

HBase的学习笔记（1）

1. 概述

1.1 HBase的发展史

history

• started by chad walters and jim
• 2006.11 G release paper on BigTable
• 2007.2 inital HBase prototype created as Hadoop contrib
• 2007.10 First useable Hbase
• 2008.1 Hadoop become Apache top-level project and Hbase becomes subproject
• 2008.10 Hbase 0.18,0.19 released

翻译如下：

• 由 chad walters 和 jim 创立
• 2006.11 关于BigTable 的G发布文件
• 2007.2 最初的HBase原型创建为 Hadoop contrib
• 2007.10 第一个可用的HBase
• 2008.1 Hadoop成为Apache顶级项目，HBase成为子项目
• 2008.10 HBase 0.18，0.19发布

总而言之，2006年底由PowerSet的 chad walters 和 Jim Kellerman 发起，2008年成为Apache Hadoop 的一个子项目。现以作为产品在多家企业被使用。

1.2 HBase是什么

​ HBase是一种构建在HDFS之上的分布式、面向列的存储系统。在需要实时读写、随机访问超大规模数据集时，可以使用HBase（提供实时计算）。

​ Apache HBase 官方给出了这样的定义：

Apache HBase™ is the Hadoop database, a distributed, scalable, big data store.

翻译如下： Apache HBase 是基于Hadoop构建的一个分布式的、可伸缩的海量数据存储系统。

​ HBase 常被用来存放一些结构简单，但数据量非常大的数据（通常在TB级别以上），如历史订单记录，日志数据，监控Metris数据等等，HBase提供了简单的基于Key值的快速查询能力。

​ HBase是一个高可靠、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价的PC Server上搭建大规模结构化存储集群。

​ 利用Hadoop HDFS 作为其文件存储系统，利用Hadoop MapReduce来处理HBase中的海量数据，利用ZooKeeper作为其分布式协同服务，主要来存储非结构化和半结构化的松散数据（列存NoSQL数据库）

​ HBase是一个分布式的、面向列的开源数据库，它不同于一般的关系数据库，是一个**适合于非结构化数据存储的数据库。另外一个不同的是HBase基于列的**而不是基于行的模式。HBase使用和Big Table 非常相同的数据模型。用户存储数据行在一个表里。一个数据行拥有一个可选择的键和任意数量的列，一个或多个列组成一个ColumnFamily，一个Family 下的列位于一个HFile中，易于缓存数据。表是疏松存储的，因此用户可以给行定义各种不同的列。在HBase中数据按字典排序，同时表按主键划分为多个Region。

​ 在分布式的生产环境中，HBase 需要运行在HDFS 之上，以HDFS 作为其基础的存储设施。HBase上层提供了访问的数据的Java API层，供应用访问存储在HBase的数据。在HBase的集群中主要由Master 和 Region Server 组成，以及Zookeeper。

1.3 HBase 模块

简单介绍一下HBase中相关模块的作用：

• Master

  HBase Master 用于协调多个Region Server，侦测各个Region Server 之间的状态，并平衡Region Server之间的负载。HBase Master还有一个职责就是负责分配Region给Region Server。HBase允许多个Master节点共存，但是这需要Zookeeper的帮助。不过当多个Master节点共存时，只有一个Master是提供服务的，其他的Master节点处于待命的状态。当正在工作的Master节点宕机时，其他的Master则会接管HBase的集群。

• Region Server

  对于一个Region Server而言，其包括了多个Region。RegionServer的作用只是管理表格，以及实现读写操作。Client 直接连接RegionServer，并通信获取HBase中的数据。对于Region而言，则是真实存放HBase数据的地方，也就是说Region是HBase可用性和分布式的基本单位。如果当一个表格很大，并由多个CF组成时，那么表的数据将存放在多个Region之间，并且在每个Region中会关联多个存储的单元（Store)

• Zookeeper

  对于HBase而言，Zookeeper的作用是至关重要的。首先Zookeeper是作为HBase Master的解决方案。也就是说，是Zookeeper保证了至少有一个HBase Master处于运行状态。并且Zookeeper负责Region 和 Region Server 的注册。其实Zookeeper发展到目前为止，已经成分了分布式大数据框架中容错性的标准框架。不光是Hbase ,几乎所有的分布式大数据相关的开源框架，都依赖于Zookeeper实现。

1.4 HBase特点

1. 大：一个表可以有上亿行，上百万列。

2. 面向列：面向列表（簇）的存储和权限控制，列（簇）独立检索。

3. 稀疏：对于为空（Null ) 的列，并不占用存储空间，因此，表可以设计的非常稀疏。

4. 无模式：每一个行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。

5. 数据多版本：每个单元中的数据可以有多个版本，默认情况下，版本号自动分配，版本号就是单元格插入时的时间戳。

   时间戳：一个能表示一份数据在某个特定时间之前已经存在的、完整的、可验证的数据，通常是一个字符序列，唯一地表示某一刻的时间。说白了就是，表示某一时刻的时间。

   时间戳的作用：一般，在互联网公司都会在项目中使用时间戳，时间戳主要用于清理缓存，大多数用于版本更新；

6. 数据类型单一：HBase中的数据都是字符串，没有类型。

1.5 HBase的高并发和实时处理数据

​ hadoop是一个高容错、高延时的分布式文件系统和高并发的批处理系统，不适用于提供实时计算；HBase是可以提供实时计算的分布式数据库，数据被保存在HDFS分布式文件系统上，由于HDFS保证其高容错性，但是在生产环境中，HBase是如何基于hadoop提供实时性呢？HBase上的数据是以StoreFile(HFile)二进制流的形式存储在HDFS上block块中；但是HDFS并不知道HBase存的是什么，它只把存储文件视为二进制文件，也就是说，HBase的存储数据对于HDFS文件系统是透明的。

​ HBase HRegion Servers集群中的所有的Region的数据在服务器启动时都是被打开的，并且在内冲初始化一些memstore，相应的这就在一定程度上加快系统响应；而Hadoop中的block中的数据文件默认是关闭的，只有在需要的时候才打开，处理完数据后就关闭，这在一定程度上就增加了响应时间。

​ 从根本上说，HBase能提供实时计算服务主要原因是由其架构和底层的上古巨结构决定的，即由LSM-Tree + HTable(region分区) + Cache 决定——客户端可以直接定位到要查数据所在的HRegion server服务器，然后直接在服务器的一个region上查找要匹配的数据，并且这些数据部分是经过cache缓存的。

具体数据访问流程如下：

1. Client会通过内容缓存的相关的-ROOT-中的信息和.META. 中的信息直接连接与请求数据匹配的HRegion server;
2. 然后直接定位到该服务器上与客户请求对应的Region，客户请求首先会查询该Region在内存中的缓存——Memstore(Memstore是一个按key排序的属性结构的缓冲区)；
3. 如果在Memstore中查到结果则直接将结果返回给Client；
4. 在Memstore中没有查到匹配的数据，接下来会读已持久化的StoreFile文件中的数据。StoreFile也是按key排序的属性结构的文件——并且是特别为范围查询或block查询优化过的；另外HBase读取磁盘文件是按其基本I/O单元（即HBase Block）读数据的。

具体过程就是：

​ 如果在BlockCache中能查到要造的数据则直接返回结果，否则就读取相应的StoreFile文件中一block的数据。如果还没有读到要查的数据，就将该数据block 放到HRegion Server的blockcache中，然后接着读下一block块的数据，一直到这样循环的block数据指导找到要请求的数据并返回结果；如果将该Region中的数据都没有查到要找的数据，最后直接返回null，表示没有找到匹配额数据。当然blockcache会在其大小大于一的阈值(heapsize * hfile.block.cache.size *0.85)后启动基于LRU算法的淘汰机制，将最老最不常用的block删除。

2. HBase数据模型

HBase以表的形式存储数据。表由行和列组成。列划分为若干个列族（column family ）

逻辑视图：

• RowKey：是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要；
• Column Family：列族，拥有一个名称（string），包含一个或者多个相关列；
• Column：属于某一个column family，familyName:columnName，每条记录可动态添加；
• Version Number：类型为long，默认值是系统时间戳，可由用户自定义；
• Value(Cell)：Byte array。

物理模型：

• 每个column family存储在HDFS上的一个单独文件中，空值(NULL)不会被保存。
• Key 和 Version number 在每个column family中均有一份；
• HBase为每个值维护了多级索引，即：<key，columnfamily,columnname,timestamp>;
• 表在行的方向上分割为多个Region；
• Region 是HBase中分布式存储和负载均衡的最小单元，不同Region分布到不同RegionServer上。
• Region按大小分割的，随着数据增多，Region不断增大，当增大到一个阈值的时候，Region就会分成两个新的Region；
• Region虽然是分布式存储的最小单元，但并不是存储的最小单元。**每个Region包含着多个Store对象。每个Store包含一个MemStore或若干个StoreFile，StoreFile包含一个或多个HFile。**MemStore存放在内存中，StoreFile存储在HDFS上。

详细解释：

1. Row Key:

​ 是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要。RowKey用来表示唯一一行记录的主键，HBase的数据是按照Row Key的字典顺序进行全局排序的，所有的查询都只能依赖于这一个排序维度。

​ 与NoSQL数据库一样，Row Key 、是用来检索记录的主键。访问HBase table中的行，只有三种方式：

1. 通过单个Row Key访问。
2. 通过Row Key的 range
3. 全表扫描。

Row Key 可以是任意字符串（最大长度是64KB，实际英语那个中长度一般为10~100bytes），在HBase 内部，Row Key 保存为字节数组。

在存储时，数据按照 Row Key 的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储到一起（位置相关性）。

注意：

字典序对 int 排序的结果是 1,10,100,11,12,13,14,15,16,17,18,19,20,21,…,9,91,92,93,94,95,96,97,98,99。要保证整形的自然序，Row Key 必须用0进行左填充。

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

通过一个例子来说明一下“字典排序”的原理：

RowKey {“abc”,“a”,“bdf”,“cdf”,“defg”} 按字典排序后的结果为{“a”,“abc”,“bdf”,“cdf”,“defg”}

也就是说，当两个Row key 进行排序时，先对比两个RowKey 的第一个字节，如果相同，则对比第二个字节，以此类推…如果在对比到第M个字节时，已经超出了其中一个RowKey的字节长度，那么，短的RowKey要被排在另外一个RowKey的前面

2. 稀疏矩阵

参考了BigTable，HBase中一个表的数据是按照稀疏矩阵的方式组织的，可以结合下面两张图来理解HBase数据表的抽象图（图一），以及”稀疏矩阵“（图二）。

如上图（图一），行由看似”杂乱无章“的列组成，行与行之间也无需遵循一致的定义，而这种定义恰好符合半结构化数据或非结构化数据的特点。这些”杂乱无章“的列所构成的多行数据，被称之为一个”稀疏矩阵“，而上图中的每一个”黑块“，在HBase中称之为一个keyValue。

如上图（图二），可以看到每一行中，列的组成都是灵活的，行与行之间并不需要遵循相同的列定义，也就是HBase数据表”schema-less"的特点。

3. Region

​ 区别于Cassandra/DynamoDB的“Hash分区”设计，HBase中采用了“Range分区”，将Key的完整区间切割成一个个的“Key Range"，每一个”Key Range“称之为一个Region。

​ 可以这样理解：将HBase中拥有数亿行的一个大表，横向切割成一个个”子表“，这一个个”子表”就是Region:

​ Region是HBase中负载均衡的基本单元，当一个Region增长到一定大小后，会自动分裂成两个。

4. Column Family(列族)

​ HBase 表中的每个列都归属于某个列族。列族是表的Schema（模式）的一部分（而列不是），必须在使用表之前定义。列名都以列族作为前缀，例如courses:history、courses:math都属于 courses 这个列族。

​ 访问控制、磁盘和内存的使用统计都是在列族层面进行的。在实际应用中，列族上的控制权能帮助我们管理不同类型的应用，例如，允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据（甚至可能因为隐私的原因不能浏览所有数据）。

​ 如果将Region看成是一个表的横向切割，那么，**一个Region中的数据列的纵向切割，称之为一个Column Family (列族)。**每一个列，都必须归属于一个Column Family，这个归属关系是在写数据时指定的，而不是建表时预先定义。

5. KeyValue

​ KeyValue的设计不是源自BigTable，而是要追溯至论文“The log-structured merge-tree(LSM-Tree)”。每一行中的每一列数据，都被包装成独立的拥有特定结构的KeyValue，KeyValue中包含了丰富的自我描述信息：

如上图，可以看出，KeyValue是支撑“稀疏矩阵”设计的一个关键点：一些key相同的任意数量的独立KeyValue就可以构成一行数据。但这种设计有一个显而易见的缺点：每一个KeyValue所携带的自我描述信息，会带来显著的数据膨胀。

6. 时间戳

​ HBase 中通过Row 和Columns 确定的一个存储单元称为Cell。每个Cell都保存着同一份数据的多个版本。版本通过时间戳来索引，时间戳的类型是64位整型。时间戳可以由HBase(在数据写入时自动)复制。
此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显示赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个Cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。

​ 为了避免数据存在过多版本造成的管理（包括存储和索引）负担，HBase提供了两种数据版本回收方式。一是保存数据的最后n个版本，二是保存最近一段时间内的版本（比如最近7天）。用户可以针对每个列族进行设置。

时间戳：一个能表示一份数据在某个特定时间之前已经存在的、完整的、可验证的数据，通常是一个字符序列，唯一地表示某一刻的时间。说白了就是，表示某一时刻的时间。

时间戳的作用：一般，在互联网公司都会在项目中使用时间戳，时间戳主要用于清理缓存，大多数用于版本更新；

7. Cell

​ Cell是由{row key，column(= + )，version} 唯一确定的单元。Cell中的数据是没有类型的，全部是字节码形式存储。

3. HBase 物理存储

1. Table中所有行都按照 row Key 的字典序排列；
2. Table 在行的方向上分割为多个Region(HRegion)。

​ 3. Region按大小分割的，每个表一开始只有一个Region，随着数据不断插入表中，Region不断增大，当增大到一个阈值时，Region就会等分为两个新的HRegion。当table中的行不断增多，就会有越来越多的HRegion。

4.  <u>Region是HBase中分布式存储和负载均衡的最小单元</u>。最小单元就表示不同的Region可以分布在不同的Region server上。但一个Region是不会拆分到多个server上的。

5. Region虽然是分布式存储的最小单元，但并不是存储的最小单元。

   **Region由一个或者多个Store组成，每个store 保存一个columns family。每个store又由一个memStore和 0至多个StoreFile组成。**如下图：

其中，StoreFile以HFile格式保存在HDFS上。HFile的格式为：

Trailer 部分的格式：

3.1 HFile分为六个部分：

1. Data Block 段：保存表中的数据，这部分可以被压缩
2. Meta Block段（可选的）：保存用户自定义的keyvalue对。可以被压缩。
3. FileInfo段：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时，不需要扫描整个File，而只需要从内存中找到key 所在的block，通过一次磁盘I/O将整个block读取到内存中，再找到需要的key 。DataBlock Index采用了LRU机制淘汰。

HFile的Data Block，Meta Block 通常采用压缩方式存储，压缩之后可以大大减少网络IO和磁盘IO，随之而来的开销当然是需要花费cpu进行压缩和解压缩。

目前HFile的压缩支持两种方式：Gzip，Lzo。

3.2 HLog(WAL log)

​
​ 每个Region Server维护一个Hlog，而不是每个Region 一个。这样，不同Region（来自不同table）的日志会混在一起，这样做的目的是不断追加单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能。带来的麻烦是，如果一台Region Server下线，为了恢复其 上的Region，需要将RegionServer 上的log 进行拆分，然后分发到其它Region server上进行恢复。

​ HLog文件就是一个普通的 Hadoop Sequence File，Sequence File的 Key 是HLogKey对象，HLogKey 中记录了写入数据的归属信息，除了table和Region名字外，同时还包括 sequence number 和timestamp，timestamp是“写入时间”（时间戳），sequence number （译：序列号）的起始值为0，或者是最近一次存入文件系统中Sequence number。HLog Sequence File 的 Value 是 HBase 的KeyValue 对象，即对应HFile 中的KeyValue。

​ WAL 意为 Write ahead log，类似mysql中的binlog，用来做灾难恢复使用，Hlog记录数据的所有变更，一旦数据修改，就可以从log中进行恢复。

WAL（Write ahead Log）预写日志，是数据库系统中常见的一种手段，用于保证数据操作的原子性和持久性。

在计算机科学中，预写式日志（Write-ahead logging，缩写WAL）是 关系数据库 系统中用于提供原子性和持久性的一系列技术。在使用WAL的系统中，所有的修改在提交之前都要先写入log文件中。

该机制用于数据的容错和恢复：

​ 每个HRegionServer 中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中（HLog文件格式见后续），HLog文件定期会滚动出新的，并删除旧的文件（已持久化到StoreFile中的数据）。当HRegionServer意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应region的目录下，然后再将失效的region重新分配，领取到这些region的HRegionServer在LoadRegion 的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到Memstore，然后flush到StoreFiles，完成数据恢复。

4. HBase 系统架构

HBase的架构图如下：

​ 从HBase的架构图上可以看出，Hbase中的存储包括HMaster、HRegion、HLog、Store、MemSrore、StoreFile、HFile等。

​ HBase中的每张表都通过键按照一定的范围被分割成多个子表（HRegion），默认一个HRegion 超过256M 就要被分割成两个，这个过程由 HRegionServer管理，而HRegion的分配由HMaster管理。

4.1 HMaster的作用

• 为HRegionServer分配HRegion
• 负责HRegionServer的负载均衡
• 发现失效的HRegionServer并重新分配
• HDFS上的垃圾文件回收
• 处理Schema（译：模式)更新请求

4.2 Client

​ 包含访问HBase的接口，并维护cache来加快对HBase的访问，比如region的位置信息。

4.3 Zookeeper的作用

​ HBase依赖 Zookeeper，默认情况下HBase管理Zookeeper 实例（启动或关闭Zookeeper），Master与RegionServers 启动时会向 Zookeeper注册。

Zookeeper的作用：

• 保证任何时候，集群中只有一个master
• 存储所有Region的寻址入口
• 实时监控Region server的上线和下线信息，并实时通知给master
• 存储HBase 的schema 和 table 数据

4.4 HRegionServer的作用

• 维护HMaster分配给它的HRegion ，处理对这些HRegion的IO请求
• 负责切分正在运行过程中变得过大的HRegion。

​ 从HBase架构图中可以看到，Client 访问 HBase 上的数据并不需要HMaster参与，数据寻址访问 ZooKeeper和 HRegionServer，数据读写访问HReginServer，HMaSter仅仅维护Table和Region的元数据信息，Table的元数据信息保存在ZooKeeper上，因而master负载很低。HRegionServer存取一个子表时，会创建一个HRegion对象，然后对表的每个列族创建一个Store对象，每个Store都会有一个MemStore和 0或多个StoreFile 与之对应，每个StoreFile 都会对应一个HFile，HFile 就是实际的存储文件。因此，一个HRegion有多少列族就有多少个Store。

​ 一个HRegionServer会有多个HRegion和一个HLog。

4.5 HRegion

​ Table在行的方向上分割为多个HRegion，HRegion是HBase中分布式存储和负载均衡的最小单元，即不同的HRegion 可以分别在不同的 HRegionServer 上，但同一个HRegion 是不会拆分到多个HRegionServer上的。HRegion按大小分割，每个表一般只有一个HRegion，随着数据不断插入表，HRegion不断增大，当HRegion的某个列族达到一个阈值（默认为256M）时就会分成两个新的HRegion。

1. <表名，StartRowKey，创建时间>
2. 由目录表（-ROOT- 和 .META.）记录该Region的EndRowKey。

4.6 HRegion 定位

​ HRegion被分配给哪个HRegionServer是完全动态的，所以需要机制来定位HRegion具体在哪个HRegionServer，HBase使用三层结构来定位HRegion：

1. 通过zk里的文件/Hbase/rs 得到-ROOT- 表的位置。-ROOT- 表只有一个Region。
2. 通过 -ROOT- 表查找 .META. 表的第一个表中相应的HRegion 位置。其实 -ROOT- 表是 .META. 表的第一个region；.META. 表中的每一个Region在 -ROOT- 表中都是一行记录。
3. 通过 .META. 表要找到所要的用户表HRegion的位置。用户表的每个HRegion在 .META. 表中都是一行记录。

​ -ROOT- 表永远不会被分割为多个HRegion，保证了最多需要三次跳转，就能定位到任意的Region。Client 会将查询的位置信息保存缓存起来，缓存不会主动失效，因此如果Client 上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的HRegion，其中三次用来发现缓存失效，另外三次用来获取位置信息。

-ROOT- 表： 包含。META. 表所在的Region 列表，该表只有一个Region；Zookeeper中记录了 -ROOT- 表的location（位置）

.META. 表：表包含所有的用户空间region 列表，以及Region Server的服务器地址

4.7 Store

​ 每一个HRegion 由一个或多个Store 组成，至少是一个Store，Hbase会把一起访问的数据放在一个Store里面，即为每个ColumnFamily 建一个Store，如果有几个ColumnFamily，也就有几个Store。一个Store由一个 MemStore 和 0或者多个StoreFile组成。Hbase以Store的大小来判断是否需要切分HRegion。

4.8 MemStore

​ MemStore 是放在内存里的，保存修改的数据即keyValues。当MemStore的大小达到一个阈值（默认为64MB）时，MemStore会被Flush到文件，即生成一个快照。目前Hbase会有一个线程来负责MemStore 的Flush操作。

4.9 StoreFile

​ MemStore内存中的数据写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。

4.10 HFile

​ Hbase中KeyValue数据的存储格式，是Hadoop的二进制格式文件。首先HFile文件是不定长的，长度固定的只有其中的两块：Trailer 和 FileInfo。

​ Trailer 中有指针指向其他数据块的起始点，FileInf记录了文件的一些meta信息。Data Block是Hbase IO 的基本单元，为了提高效率，HRegion Server中有基于LRU的Block Cache机制。每个Data块的啊大小可以在创建一个Table的时候通过参数指定（默认块大小64KB)，大号的Block有利于顺序Scan(扫描)，小号的Block利于随机查询。每个Data块除了开头的magic以外就是一个个KeyValue对拼接而成，Magic内容就是一些随机数字，目的是防止数据损坏，结构如下。

HFile结构图如下：

​ Data Block段用来保存表中的数据，这部分可以被压缩。Meta Block段（可选的）用来保存用户自定义的kv段，可以被压缩。FileInfo 段是用来保存HFile的元信息，不能被压缩，用户也可以在这一部分添加自己的元信息。Data Block Index 段（可选的）用来保存Meta Block 的索引。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 进行压缩和解压缩。（备注： DataBlock Index 的缺陷。 a.占用过多内存 b.启动加载时间缓慢）

4.11 HLog

​ HLog(WAL log)：WAL意为 write ahead log，用来做灾难恢复使用，HLog记录数据的所有变更，一旦region server 宕机，就可以从log中恢复。

4.12 LogFlusher

​ 数据以keyValue形式到达HRegion Server，将写入WAL之后，写入一个SequenceFile。看过去没问题，但是因为数据流在写入文件系统时，经常会缓存以提高性能。这样，有些本以为在日志文件中的数据实际在内存中。

​ 在此，我们提供了一个LogFlusher的类。它调用 HLog.optionalSync()，后者根据hbase.regionserver.optionallogflushinterval（默认是10秒），定期调用Hlog.sync()。另外，HLog.doWrite()也会根据hbase.regionserver.flushlogentries(默认100秒)定期调用Hlog.sync()。Sync()本身调用HLog.Writer.Sync()，它有SequenceFileLogWriter实现。

4.13 Log Roller

​ Log的大小通过 $HBASE_HOME/conf/hbase-site.xml 的hbase.regionserver.logroll.period 限制，默认是一个小时。所以每60分钟，会打开一个新的log文件。久而久之，会有一大堆的文件需要维护。首先，LogRoller调用HLog.rollWrite()，定时滚动日志，之后，利用HLog.cleanOldLogs()可以清楚旧的日志。它首先取得存储文件中的最大的 sequence number，之后检查是否存在一个log 所有的条目的“sequence number"均低于这个值，如果存在，将删除这个log。每个region server 维护一个HLog，而不是每一个region一个，这样不同region（来自不同的table）的日志会混在一起，这样做的目的是不断追加 单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高table的写性能。带来麻烦的是，如果一个 region server 下线，们为了恢复其上的region ，需要将region server上的log进行拆分，然后分发到其他regionservers上进行恢复。

4.14 HBase 容错性

Master容错：Zookeeper重新选择一个新的Master

• 无Master过程中，数据读取仍照常进行；
• 无Master过程中，region切分、负载均衡等无法进行；

Region Server容错：定时向Zookeeper汇报心跳，如果一旦时间内未出现心跳，Master将该RegionServer上的Region重新分配到其他RegionServer上，失效服务器上”预写“日志由主服务器进行分割并派送给新的RegionServer。

Zookeeper容错：Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例

补充一些概念

HDFS

HDFS 是Google公司GFS论文思想的实现，它由NameNode(名称节点)、DataNode(数据节点)、SecondaryNameNode(第二名称节点) 组成。其中，NameNode 相当于论文中的GFS Master，DataNode 相当于论文中的GFS Chunk Server。

GFS 是一个可扩展的分布式文件系统设计思想，用于设计针对大型的、分布式的、对大量数据进行访问的文件系统。

​ HDFS是基于 流数据 访问模式的 分布式文件系统，其设计建立在“一次写入、多次读取”的基础上，提高吞吐量、高容错性的数据访问，能很好的解决海量数据的存储问题。

流数据 是指数千个数据源持续生成的数据，可以理解为随时间延续而无限增长的动态数据集合。

通俗点说，如果把数据比如成一个水库，那么流进去的水，就是流数据（比如我们听到的音乐，属于音乐流；而看到的文字、图片这些较为固定的，一次性下载的，形成不了流）。

在Hadoop 生态圈中，HDFS属于底层基础，负责存储文件。