第四次作业

1.Hadoop起源与发展阶段

（1）Hadoop最早起源于lucene下的Nutch。Nutch的设计目标是构建一个大型的全网搜索引擎，包括网页抓取、索引、查询等功能，但随着抓取网页数量的增加，遇到了严重的可扩展性问题——如何解决数十亿网页的存储和索引问题。

（2）2003年、2004年谷歌发表的三篇论文为该问题提供了可行的解决方案。
——分布式文件系统（GFS），可用于处理海量网页的存储
——分布式计算框架MAPREDUCE，可用于处理海量网页的索引计算问题。
——分布式的结构化数据存储系统Bigtable，用来处理海量结构化数据。

（3）Doug Cutting基于这三篇论文完成了相应的开源实现HDFS和MAPREDUCE，并从Nutch中剥离成为独立项目HADOOP，到2008年1月，HADOOP成为Apache顶级项目(同年，cloudera公司成立)，迎来了它的快速发展期。

Hadoop的历史版本介绍

0.x系列版本：Hadoop当中最早的一个开源版本，在此基础上演变而来的1.x以及2.x的版本
1.x版本系列：Hadoop版本当中的第二代开源版本，主要修复0.x版本的一些bug等
2.x版本系列：架构产生重大变化，引入了yarn平台等许多新特性

 

 

2.名称节点、数据节点的主要功能及相互关系

在HDFS中，名称节点（NameNode）负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即FsImage和EditLog

 

第二名称节点：是HDFS架构中的一个组成部分，它是用来保存名称节点中对HDFS 元数据信息的备份，并减少名称节点重启的时间。
SecondaryNameNode一般是单独运行在一台机器上

SecondaryNameNode让EditLog变小的工作流程：
（1）SecondaryNameNode会定期和NameNode通信，请求其停止使用EditLog文件，暂时将新的写操作写到一个新的文件edit.new上来，这个操作是瞬间完成，上层写日志的函数完全感觉不到差别；
（2）SecondaryNameNode通过HTTP GET方式从NameNode上获取到FsImage和EditLog文件，并下载到本地的相应目录下；
（3）SecondaryNameNode将下载下来的FsImage载入到内存，然后一条一条地执行EditLog文件中的各项更新操作，使得内存中的FsImage保持最新；这个过程就是EditLog和FsImage文件合并；
（4）SecondaryNameNode执行完（3）操作之后，会通过post方式将新的FsImage文件发送到NameNode节点上

 数据节点是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表

 

4.梳理HBase的结构与运行流程，以用图与自己的话进行简要描述，图中包括以下内容：

• Master 功能：

  1、为 RegionServer 分配 Region

  2、负责 RegionServer 的负载均衡

  3、发现失效的 RegionServer 并重新分配其上的 Region

  4、HDFS 上的垃圾文件（HBase）回收

  5、处理 Schema 更新请求（表的创建，删除，修改，列簇的增加等等）

• RegionServer功能：

  1、RegionServer 维护 Master 分配给它的 Region，处理对这些 Region 的 IO 请求

  2、RegionServer 负责 Split 在运行过程中变得过大的 Region，负责 Compact 操作

开始只有一个Region，后来不断分裂

Region拆分操作非常快，接近瞬间，因为拆分之后的Region读取的仍然是原存储文件，直到“合并”过程把存储文件异步地写到独立的文件之后，才会读取新文件

每个Region默认大小是100MB到200MB（2006年以前的硬件配置）
– 每个Region的最佳大小取决于单台服务器的有效处理能力
– 目前每个Region最佳大小建议1GB-2GB（2013年以后的硬件配置）
同一个Region不会被分拆到多个Region服务器
每个Region服务器存储10-1000个Region

 Region的定位
元数据表，又名.META.表，存储了Region和Region服务器的映射关系
当HBase表很大时， .META.表也会被分裂成多个Region
根数据表，又名-ROOT-表，记录所有元数据的具体位置
-ROOT-表只有唯一一个Region，名字是在程序中被写死的
Zookeeper文件记录了-ROOT-表的位置

 

 

• ZooKeeper功能：

  1、ZooKeeper 为 HBase 提供 Failover 机制，选举 Master，避免单点 Master 单点故障问题

  2、存储所有 Region 的寻址入口：-ROOT-表在哪台服务器上。-ROOT-这张表的位置信息

  3、实时监控 RegionServer 的状态，将 RegionServer 的上线和下线信息实时通知给 Master

  4、存储 HBase 的 Schema，包括有哪些 Table，每个 Table 有哪些 Column Family

• Client请求流程：

  Client 访问用户数据前需要首先访问 ZooKeeper，找到-ROOT-表的 Region 所在的位置，然 后访问-ROOT-表，接着访问.META.表，最后才能找到用户数据的位置去访问，中间需要多次网络操作，不过 client 端会做 cache 缓存。

• 四者之间的相系关系
• 

   

   

• 与HDFS关联：

  HBase是一个内存数据库，而hdfs是一个存储空间；是物品和房子的关系。HBase 参考了 Google 公司的 Bigtable 建模，而 Bigtable 是基于 GFS 来完成数据的分布式存储的，因此，HBase 与 HDFS 有非常紧密的关系，它使用 HDFS 作为底层存储系统。

  HDFS是GFS的一种实现，他的完整名字是分布式文件系统，类似于FAT32，NTFS，是一种文件格式，是底层的。Hive与Hbase的数据一般都存储在HDFS上。Hadoop HDFS为他们提供了高可靠性的底层存储支持。

 

5.理解并描述Hbase表与Region与HDFS的关系。

 在Hbase中存在一张特殊的meta表,其中存放着HBase的元数据信息,包括,有哪些表,表有哪些HRegion,每个HRegion分布在哪个HRegionServer中。meta表很特殊，永远有且仅有一个HRegion存储meta表，这个HRegion存放在某一个HRegionServer中，并且会将这个持有meta表的Region的HRegionServer的地址存放在Zookeeper中meta-region-server下。
所以当在进行HBase表的读写操作时，需要先根据表名 和 行键确 定位到HRegion，这个过程就是HRegion的寻址过程。
HRgion的寻址过程首先由客户端开始，访问zookeeper 得到其中meta-region-server的值,根据该值找到唯一持有meta表的HRegion所在的HRegionServer,得到meta表,从中读取真正要查询的表和行键 对应的HRgion的地址,再根据该地址,找到真正的操作的HRegionServer和HRegion,完成HRgion的定位,继续读写操作.
客户端会缓存之前已经查找过的HRegion的地址信息,之后的HRgion定位中,如果能在本地缓存中的找到地址,就直接使用该地址提升性能。

 

6.理解并描述Hbase的三级寻址。

(1)寻找RegionServer
ZooKeeper–> -ROOT-(单Region)–> .META.–> 用户表
(2)-ROOT-表
表包含.META.表所在的region列表，该表只会有一个Region；
Zookeeper中记录了-ROOT-表的location。
(3).META.表
表包含所有的用户空间region列表，以及RegionServer的服务器地址。

　　HBase通过三级索引结果实现region的寻址。我们逆序描述这个设计的思路，HBase的所有数据region元数据被存储在.META.表中，但是随着region增多，显然.META.会越大越大，最终也会分裂成多个region；-ROOT-表实现定位.META.表的region的位置，保存.META.表中所有region的元数据。而且-ROOT-不会分裂，只有一个region。Zookeeper会记录-ROOT-表的位置信息。

 　　我们在正序描述寻址过程，Client通过ZK找到-ROOT-表的位置，通过-ROOT-表查找到.META.的位置，再从.META.查找用户Region的位置。可以实现最多三次跳转就可以定位任意一个region的效果。为了加快访问速度，.META.表的所有Region全部保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。

 

7.假设.META.表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为2GB，通过HBase的三级寻址方式，理论上Hbase的数据表最大有多大？
　　（-ROOT-表能够寻址的.META.表的Region个数）×（每个.META.表的 Region可以寻址的用户数据表的Region个数）:一个-ROOT-表最多只能有一个Region，也就是最多只能有128MB，按照每行（一个映射条目）占用1KB内存计算，128MB空间可以容纳128MB/1KB=2^{17}行，也就是说，一个-ROOT-表可以寻址2^{17}个.META.表的Region。同理，每个.META.表的 Region可以寻址的用户数据表的Region个数是128MB/1KB=2^{17}。最终，三层结构可以保存的Region数目是(128MB/1KB) × (128MB/1KB) = 2^{34}个Region
　　客户端访问数据时的“三级寻址”：为了加速寻址，客户端会缓存位置信息，同时，需要解决缓存失效问题；寻址过程客户端只需要询问Zookeeper服务器，不需要连接Master服务器。