面试--Hadoop1

Hadoop基本常用端口

端口名 作用
50070 namenode 的http服务端口
8020 接收client的rpc端口,获取文件系统的元数据信息
50057 datanode的http服务端口
50010 datanode的服务端口,用于数据传输
50090 secondarnamenode的辅助端口
8088 yarn.resourcemanager的服务端口

hadoop集群搭建简单描述

  1. 用root账号登录
  2. 修改IP
  3. 修改主机名
  4. 配置ssh免登录
  5. 关闭防火墙
  6. 安装jdk
  7. 上传Hadoop压缩包,解压
  8. 配置Hadoop核心文件,Hadoop-env.sh, core-site.xml, mapred-site.xml, hdfs-site.xml, yarn-site.xml
  9. 配置环境变量
  10. 格式化hdfs,bin/hadoop namenode -format
  11. 11.启动节点

hdfs体系结构

hdfs主要由namenode, secondraynamenode, datanode组成。

  1. namenode负责管理和记录整个文件系统的元数据。
  2. datanode负责管理用户的文件数据块,文件会按照固定的大小(blocksize,固定大小,一般是128M)切成若干块后分布式储存在若干台datanode上,每个文件块可以有多个副本,并存放在不同的datanode。datanode会定期向namenode汇报自身所保存的文件块block的信息,而namenode会负责保持文件的副本数。
  3. hdfs的内部工作机制对客户端保持透明,客户端访问hdfs都是向namenode 申请进行的。
  4. secondraynamenode负责合并日志(fsimage和edit log)

hdfs读写过程

一.hdfs读数据

  1. 客户端client 跟namenode通讯查询元数据,namenode通过查询元数据,所得文件块所在的datanode服务器。
  2. 挑选几台datanode服务器(就近原则,然后随机原则),请求socket流。
  3. datanode开始发送数据(从磁盘里面读取数据放入流中,以packet为单位作为校验,大小为64k.)
  4. 客户端以packer为单位接收,现在本地缓存,写入目标文件。

二.hdfs写文件

  1. client向namenode通信请求上传文件,namenode检查目标文件是否已经存在,父目录是否存在,用户是否有权限。
  2. namenode返回是否可以上传。
  3. client请求第一个block可以传输到那些datanode服务器上
  4. namenode返回3个datanode服务器ABC。
  5. client 请求三台datanode中的A上传数据(本质上是RPC调用,建立pipeline),A收到请求后会继续调用B,B调用C,整个pipeline建立完成,逐级返回客户端。
  6. client开始往A上传第一个block,(从磁盘读取数据放到本地内存缓存),然后一packet为单位上传给A,A收到一个packet就会上传给B,B传给C。A每传一个packet会放进一个应答队列等待应答。
  7. 当一个block传输完成后,client再次请求namenode上传第二个block的服务器。

宕机

datanode宕机

datanode宕机后,如果是短暂的宕机,可以实现写好脚本监控,重新启动。但是如果是长时间的宕机后,datanode的数据已经备份到其他机器了,那这台datanode就是全新的datanode,可以删除它的所有数据文件和状态文件,重新启动。

namenode宕机

宕机后导致client无法访问,内存中元数据丢失,但是硬盘中的元数据还在。如果只是节点挂了,重启即可。但是如果是机器挂了,重启机器后看节点是否能重启,不能重启就要找原因修复。应该在初期设计namenode的ha模式。

因为MR造成系统宕机

如果是因为MR而造成宕机的话,此时要控制好YARN同时运行的任务数。和每个任务申请的最大内存。调整:yarn.sheduler.maxnum-allocation-mb(单个任务可申请的物理内存量,默认是8192M)

因为写入文件过量造成的namenode宕机

如果写入的文件过量造成namenode宕机,调整kafka的存储大小,控制Kafka到hdfs的写入速度。高峰时期用Kafka缓存,高峰期后数据同步会跟上去。

元数据

hdfs对元数据的管理

namenode对元数据的三种存储形式:

  1. 内存元数据(namesystem)
  2. 磁盘元数据镜像文件(fsimage镜像)
  3. 数据操作日志文件(edit日志)

元数据的checkpoint

元数据存在内存中,可以方便存储,但是断电后会丢失,存在磁盘中但是因为要经常进行随机访问,响应客户端请求,效率过低,所以最好的方法是存在内存中,磁盘也相对应备份一份。但是如果同步更新,效率就会底下,过久则会导致数据不一致,所以引入了edit.log日志,记录更新或更新元数据的操作,这样断电后就能合并fsimage和edit合成新元数据。所以引入secondraynamenode专门负责合并。

合并操作:
每隔一段时间,由secondraynamenode将积累namenode上的所有edit和最新的fsimage下载到本地,并加载到内存中merge合并。
namenode和secondraynamenode工作目录结构相同,所以当namenode故障退出的时候可以从secondraynamenode工作目录中将fsimage拷贝到namenode的工作目录,以回复namenode的元数据。

combiner和partitioner

  1. combiner是发生在map最后一个阶段,父类是Reducer。意义是对每个maptask后的结果进行一个局部的汇总,以减少后面的网络传输量,缓解网络传输瓶颈,提高reducer的执行效率。
  2. partitioner是将map阶段产生的所有key -value分配给不同的reducer task处理,可以将recuer阶段的处理负载均衡。

MR

什么是MR

MR是mapreduce缩写,mr是一个分布式运算程序的编程框架,是用户开发”基于Hadoop的分析应用“的核心框架。
MR核心功能就是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序,运行在一个Hadoop集群。

MR结构

一个完整的mapreduce程序在分布式运行时有三类实例进程:

  1. MrAppMaster:负责整个程序的过程协调及状态协调。
  2. maptask:负责map阶段的整个数据处理流程。
  3. reducetask:负责reduce阶段的整个数据处理流程。

MR的核心思想:分而治之,先分后合。

MR流程

在这里插入图片描述
其中maptask的数量是不能设置的,reducetask的数量可以设置:job.setNumReduceTasks(5);

流程解析

  1. 首先启动mrappmaster,mrappmaster启动后根据job描述信息计算出所需要的的maptask实例数量,然后向集群机器启动相对应数量的maptask进程。
  2. maptask进程启动后,根据 给定的数据切片范围进行数据处理,主要流程:maptask利用客户指定的inputformat来获取recordreader读取数据,形成kv对传递客户定义的map方法做逻辑运算,并将map()方法输出的kv对收集缓存,将缓存中的kv按照k分区排序后不断溢写到磁盘文件。
  3. mrappmaster监控到所有的maptask任务进程完成后,根据客户指定的参数启动相应数量的reducetask进程,告知reducetask进程要处理的数据范围(数据分区)。
  4. reducetask进程启动后,根据mrappmaster告知的待处理数据所在位置,从若干台maptask运行所在的机器上获取若干个maptask输出结果文件,并在本地进行重新归并排序,然后按照相同key所在
    的kv分组。调用客户定义的reduce()方法进行逻辑计算。并收集运算输出的结果,然后调用outputformat输出结果。

Mapreduce 的 map 数量 和 reduce 数量是由什么决定的 ,怎么配置

map的数量是由输入的切片数量决定的,128M分一个切片,只要是文件也分一个切片。有多少个切片就有多少个maptask。
reduce数量由自己决定。

猜你喜欢

转载自blog.csdn.net/weixin_43859562/article/details/114366038