大家好,又见面了,我是你们的朋友全栈君。
文章目录
-
- 你们公司集群有多少机器,内存,硬盘,CPU?
- 你们Hadoop、Hive、Kafka都是什么版本?
- 你们每天的数据量有多少?数据总量是多少?
- 分布式和集群的区别?
- Hadoop 1和Hadoop 2的区别?
-
-
- Hadoop 1
- Hadoop 2
-
- NameNode
- 运行处理
-
- 什么是Hadoop?
- 说一说Hadoop的shuffle过程?
- Hadoop中为什么需要排序?
- HDFS相关概念
-
-
- 特点
- 缺点
- Block
- NameNode
- DataNode
- Edit Log
- FSImage
- Secondary NameNode
- fsimage和edits合并过程
- 副本放置策略
-
- HDFS读
- HDFS写
- HDFS删除
- YARN相关概念
-
-
- ResourceManager
- Scheduler
- Application Manager
- Application Master
- Node Manager
- Container
-
- 向YARN提交任务的流程
- YARN资源调度
- Hadoop Shuffle优化
- MR优化策略
- 造成数据倾斜的原因
- Hadoop数据倾斜优化
-
-
- join倾斜
- group by倾斜
-
- InputFormat、OutputFormat、Split
- Hadoop Hive支持的文件格式
-
-
- TEXTFILE
- SEQUENCEFILE
- RCFILE
- Orc和Parquet
-
- 压缩算法
- 参考
你们公司集群有多少机器,内存,硬盘,CPU?
你们Hadoop、Hive、Kafka都是什么版本?
你们每天的数据量有多少?数据总量是多少?
分布式和集群的区别?
分布式是指通过网络连接的多个组件,通过交换信息协作而形成的系统。
集群是指同一组件的多个实例,形成的逻辑上的整体。
集群强调的是任务的同一性,分布式强调的是差异性
分布式:不同的业务模块部署在不同的服务器上或者同一个业务模块分拆多个子业务,部署在不同的服务器上,解决高并发的问题
集群:同一个业务部署在多台机器上,提高系统可用性
Hadoop 1和Hadoop 2的区别?
Hadoop 1
主要由HDFS和MapReduce组成,MR由JobTracker和多个TaskTracker组成。
JobTracker的主要作用:JobTracker是框架的中心,接收任务,计算资源,分配资源,分配任务,与DataNode进行交流等功能。决策程序失败时 重启等操作。
TaskTracker监视当前机器上的task运行状况
存在问题:JobTracker是MR的集中处理点,存在单点故障。JobTracker完成了太多任务,造成了过多资源的消耗,当mapreduce job非常多的时候,会造成很大的内存消耗,同时也增加了JobTracker失效的风险
Hadoop 2
NameNode
为了解决单NameNode制约HDFS扩展性的问题,提出了联邦HDFS。让多个NameNode分管不同的目录进而实现访问隔离和横向扩展,同时解决了NameNode单点故障的问题
有两个NameNode: active、standby。实现高可用。
运行处理
基于yarn进行计算资源的分配、管理
yarn负责资源的管理和调度。
Application Master负责一个作业的管理。每个Job都有独立的Application Master
Resource Manager负责资源的分配。
Node Manager负责节点上资源管理。
什么是Hadoop?
Hadoop是开源的、可靠的、可扩展的系统架构,可以利用分布式架构来存储海量数据,以及实现分布式的计算。使用MapReduce计算模型实现对大数据集进行分布式的处理。
说一说Hadoop的shuffle过程?
Shuffle是MapReduce的核心。
Map端Shuffle :map端会将map处理数据的中间结果写入磁盘供reduce端拉取;首先会写入内存缓冲区,当内存缓存区达到阈值,溢写到磁盘; 在溢写之前会进行分区、排序,保证所属分区及有序性;写磁盘之前,如果有combiner阶段,就先进行combiner预聚合;写入磁盘,将溢写到磁盘的文件合并为一个大文件,等待reduce拉取
Reduce端Shuffle: reduce会默认起5个线程来拉取属于自己的数据,会对拉取到的数据济宁合并、排序,最终生成一个大的文件作为reduce端的输入
Hadoop中为什么需要排序?
MR在reduce阶段需要分组将key相同的放在一起进行规约,为实现目的,有两种算法:hashmap和sort,前者太耗内存,而排序通过外排可以对任意数据量分组,只要磁盘够大进行。
map端排序是为了减轻reduce端排序的压力。
HDFS相关概念
特点
支持大文件存储、部署在廉价机器上、高容错、简单的一致性模型
缺点
不适合低延迟数据访问、不适合大量小文件存储、不支持强事务
Block
存储文件的基本单位,把文件存储到不同的磁盘上,默认大小是128M
NameNode
存储元数据,将元数据保存到内存及磁盘上,保存文件、block、datanode的关系
NameNode中的元数据信息存储在内存及文件中。内存中为实时信息;文件中为数据镜像,作为持久化存储使用
DataNode
存储块内容,存储在磁盘中,维护了block id到文件的映射
Edit Log
NameNode的操作日志
FSImage
NameNode的元数据镜像文件。fsimage保存了最新的元数据检查点,包含了整个HDFS文件系统的所有目录和文件的信息
Secondary NameNode
Secondary NameNode会定期合并fsimage和edits,合成新的fsimage,新的操作会写入新的edit log中。
保留合并后的镜像文件,以防数据节点失败时恢复数据
fsimage和edits合并过程
- 将hdfs更新记录写入一个新的文件edit.new
- 将fsimage和edit log通过http发送到secondary namenode
- 将fsimage和edit log进行合并,生成新的fsimage.ckpt,这个过程在secondary NameNode中进行
- 将生成的fsimage.ckpt通过http协议发送至namenode
- 重命名fsimage.ckpt为fsimage,edits.new为edit
副本放置策略
- 第一个副本放置在上传文件的DataNode服务器节点上,如果是在集群外提交,则随机放置在一个DataNode服务器节点上
- 第二个副本放置在与第一个DataNode不同的机架的一个节点上。
- 第三个副本放置在与第二个DataNode相同的机架的不同节点上。
- 更多副本:随机节点放置
这种策略减少了机架间的数据传输,提高了写操作的效率。机架的错误远远比节点的错误少,所以这种策略不会影响到数据的可靠性和可用性。这种策略在不损害数据可靠性和读取性能的情况下改进了写的性能。
HDFS读
- 客户端向NameNode获取每个数据块DataNode的列表
- 就近挑选一台DataNode服务器,请求建立输入流,读取数据
- 读取完当前block的数据后,关闭与当前DataNode的连接,并为读取下一个Block寻找最佳的DataNode
- 读取完每个Block都会进行checksum,如果读取datanode时出现错误,客户端户通知NameNode,然后从下一个拥有该Block拷贝的DataNode继续读
- 当文件最后一个块也读取完成后,datanode会连接NameNode告知关闭文件。
HDFS写
- 客户端向NameNode发出写文件请求。
- 检查是否已存在文件、检查权限。若通过检查,直接先将操作写入EditLog,并返回输出流对象。
- client端按128M的块切分文件。
- client将NameNode返回的分配的可写的DataNode列表和Data数据一同发送给最近的第一个DataNode节点,此后client端和NameNode分配的多个DataNode构成pipeline管道
- 最后一个datanode成功存储之后会返回一个ack packet,在pipeline里传递至客户端,在客户端的开发库内部维护着”ack queue”,成功收到datanode返回的ack packet后会从”ack queue”移除相应的packet。
- 写完数据,关闭输输出流。
- 发送完成信号给NameNode。
HDFS删除
- 在NameNode上执行节点名称的删除
- 当NameNode执行delete方法时,它只标记操作涉及的需要被删除的数据块,而不会主动联系这些数据块所在的DataNode节点
- 当保存着这些数据块的DataNode节点向NameNode发送心跳时,在心跳应答里,NameNode节点会向DataNode发出指令,从而把数据删掉
- 所以在执行完delete方法后的一段时间内,数据块才真正的被删除掉
YARN相关概念
ResourceManager
全局资源管理器,负责对系统中的所有资源进行管理,处理客户端请求,启动或监控Application Master,监控NodeManager,资源的调度和分配
由两个组件组成:Scheduler调度器、应用程序管理器Application Manager
Scheduler
负责资源的调度,根据容量队列的限制,将资源分配给正在运行的应用
Application Manager
负责管理所有的应用程序,包括应用程序的提交,与调度器协商启动Application Master,监控Application Master的运行状态。
Application Master
每个应用均包含一个Application Master,用于和Resource Manager协调获取资源,将得到的资源进一步分配给任务,与Node Manager通信启动/停止任务,监控所有任务的状态,在任务失败时重新为任务申请资源执行任务
Node Manager
每个节点上的任务和资源管理器,是真正执行应用程序的容器的提供者,监控应用程序的使用情况。并通过心跳向集群资源调度器 ResourceManager 进行汇报以更新自己的健康状态。同时其也会监督 Container 的生命周期管理,监控每个 Container 的资源使用(内存、CPU 等)情况,追踪节点健康状况,管理日志和不同应用程序用到的附属服务
Container
抽象的逻辑资源单位。Container是由Resource Manager动态分配的资源构成。它包括了该节点上的一定量的CPU、内存、磁盘、网络等资源,MapReduce程序的所有Task都是在一个容器中执行的,容器的大小是可以动态调整的
向YARN提交任务的流程
- 客户端向yarn提交任务
- Resource Manager会为该应用程序分配第一个Container,并与Node Manager通信,要求在这个Container中启动Application Master
- Application Master启动后向Resource Manager注册,RM监控AM的运行,并给他分配资源
- Application Master 通过轮询的方式向Resource Manager申请资源
- 申请到资源后,与Node Manager通信,要求它启动任务
- Node Manager启动任务,启动后向Application Master汇报自己的状态和进度
- 应用完成后,Application Master向Resource Manager注销自己。
YARN资源调度
有三种:先进先出、容量调度、公平调度
FIFO:将所有的应用放到一个队列中,按照提交的顺序执行,不适合大型集群
容量调度器:保留一个小队列保证小作业一提交就可以启动,以整个集群的利用率为代价,大作业的执行时间更长(默认的资源调度)
公平调度器:调度器在所有任务之间动态平衡
Hadoop Shuffle优化
- 增大缓冲区,减少溢写的次数
- 增加combiner,在map端聚合,减少传输的数据量
- merge合并后对文件进行压缩,减少网络传输的带宽
- 调大reduce端fetch的线程数,默认是5个
- reduce启动的时机,默认是百分之五的map完成后,就开始拉取
- 文件合并因子,默认为10
MR优化策略
- 减少数据的传输量
- 尽量使用内存
- 减少磁盘IO的次数
- 增大任务的并行度
造成数据倾斜的原因
- 分组 group by维度过小,某值的数量过多 后果:处理某值的reduce非常耗时
- distinct 某特殊值过多,处理此特殊值的reduce耗时
- join,其中一个表较小,但是key集中 分发到某一个或几个reduce上的数据远高于平均值
- 大表与大表关联,分桶的判断字段0值或空值过多 这些空值都有一个reduce处理,非常慢
Hadoop数据倾斜优化
join倾斜
map side join:将小表
group by倾斜
- 加combiner,减少数据量
- 将一个MR job拆分为两个,让第一个MR job尽可能平均的处理数据
InputFormat、OutputFormat、Split
Hadoop Hive支持的文件格式
TEXTFILE
textfile为默认格式,存储方式为行式存储,在检索时磁盘开销大,数据解析开销大
SEQUENCEFILE
二进制文件,以<key,value>的形式序列化到文件中,存储方式为行式存储,可以对文件进行分割和压缩,一般使用block压缩,使用Hadoop 的标准的Writable 接口实现序列化和反序列化
RCFILE
存储方式为数据按行分块,每块按照列存储的行列混合模式,具有压缩、列存取的特点。在使用时,读记录尽量涉及到最少的block,这样读取需要的列只需要读取每个row group的头部定义,具有明显速度优势。
Orc和Parquet
Orc是从hive的原生格式RCFILE优化改进而来
Parquet是Cloudera公司研发并开源的格式
两者都属于行列存储模式,但Orc严格上应该算是行列混合存储,首先按照行组分割整个表,在一个行组内按列进行存储
Parquet和ORC都是自解析的,文件中包含该文件的数据和元数据,Orc的元数据使用Protocol Buffers序列化
两者都支持嵌套数据格式(struct/map/list),但是策略不同:
- Parquet支持嵌套的数据模型,类似于Protocol Buffers,每个数据模型的schema报货多个字段,每个字段有三个属性:重复次数、数据类型和字段名
- ORC原生不支持嵌套数据格式,而是通过对复杂数据类型的特殊处理实现嵌套格式的支持
压缩:两者都相比txt格式进行了数据压缩,相比而言,Orc的压缩比例更大,效果更好
计算引擎支持:都支持MR、spark计算引擎
查询引擎支持:parquet被spark sql、hive、impala等支持;而Orc被spark sql、hive支持,不被impala支持。
压缩算法
参考
https://zhuanlan.zhihu.com/p/156064664?from_voters_page=true
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/147674.html原文链接:https://javaforall.cn