整套大数据学习资料(视频+笔记)百度网盘无门槛下载:http://www.edu360.cn/news/content?id=3377

13.3.2 实现

hadoop 花牛 17℃ 0评论

正如HDFSMapReduce由客户端、从属机(slave)和协调主控机(master) (即 HDFS 的 namenode 和 datanode,..以及 MapReduce 的 jobtrackertasktracker)——组成,HBase也采用相同的模型,它用一个master节点 协调管理一个或多个regionserver从属机(参见图13-1)。HBase主控机 (master)负责启动(bootstrap—个全新的安装,把区域分配给注册的 regionserver,恢复 regionserver 的故障。master 的负载很轻。regionserver 负责零个或多个区域的管理以及响应客户端的读写请求。regionserver还负 责区域的划分并通知HBase master有了新的子区域(daughter region),这样 主控机就可以把父区域设为离线,并用子区域替换父区域。

 

 image.png

13-1. HBase集群的成员


HBase依赖于ZooKeeper(参见第14章)。默认情况下,它管理一个ZooKeeper实例,作为集群的“权威机构”(authority)。HBase负责根目录表(root catalog table)的位置、当前集群主控机地址等重要信息的管理。如果 在区域的分配过程中有服务器崩溃,就可以通过ZooKeeper来进行分配的 协调。在ZooKeeper上管理分配事务的状态有助于在恢复时能够从崩溃服 务器遗留的状态开始继续分配。在启动一个客户端到HBase集群的连接 时,客户端必须至少拿到到集群所传递的ZooKeeper集合体(ensemble)的位 置。这样,客户端才能访问ZooKeeper的层次结构,从而了解集群的属性,例如服务器的位置。

类似于在Hadoop中可以通过文件查看datanode和tasktracker, regionserver从属机节点列在HBase的文件中。启动和结束服务的脚本和Hadoop类似,使用相同的基于SSH的机制来运行远程命 令。集群的站点配置(site-specific configuration)在 HBase的conf/hbase-site.xml和conf/hbase-env.sh文件中。它们的格式和Hadoop项目中对应的格式相同(参见第9章)。

对于HBaseHadocjp上相同的服务或类型HBase实际上直接使用 或继承Hadoop的实现。在无法直接使用或继承时HBase会尽量遵 循 Hadoop 的模型。例如,HBase 使用 Hadoop Configuration 系统,所以它们的配置文件格式相同。对于作为用户的你来说,这意味着 你使用HBase时感觉就像使用Hadoop —样“亲切”。HBase只是在 增加特殊功能时才不遵循这一规则。

HBase通过Hadoop文件系统API来持久化存储数据。有多种文件系统接口的实现:一种用于本地文件系统;一种用于KFS文件系统、Amazon S3以 及HDFS。多数人使用HDFS作为存储来运行HBase。但是,在默认情况 下,除非另行指明,HBase会'將存储写入本地文件系统。如果是体验一下 新装HBase,这是没有问题的,但如果稍后要使用HBase集群,首要任务 通常是把HBase的存储配置为指向所要使用的HDFS集群。

运行中的HBase

HBase内部保留名为-R00T-和.META.的特殊目录表(catalog table)。它们维护着当前集群上所有区域的列表、状态和位置。-ROOT-表包含.META.表的区域列表。.META.表包含所有用户空间区域(user-space region)的列表。表 中的项使用区域名作为键。区域名由所属的表名、区域的起始行、区域的 创建时间以及对其整体进行的MD5哈希值(即对表名、起始行、创建的时 间戳进行哈希后的结果)组成。如前所述,行的键是排序的。因此,要査找一个特定行所在的区域只要在目录表中找到第一个键大于或等于给定行 键的项即可。区域变化时——即分裂、禁用/启用(disable/enable)、删除、为负载均衡重新部署区域或由于regionserver崩溃而重新部署区域时目录表会进行相应的更新。这样,集群上所有区域的状态信息就能保持是最新的。

新连接到ZooKeeper集群上的客户端首先查找-ROOT-的位置。然后客户端通过-ROOT-获取所请求行所在范围所属.META.区域的位置。客户端接着 査找.META.区域来获取用户空间区域所在节点及其位置。接着,客户端就 可以直接和管理那个区域的regionserver进行交互。

每个行操作可能要访问三次远程节点。为了节省这些代价,客户端会缓存 它们遍历-ROOT-时获取的信息和.META.位置以及用户空间区域的开始行和结束行。这样,它们以后不需要访问.META.表也能得知区域存放的位置。客户端在碰到错误之前会一直使用所缓存的项。当发生错误时一一即区 域被移动了——客户端会再去査看.META.获取区域的新位置。如果.META.区域也被移动了,客户端会再去査看-ROOT-。

到达Regionserver的写操作首先被追加到“提交日志”(commit log)中,然 后被加入内存中的memstore。如果memstore满,它的内容会被“刷入”(flush)文件系统。

提交日志存放在HDFS中,因此即使一个regionserver崩溃,提交日志仍然 可用。如果发现一个regionserver不能访问(通常因为服务器的znode在 ZooKeeper中过期)主控机会根据区域对死掉的regionserver的提交日志进行 分割。重新分配后,在打开并使用死掉的regionserver上的区域之前,这些 区域会找到属于它们的从被分割提交日志中得到的文件,其中包含还没有 被持久化存储的更新。这些更新会被“重做”(replay)以使区域恢复到服务 器失败前的状态。

在读的时候首先査看区域的memstore。如果在memstore中找到了需要的版 本,査询就结束了。否则,需要按照次序从新到旧检査“刷新文件”(flush file),直到找到满足査询的版本,或所有刷新文件都处理完为止。

有一个后台进程负责在刷新文件个数到达一个阈值时压缩它们。它把多个 文件重新写入一个文件。这是因为读操作检査的文件越少,它的执行效率 越高。在压缩(compaction)时,进程会清理掉超出模式所设最大值的版本以 及删除单元格或标识单元格为过期。在regionserver上,另外有一个独立的 进程监控着刷新文件的大小,一旦文件大小超出预先设定的最大值,便对区域进行分割。

转载请注明:全栈大数据 » 13.3.2 实现

喜欢 (0)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址