Yarn_基础库

1. 概述

   YARN 基础库是其他一切模块的基础，它的设计直接决定了YARN 的稳定性和扩展性，概括起来，YARN 的基础库主要有以下几个。
   ❑ Protocol Buffers ：Protocol Buffers 是 Google 开源的序列化库，具有平台无关、高性能、兼容性好等优点。YARN 将Protocol Buffers 用到了RPC 通信中，默认情况下， YARN RPC 中所有参数采用Protocol Buffers 进行序列化/ 反序列化，相比于MRv1 中基于自定义Writable 框架的方式，YARN 在向后兼容性、扩展性等方面提高了很多。
   ❑ Apache Avro ：Avro 是 Hadoop 生态系统中的 RPC 框架，具有平台无关、支持动态模 式（无需编译）等优点，Avro 的最初设计动机是解决YARN RPC 兼容性和扩展性差等问题，目前，YARN 采用Avro 记录MapReduce 应用程序日志（用于故障后应用程序恢复），今后可能代替Protocol Buffers 作为RPC 辅助库（至少会作为一个可选方案）。
   ❑ RPC 库 ：YARN 仍采用了 MRv1 中的 RPC 库，但其中采用的默认序列化方法被替换成了Protocol Buffers。
   ❑ 服务库和事件库 ：YARN 将所有的对象服务化，以便统一管理（比如创建、销毁等），而服务之间则采用事件机制进行通信，不再使用类似MRv1 中基于函数调用的方式。
   ❑ 状态机库 ：状态机是一种表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。在YARN 中，很多对象都是由若干状态组成的，且当有事件发生时，状态之间会发生转移，比如作业、任务、Container 等，而YARN 正是采用有限状态机描述一些对象的状态以及状态之间的转移。引入状态机模型后，相比MRv1，YARN 的代码结构更加清晰易懂了。

2. Protocol Buffers

   Protocol Buffers是一种轻便高效的结构化数据存储格式，可以用于结构化数据序列化/ 反序列化。它很适合做数据存储或 RPC 的数据交换格式，常用作通信协议、数据存储等领域的与语言无关、平台无关、可扩展的序列化结构数据格式。
   相比于常见的XML 格式，Protocol Buffers 的优点：
   ❑ 平台无关、语言无关；
   ❑ 高性能，解析速度是 XML 的 20 ～ 100 倍；
   ❑ 体积小，文件大小仅是 XML 的 1/10 ～ 1/3；
   ❑ 使用简单；
   ❑ 兼容性好。

   通常编写一个Protocol Buffers 应用需要以下三步：
   1）定义消息格式文件，通常以proto 作为扩展名；
   2）使用Google 提供的Protocol Buffers 编译器生成特定语言（目前支持 C++、Java、Python 三类语言）的代码文件；
   3）使用Protocol Buffers 库提供的API 来编写应用程序。

3. Apache Avro

   Apache Avro 是Hadoop 的一个子项目。它既是一个序列化框架，同时也实现了RPC 的功能。
   Avro 的特性和功能如下：
   ❑ 丰富的数据结构类型；
   ❑ 快速可压缩的二进制数据形式；
   ❑ 存储持久数据的文件容器；
   ❑ 提供远程过程调用 RPC；
   ❑ 简单的动态语言结合功能。

   相比于Apache Thrift 和Google 的Protocol Buffers，Apache Avro 具有以下特点：
   ❑ 支持动态模式。Avro 不需要生成代码，这有利于搭建通用的数据处理系统，同时避免了代码入侵。
   ❑ 数据无须加标签。读取数据前，Avro 能够获取模式定义，这使得 Avro 在数据编码时只需要保留更少的类型信息，有利于减少序列化后的数据大小。
   ❑ 无须手工分配的域标识。Thrift 和 Protocol Buffers 使用一个用户添加的整型域唯一性定义一个字段，而Avro 则直接使用域名，该方法更加直观、更加易扩展。

   编写一个Avro 应用也需如下三步：
   1）定义消息格式文件，通常以avro 作为扩展名；
   2）使用Avro 编译器生成特定语言的代码文件（可选）；
   3）使用Avro 库提供的API 来编写应用程序。

4. 底层通信库

   网络通信模块是分布式系统中最底层的模块，它直接支撑了上层分布式环境下复杂的进程间通信（Inter-Process Communication，IPC）逻辑，是所有分布式系统的基础。远程过程调用（Remote Procedure Call，RPC）是一种常用的分布式网络通信协议，它允许运行于一台计算机的程序调用另一台计算机的子程序，同时将网络的通信细节隐藏起来，使得用户无须额外地为这个交互作用编程。由于RPC 大大简化了分布式程序开发，因此备受欢迎。作为一个分布式系统，Hadoop 实现了自己的RPC 通信协议，它是上层多个分布式子系统（如MapReduce、YARN、HDFS 等）公用的网络通信模块。

   ① RPC通信模型
   RPC 是一种通过网络从远程计算机上请求服务，但不需要了解底层网络技术的协议。RPC 协议假定某些传输协议（如 TCP 或 UDP 等）已经存在，并通过这些传输协议为通信程序之间传递访问请求或者应答信息。在 OSI 网络通信模型中，RPC 跨越了传输层和应用层。RPC 使得开发分布式应用程序更加容易。RPC 通常采用客户机/服务器模型。请求程序是一个客户机，而服务提供程序则是一个服务器。一个典型的RPC 框架主要包括以下几个部分：
   ❑ 通信模块。两个相互协作的通信模块实现请求 - 应答协议，它们在客户和服务器之间传递请求和应答消息，一般不会对数据包进行任何处理。请求–应答协议的实现方式有同步方式和异步方式两种。
   同步模式下客户端程序一直阻塞到服务器端发送的应答请求到达本地；而异步模式不同，客户端将请求发送到服务器端后，不必等待应答返回，可以做其他事情，待服务器端处理完请求后，主动通知客户端。在高并发应用场景中，一般采用异步模式以降低访问延迟和提高带宽利用率。

   
   ❑ Stub 程序。客户端和服务器端均包含 Stub 程序，可将之看做代理程序。它使得远程函数调用表现得跟本地调用一样，对用户程序完全透明。在客户端，它表现得就像一个本地程序， 但不直接执行本地调用，而是将请求信息通过网络模块发送给服务器端。此外，当服务器发送应答后，它会解码对应结果。在服务器端，Stub 程序依次进行解码请求消息中的参数、调用相 应的服务过程和编码应答结果的返回值等处理。
   ❑ 调度程序。调度程序接收来自通信模块的请求消息，并根据其中的标识选择一个Stub 程序 进行处理。通常客户端并发请求量比较大时，会采用线程池提高处理效率。
   ❑ 客户程序/服务过程。请求的发出者和请求的处理者。如果是单机环境，客户程序可直接通过函数调用访问服务过程，但在分布式环境下，需要考虑网络通信，这不得增加通信模块和 Stub 程序（保证函数调用的透明性）。

   通常而言，一个RPC 请求从发送到获取处理结果，所经历的步骤如下所示。
   1）客户程序以本地方式调用系统产生的Stub 程序；
   2）该Stub 程序将函数调用信息按照网络通信模块的要求封装成消息包，并交给通信模块发送到远程服务器端。
   3）远程服务器端接收此消息后，将此消息发送给相应的Stub 程序；
   4）Stub 程序拆封消息，形成被调过程要求的形式，并调用对应函数；
   5）被调用函数按照所获参数执行，并将结果返回给Stub 程序；
   6）Stub 程序将此结果封装成消息，通过网络通信模块逐级地传送给客户程序。

   
   ② Hadoop RPC的特点概述
   RPC 实际上是分布式计算中C/S（Client/Server）模型的一个应用实例，对于Hadoop RPC 而言，它具有以下几个特点。
   ❑ 透明性。这是所有 RPC 框架最根本的特点，即当用户在一台计算机的程序调用另外一台计算机上的子程序时，用户自身不应感觉到其间涉及跨机器间的通信，而是感觉像是在执行一个本地调用。
   ❑ 高性能。Hadoop 各个系统（如 HDFS、YARN、MapReduce 等）均采用了 Master/Slave 结构，其中，Master 实际上是一个RPC Server，它负责处理集群中所有Slave发送的服务请求，为了保证Master 的并发处理能力，RPC Server 应是一个高性能服务器，能够高效地处理来自多个Client 的并发RPC 请求。
   ❑ 可控性。JDK 中已经自带了一个 RPC 框架—RMI（Remote Method Invocation，远程方法调用），之所以不直接使用该框架，主要是考虑到RPC 是Hadoop 最底层最核心的模块之一，保证其轻量级、高性能和可控性显得尤为重要，而RMI 重量级过大且用户可控之处太少（如网络连接、超时和缓冲等均难以定制或者修改）。

   ③ RPC总体架构
   同其他RPC 框架一样，Hadoop RPC 主要分为四个部分，分别是序列化层、函数调用层、网络传输层和服务器端处理框架，具体实现机制如下：
   ❑序列化层。序列化主要作用是将结构化对象转为字节流以便于通过网络进行传输或写入持久存储，在RPC 框架中，它主要用于将用户请求中的参数或者应答转化成字节流以便跨机器传输。前面介绍的Protocol Buffers 和Apache Avro 均可用在序列化层，Hadoop 本身也提供了一套序列化框架，一个类只要实现Writable 接口即可支持对象序列化与反序列化。
   ❑函数调用层。函数调用层主要功能是定位要调用的函数并执行该函数，Hadoop RPC采用了 Java 反射机制与动态代理实现了函数调用。
   ❑网络传输层。网络传输层描述了 Client 与 Server 之间消息传输的方式，Hadoop RPC采用了基于 TCP/IP 的 Socket 机制。
   ❑服务器端处理框架。服务器端处理框架可被抽象为网络 I/O 模型，它描述了客户端与服务器端间信息交互方式，它的设计直接决定着服务器端的并发处理能力，常见的网络I/O 模型有阻塞式I/O、非阻塞式I/O、事件驱动I/O 等，而Hadoop RPC 采用了基于Reactor 设计模式的事件驱动I/O 模型。

5. Hadoop RPC 主要由三个大类组成，即RPC、Client 和Server，分别对应对外编程接口、客户端实现和服务器实现。

   ipc.Server 类分析
   Hadoop 采用了Master/Slave 结构，其中Master 是整个系统的单点，如NameNode 或JobTracker ，这是制约系统性能和可扩展性的最关键因素之一；而Master 通过ipc.Server接收并处理所有Slave 发送的请求，这就要求ipc.Server 将高并发和可扩展性作为设计目标。为此，ipc.Server 采用了很多提高并发处理能力的技术，主要包括线程池、事件驱动和Reactor 设计模式等，这些技术均采用了JDK 自带的库实现，这里重点分析它是如何利用Reactor 设计模式提高整体性能的。
   典型的Reactor 模式中主要包括以下几个角色。
   ❑Reactor：I/O 事件的派发者。
   ❑Acceptor ：接受来自 Client 的连接，建立与 Client 对应的 Handler，并向 Reactor 注册此Handler。
   ❑Handler ：与一个 Client 通信的实体，并按一定的过程实现业务的处理。Handler 内部往往会有更进一步的层次划分，用来抽象诸如read、decode、compute、encode 和send 等过程。在Reactor 模式中，业务逻辑被分散的I/O 事件所打破，所以Handler需要有适当的机制在所需的信息还不全（读到一半）的时候保存上下文，并在下一次I/O 事件到来的时候（另一半可读）能继续上次中断的处理。
   ❑Reader/Sender ：为了加速处理速度，Reactor 模式往往构建一个存放数据处理线程的线程池，这样数据读出后，立即扔到线程池中等待后续处理即可。为此，Reactor模式一般分离 Handler 中的读和写两个过程，分别注册成单独的读事件和写事件，并由对应的Reader 和Sender 线程处理。

   分析ipc.Server 的实现细节：
   （1）接收请求
   该阶段主要任务是接收来自各个客户端的RPC 请求，并将它们封装成固定的格式（Call 类）放到一个共享队列（callQueue）中，以便进行后续处理。该阶段内部又分为建立连接和接收请求两个子阶段，分别由Listener 和Reader 两种线程完成。整个Server 只有一个Listener 线程，统一负责监听来自客户端的连接请求，一旦有新的请求到达，它会采用轮询的方式从线程池中选择一个Reader 线程进行处理，而Reader 线程可同时存在多个，它们分别负责接收一部分客户端连接的RPC 请求，至于每个Reader 线程负责哪些客户端连接，完全由Listener 决定，当前Listener 只是采用了简单的轮询分配机制。
   Listener 和Reader 线程内部各自包含一个Selector 对象，分别用于监听SelectionKey.OP_ACCEPT 和SelectionKey.OP_READ 事件。对于Listener 线程，主循环的实现体是监听是否有新的连接请求到达，并采用轮询策略选择一个Reader 线程处理新连接；对于Reader线程，主循环的实现体是监听（它负责的那部分）客户端连接中是否有新的RPC 请求到达，并将新的RPC 请求封装成Call 对象，放到共享队列callQueue 中。
   （2）处理请求
   该阶段主要任务是从共享队列callQueue 中获取Call 对象，执行对应的函数调用，并将结果返回给客户端，这全部由Handler 线程完成。Server 端可同时存在多个Handler 线程，它们并行从共享队列中读取Call 对象，经执行对应的函数调用后，将尝试着直接将结果返回给对应的客户端。但考虑到某些函数调用返回结果很大或者网络速度过慢，可能难以将结果一次性发送到客户端，此时Handler 将尝试着将后续发送任务交给Responder 线程。
   （3）返回结果
   前面提到，每个Handler 线程执行完函数调用后，会尝试着将执行结果返回给客户端，但对于特殊情况，比如函数调用返回结果过大或者网络异常情况（网速过慢），会将发送任务交给Responder 线程。Server 端仅存在一个Responder 线程， 它的内部包含一个Selector 对象，用于监听SelectionKey.OP_WRITE 事件。当Handler 没能将结果一次性发送到客户端时， 会向该Selector 对象注册SelectionKey.OP_WRITE 事件，进而由Responder 线程采用异步方式继续发送未发送完成的结果。

6. Hadoop RPC 参数调优

   Hadoop RPC 对外提供了一些可配置参数，以便于用户根据业务需求和硬件环境对其进行调优。主要的配置参数如下。
   ❑ Reader 线程数目。由参数 ipc.server.read.threadpool.size 配置，默认是 1，也就是说，默认情况下，一个RPC Server 只包含一个Reader 线程。
   ❑ 每个 Handler 线程对应的最大 Call 数目。由参数 ipc.server.handler.queue.size 指定，默 认是100，也就是说，默认情况下，每个Handler 线程对应的Call 队列长度为100。比如，如果Handler 数目为10，则整个Call 队列（即共享队列callQueue）最大长度为：100×10=1000。
   ❑ Handler 线程数目。在Hadoop中， ResourceManager和NameNode分别是YARN和HDFS两个子系统中的RPC Server，其对应的Handler 数目分别由参数yarn.resourcemanager.resource-tracker.client.thread-count 和dfs.namenode.service.handler.count 指定，默认值分别为50 和10，当集群规模较大时，这两个参数值会大大影响系统性能。
   ❑ 客户端最大重试次数。在分布式环境下，因网络故障或者其他原因迫使客户端重试连接是很常见的，但尝试次数过多可能不利于对实时性要求较高的应用。客户端最大重试次数由参数ipc.client.connect.max.retries 指定，默认值为10，也就是会连续尝试10 次（每两次之间相隔1秒）。

7. 服务库与事件库

   ①服务库
   对于生命周期较长的对象，YARN 采用了基于服务的对象管理模型对其进行管理，该模型主要有以下几个特点。
   ❑将每个被服务化的对象分为4 个状态：NOTINITED（被创建）、INITED（已初始化）、STARTED（已启动）、STOPPED（已停止）。
   ❑任何服务状态变化都可以触发另外一些动作。
   ❑可通过组合的方式对任意服务进行组合，以便进行统一管理。
   ②事件库
   YARN 采用了基于事件驱动的并发模型，该模型能够大大增强并发性，从而提高系统整体性能。为了构建该模型，YARN 将各种处理逻辑抽象成事件和对应事件调度器，并将每类事件的处理过程分割成多个步骤，用有限状态机表示。整个处理过程大致为：处理请求会作为事件进入系统，由中央异步调度器（Async-Dispatcher）负责传递给相应事件调度器（Event Handler）。该事件调度器可能将该事件转发给另外一个事件调度器，也可能交给一个带有有限状态机的事件处理器，其处理结果也以事件的形式输出给中央异步调度器。而新的事件会再次被中央异步调度器转发给下一个事件调度器，直至处理完成（达到终止条件）。

8. 状态机库

   状态机由一组状态组成，这些状态分为三类：初始状态、中间状态和最终状态。状态机从初始状态开始运行，经过一系列中间状态后，到达最终状态并退出。在一个状态机中，每个状态都可以接收一组特定事件，并根据具体的事件类型转换到另一个状态。当状态机转换到最终状态时，则退出。