第四次作业

1.用图与自己的话，简要描述Hadoop起源与发展阶段

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

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

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.用图与自己的话，简要描述名称节点、数据节点的主要功能及相互关系、名称节点的工作机制。

1、HDFS 采用主/从架构，主节点即NameNode 从节点即：DataNode

2、NameNode即是模式， 并完成外模式和模式之间的映像，模式和内模式之间的映像。

3、NameNode存放HDFS全局命名空间，充当全局数据目录；存储全局文件系统树，目录-文件-文件块信息

NameNode存放的数据块信息是在启动时扫描所有数据节点重构；

在运行过程中周期性受到数据节点发送的数据块列表信息重构而得；

4、在客户端读取数据过程中，将数据块和数据节点映射按远近排序列表发送给客户端；

5、在客户端写数据过程中，检查文件是否存在、是否有权限；将待写入文件分成若干文件块，并根据数据节点的繁忙和磁盘容量程度，分配数据块和数据节点对应关系列表反馈给客户端；

6、HDFS文件块默认是64M,普通文件块的大小为521字节；

相互关系：

名称节点管理文件系统的命名空间。它维护着这个文件系统树及这个树内所有的文件和索引目录。这些信息以两种形式将文件永久保存在本地磁盘上：命名空间镜像和编辑日志。名称节点也记录着每个文件的每个块所在的数据节点，但它并不永久保存块的位置，因为这些信息会在系统启动时由数据节点重建。

名称结点的工作机制：

名称节点启动时，会将FsImage的内容加载到内存当中，然后执行EditLog文件中的各项操作，使得内存中的元数据保存最新。这个操作完成后，就会创建一个新的FsImage文件和一个空的EditLog文件。名称节点启动成功并进入正常运行状态以后，HDFS中的更新操作都会被写入到EditLog，而不是直接写入FsImage

3.分别从以下这些方面，梳理清楚HDFS的 结构与运行流程，以图的形式描述。

客户端与HDFS

客户端读

客户端写

数据结点与集群

数据结点与名称结点

名称结点与第二名称结点

数据结点与数据结点

数据冗余

数据存取策略

数据错误与恢复

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

• Master主服务器的功能
• Region服务器的功能。
• Zookeeper协同的功能.
• Client客户端的请求流程
• 四者之间的相系关系
• 与HDFS的关联

 

 

(1）Master主服务器的功能

管理用户对Table表的增、删、改、查操作；

管理HRegion服务器的负载均衡，调整HRegion分布； 

(2）Region服务器的功能

HRegion部分由很多的HRegion组成，存储的是实际的数据。每一个HRegion又由很多的Store组成，每一个Store存储的实际上是一个列簇（ColumnFamily）下的数据。 

(3）Zookeeper协同的功能

zookeeper是hbase集群的"协调器"。由于zookeeper的轻量级特性，因此我们可以将多个hbase集群共用一个zookeeper集群，以节约大量的服务器.

(4）Client客户端的请求流程

Client请求Zookeeper确定meta表所在的RegionServer所在的地址，接着根据Rowkey找到数据所归属的RegionServer；用户提交put或delete请求时HbaseClient会将put或delete请求添加到本地buffer中，符合一定条件会通过异步批量提交服务器处理。

(5）与HDFS的关联

HDFS是GFS的一种实现，他的完整名字是分布式文件系统，类似于FAT32，NTFS，是一种文件格式，是底层的，Hadoop HDFS为HBase提供了高可靠性的底层存储支持。

HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统

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

 

 

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

客户端首先访问Zookeeper，获取-ROOT-表的位置信息------->访问-ROOT-表，获取.META.表的文位置信息---------->访问.META.表，找到所需的Region位于哪个服务器，然后到该服务器读取数据

RegionServer维护Master分配给它的region，处理对这些region的IO请求,负责切分在运行过程中变得过大的region, 由于集群性能（ 分配的内存和磁盘是有限的 ）有限的，那么HBase单个RegionServer的region数目肯定是有上限的。

 

7.通过HBase的三级寻址方式，理论上Hbase的数据表最大有多少个Region

Region数目上限

     RegionServer的region数目取决于memstore的内存使用，每个region拥有一组memstore（memstore的数量有hstore决定，hstore的数据由创建表时的指定的列族个数决定，所以 每个region的memstore的个数 = 表的列族的个数 ），可以通过配置来修改memstore占用内存的大小，一般设置在  128 M – 256M之间。

     RegionServer 分配一定比例的内存给它下面的所有memstore( 该比例大小 可通过hbase.regionserver.global.memstore.upperLimit 进行修改 ), 如果内存溢出（使用了太多的memstore），它可能会导致严重的后果，如服务器反应迟钝 或compact风暴。比较好的计算每RS（假设一个表）region的数量的公式为：

((RS memory) * (total memstore fraction)) / ((memstore size)*(# column families))

 

 例如： 如果 一个RegionServer配置的内存是16g,使用默认配置（ hbase默认regionserver分给memstore的比例是0.4 ， 默认的menstore的占用128M内存 ）， 一个CF，那么这个regionServer下的region的个数大约为  16384 * 0.4 / （128*1） = 51个，实际测试大于这个数 一两倍 也没太大的问题。 一个HBase表包含一至多个region，那么表的数目上限也是可以估算出来的。

 

Region大小上限

　　　对于生产场景中大表，最大的region大小主要是受compactions 的限制，大量大HFile的compact会降低群集性能。目前，该建议的最大region大小为10-20GB，而5-10GB是最优