讲一下 Hbase 架构
Hbase主要包含HMaster/HRegionServer/Zookeeper
HRegionServer 负责实际数据的读写. 当访问数据时, 客户端直接与RegionServer通信.
HBase的表根据Row Key的区域分成多个Region, 一个Region包含这这个区域内所有数据. 而Region server负责管理多个Region, 负责在这个Region server上的所有region的读写操作.
HMaster 负责管理Region的位置, DDL(新增和删除表结构)
- 协调RegionServer
- 在集群处于数据恢复或者动态调整负载时,分配Region到某一个RegionServer中
- 管控集群,监控所有Region Server的状态
- 提供DDL相关的API, 新建(create),删除(delete)和更新(update)表结构.
Zookeeper 负责维护和记录整个Hbase集群的状态
zookeeper探测和记录Hbase集群中服务器的状态信息.如果zookeeper发现服务器宕机,它会通知Hbase的master节点.
hbase 如何设计rowkey
RowKey长度原则
Rowkey是一个二进制码流，Rowkey的长度被很多开发者建议说设计在10~100个字节，不过建议是越短越好，不要超过16个字节。
原因如下：
数据的持久化文件HFile中是按照KeyValue存储的，如果Rowkey过长比如100个字节，1000万列数据光Rowkey就要占用100*1000万=10亿个字节，将近1G数据，这会极大影响HFile的存储效率；
MemStore将缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率。因此Rowkey的字节长度越短越好。
目前操作系统是都是64位系统，内存8字节对齐。控制在16个字节，8字节的整数倍利用操作系统的最佳特性。
RowKey散列原则
如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有新数据都在一个RegionServer上堆积的热点现象，这样在做数据检索的时候负载将会集中在个别RegionServer，降低查询效率。
RowKey唯一原则
必须在设计上保证其唯一性。
讲一下hbase的存储结构,这样的存储结构有什么优缺点
Hbase的优点及应用场景:
- 半结构化或非结构化数据:
对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据适合用HBase，因为HBase支持动态添加列。 - 记录很稀疏：
RDBMS的行有多少列是固定的。为null的列浪费了存储空间。HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。 - 多版本号数据：
依据Row key和Column key定位到的Value能够有随意数量的版本号值，因此对于须要存储变动历史记录的数据，用HBase是很方便的。比方某个用户的Address变更，用户的Address变更记录也许也是具有研究意义的。 - 仅要求最终一致性：
对于数据存储事务的要求不像金融行业和财务系统这么高，只要保证最终一致性就行。（比如HBase+elasticsearch时，可能出现数据不一致） - 高可用和海量数据以及很大的瞬间写入量：
WAL解决高可用，支持PB级数据，put性能高
适用于插入比查询操作更频繁的情况。比如，对于历史记录表和日志文件。（HBase的写操作更加高效） - 业务场景简单：
不需要太多的关系型数据库特性，列入交叉列，交叉表，事务，连接等。
Hbase的缺点：
- 单一RowKey固有的局限性决定了它不可能有效地支持多条件查询
- 不适合于大范围扫描查询
- 不直接支持 SQL 的语句查询
hbase的HA实现,zookeeper在其中的作用
HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行。
配置HBase高可用，只需要启动两个HMaster，让Zookeeper自己去选择一个Master Acitve即可
zk的在这里起到的作用就是用来管理master节点,以及帮助hbase做master选举
HMaster宕机的时候,哪些操作还能正常工作
对表内数据的增删查改是可以正常进行的,因为hbase client 访问数据只需要通过 zookeeper 来找到 rowkey 的具体 region 位置即可. 但是对于创建表/删除表等的操作就无法进行了,因为这时候是需要HMaster介入, 并且region的拆分,合并,迁移等操作也都无法进行了
讲一下hbase的写数据的流程
- Client先访问zookeeper，从.META.表获取相应region信息，然后从meta表获取相应region信息
- 根据namespace、表名和rowkey根据meta表的数据找到写入数据对应的region信息
- 找到对应的regionserver 把数据先写到WAL中，即HLog，然后写到MemStore上
- MemStore达到设置的阈值后则把数据刷成一个磁盘上的StoreFile文件。
- 当多个StoreFile文件达到一定的大小后(这个可以称之为小合并，合并数据可以进行设置，必须大于等于2，小于10——hbase.hstore.compaction.max和hbase.hstore.compactionThreshold，默认为10和3)，会触发Compact合并操作，合并为一个StoreFile，（这里同时进行版本的合并和数据删除。）
- 当Storefile大小超过一定阈值后，会把当前的Region分割为两个（Split）【可称之为大合并，该阈值通过hbase.hregion.max.filesize设置，默认为10G】，并由Hmaster分配到相应的HRegionServer，实现负载均衡
讲一下hbase读数据的流程
首先，客户端需要获知其想要读取的信息的Region的位置，这个时候，Client访问hbase上数据时并不需要Hmaster参与（HMaster仅仅维护着table和Region的元数据信息，负载很低），只需要访问zookeeper，从meta表获取相应region信息(地址和端口等)。【Client请求ZK获取.META.所在的RegionServer的地址。】
客户端会将该保存着RegionServer的位置信息的元数据表.META.进行缓存。然后在表中确定待检索rowkey所在的RegionServer信息（得到持有对应行键的.META表的服务器名）。【获取访问数据所在的RegionServer地址】
根据数据所在RegionServer的访问信息，客户端会向该RegionServer发送真正的数据读取请求。服务器端接收到该请求之后需要进行复杂的处理。
先从MemStore找数据，如果没有，再到StoreFile上读(为了读取的效率)。
