HBase问题汇总与解答

今天早上分享了下HBase，分享的时候同事提出了一些问题，可能大部分有有这样的困惑，汇总下来：

HBase问题汇总与解答

1. 两个独立的服务器，一台用HDFS，一台不用HDFS能够吗？HDFS和Hbase必需要装在同一台服务器上吗？

答：

As HBase runs on HDFS (and each StoreFile is written as a file on HDFS), it is important to have an understanding of the HDFS Architecture especially in terms of how it stores files, handles failovers, and replicates blocks.

To operate with the most efficiency, HBase needs data to be available locally. Therefore, it is a good practice to run an HDFS DataNode on each RegionServer

Hbase运行在HDFS之上，每一个StoreFile都被写成一个HDFS的文件，能理解HDFS的架构，它是如何存储文件，处理故障转移和复制块很重要

大多数状况下，Hbase将数据存储在HDFS之上，像Hfile和WALs(主要为了防止RegionServer出现故障)都会存储在HDFS上，HDFS提供对Hbase数据的可靠性和保证，为了最大化的操做效率，Hbase也须要本地的数据是可靠的，所以最好是在每个RegionServer上运行DataNode。

当有问题出现的时候，最好同时检查HDFS和Hbase的日志，由于日志可能再两个地方都有记录。

另外，HBase不支持一台用HDFS，一台不用HDFS，在彻底分布式的场景中，多个Hbase的实例运行在集群的多个服务器上面，通常要设置两个属性：

hbase.rootdir指向一个HDFS的文件系统

hbase.cluster.distributed属性设置为true。

以下：能够看到HBase只能指向某一种文件系统的路径上，并且想要HBase彻底的分布式，必需要设置上面两个属性。

<configuration>
  <property>
    <name>hbase.rootdir</name>
    <value>hdfs://namenode.example.org:8020/hbase</value>
  </property>
  <property>
    <name>hbase.cluster.distributed</name>
    <value>true</value>
  </property>
  <property>
    <name>hbase.zookeeper.quorum</name>
    <value>node-a.example.com,node-b.example.com,node-c.example.com</value>
  </property>
</configuration>
复制代码

HBase是HDFS的客户端，Hbase使用的是DFSClient来和HDFS交互，能够看到配置就是Hbase指向HDFS的那个位置，HBase经过Ip port访问HDFS。

参见：hbase.apache.org/book.html#_…

2. 除了HDFS以外，还有其余的文件系统可让Hbase更好的使用吗？

答：HBase和HDFS并非强制的绑定在一块儿的，HBase彻底可使用本地文件系统，好比mac的文件系统，Linux的ext3,ext2等等，均可以运行Hbase。

3. HLog是写磁盘仍是日志？

Hlog其实就是WAL的实现, 它记录Hbase中全部的数据改变，若是在RegionServer在MemStore刷新到磁盘以前，不能访问或者挂掉了，WAL能够保证数据的改变从新再进行一次。

The Write Ahead Log (WAL) records all changes to data in HBase, to file-based storage， WAL ensures that the changes to the data can be replayed

根据官网描述，HLog默认写到磁盘上，即HDFS上，咱们在使用Hbase的时候能够设置WAL的持久化方式，有如下四种：

• SKIP_WAL: 不写WAL
• ASYNC_WAL：异步写，不用等到WAL写到磁盘上的时候离开返回客户端，同时后台数据的改变会被刷新到WAL。这个选项可能致使丢失数据
• SYNC_WAL：默认的方式，每一次数据的改变都会写到HDFS上面，只有写入成功才返回给客户端成功。
• FSYNC_WAL：每一次的编辑都会写到HDFS，而且同步到文件系统以后才会返回成功。

Mutation.setDurability(Durability.SKIP_WAL)
复制代码

所以默认方式下，WAL是写到HDFS之上，会尽量的走持久化，而不是在内存中久留，可能再数据改变的时候通过内存，而后就马上写到HDFS上面了。

4. 列簇能不能更名字？

官方的命令是能够修改列簇的名字的，列簇的添加，删除，修改都是能够的。可是能不能修改取决因而否配置了这个属性：

hbase.online.schema.update.enable

// 给t1表新增f1列簇
alter 't1', NAME => 'f1', VERSIONS => 5
// 删除ns1:t1表的f1列簇
alter 'ns1:t1', NAME => 'f1', METHOD => 'delete'
复制代码

可是就像MySQL咱们能够修改列的名字，在数据量很大的状况下，咱们通常不会修改原有的列名。

5. 客户端的缓存何时更新？Master怎么处理

客户端首先经过hbase:meta表找到服务指定范围的行的RegionServer，在定位到是哪一个Region以后，客户端直接联系RegionServer，而没有通过Master，而后发出读写请求。当Region被Master从新分配，或者某个RegionSever挂掉的时候，客户端会从新的查询索引表hbase:meta 来决定新的region位置。当RegionServer挂掉的时候，Master节点是能够感知到的，Master作RegionServer的协调工做，会通知RegionSever，在客户端查的时候也知道数据改变了，能够再次请求索引表hbase:meta。

The HBase client finds the RegionServers that are serving the particular row range of interest. It does this by querying the hbase:meta table. See hbase:meta for details. After locating the required region(s), the client contacts the RegionServer serving that region, rather than going through the master, and issues the read or write request. This information is cached in the client so that subsequent requests need not go through the lookup process. Should a region be reassigned either by the master load balancer or because a RegionServer has died, the client will requery the catalog tables to determine the new location of the user region.

一个常问的问题就是Master挂掉的时候，Hbase会发生什么事情，由于Hbase客户端是直接和RegionServer进行通讯，并且hbase:meta表并无存在Master节点上，Master只是进行RegionServer的故障恢复和Region的切分，所以在Master挂掉的短期内，Hbase还能正常的工做，只不过要尽量快的修复Master。

Master节点感知的元数据改变是粒度比较大的，好比表改变，列簇改变，Region的切分，合并，移动，都不是频繁的发生的状况。

A common dist-list question involves what happens to an HBase cluster when the Master goes down. Because the HBase client talks directly to the RegionServers, the cluster can still function in a "steady state". Additionally, per Catalog Tables, hbase:meta exists as an HBase table and is not resident in the Master. However, the Master controls critical functions such as RegionServer failover and completing region splits. So while the cluster can still run for a short time without the Master, the Master should be restarted as soon as possible.

6. Master有没有存元数据？

Master通常运行在NameNode上面，没有存储元数据。

另外多说下，Master是能够有多个的，若是主Master挂掉了，剩余的Master会竞争Master的角色。

If run in a multi-Master environment, all Masters compete to run the cluster. If the active Master loses its lease in ZooKeeper (or the Master shuts down), then the remaining Masters jostle to take over the Master role.

7. 发送一个key，里面具体怎么获取数据的？

   1. 由于每个用户表Region都是一个RowKey Range，meta Region中记录了每个用户表Region的路由以及状态信息，以RegionName(包含表名，Region StartKey，Region ID，副本ID等信息)做为RowKey。

   2. Region只要不被迁移，那么获取的该Region的路由信息就是一直有效的，所以，HBase Client有一个Cache机制来缓存Region的路由信息，避免每次读写都要去访问ZooKeeper或者meta Region。

   3. 相似于Client发送建表到Master的流程，Client发送写数据请求到RegionServer，也是经过RPC的方式。只是，Client到Master以及Client到RegionServer，采用了不一样的RPC服务接口。

   4. RegionServer的RPC Server侧，接收到来自Client端的RPC请求之后，将该请求交给Handler线程处理。若是是single put，则该步骤比较简单，由于在发送过来的请求参数MutateRequest中，已经携带了这条记录所关联的Region，那么直接将该请求转发给对应的Region便可。

   5. HBase也采用了LSM-Tree的架构设计：LSM-Tree利用了传统机械硬盘的“顺序读写速度远高于随机读写速度”的特色。随机写入的数据，若是直接去改写每个Region上的数据文件，那么吞吐量是很是差的。所以，每个Region中随机写入的数据，都暂时先缓存在内存中(HBase中存放这部份内存数据的模块称之为MemStore，这里仅仅引出概念，下一章节详细介绍)，为了保障数据可靠性，将这些随机写入的数据顺序写入到一个称之为WAL(Write-Ahead-Log)的日志文件中.

      1. WAL中的数据按时间顺序组织：若是位于内存中的数据还没有持久化，并且忽然遇到了机器断电，只须要将WAL中的数据回放到Region中便可

      2. 若是一个WAL中所关联的全部的Region中的数据，都已经被持久化存储了，那么，这个WAL文件会被暂时归档到另一个目录中

      3. 在0.94版本以前，Region中的写入顺序是先写WAL再写MemStore，这与WAL的定义也相符。

      4. 但在0.94版本中，将这二者的顺序颠倒了，当时颠倒的初衷，是为了使得行锁可以在WAL sync以前先释放，从而能够提高针对单行数据的更新性能。详细问题单，请参考HBASE-4528。

         在2.0版本中，这一行为又被改回去了，缘由在于修改了行锁机制之后(下面章节将讲到)，发现了一些性能降低，而HBASE-4528中的优化却没法再发挥做用，详情请参考HBASE-15158。改动以后的逻辑也更简洁了。

至此，这条数据已经被同时成功写到了WAL以及MemStore中, 当MemStore达到阈值的时候，会被刷新到磁盘上进行持久化存储，而若是服务器挂掉了，则能够经过WAL进行数据恢复。

参考:一条数据的HBase之旅，简明HBase入门教程-Write全流程

8. Hlog有没有存满以后的淘汰策略？磁盘存满了？HBase怎么存储

像上面提到的Hlog是存储在磁盘上面的，不是内存型存储不须要淘汰策略，要解决的就是磁盘存满以后怎么办？磁盘满了确定是存不进去了，通常状况下咱们都会有磁盘利用率的检测工具，在磁盘到达必定程度以后进行通知，HDFS是能够无限扩容的，就是多加台服务器的事情。

9. 并发写一个key？

在以前的版本中，行级别的任何并发写入/更新都是互斥的，由一个行锁控制。但在2.0版本中，这一点行为发生了变化，多个线程能够同时更新一行数据，这里的考虑点为：

• 若是多个线程写入同一行的不一样列族，是不须要互斥的
• 多个线程写同一行的相同列族，也不须要互斥，即便是写相同的列，也彻底能够经过HBase的MVCC机制来控制数据的一致性
• 固然，CAS操做(如checkAndPut)或increment操做，依然须要独占的行锁

HBase 原子性文档

ACID in HBase

后续单独整理

10. 数据恢复，集群管理

Hbase备份和恢复，属于比较大的知识块，后续单独整理