Hbase的读写流程

Hbase的读写流程 Hbase的读写流程 1.hbase的公共流程

用户在访问数据时，如何找到该条数据对应的region呢？

通过rowkey对应regionserver

1.1.Hbase 0.96以前

• 系统维护了两张表
  • -ROOT-
    • 使用-ROOT-表来记录.meta.的存放位置
    • -ROOT-表只需要一个Region，它不会被切分
    • -ROOT-的Region信息被记录到Zookeeper
  • .meta.
    • .meta.表中存储了表对应Region对应的RegionServer Rowkey的区间
    • 但是.meta.也是一张普通的Hbase表，也需要存放到RegionServer

1.2.Hbase 0.96以后

• 系统只维护.meta.表

  • meta表更名为hbase:meta

  • .meta.的位置信息由Zookeeper维护

2.hbase的读取数据流程

• 1.Client通过访问zookeeper拿到hbase:meta所在RegionServer的节点信息
• 2…Client在访问hbase:meta所在RegionServer，拿到hbase:meta记录的数据后
  • 先加载到内存
  • 然后从内存中根据需要查询的RowKey查询出RowKey所在的Region的相关信息（Region所在RegionServer）
• 3.Client访问RowKey所在Region对应的RegionServer，发起数据读取请求
• 4.RegionServer构建RegionScanner，用于对该Region的数据检索
  • 注意：需要查询的RowKey分布在多少个Region中就需要构建多少个RegionScanner
• 5.RegionScanner构建StoreScanner，用于对该列族的数据检索
  • 注意：Region中有多少个Store就需要构建多少个StoreScanner
  • Store的数量取决于Table的ColumnFamily的数量，因为每个store保存一个columns family
• 6.多个StoreScanner合并构建最小堆（已排序的完全二叉树）StoreHeap:PriorityQueue
• 7.StoreScanner构建一个MemStoreScanner和一个或多个StoreFileScanner（数量取决于StoreFile数量）
  • 这里是因为一个Store由一个MemStore和多个StoreFile
• 8.过滤掉某些能够确定所要查询的RowKey一定不在StoreFile内的对应的StoreFileScanner或MemStoreScanner
• 9.经过筛选后留下的Scanner开始做读取数据的准备，将对应的StoreFile定位到满足的RowKey的起始位置
  • 优先从MemStore读取数据，没有再到StoreFile读取，StoreFile内部有序，外部无序
• 10.将所有的StoreFileScanner和MemStoreScanner合并构建最小堆KeyValueHeap:PriorityQueue，排序的规则按照KeyValue从小到大排序
• 11.从KeyValueHeap:PriorityQueue中经过一系列筛选后一行行的得到需要查询的KeyValue。

3.hbase的写入流程

• 1.首先客户端和RegionServer建立连接
• 2.然后将DML要做的 *** 作写入到日志wal-log
• 3.然后将数据的修改更新到memstore中，然后本次 *** 作结束
  • 写 *** 作先写入memstore.
  • 当memstore数据写到阈值之后，创建一个新的memstore
  • 旧的memstore写成一个独立的storefile,regionserver会启动flashcache进程写入storefile，每次写入形成单独的一个storefile,存放到hdfs
  • 但是当storefile数量不断的增大，到达一定阈值的时候，系统会进行合并
    • 在合并过程中会进行版本合并和删除工作，形成更大的storefile
  • 当一个region所有storefile的大小和数量超过一定阈值后，会把当前的region分割为两个，并由hmaster分配到相应的regionserver服务器，实现负载均衡，这就是切分 *** 作
• 注意：其实当storefile文件数量变多就会合并，合并之后文件变大，或者storefile数量多到一定阈值，region就会开始切分