Hadoop生态——HBase

HBase

1.为什么用HBase存储？

HBase(Hadoop Database)是一个高可靠性，高性能，可伸缩，面向列的分布式数据库（也许叫做存储系统会更加贴切）。
HBase与Hadoop的关系非常紧密，Hadoop的HDFS提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定性及failover机制的保障。同时其他周边产品诸如Hive可以与HBase相结合使在HBase进行数据统计处理变得简单，Sqoop为HBase提供了方便的RDBMS数据导入功能，使传统数据库的数据向HBase中迁移变得容易，Spark等高性能的内存分布式计算引擎也可能帮助我们更加快速的对HBase中的数据进行处理分析。

技巧

考察HBase的特点。需要能够回答出HBase的高可用，高性能，面向列的存储。是一个非关系型的分布式存储数据库。运行与HDFS文件系统之上，但查询速度快。

2.*Rowkey怎么设计，有什么好处？

1.长度原则

RowKey是一个二进制码流，可以是任意字符串，最大长度为64kb，实际应用中一般为10-100byte，以byte[]形式保存，一般设计成定长。建议越短越好，不要超过16个字节，原因如下：

• 数据的持久化文件HFile中时按照Key-Value存储的，如果RowKey过长，例如超过100byte，那么1000w行的记录，仅RowKey就需占用近1GB的空间。这样会极大影响HFile的存储效率。
• MemStore会缓存部分数据到内存中，若RowKey字段过长，内存的有效利用率就会降低，就不能缓存更多的数据，从而降低检索效率。
• 目前操作系统都是64位系统。内存8字节对齐，控制在16字节，8字节的整数倍利用了操作系统的最佳特性。

2.唯一原则

必须在设计上保证RowKey的唯一性。由于在HBase中数据存储是Key-Value形式，若向HBase中同一张表插入相同RowKey的数据，则原先存在的数据会被新的数据覆盖。

3.排序原则

HBase的RowKey是按照ASCII有序排序的，因此我们在设计RowKey的时候要充分利用这点。

4.散列原则

设计的RowKey应均匀的分布在各个HBase节点上。

技巧

RowKey的设计原则是HBase常问的问题。需要能够回答出这些原则，以及相对应得一些细节，比如长度原则，建议越短越好，不要超过16个字节。唯一原则中，同一张表插入相同RowKey的数据，则原先存在的数据会被新的数据覆盖等。

3.HBase的优化？

1.表的设计

1. 建表时就分区（预分区），RowKey设置定长（64字节），CF2到3个。
2. Max Versio，Time to live，compact&Split。

2.写表

1. 多Htable并发写，提高吞吐量。
2. Htable参数设置，手动flush，降低IO。
3. WriteBuffer。
4. 批量写，减少网络I/O开销。
5. 多线程并发写，结合定时flush和写buffer（writeBufferSize），可以既保证在数据量小的时候，数据可以在较短时间内被flush（如1秒内），同时又保证在数据量大的时候，写buffer一满就及时进行flush。

3.读表

1. 多Htable并发读，提高吞吐量。
2. Htable参数设置。
3. 批量读。
4. 释放资源。
5. 缓存查询结果。

技巧

考察有没有使用过HBase的优化。从设计方面，写数据和读数据三个方面进行回答。本着解决什么瓶颈的问题来谈优化。比如吞吐量低，就提高吞吐量，受网络I/O影响，就提升网络I/O。最好能结合自己的项目进行说明。

4.*HBase的读写流程？

1.元数据存储

HBase中有一个系统表hbase:meta存储HBase元数据信息，可以在HBase Web UI查看到相关信息。如下图。
HBase 元数据表：

该表记录保存了每个表的Region地址，还有一些其他信息。例如Region的名字，对应表的名字，开始行键，结束行键，服务器的信息。hbase:meta 表中每一行对应一个单一的Region。数据如下图。
图 hbase:meta 表数据格式：


ZooKeeper中存储了hbase:meta表的位置，客户端可以通过Zookeeper查找到hbase:meta表的位置，hbase:meta是HBase当中一张表，肯定由一个HRegionServer来管理，其实主要就是要通过Zookeeper的 “/hbase/meta-region-server” 获取存储 “hbase:meta” 表的HRegionServer的地址。