HBase之功能细节
fmms
13年前
<h3>1.Region定位</h3> <p>在Google的BigTable体系中，<span style="color:#3366ff;">tablet</span>的存储地址通过3层目录结构来定位的，如图所示：</p> <p>注：<span style="color:#3366ff;">tablet</span>等同与HBase中的Region</p> <p><img alt="HBase之功能细节" src="https://simg.open-open.com/show/e1ced262737e715e723bd6bc234c5923.jpg" width="390" height="220" /></p> <p>图释说明：</p> <p>(1)METADATATable</p> <p>METADATATable是系统预定义的Table,当用户自定义表格被拆分成多个tablet之后,METADATA Table用来存储这些tablet的地址,在目录层级中处于第3层</p> <p>(2)Root tablet</p> <p>METADATA表格在分布式存储过程中也会被拆分成多个tablet,其中第一个tablet比较特殊,用来存储其他tablet的地址,称之为Roottablet,在目录层级中处于第2层</p> <p>(3)Chunbby file</p> <p>用来存储Roottablet的地址,在目录结构中处于顶层</p> <p>这样，客户端可通过Chubby file遍历到任何tablet的地址</p> <p><em>在HBase中:</em></p> <p><em>Region的概念等同于tablet<br /> </em></p> <p><em>.META.表格等同于METADATATable</em></p> <p><em>而-ROOT-表格等同于Chunbby file<br /> </em></p> <p><em>这样，客户端可通过-ROOT- Table遍历到任何Region的地址,并把这些地址在本地进行缓存，以加快下次查询效率</em></p> <h3>2.Region分配<br /> </h3> <p>在HBase中，MasterServer负责将Region分配给RegionServer</p> <p>首先，看一下BigTable中tablet如何分配：</p> <p>当master机器启动的时候，它会处理如下事情：</p> <p>(1)首先在Chunbby中获取masterlock,在分布式部署中，系统中只能有一个master处于运行状态，当其获得master锁之后，其他的master机器将会进入等待状态</p> <p>(2)master会扫描Chunbby目录，以获取处于运行状态的table server(RegionServer)</p> <p>(3)master会和每一台tabletserver进行通信，来记录哪些tablet已经成功分配</p> <p>(4)master会扫描METADATA表格，如果发现有tablet不在已分配记录中，则将其分配到合适的tablet server</p> <p><em>在HBase中，是通过如下API来完成Region的分配过程：</em></p> <p><em>(1)Master在启动的时候，会去调用AssignmentManager类<br /> </em></p> <p><em>(2)AssignmentManager通过查找.META.表格来获取Region信息</em></p> <p><em>(3)如果Region尚未分配，则调用LoadBalancerFactory将其分配，默认的分配器(DefaultLoadBalancer)会将该Region分配给一个随机的RegionServer<br /> </em></p> <p><em>(4)更新.META.表格信息</em></p> <h3>3.数据存储<br /> </h3> <p>在HDFS中，HBase的数据存储呈如下目录结构：</p> <p> <hbase></hbase></p> <p> |__</p> <p></p> <p> |__ <region></region></p> <p> |__ <columnfamily></columnfamily></p> <p> |__ <storefile></storefile></p> StoreFile是基于Google的SSTable来实现的，每个SSTable相当于一个持久存储的、多维的、可序列化Map，Map的key和 value都是可解释型字符数组，可从中提炼出具体的rowKey、timestamp、columnKey和columnValue等信息。 <br /> <p>在物理存储上SSTable由多个Block块组成，SSTable记录了每个Block快的索引位置，并且在被访问的时候将这些块索引加载到内存,以便系统快速定位Block块所在磁盘位置。</p> <h3>4.Region Serving</h3> <p>在Google的BigTable体系中，tablet会持久化存储到GFS文件系统中，如图：</p> <p><img alt="HBase之功能细节" src="https://simg.open-open.com/show/c953020c33dc147266f26833e95713aa.jpg" width="389" height="222" /></p> <p>图释说明：</p> <p>(1)当有写操作到达时，系统首先会将信息写入到tablet log，然后把所提交的数据存储在memtable上，这样，tablet log就记录了每次写操作的日志信息以及操作的数据信息，当需要执行undo/redo操作式，可通过遍历查找该tablet log来实现撤销/恢复的功能。</p> <p>写操作提交之后，数据并没有持久化存储到本地硬盘上，而是放到了memtable里，memtable是存储在内存当中的，当其大小达到一定上限之后，才持久化存储到SSTable File中去，随后进行数据的压缩处理(参考<span style="color:#3366ff;">5-数据压缩</span>)</p> <p>(2)因为memtable也存储了相关的数据信息，而且是写操作提交后的最新信息，所以查询操作的数据来源有两方面，一方面是SSTable Files，另一方面是memtable。</p> <p>(3)tablet恢复</p> <p>当tablet数据需要恢复到历史版本时，tablet server首先会查询METADATA表格，从中获取该tablet的元数据信息，包括：</p> <p> 存储该tablet的SSTable文件</p> <p> Tablet的恢复点(存储在tabletlog中)</p> <p>随后，tablet server会把要恢复的相关记录加载到内存，根据tablet log所记录的操作日志来重新构建memtable</p> <h3>5.数据压缩<br /> </h3> <p>数据压缩主要有3中方式，分别是：</p> <p>(1)Minor compaction:</p> <p>当memtable的大小达到一定上限之后便会被系统冻结。此时，一个新的memtable将会创建，而被冻结的memtable将会持久化储存到SSTable文件中去。</p> <p>(2)Merging compaction:</p> <p>每一个minor compaction都会生成一个SSTable文件，当minor compaction操作较多时， SSTable文件将会包含很多实体的历史信息，造成数据冗余，解决办法是系统会定期执行merging compaction，将相关SSTable存储的实体进行合并，以保证实体信息处于最新版本，为查询提供方便。</p> <p>(3)Major compaction:</p> 将所有的SSTable合并成一个SSTable称之为major compaction，Major compaction通常用来回收逻辑上已被删除的数据，以节省磁盘空间。 <table class="ke-zeroborder"> <tbody></tbody> </table> <p></p>