Hbase面试题

HBase面试题整理（一）

1、 HBase的特点是什么？

  1）大：一个表可以有数十亿行，上百万列；
  2）无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；
  3）面向列：面向列（族）的存储和权限控制，列（族）独立检索；
  4）稀疏：空（null）列并不占用存储空间，表可以设计的非常稀疏；
  5）数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳；
  6）数据类型单一：Hbase中的数据都是字符串，没有类型。

2、HBase和Hive的区别？

  Hive和Hbase是两种基于Hadoop的不同技术–Hive是一种类SQL的引擎，并且运行MapReduce任务，Hbase是一种在Hadoop之上的NoSQL 的Key/vale数据库。
当然，这两种工具是可以同时使用的。就像用Google来搜索，用FaceBook进行社交一样，Hive可以用来进行统计查询，HBase可以用来进行实时查询，
数据也可以从Hive写到Hbase，设置再从Hbase写回Hive。

3、HBase适用于怎样的情景？

  ① 半结构化或非结构化数据
  对于数据结构字段不够确定或杂乱无章很难按一个概念去进行抽取的数据适合用HBase。以上面的例子为例，当业务发展需要存储author的email，phone，
address信息时RDBMS需要停机维护，而HBase支持动态增加。
  ② 记录非常稀疏
  RDBMS的行有多少列是固定的，为null的列浪费了存储空间。而如上文提到的，HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。
  ③ 多版本数据
  如上文提到的根据Row key和Column key定位到的Value可以有任意数量的版本值，因此对于需要存储变动历史记录的数据，用HBase就非常方便了。
比如上例中的author的Address是会变动的，业务上一般只需要最新的值，但有时可能需要查询到历史值。
  ④ 超大数据量
  当数据量越来越大，RDBMS数据库撑不住了，就出现了读写分离策略，通过一个Master专门负责写操作，多个Slave负责读操作，服务器成本倍增。
随着压力增加，Master撑不住了，这时就要分库了，把关联不大的数据分开部署，一些join查询不能用了，需要借助中间层。随着数据量的进一步增加，
一个表的记录越来越大，查询就变得很慢，于是又得搞分表，比如按ID取模分成多个表以减少单个表的记录数。经历过这些事的人都知道过程是多么的折腾。
采用HBase就简单了，只需要加机器即可，HBase会自动水平切分扩展，跟Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）。

4、描述HBase的rowKey的设计原则？（☆☆☆☆☆）

（1）Rowkey长度原则
  Rowkey 是一个二进制码流，Rowkey 的长度被很多开发者建议说设计在10~100 个字节，不过建议是越短越好，不要超过16 个字节。
  原因如下：
  ① 数据的持久化文件HFile 中是按照KeyValue 存储的，如果Rowkey 过长比如100 个字节，1000 万列数据光Rowkey 就要占用100*1000 万=10 亿个字节，
将近1G 数据，这会极大影响HFile 的存储效率；
  ② MemStore 将缓存部分数据到内存，如果Rowkey 字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率。
因此Rowkey 的字节长度越短越好。
  ③ 目前操作系统是都是64 位系统，内存8 字节对齐。控制在16 个字节，8 字节的整数倍利用操作系统的最佳特性。
（2）Rowkey散列原则
  如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，
这样将提高数据均衡分布在每个Regionserver 实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有新数据都在一个 RegionServer 上堆积的
热点现象，这样在做数据检索的时候负载将会集中在个别Reg