第四次作业

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

Hadoop最早起源于Nutch。Nutch的设计目标是构建一个大型的全网搜索引擎，包括网页抓取、索引、查询等功能，但随着抓取网页数量的增加，遇到了严重的可扩展性问题——如何解决数十亿网页的存储和索引问题。
2003年、2004年谷歌发表的两篇论文为该问题提供了可行的解决方案。
——分布式文件系统（GFS），可用于处理海量网页的存储
——分布式计算框架MAPREDUCE，可用于处理海量网页的索引计算问题。
Nutch的开发人员完成了相应的开源实现HDFS和MAPREDUCE，并从Nutch中剥离成为独立项目HADOOP，到2008年1月，HADOOP成为Apache顶级项目(同年，cloudera公司成立)，迎来了它的快速发展期。
狭义上来说，hadoop就是单独指代hadoop这个软件，
广义上来说，hadoop指代大数据的一个生态圈，包括很多其他的软件

 

2.用图与自己的话，简要描述名称节点、数据节点的主要功能及相互关系、名称节点的工作机制。

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

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

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

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

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

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

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

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

相互关系：

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

名称结点的工作机制：

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

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的关系.

  当在进行HBase表的读写操作时，需要先根据表名 和 行键确 定位到HRegion，这个过程就是HRegion的寻址过程。

  HRgion的寻址过程首先由客户端开始，访问zookeeper 得到其中meta-region-server的值,根据该值找到唯一持有meta表的HRegion所在的HRegionServer,得到meta表,从中读取真正要查询的表和行键 对应的HRgion的地址,再根据该地址,找到真正的操作的HRegionServer和HRegion,完成HRgion的定位,继续读写操作.
  

   

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

  现在假设我们要从Table2里面查询一条RowKey是RK10000的数据。那么我们应该遵循以下步骤：
  1. 从.META.表里面查询哪个Region包含这条数据。
  2. 获取管理这个Region的RegionServer地址。
  3. 连接这个RegionServer, 查到这条数据。

  系统如何找到某个row key (或者某个 row key range)所在的region
  bigtable 使用三层类似B+树的结构来保存region位置。
  第一层： 保存zookeeper里面的文件，它持有root region的位置。
  第二层：root region是.META.表的第一个region其中保存了.META.表其它region的位置。通过root region，我们就可以访问.META.表的数据。
  第三层： .META.表它是一个特殊的表，保存了hbase中所有数据表的region 位置信息。

   

  7.假设.META.表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为2GB，通过HBase的三级寻址方式，理论上Hbase的数据表最大有多大？

  （-ROOT-表能够寻址的.META.表的Region个数）×（每个.META.表的Region可以寻址的用户数据表的Region个数）

  •一个-ROOT-表最多只能有一个Region，也就是最多只能有128MB，按照每行（一个映射条目）占用1KB内存计算，128MB空间可以容纳128MB/1KB=217行，也就是说，一个-ROOT-表可以寻址217个.META.表的Region。

  •同理，每个.META.表的Region可以寻址的用户数据表的Region个数是128MB/1KB=217。