Yarn
Yarn产生背景：
Yarn直接来自于MR1.0
MR1.0 问题：采用的是master slave结构，master是JobTracker。Slave是TaskTracker、JobTracker整个集群只有一个，构建调度和资源管理，两个功能。每个节点上，可以通过一个TaskTracker控制本节点的资源管理和任务管理。每个TaskTracker通过心跳机制周期性的向JobTracker发送本节点的资源使用情况以及任务运行状态，JobTracker会通过心跳应答将新的命令或者任务发送至TaskTracker。
1、 JobTracker是一个性能瓶颈，既负责资源管理有负责作业调度，实际上，资源管理是所有的计算框架共有的一个模块，不能将其寄宿在某一个特殊的计算框架中，另，作业调度模块是与应用层相关的，与通用的资源管理模块分开。
2、 JobTracker是一个单点故障，一旦出现宕机，整个集群将无法正常使用，
3、 只支持Map Reduce这一种计算模型，如果希望支持Map-reduce-reduce这种计算框架，无法支持，需要修改JobTracker。
4、 MRv1.0 扩展性差、可靠性差、资源利用率低（MRv1采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源划分单位；通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空闲资源，无法支持多种计算框架）
Yarn安装常见问题：
1、 运行APP时内存不足：确保yarn-site.xml文件中的yarn.scheduler.maximum-allocation-mb参数大于mapred-site.xml中的yarn.app.mapreduce.am.resource.mb参数
2、 无法加载本地hadoop库：
WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform
如果要使用native library，只能从Hadoop源码重新编译生成binary安装文件
只是想不输出这个WARN信息的话，在core-site.xml中配置hadoop.native.lib的值为false即可
重新编译方法：http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/NativeLibraries.html
Yarn产生背景-资源利用率
不同计算框架所在集群其资源利用率不均衡，导致整体的资源利用率很低。
引入中间层（资源管理层），管理所有节点上的资源，框架在使用之前首先申请资源，然后运行自己内部的作业和任务 ，通过引入资源管理层，可以有效解决资源利用率的问题，将公司的各种集群整合为一个大的集群，非常方便管理。
Yarn产生背景-运维成本：
如果采用 一个框架一个集群 的模式，则可能需要多个管理员管理这些集群，增加运维成本，共享模式通常需要少数管理员即可完成多个框架的统一管理。
Yarn产生背景-数据共享：
随着数据量的暴增，跨集群间的数据移动不仅花费更多时间，硬件成本也会更大，共享集群模式可让更多框架共享数据和硬件资源，将大大减小数据移动带来的成本。
产生背景-总结：
源于MR1.0的缺陷：单点故障 性能瓶颈 扩展性受限 难以支持MR以外的计算
多计算框架各自为战，数据共享困难：MR 离线计算框架 Storm实时计算框架 Spark 内存计算框架
编程模型对比
第一代MR框架：编程模型
第二代框架：编程模型
编程模型对比：
为保证编程模型的向下兼容性，MRv2重用了MRv1中的编程模型和数据处理引擎，但运行环境被完全重写
编程模型与数据处理引擎：
MapReduce应用程序编程接口有两套：新API（mapred）和旧API（mapreduce）
1、 采用MRv1旧API编写的程序可直接运行在MRv2上；
2、 采用MRv1新API编写的程序需要使用MRv2编程库重新编译并修改不兼容的参数和返回值
运行时环境
1、 MRv1：JobTracker和TaskTracker；
2、 MRv2：YARN和ApplicationMaster
编程模型：
Yarn基本构成与资源调度
也是采用master（Resource Manager）- slave （Node Manager）架构，Resource Manager 整个集群只有一个，一个可靠的节点。
1、 每个节点上可以负责该节点上的资源管理以及任务调度，Node Manager 会定时向Resource Manager汇报本节点上 的资源使用情况和任务运行状态，
2、 Resource Manager会通过心跳应答的机制向Node Manager下达命令或者分发新的任务，
3、 Yarn 将某一资源分配给该应用程序后，应用程序会启动一个Application Master，
4、 Application Master为应用程序负责向Resource Manager申请资源，申请资源之后，再和申请到的节点进行通信，运行内部任务。
两层调度：
1、 第一层是Yarn中Resource Manager将资源分配（Driver Application Master所需要的资源）给各应用程序，
2、 第二层是应用程序（Application Master启动后，向Resource Manager申请Container资源，即Executor运行所需要的资源）申请资源成功，ResourceManager将资源分配给内部的各种任务，在对应的节点上启动Container以运行Application Master分发过来的任务。
Yarn中，任务会运行在Container的一个容器内，封装的是整个任务的运行环境，比如CPU、内存等环境变量封装在container中，在container中运行。
ResourceManager
全局资源管理器，整个集群只有一个，负责集群资源的统一调度和任务管理
主要由两个组件构成：资源调度器 Resource Scheduler 和应用程序管理器(Applications Master -- ASM)
调度器：
1、 调度器根据容量、队列等限制条件，将系统中的资源分配给各个正在运行的应用程序
2、 不负责具体应用程序的相关工作，比如监控或跟踪状态
3、 不负责重新启动失败任务
4、 资源分配单位用“资源容器”（Resource Container）表示
5、 Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务的资源量
6、 调度器是一个可拔插的组件，用户可以自行设计
7、 Yarn提供了多种直接可用的调度器，比如Fair Scheduler、Capacity Scheduler等
应用程序管理器：
负责管理整个系统的所有应用程序
ResourceManager详细功能：
1、 处理客户端请求，
2、 启动/监控Application Master（每个应用程序有一个，每个应用程序的master负责该应用程序的资源申请，任务调度，任务容错等），
3、 监控Node Manager（如果一个节点挂了，Resource Manager会将运行在该Node Manager上的任务通知Application master，让application master触发新的调度或者其他操作，），
4、 资源分配与调度。（集群中所有节点的资源统筹灵活的智能的分配给各个应用程序）
Application Matser
用户提交的每个应用程序只有一个，负责应用程序的管理
AM主要功能：
1、 与RM调度器协商以获取资源（用Container表示）
2、 将得到的任务进一步分配给内部的任务
3、 与NM通信以启动/停止任务
4、 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务
5、 YARN自带的AM实现：一个用于演示AM编写方法的示例程序distributedshell
详细功能：
1、 数据切分，
2、 为应用程序申请资源，并进一步分配给内部任务，
3、 任务监控与容错
Node Manager
整个集群有多个，负责单节点资源管理和使用，每个节点上的资源和任务管理器
详细功能：
1、 定时向RM汇报本节点上的资源使用情况和各个Container的运行状态
2、 单个节点上的资源管理和任务管理
3、 处理来自Resource Manager的命令（杀死任务或重启节点等）
4、 处理来自Application Master的命令（启动task等命令）
Container
是Yarn中的资源抽象，封装了某个节点上的多维度资源，对任务运行环境的抽象
Yarn会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源
Container不同于MRv1中的slot，是一个动态资源划分单位，是根据应用程序的需求动态生成的。
描述一系列信息：
1、 任务运行资源（节点、内存、CPU），任务执行在哪个节点，占用多少内存，多少CPU
2、 任务启动命令，
3、 任务运行环境，
4、 当Yarn把一个资源（管理资源）2G内存，一个CPU分配给一个应用程序的时候，将运行资源的描述封装为一个container，发送给Application master，application master根据资源的特点将资源分配给内部的某一个task，之后再与node manager通信启动container，进而启动task。
Yarn通信协议：
1、 RPC协议是连接各个组件的“大动脉”
2、 Yarn 采用的是拉式（pull-based）通信模型
3、 任何两个需要相互通信的组件之间只有一个RPC协议
4、 对于任何一个RPC协议，通信双方有一端是Client，另一端为Server，且Client总是主动连接Server的。
Yarn主要由以下几个RPC协议组成：
1、 ApplicationClientProtocol：JobClient通过该RPC协议提交应用程序、查询应用程序状态等。
2、 ResourceManagerAdministratorProtocol：Admin通过该RPC协议更新系统配置文件，比如节点黑白名单，用户队列权限等
3、 ApplicationMasterProtocol：AM通过该RPC协议向RM注册和撤销自己，并为各个任务申请资源
4、 ContainerManagerProtocol：AM通过该RPC要求NM启动或者停止Container，获取各个Container的使用状态等信息。
5、 ResourceTracker：NM通过该RPC协议向RM注册，并定时发送心跳信息汇报当前节点的资源使用情况和Container运行情况。
Yarn工作流程：
运行Yarn的应用程序有两类：短应用程序和长应用程序。
短应用程序
指在一定时间内可以运行完成并正常退出的应用程序，比如MR作业
长应用程序
是指不出意外，永不终止运行的应用程序，通常是一些服务，Storm Service，HBase Service等。
当用户向Yarn提交一个应用程序后，Yarn将分两步执行该应用程序：首先启动Application Master，然后由Application Master启动应用程序。
从并行编程的角度理解YARN
为快速处理一个大数据集，通常采用多线程并行编程
Yarn-总结资源管理系统：
对集群中各类资源进行抽象；按照一定的策略，将资源分配给应用程序或服务；采用一定的隔离机制防止应用程序或者服务之间因资源抢占而相互干扰
引入YARN这一层后，各种计算框架可各自发挥自己的优势，并由YARN进行统一管理。
云计算概念与Yarn：
三层服务：Infrastructure As A Service IaaS、PaaS和SaaS
1、 IaaS：基础设施即服务。消费者通过Internet可以从完善的计算机基础设施获得服务
2、 PaaS：平台即服务。PaaS是将软件研发的平台作为一种服务，以SaaS的模式提交给用户
3、 SaaS：软件即服务。 它是一种通过Internet提供软件的模式，用户无需购买软件，而是向提供商租用基于Web的软件，来管理企业经营活动
YARN可以看作PaaS层，它能够为不同类型的应用程序提供统一的管理和调度
Yarn 运行过程剖析
（以下默认为Yarn-Cluster模式）
- 用户通过Client向Resource Manager提交应用程序并指定Application Master是什么 需要多少CPU 内存（driver） 指定程序入口（主类 入口类） driver所需要的内存、cpu资源 应用程序所需要的额外jar包 需要的外部资源 以及 Executor端的相关资源情况，
- Resource Manager根据Application Master（driver端所需资源）通过调度器为Application Master寻找到匹配的资源，找到满足条件的Node后，ResourceManager 发送命令给Node Manager，告诉Node Manager 需要多少资源以及CPU，要求其启动Application Master进程。（在集群中选择一个满足Driver资源请求的节点启动Application Master进程。）
- Node Manager在相应的节点上启动Application master。
- 应用程序内部的逻辑，若是Map-Reduce Application master应用程序，Application master将作业按照数据切分为一个一个的Map和Reduce,之后汇总Map和Reduce总的需求（若是Spark Application Master，将Spark Job切分为跟多Stage，每个Stage会有很多Task，），然后和Resource Manager进行通信，根据应用提交时所指定的executor资源要求，通过心跳机制向Resource Manager申请资源，Resource Manager根据当前节点的资源使用情况给Application Master分配资源（这些资源是一个动态分配过程），通过心跳应答将在相应的节点的资源分配给应用程序。
- Application Master 根据Resource Manager分配给其的Executor 资源当前任务的需求，与对应的节点Node Manager进行通信，启动一个Task，
- Node Manager根据Application Master的描述（比如启动命令、需要的外部jar包、环境变量是什么？），在已分配资源的相应的Node上启动这一任务，以container形式封装这些任务。
Yarn容错性
1、 ResourceManager：存在单点故障，但Zookeeper实现HA BakMaster
2、 NodeManager：
a. 失败后，NM通过心跳将失败任务的情况告诉RM，RM将失败后任务告诉对应的AM；
b. AM决定如何处理失败的任务（大数据应用场景下 有些任务的失败 可以考虑丢弃）
3、 ApplicationMaster：
a. 失败后，由RM负责重启；
b. AM需处理内部任务的容错问题
4、 RMAPPMaster 会保存已经运行完成的Task，重启后无需重新运行。
Yarn 调度框架
双层调度框架
1、 RM将资源分配给AM
2、 AM收到RM分配的资源后，根据资源的特点和任务的情况采用相关的调度策略进一步分配给各个Task
基于资源预留的调度策略
1、 资源不够时，会为Task预留，直到资源充足（牺牲资源利用率）
2、 与“all or nothing”策略不同（Apache Mesos 要么给他 要么不给他你 产生饿死情况）
Yarn资源调度器 --
多类型资源调度
1、 可以对多种类型的资源进行调度，不同于MR1.0 基于slot进行的调度
2、 将多维度的资源抽象为一维度的slot
3、 资源调度的过程就是把slot资源分配给Task的过程，
Yarn的调度资源
1、 直接调度的是CPU和内存以及网络资源，没有slot类型概念
2、 采用DRF算法，Dominant Resource Fairness Fair Allocation of Multiple Resource Types
提供多种资源调度器
1、 FIFO
2、 Fair Scheduler(多用户共享模式调度器)
3、 Capacity Scheduler（多用户共享模式调度器）
调度器对比：
FifoScheduler
最简单的调度器，按照先进先出的方式处理应用
CapacityScheduler
FifoScheduler的多队列版本，每个队列可以限制资源使用量
队列间的资源分配以使用量作排列依据，使得容量小的队列有竞争优势
使得hadoop应用能够被多用户使用，且最大化整个集群资源的吞吐量
启动容量调度器之后，调度器会从classpath中加载capacity-scheduler.xml文件，完成容量调度器的初始化
FairScheduler
多队列，多用户共享资源。使得hadoop应用能够被多用户公平地共享整个集群资源的调度器
根据队列设定的最小共享量或者权重等参数，按比例共享资源
调度器的集群配置：
容量调度器参数定义和计算关系：
队列容量=yarn.scheduler.capacity.<queue-path>.capacity/100
队列绝对容量=父队列的 队列绝对容量队列容量
队列最大容量=yarn.scheduler.capacity.<queue-path>.maximum-capacity/100
队列绝对最大容量=父队列的 队列绝对最大容量队列最大容量
绝对资源使用比=使用的资源/全局资源
资源使用比=使用的资源/(全局资源 * 队列绝对容量)
最小分配量=yarn.scheduler.minimum-allocation-mb
用户上限=MAX(yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent,1/队列用户数量)
用户调整因子=yarn.scheduler.capacity.<queue-path>.user-limit-factor
最大提交应用=yarn.scheduler.capacity.<queue-path>.maximum-applications
如果小于0 设置为(yarn.scheduler.capacity.maximum-applications队列绝对容量)
单用户最大提交应用=最大提交应用(用户上限/100)用户调整因子
AM资源占比（AM可占用队列资源最大的百分比)
=yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent
如果为空，设置为yarn.scheduler.capacity.maximum-am-resource-percent
最大活跃应用数量=全局总资源/最小分配量AM资源占比队列绝对最大容量
单用户最大活跃应用数量=(全局总资源/最小分配量AM资源占比队列绝对容量)用户上限*用户调整因子
本地延迟分配次数=yarn.scheduler.capacity.node-locality-delay<code>
多租户资源调度器
1、 支持资源按比例分配
2、 支持层级队列划分方式（树形结构）
3、 支持资源抢占
资源分配模型：
Yarn 资源隔离方案
Yarn通过Resource Manager为应用分配资源，Node Manager获得相应的资源在其节点上执行Task，NodeManager 有责任为Task提供一个隔离的环境。
否咋，节点上所有的Task都在竞争资源，性能降低，服务质量得不到保证。
支持CPU和内存的两种资源隔离
1、 内存是一种决定生死的资源
2、 Cpu是一种影响快慢的资源
内存隔离：
1、 基于线程监控的方案：在每个节点上启动一个监控线程以对内存的访问和使用进行监控。一旦内存的资源使用量超过了其所申请的资源量，其将被杀死。
2、 基于Cgroups的方案：
CPU隔离：
1、 默认不对CPU资源进行隔离：yarn将cpu的资源分配交给node manager所在的操作系统，由os对cpu资源进行分配，
2、 基于Cgroups的方案：需要配置 默认没有打开
Yarn支持的调度语义：
应用程序向yarn申请资源时，向Yarn表达出所需资源的方式所需的格式及相关标准，成为调度语义。申请资源、归还资源
支持的语义：
1、 请求某个特定节点/机架上的特定资源量
2、 将某些节点加入或移除黑名单，不再为自己分配这些节点上的资源（可能某个节点不适合运行某种任务）
3、 请求归还这些资源
不支持的语义：
1、 请求任意节点/机架上的特定资源量
2、 请求一组或几组符合某种特质的资源
3、 超细粒度资源
4、 动态调整Container资源（目前支持）
框架运行在Yarn上的好处：
1、 应用程序部署变得更简单：只需部署YARN服务，各类应用不再自带服务
2、 服务部署变得更简单：用户可以运行一个应用程序的方式部署一套服务
3、 多版本共享集群资源：Cgroups隔离机制
4、 资源弹性管理：YARN可根据不同类型的应用程序压力情况，调整对应的资源使用量，实现资源弹性管理
Yarn上的计算框架
Yarn主要的使用是运行高级 的计算框架，不是用户写一个程序直接与yarn交互，这种情况很少出现。直接与计算框架交互，将计算框架与yarn交互，用户与计算框架进行交互，应用程序种类繁多，每种应用程序类型都对应一种计算框架，
Map map-reduce spark（stage） stage - DAG图
Yarn设计目标
通用的统一资源管理系统：同时运行长应用程序和短应用程序，
1、 长应用程序：通常情况下，永不停止运行的程序 service Http Server
2、 短应用程序：短时间 秒级 分钟级 小时级 内会结束运行的程序 MR Job Spark Job
以Yarn为核心的生态系统
在Yarn之上的，以MR为代表批处理应用程序 交互式的Tez 在线online的Hbase
流处理 Storm Graph 图计算框架 Spark内存计算框架
运行在Yarn上的计算框架：
Map-Reduce 离线计算框架
Tez：DAG计算框架
Storm：流式计算框架
内存计算框架：Spark
离线计算框架Map Reduce：
将计算过程分为两个阶段：Map和Reduce
Map阶段并行处理输入数据
Reduce阶段对Map结果进行汇总
Shuffle连接Map和Reduce两个阶段
Map Task将数据写到本地磁盘
Reduce Task从每个Map Task上读取一份数据
仅适合离线批处理
具有很好的容错性和扩展性
适合简单地批处理任务
缺点明显：启动开销大、过多使用磁盘导致效率低下等
MapReduce On Yarn
- Client提交MR应用程序至Yarn的Resource Manager的Applications Manager，
- Resource Manager的Applications Manager收到请求后找到一个节点Node Manager启动Application Master（MR APP Mstr MapReduce中已经实现好了），
- Application Master启动成功后，会根据输入数据的大小，将应用程序切分为很多的MapTask 和Reduce Task，
- Application Master向Resource Manager的Resource Scheduler发送请求资源信息，，根据Task所需申请
- Resource Manager的Resource Scheduler会根据当前资源的使用情况和任务状态进行资源的分配，产生一个心跳应答，动态的将资源分配给Application Master
- Application Master获得资源后，发送消息给Node Manager启动task
- Node Manager启动Container封装Task
- Node Manager的Task启动后会向Application Master 发送心跳，维护一个心跳信息，Application Master 通过心跳信息监控各个Task的运行状态。如果一段时间内未接收到相关Task的心跳信息，则认为该Task挂了，重新为Task申请资源，运行Task
DAG计算框架Tez
多个作业之间存在数据依赖关系，并形成一个依赖关系有向图（Directed Acyclic Graph），该图的计算称为“DAG计算”
Apache Tez：基于Yarn 的DAG计算框架
直接源于MapReduce框架，核心思想是将Map和Reduce两个操作进一步拆分
Map被拆分成Input、Processor、Sort、Merge和Output
Reduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output
分解后的元操作可以任意灵活组合，产生新的操作，这些操作经过一些控制程序组装后，可形成一个大的DAG作业
天生融入Hadoop 2.0中的资源管理平台YARN
Tez主要由两部分组成
数据处理引擎
DAGAppMaster
Tez数据处理引擎：
Tez提供了6中可编程组件，实现了一些常见的算法和组件
Input：对输入数据源的抽象，类似于MR模型中的InputFormat，它解析输入数据格式，并吐出一个个Key/value
Output：对输出数据源的抽象，类似于MR模型中的OutputFormat，它将用户程序产生的Key/value写入文件系统
Partitioner：对数据进行分片，类似于MR中的Partitioner
Processor：对计算单元的抽象，它从一个Input中获取数据，经用户定义的逻辑处理后，通过Output输出到文件系统
Task：对任务的抽象，每个Task由一个Input、Ouput和Processor组成
Maser：管理各个Task的依赖关系，并按照依赖关系执行他们
Tez数据处理引擎实现了一些常见的组件
Tez数据处理引擎的基础是Sort（排序）和Shuffle（混洗）
Tez提供了多种Input、Output、Task和Sort的实现
Input实现
LocalMergedInput（多个文件本地合并后作为输入）
ShuffledMergedInput（远程拷贝数据且合并后作为输入）
Output实现
InMemorySortedOutput（内存排序后输出）
LocalOnFileSorterOutput（本地磁盘排序后输出）OnFileSortedOutput（磁盘排序后输出）
Task实现
RunTimeTask
Sort实现
DefaultSorter（本地数据排序）
InMemoryShuffleSorter（远程拷贝数据并排序）
Tez On Yarn 优势：
1、 运行在Yarn之上，充分利用Yarn的资源管理和容错等功能
2、 提供了丰富的数据流 dataflow api
3、 扩展性良好的 Input-Processor-Output 运行时模型
4、 动态生成物理数据流关系
启动的不是Application Master 而是 DAG APlication Master
Tez Application Master
Tez ApplicationMaster直接源于MapReduce的ApplicationMaster，重用了大部分机制和代码
功能
数据切分和作业分解
任务调度
与ResourceManager进行通信，为DAG作业申请资源
与NodeManager进行通信，启动DAG作业中的任务
监控DAG作业的运行过程，确保它快速运行结束
每个DAGAppMaster负责管理一个DAG作业
DAGAppMaster优先为那些不依赖任何顶点的任务申请资源
DAG中的一个顶点由一定数目的任务组成
一旦一个顶点中所有任务运行完成，则认为该顶点运行结束
Tez优化技术
1、 如果每个作业都启动一个Application Master，性能将会很低。
2、 Application Master缓冲池：作业提交到AMPoolServer服务上，预启动若干个Application Master，形成一个Application Master缓冲池
3、 预先启动Container：Application Master启动时可以预先启动若干个Container
Container重用：
任务运行完成后，Application Master不会马上注销所使用的Container，而是将它重新分配给其他未运行的任务。
Tez应用场景：
1、 直接编写应用程序
2、 Tez提供一套通用编程接口
3、 适合编写有依赖关系的作业
4、 优化Pig、Hive等引擎->
5、 下一代Hive Stinger
好处1：避免查询语句转换成过多的MR作业后产生大量不必要的网络和磁盘IO
好处2：更加智能的任务处理引擎
Tez与其他系统对比
与Oozie对比
Oozie是工作流调度系统，按照用户定义好的作业依赖关系调度作业
Oozie只是一种作业依赖关系表达和调度框架，逻辑上并没有将有依赖关系的作业合并成一个作业来优化I/O读写
与MapReduce对比
MapReduce只是一种简单的数据处理模型
Tez可以包含任意多个数据处理阶段
Tez可作为MapReduce之下的数据处理引擎
Tez与MapReduce编程接口完全兼容
流式计算框架 Storm
1、 流式计算指的是被处理的数据像流水一样不断流入系统，而系统需要针对每条数据进行实时处理和计算，并永不停止（直到用户显式杀死进程）
2、 传统做法：由消息队列和消息处理者组成的实时处理网络进行实时计算，缺乏自动化，缺乏健壮性，伸缩性差
Storm典型应用场景
1、 广告；
2、 分布式rpc：由于storm的处理组件是分布式的，而且处理延迟极低，所以可以作为一个通用的分布式rpc框架来使用
360：Storm在实时网络攻击检测和分析的应用和改进 集群规模：46个集群，9000个节点，每个结点2-4个slot 利用云存储的空闲资源 应用：50多个业务，100多个topology
实时日志统计、网页分析、图片处理、人脸识别、……..
每天处理约120TB 200亿条
Stom 计算框架：
Master（Nimbus） 通过Zookeeper 与 slaves（Supervisor）进行通信，master挂了，supervisor仍然可以重新工作，只是任务不可以重新提交作业，一个supervisor可以运行多个worker，一个worker可以运行多个executor，一个executor可以运行多个task。
每个应用程序有一个spout 数据源（web 服务器，kafka），实时的将数据推送给blot（类似于map reduce），blot之间可以存在依赖关系。整个依赖关系称之为topology
Hadoop MRv1.0 Storm
系统服务 JobTracker(master) Nimbus(master Zookeeper)
TaskTracker(slave) Supervisor(slave)
Child(启动Task) Worker(启动Task)
应用程序名称 Job Topology
编程模型 Map-Reduce Spout/Blot
Shuffle Stream Grouping
1、 Nimbus：负责资源分配和任务调度
2、 Supervisor：负责接受nimbus分配的任务，启动和停止属于自己管理的worker进程
3、 Worker：运行具体处理组件逻辑的进程
4、 Task：worker中每一个spout/bolt的线程称为一个task。在storm0.8之后，task不再与物理线程对应，同一个spout/bolt的task可能会共享一个物理线程，该线程称为executor
5、 Topology：storm中运行的一个实时应用程序；各个组件间的消息流动形成逻辑上的一个拓扑结构
6、 Spout：在一个topology中产生源数据流的组件；通常情况下spout会从外部数据源中读取数据，然后转换为topology内部的源数据；Spout是一个主动的角色，其接口中有个nextTuple()函数，storm框架会不停地调用此函数，用户只要在其中生成源数据即可
7、 Bolt：在一个topology中接受数据然后执行处理的组件；Bolt可以执行过滤、函数操作、合并、写数据库等任何操作；Bolt是一个被动的角色，其接口中有个execute(Tupleinput)函数,在接受到消息后会调用此函数，用户可以在其中执行自己想要的
8、 Tuple：一次消息传递的基本单元；本来应该是一个key-value的map，但是由于各个组件间传递的tuple的字段名称已经事先定义好，所以tuple中只要按序填入各个value就行了，所以就是一个value list
9、 Stream：源源不断传递的tuple就组成了stream
10、 stream grouping：即消息的partition方法；Storm中提供若干种实用的grouping方式，包括shuffle, fields hash, all, global, none, direct和localOrShuffle等
Storm On Yarn
运行的不是短作业 而是服务 ，将master和slave运行在Storm Application Master上，通过Yarn将Nimbus和Supervisor部署在Yarn集群中，部署之后，Strom的client可以直接连接Storm Application Master 里的Nimbus，使用一个普通的Storm集群一样使用Storm，该Storm是通过Yarn启动，
Storm ApplicationMaster初始化时，将在同一个Container中启动Storm Nimbus和Storm Web UI两个服务
根据待启动的Supervisor数目向ResourceManager申请资源
ApplicationMaster将请求一个节点上所有资源然后启动Supervisor服务，也就是说，当前Supervisor将独占节点而不会与其他服务共享节点资源，这种情况下可避免其他服务对Storm集群的干扰
Storm ApplicationMaster还会启动一个Thrift Server以处理来自YARN-Storm Client端的各种请求
Storm On Yarn 优势
弹性计算资源
Storm可与YARN上其他应用程序（比如MapReduce批处理应用程序）共享整个集群中的资源
当Storm负载骤增时，可动态为它增加计算资源
当负载减小时，可释放部分资源，从而将这些资源暂时分配给负载更重的批处理应用程序
共享底层存储
Storm可与运行在YARN上的其他框架共享底层的一个HDFS存储系统
避免多个集群带来的维护成本
避免数据跨集群拷贝带来的网络开销和时间延迟
支持多版本
可同时将多个Storm版本运行YARN上，避免一个版本一个集群带来的维护成本
内存计算框架Spark
Spark是什么：
Spark是一种与Hadoop相似的开源集群计算环境
Spark基于MR算法实现的分布式计算，拥有Hadoop MR的优点，不同的是结果保存在内存中
Spark是一个针对超大数据集合的低延迟的集群分布式计算系统，比MapReduce快40倍左右
Spark 是在 Scala 语言中实现的，它将 Scala 用作其应用程序框架
Spark兼容Hadoop的API，能够读写Hadoop的HDFS HBASE 顺序文件等
传统Hadoop：
Spark：
Spark优势
轻
Spark 0.6核心代码有2万行
Spark很好地利用了Hadoop和Mesos的基础设施
快
Spark对小数据集能达到亚秒级的延迟
灵
Spark提供了不同层面的灵活性
巧
巧在借势和借力
Spark与Hadoop对比
Spark的中间数据放到内存中，对于迭代运算效率更高
Spark更适合于迭代运算比较多的ML和DM运算。因为在Spark里面，有RDD的抽象概念
Spark提供多种数据集操作类型
Transformations
包括map, filter, flatMap, sample, groupByKey, reduceByKey, union,join,cogroup,mapValues,sort,partionBy等
Actions
包括Count, collect, reduce, lookup, save等
编程模型比Hadoop更灵活，用户可以命名，物化，控制中间结果的存储、分区
Spark不适用那种异步细粒度更新状态的应用
可用性
容错性
Shark – Hive On Spark SparkSQL-DataFrame
Shark基本上就是在Spark的框架基础上提供和Hive一样的H iveQL命令接口
Shark使用了Hive的API来实现query Parsing和 Logic Plan generation
通过配置Shark参数，Shark可以自动在内存中缓存特定的RDD，实现数据重用，进而加快特定数据集的检索
Shark通过UDF用户自定义函数实现特定的数据分析学习算法，使得SQL数据查询和运算分析能结合在一起
Spark Streaming
构建在Spark上处理Stream数据的框架
Spark的低延迟执行引擎（100ms+）可以用于实时计算
相比基于Record的其它处理框架（如Storm），RDD数据集更容易做高效的容错处理
基本原理是将Stream数据分成小的时间片断（几秒），以类似batch批量处理的方式来处理这小部分数据
使得它可以同时兼容批量和实时数据处理的逻辑和算法
Spark核心概念-RDD
为什么会产生RDD？
解决传统MapReduce 迭代计算式要进行大量的磁盘IO操作
RDD：Resilient Distributed Dataset 弹性分布数据集
RDD是一个只读的，可分区的分布式数据集，这个数据集的全部或部分可以缓存在内存中，在多次计算间重用
RDD是一种有容错机制的特殊集合，可以分布在集群的节点上，以函数式编程操作集合的方式，进行各种并行操作
RDD可以cache到内存中，每次对RDD数据集的操作之后的结果，都可以存放到内存中
实质是一种更为通用的迭代并行计算框架，用户可以显示的控制计算的中间结果，然后将其自由运用于之后的计算
RDD存储与分区
用户可以选择不同的存储级别存储RDD以便重用
当前RDD默认是存储于内存，但当内存不足时，RDD会spill到disk
RDD在需要进行分区把数据分布于集群中时会根据每条记录Key进行分区，以此保证两个数据集在Join时能高效
Lineage 血统
为了保证RDD中数据的鲁棒性，RDD数据集通过所谓的血统关系(Lineage) 记住了它是如何从其它RDD中演变过来的
RDD的Lineage记录的是粗颗粒度的特定数据变换（Transformation）操作（filter, map, join etc.)行为
当这个RDD的部分分区数据丢失时，它可以通过Lineage获取足够的信息来重新运算和恢复丢失的数据分区
RDD容错机制：
两种方式：数据检查点和记录更新（默认）
只记录单个块上执行的单个操作，然后创建某个RDD的变换序列（血统）存储下来
RDD的容错机制又称“血统”容错
如何表达父RDD和子RDD之间的依赖关系？
依赖关系可以分两种，窄依赖和宽依赖
依赖关系分类的两个特性
计算子RDD的方式不同
数据恢复的方式不同
对于宽依赖，要在适当时机设置数据检查点
RDD只能从持久存储或通过Transformations操作产生，对于丢失部分数据分区只需根据它的lineage就可重新计算出来，而不需要做特定的Checkpoint
RDD的不变性，可以实现类Hadoop MapReduce的推测式执行
RDD的数据分区特性，可以通过数据的本地性来提高性能
RDD都是可序列化的，在内存不足时可自动降级为磁盘存储
RDD内部设计
源数据分割后的数据块，源代码中的splits变量
关于“血统”的信息，源码中的dependencies变量
一个计算函数（该RDD如何通过父RDD计算得到），源码中的iterator(split)和compute函数
一些关于如何分块和数据存放位置的元信息，如源码中的partitioner和preferredLocations
操作RDD：
如何获取RDD
从共享的文件系统获取（如：HDFS）
通过已存在的RDD转换
将已存在scala集合（只要是Seq对象）并行化，通过调用SparkContext的parallelize方法实现
改变现有RDD的持久性；RDD是懒散，短暂的
操作RDD的两个动作
Actions （ 如： count, collect, save等）
返回结果或把RDD数据写到存储系统中；
Actions是触发Spark启动计算的动因
Transformation（ 如：map, filter, groupBy, join等）
根据数据集创建一个新的数据集，计算后返回一个新RDD；
Transformations操作是Lazy的
窄依赖和宽依赖
RDD数据模型 ：
把RDD当简单元素的Transformation操作类别
输入输出一对一(element-wise)的算子，且结果RDD分区结构不变
主要是map、flatMap等
输入输出一对一，但结果RDD的分区结构发生了变化
如union（两个RDD合为一个）、coalesce（分区减少）
从输入中选择部分元素的算子
如filter、distinct、subtract和sample
针对Key-Value的Transformation操作类别
对单个RDD做element-wise运算
如mapValues
对单个RDD重排
如sort、partitionBy
对单个RDD基于key进行重组和reduce
如groupByKey、reduceByKey
对两个RDD基于key进行join和重组
如join、cogroup
RDD数据模型
Spark 调度框架
Spark的分布部署方式
Apache Spark支持三种分布式部署方式
Standalone
Spark on YARN
Spark on mesos
Standalone实现了容错性和资源管理
另外两种实现了部分容错性和资源管理交由同一的资源管理系统完成
Standalone模式
可单独部署到一个集群中，无需依赖任何其他资源管理系统
Spark在standalone模式下是没有任何单点故障问题的，这是借助zookeeper实现的
Spark standalone与MapReduce架构比较
都是由master/slaves服务组成的
各个节点上的资源被抽象成粗粒度的slot，有多少slot就能同时运行多少task
Spark On Mesos
官方推荐模式，Spark运行在Mesos上会比运行在YARN上更加灵活，更加自然
两种调度模式：粗粒度和细粒度
粗粒度模式（Coarse-grained Mode）
每个应用程序的运行环境由一个Dirver和若干个Executor组成
每个Executor占用若干资源，内部可运行多个Task
应用程序运行之前，申请好全部资源，运行结束后，回收这些资源
细粒度模式（Fine-grained Mode）
思想是按需分配
启动executor，但每个executor占用资源仅仅是自己运行所需的资源
mesos会为每个executor动态分配资源
单个Task运行完之后可以马上释放对应的资源
每个Task会汇报状态给Mesos slave和Mesos Master
Spark On Yarn模式
多进程VS多线程
MapReduce采用了多进程模型，便于细粒度控制每个任务占用的资源，但会消耗较多的启动时间
Spark同节点上的任务以多线程的方式运行在一个JVM进程中
多线程好处
任务启动速度快
有利于共享内存, 非常适合内存密集型任务
避免了每个任务重复申请资源带来的时间开销
不足
会出现严重的资源争用，难以细粒度控制每个任务占用资源
MapReduce多进程模型
每个Task运行在一个独立的JVM进程中
可单独为不同类型的Task设置不同的资源量，目前支持内存和CPU两种资源
每个Task都要经历“申请资源—> 运行Task –> 释放资源”的过程
Spark多线程模型
每个节点上可以运行一个或多个Executor服务
每个Executor配有一定数量的slot
每个Executor单独运行在一个JVM进程中，每个Task则是运行在Executor中的一个线程
同一个Executor内部的Task可共享内存
将Spark运行在Hadoop上，本质上是将Spark运行在Hadoop YARN上
之所以不采用Mesos而是YARN，是因为YARN拥有强大的社区支持，且逐步已经成为资源管理系统中的标准
spark-shell 是一个spark application，运行时需要向资源管理器申请资源
Spark Standalone Mode的运行
资源调度
Spark Standalone Cluster支持FIFO方式调度，不过，允许多个并发用户
监控和日志
通过Web UI来监控集群
日志：$SPARK_HOME/spark/logs
和Hadoop并用
Spark可以作为独立的服务，在已有的Hadoop集群设备上并行，并通过hdfs://URL存取Hadoop数据
Spark优势
1、 克服MR在迭代式计算和交互式计算方面的不足
2、 引入RDD（Resilient Distributed DataSets）数据表示模型
3、 RDD是一个有容错机制，可以被并行操作的数据集合，能够被缓存到内存或磁盘上。
基于Spark on Yarn 的淘宝数据挖掘平台
Spark On Yarn
与MR Tez 非常类似
1、 通过Yarn-Spark客户端Client提交 Spark Submission Spark Application 提交至Resources Manager
2、 Resources Manager找到程序主类和资源需求之后为Application Master申请资源
3、 申请资源之后与Node Manager发送命令启动Spark Application Master
4、 在 Spark Application Master内部启动Spark Container 里面有一个Cluster Scheduler 和web UI
5、 启动之后Application Master向Resource Manager申请资源，然后向Node Manager发出命令，启动Spark作业的Executor（StandaloneExecutorBackend），Executor里会有 很多Task，Cluster Scheduler向Executor调度很多Task执行，执行完成之后，Spark作业执行完毕。
Hbase On Yarn ： Hoya hortonworks
Impala On Yarn：LLAMA
Kafka On Yarn：kafka-yarn kkasravi
MapReduce2.0 & Yarn
一个MR应用程序的成功运行需要若干个模块：
1、 任务管理（由各个应用程序管理）和资源调度（每个应用程序都需要，Yarn统一管理）
2、 任务驱动模块 MapTask ReduceTask
3、 用户代码 Mapper Reducer
Yarn是一个资源管理系统，只负责资源管理和调度，MapReduce只是运行在Yarn上的一个应用程序，Yarn 对比于 Android MapReduce只是一个 app
MapReduce2.0组成：
Yarn（整个集群只有一个）Spark可以用、Storm也可以用 公用模块
MRAppMaster 一个应用程序一个
用户代码Mapper Reducer
MapReduce 1.0 与 MapReduce2.0区别：
MapReduce1.0是一个独立的系统，直接运行在Linux之上
MapReduce2.0是运行在Yarn上的计算框架，且可与多种框架同时一起运行在Yarn上。
2.0没有JobTracker 、 TaskTracker 这样的服务 必须依托于Yarn来运行
