Apache hadoop相关的知识点总结, 包含yarn mr hdfs等等的东西 算是Hadoop框的知识点索引, 后续会逐渐展开写

总览

简述MR, Spark,Storm,Hive,Hbase的特点和使用场景

Hadoop ：是一种分布式系统基础架构当处理海量数据的程序，开始要求高可靠、高扩展、高效、低容错、低成本的场景

MapReduce： MapReduce是一种编程模型，用于大规模数据集（大于1TB）的并行运算。 MapReduce的典型应用场景中，目前日志分析用的比较多，还有做搜素的索引，机器学习算法包mahout也是之一，当然它能做的东西还有很多，比如数据挖掘、信息提取。

Spark：拥有Hadoop MapReduce所具有的优点；但不同于MapReduce的是Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。 数据过于繁杂，并且需要让计算通过迭代，并在内存中，极大地提高效率的场景

Strom：一个分布式实时计算系统，Storm是一个任务并行连续计算引擎。 Storm本身并不典型在Hadoop集群上运行，它使用Apache ZooKeeper的和自己的主/从工作进程，协调拓扑，主机和工作者状态，保证信息的语义。无论如何， Storm必定还是可以从HDFS文件消费或者从文件写入到HDFS。

Hive：基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。 应用场景：十分适合数据仓库的统计分析。

Hbase: 应用场景： 数据量太大，以至于传统RDBMS无法胜任、 联机业务功能开发、 离线数据分析（数据仓库），

• mr
• 大吞吐量
• 低延时要求的离线计算

• spark
• 大吞吐量
• 离线计算
• 同样的任务比mr快
• hive
• 基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，
• 可以将sql语句转换为MapReduce任务进行运行

• hbase
• 数据量太大，以至于传统RDBMS无法胜任、
• 适合大量写入的nosql

请列出正常的hadoop集群中hadoop都分别需要启动哪些进程，他们的作用分别都是什么，请尽量列的详细一些,且单独启动的方法。

• hdfs
• DataNode
• namenode

• yarn
• resourcemanger
• Nodemanger
• hbase
• hmaster
• zookeeper
• HregionServer

• spark
• Worker
• Master

Spark和mapreduce的区别

mapreduce

• 优点
• 可以横向拓展
• 吞吐量大
• 适合海量数据批处理

• 缺点
• 中间过程需要写入硬盘 慢
• map函数和reduce函数 属于底层的api,实现复杂操作比较麻烦
• 不适合迭代任务

spark

• rdd可以采用内存存储, 减少了一些io操作
• 通过划分宽依赖 短依赖,可以让不需要shuffle的运算在一个节点上运行, 并行中间不需要写入磁盘
• 有很多高层的api
• 使用比mapreduce更容易

spark是否可以取代MapReduce

• 技术上是完全可以的
• 所有MR的功能都能被spark代替
• 但是两者侧重点不一样
• mapReduce适合对实时性要求不高的计算, 计算时中间结果溢写到磁盘 io消耗大
• 相对来着MR内存消耗不大
• spark是基于内存的计算框架，计算速度是很快的
• 内存消耗大

数据倾斜问题怎么办??

容易出现的场景

• 分区不均匀 wordcount 一个分区数据太多
• 发生group by的场景
• 发生join

原因

• key分布不均
• 业务数据本身的特性
• 建表考虑不周全

解决思想

• 物理上, 加大并行度
• 适量正经jvm内存
• 增加reduce个数
• spark增加分区

• 重新设计partition函数
• key上加盐 – 加上一个随机数
• 在无聚合操作中
• spark group或者join中, 某个key爆炸
• map端join
• 拆分聚合思想
• 倾斜严重的key加盐
• 两次聚合

for hadoop

• 具体是指mapreduce处理过程中, 通过partition函数后,,reduce接收的数据量不一样
• 数据倾斜无非就是大量的相同key被partition分配到一个分区里
• 解决方法
• 适当的增加jvm内存和reduce个数
• 自定义partition函数
• 对key加上一个随机数, 加盐的方式
• 将Reduce side Join转变为Map side Join

for spark

• 出现在shuffle中
• groupByKey
• reduceByKey
• join操作

解决方案

• 调整并行度。一般是增大并行度
• 适用场景少，只能将分配到同一Task的不同Key分散开
• 对于同一Key对应数据集非常大的场景不适用

• 使用自定义的Partitioner（默认为HashPartitioner）
• 将原本被分配到同一个Task的不同Key分配到不同Task。
• 适用场景有限，只能将不同Key分散开，对于同一Key对应数据集非常大的场景不适用
• 对于同一Key对应数据集非常大的场景不适用
• 将Reduce side Join转变为Map side Join
• 避免Shuffle从而完全消除Shuffle带来的数据倾斜
• 适用于参与Join的一边数据集足够小，可被加载进Driver并通过Broadcast方法广播到各个Executor中。

• 为数据量特别大的Key增加随机前/后缀join
• 将有数据倾斜的RDD中倾斜Key对应的数据集单独抽取出来加上随机前缀
• 另外一个RDD每条数据分别与随机前缀结合形成新的RDD
• 然后将二者Join并去掉前缀。然后将不包含倾斜Key的剩余数据进行Join
• 最后将两次Join的结果集通过union合并，即可得到全部Join结果
• 随机key 双重聚合
• 第一轮聚合的时候，对key进行打散，将原先一样的key，变成不一样的key，相当于是将每个key分为多组。
• 先针对多个组，进行key的局部聚合。接着，再去除掉每个key的前缀，然后对所有的key进行全局的聚合。
• 对groupByKey、reduceByKey造成的数据倾斜，有比较好的效果

hadoop IO与RPC

hadoop io基础知识 hadoop file相关的基础知识

参考资料

• hadoop权威指南 IO部分
• hadoop技术内幕 3章 序列化与压缩
• 序列化
• 压缩

• hadoop权威指南 avro部分
• 深入云计算 6章 hadoop IO
• hdfs-hadoop 源码剖析 2.6 写的挺好
• hadoop技术内幕 yarn p66 不是很全
• 大数据处理系统 源码分析更透彻
• hadoop源代码分析
• 未曾深入的细节
• server各个组件功能,多线程等细节
• 具体代理对象的生成

IO方面问题

hadoop io和java io的关系

• hadoop io
• 精简/紧凑 占用最少的空间
• 快速 减少序列化,反序列化的开销
• 可拓展

• java io 重量级
• hadoop体系中数据存储有哪些方案

Hadoop上序列化存储方式

• writable
• 比java序列化轻量级,
• 不跨语言

• avro
• 行式存储
• 支持RPC
• 支持动态拓展
• 语言无关
• 适合大数据量,
• 可压缩,可切分
• avro与json protocol相比更有优势
• Thrift
• protocol
• 容器
• SequenceFile
• mapFile

列式存储

列式存储的优势

• 适合数据分析
• 非常适合仅访问小部分列的查询

• 空间利用率高
• 可以进行谓词下推
• 查询内容之外的列，不必执行 I/O 和解压（若适用）操作
• 适合在极大的数据集上对某些特定的列进行聚合操作

Parquet

• Parquet仅仅是一种存储格式，它是语言、平台无关的
• 特点
• 查询性能
• 列存储,更好的取出部分类
• 如果你的数据字段非常多，但实际应用中，每个业务仅读取其中少量字段，parquet将是一个非常好的选择

• 能够镶套存储
• 更好的压缩比
• 相对CSV
• 更好的压缩
• ORC

Hbase

• 提供数据随机访问
• 可以理解为一个巨大的hash表

Rpc方面问题

RPC特点

• 透明性 (像调用本地方法一样)
• 采用CS模式
• 依赖某些网络传输协议
• 良好的RPC调用是面向服务的封装

主要组成部分

• 对象序列化
• 远程调用
• 实现方法可以是Socket
• 一般分为C与S

java RPC和hadoopRPC =的区别

java RMI执行原理和流程?

这个不太会!

- 实现远程对象

    - 类要实现远程接口 (extends remote
    - 每个方法都要

        - public
        - 抛出throws异常

- Server端

    - 注册端口供客户端调用
    - 收到请求后

        - 反序列请求
        - 调用服务
        - 序列化结果,返回

- Client端

    - 通过指定 主机和端口,请求封装
    - 通过网络协议发送
    - 收到结果,并反序列化

• Hadoop RPC可以灵活的切换序列化框架

hadoop RPC原理

hadoop RPC的执行过程

服务端

- 建立服务

    - 通过RPC.Builder 内部静态类 建立
    - builder方法

        - 调用所选的RPCEngine的getserver方法
        - 设置好需要的参数

    - start方法启动服务

        - 根Server类的start方法
        - 启动Listener线程,监听端口
        - 启动Handler,来处理请求

- 处理请求

    - Listener端口监听请求

        - 交给read去读取
        - 加入call队列

    - handler处理请求

客户端

- 创建代理对象

    - 通过Rpc.GetProxy来创建代理对象
    - 调用所选的RPCEngine的getProxy方法
    - 获取一个代理对象

- 处理请求

    - 调用代理对象的方法

        - 实际调用Invoker类的Invoker方法
        - 调用Client类的call方法, 发送请求

    - Client.call()

        - 把封装好的请求 发送出去
        - call方法 等待

            - 直到Connection类通知结果已经收到

        - sendRpcRequest中,在线程池中开启一个新的线程来发送请求
        - 接收信息的话,是在Connection类中监听了专门的端口, 收到信息后 再唤醒call线程

hadoop RPC的核心库类

• ProtocolVersion
• 协议接口

• IPC
• Server
• IPC客户端,提供处理协议的类的方法
• Listener类
• 监听socket接口,
• 创建线程来处理
• Handler
• 处理CallQueue里面的call

• Client
• 封装客户端Rpc请求,发送请求, 等待结果返回
• 代理机制
• Connection类
• 管理已建立并维持的连接
• 接收server方的相应
• Call类

• RPC类
• 帮助应用层构建具体的Rpc层设施
• server内部类
• 实现了Call方法
• 反射机制 ,调用方法
• Builder静态内部类
• getProxy
• getServer

• RPCEngine类
• 具体实现Rpc层
• 创建Server
• 创建Proxy
• Invoker类
• 代理对象相关的
• 实现了
• RpcInvocationHandler
• 继承了反射包的InvocationHandler方法

hadoop RPC的特点是什么?

• 可控性
• 可以自己选择序列化框架

• 轻量级
• 高性能
• NIO
• 高并发设计

Hadoop rpc原理是什么?

• 通过序列化,socket NIO, 反射,动态代理 实现了远程方法调用
• Rpc入口在RPC这个类
• 提供了创建Server类
• 代理对象类的方法

• Server类如何监听与处理线程的
• 难点!
• hadoop rpc中如何实现高性能的
• 并发编程
• NIO

hadoop HDFS

集群架构

• NameNode
• 负责处理客户端的请求
• 负责元数据的管理

• datanode
• 存储管理用户的文件块数据
• 定期向namenode汇报自身所持有的block信息
• SecondaryNameNode
• 他的目的使帮助NameNode合并编辑日志，减少NameNode 启动时间

checkpoint原理

周期性的建立NameNode元数据的检查点,可以减少namenode的启动时间

触发条件

• 时间周期
• 日志数量

组成

• FSImage
• 周期性的元数据镜像

• edits
• 操作的日志

流程

• 满足checkpoint要求后
• 执行checkpoint的节点拉取FSImage和Edits
• 载入内存,合并文件
• 将新的FSImage发送回NameNode

hdfs基本原理

hdfs读取过程

• Client与NN通信,获取元数据信息
• Client与DN通信, 获取信息

hdfs写入过程

• 创建文件
• 在NN中建立元数据
• Client写入其中一个DN
• 从这个DN,复制到其他DN

HDFS HA

• 在HDFS的HA中SecondaryNameNode这个冷备角色已经不存在
• 为了保持standby NN时时的与主Active NN的元数据保持一致，他们之间交互通过一系列守护的轻量级进程JournalNode
• 由哪几个部分组成?
• ActiveNN
• StandByNN
• 共享存储
• 基本原理就是用2N+1台 JN 存储EditLog
• 半数写入成功就不会丢失
• QJM

• standby随时更新activeNN的新日志
• FailoverController（故障转移控制器）和Zookeeper
• FailoverController与Zookeeper通信，通过Zookeeper选举机制
• FailoverController通过RPC让NameNode转换为Active或Standby

• 防止脑裂 Fencing

指在一个高可用（HA）系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏

• 确保只有一个NN
• DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回是认为该NN为新的active
• 如果这时原来的active（比如GC）恢复，返回给DN的心跳信息包含active状态和原来的序列号，这时DN就会拒绝这个NN的命令。
• 让访问standby nn的客户端直接失败

spark与hadoop源码对比!!!

hadoop Rpc和spark RPC的区别和联系

hadoop Rpc在整体架构上封装了如下几层

• IPC
• 进程间通信
• 定义了Server和client来处理请求

• Rpc
• 在ICP层面上提供了网络通信的支持
• 还使用RPCEngine提供了不同的序列化引擎
• yarn rpc
• 在Rpc的基础上, 封装
• 提供具体的通信协议支持

spark整体设计上有所不同

• 先封装了一层通信层
• 之前是akka
• 后来是netty
• 在netty基础上封装了一层通信
• 用来
• RPC
• shuffle中的数据传递

• transportContext
• TransportServer
• transportClient
• 在通信包的基础上
• 添加Rpc支持
• RpcEndpoint
• RpcEndpointRef
• RpcEnv

hadoop和spark事件机制的不同

• 都是做到了基于事件和消息传递的这么一个并发模型

hadoop事件机制

• 与状态机模型配合
• 在管理生命周期的同时
• 处理生命周期变化中的事件
• 维护着状态机状态变化需要出发的跳转表和事件

• 组成
• Dispatcher
• 具体的事件
• EventHandler

spark事件机制

• 更加纯粹的事件机制
• 组成
• listenBus
• Listener
• 是一对多的事件监听机制

hadoop和yarn的调度机制

hadoop yarn

• hadoop技术内幕 yarn
• hadoop权威指南
• 大数据处理分析系统
• yarn核心技术实践
• yarn权威指南

Yarn的原理

yarn的设计思想?

• 拆分资源调度和任务的调度
• 一个由RM和NM来做
• 一个由APPMaster

yarn工作流程

• 组成
• RM
• NM
• ApplicationMaster
• Container

• Yarn由几部分构成?
• yarn应用中有哪些组件
• 各部分的功能?

RM

RM的作用是什么?

• 处理客户端的请求
• 资源调度
• 有NM通信,监听资源, 分配任务
• 与appMaster通信, 分配资源

RM的原理是什么? (由那些组件构成)

• 内部有这么一些服务,负责与各个组件交互
• ClientRMService
• 与客户端进行通信

• ResourceTracker
• 与NM通信
• ApplicationMasterService
• 与APPMaster通信

• ApplicationMasterLauncher
• YarnScheduler
• RM端维护着这些状态机,
• RMApp
• RMAPPAttempt
• RMNode
• RMContainer

• 有着这些通信协议
• ApplicationClientProtocol
• ResourceTracker
• ApplicationMasterProtocol

RM的资源调度器有哪些?

• FIFO
• 公平调度
• 容量调度

未解问题: – 内存调度是什么怎么调度的? – 如果考虑CPU怎么调度的? – 如何实现隔离的?

Yarn应用的提交过程 ApplicationMaster启动的过程

• 是指从Client到ApplicationMaster启动这个阶段
• ApplicationMasterLauncher是最后的一步
• 牵扯到的点
• 客户端到RM
• RMClientService
• ApplicationClientProtocol

• RM内的服务
• APPManger
• 内部维持的状态机
• RMApp
• 五个状态
• 实现了新建/备份保存/提交/接收/运行

• RMAppAttempt
• 新建/备份保存/与资源调度接触/申请具体资源
• 提出申请后等待RMContainer启动
• 调用launcher组件
• RMNodemanger
• RMContainer

• RM资源调度
• 最后 ApplicationMasterLauncher
• 流程
• Client发送请求到RM
• 通过APPClientProtocol协议
• 到, RMClientService组件

• 业务逻辑在APPManger组件中
• 开启RMApp的生命周期
• 开启RMAppattempt生命周期
• 期间不断与调度器通信
• 调度器与RM通信
• 获取所需的Container资源

• 一切就绪后,
• ApplicationMasterLauncher
• 去启动Container线程

RM和NM的交互过程?如何分配任务的

- 通信协议

    - ResourceTracker
    - 注册
    - 心跳感应

- 启动后,先注册
- 周期性发送心跳报告
- 所有的交互操作,都在报告里面

    - 更新节点信息
    - 更新container信息
    - 领取container启动的信息

- 在RM端有两个状态机

    - RMNode
    - RMContainer

- 在NM端有两个状态机

    - Application
    - Container

NM

NM的作用?

• 与ResourceManager通信, 汇报节点信息和资源信息
• 管理Container生命周期
• 监控Container资源使用

NM如何实现Container的管理的?

• 通过ContainerMangerProtocol
• 服务端应该是在Nodemanager端
• 相关状态机
• Application
• Container

• 每一个container都是一个单独的进程

ApplicationMaster原理

• 通信协议
• ApplicationMasterProtocol
• 与RM通信

Hadoop yarn上工作的Rpc协议

看清楚这些通信协议能摸到yarn工作的脉搏

ApplicationClientProtocol

• 用于客户端与RM通信
• 申请应用
• 提交应用
• 获取RM的各种信息

• server
• RM
• client
• 用户

ApplicationMasterProtocol

• 用于ApplicationMaster与RN通信
• 注册应用
• 结束应用
• 分配

• server
• RM
• client
• APPMaster

ResourceTracker

• 用于RM与NM通信
• 心跳
• 注册

• server
• RM
• client
• NM

CotainerMangermentProtocol

• 应用和NM之间通信
• 开启容器
• 结束容器
• 获取容器状态

• Server
• NM
• client
• ApplicationMaster

yarn源码的组合和结构

• YarnRpc
• 对hadoop rpc的进一步封装
• 状态机
• 好处是什么?
• 便于进行生命周期的管理
• 各种事件对应着状态机状态的变化
• 每个变化都是原子性的

• 状态机维护的是事件的跳转表和触发规则等
• 维护一些对象的生命周期
• Application
• Container
• 事件库
• 服务中的处理逻辑都是事件
• 事件与服务密切相关
• 事件与状态机密切相关

Yarn中的并发示例有哪些?

• Server类中
• 基于事件的并发处理

RM有几种资源调度器?

FIFO

• 在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。
• 在FIFO 调度器中，小任务会被大任务阻塞。

Capacity

• Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力
• 通过为每个组织分配专门的队列
• 然后再为每个队列分配一定的集群资源
• 这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了

• 对于Capacity调度器，有一个专门的队列用来运行小任务
• 为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间

Fair

• 设计目标是为所有的应用分配公平的资源
• 对公平的定义可以通过参数来设置
• 默认采用Capacity Scheduler调度器

• Fair调度器会为所有运行的job动态的调整系统资源
• 当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源
• 当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。

综合问题

• Yarn分布式缓存机制原理?
• yarn底层的通信协议

hadoop应用与架构

参考资料

• hadoop应用架构
• 数据算法

面试问题

hadoop如何优化?

MapReduce优化经验

(1.)设置合理的map和reduce的个数。 (2.)避免出现数据倾斜 (3.combine函数 (4.对数据进行压缩，避免大量的小文件

如何连接新节点和删除节点?

增加一个新的节点在新的几点上执行 Hadoop daemon.sh start datanode Hadooop daemon.sh start tasktracker 然后在主节点中执行 hadoop dfsadmin -refreshnodes 删除一个节点的时候，只需要在主节点执行 hadoop mradmin -refreshnodes

hadoop mapreduce

参考资料

• hadoop权威指南 看完一遍了,还需要回顾,不太细
• 深入云计算hadoop源码分析
• 大数据处理系统 hadoop源码分析2.6
• hadoop技术内幕深入解析yarn
• hadoop源代码分析 后半部分
• mapreduce设计模式

MR原理

MR设计思想

• mapreduce是一种设计模型
• 拆分，读取原始数据，形成key-value数据（map方法）；
• 聚合，将相同key的数据聚合到一组（reduce方法）。

MR可定制的组件

• map
• reduce
• combiner
• combiner发生在哪个阶段?
• shuffle阶段
• map端 reduce端都有
• 合并文件时候发生

• Combiner怎么样触发?
• combiner在合并文件的时候发生,
• 要满足合并的条件
• 目的是减少IO
• Partitioner
• GroupComparator
• SortComparator

MR框架里面的数据流向是怎样的?[数据流]

宏观Map reduce过程 , 数据流视角 – map

• InputFormat
• 针对具体的数据类型
• 划分数据集
• split的数量决定了Mapper的数量

• 提供按行读取的工具
• RecordReader
• 由InputFormat创建
• NewTrackingRecordReader
• 对IF创建的RR进行包装
• 使之可以被追踪

• mapContext
• 通过nextKeyValue来具体的输入
• Mapper里面的run()函数
• map
• RecordWriter
• OutputCollector
• 收集输出的组件
• 还是RecordWriter类
• 里面还有Partitioner

• MaxOutputCollector接口 MapOutputBuffer
• OutputCollector里面的组件
• 实际实现是MapOutputBuffer
• 收集map的输出
• 缓冲区内,排序,分区 写入到文件

• 输出
• reduce
• fetch
• 收取
• merge
• combiner
• reduce
• 输出

shuffle写的过程是怎么样的?

• map端
• 环形缓冲区写入
• 环形缓冲区文件合并
• reduce端

MR执行的流程[控制流]

控制流视角

- 作业提交 在客户端完成
- Job对象

    - 封装job信息

- jobsubmit
- 这阶段执行的操作

    - 申请应用ID
    - 使用设置的InputFormat组件来计算分片
    - 判断输出路径
    - 打包jobContext
    - 复制相关的资源
    - 提交

- 作业初始化

    - ApplicationMaster的启动过程

        - RMClientService通信
        - 创建Application/ApplicationAttempt状态机
        - 在和资源调度的一系列交互后,获取APPMaster的容器

            - RN

                - Application
                - ApplicationAttempt
                - 资源管理器组件

            - NM

                - 心跳协议
                - 领取任务

            - Container

        - ApplicationLauncher 具体启动ApplicationMaster相关的Container

    - ApplicationMaster的初始化过程

        - 实现了客户端和ApplicationMaster的通信协议

- 任务分配

    - 维护了Job Task状态机,TaskAttempt 通过状态机之间的跳转表来进行并发操作
    - 接收客户端的分片结果,划分map任务和reduce任务
    - 为每个Task建立TaskAttempt
    - TaskAttempt申请container资源资源
    - 申请到之后 ContainerLauncher组件去执行
    - 在目标节点上启动一个JVM任务,map和reduce任务都是有main方法的

- 任务执行

    - uber任务

        - 分布式执行比本地执行消耗还大时
        - 申请本地container来执行

    - 分布式任务

        - main方法入口在YarnChild里面

            - 求取服务端,获取任务
            - 启动JVM和相关任务
            - 运行task类的run方法

        - map任务

            - 创建一些对象

                - RecordReader对象

                    - 输入

                - RecordWriter

                    - 输出
                    - MapOutputCollector
                    - MapOutputBuffer

                - mapcontext对象

                    - 保证输入输出
                    - 提供输入
                    - 收集输出

            - 下载数据
            - 运行Mapper任务

                - run()方法

                    - 不断的读取分片数据

                - 调用用户实现的map方法

                    - 进行计算

                - 写入到recordWriter中

            - 写入磁盘等过程由RecordWriter实现

            - map计算结果

        - reduce任务

            - 复制
            - Shuffle过程
            - reduce过程

- 进度查询/任务完成

MRAppMaster原理是什么?

组件

• TaskAttemptListener
• 监听启动了的任务

• ContainerAllocator
• RMCommunicator
• 与RM通信
• 为Job申请资源
• ContainerLauncher
• 与Nodemanger通信
• 启动容器

• OutputCommitter
• 描述输出
• CommitterEventHandler
• 用于处理事件
• 利用队列和线程池

状态机

• Job
• Task
• TaskAttempt

通信协议

• MRClientProtocol
• 用于向客户端报告进度

• ContainerManagementProtocol
• 用于启动Container
• ApplicationMasterProtocol

MR计算题

• 求共同好友
• 倒排索引