第四次作业
1.用图与自己的话，简要描述Hadoop起源与发展阶段。
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：解决查询分布式存储文件慢的问题，把所有的数据存入一张表中，通过牺牲空间换取时间。
时间线发展阶段（部分）：
发行版本的描述：
从与谷歌系统的关系，关键时间节点，1.x,2.x与3.x的区别，不同公司发行版本等方面来讲。
Hadoop是一个对海量数据存储和海量数据分析计算的分布式系统。
Hadoop 1.x
海量数据存储 ----> HDFS
海量数据分析计算 ----> MapReduce
Hadoop 2.x 增加
资源调度系统 ----> Yarn
从hadoop最初的原型来看，hadoop已经远远超过了本身的批处理。从广义上来说，hadoop现在可以是指更广泛的一个hadoop生态了，而不仅仅是HDFS，MapReduce和Yarn。例如Hive，Hbase，Flume，Sqoop等等项目都属于这个生态。
从与谷歌系统的关系，关键时间节点，1.x,2.x与3.x的区别，不同公司发行版本等方面来讲：
1.0版本和2.0版本，2011年11月，Hadoop 1.0.0版本正式发布，意味着可以用于商业化。但是，1.0版本中，存在一些问题：
（1）扩展性差，JobTracker负载较重，成为性能瓶颈。
（2）可靠性差，NameNode只有一个，万一挂掉，整个系统就会崩溃。
（3）仅适用MapReduce一种计算方式。
（4）资源管理的效率比较低。
所以，2012年5月，Hadoop推出了 2.0版本 。2.0版本中，在HDFS之上，增加了YARN（资源管理框架）层。它是一个资源管理模块，为各类应用程序提供资源管理和调度。此外，2.0版本还提升了系统的安全稳定性。所以，后来行业里基本上都是使用2.0版本。目前Hadoop又进一步发展到3.X版本。
2.用图与自己的话，简要描述名称节点、第二名称节点、数据节点的主要功能及相互关系。
HDFS集群有两种节点，以管理者-工作者的模式运行，即一个名称节点(管理者)和多个数据节点(工作者)。名称节点管理文件系统的命名空间。它维护着这个文件系统树及这个树内所有的文件和索引目录。这些信息以两种形式将文件永久保存在本地磁盘上：命名空间镜像和编辑日志。名称节点也记录着每个文件的每个块所在的数据节点，但它并不永久保存块的位置，因为这些信息会在系统启动时由数据节点重建。
客户端代表用户通过与名称节点和数据节点交互来访问整个文件系统。客户端提供一个类似POSIX(可移植操作系统界面)的文件系统接口，因此用户在编程时并不需要知道名称节点和数据节点及其功能。
数据节点是文件系统的工作者。它们存储并提供定位块的服务(被用户或名称节点调用时)，并且定时的向名称节点发送它们存储的块的列表。
没有名称节点，文件系统将无法使用。事实上，如果运行名称节点的机器被毁坏了，文件系统上所有的文件都会丢失，因为我们无法知道如何通过数据节点上的块来重建文件。因此，名称节点能够经受故障是非常重要的，Hadoop提供了两种机制来确保这一点。
第一种机制就是复制那些组成文件系统元数据持久状态的文件。Hadoop可以通过配置使名称节点在多个文件系统上写入其持久化状态。这些写操作是具同步性和原子性的。一般的配置选择是，在本地磁盘上写入的同时，写入一个远程NFS挂载(mount)。
另一种可行的方法是运行一个二级名称节点，虽然它不能作为名称节点使用。这个二级名称节点的重要作用就是定期的通过编辑日志合并命名空间镜像，以防止编辑日志过大。这个二级名称节点一般在其他单独的物理计算机上运行，因为它也需要占用大量CPU和内存来执行合并操作。它会保存合并后的命名空间镜像的副本，在名称节点失效后就可以使用。但是，二级名称节点的状态是比主节点滞后的，所以主节点的数据若全部丢失，损失仍在所难免。在这种情况下，一般把存在NFS上的主名称节点元数据复制到二级名称节点上并将其作为新的主名称节点运行。
3.分别从以下这些方面，梳理清楚HDFS的 结构与运行流程，以图的形式描述。
- 客户端与HDFS
- 客户端读
- 客户端写
- 数据结点与集群
- 数据结点与名称结点
- 名称结点与第二名称结点
- 数据结点与数据结点
- 数据冗余
- 数据存取策略
- 数据错误与恢
4.梳理HBase的结构与运行流程，以用图与自己的话进行简要描述，图中包括以下内容：
(1) Master主服务器的功能
1.为Region server分配region
2. 负责region server的负载均衡
3. 发现失效的region server并重新分配其上的region
4 .HDFS上的垃圾文件回收
5 .处理schema更新请求
(2) Region服务器的功能
1. Region server维护Master分配给它的region，处理对这些region的IO请求
2. Region server负责切分在运行过程中变得过大的region
可以看到，client访问hbase上数据的过程并不需要master参与（寻址访问zookeeper和region server，数据读写访问regione server），master仅仅维护者table和region的元数据信息，负载很低。
(3) Zookeeper协同的功能
1.保证任何时候，集群中只有一个master
2.存贮所有Region的寻址入口—-root表在哪台服务器上。
3.实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master
4.存储Hbase的schema,包括有哪些table，每个table有哪些column family
(4) Client客户端的请求流程
1.包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。
(6) 与HDFS的关联
hbase是一个内存数据库，而hdfs是一个存储空间；是物品和房子的关系。
hdfs只是一个存储空间，他的完整名字是分布式文件系统。从名字可知他的作用了。
hbase是一个内存数据库，简单点说hbase把表啊什么的存在hdfs上。
Hbase与HDFS的性质和属性。
1、Hbase是Hadoop database，即Hadoop数据库。它是一个适合于非结构化数据存储的数据库，HBase基于列的而不是基于行的模式。
HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据。
2、HDFS是GFS的一种实现，他的完整名字是分布式文件系统，类似于FAT32，NTFS，是一种文件格式，是底层的。
Hive与Hbase的数据一般都存储在HDFS上。Hadoop HDFS为他们提供了高可靠性的底层存储支持。
5.理解并描述Hbase表与Region与HDFS的关系。
1、首先了解一下 HDFS文件存储系统和HBASE分布式数据库
HDFS是Hadoop分布式文件系统。
HBase的数据通常存储在HDFS上。HDFS为HBase提供了高可靠性的底层存储支持。
Hbase是Hadoop database即Hadoop数据库。它是一个适合于非结构化数据存储的数据库，HBase基于列的而不是基于行的模式。
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中迁移变的非常方便。
2、HBASE本身作为一个分布式数据库
HBase 本身其实可以完全不要考虑 HDFS 的，你完全可以只把 HBase
当作是一个分布式高并发 k-v 存储系统，只不过它底层的文件系统是通过 HDFS 来支持的罢了。换做其他的分布式文件系统也是一样的，不影响
HBase 的本质。甚至如果你不考虑文件系统的分布式或稳定性等特性的话，完全可以用简单的本地文件系统，甚至内存文件系统来代替。
HBase 在 HDFS 之上提供了：
①、高并发实时随机写，通过 LSM（内存+顺序写磁盘）的方式提供了 HDFS 所不拥有的实时随机写及修改功能
②、高并发实时点读及扫描了解一下 LSM 算法，在文件系统之上有数据库，在业务层面，HBase 完全可以独立于 HDFS 来理解
3、HBASE可以满足大规模数据的实时处理需求
.HDFS面向批量访问模式，不是随机访问模式Hadoop可以很好地解决大规模数据的离线批量处理问题，但是，受限于Hadoop MapReduce编程框架的高延迟数据处理机制，使得Hadoop无法满足大规模数据实时处理应用的需求
●传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题(分库分表也不能很好解决)
●传统关系数据库在数据结构变化时一般需要停机维护;空列浪费存储空间
因此，业界出现了一类面向半结构化数据存储和处理的高可扩展、低写入/查询延迟的系统，例如键值数据库、文档数据库和列族数据库(如BigTable和HBase等)
.HBase已经成功应用于互联网服务领域和传统行业的众多在线式数据分析处理系统中
6.理解并描述Hbase的三级寻址。
HBase的寻址机制
（一）寻址示意图
（二）-ROOT-和.META.表结构
.META.行记录结构
（三）老的 Region 寻址方式
在 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 寻址方式
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的数据表最大有多大？
1MB = 2(10)次方KB
2GB = 2048MB = 2(11)次方MB
2048MB/1KB=2（21）次方大小；
三层结构可以保存的region数为：2048MB/1KB * 2048MB/1KB = 2（42）次方大小
8.MapReduce的架构，各部分的功能，以及和集群其他组件的关系。
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处理。
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阶段”）
