1.Spark源码解析2-YarnCluster模式启动
2.YARN工作原理 YARN调度器
3.开启 Kerberos 安全的大数据环境中，Yarn Container 启动失败导致作业失败
4.yarn详解
5.如何理解 yarn 的 container
6.yarn源码分析（四）AppMaster启动

Spark源码解析2-YarnCluster模式启动

       YARN 模式运行机制主要体现在Yarn Cluster 模式和Yarn Client 模式上。在Yarn Cluster模式下，SparkSubmit、ApplicationMaster 和 CoarseGrainedExecutorBackend 是独立的进程，而Driver 是摄像头PHP源码独立的线程；Executor 和 YarnClusterApplication 是对象。在Yarn Client模式下，SparkSubmit、ApplicationMaster 和 YarnCoarseGrainedExecutorBackend 也是独立的进程，而Executor和Driver是对象。

       在源码中，SparkSubmit阶段首先执行Spark提交命令，底层执行的是开启SparkSubmit进程的命令。代码中，SparkSubmit从main()开始，根据运行模式获取后续要反射调用的类名赋给元组中的ChildMainClass。如果是Yarn Cluster模式，则为YarnClusterApplication；如果是Yarn Client模式，则为主类用户自定义的qq空间病毒源码类。接下来，获取ChildMainClass后，通过反射调用main方法的过程，反射获取类然后通过构造器获取一个示例并多态为SparkApplication，再调用它的start方法。随后调用YarnClusterApplication的start方法。在YarnClient中，new一个Client对象，其中包含了yarnClient = YarnClient.createYarnClient属性，这是Yarn在SparkSubmit中的客户端，yarnClient在第行初始化和开始，即连接Yarn集群或RM。之后就可以通过这个客户端与Yarn的RM进行通信和提交应用，即调用run方法。

       ApplicationMaster阶段主要涉及开启一个Driver新线程、AM向RM注册、AM向RM申请资源并处理、封装ExecutorBackend启动命令以及AM向NM通信提交命令由NM启动ExecutorBackend。简易文章网源码在ApplicationMaster进程中，首先开启Driver线程，开始运行用户自定义代码，创建Spark程序入口SparkContext，接着创建RDD，生成job，划分阶段提交Task等操作。

       在申请资源之前，AM主线程创建了Driver的终端引用，作为参数传入createAllocator()，因为Executor启动后需要向Driver反向注册，所以启动过程必须封装Driver的EndpointRef。AM主线程向RM申请获取可用资源Container，并处理这些资源。ExecutorBackend阶段尚未完成，后续内容待补充。

YARN工作原理 YARN调度器

        旧的MapReduce架构

        、

        在Hadoop2.0中, YARN负责管理MapReduce中的资源(内存, CPU等)并且将其打包成Container. 这样可以精简MapReduce, 使之专注于其擅长的数据处理任务, 将无需考虑资源调度. YARN会管理集群中所有机器的可用计算资源. 基于这些资源YARN会调度应用(比如MapReduce)发来的资源请求, 然后YARN会通过分配Container来给每个应用提供处理能力

        在Hadoop集群中，平衡内存（RAM）、处理器（CPU核心）和磁盘的使用是至关重要的，合理规划以免某一项引起瓶颈制约。一般的建议是，一块磁盘和一个CPU核心上配置两个Container会达到集群利用率的最佳平衡,Container是YARN中处理能力的基本单元, 是对内存, CPU等的封装

        从可用的硬件资源角度看，要调整群集每个节点Yarn和MapReduce的内存配置到合适的数据，应注意以下几个重要的元素：

        保留内存=保留系统内存+保留HBase内存（如果HBase是在同一个节点）

下面的计算是确定每个节点的Container允许的最大数量。

        Container数量=min (2 CORES, 1.8 DISKS, (可用内存)/最低Container的大小)

        最低Container的大小 这个值是依赖于可用的RAM数量——在较小的存储节点，最小的Container的大小也应较小。下面的表列出了推荐值：

        最后计算的每个Container的内存大小是

        每个Container的内存大小 = max(最小Container内存大小, (总可用内存) /Container数))

        YARN 的核心就是将jobTracker的功能进行拆解，分成了资源管理和任务调度监控两个进程，一个全局的资源管理和每个作业的管理。ResourceManager和Nodemanager提供了计算资源的分配和管理，ApplicationMaster负责完成程序的运行.YARN架构下形成了一个通用的资源管理平台和一个通用的应用计算平，避免了旧架构的单点问题和资源利用率问题，同时也让在其上运行的应用不再局限于MapReduce形式

        理想情况下，我们应用对 Yarn 资源的请求应该立刻得到满足，但现实情况资源往往是

        有限的，特别是在一个很繁忙的集群，一个应用资源的请求经常需要等待一段时间才能的到

        相应的资源。在Yarn中，负责给应用分配资源的就是Scheduler。其实调度本身就是一个

        难题，很难找到一个完美的策略可以解决所有的应用场景。为此Yarn提供了多种调度器

        和可配置的策略供我们选择。在 Yarn 中有三种调度器可以选择：FIFO Scheduler ，Capacity Scheduler，Fair Scheduler。

开启 Kerberos 安全的大数据环境中，Yarn Container 启动失败导致作业失败

       在开启Kerberos安全的tensorflow源码函数解析大数据环境时，经常会遇到Yarn Container启动失败导致的spark/hive作业失败问题。以下是分析和解决这些问题的关键步骤。

       问题1：在大数据集群中开启kerberos安全认证后，提交hive on mr/hive on spark任务到YARN执行失败。查看YARN web UI，发现报错信息指向了YARN Container启动失败。

       问题2：同样地，在集群中开启kerberos安全认证并提交spark on hive任务到YARN后，执行同样失败，YARN web UI中显示了相关的错误信息。

       分析过程：在分析问题时，我们注意到在使用命令查询作业详细日志时，无法找到任何相关日志（确认了YARN已开启日志聚合），并且在HDFS文件系统中发现已创建了作业日志对应的目录，但该目录下没有文件。此外，我们注意到集群中启用了Hive代理：hive.server2.enable.doAs=true。结合YARN web UI中的卖源码还是saas关键报错信息，可以确认是因为集群中YARN nodeManager节点上没有相关业务用户，导致YARN Container启动失败，进而导致作业无法执行。

       原因：YARN Container启动失败的主要原因是YARN nodeManager节点上缺少相关的业务用户，这可能是由于用户管理配置不当、权限问题或者用户信息未正确同步等原因导致。

       解决方案：解决此问题的关键在于确保YARN nodeManager节点上包含所有需要的业务用户。这通常涉及到调整用户管理配置、确保用户信息正确同步至YARN环境，以及可能的权限管理调整。具体步骤可能包括检查HDFS和YARN的用户配置文件、验证用户信息同步机制（如Kerberos或LDAP的集成）、确保用户在YARN节点上正确创建或存在等。

       技术背景：本文由mdnice多平台发布，旨在分享大数据环境中的Kerberos安全配置与YARN作业执行问题的排查与解决策略，提供给开发者和系统管理员作为参考。

yarn详解

        yarn的组成可以从两个角度看待：

        其中，在master node上运行ResourceManager。

        每个datanode上运行一个NodeManager。

        并把该dataNode上的所有计算资源（CPU、内存）视为一个/多个Container，而Container可以被分配执行一个task(ApplicationMaster、map task、reduce task等)。

        具体可看下图：

        可结合上文的图片理解

        Container是Yarn框架的计算单元，是具体执行应用task（如map task、reduce task）的基本单位。

        Container和集群节点的关系是：一个节点会运行多个Container，但一个Container不会跨节点。

        一个Container就是一组分配的系统资源，现阶段只包含两种系统资源（之后可能会增加磁盘、网络等资源）：

        既然一个Container指的是具体节点上的计算资源，这就意味着Container中必定含有计算资源的位置信息：计算资源位于哪个机架的哪台机器上。所以我们在请求某个Container时，其实是向某台机器发起的请求，请求的是这台机器上的CPU和内存资源。

        任何一个job或application必须运行在一个或多个Container中。在Yarn框架中，ResourceManager只负责告诉ApplicationMaster哪些Containers可以用，ApplicationMaster还需要去找NodeManager请求分配具体的Container。

        NodeManager进程运行在集群中的节点上，每个节点都会有自己的NodeManager。NodeManager是一个slave服务：

        通过和ResourceManager配合，NodeManager负责整个Hadoop集群中的资源分配工作。

        NodeManager只负责管理自身的Container，它并不知道运行在它上面应用的信息。负责管理应用信息的组件是ApplicationMaster，在后面会讲到。

        ResourceManager主要有两个组件：Scheduler和ApplicationManager。

        另一个组件ApplicationManager的功能如下：

        ApplicationMaster运行在Container中。

        ApplicationMaster的主要作用是向ResourceManager申请资源并和NodeManager协同工作来运行应用的各个任务然后跟踪它们状态及监控各个任务的执行，遇到失败的任务还负责重启它。

        1.client向yarn提交job，首先找ResourceManager分配资源，

        2.ResourceManager开启一个Container,在Container中运行一个Application manager

        3.Application manager找一台nodemanager启动Application master，计算任务所需的计算

        4.Application master向Application manager（Yarn）申请运行任务所需的资源

        5.Resource scheduler将资源封装发给Application master

        6.Application master将获取到的资源分配给各个nodemanager

        7.各个nodemanager得到任务和资源开始执行map task

        8.map task执行结束后，开始执行reduce task

        9.map task和 reduce task将执行结果反馈给Application master

        .Application master将任务执行的结果反馈pplication manager。

        各个组件的功能

        一个Job的提交过程

        blogs.com/yangsy/p/.html

        功能与运行过程

        blogs.com/xwdreamer/archive////.html

如何理解 yarn 的 container

       ã€€ã€€container就是“一组资源”，现在是“内存+CPU”，未来还有可能把网络带宽之类的也包含进去。

       ã€€ã€€å½“有一个Application（在MRV1里叫Job），第一个container就用来跑ApplicationMaster，然后ApplicationMaster再申请一些container来跑Mapper，之后再申请一些container来跑Reducer。

       ã€€ã€€container既可以跑Mapper也可以跑Reducer，就不像MRV1里的map slot只能跑map、reduce slot只能跑reduce。

yarn源码分析（四）AppMaster启动

       在容器分配完成之后，启动容器的代码主要在ContainerImpl.java中进行。通过状态机转换，container从NEW状态向其他状态转移时，会调用RequestResourceTransition对象。RequestResourceTransition负责将所需的资源进行本地化，或者避免资源本地化。若需本地化，还需过渡到LOCALIZING状态。为简化理解，此处仅关注是否进行资源本地化的情况。

       为了将LAUNCH_CONTAINER事件加入事件处理队列，调用了sendLaunchEvent方法。该事件由ContainersLauncher负责处理。ContainersLauncher的handle方法中，使用一个ExecutorService（线程池）容器Launcher。ContainerLaunch实现了Callable接口，其call方法生成并执行launch_container脚本。以MapReduce框架为例，该脚本在hadoop.tmp.dir/application name/container name目录下生成，其主要作用是启动MRAppMaster进程，即MapReduce的ApplicationMaster。

深入理解 Hadoop （七）YARN资源管理和调度详解

       Hadoop最初为批处理设计，其资源管理与调度仅支持FIFO机制。然而，随着Hadoop的普及与用户量的增加，单个集群内的应用程序类型与数量激增，FIFO调度机制难以高效利用资源，也无法满足不同应用的服务质量需求，故需设计适用于多用户的资源调度系统。

       YARN采用双层资源调度模型：ResourceManager中的资源调度器分配资源给ApplicationMaster，由YARN决定；ApplicationMaster再将资源分配给内部任务Task，用户自定。YARN作为统一调度系统，满足调度规范的分布式应用皆可在其中运行，调度规范包括定义ApplicationMaster向RM申请资源，AM自行完成Container至Task分配。YARN采用拉模型实现异步资源分配，RM分配资源后暂存缓冲区，等待AM通过心跳获取。

       Hadoop-2.x版本中YARN提供三种资源调度器，分别为...

       YARN的队列管理机制包括用户权限管理与系统资源管理两部分。CapacityScheduler的核心特点包括...

       YARN的更多理解请参考官方文档：...

       在分布式资源调度系统中，资源分配保证机制常见有...

       YARN采用增量资源分配，避免浪费但不会出现资源饿死现象。YARN默认资源分配算法为DefaultResourceCalculator，专注于内存调度。DRF算法将最大最小公平算法应用于主资源上，解决多维资源调度问题。实例分析中，系统中有9个CPU和GB RAM，两个用户分别运行两种任务，所需资源分别为...

       资源抢占模型允许每个队列设定最小与最大资源量，以确保资源紧缺与极端情况下的需求。资源调度器在负载轻队列空闲时会暂时分配资源给负载重队列，仅在队列突然收到新提交应用程序时，调度器将资源归还给该队列，避免长时间等待。

       YARN最初采用平级队列资源管理，新版本改用层级队列管理，优点包括...

       CapacityScheduler配置文件capacity-scheduler.xml包含资源最低保证、使用上限与用户资源限制等参数。管理员修改配置文件后需运行"yarn rmadmin -refreshQueues"。

       ResourceScheduler作为ResourceManager中的关键组件，负责资源管理和调度，采用可插拔策略设计。初始化、接收应用和资源调度等关键功能实现，RM收到NodeManager心跳信息后，向CapacityScheduler发送事件，调度器执行一系列操作。

       CapacityScheduler源码解读涉及树型结构与深度优先遍历算法，以保证队列优先级。其核心方法包括...

       在资源分配逻辑中，用户提交应用后，AM申请资源，资源表示为Container，包含优先级、资源量、容器数目等信息。YARN采用三级资源分配策略，按队列、应用与容器顺序分配空闲资源。

       对比FairScheduler，二者均以队列为单位划分资源，支持资源最低保证、上限与用户限制。最大最小公平算法用于资源分配，确保资源公平性。

       最大最小公平算法分配示意图展示了资源分配过程与公平性保证。