第四次作业
（三）熟悉Hadoop及其操作
1.用图文与自己的话，简要描述Hadoop起源与发展阶段。
2.用图与自己的话，简要描述名称节点、第二名称节点、数据节点的主要功能及相互关系。
1、什么是Hadoop?
(1)Hadoop是一个开源的框架，可编写和运行分布式应用处理大规模数据，是专为离线和大规模数据分析而设计的，并不适合那种对几个记录随机读写的在线事务处理模式。Hadoop=HDFS(文件系统，数据存储技术相关)+ Mapreduce(数据处理)，Hadoop的数据来源可以是任何形式，在处理半结构化和非结构化数据上与关系型数据库相比有更好的性能，具有更灵活的处理能力。
Hadoop是Apache Lucene创始人 Doug Cutting 创建的。最早起源于Nutch，它是Lucene的子项目。Nutch的设计目标是构建一个大型的全网搜索引擎，包括网页抓取、索引、查询等功能，但随着抓取网页数量的增加，遇到了严重的可扩展性问题：如何解决数十亿网页的存储和索引问题。
2003年Google发表了一篇论文为该问题提供了可行的解决方案。论文中描述的是谷歌的产品架构，该架构称为：谷歌分布式文件系统（GFS）,可以解决他们在网页爬取和索引过程中产生的超大文件的存储需求。
2004年 Google发表论文向全世界介绍了谷歌版的MapReduce系统。
同时期，以谷歌的论文为基础，Nutch的开发人员完成了相应的开源实现HDFS和MAPREDUCE，并从Nutch中剥离成为独立项目HADOOP，到2008年1月，HADOOP成为Apache顶级项目，迎来了它的快速发展期。
2.用图与自己的话，简要描述名称节点、第二名称节点、数据节点的主要功能及相互关系。
链接：https://zhuanlan.zhihu.com/p/350829188
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
一、名称节点（NameNode）
1.什么是名称节点
在HDFS中，名称节点负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构-FsImage和EditLog。
- FsImage：用于维护文件系统树以及文件树中所有的文件和文件夹的元数据。
- EditLog：中记录所有针对文件创建、删除、重命名等操作的日志文件。
名称节点记录了每个文件中各个块所在的数据节点的位置信息，但并不持久化存储这些信息，而是在系统每次启动时扫描所有数据节点重构得到这些信息。
2.名称节点工作过程
名称节点启动时，会将FsImage的内容加载到内存当中，然后执行EditLog文件中的各项操作，使得内存中的元数据保存最新。这个操作完成后，就会创建一个新的FsImage文件和一个空的EditLog文件。名称节点启动成功并进入正常运行状态以后，HDFS中的更新操作都会被写入到EditLog，而不是直接写入FsImage（文件大，直接写入系统会变慢）。
名称节点在启动的过程中处于“安全模式”，只能对外提供读操作。启动结束后，则进入正常运行状态，对外提供读写操作。
二、第二名称节点（Secondary NameNode）
1.功能
在名称节点运行期间，EditLog文件由于操作不断发生会逐渐变大，为解决逐渐变大带来的问题，故采用了第二名称节点。
- 可以完成EditLog与FsImage的合并操作，减少EditLog文件大小，缩短名称节点重启时间
- 作为名称节点的“检查点”，保存名称节点中的元数据信息。
2.工作过程
- SecondaryNameNode会定期和NameNode通信，请求其停止使用EditLog文件，暂时将新的写操作写到一个新的文件edit.new上来，这个操作是瞬间完成，上层写日志的函数完全感觉不到差别。
- SecondaryNameNode通过HTTP GET方式从NameNode上获取到FsImage和EditLog文件，并下载到本地的相应目录下。
- SecondaryNameNode将下载下来的FsImage载入到内存，然后一条一条地执行EditLog文件中的各项更新操作，使得内存中的FsImage保持最新；这个过程就是EditLog和FsImage文件合并。
- SecondaryNameNode执行完（3）操作之后，会通过post方式将新的FsImage文件发送到NameNode节点。
- NameNode将从SecondaryNameNode接收到的新的FsImage替换旧的FsImage文件，同时将edit.new替换EditLog文件，通过这个过程EditLog就变小了。
三：分别从以下这些方面，梳理清楚HDFS的 结构与运行流程，以图的形式描述。
- 客户端与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的定位,继续读写操作.6.理解并描述Hbase的三级寻址。
现在假设我们要从Table2里面查询一条RowKey是RK10000的数据。那么我们应该遵循以下步骤：
1. 从.META.表里面查询哪个Region包含这条数据。
2. 获取管理这个Region的RegionServer地址。
3. 连接这个RegionServer, 查到这条数据。7.假设.META.表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为2GB，通过HBase的三级寻址方式，理论上Hbase的数据表最大有多大？
一个-ROOT-表最多只能有一个Region，也就是最多只能有2GB，按照每行（一个映射条目）占用1KB内存计算，2GB空间可以容纳2GB/1KB=2的21次方行，也就是说，一个-ROOT-表可以寻址2的21次方个.META.表的Region。同理，每个.META.表的 Region可以寻址的用户数据表的Region个数是2GB/1KB=2的21次方。最终，三层结构可以保存的Region数目是(2GB/1KB) × (2GB/1KB) = 2的42次方个Region
-
MapReduce
1. MapReduce的架构，各部分的功能，以及和集群其他组件的关系。
MapReduce包含四个组成部分，分别为Client，JobTracker，TaskTracker，Task。
a）client客户端
每一个Job都会在用户端通过Client类将应用程序以及参数配置Configuration打包成Jar文件存储在HDFS，并把路径提交到JobTracker的master服务，然后由master创建每一个Task（即MapTask和ReduceTask），将它们分发到各个TaskTracker服务中去执行。
b）JobTracker
JobTracker负责资源监控和作业调度。JobTracker监控所有的TaskTracker与job的健康状况，一旦发现失败，就将相应的任务转移到其它节点；同时JobTracker会跟踪任务的执行进度，资源使用量等信息，并将这些信息告诉任务调度器，而调度器会在资源出现空闲时，选择合适的任务使用这些资源。在Hadoop中，任务调度器是一个可插拔的模块，用于可以根据自己的需要设计相应的调度器。
c）TaskTracker
TaskTracker会周期性地通过HeartBeat将本节点上资源的使用情况和任务的运行进度汇报给JobTracker，同时执行JobTracker发送过来的命令 并执行相应的操作（如启动新任务，杀死任务等）。TaskTracker使用“slot”等量划分本节点上的资源量。“slot”代表计算资源（cpu，内存等） 。一个Task获取到一个slot之后才有机会运行，而Hadoop调度器的作用就是将各个TaskTracker上的空闲slot分配给Task使用。slot分为MapSlot和ReduceSlot两种，分别提供MapTask和ReduceTask使用。TaskTracker通过slot数目（可配置参数）限定Task的并发度。
d）Task
Task分为MapTask和Reduce Task两种，均由TaskTracker启动。HDFS以固定大小的block为基本单位存储数据，而对于MapReduce而言，其处理单位是split。split是一个逻辑概念，它只包含一些元数据信息，比如数据起始位置、数据长度、数据所在节点等。它的划分方法完全由用户自己决定。但需要注意的是，split的多少决定了MapTask的数目，因为每一个split只会交给一个MapTask处理。split与block的关系如下图：
MapTask的执行过程如下图所示：由下图可知，Map Task 先将对应的split迭代解析成一个个key-value对，依次调用用户自定义的map()函数进行处理，最终将临时结果存放到本地磁盘上。其中，临时数据被分成若干个partition，每个partition将被一个Reduce Task处理。
Reduce Task 的执行过程如下图所示。该过程分为三个阶段：
(1)从远程节点上读取Map Task中间结果（称为“Shuffle 阶段”）
(2) 按照 key 对 key-value 对进行排序（称为 “Sort 阶段”）
(3) 依次读取< key， value list >，调用用户自定义的Reduce函数处理，并将最终结果存到HDFS上（称为“Reduce阶段”）过程如下图：
2. MapReduce的工作过程，用自己词频统计的例子，将split, map, partition,sort,spill,fetch,merge reduce整个过程梳理并用图形表达出来。
从整体上，MapReduce框架可以分为五个不同实体：
客户端：提交 MapReduce job
Yarn 资源管理器（ResouceManager）：协调集群计算资源的分配。包含主要的组件：定时调用器(Scheduler)以及应用管理器(ApplicationManager)。
定时调度器(Scheduler)：从本质上来说，定时调度器就是一种策略。当 Client 提交一个任务的时候，它会根据所需要的资源以及当前集群的资源状况进行分配。
应用管理器(ApplicationManager)：应用管理器就是负责管理 Client 用户提交的应用。监控应用的工作正是由应用管理器（ApplicationManager）完成的。
Yarn 节点管理器（NodeManager）：启动和监视集群中每个节点的计算容器，并监控它们的资源使用情况（cpu，内存，磁盘及网络等），以及向 ResourceManager/Scheduler 提供这些资源使用报告。
Mapreduce 应用管理器（Application Master）：负责调度Mapreduce任务。应用管理器和 MapReduce 任务是运行在容器中的，这个容器是由资源管理器分配的，并且接受阶段管理器的管理。
分布式文件系统（通常为HDFS）
客户端提交job给 ApplicationManager 连接NodeManager去申请一个Container的容器，这个容器运行作业的ApplicationMaster的主程序，启动后向ApplicationManager进行注册，然后ApplicationMaster向ResourceManager申请资源，申请job的提交资源staging-dir，还会拿到ResourceManager为这个job产生的jobId，并把staging-dir和jobId合并在一起形成特定路径。然后客户端再把这些资源提交到HDFS相应的路径下面。随后，Yarn框架会把本次job所要用到的资源放到一个任务队列里面描述出来，拿到一个资源的列表，和对应的NodeManager进行通信，启动对应的Container容器，运行 ReduceTask和MapTask ，它们是向ApplicationMaster进行汇报它们的运行状态， 当所有作业运行完成后还需要向ApplicationManager进行汇报并注销和关闭，这时所有资源会回收。
Map端流程：
由程序内的InputFormat(默认实现类TextInputFormat)来读取外部数据，它会调用RecordReader(它的成员变量)的read()方法来读取，返回k,v键值对。map每次读取split的数据（一行一行的读取）。
读取的k,v键值对传送给map()方法，作为其入参来执行用户定义的map逻辑。
context.write方法被调用时，outputCollector组件会将map()方法的输出结果写入到环形缓冲区内。
环形缓冲区其实就是一个数组，后端不断接受数据的同时，前端数据不断被溢出，长度用完后读取的新数据再从前端开始覆盖。
spiller组件会从环形缓冲区溢出文件，这过程会按照定义的partitioner分区(默认是hashpartition)，并且按照key.compareTo进行排序(快速排序、外部排序)，若有combiner也会执行combiner。spiller的不断工作，会不断溢出许多小文件。这些文件仍在map task所处机器上。
小文件执行merge(合并)，行程分区且区内有序的大文件(归并排序，会再一次调用combiner)。
Reduce会根据自己的分区，去所有map task中，从文件读取对应的数据。
Reduce端流程：
1.Copy过程。每个ReduceTask不断地通过RPC（HTTP协议）从ResourceManager获取MapTask是否完成信息。如果ReduceTask获知AppMaster上的MapTask执行完成，那么Shuffler的后半段过程开始启动。Reduce task通过网络向Map task获取某一分区的数据
2.Merge阶段。复制过来数据会先放到内存缓冲区中，当内存中的数据达到一定阈值时，就会启动内存到磁盘的Merge。与Map端类似，这也是溢写过程，会在磁盘中形成众多的溢写文件，由于一个split对应一个Map，Reduce端是从多个Map中拉取数据，所以也需要进行归并排序，成为一个有序的文件，最终每个相同的key分为一组执行一次Reduce方法
3.Reducer的输出文件。不断地进行Merge后，最后会生成一个“最终文件”。这个文件可能存放在磁盘，也可能存放在内存中，默认存放在磁盘上。当Reducer的输入文件已定时，整个Shuffle过程才最终结束
