Hadoop：Yarn 初识

写的不到位的地方，欢迎评论指出不足之处

•  模型
  • Container 容器，不是 docke
    • 虚的
      • 对象
        • 属性：容量归属 Node Manage、cpu、内存、io量
    • 物理的
      • JVM 操作系统进程
        • Node Manage 会有线程监控 container 资源情况
          • 超额：NM 直接kill干掉
        • cgroup 内核级技术：在启动 JVM 进程，由 kernel 约束死
        • 整合 docker
• 实现：架构/框架
  • ResourceManager 主
    • 负责整体资源的管理
  • NodeManager 从
    • 向 RS 汇报心跳，提交自己的资源情况
• ResourceManager 运行 MapReduce on yarn
  • MR-Cli （切片清单/配置/JAR/上传到HDFS）
    • 访问 ResourceManager 申请的 AppMaster
  • RM 选择一台不忙的节点通知 NodeManager 启动一个 Container，在里面反射一个 MapReduceAppMaster
  • 启动 MRAppMaster，从 hdfs 下载切片清单，向 RM 申请资源
  • 由 RM 根据自身掌握的资源情况得到一个确定清单，通知NM来启动 Container
  • Container 启动后会反向注册到已经启动的 MRAppMaster 进程
  • MRAppMaster （曾经的 JobTracker 阉割版不带资源管理），最终将任务 Task 发送给 container（消息）
  • Container 会反射相应的 Task 类为对象，调用方法执行，其结果就是我们的业务逻辑代码的执行
  • 计算框架都有 Task 失败重试的机制
  • 结论：
    • 单点故障
      • 曾经是全局的，JobTracker 挂了，整个计算层没有了调度
      • Yarn：每一个 APP 由一个自己的 AppMaster 调度（计算程序级别）
        • 支持AppMaster失败重试
    • 压力过大
      • Yarn：每个计算程序自有 AppMaster，每个 AppMaster 只负责自己计算程序的任务调度，轻量了
        • AppMasters 是在不同的节点中启动，默认有了负载的光环

    • 集成了【资源管理和任务调度】，两者耦合

      • Yarn：只是资源管理，不负责具体的任务调度

        •  是公立的，只要计算框架继承 Yarn 的 AppMaster，大家都可以使用一个统一视图的资源层

• 总结

  •  从 1.X 到 2.X

    • JT / TT 是 MR 的常服务

  • 2.X

    • 之后没有了这些服务

    • 相对的：MR的Cli、调度、任务，这些都是临时服务