hbase问题总结(校招)

1.hbase的底层
1)StoreFile
保存实际数据的物理文件，StoreFile以HFile的形式存储在HDFS上。每个Store会有一个或多个StoreFile(HFile),数据在每个StoreFile都是有序的。
2)MemStore
写缓存，由于HFile中的数据要求是有序的，所以数据是先存储在MemStore中，排好序后，等到达刷写时机时才会刷写到HFile，每次刷写都会形成一个新的HFile。
3)WAL
由于数据要经MemStore排序后才会刷写到HFile，但把数据保存在内存中会有很高的效率导致数据丢失，为了解决这个问题，数据会先写在一个叫做Write-Ahead logfile的文件中，然后再写入到MemStore中。所以在系统出现故障的时候，数据可以通过这个日志文件重建。

读流程:
1)client先访问zookeeper，获取hbase:meta表位于哪个RegionServer.
2)访问对应的RegionServer，获取hbase:meta表，根据读请求的namespace:table/rowkey,查询出目标数据位于哪个RegionServer中的哪个Region中。并把该table的region信息以及meta表的位置信息缓存在客户端的meta cache，方便下次访问。
3)与目标RegionServer进行通讯；
4）分别在BlockCache(读缓存)，MemStore中查询目标数据，如果BlockCache中未查到相应数据则扫描对应的HFile文件，HFile中扫描的数据块(64k)写入BlockCache，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本或者不同的类型。
5）将合并后的最终结果返回给客户端。

2.rowkey设计原则:
1)长度原则:hbase将部分数据加载到内存中，如果rowkey过长，会降低内存的有效利用率。
2）散列原则：提高数据均衡分布的几率。如果不进行散列处理，首字段直接使用时间信息，所有该时段的数据都将集中到一个regionServer中，当检索数据时，负载会集中到个别RegionServer，造成热点问题，降低查询效率。
3）唯一原则。rowkey按照字典顺序排序存储的。将经常读取的数据存储到一块。
3.rowkey如何设计？
1）（在rowkey的前面加)随机数、哈希、散列值
2）字符串反转