HBase入门简介
2015-08-03 17:54:24 
阿炯
一、 简介HBase 是一个面向列式存储的分布式数据库，其设计思想来源于 Google 的 BigTable 论文。HBase 底层存储基于 HDFS 实现，集群的管理基于 ZooKeeper 实现。HBase 良好的分布式架构设计为海量数据的快速存储、随机访问提供了可能，基于数据副本机制和分区机制可以轻松实现在线扩容、缩容和数据容灾，是大数据领域中 Key-Value 数据结构存储最常用的数据库方案。
基本概念
表(Table)，数据的组织形式
行(Row)，Table中的每一行
列族(Column Family)，一行中有多个列，以Column Family进行分组，同一Column Family的列存储在同一个底层文件(HFile)中，所以Column Family会影响数据的物理存储，一般在表创建的时候，就需要指定好，并且不要轻易修改。
列(Column Qualifier)，这个不需要创建表的时候就指定。
单元格(Cell)，一组Row、Family、Qualifier可以定位一个Cell。
时间戳(Timestamp)，一个单元格中的数据是由版本的，版本以Timestamp来区分。默认写入的是当前的timestamp，读取的是最新的timestamp的数据，HBase默认一个单元格保存三个版本。
所以，一个HBase的Table存取模式为：
(Table, RowKey, Family, Qualifier, Timestamp) -> Value
Hbase是bigtable的开源版本。是建立的hdfs之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。它介于nosql和RDBMS之间，仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务(可通过hive支持来实现多表join等复杂操作)。主要用来存储非结构化和半结构化的松散数据。与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。HBase中的表一般有这样的特点：
1、大：一个表可以有上亿行，上百万列；
2、面向列:面向列(族)的存储和权限控制，列(族)独立检索；
3、稀疏:对于为空(null)的列，并不占用存储空间，因此表可以设计的非常稀疏。
下面一幅图是Hbase在Hadoop Ecosystem中的位置。
二、 逻辑视图
HBase以表的形式存储数据。表有行和列组成。列划分为若干个列族(row family)
Row Key
与nosql数据库们一样，row key是用来检索记录的主键。访问hbase table中的行，只有三种方式：
1、通过单个row key访问
2、通过row key的range
3、全表扫描
Row key行键 (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,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行键必须用0作左填充。行的一次读写是原子操作 (不论一次读写多少列)。这个设计决策能够使用户很容易的理解程序在对同一个行进行并发更新操作时的行为。
列族
hbase表中的每个列，都归属与某个列族。列族是表的chema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如courses:history ， courses:math 都属于 courses 这个列族。
访问控制、磁盘和内存的使用统计都是在列族层面进行的。实际应用中，列族上的控制权限能帮助我们管理不同类型的应用：我们允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据(甚至可能因 为隐私的原因不能浏览所有数据)。
时间戳
HBase中通过row和columns确定的为一个存贮单元称为cell。每个 cell都保存着同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是 64位整型。时间戳可以由hbase(在数据写入时自动)赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个 cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。
为了避免数据存在过多版本造成的的管理(包括存贮和索引)负担，hbase提供了两种数据版本回收方式。一是保存数据的最后n个版本，二是保存最近一段时间内的版本(比如最近七天)。用户可以针对每个列族进行设置。
Cell
由{row key, column( =<family> + <label>), version} 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。
三、 物理存储
1、已经提到过，Table中的所有行都按照row key的字典序排列。
2、Table 在行的方向上分割为多个Hregion。
3、region按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。当table中的行不断增多，就会有越来越多的Hregion。
4、Hregion是Hbase中分布式存储和负载均衡的最小单元，最小单元就表示不同的Hregion可以分布在不同的HRegion server上，但一个Hregion是不会拆分到多个server上的。
5、HRegion虽然是分布式存储的最小单元，但并不是存储的最小单元。
事实上，HRegion由一个或者多个Store组成，每个store保存一个columns family。每个Strore又由一个memStore和0至多个StoreFile组成。
StoreFile以HFile格式保存在HDFS上。
HFile的格式为：
Trailer部分的格式:
HFile分为六个部分：
Data Block 段–保存表中的数据，这部分可以被压缩
Meta Block 段 (可选的)–保存用户自定义的kv对，可以被压缩。
File Info 段–Hfile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。
Data Block Index 段–Data Block的索引。每条索引的key是被索引的block的第一条记录的key。
Meta 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进行压缩和解压缩。
目标Hfile的压缩支持两种方式：Gzip，Lzo。
HLog(WAL log)
WAL 意为Write ahead log(http://en.wikipedia.org/wiki/Write-ahead_logging)，类似mysql中的binlog，用来 做灾难恢复只用，Hlog记录数据的所有变更，一旦数据修改，就可以从log中进行恢复。
每个Region Server维护一个Hlog，而不是每个Region一个。这样不同region(来自不同table)的日志会混在一起，这样做的目的是不断追加单个 文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能。带来的麻烦是，如果一台region server下线，为了恢复其上的region，需要将region server上的log进行拆分，然后分发到其它region server上进行恢复。
HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是”写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue，可参见上文描述。
四、 系统架构
Client
1、包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。
Zookeeper
1、保证任何时候，集群中只有一个master
2、存贮所有Region的寻址入口。
3、实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master
4、存储Hbase的schema,包括有哪些table，每个table有哪些column family
Master
1、为Region server分配region
2、负责region server的负载均衡
3、发现失效的region server并重新分配其上的region
4、GFS上的垃圾文件回收
5、处理schema更新请求
Region Server
1、Region server维护Master分配给它的region，处理对这些region的IO请求
2、Region server负责切分在运行过程中变得过大的region
可以看到，client访问hbase上数据的过程并不需要master参与(寻址访问zookeeper和region server，数据读写访问regione server)，master仅仅维护者table和region的元数据信息，负载很低。
五、关键算法/流程
region定位
系统如何找到某个row key (或者某个 row key range)所在的region，与 bigtable类似，使用三层类似B+树的结构来保存region位置。
第一层是保存zookeeper里面的文件，它持有root region的位置。
第二层root region是.META.表的第一个region其中保存了.META.z表其它region的位置。通过root region，我们就可以访问.META.表的数据。
.META.是第三层，它是一个特殊的表，保存了hbase中所有数据表的region位置信息。
说明：
1、root region永远不会被split，保证了最需要三次跳转，就能定位到任意region 。
2、.META.表每行保存一个region的位置信息，row key 采用表名+表的最后一样编码而成。
3、为了加快访问，.META.表的全部region都保存在内存中。
假设.META.表的一行在内存中大约占用1KB，并且每个region限制为128MB，那么上面的三层结构可以保存的region数目为：
(128MB/1KB) * (128MB/1KB) = = 2(34)个region
4、client会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的region(其中三次用来发现缓存失效，另外三次用来获取位置信息)。
读写过程
上文提到，hbase使用MemStore和StoreFile存储对表的更新。
数据在更新时首先写入Log(WAL log)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。于此同时，系统会在zookeeper中 记录一个redo point，表示这个时刻之前的变更已经持久化了(minor compact)。
当系统出现意外时，可能导致内存(MemStore)中的数据丢失，此时使用Log(WAL log)来恢复checkpoint之后的数据。
前面提到过StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并(major compact),将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对 StoreFile进行split，等分为两个StoreFile。
由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部的 StoreFile和MemStore，将他们的按照row key进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，合并的过程还是比较快。
写请求处理过程
1、client向region server提交写请求
2、region server找到目标region
3、region检查数据是否与schema一致
4、如果客户端没有指定版本，则获取当前系统时间作为数据版本
5、将更新写入WAL log
6、将更新写入Memstore
7、判断Memstore的是否需要flush为Store文件。
region分配
任何时刻，一个region只能分配给一个region server。master记录了当前有哪些可用的region server。以及当前哪些region分配给了哪些region server，哪些region还没有分配。当存在未分配的region，并且有一个region server上有可用空间时，master就给这个region server发送一个装载请求，把region分配给这个region server。region server得到请求后，就开始对此region提供服务。
region server上线
master使用zookeeper来跟踪region server状态。当某个region server启动时，会首先在zookeeper上的server目录下建立代表自己的文件，并获得该文件的独占锁。由于master订阅了server 目录上的变更消息，当server目录下的文件出现新增或删除操作时，master可以得到来自zookeeper的实时通知。因此一旦region server上线，master能马上得到消息。
region server下线
当region server下线时，它和zookeeper的会话断开，zookeeper而自动释放代表这台server的文件上的独占锁。而master不断轮询 server目录下文件的锁状态。如果master发现某个region server丢失了它自己的独占锁，(或者master连续几次和region server通信都无法成功)，master就是尝试去获取代表这个region server的读写锁，一旦获取成功，就可以确定。
1、region server和zookeeper之间的网络断开了；
2、region server挂了。
其中一种情况发生了，无论哪种情况，region server都无法继续为它的region提供服务了，此时master会删除server目录下代表这台region server的文件，并将这台region server的region分配给其它还活着的伙伴。如果网络短暂出现问题导致region server丢失了它的锁，那么region server重新连接到zookeeper之后，只要代表它的文件还在，它就会不断尝试获取这个文件上的锁，一旦获取到了，就可以继续提供服务。
master上线
master启动进行以下步骤：
1、从zookeeper上获取唯一一个代码master的锁，用来阻止其它master成为master。
2、扫描zookeeper上的server目录，获得当前可用的region server列表。
3、和2中的每个region server通信，获得当前已分配的region和region server的对应关系。
4、扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表。
master下线
由于master只维护表和region的元数据，而不参与表数据IO的过程，master下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region上下线，无法进行region的合并，唯一例外的是region的split可以正常进行，因为只有region server参与)，表的数据读写还可以正常进行。因此master下线短时间内对整个hbase集群没有影响。从上线过程可以看到，master保存的信息全是可以冗余信息(都可以从系统其它地方收集到或者计算出来)，因此，一般hbase集群中总是有一个master在提供服务，还有一个以上的’master’在等待时机抢占它的位置。
六、访问接口
HBase Shell
Java clietn API
HBase non-java access
languages talking to the JVM
Jython interface to HBase
Groovy DSL for HBase
Scala interface to HBase
languages with a custom protocol
REST gateway specification for HBase
充分利用HTTP协议：GET POST PUT DELETE
text/plain
text/xml
application/json
application/x-protobuf
Thrift gateway specification for HBase
java
cpp
rb
py
perl
php
HBase Map Reduce
Hive/Pig
接上文，再从不同的视角整体综合介绍一遍HBase
HBase特点再述
易扩展
Hbase 的扩展性主要体现在两个方面，一个是基于运算能力(RegionServer) 的扩展，通过增加 RegionSever 节点的数量，提升 Hbase 上层的处理能力；另一个是基于存储能力的扩展(HDFS)，通过增加 DataNode 节点数量对存储层的进行扩容，提升 HBase 的数据存储能力。
海量存储
HBase 作为一个开源的分布式 Key-Value 数据库，其主要作用是面向 PB 级别数据的实时入库和快速随机访问。这主要源于上述易扩展的特点，使得 HBase 通过扩展来存储海量的数据。
列式存储
Hbase 是根据列族来存储数据的。列族下面可以有非常多的列。列式存储的最大好处就是，其数据在表中是按照某列存储的，这样在查询只需要少数几个字段时，能大大减少读取的数据量。
高可靠性
WAL 机制保证了数据写入时不会因集群异常而导致写入数据丢失，Replication 机制保证了在集群出现严重的问题时，数据不会发生丢失或损坏。而且 Hbase 底层使用 HDFS，HDFS 本身也有备份。
稀疏性
在 HBase 的列族中，可以指定任意多的列，为空的列不占用存储空间，表可以设计得非常稀疏。
模块组成
HBase 可以将数据存储在本地文件系统，也可以存储在 HDFS 文件系统。在生产环境中，HBase 一般运行在 HDFS 上，以 HDFS 作为基础的存储设施。HBase 通过 HBase Client 提供的 Java API 来访问 HBase 数据库，以完成数据的写入和读取。HBase 集群主由HMaster、Region Server 和 ZooKeeper 组成。
HMaster
1.负责管理 RegionServer，实现其负载均衡；
2.管理和分配 Region，比如在 Region split时分配新的 Region，在 RegionServer 退出时迁移其内的 Region 到其他 RegionServer上；
3.管理namespace和table的元数据(实际存储在HDFS上)；
4.权限控制(ACL)。
5.RegionServer
存放和管理本地 Region；
读写HDFS，管理Table中的数据；
Client 从 HMaster 中获取元数据，找到 RowKey 所在的 RegionServer 进行读写数据。
6.ZooKeeper
存放整个HBase集群的元数据以及集群的状态信息；
实现HMaster主从节点的failover。
HBase 数据模型
HBase 是一个面向列式存储的分布式数据库，其数据模型与 BigTable 十分相似。在 HBase 表中，一条数据拥有一个全局唯一的键(RowKey)和任意数量的列(Column)，一列或多列组成一个列族(Column Family)，同一个列族中列的数据在物理上都存储在同一个 HFile 中，这样基于列存储的数据结构有利于数据缓存和查询。HBase 中的表是疏松地存储的，因此用户可以动态地为数据定义各种不同的列。HBase中的数据按主键排序，同时，HBase 会将表按主键划分为多个 Region 存储在不同 Region Server 上，以完成数据的分布式存储和读取。
HBase 根据列成来存储数据，一个列族对应物理存储上的一个 HFile，列族包含多列列族在创建表的时候被指定。
Column Family
Column Family 即列族，HBase 基于列划分数据的物理存储，一个列族可以包含包意多列。一般同一类的列会放在一个列族中，每个列族都有一组存储属性：
1.是否应该缓存在内存中；
2.数据如何被压缩或行键如何编码等。
HBase 在创建表的时候就必须指定列族。HBase的列族不是越多越好，官方荐一个表的列族数量最好小于或者等于3，过多的列族不利于 HBase 数据的管理和索引。
RowKey
RowKey的概念与关系型数据库中的主键相似，HBase 使用 RowKey 来唯一标识某行的数据。访问 HBase 数据的方式有三种:
1.基于 RowKey的单行查询；
2.基于RowKey的范围查询；
3.全表扫描查询。
Region
HBase 将表中的数据基于 RowKey 的不同范围划分到不同 Region 上，每个Region都负责一定范围的数据存储和访问。
每个表一开始只有一个 Region，随着数据不断插入表，Region 不断增大，当增大到一个阀值的时候，Region 就会等分成两个新的 Region。当table中的行不断增多，就会有越来越多的 Region。
另外，Region 是 Hbase 中分布式存储和负载均衡的最小单元，不同的 Region 可以分布在不同的 HRegion Server上。但一个Hregion是不会拆分到多个server上的。
这样即使有一个包括上百亿条数据的表，由于数据被划分到不同的 Region上，每个 Region 都可以独立地进行写入和查询，HBase 写查询时候可以于多 Region 分布式并发操作，因此访问速度也不会有太大的降低。
TimeStamp
TimeStamp 是实现 HBase 多版本的关键。在HBase 中，使用不同 TimeStamp 来标识相同RowKey对应的不同版本的数据。相同 RowKey的数据按照 TimeStamp 倒序排列。默认查询的是最新的版本，当然用户也可以指定 TimeStamp 的值来读取指定版本的数据。
列式存储会被广泛用在OLAP中
为什么列式存储会广泛地应用在 OLAP 领域，和行式存储相比，它的优势在哪里，一起来对比下这两种存储方式的差别。
其实，列式存储并不是一项新技术，最早可以追溯到 1983 年的论文 Cantor。然而受限于早期的硬件条件和应用场景，传统的事务型数据库(OLTP)如 Oracle、MySQL 等关系型数据库都是以行的方式来存储数据的。直到近几年分析型数据库(OLAP)的兴起，列式存储这一概念又变得流行，如 HBase、Cassandra 等大数据相关的数据库都是以列的方式来存储数据的。
行式存储的原理与特点
对于 OLAP 场景，大多都是对一整行记录进行增删改查操作的，那么行式存储采用以行的行式在磁盘上存储数据就是一个不错的选择。当查询基于需求字段查询和返回结果时，由于这些字段都埋藏在各行数据中，就必须读取每一条完整的行记录，大量磁盘转动寻址的操作使得读取效率大大降低。
举个例子，下图为员工信息emp表。
数据在磁盘上是以行的形式存储在磁盘上，同一行的数据紧挨着存放在一起。
对于 emp 表，要查询部门 dept 为 A 的所有员工的名字：
select name from emp where dept = A;
由于 dept 的值是离散地存储在磁盘中，在查询过程中，需要磁盘转动多次，才能完成数据的定位和返回结果。
列式存储的原理与特点
对于 OLAP 场景，一个典型的查询需要遍历整个表，进行分组、排序、聚合等操作，这样一来行式存储中把一整行记录存放在一起的优势就不复存在了。而且，分析型 SQL 常常不会用到所有的列，而仅仅对其中某些需要的的列做运算，那一行中无关的列也不得不参与扫描。然而在列式存储中，由于同一列的数据被紧挨着存放在了一起，如下图所示。
那么基于需求字段查询和返回结果时，就不许对每一行数据进行扫描，按照列找到需要的数据，磁盘的转动次数少，性能也会提高。还是上面例子中的查询，由于在列式存储中 dept 的值是按照顺序存储在磁盘上的，因此磁盘只需要顺序查询和返回结果即可。
列式存储不仅具有按需查询来提高效率的优势，由于同一列的数据属于同一种类型，如数值类型，字符串类型等，相似度很高，还可以选择使用合适的编码压缩可减少数据的存储空间，进而减少IO提高读取性能。
总的来说，行式存储和列式存储没有说谁比谁更优越，只能说谁更适合哪种应用场景。
HBase 的架构组成
HBase 作为 NoSQL 数据库的代表，属于三驾马车之一 BigTable 的对应实现，HBase 的出现很好地弥补了大数据快速查询能力的空缺。其核心架构由五部分组成，分别是 HBase Client、HMaster、Region Server、ZooKeeper 以及 HDFS。它的架构组成如下所示，将对 HBase 架构组成的每一部分详细介绍一下。
HBase Client
HBase Client 为用户提供了访问 HBase 的接口，可以通过元数据表来定位到目标数据的 RegionServer，另外 HBase Client 还维护了对应的 cache 来加速 Hbase 的访问，比如缓存元数据的信息。
HMaster
HMaster 是 HBase 集群的主节点，负责整个集群的管理工作，主要工作职责如下：
1.分配Region：负责启动的时候分配Region到具体的 RegionServer；
2.负载均衡：一方面负责将用户的数据均衡地分布在各个 Region Server 上，防止Region Server数据倾斜过载。另一方面负责将用户的请求均衡地分布在各个 Region Server 上，防止Region Server 请求过热；
3.维护数据：发现失效的 Region，并将失效的 Region 分配到正常的 RegionServer 上，并且在Region Sever 失效的时候，协调对应的HLog进行任务的拆分。
Region Server
Region Server 直接对接用户的读写请求，是真正的干活的节点，主要工作职责如下：
1.管理 HMaster 为其分配的 Region；
2.负责与底层的 HDFS 交互，存储数据到 HDFS；
3.负责 Region 变大以后的拆分以及 StoreFile 的合并工作。
4.与 HMaster 的协同：当某个 RegionServer 宕机之后，ZK 会通知 Master 进行失效备援。下线的 RegionServer 所负责的 Region 暂时停止对外提供服务，Master 会将该 RegionServer 所负责的 Region 转移到其他 RegionServer 上，并且会对所下线的 RegionServer 上存在 MemStore 中还未持久化到磁盘中的数据由 WAL 重播进行恢复。
5.Region：每一个 Region 都有起始 RowKey 和结束 RowKey，代表了存储的Row的范围，保存着表中某段连续的数据。一开始每个表都只有一个 Region，随着数据量不断增加，当 Region 大小达到一个阀值时，Region 就会被 Regio Server 水平切分成两个新的 Region。当 Region 很多时，HMaster 会将 Region 保存到其他 Region Server 上。
6.Store：一个 Region 由多个 Store 组成，每个 Store 都对应一个 Column Family，Store 包含 MemStore 和 StoreFile。
6.1.MemStore：作为HBase的内存数据存储，数据的写操作会先写到 MemStore 中，当MemStore 中的数据增长到一个阈值(默认64M)后，Region Server 会启动 flasheatch 进程将 MemStore 中的数据写人 StoreFile 持久化存储，每次写入后都形成一个单独的 StoreFile。当客户端检索数据时，先在 MemStore中查找，如果MemStore 中不存在，则会在 StoreFile 中继续查找。
6.2.StoreFile：MemStore 内存中的数据写到文件后就是StoreFile，StoreFile底层是以 HFile 的格式保存。HBase以Store的大小来判断是否需要切分Region。
当一个Region 中所有 StoreFile 的大小和数量都增长到超过一个阈值时，HMaster 会把当前Region分割为两个，并分配到其他 Region Server 上，实现负载均衡。
6.3.HFile：HFile 和 StoreFile 是同一个文件，只不过站在 HDFS 的角度称这个文件为HFile，站在HBase的角度就称这个文件为StoreFile。
6.4.HLog：负责记录着数据的操作日志，当HBase出现故障时可以进行日志重放、故障恢复。例如，磁盘掉电导致MemStore中的数据没有持久化存储到 StoreFile，这时就可以通过HLog日志重放来恢复数据。
ZooKeeper
HBase 通过 ZooKeeper 来完成选举 HMaster、监控 Region Server、维护元数据集群配置等工作，主要工作职责如下：
1.选举HMaster：通ooKeeper来保证集中有1HMaster在运行，如果 HMaster 异常，则会通过选举机制产生新的 HMaster 来提供服务；
2.监控Region Server: 通过 ZooKeeper 来监控 Region Server 的状态，当Region Server 有异常的时候，通过回调的形式通知 HMaster 有关Region Server 上下线的信息；
3.维护元数据和集群配置：通过ooKeeper储B信息并对外提供访问接口。
HDFS
HDFS 为 HBase 提供底层数据存储服务，同时为 HBase提供高可用的支持， HBase 将 HLog 存储在 HDFS 上，当服务器发生异常宕机时，可以重放 HLog 来恢复数据。
HBase 的写入流程
了解下 HBase 是如何写入数据的，然后再讲解一下一个比较经典的面试题。
Region Server 寻址
HBase Client 访问 ZooKeeper；
1.获取写入 Region 所在的位置，即获取 hbase:meta 表位于哪个 Region Server；
2.访问对应的 Region Server；
3.获取 hbase:meta 表，并查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 Region 信息以及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问；
4.写 Hlog
4.1.HBase Client 向 Region Server 发送写 Hlog 请求；
4.2.Region Server 会通过顺序写入磁盘的方式，将 Hlog 存储在 HDFS 上；
5.写 MemStore 并返回结果
5.1.HBase Client 向 Region Server 发送写 MemStore 请求；
5.2.只有当写 Hlog 和写 MemStore 的请求都成功完成之后，并将反馈给 HBase Client，这时对于整个 HBase Client 写入流程已经完成。
MemStore 刷盘
HBase 会根据 MemStore 配置的刷盘策略定时将数据刷新到 StoreFile 中，完成数据持久化存储。为什么要把 WAL 加载到 MemStore中，再刷写成 HFile 呢？
WAL (Write-Ahead-Log) 预写日志是 HBase 的 RegionServer 在处理数据插入和删除过程中用来记录操作内容的一种日志。每次Put、Delete等一条记录时，首先将其数据写入到 RegionServer 对应的 HLog 文件中去。
而WAL是保存在HDFS上的持久化文件，数据到达 Region 时先写入 WAL，然后被加载到 MemStore 中。这样就算Region宕机了，操作没来得及执行持久化，也可以再重启的时候从 WAL 加载操作并执行。
那么从写入流程中可以看出，数据进入 HFile 之前就已经被持久化到 WAL了，而 WAL 就是在 HDFS 上的，MemStore 是在内存中的，增加 MemStore 并不能提高写入性能，为什么还要从 WAL 加载到 MemStore中，再刷写成 HFile 呢？
1.数据需要顺序写入，但 HDFS 是不支持对数据进行修改的；
2.WAL 的持久化为了保证数据的安全性，是无序的；
3.Memstore在内存中维持数据按照row key顺序排列，从而顺序写入磁盘。
所以 MemStore 的意义在于维持数据按照RowKey的字典序排列，而不是做一个缓存提高写入效率。
HBase 的读取流程
Region Server 寻址
HBase Client 请求 ZooKeeper 获取元数据表所在的 Region Server的地址。
Region 寻址
HBase Client 请求 RegionServer 获取需要访问的元数据，查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以 及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。
数据读取
HBase Client 请求数据所在的 Region Server，获取所需要的数据。Region 首先在 MemStore 中查找，若命中则返回；如果在MemStore 中找不到，则通过 BloomFilter 判断数据是否存在；如果存在，则在StoreFile中扫描并将结果返回客户端。