Hadoop是什么
Hadoop是根据Google发表的两篇论文（论述Google文件系统（GFS）和MapReduce框架）开发出的开源框架。
Hadoop是一种开源的适合大数据的分布式存储和处理的平台。作为一种大规模分布式数据处理平台。
Hadoop能做什么
- 搜索引擎：这也正是Doug Cutting设计Hadoop的初衷，为了针对大规模的网页快速建立索引；
- 大数据存储：利用Hadoop的分布式存储能力，例如数据备份、数据仓库等；
- 大数据处理：利用Hadoop的分布式处理能力，例如数据挖掘、数据分析等；
- 科学研究：Hadoop是一种分布式的开源框架，对于分布式系统有很大程度地参考价值。
Hadoop三种模式
Hadoop有三种不同的模式操作，分别为单机模式、伪分布模式和全分布模式。Hadoop官网都详细介绍了三种模式的配置方式。
Hadoop分布式文件系统HDFS
Hadoop分布式文件系统（Hadoop Distributed File System，简称HDFS）是Hadoop的核心模块之一，它主要解决Hadoop的大数据存储问题，其思想来源与Google的文件系统GFS。HDFS的主要特点：
- 保存多个副本，且提供容错机制，副本丢失或宕机自动恢复。默认存3份。
- 运行在廉价的机器上,可以用大规模的PC机搭建出高可用、高性能的服务集群
- 适合大数据的处理。HDFS默认会将文件分割成block，128M为1个block。然后将block按键值对存储在HDFS上，并将键值对的映射存到内存中。Hadoop更适合处理大文件，如果小文件太多，那内存的负担会很重。
HDFS中的四个重要对象：
[Namenode]
- 管理文件系统的命名空间。
- 记录每个文件数据块在各个Datanode上的位置和副本信息。
- 协调客户端对文件的访问。
- 记录命名空间内的改动或者空间本省属性的改动。
- 校验块的完整性，副本数量
- Namenode 使用事务日志记录HDFS元数据的变化。使用映像文件存储文件系统的命名空间，包括文件映射，文件属性等。
Namenode是HDFS里面的管理者，发挥者管理、协调、操控的作用。
[Datanode]
- Datnode会发送心跳和块报告给namenode，如果namenode长时间没收到心跳，会判断此节点丢失，并不会再给这个分配任务
- 负责所在物理节点的存储管理。
- 一次写入，多次读取（不能修改）。
- 文件由数据库组成，一般情况下，数据块的大小为128MB。
- 数据尽量散步到各个节点
Datanode是HDFS的工作者，发挥按着Namenode的命令干活，并且把干活的进展和问题反馈到Namenode的作用。
客户端如何访问HDFS中一个文件呢
- 首先从Namenode获得组成这个文件的数据块位置列表。
- 接下来根据位置列表知道存储数据块的Datanode。
- 最后访问Datanode获取数据。
Namenode并不参与数据实际传输。
[SecondaryNameNode]
- 定期合并namenode的编辑日志到fsimage
- 一旦它有了新的fsimage文件，它将其拷贝回NameNode中。
- NameNode在下次重启时会使用这个新的fsimage文件，从而减少重启的时间
SecondaryNameNode辅助NameNode工作，好比是namenode的秘书，不参与实际的管理工作
HDFS是如何保证其可靠性呢
数据存储系统，数据存储的可靠性至关重要。
- 冗余副本策略，即所有数据都有副本，副本的数目可以在hdfs-site.xml中设置相应的复制因子。
- 机架策略，即HDFS的“机架感知”，一般在本机架存放一个副本，在其它机架再存放别的副本，这样可以防止机架失效时丢失数据，也可以提供带宽利用率。
- 心跳机制，即Namenode周期性从Datanode接受心跳信号和快报告，没有按时发送心跳的Datanode会被标记为宕机，不会再给任何I/O请求，若是Datanode失效造成副本数量下降，并且低于预先设置的阈值，Namenode会检测出这些数据块，并在合适的时机进行重新复制。
- 安全模式，Namenode启动时会先经过一个“安全模式”阶段。
- 校验和，客户端获取数据通过检查校验和，发现数据块是否损坏，从而确定是否要读取副本。
- 回收站，删除文件，会先到回收站/trash，其里面文件可以快速回复。
- 元数据保护，映像文件和事务日志是Namenode的核心数据，可以配置为拥有多个副本。
- 快照，支持存储某个时间点的映像，需要时可以使数据重返这个时间点的状态。
HDFS也是按照Master和Slave的结构。分NameNode、SecondaryNameNode、DataNode这几个角色。
NameNode：是Master节点，是大领导。管理数据块映射；处理客户端的读写请求；配置副本策略；管理HDFS的名称空间；
SecondaryNameNode：是一个小弟，分担大哥namenode的工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给namenode。
DataNode：Slave节点，负责存储client发来的数据块block；执行数据块的读写操作。
fsimage:元数据镜像文件（文件系统的目录树。）
edits：元数据的操作日志（针对文件系统做的修改操作记录）
namenode内存中存储的是=fsimage+edits。
SecondaryNameNode负责定时默认1小时，从namenode上，获取fsimage和edits来进行合并，然后再发送给namenode。减少namenode的工作量。
HDFS文件系统的优点
- 处理超大文件，超大文件通常是指百MB、设置数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。
- 流式的访问数据，HDFS的设计建立在更多地响应”一次写入、多次读写”任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。
- 运行于廉价的商用机器集群上，Hadoop设计对硬件需求比较低，只须运行在低廉的商用硬件集群上，而无需昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性，安全性及高可用性。
HDFS的缺点
- 不适合低延迟数据访问，如果要处理一些用户要求时间比较短的低延迟应用请求，则HDFS不适合。HDFS是为了处理大型数据集分析任务的，主要是为达到高的数据吞吐量而设计的，这就可能要求以高延迟作为代价。
对于那些有低延时要求的应用程序，HBase是一个更好的选择。通过上层数据管理项目来尽可能地弥补这个不足。在性能上有了很大的提升，它的口号就是goes real time。使用缓存或多master设计可以降低client的数据请求压力，以减少延时。还有就是对HDFS系统内部的修改，这就得权衡大吞吐量与低延时了，HDFS不是万能的银弹。 - 无法高效存储大量小文件，因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。
- 不支持多用户写入及任意修改文件，在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。
改进策略：要想让HDFS能处理好小文件：
- 利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。对于这种方法，如果想找回原来的小文件内容，那就必须得知道与归档文件的映射关系。
- 横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。
- 多Master设计，这个作用显而易见了。正在研发中的GFS II也要改为分布式多Master设计，还支持Master的Failover，而且Block大小改为1M，有意要调优处理小文件啊。
Alibaba DFS的设计，也是多Master设计，它把Metadata的映射存储和管理分开了，由多个Metadata存储节点和一个查询Master节点组成。
Hadoop是资源管理系统YARN
ResourceManager
整个集群只有一个，负责集群资源的统一管理和调度
- 处理客户端请求
- 启动/监控ApplicationMaster
- 监控NodeManager
- 资源分配与调度
NodeManager
整个集群有多个，负责单节点资源管理和使用
- 单个节点上的资源管理和任务管理
- 处理来自ResourceManager的命令
- 处理来自ApplicationMaster的命令
ApplicationMaster
每个应用有一个，负责应用程序的管理
- 数据切分
- 为应用程序申请资源，并进一步分配给内部任务
- 任务监控与容错
Container
对任务运行环境的抽象，描述一系列信息
- 任务运行资源（节点、内存、CPU）
- 任务启动命令
- 任务运行环境
Hadoop数据分析框架
MapReduce是Hadoop的大数据分布式处理系统，Hadoop核心之MapReduce是一个软件框架，基于该框架能够容易地编写应用程序，这些应用程序能够运行在由上千个商用机器组成的大集群上，并以一种可靠的，具有容错能力的方式并行地处理上TB级别的海量数据集。
MapReduce主要是用于解决Hadoop大数据处理的。所谓大数据处理，即以对大数据加工、挖掘和优化等各种处理。
MapReduce擅长处理大数据，其主要思想是“分而治之”。Mapper负责“分”，即把复杂的任务分解为若干个“简单的任务”来处理。“简单的任务”包含三层含义：一是数据或计算的规模相对原任务要大大缩小；二是就近计算原则，即任务会分配到存放着所需数据的节点上进行计算；三是这些小任务可以并行计算，彼此间几乎没有依赖关系。Reducer负责对map阶段的结果进行汇总。可以设置多个Reducer（通过在mapred-site.xml配置文件里设置参数mapred.reduce.tasks的值，缺省值为1）。
MapReduce的工作机制如图所示：
MapReduce的整个工作过程如上图所示，它包含如下4个独立的实体：
1. 客户端，用来提交MapReduce作业。
2. jobtracker，用来协调作业的运行。
3. tasktracker，用来处理作业划分后的任务。
4. HDFS，用来在其它实体间共享作业文件。
MapReduce整个工作过程有序地包含如下工作环节：
1. 作业的提交
2. 作业的初始化
3. 任务的分配
4. 任务的执行
5. 进程和状态的更新
6. 作业的完成