Hadoop架构原理、三大组件详解（笔记）

Hadoop是一个由Apache基金会所开发的大数据分布式系统基础架构，用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的为例进行高速运算和存储。
Hadoop框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，而MapReduce则为海量的数据提供了运算。
Hadoop大数据处理的意义：
Hadoop得以在大数据处理应用中广泛应用得益于其自身在数据提取、变形和加载(ETL)方面上的天然优势。Hadoop的分布式架构，将大数据处理引擎尽可能的靠近存储，对例如像ETL这样的批处理操作相对合适，因为类似这样操作的批处理结果可以直接走向存储。Hadoop的MapReduce功能实现了将单个任务打碎，并将碎片任务(Map)发送到多个节点上，之后再以单个数据集的形式加载(Reduce)到数据仓库里。
本人也是大白一枚，参照网上的一些博客然后做一些“增删改”，用比较通俗的语言写了这篇，原本是留着自己无事时看看加深记忆之用，想了想还是拿出来让大家也看下，， 有不对的地方请指出。我加以改正。

Hadoop的三大组件：

HDFS：分布式文件系统
MapReduce：分布式计算系统
YARN：资源调度系统

1、Hadoop的核心-HDFS分布式文件系统

1.1HDFS在设计之初就非常明确其应用场景，而以下场景不适合使用HDFS来存储数据，

低延时的数据访问
对延时要求在毫秒级别的应用不适合采用HDFS，HDFS是专门为高吞吐数据传输设计的，因此可能牺牲延时。相比较而言Hbase更适合低延时的数据访问。
大量小文件
文件的元数据保存在NameNode的内存中，整个文件系统的文件数量会受限于NameNode的内存大小。
多方读写，需要任意的文件修改
HDFS采用追加（append-only）的方式写入数据，不支持文件任意offset的修改，不支持多个写入器（writer）。

1.2HDFS设计目标

存储海量的数据文件：
这里的大指的是几百MB、GB、或者TB级别，实际应用中已经有很多集群存储的数据量达到PB级别。
采用流式的数据访问方式：
HDFS基于：最有效的数据处理模式是一次写入，多次读取数据集，经常从数据源生成或者拷贝一次，然后再在其上做很多分析工作，
分析工作经常读取器中的大部分数据，即使不是全部。因此读取整个数据集所需要的时间比读取第一条记录的延时更重要。
运行于商业硬件上：
Hadoop不需要很贵很可靠的机器，可以运行在普通的商用机器。在集群中（尤其是比较大的集群），节点失败率是比较高的，HDFS的目标是确保集群在节点失败的时候不会让用户感觉到明显的中断。

1.3 HDFS核心概念

1.3.1 Blocks

物理磁盘中有块的概念，磁盘的物理Block是磁盘操作最小的单元，读写操作均以Block为最小单元。一般为512Byte。文件系统在物理Block上抽象了另一层概念，文件系统Block通常是几KB。
而为了最小化查找时间（seek），控制定位文件与传输文件所用的时间比例，假设定位文件时间为10ms，磁盘传输速度为100M/s，如果要将定位文件与传输文件时间比控制在1%，则Block大小需要约100M，所以基于此情况，HDFS的Block默认为128M。HDFS文件被拆分为Block-sized的chunk，chunk作为独立单元存储，比Block小的文件也不会占用整个Block的大小，只会占据实际大小。比如一个文件大小129M，虽然分成128M和1M，但是1M就算占据了一个Block，但是实际占用的磁盘空间是1M而不是128M。

1.3.2 NameNode和DataNode

整个HDFS集群由NameNode和DataNode构成master-worker模式（主从）。NameNode负责构建命名空间，管理文件的元数据等，DataNode则负责实际存储数据，负责数据的读写工作。
NameNode
NameNode有一个很核心的功能：管理整个HDFS集群的元数据，比如说文件目录树、权限的设置、副本数的设置，等等。
下面用对文件目录树的维护举例说明：比如客户端要上传一个1TB的大文件到HDFS集群中。

首先客户端会先向NameNode发起请求，犹如此图，NameNode会在自己所在节点的内存的文件目录树中，在指定的目录下搞一个新的文件对象，这个文件目录树不就是HDFS核心的元数据么，但是这个目录树是在NameNode内存中的！万一NameNode主节点因不可抗因素而挂掉，元数据丢失了咋整？
对此呢，HDFS自有优雅的解决方案。
每次内存里更改完了文件目录树以后，写一个edits log，将元数据修改的操作日志写到磁盘文件里，**并不修改磁盘文件内容，只是顺序追加。**犹如此图。。。

但是还有一个问题，随着文件越来越多，更改的日志也会越来越多，那在集群重启时读取大量的edits log恢复元数据岂不是很慢？
针对这种情况，HDFS也是自有妙计。
HDFS引入一个新的磁盘文件叫fsimage，然后再引入一个JournalNodes集群，以及一个Standby NameNode(备节点)。
每次Active NameNode主节点修改一次元数据都会生成一条edits log，除了写入