hadoop hbase学习笔记

jxp2002

　　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>　　图片元数据存储：根据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(其中三次用来发现缓存失效，另外三次用来获取位置信息)。
　　Zookeeper存储
　　不但在HDFS中存储信息，HBase还在Zookeeper中存储信息，其中的znode如下所示：

• 　　/hbase/root-region-server ，Root region的位置
  
• 　　/hbase/table/-ROOT-，根元数据信息
  
• 　　/hbase/table/.META.，元数据信息
  
• 　　/hbase/master，当选的Mater
  
• 　　/hbase/backup-masters，备选的Master
  
• 　　/hbase/rs ，Region Server的信息
  
• 　　/hbase/unassigned，未分配的Region
  

　　也就是说，由Zookeeper保持了集群的状态信息
　　1. 在整个路由过程中并没有涉及到MasterServer，也就是说HBase日常的数据操作并不需要MasterServer，不会造成MasterServer的负担。
　　2. Client端并不会每次数据操作都做这整个路由过程，很多数据都会被Cache起来。
　　作者：用心阁
　　链接：https://www.zhihu.com/question/20130759/answer/35406376
　　来源：知乎
　　著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
　　http://www.alidata.org/archives/1509