第四次作业

1.用图与自己的话，简要描述Hadoop起源与发展阶段。（作业3中剪过来）

Hadoop源自2002年Apache Nutch——一个开源的网络搜索引擎，并且也是APACHE lUCENE 项目的一部分，2003年谷歌公司发布了分布式文件GFS方面的论文，解决了大规模数据存储的问题；2004年Apache Nutch项目模仿GFS开发了自己的文件系统，也就是HDFS的前身；2008年Hadoop正式成为Apache顶级项目并成为最快排序1TB数据的系统，自此Hadoop发展成大数据时代最具有影响力的开源分布式开发平台，成为事实上的大数据标准。

 

 

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

名称节点主要负责管理分布式文件系统的命名空间，保存了两个核心的数据结构，如FsImage和EditLog。名称节点记录了每个文件中各个块所在的数据节点的位置信息，但是并不持久的保存这些信息，而是在系统每次启动时扫描所有数据节点并重构得到这些信息。

第二名称节点是HDFS架构的一个重要组成部分，具有两个方面的功能：首先，可以完成EditLog与FsImage的合并操作，减小EditLog文件大小，缩短名称节点重启时间；其次，可以作为名称节点的“检查点”，保存名称节点中的元数据信息。

数据节点：主要是存储索引数据的节点，主要对文档进行增删改查操作，聚合操作等。 配置文件定义：node.master: false node.data: true

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

• 客户端与HDFS
• 客户端读
• 客户端写
• 数据结点与集群
• 数据结点与名称结点
• 名称结点与第二名称结点
• 数据结点与数据结点
• 数据冗余
• 数据存取策略

•  

   

   

  4.梳理HBase的结构与运行流程，以用图与自己的话进行简要描述。

  • Master主服务器的功能

  • 主从服务优势：

    好处一：实现服务器负载均衡。通过服务器复制功能，可以在主服务器和从服务器之间实现负载均衡。

    好处二：通过复制实现数据的异地备份。可以定期的将数据从主服务器上复制到从服务器上，这无疑是先了数据的异地备份。

    好处三：提高数据库系统的可用性 。数据库复制功能实现了主服务器与从服务器之间数据的同步，增加了数据库系统的可用性。当主服务器出现问题时，数据库管理员可以马上让从服务器作为主服务器，用来数据的更新与查询服务。然后回过头来再仔细的检查主服务器的问题。

  • Region服务器的功能
  • 1 Region server维护Master分配给它的region，处理对这些region的IO请求
    2 Region server负责切分在运行过程中变得过大的region
    可以看到，client访问hbase上数据的过程并不需要master参与（寻址访问zookeeper和region server，数据读写访问regione server），master仅仅维护者table和region的元数据信息，负载很低
  • Zookeeper协同的功能
  • 1 保证任何时候，集群中只有一个master
    2 存贮所有Region的寻址入口—-root表在哪台服务器上。
    3 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master
    4 存储Hbase的schema,包括有哪些table，每个table有哪些column family
  • Client客户端的请求流程
  • 包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。
  • 与HDFS的关联
  • HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据。
    HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和failover机制。Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。 Sqoop则为HBase提供了方便的RDBMS（关系型数据库）数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。
  • HBase读数据流程：
  • 

     

     HBase写数据流程：

  • 

     

     

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

• HBase通过三级索引结果实现region的寻址。我们逆序描述这个设计的思路，HBase的所有数据region元数据被存储在.META.表中，但是随着region增多，显然.META.会越大越大，最终也会分裂成多个region；-ROOT-表实现定位.META.表的region的位置，保存.META.表中所有region的元数据。而且-ROOT-不会分裂，只有一个region。  hbase的客户端不同行为，导致了region的不同状态的变迁。  Region 的状态变迁，会涉及master、zookeeper和Regionserver三个组件，其中Region的状态会存在master和meta和zk中维护。 

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

• 第 1 步：Client 请求 ZooKeeper 获取.META.所在的 RegionServer 的地址。
  第 2 步：Client 请求.META.所在的 RegionServer 获取访问数据所在的 RegionServer 地址，Client
  会将.META.的相关信息 cache 下来，以便下一次快速访问。
  第 3 步：Client 请求数据所在的 RegionServer，获取所需要的数据。

• 系统如何找到某个row key 所在的region，bigtable 使用三层类似B+树的结构来保存region位置。

  第一层： 保存zookeeper里面的文件，它持有root region的位置。
  第二层：root region是.META.表的第一个region其中保存了.META.表其它region的位置。通过root region，我们就可以访问.META.表的数据。
  第三层： .META.表它是一个特殊的表，保存了hbase中所有数据表的region 位置信息。

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

• 假设，.META.表的一行在内存中大约占用1KB。并且每个region限制为2048MB（2G）。

  那么上面的三层结构可以保存的region数目为：

  (2048MB/1KB) * (2048MB/1KB) =  2^35个region

  Client会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的region(其中三次用来发现缓存失效，另外三次用来获取位置信息)。

   

  8.MapReduce的架构，各部分的功能，以及和集群其他组件的关系。

• 1）Client：
  用户编写的Mapreduce程序通过Client提交到JobTracker端；同时，用户可通过Client提供的一些接口查看作业运行状态。在Hadoop内部用“作业”（Job）表示Mapreduce程序。
• 2）JobTracker：
  JobTracker主要负责资源监控和作业调度。JobTracker监控所有TaskTracker与作业的健康状况，一旦发现失败情况后，会将 相应的任务转移到其他节点；同时，JobTracker会跟踪任务的执行进度、资源使用量等信息，并将这些信息告诉任务调度器，而调度器会在资源出现空闲时，选择合适的任务使用这些资源。
• 3）TaskTracker：
  TaskTracker会周期性的通过Heartbeat将本节点上资源的使用情况和任务的运行进度汇报给JobTracker，同时接收JobTracker发送过来的命令并执行相应的操作（如启动新任务、杀死任务等）。TaskTracker使用“slot”等量划分本节点上的资源量。
• 4）Task：
  Task分为Map Task和Reduce Task两种，均由TaskTracker启动。从上篇HDFS文档中知道，HDFS以固定大小的block为基本单位存储数据，而对于Mapreduce而言，其处理单位是split。split是一个逻辑概念，它只包含一些元数据信息，比如数据起始位置、数据长度、数据所在节点等

• 9.MapReduce的工作过程，用自己词频统计的例子，将split, map, partition,sort,spill,fetch,merge reduce整个过程梳理并用图形表达出来。

  

   

  

   

   

• 客户端（Client）：编写mapreduce程序，配置作业，提交作业，这就是程序员完成的工作；
• 向JobTracker请求一个Job ID；

• 将运行作业所需要的资源文件复制到HDFS上，包括MapReduce程序打包的JAR文件、配置文件和客户端计算所得的输入划分信息。这些文件都存放在JobTracker专门为该作业创建的文件夹中。文件夹名为该作业的Job ID。JAR文件默认会有10个副本（mapred.submit.replication属性控制）；输入划分信息(Split)告诉了JobTracker应该为这个作业启动多少个map任务等信息。

• JobTracker接收到作业后，将其放在一个作业队列里(一般来说，公司部门都与自己的队列，默认的调度方法是FIFO，也就是first in first out-队列)，等待作业调度器对其进行调度，当作业调度器根据自己的调度算法调度到该作业时，会根据输入划分信息(Split)为每个划分创建一个map任务，并将map任务分配给TaskTracker执行。

• TaskTracker每隔一段时间会给JobTracker发送一个心跳，告诉JobTracker它依然在运行，同时心跳中还携带着很多的信息，比如当前map任务完成的进度等信息。当JobTracker收到作业的最后一个任务完成信息时，便把该作业设置成“成功”。当JobClient查询状态时，它将得知任务已完成，便显示一条消息给用户。