HBase is a NoSQL database modeled after Google's Bigtable. It provides a distributed, scalable, big data store. Key features include horizontal scaling, reliability, column orientation, high performance random reads/writes, and seamless integration with Hadoop. Data is stored in tables containing rows, column families, and columns. The system is comprised of clients, Zookeeper, masters, region servers, and HDFS for data storage. Region servers handle read/write operations on regions, while masters manage region assignment and load balancing.

1. HBase– Yet Another NoSQL bluedavy http://blog.bluedavy.com

2. Basic Concept Example 表 表名 + Column Family + Column Qualifier users ( infos(name,email,age) auths(password,security) ) 表名+Column Family相当于Schema Column Qualifier可动态增加 读 table.get(rowKey,Column Family) table.get(rowKey,ColumnFamily,Column Qualifier) table.get(rowKey,ColumnFamily,ColumnQualifier,maxVersions) 写 table.put(rowKey,ColumnFamily,ColumnQualifier,value)

3. Overview Client Zookeeper Region Server Master HDFS

4. Overview Client 读写数据的客户端 Zookeeper 保存rootregion的位置 Master选举 Region Server以及Region上下线的感应 Region Server 表的具体操作的场所 Master Region的分配以及balance HDFS 存放数据的地方

5. from Facebook

6. Features 水平扩展 可 靠 性 面向列 高性能随机读/写 范围查询 和Hadoop无缝集成

7. 水平扩展 数据量太大了，读写性能下降？ 传统方案：分库分表（迁移数据，中间层） HBase：啥都不用做，加机器即可。 且性能平稳。

8. 水平扩展 HBase存储结构 HDFS

9. 水平扩展 如何做到的？ 当storeFile多了后，HBase会自动compact； 当rows多了后，HBase会自动将region split； HBase会定时对Region Server的Region数进行balance； Region Server下线，Master会重新分配其负责的Region到其他的Region Server； Region Server上线后，当Master进行balance时会迁移一些Region到新的Region Server。

10. 面向列 动态增删schema？ 传统方案：停机维护； HBase: No，Column Qualifier可动态增删。

11. 面向列 如何做到的？ 以Column Family为存储单元； K/V方式存储。

12. 高性能随机读/写 如何做到的？ 随机读 K/V存储； Cache； Split； Balance。 随机写（相对而言） Cache+WAL； Compact； Split； Balance；

13. 范围查询 如何做到的？ 存储时按字典序对key做排序； 1,10,11,15,19,2,24,3

14. 可靠性 借助HDFS保证数据的可靠； WAL； 恢复机制。

15. 不足 目前版本不支持二级索引； 易用性不够； 系统结构复杂，运维上有挑战； rowKey的设计对运行状况有很大影响； 对Online业务还是有很大挑战，主要是延时以及失败率。

16. HBase关键操作 读 写 Cache刷磁盘 Compact Split Balance 数据恢复

17. 读 Example 代码 Configuration config=HBaseConfiguration.create(); HTable table=new HTable(config,"users"); Get queryRow=new Get(Bytes.toBytes("0")); queryRow.addColumn(Bytes.toBytes("infos"), Bytes.toBytes("nick")); Result rowResult=table.get(queryRow); System.out.println("nick is :"+Bytes.toString(rowResult.raw()[0].getValue()));

18. 读 Client 本地cache Region Server 1、找rowKey对应的region 或接近rowKey的region 2、未找到则从缓存的.meta信息中获取meta的region server 2.1、从meta所在的Region Server获取rowKey对应的Region 3、RPC发送请求，从Region Server读数据，超时默认为60s 4、reader线程接到RPC请求后，丢到Queue里； 5、10个handler线程处理Queue，默认Queue最大为1000； 6、检查Region Server是否为运行状态； 7、检查Region是否为Online，如不Online则抛出异常； 8、再次检查Region是否正在关闭或已关闭； 9、创建Scanner（Region—Store—Memstore--StoreFile），在读取StoreFile时会先读取LruBlockCache（全局一个，默认20%的xmx空间）； 10、扫描找到相应的数据，算法较复杂，不在此描述。 抛出异常或返回结果数据 如抛出异常，则检查重试次数是否超过10次（默认值），未超过则按照指数退避的方法sleep后再继续重试，重试时重新获取meta信息。

19. 影响读的关键因素 速度 是否能从cache中获取到region server的地址； RPC发送请求的速度； RPC超时时间； Reader线程的活跃数； Handler Queue的Size； Handler线程的活跃数； Memstore的命中率； LruCache的命中率； HDFS读取速度； 读重试的次数以及重试的间隔时间。 失败率 Region Server以及Region的状态； HDFS能否读取。

20. 写 Example 代码 Configuration config=HBaseConfiguration.create(); HTable table=new HTable(config,"users"); Put row=new Put(Bytes.toBytes(String.valueOf(“0”))); row.add(Bytes.toBytes("infos"), Bytes.toBytes("nick"), Bytes.toBytes("bixuan")); row.add(Bytes.toBytes("infos"), Bytes.toBytes("age"), Bytes.toBytes(“30”)); row.add(Bytes.toBytes("infos"), Bytes.toBytes("sex"), Bytes.toBytes("male")); table.put(row);

21. 写 Client 本地cache Region Server 1、检验put的key/value size是否超过了最大值，默认无限制； 2、往writeBuffer中放入put，计算currentWriteBufferSize； 3、如为autoFlush或currentWriteBufferSize大于了2M，则提交； 4、从cache中获取需要操作的 Region Server地址； reader线程接到RPC请求后，丢到Queue里； 10个handler线程处理Queue，默认Queue最大为1000； 检查Region Server是否在运行状态，不运行则抛出异常； 检查Region是否online，不online则抛出异常； 检查RS的memstore的总值是否已超过最大限制，超过则唤醒flush线程，并等待5s或唤醒后再次检查，如还是超过，则继续； 如memstore的总值只是超过了最低限制，则只是唤醒flush线程； 从put中获取是否要写WAL； 如region为只读，则抛出异常； 如region的memstore大小超过128M，则通知进行flush，等待10s 后重新尝试； 再次检查region的状态； 行上加锁； 检查families，更新KV的timestamp； 如要写WAL，则写Hlog； 往memstore里写相应的信息； 检查memstore的size是否要flush，如要flush，则通知flusher flush。 5、未找到则从.meta.的region中获取需要操作的region server； 6、丢入htable instance创建的线程池提交put请求，Future方式等待结果； 7、线程池中RPC发送put请求到对应的region server； 抛出异常或返回结果数据 按提交put请求的server遍历返回的结果； 如返回的结果为null或不为DoNotRetryIOException的异常，则放入重试的list中； 进行重试，最大次数10次，每次做指数避让的sleep； 遍历返回的所有result，如其中有null或异常，则抛出RetriesExhaustedWithDetailsException； 从writeBuffer中删除已成功的put请求。

22. 影响写的关键因素 速度 是否autoflush； 不为autoflush时的flushWriteBufferSize； 是否能从cache中获取需要操作的region server地址； Htable instance线程池的队列的size； RPC发送请求的速度以及超时时间； Reader线程的活跃数； Handler Queue的Size； Handler线程的活跃数； RS全局的memstore Size以及Region的memstore size； Memstore刷磁盘的执行频率和时间； 是否WAL； 写Hlog的速度； 写重试的次数。 失败率 Region Server以及Region的状态； HDFS能否写成功。 可靠性 不为autoflush时不可靠； 目前的代码一直要到put成功为止。

23. Cache刷磁盘 MemstoreFlusher HRegion 1、从flush队列中获取刷磁盘的请求，超时时间为10s； 2、如队列中没有请求，或请求的类型为WakeFlushThread，则进入下面的流程； 2.1 判断当前所有的memstore size总和是否超过了最低的阈值（默认为0.35 * -Xmx），如超过则选择一个合适的Region，将其memstore刷入到磁盘； 3、如队列中的请求类型为FlushRegionEntry，则进入下面的流程； 3.1 将该region的memstore刷入到磁盘； 4、将Region的memstore刷入到磁盘。 5、检查Region的状态； 6、锁住对memstore以及storeFile的更新操作； 7、锁住hlog的cacheFlush，避免roll； 8、创建memstore的snapshot； 8.1 清空之前的memstore的内容； 9、释放memstore以及storeFile的更新锁； 10、刷memstore到磁盘并将新文件加入到store list中； 11、如store中的store files已>=3个，则表示需要进行compact； 12、hlog中记录下flush已完成。 13、返回是否需要compact； 14、如需要compact，则放一个请求到CompactSplitThread的队列中。

24. 影响Cache刷磁盘的关键因素 Memstore中数据的大小； 写HDFS的速度。

25. Cache刷磁盘对读写造成的影响 对读的影响 memstore被清空，命中率会有些许下降； 对写的影响 有一小段锁住memstore及storeFile更新操作的时间，基本可忽略，因为只是创建snapshot；

26. Compact CompactSplitThread HRegion 1、根据队列中的请求获取需要Compact的Region，单线程工作； 2、检查Region Server的状态； 3、压缩region； 4、检查region的状态； 5、交给region中的store来完成compact，store会根据一定的算法选择需要compact的storeFiles（如store中有reference，则全部compact），最少要有3个，并根据需要保存的max version生成新的store file； 6、给store加锁，将没有compact的storeFile以及生成的新的store File合并为新的store list，排序并赋值给store files，删除旧的store files，释放锁； 7、如compact后的storeFile文件大于了256m，则获取其中间key，并返回，如小于则返回null； 8、返回中间key或null； 9、如hbase.regionserver.regionSplitLimit>当前server中online的region数，且中间key不为null，则进入split过程。

27. 影响Compact的关键因素 需要compact的文件个数； 写HDFS的速度。

28. Compact对读写造成的影响 对读的影响； 有一小段锁store的时间，读需要等； 对写的影响； 有一小段锁store的时间，写需要等； Compact文件如果大的话，对写也会产生影响，抢IO资源；

29. Split CompactSplitThread HRegion 1、检查server的状态； 2、创建split文件夹； 3、close region； 4、设置状态为closing； 5、对region加写锁； 6、刷memstore； 7、关闭所有的store file reader； 8、设置状态为closed； 9、释放锁。 10、从online region中拿掉此region； 11、每个store file一个线程进行split，生成的为两个reference的文件； 12、创建两个daughter region，并将parent region从meta表中下线； 12、如split失败，则按状态进行回滚； 13、如split成功，则打开新创建的两个region，更新meta表信息，通知master发生了split事件。

30. 影响Split的关键因素 写HDFS的速度；

31. Split对读写造成的影响 split时读写均无法操作，会直接抛错，要直到meta表信息更新完毕才能恢复。

32. Balance对读写造成的影响 部分读写操作可能会出现短暂的失败 原因在于balance需要关闭一些region。 部分读会出现慢的现象 原因在于balance后的region没cache。

33. 数据恢复 store file中的元信息存储了seqid； region在open时会根据seqid以及hlog来进行恢复； master在重新分配region的时候会将hlog分好类，以便进行恢复； rs在做split动作时会先创建一个splits目录，以便恢复。