概述
Hadoop是一个分布式系统基础架构，由Apache基金会开发，用户可以在不了解分布式底层细节的情况下，开发分布式应用程序。充分利用集群的威力来高速运算或存储。它是一个高可靠、高扩展、分布式计算的开源软件。
HDFS
HDFS是一个有高吞吐能力的分布式文件系统。源自Google的GFS的论文，是GFS的开源克隆版本。
架构
HDFS是一个master/slave的架构。一个master带多个slave。HDFS的集群通常由一个namenode和多个datanode构成。namenode是master的服务，它管理文件系统的namespace和客户端的访问。集群中有多个datanode，通常每个节点有一个，它管理着数据存储到自己运行的节点上。HDFS暴露一个文件系统namespace，允许用户数据存储在文件中。
1个文件将会被拆分成一个或多个block，按照配置的blocksize来拆分。（假设blocksize=128M，一个文件有150M，该文件会被拆分成2个block，一个block128M，一个block 22M）。block被存储在一些列的datanode上（即所有的block不是存放在一个节点上）。
namenode执行文件系统的namespace操作，例如：打开文件、关闭文件、重命名文件、重命名目录。它还决定block和datanode的映射（即block存在哪个datanode上）。
即：1.负责客户端请求的响应。2.负责元数据（文件名称、副本系数、block存储的datanode地址）的管理。
datanode复制处理来自系统客户端的读写请求。在namenode的命令下，datanode也会创建、删除、备份block。
即：1.存储用户的文件对应的数据块（block）。2.定期向namenode发送心跳信息，汇报本身机器所有的block信息和健康状况。
namenode和datanode被设计成能够运行在廉价的机器上。这些机器通常是Linux操作系统。HDFS的开发是用的Java语言。只要支持Java的机器就能运行namenode和datanode软件。典型的部署是：一台机器只运行namenode，集群中其他的机器每台都运行一个datanode。虽然这个架构并不排斥运行多个datanode在同一台机器上，但是实际中我们不会这样做。
HDFS的副本机制
文件系统的namespace
HDFS支持传统的层级目录。一个用户或应用程序能够创建目录并且把文件存储到指定的目录中。文件系统的namespace层级目录跟大多数文件系统很像，支持创建文件、删除文件、移动文件、重命名文件。
namenode维护的是文件系统的命名空间，对文件系统的命名空间做任何修改都会被namenode记录下来。应用程序能够指定每个文件的副本系数。 replication factor就是文件副本数量。这些信息都会存放在namenode里面。
数据副本
HDFS能高可靠的存储集群中的、大量的、跨节点的数据。1个文件会被作为一系列有序block来存储。为了容错性好，文件的每个block都是已多副本的方式存储的。block大小和副本数量可以针对每个文件来配置。
一个文件中的所有Block，除了最后一个Block外，其他的Block大小都相等。
应用程序能够指定一个文件的副本系数，副本系数能在创建文件的时候指定，之后也能进行修改。
HDFS中的文件是write-once只能写一次（除非追加或者truncate），不支持多并发写，同一时间只能有一个writer。
namenode会管理副本的复制。namenode会周期性的从集群中每个datanode接收心跳和block汇报。block汇报包括datanode中所有的block。
HDFS shell常用命令
bin/hadoop fs -ls / 查看根目录
bin/hadoop fs -ls -R / 递归查看根目录
bin/hadoop fs -mkdir /hadoop 创建hadoop文件夹
bin/hadoop fs -mkdir -p /mr/input 创建/mr/input文件夹，在还没有/mr的时候，用-p可以一起创建了
bin/hadoop fs -put filename /dir 把本地文件上传到HDFS上。
copyFromLocal和put类似
bin/hadoop fs -text /dir/filename 查看文件的内容
bin/hadoop fs -cat /dir/filename 查看文件的内容
bin/hadoop fs -get /dir/filename localname 把HDFS上/dir/filename文件下载到本地，localname是在本地的新名字
bin/hadoop fs -rm /dir/filename 删除文件
bin/hadoop fs -rmr /mr 递归删除该目录
MapReduce
MapReduce基于YARN的，并行计算。一个分布式计算框架。它源自Google的MapReduce论文。Hadoop MapReduce是Google MapReduce的开源克隆版。它有良好的扩展性、高容错性（HDFS中数据有多副本，计算的时候就近取副本进行处理，当前计算的任务挂掉，会自己把作业转义到其他节点运行）。
Shuffling原理
定义
shuffle：针对多个map任务的输出按照不同的分区（Partition）通过网络复制到不同的reduce任务节点上的过程。相应上图中红色框所圈的内容。
由图可见Shuffle过程横跨了map，reduce两端，所以为了方便讲解，我们在下面分为两个部分进行讲解：map端和reduce端
map端的shuffle：
我们按照图中的1234步逐步进行说明：
①在map端首先接触的是InputSplit，在InputSplit中含有DataNode中的数据，每一个InputSplit都会分配一个Mapper任务。
②当key/value被写入缓冲区之前，都会被序列化为字节流。mapreduce提供Partitioner接口，它的作用就是根据key或value及reduce的数量来决定当前的这对输出数据最终应该交由哪个reduce task处理（分区）。默认对key hash后再以reduce task数量取模。默认的取模方式只是为了平均reduce的处理能力，如果用户自己对Partitioner有需求，可以订制并设置到job上。
注意：虽然Partitioner接口会计算出一个值来决定某个输出会交给哪个reduce去处理，但是在缓冲区中并不会实现物理上的分区，而是将结果加载key-value后面。物理上的分区实在磁盘上进行的。
每个map有一个环形内存缓冲区，用于存储任务的输出。默认大小100MB（io.sort.mb属性）。
③一旦达到阀值80%(io.sort.spil l.percent)，一个后台线程就把内容写到(spill：溢写)Linux本地磁盘中的指定目录（mapred.local.dir）下的新建的一个溢出写文件。在这一步会执行两个操作排序和Combiner（前提是设置了Combiner）。
这里大家可能会出现疑问：是将哪部分溢写到磁盘上那？答案是，溢写线程启动时，会锁定这80M的内存，执行溢写过程。而剩余的那20M缓冲区会继续接收map的输出，直到缓冲区写满，Map 才会被阻塞直到spill 完成。spill操作和接收map输出的操作是两个独立的线程，故互不影响。
spill 线程在把缓冲区的数据写到磁盘前，会对它进行一个二次快速排序，首先根据数据所属的partition （分区）排序，然后每个partition 中再按Key 排序。输出包括一个索引文件和数据文件。如果设定了Combiner，将在排序输出的基础上运行。Combiner 就是一个简单Reducer操作，它在执行Map 任务的节点本身运行，先对Map 的输出做一次简单Reduce，使得Map 的输出更紧凑，更少的数据会被写入磁盘和传送到Reducer。spill 文件保存在由mapred.local.dir指定的目录中，map 任务结束后删除。
每次溢写会在磁盘上生成一个溢写文件，如果map的输出结果很大，有多次这样的溢写发生，磁盘上相应的就会有多个溢写文件存在。而如果map的输出很小以至于最终也没有到达阀值，那最后会将其缓冲区的内容写入磁盘。
④因为最终的文件只有一个，所以需要将这些溢写文件归并到一起，
这个过程就叫做Merge。因为merge是将多个溢写文件合并到一个文件，所以可能也有相同的key存在，在这个过程中如果client设置过Combiner，也会使用Combiner来合并相同的key。
从这里我们可以得出，溢写操作是写到了磁盘上，并不一定就是最终的结果，因为最终结果是要只有一个文件，除非其map的输出很小以至于没有没有发生过溢写（也就是说磁盘上只有一个文件）。
到这里，map端的shuffle就全部完成了。
reduce端的shuffle：
map完成后，会通过心跳将信息传给tasktracker，其进而通知jobtracker，reduce task不断地通过RPC从JobTracker那里获取map task是否完成的信息,当得知某个TaskTracker上的map task执行完成，Reduce端的shuffle就开始工作了。
注意：这里是reduce端的shuffle开始工作，而不是reduce操作开始执行，在shuffle阶段reduce不会运行。
同样我们按照图中的标号，分为三个阶段进行讲解。
**①**Copy阶段：reduce端默认有5个数据复制线程从map端复制数据，其通过Http方式得到Map对应分区的输出文件。reduce端并不是等map端执行完后将结果传来，而是直接去map端去Copy输出文件。
**②**Merge阶段：reduce端的shuffle也有一个环形缓冲区，它的大小要比map端的灵活（由JVM的heapsize设置），由Copy阶段获得的数据，会存放的这个缓冲区中，同样，当到达阀值时会发生溢写操作，这个过程中如果设置了Combiner也是会执行的，这个过程会一直执行直到所有的map输出都被复制过来，如果形成了多个磁盘文件还会进行合并，最后一次合并的结果作为reduce的输入而不是写入到磁盘中。
③当Reducer的输入文件确定后，整个Shuffle操作才最终结束。之后就是Reducer的执行了，最后Reducer会把结果存到HDFS上。
YARN
YARN是集群资源调度管理。在hadoop2.X开始才有。
YARN解决了hadoop1.X中JobTracker单点故障的问题。
YARN提高了资源利用率，降低了运维成本。不同计算框架，数据可以放在同一集群上。不同框架共享集群。
架构
1个ResourceManager主节点，多个NodeManager从节点。
ResourceManager通常情况下在集群中活跃（Active）的只有一个，它虽然可以做主备，另一个是standby，只有一个挂了才会起另一个。
1.处理客户端提交的请求（启动/停止作业）。
2.作业提交到ResourceManager后，ResourceManager会找一个NodeManager，在Container中启动一个Application Master，同时会监控这个Application Master，如果这个Application Master挂了会通知ResourceManager在另外一个节点再起Application Master。一个作业对应一个Application Master。
3.通过心跳机制监控NodeManager状态。
4.系统的资源分配和调度。
NodeManager负责当前节点的资源管理和使用，task的运行情况
1.通过心跳机制定期高速ResourceManager本节点的资源使用情况，以及节点上Container中任务的运行情况。
2.接收ResourceManager对Container的启动和停止。
3.管理本节点的资源。
Application Master一个作业对应一个Application Master
1.它负责应用程序的管理（包括数据的拆分、为应用程序向ResourceManager申请资源并分配给内部任务）。
2.一个Application Master可能会由多个Container在运行。
3.与ResourceManager通行，启停task，task是运行在Container中的。
4.task的监控和容错。
Container是对任务运行情况的描述，包括（CPU、Memory、环境变量）。所有的task都是跑在Container上的。
YARN工作流程
1.客户端提交作业到YARN。
2.ResourceManager为作业分配第一个Container（Application Master）。
3.NodeManager拿到Container把Application Master运行上去。ResourceManager会与对应的NodeManager通信，要求NodeManager在这个上Container启动应用程序的Application Master。
4.Application Master运行起来后注册到ResourceManager上（这样用户就可以通过RM查询作业的运行情况），Application Master会给各个任务申请资源并监控运行情况。ResourceManager分配资源给Application Master。
5.Application Master领取到资源后会和相应的NodeManager通信，要求NodeManager启动任务。
6.NodeManager启动Container来跑task。
Hadoop生态系统：
