【作者主页】Francek Chen【专栏介绍】⌈ ⌈⌈大数据技术原理与应用⌋ ⌋⌋专栏系统介绍大数据的相关知识分为大数据基础篇、大数据存储与管理篇、大数据处理与分析篇、大数据应用篇。内容包含大数据概述、大数据处理架构Hadoop、分布式文件系统HDFS、分布式数据库HBase、NoSQL数据库、云数据库、MapReduce、Hadoop再探讨、数据仓库Hive、Spark、流计算、Flink、图计算、数据可视化以及大数据在互联网领域、生物医学领域的应用和大数据的其他应用。【GitCode】专栏资源保存在我的GitCode仓库https://gitcode.com/Morse_Chen/BigData_principle_application。文章目录一、HBase 的功能组件二、表和Region三、Region的定位总结一、HBase 的功能组件HBase 的实现包括 3 个主要的功能组件库函数链接到每个客户端一个 Master 主服务器也称为 Master许多个 Region 服务器。Region 服务器负责存储和维护分配给自己的 Region处理来自客户端的读写请求。Master 主服务器负责管理和维护 HBase 表的分区信息比如一个表被分成了哪些 Region每个 Region 被存放在哪台 Region 服务器上同时也负责维护 Region 服务器列表。因此如果 Master 主服务器死机那么整个系统都会无效。Master 会实时监测集群中的 Region 服务器把特定的 Region 分配到可用的 Region 服务器上并确保整个集群内部不同 Region 服务器之间的负载均衡。当某个 Region 服务器因出现故障而失效时Master 会把该故障服务器上存储的 Region 重新分配给其他可用的 Region 服务器。除此以外Master 还处理模式变化如表和列族的创建。客户端并不是直接从 Master 主服务器上读取数据而是在获得 Region 的存储位置信息后直接从 Region 服务器上读取数据。尤其需要指出的是HBase 客户端并不依赖于 Master 而是借助于 ZooKeeper 来获得 Region 的位置信息的所以大多数客户端从来不和 Master 主服务器通信这种设计方式使 Master 的负载很小。二、表和Region在一个 HBase 中存储了许多表。对于每个 HBase 表而言表中的行是根据行键的值的字典序进行维护的表中包含的行的数量可能非常庞大无法存储在一台机器上需要分布存储到多台机器上。因此需要根据行键的值对表中的行进行分区见图1。每个行区间构成一个分区被称为“Region”。Region 包含了位于某个值域区间内的所有数据是负载均衡和数据分发的基本单位。这些 Region 会被分发到不同的 Region 服务器上。初始时每个表只包含一个 Region随着数据的不断插入Region 会持续增大。当一个 Region 中包含的行数量达到一个阈值时就会被自动等分成两个新的 Region图2随着表中行的数量继续增加就会分裂出越来越多的 Region。图1 一个HBase表被划分成多个Region图2 一个Region会分裂成多个新的Region每个 Region 的默认大小是 100200 MB是 HBase中负载均衡和数据分发的基本单位。Master 主服务器会把不同的 Region 分配到不同的 Region 服务器上见图3但是同一个 Region 不会被拆分到多个 Region 服务器上。每个 Region 服务器负责管理一个 Region 集合通常在每个 Region服务器上会放置 101000 个 Region。图3 不同的Region可以分布在不同的Region服务器上三、Region的定位一个 HBase 的表可能非常庞大会被分裂成很多个 Region这些 Region 可被分发到不同的 Region 服务器上。因此必须设计相应的 Region 定位机制保证客户端知道到可以在哪里找到自己所需要的数据。元数据表又名 .META. 表存储了 Region 和 Region 服务器的映射关系当 HBase 表很大时.META. 表也会被分裂成多个 Region。根数据表又名 -ROOT- 表记录所有元数据的具体位置。-ROOT- 表只有唯一一个 Region名字是在程序中被写死的。Zookeeper 文件记录了 -ROOT- 表的位置。图4 HBase的三层结构表1 HBase三层结构中各层次的名称和作用层次名称作用第一层Zookeeper文件记录了-ROOT-表的位置信息第二层-ROOT-表记录了.META.表的Region位置信息-ROOT-表只能有一个Region。通过-ROOT-表就可以访问.META.表中的数据第三层.META.表记录了用户数据表的Region位置信息.META.表可以有多个Region保存了HBase中所有用户数据表的Region位置信息为了加快访问速度.META. 表的全部 Region 都会被保存在内存中。假设 .META. 表的每行一个映射条目在内存中大约占用 1 KB并且每个 Region 限制为 128 MB那么上面的三层结构可以保存的用户数据表的 Region 数目的计算方法是-ROOT- 表能够寻址的 .META. 表的 Region 个数×每个 .META. 表的 Region 可以寻址的用户数据表的 Region 个数。一个 -ROOT- 表最多只能有一个 Region也就是最多只能有 128 MB按照每行一个映射条目占用 1 KB 内存计算128 MB 空间可以容纳 128 MB/1 KB217行也就是说一个 -ROOT- 表可以寻址 217 个.META. 表的 Region。同理每个 .META. 表的 Region 可以寻址的用户数据表的 Region 数目是 128 MB/1KB217。最终三层结构可以保存的 Region 数目是 (128 MB/1 KB)×(128 MB/1 KB) 234个 Region。可以看出这种数量已经可以满足实际应用中的用户数据存储需求。客户端访问用户数据之前需要首先访问 ZooKeeper获取 -ROOT- 表的位置信息然后访问 -ROOT- 表获得 .META. 表的信息接着访问 .META. 表找到所需的 Region 具体位于哪个 Region 服务器最后才会到该 Region 服务器读取数据。该过程需要多次网络操作为了加速寻址过程一般会在客户端把查询过的位置信息缓存起来这样以后访问相同的数据时就可以直接从客户端缓存中获取 Region 的位置信息而不需要每次都经历一个“三级寻址”过程。需要注意的是随着 HBase 中表的不断更新Region 的位置信息可能会发生变化但是客户端缓存并不会自己检测 Region 位置信息是否失效而是在需要访问数据时从缓存中获取 Region 位置信息却发现不存在的时候才会判断出缓存失效。这时客户端就需要再次经历上述的“三级寻址”过程重新获取最新的 Region 位置信息去访问数据并用最新的 Region 位置信息替换缓存中失效的信息。当一个客户端从 ZooKeeper 服务器上拿到-ROOT-表的地址以后就可以通过“三级寻址”找到用户数据表所在的 Region 服务器并直接访问该 Region 服务器获得数据没有必要再连接 Master 主服务器。因此Master 主服务器的负载相对就小了很多。总结HBase 有库函数、Master 主服务器、Region 服务器三大功能组件。表按行键分区成 Region随数据增多会分裂。为定位 Region设计了三层结构包括 Zookeeper 文件、-ROOT- 表、.META. 表。客户端先经“三级寻址”找数据位置为加速会缓存信息位置变化致缓存失效时再重新寻址。客户端获-ROOT-表地址后可直接访问 Region 服务器减轻 Master 负载。欢迎点赞 | 收藏⭐ | 评论✍ | 关注