Hadoop基本理论
1、什么是Hadoop？
Hadoop是一个分布式系统。主要包含两个核心组件HDFS和MR。
HDFS： 分布式存储系统，解决海量数据的存储问题。
MR：分布式计算框架，解决海量数据的处理问题。
在基础的HDFS和MR基础上，Hadoop生态圈又加入了其它的组件：
Habse 非关系型的分布式数据库，
Hive基于HDFS的数据仓库，
Pig 一个基于MR的大数据分析平台，提供PigLatin类似SQL的查询语言。
Storm 基于HDFS的流数据处理框架
Spark 一个架构在HDFS之上的基于内存的分布式计算框架。
2.HDFS的特点
2.1、HDFS的设计初衷是为了解决海量数据的存储问题，HDFS具有以下特性：
1、流式读写，一次写入，多次读取，只允许追加，不允许修改。
2、存储大数据集
3、支持低廉的硬件设备
4、简单的文件模型
5、跨平台
缺点：
1、不是低延迟访问
2、无法高效存储大量小文件
3、不支持多用户写入及任意修改文件。
2.2、HDFS的组成：
HDFS采用Master/Slave架构，一个主节点NameNode，多个从节点DataNode，一个SecondaryNameNode节点。
NameNode：负责存储元数据，系统文件树，管理读写。
DataNode：负责存储具体的数据块。
NameNode磁盘上保存着FsImage文件和EditLog日志文件
FsImage：用于维护文件树，所有文件及文件夹的元数据。
EditLog：记录所有对文件的创建、删除、重命名等操作。
当系统启动时NameNode会将FsImage加载到内存，并执行EditLog日志文件记录的操作，同步内存和实际数据。DataNode启动 后，会向NameNode发送心跳，在NameNode中形成数据块-DataNode映射。
为什么增加EditLog文件，而不直接在FsImage文件上操作？
FsImage文件一般很大，如果直接在FsImage上操作会很慢。而对EditLog文件只需要写记录操作，这个过程很快，只需要记录一段时间的操作。
SecondaryNameNode:第二名称节点
虽然使用EditLog可以避免对FsImage文件的直接操作，但是可能存在系统重启的问题，内存中的最新数据丢失，需要从磁盘加载FsImage文件并执行EditLog的操作，如果EditLog文件很大，那么这个重启过程将会非常缓慢。因此SecodaryNameNode的工作就是将隔一段时间，将NameNode上的FsImage文件和EditLog文件取过来，NameNode新建一个EditLog文件记录操作，在SecondaryNameNode上进行合并操作形成一个新的FsImage文件，用这个新文件去替代NameNode上的对应文件。
注意：SecondaryNameNode的作用不是备份，只是用于合并NameNode上的数据，但是因为存储一个FsImage文件，所以在NameNode节点数据完全丢失的情况下，也能做部分数据的恢复，不过会丢失部分数据信息，因为这个FsImage文件不是最新的。
HDFS的设计缺陷：
1、命名空间的限制，NameNode存储元数据，这些元数据保存在内存中，内存的大小限制了文件数的数量。
注：这也是为什么不适合大量小文件的存储，小文件元数据占据大量内存空间。
2、性能瓶颈，只有一个NameNode节点，所有的DataNode和客户端需要和NameNode通信，吞吐量受限。
3、隔离问题，所有作业在同一个命名空间下
4、集群的可用性 NameNode挂机，整个系统不可用。
解决：在2.0的版本中加入了，Hadoop HA，为NameNode增加一个热备；Hadoop Fedration,将系统分区，每个分区使用一个NameNode，解决了扩展性和隔离问题。
HDFS将数据分块，一个块大小为64M或者128M，分块的好处是很好的解决大数据集的存储，可以将数据集划分为小块，放到不同机器上进行存储。这种分片的方式，方便了系统设计，对于存储来说，只负责块的存储，不需要其它逻辑。这里的块远大于磁盘文件系统的块大小，因为这是为了降低寻址时间在整个文件读取过程的时间比例，也就是说，文件块越大，寻址时间比例越小。但是并不是越大越好，因为在MR阶段，Map任务的分片大小会采用块大小，Map任务的数量就是数据集的分块数量，如果块设定的太大，Map数量太少，会降低并行度。
HDFS的块采取冗余存储，即一个数据块会存储多份。这有利于数据的传输，容易检查错误并做错误恢复处理，保证数据的可靠性。
一般采用的存储策略为：
第一个副本保存在上传文件的数据节点，如果是集群外提交，则选择一个磁盘不太满，CPU不太忙的节点。
第二个副本保存在和第一个副本相同机架不同节点上。
第三个副本保存在和第二个副本不同机架上的节点。
后续随机。
读取特点：
当客户端读取数据时会从NameNode上得到一个数据块的多个访问点，通过系统提供的API，计算与各个访问点的距离，选择最近读取。
2.3、写数据
2.4、读数据
读流程和上述过程相似
3、MapReduce
MR分为四个部分：Client,JobTracker,TaskTracker,Task
Clinet:用户编写的MapReduce通过Client提交给JobTracker，并且可以通过Client提供的一些接口，查询作业的状态。
JobTracker：负责作业调度和资源监控。JobTracker监控所有的TaskTracker的健康状况，一旦发现失败，则将相应的Task转移到其它节点。JobeTracker会跟踪任务的执行进度，资源的使用量信息，并将这些信息报告给TaskSchedule调度器，在出现资源空闲时，会选择合适的任务使用这些资源。
TaskTracker：TaskTracker会周期性的通过心态的方式向JobTracker汇报该节点上的资源使用情况和任务的进度，执行JobTracker的命令。TaskTracker会使用Slot将资源划分一个一个槽。分布Map slot和Reduce slot，分别供Map和Reduce任务使用，不同的任务只能使用对应的槽。因此会存在资源浪费的情况，Map槽完全占用，Reduce槽空闲。
Task:分为Map Task 和Reduce Task 两种，由TaskTracker启动。
如上图所示，InputFormat会将需要操作的数据进行分片，分片大小一般是数据块大小，分片的数量对应Map任务数。使用RecordReader读取数据块，生成一系列<key,value>对，具体的读入格式可以设置，这个就是Map任务的输入数据。
MapReduce过程：
整个流程会经历：split 、Map处理、Shuffle（Partition、Sort、Combine）、Merger、Reduce处理
一般是编写Map、Reduce函数，但是Shuflle过程也是可以控制的。
Map函数的输出不是直接写到磁盘，而是先写到缓冲区，由缓冲区溢写到磁盘，在溢写的过程，会对数据进行分区，排序，合并，过程。一般通过Hash函数，对数据进行分区，不同的区由不同的Reduce任务处理。对分区后的数据会进行排序，如果提供了合并操作，在合并操作不影响最终结果的情况下可以进行合并操作，这样可以减少网络间的数据量传输。最后，多次溢写会生成多个文件，需要对这些文件进行归并成一个大文件，这个文件存储在本地磁盘，不会存储到HDFS上。一旦Map任务完成，JobTracker会通知Redce任务取走对应的数据，在Reduce阶段，也会进一个将来自不同的Map任务的数据，进行合并和归并，按照Key进行分组，形成一系列的<key,iterator<valkue>>的输入数据。经过Reduce函数处理，将结果写到HDFS上。
并不是所有的作业都可以使用Combiner，需要满足加入这个过程的结果和不加入的结果一致时才可以使用。
在2.0的版本中，使用YARN来负责管理资源，MR只负责数据处理。
YARN包含ResourceManager、ApplicationMaster，NodeManger。
ResourceManager处理客户端的请求，启动、监控ApplicationManager，监控NodeManager，资源分配和调度。
ApplicationMaster：为应用程序申请资源，并分配给内部任务，负责任务调度、监控和容错。
NodeManger：单个结点的资源管理，处理来自上述的命令。
客户端向ResourceManager发起一个作业请求，ResourceManager会分配一个资源容器，负责运行ApplicationMaster，ApplicationMaster以轮循的方式向ResourceManager申请资源，在特定的NodeManger上运行作业任务。YARN的资源分配是使用容器，这有别于MR的任务槽。