04 Hadoop思想与原理，Hbase原理

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

 

 

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

 

 

一、名称节点（NameNode）

1.什么是名称节点

在HDFS中，名称节点负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构-FsImage和EditLog。

• FsImage：用于维护文件系统树以及文件树中所有的文件和文件夹的元数据。
• EditLog：中记录所有针对文件创建、删除、重命名等操作的日志文件。

名称节点记录了每个文件中各个块所在的数据节点的位置信息，但并不持久化存储这些信息，而是在系统每次启动时扫描所有数据节点重构得到这些信息。

2.名称节点工作过程

名称节点启动时，会将FsImage的内容加载到内存当中，然后执行EditLog文件中的各项操作，使得内存中的元数据保存最新。这个操作完成后，就会创建一个新的FsImage文件和一个空的EditLog文件。名称节点启动成功并进入正常运行状态以后，HDFS中的更新操作都会被写入到EditLog，而不是直接写入FsImage（文件大，直接写入系统会变慢）。

名称节点在启动的过程中处于“安全模式”，只能对外提供读操作。启动结束后，则进入正常运行状态，对外提供读写操作。

二、第二名称节点（Secondary NameNode）

1.功能

在名称节点运行期间，EditLog文件由于操作不断发生会逐渐变大，为解决逐渐变大带来的问题，故采用了第二名称节点。

• 可以完成EditLog与FsImage的合并操作，减少EditLog文件大小，缩短名称节点重启时间
• 作为名称节点的“检查点”，保存名称节点中的元数据信息。

2.工作过程

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节点。
5. NameNode将从SecondaryNameNode接收到的新的FsImage替换旧的FsImage文件，同时将edit.new替换EditLog文件，通过这个过程EditLog就变小了。

HDFS设计中，并不支持把系统直接切换到第二名称节点，从这角度，第二名称节点只是起到名称节点“检查点”的作用，并不能起到“热备份”作用。即使有了第二名称节点的存在，当名称节点发生故障时，系统还是有可能会丢失部分元数据信息。

来源：HDFS名称节点工作过程 - 知乎 (zhihu.com)

仅作学习交流，侵删。

 

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

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

 

4.梳理HBase的结构与运行流程，以用图与自己的话进行简要描述，图中包括以下内容：

Master主服务器的功能

1. 为Region server分配region
2. 负责Region server的负载均衡
3. 发现失效的Region server并重新分配其上的region。
4. HDFS上的垃圾文件回收。
5. 处理schema更新请求。

Region服务器的功能

1. 负责与hdfs交互，存储数据到hdfs中
2. 处理hmaster分配的region
3. 刷新缓存到hdfs
4. 维护hlog
5. 执行压缩
6. 处理region分片
7. 处理来自客户端的读写请求

Zookeeper协同的功能

Zookeeper的作用
HBase依赖Zookeeper，默认情况下HBase管理Zookeeper实例(启动或关闭Zookeeper),Master与RegionServers启动时会向Zookeeper注册。

Zookeeper的作用：

保证任何时候，集群中只有一个master
存储所有Region的寻址入口
实时监控Region server的上线和下线信息。并实时通知给master
存储HBase的schema和table元数据

Client客户端的请求流程

首先Client通过访问hbase:meta元数据表找到指定范围row所处的regions，以及对应的RegionServers；
在确定region之后，Client不会与Master进行交互，而是直接与RegionServer交互，让其开启对指定region的服务；
然后RegionServer开始处理对应的read and write请求；
同时Client会将这些region的交互信息缓存在内存中，以保证下次请求服务端就不用再查询hbase:meta重新定位；
一旦一个被请求的region被重新负载均衡分配到其它的RegionServer上，那么Client下次查询的时候才会重新访问hbase:meta,并且更新缓存的region信息

四者之间的相系关系

 

 

 与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 寻址方式
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的数据表最大有多大？

1MB = 2(10)次方KB

2GB = 2048MB = 2(11)次方MB

2048MB/1KB=2（21）次方大小；

三层结构可以保存的region数为：2048MB/1KB * 2048MB/1KB = 2（42）次方大小

 

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

 

 

 

 （1）Client

用户编写的MapReduce程序通过Client提交到JobTracker端；同时，用户可通过Client提供的一些接口查看作业运行状态。在Hadoop内部用“作业”（Job）表示MapReduce程序。一个MapReduce程序可对应若干个作业，而每个作业会被分解成若干个Map/Reduce任务（Task）。

（2）JobTracker
  JobTracker主要负责资源监控和作业调度。JobTracker监控所有TaskTracker与作业的健康状况，一旦发现失败情况后，其会将相应的任务转移到其他节点；同时JobTracker会跟踪任务的执行进度、资源使用量等，并将这些信息告诉给任务调度器（Task Scheduler），而T调度器会在资源出现空闲时，选择合适的任务使用这些资源。在Hadoop中，任务调度器是一个可插拔的模块，用户可以根据自己的需要设计相应的Scheduler。

（3）TaskTracker
  TaskTracker会周期性地通过Heartbeat将本节点上资源的使用情况和任务的运行进度汇报给JobTracker，同时接收JobTracker发送过来的命令并执行相应操作（如启动新任务、杀手任务等）。TaskTracker使用“slot”等量划分本节点上的资源量。“slot”代表计算资源（CPU、内存等）。一个Task获取到一个slot后才有机会运行，而Hadoop调度器的作用就是将各个TaskTracker上的空闲slot分配给Task使用。slot分为Map slot和Reduce slot两种，分别供Map Task和Reduce Task使用。TaskTracker通过slot数目（可配置参数）限定Task的并发度。

（4）Task
  Task分为Map Task和Reduce Task两种，均由TaskTracker启动。我们知道，HDFS以固定大小的block为基本单位存储数据，而对于MapReduce而言，其处理单位是split。split与block的对应关系如下图所示。split是一个逻辑概念，它只包含一些元数据信息，比如数据起始位置、数据长度、数据所在节点等。它的划分方法完全由用户自己决定。但需要注意的是，split的多少决定Map Task的数目，因为每个split会交由一个Map Task处理。

关系：在hadoop的框架上采取mapreduce的模式处理海量数据。

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

在MapReduce整个过程可以概括为以下过程：输入 --> map --> shuffle --> reduce -->输出

 

流程说明如下：

1、输入文件分片，每一片都由一个MapTask来处理

2、Map输出的中间结果会先放在内存缓冲区中，这个缓冲区的大小默认是100M，当缓冲区中的内容达到80%时（80M）会将缓冲区的内容写到磁盘上。也就是说，一个map会输出一个或者多个这样的文件，如果一个map输出的全部内容没有超过限制，那么最终也会发生这个写磁盘的操作，只不过是写几次的问题。

3、从缓冲区写到磁盘的时候，会进行分区并排序，分区指的是某个key应该进入到哪个分区，同一分区中的key会进行排序，如果定义了Combiner的话，也会进行combine操作

4、如果一个map产生的中间结果存放到多个文件，那么这些文件最终会合并成一个文件，这个合并过程不会改变分区数量，只会减少文件数量。例如，假设分了3个区，4个文件，那么最终会合并成1个文件，3个区

5、以上只是一个map的输出，接下来进入reduce阶段

6、每个reducer对应一个ReduceTask，在真正开始reduce之前，先要从分区中抓取数据

7、相同的分区的数据会进入同一个reduce。这一步中会从所有map输出中抓取某一分区的数据，在抓取的过程中伴随着排序、合并。

8、reduce输出