hadoop hbase学习笔记

hadoop hbase学习笔记

    当一个表中记录的数据越来越大的时候，hbase自动把表切分为不同的region，每个region包含所有行的子集，有[startkey,endkey]表示，有第一行及最后一行，加一个随机生成的区域标识符组成。不同的region会被hbase的master分配到相应的regionserver。由于原始table中的记录按照row key排序，所以分裂后的每个子table中的记录都包括在一个区间。hbase正是利用这些区间，快速的检索和存储，解决了传统的关系型数据库在大数据量下写入效率低的问题

     hbase中有两张特殊的table。Root,和META。其中META表中记录了所有用户表的Region信息，这张META表可以有多个region。ROOT表中记录了META表的region信息，ROOT表只有一个Region，hadoop项目中的子项目中的zookeeper记录了ROOT表的信息

     所以，客户端在访问数据之前要先访问zookeeper，取得root表的信息，根据信息访问META表，最后才能找到用户数据的位置

     图片写：图片写请求由用户发起，通过负载均衡模块的过滤，首先来到应用服务器排队等待进入hdfs存储系统，通过namenode分配Datanode进行存储，图片写入过程中先确定写入block,在确定Sequence file,系统将二者的id组合命名为图片的系统内名称。hadoop client --> namenode --> datanode master（完成数据复制3份）--> namenode --> datanode --> hadoop client

     图片读：图片命名blockid加block中的fileid和offset偏移量，hbase根据图片的文件名查询图片的名字，描述等相关信息。由于namenode维护了block和datanode之间的映射信息，namenode根据请求解析中的block确定该block在datanode信息，由于我们设置的HDFS中的block size大小为64M，单个图片为几k-几m，所以大量的小图片在一个block里，所以客户端根据namenode给出的datanode地址取得block后，根据fileid获取图片信息

     图片元数据存储：根据key进行表的划分，将各个分表存储在不同的节点上，写入数据的时候只需要根据key的范围即可定位到存储该范围key的datanode，数据量达到百万后，hbase写入效率高于关系型数据库。查询数据时也是根据key查找，可将针对海量数据的检索缩小到针对单个datanode存储数据的检索，效率也高于关系型数据库

      hbase会设定单张表的大小，当一张表的容量大于设定值后会自动分割为两张表。由于hbase是基于列而不是基于行的，所以表的分割不牵扯到表内容，表结构，分表效率高于关系型数据库。

      因为每个图片都有自己独立的图片文件名，所以我们采用图片文件名做key，图片描述，上传时间，上传者等作为列簇。图片文件名做行键，便于图片检索和图片的读取，由于上一节对文件名进行了定义，所以我们在分表的时候就按照blockid划分，将相同的block中所包含的图片元数据存储在表中相近的位置，同一列族的数据，物理存储位置也是相近的，这样检索后磁头读取的时候，减少了磁头来回换道的时间消耗

   Client

1 包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。

Zookeeper

1 保证任何时候，集群中只有一个master

2 存贮所有Region的寻址入口。

3 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master

4 存储Hbase的schema,包括有哪些table，每个table有哪些column family

Master

1 为Region server分配region

2 负责region server的负载均衡

3 发现失效的region server并重新分配其上的region

4 GFS上的垃圾文件回收

5 处理schema更新请求

Region Server

1 Region server维护Master分配给它的region，处理对这些region的IO请求

2 Region server负责切分在运行过程中变得过大的region

可以看到，client访问hbase上数据的过程并不需要master参与（寻址访问zookeeper和region server，数据读写访问regione server），master仅仅维护者table和region的元数据信息，负载很低。

五、关键算法/流程

region定位

系统如何找到某个row key (或者某个 row key range)所在的region

bigtable 使用三层类似B+树的结构来保存region位置。

第一层是保存zookeeper里面的文件，它持有root region的位置。

第二层root region是.META.表的第一个region其中保存了.META.z表其它region的位置。通过root region，我们就可以访问.META.表的数据。

.META.是第三层，它是一个特殊的表，保存了hbase中所有数据表的region 位置信息。

 

说明：

1 root region永远不会被split，保证了最需要三次跳转，就能定位到任意region 。

2.META.表每行保存一个region的位置信息，row key 采用表名+表的最后一样编码而成。

3 为了加快访问，.META.表的全部region都保存在内存中。

假设，.META.表的一行在内存中大约占用1KB。并且每个region限制为128MB。

那么上面的三层结构可以保存的region数目为：

(128MB/1KB) * (128MB/1KB) = = 2(34)个region

4 client会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的region(其中三次用来发现缓存失效，另外三次用来获取位置信息)。

http://www.alidata.org/archives/1509