【大数据】Hadoop 体系（二）_如何理解hadoop分治思想

Hadoop

三、Hadoop MapReduce与Hadoop YARN

1. Hadoop MapReduce

1.1 理解MapReduce思想

• MapReduce的思想核心是“先分再合，分而治之”。
• 所谓“分而治之”就是把一个复杂的问题，按照一定的“分解”方法分为等价的规模较小的若干部分，然后逐个解决，分别找出各部分的结果，然后把各部分的结果组成整个问题的最终结果。
• 这种思想来源于日常生活与工作时的经验。即使是发布过论文实现分布式计算的谷歌也只是实现了这种思想，而不是自己原创。
• Map表示第一阶段，负责“拆分”：即把复杂的任务分解为若干个“简单的子任务”来并行处理。可以进行拆分的前提是这些小任务可以并行计算，彼此间几乎没有依赖关系。
• Reduce表示第二阶段，负责“合并”：即对map阶段的结果进行全局汇总。
• 这两个阶段合起来正是MapReduce思想的体现。
  
• 一个比较形象的语言解释MapReduce
  • 要数停车场中的所有停放车的总数量。
  • 你数第一列，我数第二列…这就是Map阶段，人越多，能够同时数车的人就越多，速度就越快。
  • 数完之后，聚到一起，把所有人的统计数加在一起。这就是Reduce合并汇总阶段。

1.2 Hadoop MapReduce设计构思

• 如何对付大数据处理场景
  • 对相互间不具有计算依赖关系的大数据计算任务，实现并行最自然的办法就是采取MapReduce分而治之的策略。
  • 首先Map阶段进行拆分，把大数据拆分成若干份小数据，多个程序同时并行计算产生中间结果；然后是Reduce聚合阶段，通过程序对并行的结果进行最终的汇总计算，得出最终的结果。
  • 不可拆分的计算任务或相互间有依赖关系的数据无法进行并行计算！
    
• 构建抽象编程模型
  • MapReduce借鉴了函数式语言中的思想，用Map和Reduce两个函数提供了高层的并行编程抽象模型。
  • map: 对一组数据元素进行某种重复式的处理；
  • reduce: 对Map的中间结果进行某种进一步的结果整理。
    
  • MapReduce中定义了如下的Map和Reduce两个抽象的编程接口，由用户去编程实现:
    • map: (k1; v1) → (k2; v2)
    • reduce: (k2; [v2]) → (k3; v3)
  • 通过以上两个编程接口，大家可以看出MapReduce处理的数据类型是<key,value>键值对。
• 统一架构、隐藏底层细节
  • 如何提供统一的计算框架，如果没有统一封装底层细节，那么程序员则需要考虑诸如数据存储、划分、分发、结果收集、错误恢复等诸多细节；为此，MapReduce设计并提供了统一的计算框架，为程序员隐藏了绝大多数系统层面的处理细节。
  • MapReduce最大的亮点在于通过抽象模型和计算框架把需要做什么(what need to do)与具体怎么做(how to do)分开了，为程序员提供一个抽象和高层的编程接口和框架。
  • 程序员仅需要关心其应用层的具体计算问题，仅需编写少量的处理应用本身计算问题的业务程序代码。
  • 至于如何具体完成这个并行计算任务所相关的诸多系统层细节被隐藏起来,交给计算框架去处理：从分布代码的执行，到大到数千小到单个节点集群的自动调度使用。

1.3 Hadoop MapReduce介绍

• 分布式计算概念
  • 分布式计算是一种计算方法，和集中式计算是相对的。
  • 随着计算技术的发展，有些应用需要非常巨大的计算能力才能完成，如果采用集中式计算，需要耗费相当长的时间来完成。
  • 分布式计算将该应用分解成许多小的部分，分配给多台计算机进行处理。这样可以节约整体计算时间，大大提高计算效率。
    
• MapReduce介绍
  • Hadoop MapReduce是一个分布式计算框架，用于轻松编写分布式应用程序，这些应用程序以可靠，容错的方式并行处理大型硬件集群（数千个节点）上的大量数据（多TB数据集）。
  • MapReduce是一种面向海量数据处理的一种指导思想，也是一种用于对大规模数据进行分布式计算的编程模型。
• MapReduce产生背景
  • MapReduce最早由Google于2004年在一篇名为《MapReduce:Simplified Data Processingon Large Clusters》的论文中提出。
  • 论文中谷歌把分布式数据处理的过程拆分为Map和Reduce两个操作函数（受到函数式编程语言的启发），随后被Apache Hadoop参考并作为开源版本提供支持，叫做Hadoop MapReduce。
  • 它的出现解决了人们在最初面临海量数据束手无策的问题，同时它还是易于使用和高度可扩展的，使得开发者无需关系分布式系统底层的复杂性即可很容易的编写分布式数据处理程序，并在成千上万台普通的商用服务器中运行。
• MapReduce特点
  • 易于编程
    • Mapreduce框架提供了用于二次开发的接口；简单地实现一些接口，就可以完成一个分布式程序。任务计算交给计算框架去处理，将分布式程序部署到hadoop集群上运行，集群节点可以扩展到成百上千个等。
  • 良好的扩展性
    • 当计算机资源不能得到满足的时候，可以通过增加机器来扩展它的计算能力。基于MapReduce的分布式计算得特点可以随节点数目增长保持近似于线性的增长，这个特点是MapReduce处理海量数据的关键，通过将计算节点增至几百或者几千可以很容易地处理数百TB甚至PB级别的离线数据。
  • 高容错性
    • Hadoop集群是分布式搭建和部署的，任何单一机器节点宕机了，它可以把上面的计算任务转移到另一个节点上运行，不影响整个作业任务得完成，过程完全是由Hadoop内部完成的。
  • 适合海量数据的离线处理
    • 可以处理GB、TB和PB级别的数据量
• MapReduce局限性
  • MapReduce虽然有很多的优势，也有相对的局限性，局限性不代表不能做，而是在有些场景下实现的效果比较差，并不适合用MapReduce来处理，主要表现在以下结果方面：
  • 实时计算性能差
    • MapReduce主要应用于离线作业，无法做到秒级或者是亚秒级得数据响应。
  • 不能进行流式计算
    • 流式计算特点是数据是源源不断得计算，并且数据是动态的；而MapReduce作为一个离线计算框架，主要是针对静态数据集的，数据是不能动态变化的。
• MapReduce实例进程
  • 一个完整的MapReduce程序在分布式运行时有三类
    • MRAppMaster：负责整个MR程序的过程调度及状态协调
    • MapTask：负责map阶段的整个数据处理流程
    • ReduceTask：负责reduce阶段的整个数据处理流程
      
• 阶段组成
  • 一个MapReduce编程模型中只能包含一个Map阶段和一个Reduce阶段，或者只有Map阶段；
  • 不能有诸如多个map阶段、多个reduce阶段的情景出现；
  • 如果用户的业务逻辑非常复杂，那就只能多个MapReduce程序串行运行。
    
• MapReduce数据类型
  • 注意：整个MapReduce程序中，数据都是以kv键值对的形式流转的；
  • 在实际编程解决各种业务问题中，需要考虑每个阶段的输入输出kv分别是什么；
  • MapReduce内置了很多默认属性，比如排序、分组等，都和数据的k有关，所以说kv的类型数据确定及其重要的。
    

1.4 Hadoop MapReduce官方示例

• 概述

  • 一个最终完整版本的MR程序需要用户编写的代码和Hadoop自己实现的代码整合在一起才可以；
  • 其中用户负责map、reduce两个阶段的业务问题，Hadoop负责底层所有的技术问题；
  • 由于MapReduce计算引擎天生的弊端（慢），当下企业中直接使用率已经日薄西山了，所以在企业中工作很少涉及到MapReduce直接编程，但是某些软件的背后还依赖MapReduce引擎。
  • 可以通过官方提供的示例来感受MapReduce及其内部执行流程，因为后续的新的计算引擎比如Spark，当中就有MapReduce深深的影子存在。

• 示例说明

  • 示例程序路径：/export/server/hadoop-3.3.0/share/hadoop/mapreduce/
  • 示例程序：hadoop-mapreduce-examples-3.3.0.jar
  • MapReduce程序提交命令：[hadoop jar|yarn jar] hadoop-mapreduce-examples-3.3.0.jar args…
  • 提交到哪里去？提交到YARN集群上分布式执行。

• 评估圆周率π（PI）的值

  • 圆周率π大家都不陌生，如何去估算π的值呢？
  • Hadoop MapReduce示例提供了Monte Carlo方法计算圆周率。
    
  • 运行MapReduce程序评估一下圆周率的值，执行中可以去YARN页面上观察程序的执行的情况。
    • 第一个参数：pi表示MapReduce程序执行圆周率计算任务；
    • 第二个参数：用于指定map阶段运行的任务task次数，并发度，这里是10；
    • 第三个参数：用于指定每个map任务取样的个数，这里是50。

  [root@node1 mapreduce]# pwd
  /export/server/hadoop-3.3.0/share/hadoop/mapreduce
  [root@node1 mapreduce]# hadoop jar hadoop-mapreduce-examples-3.3.0.jar pi 10 50

• Wordcount单词词频统计（指的是统计指定文件中，每个单词出现的总次数。）

  • WordCount概述
    • WordCount算是大数据计算领域经典的入门案例，相当于Hello World。
      
  • WordCount编程实现思路
    • map阶段的核心：把输入的数据经过切割，全部标记1，因此输出就是<单词，1>。
    • shuffle阶段核心：经过MR程序内部自带默认的排序分组等功能，把key相同的单词会作为一组数据构成新的kv对。
    • reduce阶段核心：处理shuffle完的一组数据，该组数据就是该单词所有的键值对。对所有的1进行累加求和，就是单词的总次数。
      
  • WordCount程序提交
    • 上传文本文件1.txt到HDFS文件系统的/input目录下，如果没有这个目录，使用shell创建
      • hadoop fs -mkdir /input
      • hadoop fs -put 1.txt /input
    • 准备好之后，执行官方MapReduce实例，对上述文件进行单词次数统计
      • 第一个参数：wordcount表示执行单词统计任务；
      • 第二个参数：指定输入文件的路径；
      • 第三个参数：指定输出结果的路径（该路径不能已存在）；

  [root@node1 mapreduce]# pwd
  /export/server/hadoop-3.3.0/share/hadoop/mapreduce
  [root@node1 mapreduce]# hadoop jar hadoop-mapreduce-examples-3.3.0.jar wordcount /input /output

1.5 Map阶段执行流程

• 第一阶段：把输入目录下文件按照一定的标准逐个进行逻辑切片，形成切片规划。
  • 默认Split size = Block size（128M），每一个切片由一个MapTask处理。（getSplits）
• 第二阶段：对切片中的数据按照一定的规则读取解析返回<key,value>对。
  • 默认是按行读取数据。key是每一行的起始位置偏移量，value是本行的文本内容。（TextInputFormat）
• 第三阶段：调用Mapper类中的map方法处理数据。
  • 每读取解析出来的一个<key,value> ，调用一次map方法。
• 第四阶段：按照一定的规则对Map输出的键值对进行分区partition。
  • 默认不分区，因为只有一个reducetask。分区的数量就是reducetask运行的数量。
• 第五阶段：Map输出数据写入内存缓冲区，达到比例溢出到磁盘上。溢出spill的时候根据key进行排序sort。
  • 默认根据key字典序排序。
• 第六阶段：对所有溢出文件进行最终的merge合并，成为一个文件。
  

1.6 Reduce阶段执行流程

• 第一阶段：ReduceTask会主动从MapTask复制拉取属于需要自己处理的数据。
• 第二阶段：把拉取来数据，全部进行合并merge，即把分散的数据合并成一个大的数据。再对合并后的数据排序。
• 第三阶段是对排序后的键值对调用reduce方法。键相等的键值对调用一次reduce方法。最后把这些输出的键值对写入到HDFS文件中。
  

1.7 shuffle机制

• shuffle概念
  • Shuffle的本意是洗牌、混洗的意思，把一组有规则的数据尽量打乱成无规则的数据。
  • 而在MapReduce中，Shuffle更像是洗牌的逆过程，指的是将map端的无规则输出按指定的规则“打乱”成具有一定规则的数据，以便reduce端接收处理。
  • 一般把从Map产生输出开始到Reduce取得数据作为输入之前的过程称作shuffle。
    
• Map端Shuffle
  • Collect阶段：将MapTask的结果收集输出到默认大小为100M的环形缓冲区，保存之前会对key进行分区的计算，默认Hash分区。
  • Spill阶段：当内存中的数据量达到一定的阀值的时候，就会将数据写入本地磁盘，在将数据写入磁盘之前需要对数据进行一次排序的操作，如果配置了combiner，还会将有相同分区号和key的数据进行排序。
  • Merge阶段：把所有溢出的临时文件进行一次合并操作，以确保一个MapTask最终只产生一个中间数据文件。
    
• Reducer端shuffle
  • Copy阶段： ReduceTask启动Fetcher线程到已经完成MapTask的节点上复制一份属于自己的数据。
  • Merge阶段：在ReduceTask远程复制数据的同时，会在后台开启两个线程对内存到本地的数据文件进行合并操作。
  • Sort阶段：在对数据进行合并的同时，会进行排序操作，由于MapTask阶段已经对数据进行了局部的排序，ReduceTask只需保证Copy的数据的最终整体有效性即可。
    
• shuffle机制弊端
  • Shuffle是MapReduce程序的核心与精髓，是MapReduce的灵魂所在。
  • Shuffle也是MapReduce被诟病最多的地方所在。MapReduce相比较于Spark、Flink计算引擎慢的原因，跟Shuffle机制有很大的关系。
  • Shuffle中频繁涉及到数据在内存、磁盘之间的多次往复。

2. Hadoop YARN

2.1 Hadoop YARN介绍

• YARN简介
  • Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的Hadoop资源管理器。
  • YARN是一个通用资源管理系统和调度平台，可为上层应用提供统一的资源管理和调度。
  • 它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
    
• YARN功能说明
  • 资源管理系统：集群的硬件资源，和程序运行相关，比如内存、CPU等。
  • 调度平台：多个程序同时申请计算资源如何分配，调度的规则（算法）。
  • 通用：不仅仅支持MapReduce程序，理论上支持各种计算程序。YARN不关心你干什么，只关心你要资源，在有的情况下给你，用完之后还我。
• YARN概述
  • 可以把Hadoop YARN理解为相当于一个分布式的操作系统平台，而MapReduce等计算程序则相当于运行于操作系统之上的应用程序，YARN为这些程序提供运算所需的资源（内存、CPU等）。
  • Hadoop能有今天这个地位，YARN可以说是功不可没。因为有了YARN ，更多计算框架可以接入到 HDFS中，而不单单是 MapReduce，正是因为YARN的包容，使得其他计算框架能专注于计算性能的提升。
  • HDFS可能不是最优秀的大数据存储系统，但却是应用最广泛的大数据存储系统， YARN功不可没。

2.2 Hadoop YARN架构、组件

• YARN官方架构图
  
  
• YARN3大组件
  • ResourceManager（RM）
    • YARN集群中的主角色，决定系统中所有应用程序之间资源分配的最终权限，即最终仲裁者。
    • 接收用户的作业提交，并通过NM分配、管理各个机器上的计算资源。
  • NodeManager（NM）
    • YARN中的从角色，一台机器上一个，负责管理本机器上的计算资源。
    • 根据RM命令，启动Container容器、监视容器的资源使用情况。并且向RM主角色汇报资源使用情况。
  • ApplicationMaster（AM）
    • 用户提交的每个应用程序均包含一个AM。
    • 应用程序内的“老大”，负责程序内部各阶段的资源申请，监督程序的执行情况。

2.3 程序提交YARN交互流程

• 核心交互流程
  • MR作业提交 Client–>RM
  • 资源的申请 MrAppMaster–>RM
  • MR作业状态汇报 Container（Map|Reduce Task）–>Container（MrAppMaster）
  • 节点的状态汇报 NM–>RM
• 整体概述
  • 当用户向 YARN 中提交一个应用程序后， YARN将分两个阶段运行该应用程序 。
    • 第一个阶段是客户端申请资源启动运行本次程序的ApplicationMaster；
    • 第二个阶段是由ApplicationMaster根据本次程序内部具体情况，为它申请资源，并监控它的整个运行过程，直到运行完成。
• MR提交YARN交互流程
  • 第1步、用户通过客户端向YARN中ResourceManager提交应用程序（比如hadoop jar提交MR程序）；
  • 第2步、ResourceManager为该应用程序分配第一个Container（容器），并与对应的NodeManager通信，要求它在这个Container中启动这个应用程序的ApplicationMaster。
  • 第3步、ApplicationMaster启动成功之后，首先向ResourceManager注册并保持通信，这样用户可以直接通过 ResourceManage 查看应用程序的运行状态（处理了百分之几）;
  • 第4步、AM为本次程序内部的各个Task任务向RM申请资源，并监控它的运行状态;
  • 第5步、一旦 ApplicationMaster 申请到资源后，便与对应的 NodeManager 通信，要求它启动任务。
  • 第6步、NodeManager 为任务设置好运行环境后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
  • 第7步、各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过
    RPC 向 ApplicationMaster 查询应用程序的当前运行状态。
  • 第8步、应用程序运行完成后，ApplicationMaster 向 ResourceManager 注销并关闭自己。
    

2.4 YARN资源调度器Scheduler

• 如何理解资源调度
  • 在理想情况下，应用程序提出的请求将立即得到YARN批准。但是实际中，资源是有限的，并且在繁忙的群集上，应用程序通常将需要等待其某些请求得到满足。YARN调度程序的工作是根据一些定义的策略为应用程序分配资源。
  • 在YARN中，负责给应用分配资源的就是Scheduler，它是ResourceManager的核心组件之一。Scheduler完全专用于调度作业，它无法跟踪应用程序的状态。
  • 一般而言，调度是一个难题，并且没有一个“最佳”策略，为此，YARN提供了多种调度器和可配置的策略供选择。
• 调度器策略
  • 三种调度器
    • FIFO Scheduler（先进先出调度器）、Capacity Scheduler（容量调度器）、Fair Scheduler（公平调度器）。
  • Apache版本YARN默认使用Capacity Scheduler。
  • 如果需要使用其他的调度器，可以在yarn-site.xml中的yarn.resourcemanager.scheduler.class进行配置。
• FIFO Scheduler概述
  • FIFO Scheduler是Hadoop1.x中JobTracker原有的调度器实现，此调度器在YARN中保留了下来。
  • FIFO Scheduler是一个先进先出的思想，即先提交的应用先运行。调度工作不考虑优先级和范围，适用于负载较低的小规模集群。当使用大型共享集群时，它的效率较低且会导致一些问题。
  • FIFO Scheduler拥有一个控制全局的队列queue，默认queue名称为default，该调度器会获取当前集群上所有的资源信息作用于这个全局的queue。
  • 优势：无需配置、先到先得、易于执行
  • 坏处：任务的优先级不会变高，因此高优先级的作业需要等待不适合共享集群
• Capacity Scheduler概述
  • Capacity Scheduler容量调度是Apache Hadoop3.x默认调度策略。该策略允许多个组织共享整个集群资源，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。
  • Capacity可以理解成一个个的资源队列，这个资源队列是用户自己去分配的。队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。
  • Capacity Scheduler调度器以队列为单位划分资源。简单通俗点来说，就是一个个队列有独立的资源，队列的结构和资源是可以进行配置的。
• Capacity Scheduler特性优势
  • 层次化的队列设计（Hierarchical Queues）
    • 层次化的管理，可以更容易、更合理分配和限制资源的使用。
  • 容量保证（Capacity Guarantees）
    • 每个队列上都可以设置一个资源的占比，保证每个队列都不会占用整个集群的资源。
  • 安全（Security）
    • 每个队列有严格的访问控制。用户只能向自己的队列里面提交任务，而且不能修改或者访问其他队列的任务。
  • 弹性分配（Elasticity）
    • 空闲的资源可以被分配给任何队列。
    • 当多个队列出现争用的时候，则会按照权重比例进行平衡。
• Fair Scheduler概述
  • Fair Scheduler叫做公平调度，提供了YARN应用程序公平地共享大型集群中资源的另一种方式。使所有应用在平均情况下随着时间的流逝可以获得相等的资源份额。
  • Fair Scheduler设计目标是为所有的应用分配公平的资源（对公平的定义通过参数来设置）。
  • 公平调度可以在多个队列间工作，允许资源共享和抢占。
• 如何理解公平共享
  • 有两个用户A和B，每个用户都有自己的队列。
  • A启动一个作业，由于没有B的需求，它分配了集群所有可用的资源。
  • 然后B在A的作业仍在运行时启动了一个作业，经过一段时间，A,B各自作业都使用了一半的资源。
  • 现在，如果B用户在其他作业仍在运行时开始第二个作业，它将与B的另一个作业共享其资源，因此B的每个作业将拥有资源的四分之一，而A的继续将拥有一半的资源。结果是资源在用户之间公平地共享。
• Fair Scheduler特性优势
  • 分层队列：队列可以按层次结构排列以划分资源，并可以配置权重以按特定比例共享集群。
  • 基于用户或组的队列映射：可以根据提交任务的用户名或组来分配队列。如果任务指定了一个队列,则在该队列中提交任务。
  • 资源抢占：根据应用的配置，抢占和分配资源可以是友好的或是强制的。默认不启用资源抢占。
  • 保证最小配额：可以设置队列最小资源，允许将保证的最小份额分配给队列，保证用户可以启动任务。当队列不能满足最小资源时,可以从其它队列抢占。当队列资源使用不完时,可以给其它队列使用。这对于确保某些用户、组或生产应用始终获得足够的资源。
  • 允许资源共享：即当一个应用运行时,如果其它队列没有任务执行,则可以使用其它队列,当其它队列有应用需要资源时再将占用的队列释放出来。所有的应用都从资源队列中分配资源。
  • 默认不限制每个队列和用户可以同时运行应用的数量。可以配置来限制队列和用户并行执行的应用数量。限制并行执行应用数量不会导致任务提交失败,超出的应用会在队列中等待。