Hadoop解决两件事:
在Hadoop1.x
时期,Hadoop中的MapReduce同时处理业务逻辑运算和资源的调度,耦合性较大(低耦合才好,高内聚低耦合嘛)。
在Hadoop2.x
时期,增加了Yarn。Yarn只负责资源的调度,MapReduce只负责运算。
Hadoop3.x
在组成上没有变化
Hadoop Distributed File System,简称 HDFS,是一个分布式文件系统。主要解决海量数据的存储问题。
(1)NameNode(NN):存储文件的元数据
,如文件名
,文件目录结构
,文件属性
(生成时间、副本数、文件权限),和每个文件的块列表
和块所在的DataNode
等。
(2)DataNode(DN):在本地文件系统存储文件块数据
,以及块数据的校验和
。
(3)SecondaryNameNode(2NN):每隔一段时间对NameNode元数据进行备份
。
MapReduce是一个分布式运算程序的编程框架,核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序,并发运行在一个Hadoop集群上。
MapReduce 将计算过程分为两个阶段:Map 和 Reduce
Yet Another Resource Negotiator,简称 YARN ,是另一种资源协调者,是Hadoop的资源管理器。
(1)ResourceManager(RM):整个集群资源(内存、CPU等)的老大(管理者)。
(2)NodeManager(NM):单个节点服务器资源老大(管理者)。
(3)ApplicationMaster(AM):单个任务运行的老大(管理者)。
(4)Container :容器,相当于一台独立的服务器,里面封装了任务运行所需要的资源,如内存、CPU、磁盘、网络等。
说明:
企业大都在用 Hadoop2.x ,但 3.x 是个趋势,所以 额额 都要会。
端口名称 | Hadoop2.x | Hadoop3.x |
---|---|---|
NameNode 内部通信端口 | 8020 / 9000 | 8020 / 9000 / 9820 |
NameNode 对用户的查询端口 | 50070 | 9870 |
Yarn 查看任务运行情况端口 | 8088 | 8088 |
历史服务器通信端口 | 19888 | 19888 |
Hadoop2.x
:core-site.xml 、hdfs-site.xml 、mapred-site.xml 、yarn-site.xml 、slaves
Hadoop3.x
:core-site.xml 、hdfs-site.xml 、mapred-site.xml 、yarn-site.xml 、workers
HDFS中的文件在物理上是分块存储的(Block),块的大小可以通过配置参数(dfs.blocksize)来规定,默认大小在 Hadoop2.x / 3.x 版本中是128M,1.x版本中是64M 。(中小公司一般128M)
思考:为什么块的大小不能设置太小,也不能设置太大?
(1)HDFS的块设置太小
,会增加寻址时间,程序一直在找块的开始位置。
(2)如果块设置的太大
,从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。导致程序在处理这块数据时,会非常慢。(另外,块设置的太大还叫啥分布式存储呀,没意义了)
总结:HDFS块大小的设置主要取决于磁盘传输速率。
我在 HDFS的Shell操作 这篇文章里详细写了,这里就不多说了。
(1)客户端通过 Distributed FileSystem 模块向 NameNode 请求上传文件,NameNode检查权限(每个文件都有所属的用户、用户组);目标文件是否已存在,父目录是否存在。
(2)NameNode 向客户端回答是否可以上传。
(3)客户端请求第一个 Block 上传到哪几个 DataNode 服务器上。
(4)NameNode 返回3个 DataNode 节点,分别为DN1、DN2、DN3,表示采用这三个节点存储数据。
(5)客户端通过 FSDataOutputStream 模块请求DN1上传数据,DN1收到请求会继续调用DN2,然后DN2调用DN3,将这个通信管道建立完成。
(6)DN1、DN2、DN3逐级应答客户端。
(7)客户端开始往DN1上传第一个Block(先从磁盘读取数据放到一个本地内存缓存),以Packet为单位,DN1收到一个Packet就会传给DN2,DN2传给DN3;DN1 每传一个packet会放入一个应答队列等待应答。(防止发送失败,备份了一份下次还可以重发)
(8)当一个Block传输完成之后,客户端再次请求NameNode上传第二个Block的服务器。(重复执行3-7步)。
(1)客户端通过 DistributedFileSystem 向 NameNode 请求下载文件,NameNode 通过查询元数据,找到文件块所在的 DataNode 地址。
(2)挑选一台 DataNode服务器(考虑:就近原则,负载均衡),请求读取数据。
(3)DataNode 开始传输数据给客户端(从磁盘里面读取数据输入流,以Packet为单位来做校验)。
(4)客户端以Packet为单位接收,先在本地缓存,然后写入目标文件。
一、输入数据接口:InputFormat
(1)默认使用的实现类是:TextInputFormat 输入kv:key 偏移量 ;v 一行内容。
TextInputFormat的功能逻辑是:一次读一行文本,然后将该行的起始偏移量作为key,行内容作为value返回。
(2)处理小文件是:CombineTextInputFormat,把多个小文件合并到一起统一切片,提高处理效率。
二、逻辑处理接口:Mapper
用户根据业务需求实现其中三个方法:setup() 初始化 、map() 用户的业务逻辑 、clearup() 关闭资源
三、分区:Partitioner
(1)默认分区 HashPartitioner,按照 key的 hash值%numReduceTask 个数进行分区。
(2)如果业务上有特别的需求,可以自定义分区。
四、排序:Comparable
(1)部分排序:每个输出的文件内部有序。但多个文件整体上是无序的。
(2)全排序:一个reduce,对所有数据进行排序。(企业中慎用,所有数据进入一个reduce,容易撑爆)
(3)二次排序:自定义排序范畴,实现 writableComparable 接口,重写 compareTo 方法。
(4)当我们用自定义的对象作为key来输出时,就必须要实现writableComparable接口,重写其中的compareTo()方法。
五、合并:Combiner
Combiner合并可以提高程序执行效率,减少IO传输。但是使用时必须不能影响原有的业务处理结果。
使用前提:不影响最终的业务逻辑。(求和可以,求平均值不行)
好处:提前预聚合map —— 也是解决数据倾斜的办法。(mapTask个数多,每个都分担一点,减小了所有数据全部传入一个Reduce的压力,所以能在map阶段处理的尽量在map阶段早处理)
六、逻辑处理接口:Reducer
用户根据业务需求实现其中三个方法:setup() 初始化 、reduce() 用户的业务逻辑 、clearup() 关闭资源
七、输出数据接口:OutputFormat
(1)默认实现类是 TextOutputFormat ,按行输出到文件。功能逻辑是:将每一个KV对,向目标文本文件输出一行。
(2)用户还可以自定义OutputFormat。
(1)首先客户端对待处理的文件进行切片操作
(2)然后客户端向yarn提交三个文件,job的切片、jar包、job的xml(存放job运行相关参数)
(3)yarn会开启一个MrAppMaster(整个任务的管理者)去读取客户端提供的信息,根据切片信息对应开启MapTask的个数
(4)MapTask通过InputFormat读取待处理文件,默认是TestInputFormat,读完后把数据返回给Mapper
(5)Mapper通过用户自己写的业务逻辑进行计算
(6)Mapper计算完后将数据输出到环形缓冲区,环形缓冲区默认大小是100M,数据量到达80%时进行反向溢写
(7)溢写前对分区内数据进行排序,排序规则是快速排序(数据写入环形缓冲区之前就已经分好区了,此时不用分区直接排序即可)
(8)当数据量达到80%时,将环形缓冲区里分区且区内有序的数据溢写到磁盘上
(9)使用归并排序,保证每个分区内部是有序的。把排好序的数据存储到磁盘上
(10)Combiner对数据进行预聚合,优化reduce效率
(11)所有MapTask任务完成后,启动相应数量的ReduceTask,并告知ReduceTask数据的分区
(12)ReduceTask主动拉取mapTask中指定分区的数据,存储到磁盘上
(13)将从各mapTask中拉取的数据进行合并并排序,排序规则是归并排序
(14)Reducer一次读取一组相同key的数据
(15)由OutPutFormat将reducer的数据往文件中写,默认使用TextOutPutFormat
Map方法之后,Reduce方法之前的数据处理过程称之为Shuffle。
(1)从Map方法出来后,数据先进入getPartition方法,标记数据是哪一个分区
(2)之后进入环形缓冲区,环形缓冲区默认大小100M,左侧存索引,右侧存数据,数据量到达80%进行反向溢写
(3)溢写前还要对数据进行排序,排序方式是快速排序,对key的索引按照字典顺序排
(4)溢写会产生两个文件,溢写的index索引文件和溢写的真正数据文件
(5)在聚合操作的场景下也有Combiner,Combiner对数据进行预聚合,使传输到reduce端的数据量小了,优化reduce效率
(6)使用归并排序,保证每个分区内部是有序的
(7)数据按照分区写在磁盘上,等待reduce端拉取
(8)ReduceTask拉取指定分区的数据,数据先存放在内存中,如果内存不够会溢写到磁盘上
(9)对每个map来的数据归并排序
(10)按照相同key分组,进入Reduce方法
(0)MR(MapReduce)程序提交到客户端所在的节点。
(1)YarnRunner向ResourceManager申请一个Application。
(2)RM将该应用程序的资源路径返回给YarnRunner。
(3)该程序将运行所需资源提交到HDFS上。
(4)程序资源提交完毕后,申请运行MrAppMaster。
(5)RM将用户的请求初始化成一个Task。
(6)其中一个NodeManager领取到Task任务。
(7)该NodeManager创建容器Container(因为任何任务的执行都是在容器里面执行的),并启动MrAppMaster进程。
(8)Container从HDFS上拷贝资源到本地。
(9)MRAppmaster向RM申请运行MapTask资源。
(10)RM将运行MapTask任务分配给另外两个NodeManager,它们分别领取任务并创建容器(有几个切片就开启几个Container容器)。
(11)MR向两个接收到任务的NodeManager发送程序启动脚本,这两个NodeManager分别启动MapTask,MapTask对数据分区排序。
(12)MrAppMaster等待所有MapTask运行完毕后,向RM申请容器,运行ReduceTask程序。
(13)ReduceTask向MapTask获取相应分区的数据。
(14)程序运行完毕后,MR会向RM申请注销自己,同时相关的MapReduce的资源也释放掉。
(1)调度器有三种:
FIFO(先进先出)、Capacity Scheduler(容量调度器)和Fair Sceduler(公平调度器)。
Apache 默认的资源调度器是 容量调度器;
CDH 默认的资源调度器是 公平调度器。
容量和公平调度器默认都是只有一个default队列,一个default队列在生产环境中不能满足并发要求,所以要创建多队列。
(2)每个调度器特点:
FIFO调度器:支持单队列 、先进先出。生产环境不会用。
容量调度器:支持多队列,保证先进入的任务优先执行。
公平调度器:支持多队列,保证队列里的每个任务公平享有队列资源。 资源不够时可以按照缺额分配。
(3)在生产环境下怎么选择?
中小公司:对并发度要求不高,集群服务器资源不太充裕,选择容量。
大厂:对并发度要求比较高,选择公平,要求服务器性能必须OK;
(4)在生产环境怎么创建多队列? —— 调度器默认就1个default队列,不能满足生产要求
按照框架(小企业):hive /spark/ flink 每个框架的任务放入指定的队列(企业用的不是特别多)
按照业务模块(中大企业):登录注册、购物车、下单、业务部门1、业务部门2
业务部门1(重要)→ 业务部门2(比较重要)→ 下单(一般)→ 购物车(一般)→ 登录注册(次要)
(5)创建多队列的好处?
降低风险:防止员工不小心写递归死循环代码,把所有资源全部耗尽,导致整个集群瘫痪。
降级使用:实现任务的降级使用,特殊时期(双11、618)保证重要的任务队列资源充足。