分布式搭建步骤
1：克隆一台机器完成后，按以下步骤进行修改（作为源克隆主机）
1）修改网卡信息，路径/etc/sysconfig/network-scripts
2）删除70-persistent-net.rules这个文件，路径在：/etc/udev/rules.d
3）修改hosts文件，设置ip和主机名对映关系
如：
127.0.0.1 localhost
192.168.153.115 hm02
192.168.153.116 hs0201
192.168.153.117 hs0202
4）重启
5）删除hadoop和jdk的安装包（可选）
6）删除hadoop2.7.3下面的tmp目录
2：克隆从节点后，修改步骤
比上面的主节点的步骤，少3，5，6这几步
3：免密登陆设置
1）重新生成私钥和公钥（主从节点）
2）将公钥写入authorized_keys这个文件（主节点）
三台机器的免密设置
3）将2台从节点上面的公钥远程拷贝到主节点
4）在主节点上面将从节点的公钥合并到authorized_keys这个文件
5）把这已经合并了三台机器公钥的authorized_keys文件分发到两个从节点上面
cat id_rsa.pub_from_hs0201 >> authorized_keys
scp authorized_keys hadoop@hs0202:~/.ssh/authorized_keys
4：hadoop分布式搭建
hm02是主节点：namenode，resourcemanager
hs0201和hs0202是从节点：datanode，nodemanager
1):主从节点配置文件修改：
（如果配置文件多且修改的内容较多，最好是在一台机器上设置好，再克隆）
修改文件：
（1）core-site.xml
<value>hdfs://hm02:9000</value>
（2)slaves
添加从节点信息
hs0201
hs0202
（3）yarn-site.xml
<property>
<name>yarn.resourcemanager.hostname</name>
<value>hm02</value>
</property>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
2）格式化主节点上的hdfs
./hdfs namenode -format
3）启动集群进行测试
./sbin/start-all.sh
4）自带的mapreduce程序进行测试
Hadoop YARN产生背景
YARN产生背景—MapReduce 1.0固有问题
YARN产生背景—资源利用率
YARN产生背景—运维成本与数据共享
运维成本 如果采用“一个框架一个集群”的模式，则可能需要多个管理员管理这些集群，进而增加运维成本，而共享模式通常需要少数管理员即可完成多个框架的统一管理。
数据共享 随着数据量的暴增，跨集群间的数据移动不仅需花费更长的时间，且硬件成本也会大大增加，而共享集群模式可让多种框架共享数据和硬件资源，将大大减小数据移动带来的成本。
YARN产生背景—总结
直接源于MRv1在几个方面的缺陷
扩展性受限
单点故障
难以支持MR之外的计算
多计算框架各自为战，数据共享困难
MR：离线计算框架
Storm：实时计算框架
Spark：内存计算框架 。
YARN基本架构
ResourceManager
负责集群资源的统一管理和调度
详细功能
处理客户端请求
启动/监控ApplicationMaster
监控NodeManager
资源分配与调度
NodeManager
负责单节点资源管理和使用
详细功能
单个节点上的资源管理和任务管理
处理来自ResourceManager的命令
处理来自ApplicationMaster的请求
ApplicationMaster
每个应用有一个，负责应用程序的管理
详细功能
与RM调度器协商以获取资源；
将得到的任务进一步分配给内部的任务(资源的二次分配)；
与NM通信以启动/停止任务；
监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。
Container
对任务运行环境的抽象
描述一系列信息
任务运行资源（节点、内存、CPU）
任务启动命令
任务运行环境
YARN运行过程剖析
YARN容错性
ResourceManager
存在单点故障；
正在基于ZooKeeper实现HA
NodeManager
失败后，RM将失败任务告诉对应的AM；
AM决定如何处理失败的任务
ApplicationMaster
失败后，由RM负责重启；
AM需处理内部任务的容错问题
RMAppMaster会保存已经运行完成的Task，重启后无需重新运行。
YARN调度框架
双层调度框架
RM将资源分配给AM
AM将资源进一步分配给各个Task
基于资源预留的调度策略
资源不够时，会为Task预留，直到资源充足
与“ all or nothing”策略不同（ Apache Mesos）
YARN资源调度器
多类型资源调度
目前支持CPU和内存两种资源
提供多种资源调度器
FIFO
Fair Scheduler
Capacity Scheduler
多租户资源调度器
支持资源按比例分配
支持层级队列划分方式
支持资源抢占。
YARN资源隔离方案
支持内存和CPU两种资源隔离
内存是一种“决定生死”的资源
CPU是一种“影响快慢”的资源
内存隔离
基于线程监控的方案
CPU隔离
默认不对CPU资源进行隔离
应用程序种类繁多
YARN设计目标
通用的统一资源管理系统
同时运行长应用程序和短应用程序
长应用程序
通常情况下，永不停止运行的程序
Service、HTTP Server等
短应用程序
短时间（秒级、分钟级、小时级）内会运行结束的程序
MR job、Spark Job等
以YARN为核心的生态系统
运行在YARN上的计算框架
离线计算框架：MapReduce
DAG计算框架：TEZ
流式计算框架：Storm
内存计算框架：Spark
离线计算框架MapReduce
将计算过程分为两个阶段，Map和Reduce
Map阶段并行处理输入数据
Reduce阶段对Map结果进行汇总
Shuffle连接Map和Reduce两个阶段
Map Task将数据写到本地磁盘
Reduce Task从每个Map Task上读取一份数据
仅适合离线批处理
具有很好的容错性和扩展性
适合简单的批处理任务
缺点明显
启动开销大、过多使用磁盘导致效率低下等
MapReduce On YARN
DAG计算框架Tez
多个作业之间存在数据依赖关系，并形成一个依赖关系有向图（Directed Acyclic Graph ），该图的计算称为“ DAG计算”
Apache Tez：基于YARN的DAG计算框架
运行在YARN之上，充分利用YARN的资源管理和容错等功能；
提供了丰富的数据流（dataflow）API；
动态生成物理数据流关系。
Tez On YARN
Tez优化技术
ApplicationMaster缓冲池
作业提交到AMPoolServer服务上
预启动若干个ApplicationMaster，形成一个ApplicationMaster缓冲池
预先启动Container
ApplicationMaster启动时可以预先启动若干个Container
Container重用
任务运行完成后，ApplicationMaster不会马上注销它使用的Container，
而是将它重新分配给其他未运行的任务
Tez应用场景
直接编写应用程序
Tez提供了一套通用编程接口
适合编写有依赖关系的作业
优化Pig、Hive等引擎
下一代Hive：Stinger
好处1：避免查询语句转换成过多的MapReduce作业后产生大量不必要
的网络和磁盘IO
好处2：更加智能的任务处理引擎
流式计算框架Storm
流式（ Streaming） 计算，是指被处理的数据像流水一样不断流入系统，而系统需要针对每条数据进行实时处理和计算，并永不停止（直到用户显式杀死进程） ；
传统做法： 由消息队列和消息处理者组成的实时处理网络进行实时计算；
缺乏自动化
缺乏健壮性
伸缩性差
Storm出现
内存计算框架Spark
克服MapReduce在迭代式计算和交互式计算方面的不足
引入RDD（ Resilient Distributed Datasets）数据表示模型；
RDD是一个有容错机制，可以被并行操作的数据集合，能够被缓存到内存或磁盘上
Spark On YARN
Spark生态系统
346
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
