第四次作业
1.用图与自己的话，简要描述Hadoop起源与发展阶段。
2003-2004年，Google公布了部分GFS和MapReduce思想的细节，受此启发的Doug Cutting等人用2年的业余时间实现了DFS和MapReduce机制，使Nutch性能飙升。然后Yahoo招安Doug Gutting及其项目。
2005年，Hadoop作为Lucene的子项目Nutch的一部分正式引入Apache基金会。
2006年2月被分离出来，成为一套完整独立的软件，起名为Hadoop
Hadoop名字不是一个缩写，而是一个生造出来的词。是Hadoop之父Doug Cutting儿子毛绒玩具象命名的。
Hadoop的成长过程
Lucene–>Nutch—>Hadoop
总结起来，Hadoop起源于Google的三大论文
GFS：Google的分布式文件系统Google File System
MapReduce：Google的MapReduce开源分布式并行计算框架
BigTable：一个大型的分布式数据库
演变关系
GFS—->HDFS
Google MapReduce—->Hadoop MapReduce
BigTable—->HBase
Hadoop大事记
2004年— 最初的版本(现在称为HDFS和MapReduce)由Doug Cutting和Mike Cafarella开始实施。
2005年12月— Nutch移植到新的框架，Hadoop在20个节点上稳定运行。
2006年1月— Doug Cutting加入雅虎。
2006年2月— Apache Hadoop项目正式启动以支持MapReduce和HDFS的独立发展。
2006年2月— 雅虎的网格计算团队采用Hadoop。
2006年4月— 标准排序(10 GB每个节点)在188个节点上运行47.9个小时。
2006年5月— 雅虎建立了一个300个节点的Hadoop研究集群。
2006年5月— 标准排序在500个节点上运行42个小时(硬件配置比4月的更好)。
2006年11月— 研究集群增加到600个节点。
2006年12月— 标准排序在20个节点上运行1.8个小时，100个节点3.3小时，500个节点5.2小时，900个节点7.8个小时。
2007年1月— 研究集群到达900个节点。
2007年4月— 研究集群达到两个1000个节点的集群。
2008年4月— 赢得世界最快1TB数据排序在900个节点上用时209秒。
2008年7月— 雅虎测试节点增加到4000个
2008年9月— Hive成为Hadoop的子项目
2008年11月— Google宣布其MapReduce用68秒对1TB的程序进行排序
2008年10月— 研究集群每天装载10TB的数据。
2008年— 淘宝开始投入研究基于Hadoop的系统–云梯。云梯总容量约9.3PB，共有1100台机器，每天处理18000道作业，扫描500TB数据。
2009年3月— 17个集群总共24 000台机器。
2009年3月— Cloudera推出CDH（Cloudera’s Dsitribution Including Apache Hadoop）
2009年4月— 赢得每分钟排序，雅虎59秒内排序500 GB(在1400个节点上)和173分钟内排序100 TB数据(在3400个节点上)。
2009年5月— Yahoo的团队使用Hadoop对1 TB的数据进行排序只花了62秒时间。
2009年7月— Hadoop Core项目更名为Hadoop Common;
2009年7月— MapReduce 和 Hadoop Distributed File System (HDFS) 成为Hadoop项目的独立子项目。
2009年7月— Avro 和 Chukwa 成为Hadoop新的子项目。
2009年9月— 亚联BI团队开始跟踪研究Hadoop
2009年12月—亚联提出橘云战略，开始研究Hadoop
2010年5月— Avro脱离Hadoop项目，成为Apache顶级项目。
2010年5月— HBase脱离Hadoop项目，成为Apache顶级项目。
2010年5月— IBM提供了基于Hadoop 的大数据分析软件——InfoSphere BigInsights，包括基础版和企业版。
2010年9月— Hive( Facebook) 脱离Hadoop，成为Apache顶级项目。
2010年9月— Pig脱离Hadoop，成为Apache顶级项目。
2011年1月— ZooKeeper 脱离Hadoop，成为Apache顶级项目。
2011年3月— Apache Hadoop获得Media Guardian Innovation Awards 。
2011年3月— Platform Computing 宣布在它的Symphony软件中支持Hadoop MapReduce API。
2011年5月— Mapr Technologies公司推出分布式文件系统和MapReduce引擎——MapR Distribution for Apache Hadoop。
2011年5月— HCatalog 1.0发布。该项目由Hortonworks 在2010年3月份提出，HCatalog主要用于解决数据存储、元数据的问题，主要解决HDFS的瓶颈，它提供了一个地方来存储数据的状态信息，这使得 数据清理和归档工具可以很容易的进行处理。
2011年4月— SGI( Silicon Graphics International )基于SGI Rackable和CloudRack服务器产品线提供Hadoop优化的解决方案。
2011年5月— EMC为客户推出一种新的基于开源Hadoop解决方案的数据中心设备——GreenPlum HD，以助其满足客户日益增长的数据分析需求并加快利用开源数据分析软件。Greenplum是EMC在2010年7月收购的一家开源数据仓库公司。
2011年5月— 在收购了Engenio之后， NetApp推出与Hadoop应用结合的产品E5400存储系统。
2011年6月— Calxeda公司(之前公司的名字是Smooth-Stone)发起了“开拓者行动”，一个由10家软件公司组成的团队将为基于Calxeda即将推出的ARM系统上芯片设计的服务器提供支持。并为Hadoop提供低功耗服务器技术。
2011年6月— 数据集成供应商Informatica发布了其旗舰产品，产品设计初衷是处理当今事务和社会媒体所产生的海量数据，同时支持Hadoop。
2011年7月— Yahoo!和硅谷风险投资公司 Benchmark Capital创建了Hortonworks 公司，旨在让Hadoop更加鲁棒(可靠)，并让企业用户更容易安装、管理和使用Hadoop。
2011年8月— Cloudera公布了一项有益于合作伙伴生态系统的计划——创建一个生态系统，以便硬件供应商、软件供应商以及系统集成商可以一起探索如何使用Hadoop更好的洞察数据。
2011年8月— Dell与Cloudera联合推出Hadoop解决方案——Cloudera Enterprise。Cloudera Enterprise基于Dell PowerEdge C2100机架服务器以及Dell PowerConnect 6248以太网交换机
5.Hadoop的四大特性（优点）
1.扩容能力（Scalable）：Hadoop是在可用的计算机集群间分配数据并完成计算任务的，这些集群可用方便的扩展到数以千计个节点中。
2.成本低（Economical）：Hadoop通过普通廉价的机器组成服务器集群来分发以及处理数据，以至于成本很低。
3.高效率（Efficient）：通过并发数据，Hadoop可以在节点之间动态并行的移动数据，使得速度非常快。
4.可靠性（Rellable）：能自动维护数据的多份复制，并且在任务失败后能自动地重新部署（redeploy）计算任务。所以Hadoop的按位存储和处理数据的能力值得人们信赖。
2.用图与自己的话，简要描述名称节点、数据节点的主要功能及相互关系。
名称节点：负责管理分布式文件系统的命名空间，里面包含了两个核心的数据结构，即FsImage和EditLog。FsImage用户文件树以及所有的文件和文件夹的元数据。EfitLog记录的是文件的增删改查。
首次安装format格式化就是在本地生成FsImage。首次安装format格式化就是在本地生成FsImage。
HDFS的更新都会被写入到FsImage中而不是EditLog，因为对于分布式而言，FsImage非常庞大，直接对FsImage速度非常慢。HDFS的更新都会被写入到FsImage中而不是EditLog，因为对于分布式而言，FsImage非常庞大，直接对FsImage速度非常慢。
数据节点（DataNode）:定期向名称节点发送自己的存储块的列表。数据节点（DataNode）:定期向名称节点发送自己的存储块的列表。
因为HDFS文件会逐渐地变大，不断变大的EditLog文件通常不会对系统文件产生影响，但是当EditLog很大时，使得在HDFS重启时，将EditLog合并到FsImage中的过程十分缓慢，系统长期处于“安全模式”，用户的使用收到影响。
HDFS的第二名称节点（secondary NameNode）的作用：完成EditLog合并到FsImage的过程，缩短合并的重启时间，其次作为“检查点”保存元数据的信息。
3.
分别从以下这些方面，梳理清楚HDFS的结构与运行流程，以图的形式描述。
客户端与HDFS
客户端读
客户端写
数据结点与集群
数据结点与名称结点
名称结点与第二名称结点
数据结点与数据结点
数据冗余
数据存取策略
数据错误与恢复
HDFS结构图：
Secondary Namenode工作图解：
HDFS文件读流程：
HDFS文件写流程：
4.梳理HBase的结构与运行流程，以用图与自己的话进行简要描述，图中包括以下内容：
- Master主服务器的功能
- 为Region server分配region
- 负责Region server的负载均衡
- 发现失效的Region server并重新分配其上的region。
- HDFS上的垃圾文件回收。
- 处理schema更新请求。
- Region服务器的功能
table在行的方向上分隔为多个Region。Region是HBase中分布式存储和负载均衡的最小单元，即不同的region可以分别在不同的Region Server上，但同一个Region是不会拆分到多个server上。
Region按大小分隔，每个表一般是只有一个region。随着数据不断插入表，region不断增大，当region的某个列族达到一个阈值（默认256M）时就会分成两个新的region。
每个region由以下信息标识：
< 表名,startRowkey,创建时间>
由目录表(-ROOT-和.META.)记录该region的endRowkey - Zookeeper协同的功能
- Client客户端的请求流程
- 四者之间的相系关系
- 与HDFS的关联
5.理解并描述Hbase表与Region与HDFS的关系。
一个HBase表由一个或者多个列族（CF）组成，一个列族又包含很多列（限定符，CQ），每列存储相对应的值，和传统的关系型数据库不一样HBase是稀疏表，一些列根本不存值，但是也不会存储null值，且该列不会被添加到表中，一旦一个rowkey及相对应的列值形成了，将会被存储到表中。
Rowkey ： PK 每一条数据的主键
Column Family： 列族 将表进行切割的 简称CF （CF数量尽量不要超过3，过多维护的开销大）
Column ：数据列族
Version Number 类型为Long，默认值为系统时间戳
Value ：
图说明：一行row的数据是可以包含一个或多个CF，不建议设置超过3个。
Column是属于CF，一个CF可以包含1个或多个Column。
Region
HBase 将数据分布存储在多个服务器中，所以表被分割成多个region，每个region将会存储一个指定区间的数据。region将会被分配到RegionServer以服务于每个region的内容。
每个region 都有一个起始健和一个结束键来定义他的边界，所有这些信息将随着文件保存在region中，也会保存在Hbase:meta表中。region可以合并和分裂
物理层面Region：
一个RegionServer管理1个或多个Region；
一个Region管理1个或多个CF（列族）
逻辑层面Region：
表按照rowkey范围划分不同的region，region按列族划分不同的store。
store包含memstore 和 storefile。
建表时默认只有一个region，假如指定spilt rowkey，就会有多个region。
假如 有100w 数据 写到50w的时候 自动split(分裂) ，就形成region2，这时候region2就可以理解为字表，当region的行数继续写达到阈值，region继续分裂。不同的region被HMater分配给合适的HRegionServer管理。
表按照rowkey范围划分不同的region，region按列族划分不同的store。store包含memstore 和 storefile。
6.理解并描述Hbase的三级寻址。
在 HBase-0.96 版本以前，HBase 有两个特殊的表，分别是-ROOT-表和.META.表，其中-ROOT-的位置存储在 ZooKeeper 中，-ROOT-本身存储了.META. Table 的 RegionInfo 信息，并且-ROOT-不会分裂，只有一个 Region。而.META.表可以被切分成多个 Region。
读取的流程如下图所示：
步骤：
第 1 步：Client 请求 ZooKeeper 获得-ROOT-所在的 RegionServer 地址
第 2 步：Client 请求-ROOT-所在的 RS 地址，获取.META.表的地址，Client 会将-ROOT-的相关信息 cache 下来，以便下一次快速访问
第 3 步：Client 请求.META.表的 RegionServer 地址，获取访问数据所在 RegionServer 的地址，Client 会将.META.的相关信息 cache 下来，以便下一次快速访问
第 4 步：Client 请求访问数据所在 RegionServer 的地址，获取对应的数据
从上面的路径我们可以看出，用户需要 3 次请求才能直到用户 Table 真正的位置，这在一定程序带来了性能的下降。在 0.96 之前使用 3 层设计的主要原因是考虑到元数据可能需要很大。但是真正集群运行，元数据的大小其实很容易计算出来。在 BigTable 的论文中，每行METADATA 数据存储大小为 1KB 左右，如果按照一个 Region 为 128M 的计算，3 层设计可以支持的 Region 个数为 2^34 个，采用 2 层设计可以支持 2^17（131072）。那么 2 层设计的情况下一个集群可以存储 4P 的数据。这仅仅是一个 Region 只有 128M 的情况下。如果是 10G呢? 因此，通过计算，其实 2 层设计就可以满足集群的需求。因此在 0.96 版本以后就去掉了-ROOT-表了。
新的 Region 寻址方式
2 层结构其实完全能满足业务的需求，因此 0.96 版本以后将-ROOT-表去掉了。
如下图所示：
1.访问路径变成了 3 步：
第 1 步：Client 请求 ZooKeeper 获取.META.所在的 RegionServer 的地址。
第 2 步：Client 请求.META.所在的 RegionServer 获取访问数据所在的 RegionServer 地址，Client
会将.META.的相关信息 cache 下来，以便下一次快速访问。
第 3 步：Client 请求数据所在的 RegionServer，获取所需要的数据。
简单地说：
从.META.表里面查询哪个Region包含这条数据。
获取管理这个Region的RegionServer地址。
连接这个RegionServer, 查到这条数据。
2.总结去掉-ROOT-的原因有如下 2 点：
其一：提高性能
其二：2 层结构已经足以满足集群的需求
3.系统如何找到某个row key (或者某个 row key range)所在的region bigtable 使用三层类似B+树的结构来保存region位置。
第一层是保存zookeeper里面的文件，它持有root region的位置。
第二层root region是.META.表的第一个region其中保存了.META.表其它region的位置。通过root region，我们就可以访问.META.表的数据。
.META.是第三层，它是一个特殊的表，保存了hbase中所有数据表的region 位置信息。
说明：
1 root region永远不会被split，保证了最需要三次跳转，就能定位到任意region 。
2.META.表每行保存一个region的位置信息，row key 采用表名+表的最后一行编码而成。
3 为了加快访问，.META.表的全部region都保存在内存中。
4 client会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果client上的缓存全部失效，则需要进行最多6次网络来回，才能定位到正确的region(其中三次用来发现缓存失效，另外三次用来获取位置信息)
7.假设.META.表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为2GB，通过HBase的三级寻址方式，理论上Hbase的数据表最大有多大？
一个-ROOT-表最多只能有一个Region，也就是最多只能有2GB，按照每行（一个映射条目）占用1KB内存计算，2GB空间可以容纳2048MB/1KB=2^33行，也就是说，一个-ROOT-表可以寻址2^33个.META.表的Region。
同理，每个.META.表的Region可以寻址的用户数据表的Region个数是2048MB/1KB=2^33
最终，三层结构可以保存的Region数目是(2048MB/1KB)×(2048MB/1KB) = 2^66个Region
1.MapReduce的架构，各部分的功能，以及和集群其他组件的关系。
MapReduce执行步骤：
①用户编写MapReduce程序通过client提交jobtrasker
②jobstrasker开始检查tasktrasker健康情况，将client任务交给暂时空闲的tasktrasker执行
③jobstrasker并将各个tasktrasker工作状态和健康情况发送给taskscheduler
④根据任务情况开始分配资源给map task执行map
shuffle和reduce task 执行reduce
shuffle。
⑤map task向jobstrasker反应数据归并、拆分是否执行完成
⑥reduce task向jobstrasker请求，若map task执行完成，则调用数据进行计算
⑦输出计算结果以HDFS文件格式 。
Shuffler的执行过程
（一）Map
shuffle执行过程
①输入一个个切片split(一般我们默认一个block对应一个split)
②将split数值存入到Map里面，以键值对形式存储
③对map里面的值进行排序
④对map里面的值进行归并
⑤输出一个整合的map
（二）Reduce
shuffle执行过程
①接收各个map整合后的数据
②对各个map里面的相同的K值归并到一起，并对其排序
③调用一个reduce对其归并后的map进行计算
④输出一个计算结果HDFS文件
（三）Shuffler的执行过程
①输入一个个切片split(一般我们默认一个block对应一个split)
②将一个个split数值存入到一个个Map里面，以键值对形式存储
③对各个map里面的值进行排序
④对各个map里面的值进行归并
⑤将不同map里面相同K值归并在一起并排序，形成新的map
⑥调用一个reduce对其归并后的map进行计算
⑦输出一个计算结果HDFS文件
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过程才最终结束
