1.用图与自己的话，简要描述Hadoop起源与发展阶段。
Hadoop是道格·卡丁（Doug Cutting）创建的，Hadoop起源于开源网络搜索引擎Apache Nutch，后者本身也是Lucene项目的一部分。Nutch项目面世后，面对数据量巨大的网页显示出了架构的灵活性不够。当时正好借鉴了谷歌分布式文件系统，做出了自己的开源系统NDFS分布式文件系统。第二年谷歌又发表了论文介绍了MapReduce系统，Nutch开发人员也开发出了MapReduce系统。随后NDFS和MapReduce命名为Hadoop，成为了Apache顶级项目。
从Hadoop的发展历程来看，它的思想来自于google的三篇论文。
GFS：Google File System 分布式处理系统 ------》解决存储问题
Mapreduce：分布式计算模型 ------》对数据进行计算处理
BigTable：解决查询分布式存储文件慢的问题，把所有的数据存入一张表中，通过牺牲空间换取时间
2.用图与自己的话，简要描述名称节点、第二名称节点、数据节点的主要功能及相互关系。
在HDFS中，名称节点（NameNode）负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即FsImage和EditLog
第二名称节点（SecondaryNameNode）：是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的定位,继续读写操作.
6.理解并描述Hbase的三级寻址。
第 1 步：Client 请求 ZooKeeper 获取.META.所在的 RegionServer 的地址。
第 2 步：Client 请求.META.所在的 RegionServer 获取访问数据所在的 RegionServer 地址，Client
会将.META.的相关信息 cache 下来，以便下一次快速访问。
第 3 步：Client 请求数据所在的 RegionServer，获取所需要的数据。
7.假设.META.表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为2GB，通过HBase的三级寻址方式，理论上Hbase的数据表最大有多大？
计算方法是：（-ROOT-表能够寻址的。META.表的Region个数)×（每个.META.表的Region可以寻址的用户数据表的Region个数），一个-ROOT-表只能由一个Region，也就似乎最多只能有2GB(2048MB),按照每行（一个映射条目)占用1KB内存计算，2GB空间可以容纳2048MB/1KB=2048行，也就是说一个-ROOT-表可以寻址2048个.META.表的Region
最终三层结构可以保存的Region的数目是：
一个-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
8.MapReduce的架构，各部分的功能，以及和集群其他组件的关系。
一句话——整体依旧主从构，map加redu（reduce简写）。 map、split入磁盘，数据对分partition。shuffle、sort、key-value，一个redu（reduce）一 tion（partition）透。注：最后一句，一个reduce解析一个partition。
一堆话——如下：
和HDFS一样，MapReduce也是采用Master/Slave的架构，其架构如下图所示：
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 执行过程下图所示。该过程分为三个阶段：
- 从远程节点上读取Map Task 中间结果（称为"Shuffle 阶段"）；
- 按照key 对key/value 对进行排序（称为"Sort 阶段"）；
- 依次读取< key, value list>，调用用户自定义的reduce() 函数处理，并将最终结果存到HDFS 上（称为"Reduce 阶段"）
9.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获取某一分区的数据
8. Merge阶段。复制过来数据会先放到内存缓冲区中，当内存中的数据达到一定阈值时，就会启动内存到磁盘的Merge。与Map端类似，这也是溢写过程，会在磁盘中形成众多的溢写文件，由于一个split对应一个Map，Reduce端是从多个Map中拉取数据，所以也需要进行归并排序，成为一个有序的文件，最终每个相同的key分为一组执行一次Reduce方法
9. Reducer的输出文件。不断地进行Merge后，最后会生成一个“最终文件”。这个文件可能存放在磁盘，也可能存放在内存中，默认存放在磁盘上。当Reducer的输入文件已定时，整个Shuffle过程才最终结束