第四次作业

Hadoop之父
Doug Cutting

 

 

Hadoop最早起源于lucene下的Nutch。Nutch的设计目标是构建一个大型的全网搜索引擎,包括网页抓取、索引、查询等功能,但随着抓取网页数量的增加,遇到了严重的可扩展性问题——如何解决数十亿网页的存储和索引问题。
2003年、2004年谷歌发表的三篇论文为该问题提供了可行的解决方案。
——分布式文件系统(GFS),可用于处理海量网页的存储
——分布式计算框架MAPREDUCE,可用于处理海量网页的索引计算问题。
——分布式的结构化数据存储系统Bigtable,用来处理海量结构化数据。
Doug Cutting基于这三篇论文完成了相应的开源实现HDFS和MAPREDUCE,并从Nutch中剥离成为独立项目HADOOP,到2008年1月,HADOOP成为Apache顶级项目(同年,cloudera公司成立),迎来了它的快速发展期。
为什么叫Hadoop? Logo为什么是黄色的大象?

 

 


狭义上来说,Hadoop就是单独指代Hadoop这个软件(HDFS+MAPREDUCE)
广义上来说,Hadoop指代大数据的一个生态圈(Hadoop生态圈),包括很多其他的软件。


Hadoop的历史版本介绍
0.x系列版本:Hadoop当中最早的一个开源版本,在此基础上演变而来的1.x以及2.x的版本
1.x版本系列:Hadoop版本当中的第二代开源版本,主要修复0.x版本的一些bug等
2.x版本系列:架构产生重大变化,引入了yarn平台等许多新特性

 

 


Hadoop的模块组成
1、HDFS:一个高可靠、高吞吐量的分布式文件系统。
(海量数据的存储)
HDFS集群包括,NameNode和DataNode以及Secondary Namenode。
管理者:NameNode详细介绍
辅助管理者(无法替代管理者)SecondaryNameNode 用来监控HDFS状态的辅助后台程序,每隔一段时间获取HDFS元数据的快照。最主要作用是辅助namenode管理元数据信息
工作者:DataNode详细介绍
2、MapReduce:一个分布式的离线并行计算框架(海量数据的计算)。
3、YARN:集群资源(调度)管理的框架。
管理者:ResourceManager

工作者:NodeManager
4、Common:支持其他模块的工具模块。
————————————————
版权声明:本文为CSDN博主「初于久歌」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_45748397/article/details/102909155

 

 

4.梳理HBase的结构与运行流程,以用图与自己的话进行简要描述。

  • Master主服务器的功能

1、管理用户对Table表的增、删、改、查操作;

2、管理HRegion服务器的负载均衡,调整HRegion分布;

3、在HRegion分裂后,负责新HRegion的分配;

4、在HRegion服务器停机后,负责失效HRegion服务器上的HRegion迁移

 

  • Region服务器的功能

 所有的数据库数据一般是保存在Hadoop分布式系统上面的,用户通过一系列HRegion服务器获取这些数据。一台机器上一般只运行一个HRegion服务器,而且每一分区段的HRegion也只会被一个HRegion服务器维护。

 

  HRegion服务器包含两大部分:HLog部分和HRegion部分。

  HRegion服务器在它这里面,又相当于是个小组长。

 

     HBase里的HRegion

  其中HLog用来存储数据日志,采用的是先写日志的方式。HRegion部分由很多的HRegion组成,存储的是实际的数据。每一个HRegion又由很多的Store组成,每一个Store存储的实际上是一个列簇(ColumnFamily)下的数据。此外,在每一个HStore(又名Store)中有包含一块MemStore。MemStore驻留在内存中,数据到来时首先更新到MemStore中,当到达阔值之后再更新到对应的StoreFile(又名HFile)中。每一个Store包含了多个StoreFile,StoreFile负责的是实际数据存储,为HBase中最小的存储单元。

 

   HBase中不涉及数据的直接删除和更新操作,所有的数据均通过追加的方式进行更新。数据的删除和更新在HBase合并的时候进行。当Store中StoreFile的数量超过设定的阔值时将触发合并操作,该合并操作把多个StoreFile文件合并成一个StoreFile。

  当用户需要更新数据的时候,数据会被分配到对应的HRegion服务器上提交修改。数据首先被提交到HLog文件里面,在操作写入HLog之后,commit()调用才会将其返回给客户端。HLog文件用于故障恢复。例如某一台HRegionServer发生故障,那么它所维护的HRegion会被重新分配到新的机器上。这是HLog会按照HRegion进行划分。新的机器在加载HRegion的时候可以通过HLog对数据进行恢复

 

  当一个HRegion变得太过巨大,超过了设定的阔值时,HRegion服务器会调用HRegion.closeAndSplit(),将此HRegion拆分为两个,并且报告给主服务器让它决定由哪台HRegion服务器来存放新的HRegion。这个拆分过程十分迅速,因为两个新的HRegion最初只是保留原来HRegionFile文件的引用。这时旧的HRegion会处于停止服务的状态,当新的HRegion拆分完成并且把引用删除了以后,旧的HRegion才会删除。另外,HRegion可以通过调用HRegion.clodeAndMerge()合并成一个新的HRegion,当前版本下进行此操作需要两台HRegion服务器都停机。

 

 

 

 

  • Zookeeper协同的功能

ZooKeeper

HBase使用ZooKeeper作为分布式协调服务来维护集群中的服务器状态。Zookeeper维护哪些服务器处于活动状态并可用,并提供服务器故障通知。Zookeeper使用共识来保证共同的共享状态。请注意,应该有三到五台机器达成共识。

 
image

组件如何协同工作

Zookeeper用于协调分布式系统成员的共享状态信息。区域服务器和活动HMaster通过会话连接到ZooKeeper。ZooKeeper通过心跳维护活动会话的临时节点。

 
image

每个区域服务器创建一个临时节点。HMaster监控这些节点以发现可用的区域服务器,并监控这些节点的服务器故障。HMasters争夺创造一个短暂的节点。Zookeeper确定第一个并使用它来确保只有一个主站处于活动状态。活动HMaster将心跳发送到Zookeeper,非活动HMaster将监听活动HMaster故障的通知。

如果区域服务器或活动HMaster未能发送心跳,则会话过期并删除相应的临时节点。更新的听众将被通知删除的节点。活动的HMaster侦听区域服务器,并在失败时恢复区域服务器。Inactive HMaster监听活动HMaster失败,如果活动HMaster失败,则非活动HMaster将变为活动状态。

 
 
7人点赞
 
blog
 
 


作者:全能程序猿
链接:https://www.jianshu.com/p/9f08b6e2379d
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

 

  • Client客户端的请求流程

1、HBase写数据流程

1.1:

流程:Client请求Zookeeper确定meta表所在的RegionServer所在的地址,接着根据Rowkey找到数据所归属的RegionServer;用户提交put或delete请求时HbaseClient会将put或delete请求添加到本地buffer中,符合一定条件会通过异步批量提交服务器处理。

1.2:数据到达Region后,服务端处理流程如下:

 流程:RegionServer去获取RowLock,region更新共享锁;接着Hbase会先写写日志WAL(数据可靠性)再写缓MemStore(阈值默认64M,每个列族对应一个Store下的MemStore);然后释放锁后将日志落到HDFS;若MemStore达到阈值则将缓存数据落磁盘StoreFile,最后多个StoreFile发生合并;若StoreFile很大会触发split操作,将当前region分割成2个Region,并同步到Hmaster。

2、HBase读数据流程

流程:RegionServer收到get请求后,对当前Region进行Scan,接着会根据列族对Store进行Scan,同时会对对应的MemStore进行Scan;最后找到我们要的数据返回给Client。注意:一个StoreScanner会对应多个StoreFileScanner,整个过程是一个层级关系。

SUMMARY:

HBase写数据流程:


1、Client先访问zookeeper,从meta表获取相应region信息,然后找到meta表的数据
2、根据namespace、表名和rowkey根据meta表的数据找到写入数据对应的region信息
3、找到对应的regionserver
4、把数据分别写到HLog和MemStore上一份
4、MemStore达到一个阈值后则把数据刷成一个StoreFile文件。(若MemStore中的数据有丢失,则可以总HLog上恢复)
5、当多个StoreFile文件达到一定的大小后,会触发Compact合并操作,合并为一个StoreFile,(这里同时进行版本的合并和数据删除。)
6、当Storefile大小超过一定阈值后,会把当前的Region分割为两个(Split),并由Hmaster分配到相应的HRegionServer,实现负载均衡

HBase读数据流程:


1、Client先访问zookeeper,从meta表读取region的位置,然后读取meta表中的数据。meta中又存储了用户表的region信息。
2、根据namespace、表名和rowkey在meta表中找到对应的region信息
3、找到这个region对应的regionserver
4、查找对应的region
5、先从MemStore找数据,如果没有,再到StoreFile上读(为了读取的效率)。

 

  • 与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已经成功应用于互联网服务领域和传统行业的众多在线式数据分析处理系统中
————————————————
版权声明:本文为CSDN博主「zhangvalue」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/zhangvalue/article/details/102155571

 

5.完整描述Hbase表与Region的关系,三级寻址原理。

 

 

 

 

6.理解并描述Hbase的三级寻址。

Hbase寻址机制
1、寻址示意图


2、-ROOT-和.META.表结构
-ROOT-表结构

 

.META.行记录结构

 

3、寻址流程
现在假设我们要从Table2里面查询一条RowKey是RK10000的数据。那么我们应该遵循以下步骤:
1. 从.META.表里面查询哪个Region包含这条数据。
2. 获取管理这个Region的RegionServer地址。
3. 连接这个RegionServer, 查到这条数据。

系统如何找到某个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(其中三次用来发现缓存失效,另外三次用来获取位置信息)。

4、总结
Region定位流程:

 

寻找RegionServer
ZooKeeper–> -ROOT-(单Region)–> .META.–> 用户表

-ROOT-表
表包含.META.表所在的region列表,该表只会有一个Region;
Zookeeper中记录了-ROOT-表的location。

.META.表
表包含所有的用户空间region列表,以及RegionServer的服务器地址。
————————————————
版权声明:本文为CSDN博主「Running_Tiger」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_41455420/article/details/79546367

 

7.通过HBase的三级寻址方式,理论上Hbase的数据表最大有多少个Region?

  RegionServer维护Master分配给它的region,处理对这些region的IO请求,负责切分在运行过程中变得过大的region, 由于集群性能( 分配的内存和磁盘是有限的 )有限的,那么HBase单个RegionServer的region数目肯定是有上限的。

Region数目上限

     RegionServer的region数目取决于memstore的内存使用,每个region拥有一组memstore(memstore的数量有hstore决定,hstore的数据由创建表时的指定的列族个数决定,所以 每个region的memstore的个数 = 表的列族的个数 ),可以通过配置来修改memstore占用内存的大小,一般设置在  128 M – 256M之间。

     RegionServer 分配一定比例的内存给它下面的所有memstore( 该比例大小 可通过hbase.regionserver.global.memstore.upperLimit 进行修改 ), 如果内存溢出(使用了太多的memstore),它可能会导致严重的后果,如服务器反应迟钝 或compact风暴。比较好的计算每RS(假设一个表)region的数量的公式为:

((RS memory) * (total memstore fraction)) / ((memstore size)*(# column families))

 

 例如: 如果 一个RegionServer配置的内存是16g,使用默认配置( hbase默认regionserver分给memstore的比例是0.4 , 默认的menstore的占用128M内存 ), 一个CF,那么这个regionServer下的region的个数大约为  16384 * 0.4 / (128*1) = 51个,实际测试大于这个数 一两倍 也没太大的问题。 一个HBase表包含一至多个region,那么表的数目上限也是可以估算出来的。

 

Region大小上限

   对于生产场景中大表,最大的region大小主要是受compactions 的限制,大量大HFile的compact会降低群集性能。目前,该建议的最大region大小为10-20GB,而5-10GB是最优

 

7.假设.META.表的每行(一个映射条目)在内存中大约占用1KB,并且每个Region限制为2GB,通过HBase的三级寻址方式,理论上Hbase的数据表最大有多大?

(2048MB/1kb)x (2048MB/1kb)=17179869184个

 

 

 

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

MapReduce架构
  Hadoop MapReduce采用Master/Slave(M/S)架构,如下图所示,主要包括以下组件:Client、JobTracker、TaskTracker和Task。

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处理。


split和block的区别
(4-1)Map Task的执行过程
  Map Task先将对应的split迭代解析成一个个key/value对,依次调用用户自定义的map()函数进行处理,最终将临时结果存放到本地磁盘上,其中临时数据被分为若干个partition,每个partition将被一个Reduce Task处理。

Map Task执行过程
(4-2)Reduce Task的执行过程
  Map Task执行过程分为三个阶段①从远程节点上读取Map Task的中间结果(称为“Shuffle阶段”);②按照key对key/value键值对进行排序(称为“Sort阶段”);③依次读取<key, value list>,调用用户自定义的reduce()函数处理,并将最终结果存放到HDFS上(称为“Reduce阶段”)。

Reduce Task执行过程
————————————————
版权声明:本文为CSDN博主「王小康walker」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_29342837/article/details/78587458

 

9.MapReduce的工作过程,用自己的例子,将整个过程梳理并用图形表达出来

 

mapReduce编程模型的总结:
事实上MapReduce的开发一共有八个步骤其中map阶段分为2个步骤,shuffle阶段4个步骤,reduce阶段分为2个步骤

Map阶段2个步骤
第一步:设置inputFormat类,将数据切分成key,value对,输入到第二步

第二步:自定义map逻辑,处理第一步的输入数据,然后转换成新的key,value对进行输出


shuffle阶段4个步骤(该阶段不用自己操作,都是后台操作)
第三步:对输出的key,value对进行分区。相同key的数据发送到同一个reduce里面去,相同key合并,value形成一个集合
第四步:对不同分区的数据按照相同的key进行排序
第五步:对分组后的数据进行规约(combine操作),降低数据的网络拷贝(可选步骤)
第六步:对排序后的额数据进行分组,分组的过程中,将相同key的value放到一个集合当中


reduce阶段2个步骤
第七步:对多个map的任务进行合并,排序,写reduce函数自己的逻辑,对输入的key,value对进行处理,转换成新的key,value对进行输出
第八步:设置outputformat将输出的key,value对数据进行保存到文件中


八个步骤总体流程

————————————————
版权声明:本文为CSDN博主「小哪吒的BD」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/Mr_Yang888/article/details/103101183

posted on 2021-10-26 08:25  探路者0639  阅读(52)  评论(0)    收藏  举报

导航