大数据技术应用（国家） 知识点1：寻址机制 寻址机制.docx

PAGE2 / NUMPAGES4 寻址机制 寻址机制 摘 要：通过此文档来了解Hbase的Regionserver的寻址机制。 关键词：Reginonserver； 1. RegionServer简介 HRegionServer是HBase中最主要的组件，负责table数据的实际读写，管理Region。在分布式集群中，HRegionServer一般跟DataNode在同一个节点上，目的是实现数据的本地性，提高读写效率。 图1 RegionServer架构图 2. RegionServer的主要功能 （1）定期向Master汇报RS的情况，包括RS内存使用状态、在线状态的Region等信息 （2）管理Region，执行Flush、Compaction、Open、Close、Load等操作 （3）管理WAL （4）执行数据插入、更新和删除操作 （5）Metrics：对外提供了衡量HBase内部服务状况的参数 （6）内置HttpServer，提供访问RS的界面 3. 老的 Region 寻址方式 在 HBase-0.96 版本以前，HBase 有两个特殊的表，分别是-ROOT-表和.META.表，其中-ROOT-的位置存储在 ZooKeeper 中，-ROOT-本身存储了.META. Table 的 RegionInfo 信息，并且-ROOT-不会分裂，只有一个 Region。而.META.表可以被切分成多个 Region。读取的流程如下图所示： 图2 RegionServer读取流程 读取的流程步骤：（1）Client 请求 ZooKeeper 获得-ROOT-所在的 RegionServer 地址；（2）Client 请求-ROOT-所在的 RS 地址，获取.META.表的地址，Client 会将-ROOT-的相关信息 cache 下来，以便下一次快速访问；（3）Client 请求.META.表的 RegionServer 地址，获取访问数据所在 RegionServer 的地址，Client 会将.META.的相关信息cache下来，以便下一次快速访问；（4）Client请求访问数据所在 RegionServer 的地址，获取对应的数据。 从上面的路径可以看出，用户需要3次请求才能直到用户Table真正的位置，这在一定程序带来了性能的下降。在0.96之前使用3层设计的主要原因是考虑到元数据可能需要很大。但是真正集群运行，元数据的大小其实很容易计算出来。在BigTable的论文中，每行METADATA 数据存储大小为1KB左右，如果按照一个 Region为128M的计算，3层设计可以支持的 Region个数为2^34 个，采用 2 层设计可以支持 2^17（131072）。那么2层设计的情况下一个集群可以存储4P的数据。这仅仅是一个Region只有128M 的情况下。如果是10G呢? 因此，通过计算，其实2层设计就可以满足集群的需求。因此在0.96版本以后就去掉了-ROOT-表了。 4. 新的 Region 寻址方式 2 层结构其实完全能满足业务的需求，因此0.96版本以后将-ROOT-表去掉了。如下图所示： 图3 RegionServer二层架构图 访问路径变成了3步：（1）Client 请求 ZooKeeper 获取.META.所在的 RegionServer 的地址；（2）Client 请求.META.所在的 RegionServer 获取访问数据所在的RegionServer地址，Client会将.META.的相关信息 cache 下来，以便下一次快速访问。（3）Client 请求数据所在的 RegionServer，获取所需要的数据。简单地说：从.META.表里面查询哪个Region包含这条数据；获取管理这个Region的RegionServer地址；连接这个RegionServer, 查到这条数据。 总结去掉-ROOT-的原因有如下2点：提高性能；2层结构已经足以满足集群的需求。 系统如何找到某个row key（或者某个 row key range）所在的region bigtable 使用三层类似B+树的结构来保存region位置。第一层是保存zookeeper里面的文件，它持有root region的位置。第二层root region是.META.表的第一个region其中保存了.META.表其它region的位置。通过root region，我们就可以访问.META.表的数据。.META.是第三层，它是一个特殊的表，保存了Hbase中所有数据表的region位置信息。 5. 读写过程 5.1 读请求过程： （1） 客户端通过zookeeper以及root表和meta表找到目标数据所在的regionser