hadoop小结
- hdfs-site.xml 1. hdfs集群公开访问地址 2.namenode保存数据路径 3.datanode保存数据路径 4.secondary 地址
- core-site.xml 配置客户端文件上传路径为hdfs(默认为本地) 控制着文件的副本数和文件的切换
- hdfs上传文件步骤 注意事项:文件分块;client请求客户端时会封装副本数,namenode响应客户端时会分配一个blkid;客户端只会和一个datanode通信,其余自己复制;数据 packet的方式发送
- mapreduce yarn client以线程模式运行(localJobRunner),集群以进程方式运行 ;在mapred-site.xml文件中修改
- mapreduce数据流程图:
创建maptask任务,textInputFormat类用来处理读上来的hdfs文件,用LineRecordReader创建keyvalue对,对会放进环形缓冲区(100m),超过80%会溢出,至少溢出一次,spillThred处理溢出数据的的时候会调用partitioner对数据进行分组,而且还会进行快速排序,maptask中的mergeparts方法会对i分区排序完成后的溢出的小文件进行合并,然后序列化到当前机器的磁盘上;maptask结束,reducetask根据自己的分区好,去各个maptask机器上拉取结果数据,reducetask会取到相同分区来自不同maptask的数据,然后将这些数据进行合并,合并完成后会进行一次归并排序,此时shuffle阶段结束,后续处理用户自定义reduce方法.
- mapreduce切片机制
由fileInputFormat实现类的getSplits方法完成,具体inputFormat类中getsplit方法,逻辑while(文件大小/128>1.1)实现切片
- hdfs中namenode的内存中都存了什么
从架构设计上来看,主要有两部分:1.Namespace管理层:主要负责文件系统中树状目录结构及文件与数据块的映射关系 2.块管理层:主要负责文件系统中文件的物理块与实际存储位置的映射关系BlockMaps。nameSpace管理的元数据除了常驻内存外,还会周期Flush到持久化设备上FSImage,BlockMaps只在内存中。当namenode重启时,首先会在持久化设备上读取FSImage,之后根据datanode的汇报消息重构BlockMaps。namenode中这两块占据了大部分空间,其余还有NetworkTopology,维护机器拓扑及Datanode信息,leaseManager,读写的互斥同步,支持write-once-read-many的核心数据结构,CacheManagerhadoop2.3引入的缓存特性,提升读写性能,SnapshotManager2.1引入,用于数据备份回滚,防止误操作
- namenode数据不断积累造成的问题
1.启动时间变长。namenode的启动大致可分为FSImage数据加载,editlogs回收,checkPoint,datanode的blockreport(构建blockMaps)几个阶段,数据越多,耗时越长。
2.性能下降。hdfs大多操作都集中在namenode上,rpc,元数据管理等 3.FULL JC风险高 4.问题调试困难 使用namenode联邦机制进行负载均衡
- HDFS元数据checkpoit过程
standBy NameNode检测是否达到checkpoint条件,达到,将active Namenoded的最后一次操作日志读取到本地,然后将磁盘中的fsimage文件和edits文件加载到内存,合并成一个新的fsimage文件,然后sn通过http联系nn,nn通过http的方式获取最新的fsimage并删除旧的。
- Fsimage和edits的区别
Fsimage是namenode在节点中保存了文件系统所有的目录、文件信息,文件信息中包含数据块描述信息,修改时间,访问时间等。对于目录来说包括修改时间,访问权限信息。edit保存的是当对hdfs进行增删改时记录的操作,在HADOOP中存在secoundNamenode节点,当namenode中的小文件太多时,将两个文件发送到secoundNamenode中进行和并,并发送会Namenode来保证当前hdfs中信息的完整
- container
1)Container作为资源分配和调度的基本单位,其中封装了的资源如内存,CPU,磁盘,网络带宽等。 目前yarn仅仅封装内存和CPU
2 ) Container由ApplicationMaster向ResourceManager申请的,由ResouceManager中的资源调度器异步分配给ApplicationMaster
3 ) Container的运行是由ApplicationMaster向资源所在的NodeManager发起的,Container运行时需提供内部执行的任务命令.
Yarn中的application有两类container:
- 运行ApplicationMaster的Container 这是由ResourceManager(向内部的资源调度器)申请和启动的,用户提交应用程序时,可指定唯一的ApplicationMaster所需的资源;
- 运行各类任务的Container 这是由ApplicationMaster向ResourceManager申请的,并由ApplicationMaster与NodeManager通信以启动
- InputFormat作用是什么,如何自定义实现
InputFormat会在map操作之前对数据进行两方面的预处理
1是getSplits,返回的是InputSplit数组,对数据进行split分片,每片交给map操作一次
2是getRecordReader,返回的是RecordReader对象,对每个split分片进行转换为key-value键值对格式传递给map常用的InputFormat是TextInputFormat,使用的是LineRecordReader对每个分片进行键值对的转换,以行偏移量作为键,行内容作为值自定义类继承InputFormat接口,重写createRecordReader和isSplitable方法在createRecordReader中可以自定义分隔符
- hadoop和spark都是并行计算,简单谈谈异同
两者都是基于mr来并行运算,hadoop一个作业叫一个job,job里面分map task和reduce task每个task在自己的进程。Spark提交任务成application,一个app对应一个sparkcontext,App中存在多个job,每次action就会触发产生一个job,这些job可并可串,以线程的方式运行。Spark基于内存,hadoop中间计算都是在磁盘上。hadoop的job只有map和reduce,表达能力欠缺,而且会多次读写磁盘,IO严重,spark迭代基于内存,DAG容错良好
- yarn产生原因
简单来讲,因为mrv1
原生的mr由jobTracker接收客户端请求,jobt与nd共同将工作按数据本地性分发到taskTracker的可用插槽上进行计算,这种模型提供了标准的大数据处理架构,但也存在缺陷,在面对大集群,节点超过4000个左右时,就会表现出一定的不可预测性,其中一个最大的问题就是级联故障,由于要尝试复制数据和重载活动的节点,所以一个故障会通过网络泛洪形式导致整个集群严重恶化,mr1还有一个严重的问题是多租户,集群增加时一种可取的方式是采用不同的模型。 于是乎产生了yarn 为了实现一个 Hadoop 集群的集群共享、可伸缩性和可靠性。 简单介绍yarn --------- 。新的yarn打破了jb的高度约束,允许一个新 ResourceManager 管理跨应用程序的资源使用,ApplicationMaster 负责管理作业的执行,扩展能力得到提升,不再需要与一个集群上可能存在的其他更复杂的分布式应用程序框架相隔离。甚至,随着yarn的不断健全,他有能力取代一些其他的分布式架构。同时YARN 允许使用 Message Passing Interface 等标准通信模式,同时执行各种不同的编程模型,包括图形处理、迭代式处理、机器学习和一般集群计算。