Hadoop是目前应用最为广泛的分布式大数据处理框架，其具备可靠、高效、可伸缩等特点。
Hadoop的核心组件是HDFS、MapReduce。随着处理任务不同，各种组件相继出现，丰富Hadoop生态圈，
1、HDFS（分布式文件系统）
HDFS是整个hadoop体系的基础，负责数据的存储与管理。HDFS有着高容错性（fault-tolerant）的特点，并且设计用来部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。
2、MapReduce（分布式计算框架）
MapReduce是一种基于磁盘的分布式并行批处理计算模型，用于处理大数据量的计算。其中Map对应数据集上的独立元素进行指定的操作，生成键-值对形式中间，Reduce则对中间结果中相同的键的所有值进行规约，以得到最终结果。
Jobtracker：master节点，只有一个，管理所有作业，任务/作业的监控，错误处理等，将任务分解成一系列任务，并分派给Tasktracker。
Tacktracker：slave节点，运行 Map task和Reduce task；并与Jobtracker交互，汇报任务状态。
Map task：解析每条数据记录，传递给用户编写的map()函数并执行，将输出结果写入到本地磁盘（如果为map—only作业，则直接写入HDFS）。
Reduce task：从Map 它深刻地执行结果中，远程读取输入数据，对数据进行排序，将数据分组传递给用户编写的Reduce()函数执行。
3、Spark（分布式计算框架）
Spark是一种基于内存的分布式并行计算框架，不同于MapReduce的是——Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。
8、Hive/Impala（基于Hadoop的数据仓库）
Hive定义了一种类似SQL的查询语言(HQL),将SQL转化为MapReduce任务在Hadoop上执行。通常用于离线分析。
hadoop1.x和hadoop2.x的主要区别在于：
1、hadoop1.x没有提供架构中主节点namenode及jobtrack的高可用及负载均衡机制。而在hadoop2.x中有。
2、第二个区别就体现在mapreduce的架构设计上，hadoop1.x中mapreduce兼具计算和资源调度两个作用，
而在hadoop2.x中则将mapreduce中的资源调度功能剥离形成一个独立的框架叫做yarn。使得hadoop更
加地灵活，因为剥离后的yarn不仅可以运行在hadoop平台，也可以运行在其他的平台，如spark。
Hadoop3.x新特性
1、Java最低版本要求从Java7更改成Java8。
2、HDFS支持纠删码，将原本3倍的存储消耗降低到1.4倍。
####在原始数据中加入新的校验数据，使得各个部分的数据产生关联性。
####在一定范围的数据出错情况下，通过纠删码技术都可以进行恢复。
####既耗网络又耗CPU,适用于冷数据集群。
3、Hadoop的Shell脚本被重写。
4、MapReduce任务级本地优化。
####MapReduce添加了Map输出collector的本地实现。
####对于shuffle密集型的作业来说，这将会有30%以上的性能提升。
5、支持多于2个的NameNode。
6、多个服务的默认端口被改变。
7、提供了单节个磁盘存储不均的情况的解决方案。
8、重写守护进程以及任务的堆内存管理。
1）NameNode它是hadoop中的主服务器，管理文件系统名称空间和对集群中存储的文件的访问，保存有metadate。
2）SecondaryNameNode它不是namenode的冗余守护进程，而是提供周期检查点和清理任务。帮助NN合并editslog，减少NN启动时间。
3）DataNode它负责管理连接到节点的存储（一个集群中可以有多个节点）。每个存储数据的节点运行一个datanode守护进程。
4）ResourceManager（JobTracker）JobTracker负责调度DataNode上的工作。每个DataNode有一个TaskTracker，它们执行实际工作。
5）NodeManager（TaskTracker）执行任务
6）DFSZKFailoverController高可用时它负责监控NN的状态，并及时的把状态信息写入ZK。它通过一个独立线程周期性的调用NN上的一个特定接口来获取NN的健康状态。FC也有选择谁作为Active NN的权利，因为最多只有两个节点，目前选择策略还比较简单（先到先得，轮换）。
7）JournalNode 高可用情况下存放namenode的editlog文件.
磁盘IO
core-site.xml
hdfs-site.xml
mapred-site.xml
yarn-site.xml
hdfs将文件系统的元数据信息存放在fsimage和一系列的edits文件中。在启动HDFS集群时，系统会先加载fsimage，然后逐个执行所有Edits文件中的每一条操作，来获取完整的文件系统元数据。
HDFS的存储元数据是由fsimage和edits文件组成。checkpoint的过程，就是合并fsimage和Edits文件，然后生成最新的fsimage的过程。
Edits文件： 在配置了HA的hadoop2.x版本中，active namenode会及时把HDFS的修改信息（创建，修改，删除等）写入到本地目录，和journalnode上的Edits文件，每一个操作以一条数据的形式存放。Edits文件默认每2分钟产生一个。正在写入的Edits文件以edits_inprogress_*格式存在。
fsimage文件： fsimage里保存的是HDFS文件系统的元数据信息。每次checkpoint的时候生成一个新的fsimage文件，fsimage文件同步保存在active namenode上和standby namenode上。是在standby namenode上生成并上传到active namenode上的。
原文链接：https://blog.csdn.net/amber_amber/article/details/47003589
在HDFS中存储数据是以块（block）的形式存放在DataNode中的，块（block）的大小可以通过设置dfs.blocksize来实现；
在Hadoop2.x的版本中，文件块的默认大小是128M，老版本中默认是64M；
寻址时间：HDFS中找到目标文件块（block）所需要的时间。
如果块设置过大，
一方面，从磁盘传输数据的时间会明显大于寻址时间，导致程序在处理这块数据时，变得非常慢；
另一方面，mapreduce中的map任务通常一次只处理一个块中的数据，如果块过大运行速度也会很慢。
如果块设置过小，
一方面存放大量小文件会占用NameNode中大量内存来存储元数据，而NameNode的内存是有限的，不可取；
另一方面文件块过小，寻址时间增大，导致程序一直在找block的开始位置。
因而，块适当设置大一些，减少寻址时间，那么传输一个由多个块组成的文件的时间主要取决于磁盘的传输速率。
HDFS中块（block）的大小为什么设置为128M？
HDFS中平均寻址时间大概为10ms；
经过前人的大量测试发现，寻址时间为传输时间的1%时，为最佳状态；
所以最佳传输时间为10ms/0.01=1000ms=1s
目前磁盘的传输速率普遍为100MB/s；
计算出最佳block大小：100MB/s x 1s = 100MB
所以我们设定block大小为128MB。
因为HDFS的的一个设计目标就是能够快速读取。而对于磁盘来说，读取一个数据块涉及到三种时间开销，寻道时间、旋转时间和传输时间。传输时间是磁盘本身的特性，不可能通过人工手段来改变，但是对于寻道时间和旋转时间，则可以通过增大一次读取的数据量来减少寻道和旋转的次数。这样的话，就可以将读取数据的速率设计为接近真实的磁盘传输速率。
原文链接：https://blog.csdn.net/s5660gt/article/details/83655584
hadoop支持的一般压缩算法如下：
LZO
Gzip
Bzip2
LZ4
Snappy
LZO：
算法是线程安全的
算法是数据无损的
LZO是便携的
Lzop是使用LZO作为压缩服务的文件压缩器，它是最快的压缩和加压缩器。
GUN zip，基于DEFLATE算法，LZ77和Huffman编码的结合。它比LZO压缩性能好但是慢。
总结
gzip是普通的压缩器，bzip压缩性能好于gzip但速度慢，LZO由很多小块组成。
LZO和Snappy的压缩速度好但压缩效率低，解压是gzip的两倍。Snappy解压缩好于LZO
https://blog.csdn.net/victory0508/article/details/47903715
1，当client想yarn提交了作业后，就意味着想ResourceManager申请一个ApplicationMaster。这个时候RM(这里我们将ResourceManager简称为RM，同理NodeManager为NM)将分配一个ApplicationMaster给这个作业，同时向相应的NM进行rpc通信要求其启动一个container，在这个container里面启动所分配的ApplicationMaster。
2，随后这个ApplicationMaster将向RM中的ApplicationManager反向注册，这样用户就可以通过web界面直接监控和查看作业的具体情况。然后ApplicationMaster将想ResourceScheduer申请和领取资源(资源列表就是一系列NM)。
3，当获取到了NM列表后ApplicationMaster将与相关的NM进行rpc通信，要求他们启动相关的container，这些container里面就是运行作业的task任务的。
4，各个container里面的task通过rpc通信定期想ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个task的运行状态，从而在task失败的时候可以重启task，用户也可以通过web界面来实时地查看应用程序的情况。
5，当作业完成后，ApplicationMaster将想ApplicationManager注销并关闭。
总结起来就是两个阶段：第一个阶段是提交作业到RM上面并开启一个ApplicationMaster。第二阶段，ApplicationMaster申请资源并将task分配到NM上运行同时监控他们直到作业完成并被注销关闭。
原文链接：https://blog.csdn.net/weixin_39702831/article/details/83090080
每一个map都可能会产生大量的本地输出，Combiner的作用就是对map端的输出先做一次合并，以减少在map和reduce节点之间的数据传输量，以提高网络IO性能，是MapReduce的一种优化手段之一，其具体的作用如下所述。
Combiner最基本是实现本地key的聚合，对map输出的key排序，value进行迭代。
mapTask的并行机制
mapTask在运行的时候，开启多个map由谁来决定？
默认情况：mapTask 的数量和读取 HDFS 中的数据块 block 的数量相等
block块：HDFS 中文件各个小数据块（默认 128m ）（物理划分）
FileSplit： 在MapReduce 读取每一个块称为 fileSplit（文件切片）（逻辑划分）
block 的数量 和 文件分片的数量一样，大小也是一样。
Mapreduce 中 map 阶段的运行机制
Mapreduce 中 reduce 阶段的运行机制
一个程序中Map和Reduce的数量是有split和partition的数据决定的。
Combine优化
整个过程中可以提前对聚合好的value值进行计算，这个过程就叫Combine。
在数据排序后，溢写到磁盘前，相同key值的value是紧挨在一起的，可以进行聚合运算，运行一次combiner。
原文链接：
https://blog.csdn.net/woshilovetg/article/details/111414081
https://blog.csdn.net/qq_31975963/article/details/84995460
原文链接：https://blog.csdn.net/qq_31975963/article/details/84995460