A.NameNodehtml
B.JobTrackerjava
C.DataNodenode
D.SecondaryNameNodelinux
E.tasktracker程序员
A.3 份web
B.2 份算法
C.1 份sql
D.不肯定数据库
A.SecondaryNameNodeapache
B.DataNode
C.TaskTracker
D.JobTracker
hadoop的集群是基于master/slave模式，namenode和jobtracker属于master，datanode和tasktracker属于slave，master只有一个，而slave有多个. SecondaryNameNode内存需求和NameNode在一个数量级上，因此一般secondary NameNode（运行在单独的物理机器上）和 NameNode 运行在不一样的机器上。 JobTracker对应于NameNode,TaskTracker对应于DataNode. DataNode和NameNode是针对数据存放来而言的.JobTracker和TaskTracker是对于MapReduce执行而言的. mapreduce中几个主要概念，mapreduce 总体上能够分为这么几条执行线索： jobclient，JobTracker与TaskTracker。 一、JobClient会在用户端经过JobClient类将已经配置参数打包成jar文件的应用存储到hdfs，并把路径提交到Jobtracker,而后由JobTracker建立每个Task（即 MapTask 和 ReduceTask） 并将它们分发到各个TaskTracker服务中去执行。 二、JobTracker是一master服务，软件启动以后JobTracker接收Job，负责调度Job的每个子任务。task运行于TaskTracker上，并监控它们，若是发现有失败的task就从新运行它。通常状况应该把JobTracker 部署在单独的机器上。 三、TaskTracker是运行在多个节点上的slaver服务。TaskTracker主动与JobTracker通讯，接收做业，并负责直接执行每个任务。 TaskTracker 都须要运行在HDFS的DataNode上。
A.它是 NameNode 的热备
B.它是内存没有要求
C.他的目的使帮助 NameNode 合并编辑日志，减小 NameNode 启动时间
D. SecondaryNameNode 应与 NameNode 部署到一个节点
A.32MB
B.64MB
C.128MB
注 : Hadoop在1.X版本中块的大小默认64M,在hadoop2.X版本中,默认128M
A.CPU
B.网络
C.磁盘 IO
D.内存
A.Puppet
B.Pdsh
C.ClouderaManager
D.Zookeeper
A.数据通过 NameNode 传递 DataNode
B.Client 端将文件切分为 Block，依次上传
C.Client 只上传数据到一台 DataNode，而后由 NameNode 负责 Block 复制工做
A.单机版
B.伪分布式
C.分布式
A、 TextInputFormat
B、 KeyValueInputFormat
C、 SequenceFileInputFormat
Zookeeper:是一个开源的分布式应用程序协调服务,基于zookeeper能够实现同步服务，配置维护，命名服务。
Flume:一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统。
Hbase:是一个分布式的、面向列的开源数据库, 利用Hadoop HDFS做为其存储系统.
Hive:基于Hadoop的一个数据仓库工具，能够将结构化的数据档映射为一张数据库表，并提供简单的sql 查询功能，能够将sql语句转换为MapReduce任务进行运行。
Sqoop:将一个关系型数据库中的数据导进到Hadoop的 HDFS中，也能够将HDFS的数据导进到关系型数据库中。
1>.Core-site.xml：
(1)fs.defaultFS:hdfs://cluster1(域名)，这里的值指的是默认的HDFS路径 。
(2)hadoop.tmp.dir:/export/data/hadoop_tmp,这里的路径默认是NameNode、DataNode、JournalNode等存放数据的公共目录。用户也能够本身单独指定这三类节点的目录。
(3)ha.zookeeper.quorum:hadoop101:2181,hadoop102:2181,hadoop103:2181,这里是ZooKeeper集群的地址和端口。注意，数量必定是奇数，且很多于三个节点 。
2>.Hadoop-env.sh: 只需设置jdk的安装路径，如：export JAVA_HOME=/usr/local/jdk 本机j位置
3>.Hdfs-site.xml：
(1) dfs.replication:他决定着系统里面的文件块的数据备份个数，默认为3个。
(2) dfs.data.dir:datanode节点存储在文件系统的目录 。
(3) dfs.name.dir:是namenode节点存储hadoop文件系统信息的本地系统路径 。
4>.Mapred-site.xml：
(1)mapred.job.tracker:是jobtracker的主机和端口配置 。
a) NameNode它是hadoop中的主服务器，管理文件系统名称空间和对集群中存储的文件的访问，保存有 metadate.
b).SecondaryNameNode它不是namenode的冗余守护进程，而是提供周期检查点和清理任务。帮助NN合并editslog，减小NN启动时间。
c)DataNode它负责管理链接到节点的存储（一个集群中能够有多个节点）。每一个存
储数据的节点运行一个datanode守护进程。
d)ResourceManager（JobTracker）JobTracker负责调度DataNode上的工做。每一个DataNode有一个TaskTracker，它们执行实际工做。
e) NodeManager（TaskTracker）执行任务
f) DFSZKFailoverController高可用时它负责监控NN的状态，并及时的把状态信息写入ZK。它经过一个独立线程周期性的调用NN上的一个特定接口来获取NN的健康状态。FC也有选择谁做为Active NN的权利，由于最多只有两个节点，目前选择策略还比较简单（先到先得，轮换）。
g) JournalNode 高可用状况下存放namenode的editlog文件.
写入HDFS过程：
Client调用DistributedFileSystem对象的create方法，建立一个文件输出流（FSDataOutputStream）对象，经过DistributedFileSystem对象与Hadoop集群的NameNode进行一次RPC远程调用，在HDFS的Namespace中建立一个文件条目（Entry），该条目没有任何的Block，经过FSDataOutputStream对象，向DataNode写入数据，数据首先被写入FSDataOutputStream对象内部的Buffer中，而后数据被分割成一个个Packet数据包，以Packet最小单位，基于Socket链接发送到按特定算法选择的HDFS集群中一组DataNode（正常是3个，可能大于等于1）中的一个节点上，在这组DataNode组成的 Pipeline上依次传输 Packet， 这组 DataNode 组成的 Pipeline反方向上，发送 ack，最终由 Pipeline 中第一个 DataNode 节点将 Pipeline ack发送给Client，完成向文件写入数据，Client 在文件输出流（FSDataOutputStream）对象上调用close方法，关闭流.调用DistributedFileSystem对象的complete 方法，通知 NameNode 文件写入成功.
读取文件过程：
使用HDFS提供的客户端开发库Client，向远程的Namenode发起RPC请求；Namenode会视状况返回文件的部分或所有block列表，对于每一个block，Namenode都会返回有该block拷贝的DataNode地址；客户端开发库Client会选取离客户端最接近的DataNode来读取block；若是客户端自己就是DataNode,那么将从本地直接获取数据.读取完当前block的数据后，关闭与当前的DataNode链接，并为读取下一个block寻找最佳的DataNode；当读完列表的block后，且文件读取尚未结束，客户端开发库会继续向Namenode获取下一批的block列表。读取完一个block都会进行 checksum 验证，若是读取 datanode 时出现错误，客户端会通知 Namenode，而后再从下一个拥有该 block 拷贝的 datanode 继续读。
hadoop 是一套处理大数据的生态系统，包括文件存储HDFS ，计算框架MapReduce调度框架Yarn，数据库Hbase ，数据仓库Hive，协调与锁服务zookeeper，关系型数 据库与Hbase转换工具sqoop，工做流模块Oozie,机器学习模块mahout.
客户端经过把请求发送给NameNode active，NN会把文件切成1个到N个固定大小的block（通常默认为128M）并上传到DN中。当全部block拷贝结束时，NN会当即通知客户端上传结果。但此时上传的流程还未结束。DN还须要根据配置信息的副本数量，在不一样的机架节点上经过局域网做数据拷贝工做。
节点上线操做：
当要新上线数据节点的时候，须要把数据节点的名字追加在 dfs.hosts 文件中
一，关闭新增节点的防火墙
二，在 NameNode 节点的 hosts 文件中加入新增数据节点的 hostname
三，在每一个新增数据节点的 hosts 文件中加入 NameNode 的 hostname
四，在 NameNode 节点上增长新增节点的 SSH 免密码登陆的操做
五，在 NameNode 节点上的 dfs.hosts 中追加上新增节点的 hostname,
六，在其余节点上执行刷新操做：hdfs dfsadmin -refreshNodes
七，在 NameNode 节点上，更改 slaves 文件，将要上线的数据节点 hostname 追加
到 slaves 文件中
八，启动 DataNode 节点
九，查看 NameNode 的监控页面看是否有新增长的节点
节点下线操做：
一，修改/conf/hdfs-site.xml 文件
二，肯定须要下线的机器，dfs.osts.exclude 文件中配置好须要下架的机器，这个是阻
止下架的机器去链接 NameNode
三，配置完成以后进行配置的刷新操做./bin/hadoop dfsadmin -refreshNodes,这个
操做的做用是在后台进行 block 块的移动
四，当执行三的命令完成以后，须要下架的机器就能够关闭了，能够查看如今集
群上链接的节点，正在执行 Decommission，会显示：
Decommission Status : Decommission in progress 执行完毕后，会显示：
Decommission Status : Decommissioned
五，机器下线完毕，将他们从 excludes 文件中移除。
JobTracker 是一个 master 服务，软件启动以后 JobTracker 接收 Job，负责调度 Job的每个子任务 task 运行于 TaskTracker 上，并监控它们，若是发现有失败的 task 就从新运行它。通常状况应该把 JobTracker 部署在单独的机器上。
TaskTracker 是运行在多个节点上的 slaver 服务。TaskTracker 主动与 JobTracker 通讯，接收做业，并负责直接执行每个任务
推测执行机制是 Hadoop 对“拖后腿”的任务的一种优化机制，当一个做业的某些任务运行速度明显慢于同做业的其余任务时，Hadoop 会在另外一个节点 上为“慢任务”启动一个备份任务，这样两个任务同时处理一份数据，而 Hadoop 最终会将优先完成的那个任务的结果做为最终结果，并将另外一个任务杀掉
链接jobtrack服务器的配置项，默认不写是local，在本地运行，默认 map 数1，reduce数1。
splitSize=max{minSize,min{maxSize,blockSize}}
map数量由处理的数据分红的block数量决定default_num = total_size / split_size;
reduce的数量job.setNumReduceTasks(x);x 为reduce的数量
具体的数据分片是这样的，InputFormat在默认状况下会根据hadoop集群HDFS块大小进行分片，每个分片会由一个map任务来进行处理，固然用户仍是能够经过参数mapred.min.split.size参数在做业提交客户端进行自定义设置。还有一个重要参数就是mapred.map.tasks，这个参数设置的map数量仅仅是一个提示，只有当InputFormat决定了map任务的个数比mapred.map.tasks值小时才起做用。一样，Map任务的个数也能经过使用JobConf的conf.setNumMapTasks(int num)方法来手动地设置。这个方法可以用来增长map任务的个数，可是不能设定任务的个数小于Hadoop系统经过分割输入数据获得的值
纯粹的 mapreduce task 的 reduce task 数很简单，就是参数 mapred.reduce.tasks
的值，hadoop-site.xml 文件中和 mapreduce job 运行时。不设置的话默认为 1
ResourceManager HA：在apache hadoop 4.4 或者CDH5.0.0 版本以后，增长了ResourceMangerHA 特性，支持基于Zookeeper 的热主备切换。
磁盘容错：增长了几个对多磁盘很是友好地参数，这些参数容许YARN 更好地使用NodeManager 上的多块磁盘.
资源调度器：Fair Scheduler 增长了容许用户在线将一个应用程序从一个队列转移到另一个队列。
reduce side join : 在map 阶段，map 函数同时读取两个文件File1 和File2，为了区分
两种来源的key/value 数据对，对每条数据打一个标签（tag）,好比：tag=0 表示来自文件File1，
tag=2 表示来自文件File2。
map side join : Map side join 是针对如下场景进行的优化：两个待链接表中，有一个表很是大，而另外一个表很是小，以致于小表能够直接存放到内存中。这样，咱们能够将小表复制多份，让每一个map task 内存中存在一份（好比存放到hash table 中），而后只扫描大表：对于大表中的每一条记录key/value，在hash table 中查找是否有相同的key 的记录，若是有，
则链接后输出便可。
Semi Join : Semi Join，也叫半链接，是从分布式数据库中借鉴过来的方法。它的产生动机是：对于reduce side join，跨机器的数据传输量很是大，这成了join 操做的一个瓶颈，
若是可以在map 端过滤掉不会参加join 操做的数据，则能够大大节省网络IO。
reduce side join + BloomFilter : BloomFilter 最多见的做用是：判断某个元素是否在一个集合里面。它最重要的两个方法是：add() 和contains()。最大的特色是不会存在 falsenegative，即：若是contains()返回false，则该元素必定不在集合中，但会存在必定的 falsepositive，即：若是contains()返回true，则该元素必定可能在集合中。
SequenceFile文件是Hadoop用来存储二进制形式的key-value 对而设计的一种平面文件;Hadoop 的HDFS 和MapReduce子框架主要是针对大数据文件来设计的，在小文件的处理上不但效率低下，并且十分消耗磁盘空间(每个小文件占用一个Block,HDFS 默认block大小为64M)。
解决办法一般是选择一个容器，将这些小文件组织起来统一存储。HDFS提供了两种类型的容器，分别是SequenceFile和MapFile。
SequenceFile的每条记录是可序列化的字符数组。
序列化是指将结构化的对象转化为字节流以便在网络上传输或写入到磁盘进行永久存 储的过程，反序列化是指将字节流转回结构化对象的过程.
加入了yarn 解决了资源调度的问题。
加入了对zookeeper 的支持实现比较可靠的高可用.
二次排序:就是首先按照第一字段排序，而后再对第一字段相同的行按照第二字段排序，注意不能破坏第一次排序的结果。
在Hadoop中，默认状况下是按照key进行排序。对于同一个key，reduce函数接收到的value list是按照value 排序的。
有两种方法进行二次排序，分别为：buffer and in memory sort和value-to-key conversion。
对于buffer and in memory sort，主要思想是：在reduce()函数中，将某个key对应的全部value保存下来，而后进行排序。 这种方法最大的缺点是：可能会形成 out of memory。
对于value-to-key conversion，主要思想是：将key和部分value拼接成一个组合key（实现WritableComparable接口或者调用setSortComparatorClass函数），这样reduce获取的结果即是先按key排序，后按value排序的结果，须要注意的是，用户须要本身实现Paritioner，以便只按照key进行数据划分。Hadoop显式的支持二次排序，在Configuration 类中有个 setGroupingComparatorClass()方法，可用于设置排序 group的 key 值。
具体参考：http://www.cnblogs.com/xuxm2007/archive/2011/09/03/2165805.html
参考网址：http://my.oschina.net/leejun2005/blog/95186?fromerr=cDqkUyup
一个是在map side发生在spill后partition前。
一个是在reduce side发生在copy后 reduce前。
mapReduce的四个阶段：
Splitting :在进行map 计算以前，mapreduce 会根据输入文件计算输入分片（inputsplit），每一个输入分片（input split）针对一个map 任务。输入分片（input split）存储的并不是数据自己，而是一个分片长度和一个记录数据位置的数组，输入分片（input split）每每和hdfs 的block（块）关系很密切，假如咱们设定hdfs 的块的大小是64mb，若是咱们输入有三个文件，大小分别是3mb、65mb 和127mb，那么mapreduce 会把3mb 文件分为一个输入分片（input split），65mb 则是两个输入分片（input split）而127mb 也是两个输入分片（input split），换句话说咱们若是在map 计算前作输入分片调整，例如合并小文件，那么就会有5 个map 任务将执行，并且每一个map 执行的数据大小不均，这个也是mapreduce 优化计算的一个关键点。
Mapping:就是程序员编写好的map 函数了，所以map 函数效率相对好控制，并且通常map 操做都是本地化操做也就是在数据存储节点上进行；
Shuffle:描述着数据从map task 输出到reduce task 输入的这段过程。
Reduce:对Map阶段多个文件的数据进行合并
分区，排序，溢写，拷贝到对应reduce机器上，增长combiner，压缩溢写的文件
在MR做业中的Map阶段会输出结果数据到磁盘中。
Combiner只应该适用于那种Reduce的输入（key：value与输出（key：value）类型彻底一致，且不影响最终结果的场景。好比累加，最大值等，也能够用于过滤数据，在 map端将无效的数据过滤掉。
在这些需求场景下，输出的数据是能够根据key值来做合并的，合并的目的是减小输出的数据量，减小IO的读写，减小网络传输,以提升MR的做业效率。
1.combiner的做用就是在map端对输出先作一次合并,以减小传输到reducer的数据量.
2.combiner最基本是实现本地key的归并,具备相似本地reduce,那么全部的结果都是reduce完成,效率会相对下降。
3.使用combiner,先完成的map会在本地聚合,提高速度
dfs.namenode.http-address:50070
dfs.datanode.address:50010
fs.defaultFS:8020
yarn.resourcemanager.webapp.address:8088
一.mapper调优
mapper调优主要就一个目标：减小输出量。
咱们能够经过增长combine阶段以及对输出进行压缩设置进行mapper调优。
1>combine合并： 实现自定义combine要求继承reducer类。比较适合map的输出是数值型的，方便进行统计。
2>压缩设置：在提交job的时候分别设置启动压缩和指定压缩方式。
二.reducer调优
reducer调优主要是经过参数调优和设置reducer的个数来完成。
reducer个数调优：
要求：一个reducer和多个reducer的执行结果一致，不能由于多个reducer致使执行结果异常。
规则：通常要求在hadoop集群中的执行mr程序，map执行完成100%后，尽可能早的看到reducer执行到33%，能够经过命令hadoop job -status job_id或者web页面来查看。
缘由：map的执行process数是经过inputformat返回recordread来定义的；而reducer是有三部分构成的，分别为读取mapper输出数据、合并全部输出数据以及reduce处理，其中第一步要依赖map的执行，因此在数据量比较大的状况下，一个reducer没法知足性能要求的状况下，咱们能够经过调高reducer的个数来解决该问题。
优势：充分利用集群的优点。
缺点：有些mr程序无法利用多reducer的优势，好比获取top n的mr程序
hadoop和R语言在各自的领域都至关的强大，由RevolutionAnalytics发起的一个开源项目RHadoop将R语言与Hadoop结合在一块儿，很好发挥了R语言特长。广大R语言爱好者借助强大工具RHadoop，能够在大数据领域大展拳脚。
1. Hadoop家族的强大之处，在于对大数据的处理，让原来的不可能（TB,PB数据量计算），成为了可能。
2.R语言的强大之处，在于统计分析，在没有Hadoop以前，咱们对于大数据的处理，要取样本，假设检验，作回归，长久以来R语言都是统计学家专属的工具。
3. hadoop重点是全量数据分析，而R语言重点是样本数据分析。 两种技术放在一块儿，恰好是取长补短。 4.用R语言，经过分析少许数据，对业务目标回归建模，并定义指标，用Hadoop从海量日志数据中，提取指标数据，用R语言模型，对指标数据进行测试和调优
5.R和Hadoop分别都起着很是重要的做用，以计算机开发人员的思路，全部有事情都用Hadoop去作，没有数据建模和证实，”预测的结果”必定是有问题的。以统计人员的思路，全部的事情都用R去作，以抽样方式，获得的“预测的结果”也必定是有问题的。因此让两者结合，是产界业的必然的导向，也是产界业和学术界的交集，同时也为交叉学科的人才提供了更广阔的发展空间
离线计算框架，过程分为split map shuffle reduce四个过程 。
架构节点有：Jobtracker TaskTracker 。
Split将文件分割，传输到mapper，mapper接收KV形式的数据，通过处理，再传到shuffle过程。
Shuffle先进行HashPartition或者自定义的partition，会有数据倾斜和reduce的负载均衡问题；再进行排序，默认按字典排序；为减小mapper输出数据，再根据key进行合并，相同key的数据value会被合并；最后分组造成（key,value{}）形式的数据，输出到下一阶段 。
Reduce输入的数据就变成了，key+迭代器形式的数据，再进行处理
相同点：
TextInputformat和KeyValueTextInputFormat都继承了FileInputFormat类，都是每一行做为一个记录；
区别：
TextInputformat将每一行在文件中的起始偏移量做为 key，每一行的内容做为value。默认以\n或回车键做为一行记录。
KeyValueTextInputFormat 适合处理输入数据的每一行是两列，并用 tab 分离的形式
在执行 mapreduce 以前，原始数据被分割成若干个 split，每一个 split 做为一个 map
任务的输入，在 map 执行过程当中 split 会被分解成一个个记录（key-value 对）。
InputFormat 是 MapReduce 中一个很经常使用的概念是文件拆分必须实现的一个接口，包含了两个方法：
public interface InputFormat<K, V> {
InputSplit[] getSplits(JobConf job, int numSplits) throws IOException;
RecordReader<K, V> createRecordReader(InputSplit split, TaskAttemptContext
context) throws IOException;
}
这两个方法分别完成如下工做：
方法 getSplits 将输入数据切分红 splits，splits 的个数即为 map tasks 的个数，
splits 的大小默认为块大小，即 64M
方法 getRecordReader 将每一个 split 解析成 records, 再依次将 record 解析成
<K,V>对，也就是说 InputFormat 完成如下工做：InputFile --> splits --> <K,V>
系 统 常 用 的 InputFormat 又 有 哪 些 呢 ？ TextFileInputFormat ，
KeyValueTextFileInputFormat，SequenceFileInputFormat<key,value>,
NLineInputFormat 其中 Text InputFormat 即是最经常使用的，它的 <K,V>就表明 <行偏移,
该行内容>
然而系统所提供的这几种固定的将 InputFile 转换为 <K,V>的方式有时候并不能知足我
们的需求：
此时须要咱们自定义 InputFormat ，从而使 Hadoop 框架按照咱们预设的方式来将
InputFile 解析为<K,V>
在领会自定义 InputFormat 以前，须要弄懂一下几个抽象类、接口及其之间的关系：
InputFormat(interface), FileInputFormat(abstract class), TextInputFormat(class),
RecordReader (interface), Line RecordReader(class)的关系FileInputFormat implements InputFormat
TextInputFormat extends FileInputFormat
TextInputFormat.get RecordReader calls Line RecordReader
Line RecordReader implements RecordReader
对于 InputFormat 接口，上面已经有详细的描述
再看看 FileInputFormat，它实现了 InputFormat 接口中的 getSplits 方法，而将
getRecordReader 与 isSplitable 留给具体类(如 TextInputFormat )实现， isSplitable 方
法一般不用修改，因此只须要在自定义的 InputFormat 中实现
getRecordReader 方 法 即 可 ， 而 该 方 法 的 核 心 是 调 用 Line RecordReader( 即 由
LineRecorderReader 类来实现 " 将每一个 s plit 解析成 records, 再依次将 record 解析成
<K,V>对" )，该方法实现了接口 RecordReader
public interface RecordReader<K, V> {
boolean next(K key, V value) throws IOException;
K createKey();
V createValue();
long getPos() throws IOException;
public void close() throws IOException;
float getProgress() throws IOException;
}
定义一个 InputFormat 的核心是定义一个相似于LineRecordReader的RecordReader
Hadoop 的 MapReduce 框架来处理数据，主要是面向海量大数据，对于这类数据，Hadoop 可以使其真正发挥其能力。对于海量小文件，不是说不能使用 Hadoop 来处理，只不过直接进行处理效率不会高，实际应用中，咱们在使用 Hadoop 进行计算的时候，须要考虑将小数据转换成大数据，好比经过合并压缩等方法，咱们经过自定义 InputFormat和RecordReader来实现对海量小文件的并行处理
若是没有自定义的 partitioning，则默认的 partition 算法，即根据每一条数据的 key
的 hashcode 值摸运算（%）reduce 的数量，获得的数字就是“分区号“
map task上的洗牌（shuffle）结束，此时 reducer task 上的洗牌开始，抓取 fetch 所
属于本身分区的数据，同时将这些分区的数据进行排序sort（默认的排序是根据每一条数据的键的字典
排序），进而将数据进行合并merge，即根据key相同的，将其 value 组成一个集合，最后输出结果
（1）默认的调度器 FIFO
Hadoop中默认的调度器，它先按照做业的优先级高低，再按照到达时间的前后选择被执行的做业。
（2）计算能力调度器 Capacity Scheduler
支持多个队列，每一个队列可配置必定的资源量，每一个队列采用FIFO调度策略，为了防止同一个用户的做业独占队列中的资源，该调度器会对同一用户提交的做业所占资源量进行限定。调度时，首先按如下策略选择一个合适队列：计算每一个队列中正在运行的任务数与其应该分得的计算资源之间的比值，选择一个该比值最小的队列；而后按如下策略选择该队列中一个做业：按照做业优先级和提交时间顺序选择，同时考虑用户资源量限制和内存限制。
（3）公平调度器 Fair Scheduler
同计算能力调度器相似，支持多队列多用户，每一个队列中的资源量能够配置，同一队列中的做业公平共享队列中全部资源。实际上， Hadoop的调度器远不止以上三种，最近，出现了不少针对新型应用的Hadoop调度器。
（4）适用于异构集群的调度器LATE
现有的 Hadoop 调度器都是创建在同构集群的假设前提下，具体假设以下：
1）集群中各个节点的性能彻底同样
2）对于 reduce task，它的三个阶段：copy、 sort 和 reduce，用时各占 1/3
3）同一 job 的同类型的 task 是一批一批完成的，他们用时基本同样。
现有的Hadoop调度器存在较大缺陷，主要体如今探测落后任务的算法上：若是一个task 的进度落后于同类型 task进度的20%，则把该task当作落后任务(这种任务决定了job的完成时间，需尽可能缩短它的执行时间)，从而为它启动一个备份任务（speculative task）。
若是集群异构的，对于同一个task，即便是在相同节点上的执行时间也会有较大差异，于是在异构集群中很容易产生大量的备份任务。
LATE调度器从某种程度上解决了现有调度器的问题，它定义三个阈值 ：
SpeculativeCap，系统中最大同时执行的speculative task 数目（做者推荐值为总slot数的10%）； SlowNodeThreshold（做者推荐值为25%）：得分（分数计算方法见论文）低于该阈值的node（快节点）上不会启动 speculative task；SlowTaskThreshold（做者推荐值为 25%）：当 task 进度低于同批同类 task 的平均进度的 SlowTaskThreshold 时，会为该 task 启动 speculative task。它的调度策略是：当一个节点出现空闲资源且系统中总的备份任务数小 于 SpeculativeCap 时， a.若是该节点是慢节点（节点得分高 于SlowNodeThreshold），则忽略这个请求。 b.对当前正在运行的 task 按估算的剩余完成时间排序 c.选择剩余完成时间最大且进度低于 SlowTaskThreshold 的 task，为该 task 启动备份任务。
（5）适用于实时做业的调度器Deadline Scheduler和Constraint-based Scheduler
这种调度器主要用于有时间限制的做业（Deadline Job），即给做业一个deadline时间，让它在该时间内完成。实际上，这类调度器分为两种，软实时（容许做业有必定的超时）做业调度器和硬实时（做业必须严格按时完成）做业调度器。
Deadline Scheduler 主要针对的是软实时做业，该调度器根据做业的运行进度和剩余时间动态调整做业得到的资源量，以便做业尽量的在 deadline 时间内完成。
Constraint-based Scheduler 主要针对的是硬实时做业，该调度器根据做业的deadline和当前系统中的实时做业运行状况，预测新提交的实时做 业能不能在 deadline时间内完成，若是不能，则将做业反馈给用户，让他重调整做业的 deadline
Hadoop 内置的输出文件格式有：
MultipleOutputs<K,V> 能够把输出数据输送到不一样的目录；
在自定义的reduce的函数中首先使用setup函数（注：该函数在task启动后数据处理前就调用一次）new出MultipleOutputs 对象，利用该对象调用 write 方法定义输出的目录
Hadoop序列化机制，支持多语言的交互
Hadoop 集群从三个角度划分为两个角色。 Hadoop 集群包括 hdfs 做为文件存储系统，mapreduce 做为分布式计算框架。
(1)最基本的划分为主节点和从节点
(2)在 hdfs 中，Namenode 做为主节点，接收客户端的读写服务。 存储文件的的元数据如文件名，文件目录结构，文件属性(生成时间，副本数，文件权限)，以及 block所在的datanode 等等，namenode 的元数据信息会在启动后加载到内存，metadata存储到磁盘文件名为” fsimage” ,block 的信息不会保存到 fsimage,edits 记录对metadata 的操做日志datanode 做为从节点。 Datanode 的做用是存储数据即 block，启动 datanode 线程的时候会向 namenode 汇报 block 信息，经过向 namenode 发送心跳保持与其联系，若是 namenode10 分钟没有收到 datanode 的心跳，则认为 datanode 挂了，并复制其上的 block 到其余 datanode。
(3)在 mapreduce 中的主节点为 jobTracker 和 tasktracker。
JobTracker 做为主节点，负责调度分配每个子任务 task 运行于 taskTracker上，若是发现有失败的task 就从新分配到其余节点，每一个 Hadoop 集群通常有一个JobTaskTracker，运行在 master 节点上。
TaskTracker主动与JobTracker通讯，接收做业，并负责直接执行每个任务，为了减小网络带宽TaskTracker 最好运行在 datanode 上
Mapreduce 程序效率的瓶颈在于两点：
一计算机性能
二 I/O 操做优化
优化分为时间和空间两种常见的优化策略以下：
1,输入的文件尽可能使用大文件，众多的小文件会致使map的数量众多，每一个map任务都会形成一些性能的损失，若是输入的是小的文件能够在进行mapreduce处理以前整合成为大文件，或者直接采用ConbinFileInputFormat来做为输入方式，此时，hadoop 会考虑节点和集群的位置信息，决定将哪些文件打包到一个单元中。
2,合理的分配 map 和 reduce 的任务的数量.
3,压缩中间数据，减小 I/O.
4,在 map 以后先进行 combine 处理，减小 I/O
mapreduce 分布式计算 mapreduce 的思想就是分而治之
倒排索引:一种索引方法，用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射，在倒排索引中单词指向了包含单词的文档。
消息队列:大量的数据写入首先存入消息队列进行缓冲，再把消息队列做为数据来源进行数据读取。
数据库读写分离:向一台数据库写入数据，另外的多台数据库从这台数据库中进行读取
user,ip,time,oper(枚举值:1 为上线， 2 位下线 )；
访问日志格式:ip,time,url,假设登陆日志中user上下线信息完整，且同一上下线时间段内使用的ip惟一，要计算访问日志中独立 user 数量最多的前 10个url，请给出MapReduce设计思路，如须要几个MapReduce，及每一个 MapReduce 算法伪代码。
思路:
将 userid ,ip ,url 封装成一个对象，map 类输入数据，按照 userid 为 key 输出，value
为 1（intwritable）,按照 reduce 计算写一个排序类而后按照 value 降序输出前十个
一、 导入数据对需分析的数据进行分片，片的大小默认与 datanode 块大小相同。
二、 每一个数据片由一个 mapper 进行分析，mapper 按照需求将数据拆分为一个个 keyvalue 格式的数据。
三、 每一个 key-value 数据调用一次 map 方法，对数据进行相应的处理后输出。
四、 将输出的数据复制到对应的分区，默认一个键一个区，相同键放在同一个区中。
五、 将输出的数据进行合并为 key-Iterable 格式。
六、 每一个分区有一个 reduce，每一个 reduce 将同一个分区的数据进行合并处理为本身所需的数据格式。
七、 将数据输出至 hdfs
一、 secondary namenode 在 namenode 的 edits log 文件超过规定值（默认 64M）时，或者每隔3600秒（默认值）时会剪切 edits log 文件，复制 namenode 上的 fsimage文件（若没有 fsimage）。
二、 namenode 节点建立一个新的 edits 文件。
三、 将 edits log 文件及 fsimage 文件进行合并为一个新 fsimage。
四、 将 fsimage 文件回传至 namenode 节点。
五、 Namenode 节点使用 seconday namenode 节点回传的 fsimage 文件覆盖本地的fsimage 文件。
六、 当 namenode 节点启动时能够从 seconday namenode 节点复制 fsimage 文件达到快速启动的目的
一、 数据量很小。
二、 繁杂的小文件。
三、 索引是更好的存取机制的时候。
四、 事务处理。
五、 只有一台机器的时候
mr跑的慢可能有不少缘由，如：数据倾斜、map和reduce数设置不合理、reduce等待太久、小文件过多、spill 次数过多、 merge 次数过多等。
一、解决数据倾斜：数据倾斜多是partition不合理，致使部分partition中的数据过多，部分过少。可经过分析数据，自定义分区器解决。
二、合理设置map和reduce数：两个都不能设置太少，也不能设置太多。太少，会致使task等待，延长处理时间；太多，会致使 map、 reduce 任务间竞争资源，形成处理超时等错误。
三、设置map、reduce共存：调整slowstart.completedmaps参数，使map运行到必定程度后，reduce也开始运行，减小 reduce 的等待时间。
四、合并小文件：在执行mr任务前将小文件进行合并，大量的小文件会产生大量的map任务，增大map任务装载次数，而任务的装载比较耗时，从而致使 mr 运行较慢。
五、减小spill次数：经过调整io.sort.mb及sort.spill.percent参数值，增大触发spill的内存上限，减小spill 次数，从而减小磁盘 IO。
六、减小merge次数：经过调整io.sort.factor参数，增大merge的文件数目，减小merge的次数，从而缩短mr处理时间
一、 namenode 单点故障：经过 zookeeper 搭建 HA 高可用，可自动切换 namenode。
二、ResourceManager单点故障：可经过配置YARN的HA，并在配置的namenode上手动启动ResourceManager做为Slave，在 Master 故障后，Slave 会自动切换为Master。
三、reduce阶段内存溢出：是因为单个reduce任务处理的数据量过多，经过增大reducetasks数目、优化partition 规则使数据分布均匀进行解决。
四、datanode内存溢出：是因为建立的线程过多，经过调整linux的maxuserprocesses参数，增大可用线程数进行解决。
五、 集群间时间不一样步致使运行异常：经过配置内网时间同步服务器进行解决
当 jobtracker.restart.recover 参数值设置为 true， jobtracker 重启之时会触发recovery。
在JobTracker重启前，会在history log中记录各个做业的运行状态，这样在JobTracker关闭后，系统中全部数据目录、 临时目录均会被保留，待 JobTracker 重启以后，JobTracker 自动从新提交这些做业，并只对未运行完成的 task 进行从新调度，这样可避免已经计算完的 task 从新计算
一、 不支持文件的并发写入和对文件内容的随机修改。
二、 不支持低延迟、高吞吐的数据访问。
三、 存取大量小文件，会占用 namenode 大量内存，小文件的寻道时间超过读取时间。
四、 hadoop 环境搭建比较复杂。
五、 数据没法实时处理。
六、 mapreduce 的 shuffle 阶段 IO 太多。
七、 编写 mapreduce 难度较高，实现复杂逻辑时，代码量太大