从零爬Hadoop系列_1-《Hadoop技术内幕2》基础篇

发表于   |   分类于   |     |   阅读次数

基础篇

MRv1到YARN

  1. MRv1主要是以MR为主的计算框架，而MRv2主要是针对MRv1的缺陷改进而来的，以YARN为主的轻量级弹性计算平台；
  2. MRv1的缺陷：
    • 扩展性差：JobTracker兼备资源管理和作业控制；
    • 可靠性差：master单点故障；
    • 资源利用率低：粗粒度的划分单位，任务之间不共享；
    • 无法支持多种计算框架：只有基于磁盘的离线计算框架MR，不能满足多种需求；
  3. YARN的诞生背景：
    • 基于数据密集型应用的计算框架层出不穷：
      • MR：离线处理；
      • Storm：在线处理；
      • Spark：迭代式处理；
      • S4：流式处理；
    • 各种框架各有所长，在同一个公司中，多种框架可能被同时采用，如网页建立索引用MR，自然语言处理/数据挖掘用Spark等，考虑到成本等，又希望把所有框架部署在一个共享集群中，而非各占一个独立集群，而且需要在对共享资源统一管理使用的同时，保证各个任务的隔离性，急需轻量级弹性计算平台。
  4. 共享集群的好处：
    • 资源利用率高：多种框架共享资源，统一管理，不会出现分配不均或某些紧缺而某些空闲的问题；
    • 运维成本低：管理员成本和硬件成本；
    • 数据共享：减小数据移动带来的成本；
  5. 一个框架一个集群 到 多个框架共享集群：
    共享集群

YARN的组成结构和流程

  1. YARN基本组成结构：
    • ResourceManager（RM）：全局资源管理器，负责资源管理和分配；
      • Schduler：纯调度器，只负责根据各个应用程序的资源需求进行资源分配；
      • ApplicationManager（ASM）：负责管理整个系统中所有应用程序；
    • ApplicationMaster（AM）：用户提交的每个应用程序均包含一个AM，主要功能：
      • 与Scheduler协商获取资源（Container）；
      • 将得到的任务进一步分配给内部的任务；
      • 与NM通信以启动/停止任务；
      • 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务；
    • NodeManager（NM）：每个节点上的资源和任务管理器，主要功能：
      • 定时向RM汇报本节点上的资源使用情况和各个Container的运行状态；
      • 接受并处理来自AM的Container启动/停止等请求；
    • Container：资源抽象，封装某个节点上的多维度资源，如内存、CPU、磁盘等
  2. YARN工作流程：
    • 步骤1：用户向YARN提交应用程序，其中包括AM程序、启动AM的命令、用户程序等；
    • 步骤2：RM为该应用程序分配第一个Container，并与对应的NM通信，要求它在这个Container中启动该AM；
    • 步骤3：AM首先向RM注册，这样用户可以通过RM查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它们的运行状态，直到运行结束，即重复步骤4~7；
    • 步骤4：AM采用轮询的方式，通过RPC协议向RM申请和领取资源；
    • 步骤5：一旦AM申请到资源后，便与对应的NM通信，要求它启动任务；
    • 步骤6：NM为任务设置好运行环境后，将任务启动命令写到一个脚本中，通过运行该脚本启动任务；
    • 步骤7：各个任务通过某个RPC协议向AM汇报自己的状态和进度，以便AM随时掌握各个任务的运行状态，从而可以在任务失败时重启任务；
    • 步骤9：应用程序运行完成后，AM向RM注销并关闭自己；
    • 如下图：
      YARN工作流程
  3. YARN的理解角度：
    • 多线程并行编程：
      • YARN：云操作系统，为应用程序启动AM；
      • AM：主线程，负责应用程序内部的数据切分、任务分配等，并启动各个Task；
      • Task：子线程，仅负责自己的计算任务，完成即结束退出；
      • 当所有子线程（Task）结束以后，主线程（AM）结束退出；
    • 资源管理器；
    • 云计算：YARN可以看做PAAS层，为不同类型的应用程序提供统一的管理和调度；

YARN基础库

RPC

  1. Hadoop RPC（集群各组件之间的通信方式）总体架构：
    • 序列化层：结构化对象转为字节流便于网络传输或持久存储，主要用于请求中的参数和应答跨机器传输；
    • 函数调用层：定位要调用的函数并执行该函数，Hadoop RPC采用Java反射机制和动态代理实现；
    • 网络传输层：描述了Client和Server之间消息传输的方式，Hadoop RPC采用基于TCP/IP的Socket机制；
    • 服务器端处理框架：描述了Client和Server之间信息交互的方式，直接决定服务器端的并发处理能力，Hadoop RPC采用基于Reactor设计模式的事件驱动I/O模型；
  2. YARN RPC：可以集成多种RPC框架，如Protocol Buflers、Thrift、Avro等；
  3. 对RPC的理解和实现，可以通过查看具体的例子进行理解，比如NM的心跳函数；

服务库（使得YARN低耦合、高内聚、设计简单、易维护）

  1. 对于生命周期较长的对象，YARN采用了基于服务的对象管理模型对其进行管理，几个特点：
    • 每个被服务化的对象分为4个状态：NOTINITED、INITED、STARTED、STOPPED；
    • 任何服务状态变化都可以触发另外一些动作；
    • 可以通过组合的方式对任意服务进行组合，以便统一管理；
  2. 在YARN中，RM和NM属于组合服务，它们内部包含多个单一服务和组合服务，以实现对内部多种服务的统一管理；

事件库（使得YARN低耦合、高内聚、设计简单、易维护）

  1. 为了构建基于事件驱动的并发模型，YARN将各种处理逻辑抽象成事件和对应的事件调度器，并把每类事件的处理过程分割成多个步骤，用有限状态机表示；
  2. 处理过程：
    • 处理请求作为事件进入系统；
    • 由中央异步调度器负责传递给对应的事件调度器；
    • 事件调度器有两种处理：
      • 可能将该事件转发给另外一个事件调度器；
      • 也可能交给一个带有有限状态机的事件处理器，其处理结果也以事件的形式输出给中央异步调度器；
    • 新的事件会再次被中央异步调度器转发给下一个事件调度器，直至处理完成（到达终止条件）。
  3. 在YARN中，所有核心服务实际上都是一个中央异步调度器，包括RM、NM、AM等，它们维护了事先注册的事件和事件处理器，并根据接收的事件类型驱动服务的运行；

状态机库（使得YARN设计架构更清晰）

  1. 如上所述，在YARN中，事件的处理过程被分割成多个步骤，用有限状态机表示，换言之，有限状态机维护着有状态对象的生命周期；
  2. 在YARN中，每种状态转换由一个四元组表示，分别是转换前状态preState、转换后状态postState、事件event和回调函数hook，表示状态机在preState状态下，接收到事件event后，执行回调函数hook，并在执行完成后将状态转换为postState。
  3. YARN定义了三种状态转换方式：
    • 一个初态、一个终态、一种事件；
    • 一个初态、多个终态、一种事件，终态由hook返回值确定；
    • 一个初态、一个终态、多种事件；