笔记：分布式大数据技术原理（一）Hadoop 框架

Apache Hadoop 软件库是一个框架，它允许使用简单的编程模型，实现跨计算机集群的大型数据集的分布式处理。它最初的设计目的是为了检测和处理应用程序层的故障，从单个机器扩展到数千台机器（这些机器可以是廉价的），每个机器提供本地计算和存储，而不是依靠硬件提供高可靠性。 Hadoop 中有3个核心组件：

• 分布式文件系统：HDFS —— 实现将文件分布式存储在很多的服务器上
• 分布式运算编程框架：MapReduce —— 实现在很多机器上分布式并行运算
• 分布式资源调度平台：YARN —— 帮用户调度大量的 MapReduce 程序，并合理分配运算资源

整个源头是 Google 发的三篇论文， Hadoop 的 MapReduce/HDFS/HBase 分别对应 Google 的 MapReduce/GFS/Big Table

HDFS

HDFS，是 Hadoop Distributed File System 的简称，是 Hadoop 抽象文件系统的一种实现。Hadoop 抽象文件系统可以与本地系统、Amazon S3 等集成，甚至可以通过 Web 协议（webhsfs）来操作。

传统的文件系统是单机的，不能横跨不同的机器；HDFS 的文件分布在集群机器上，例如客户端写入读取文件的直接操作都是分布在集群各个机器上的，没有单点性能压力，因此 HDFS 的设计本质上是为了大量的数据能横跨成百上千台机器，提供高吞吐量的服务，同时提供副本进行容错及高可靠性保证（计算机节点很容易出现硬件故障，而不管是 Google 公司的计算平台还是 Hadoop 计算平台都将硬件故障作为常态，通过软件设计来保证系统的可靠性）。

使用 HDFS 时，用户看到的是一个文件系统而不是很多文件系统，比如说要获取 /hdfs/tmp/file1 的数据，引用的是一个文件路径，但是实际的数据存放在很多不同的机器上，作为用户，不需要知道这些，就好比在单机上我们不关心文件分散在什么磁道什么扇区一样，HDFS 为用户管理这些数据。

设计特点

• 大数据文件：非常适合上 T 级别的大文件或者一堆大数据文件的存储，如果文件只有几个 G 甚至更小就不太适用；假设 HDFS 中块的大小为 64MB，备份数量为3，—般情况下，一条元数据记录占用 200B 的内存，那么对于 1GB 的大文件，将占用 1GB/64MB x 3 个文件块；对于1024个 1MB 的小文件，则占用 1024 x 3 个文件块，可以看到，存储同等大小的文件，单个文件越小，所需的元数据信息越大，占用的内存越大，因此 HDFS 适合存储超大文件
• 文件分块存储：HDFS 会将一个完整的大文件平均分块存储到不同计算器上，它的意义在于读取文件时可以同时从多个主机取不同区块的文件，多主机读取比单主机读取效率要高得多
• 流式数据访问：一次写入多次读写，这种模式跟传统文件不同，它不支持动态改变文件内容，而是要求让文件一次写入就不做变化，要变化也只能在文件末添加内容；通过流式的数据访问保证高吞吐量
• 数据靠拢：对数据进行计算时，采用将计算向数据靠拢的方式，即选择最近的数据进行计算，减少数据在网络中的传输延迟
• 廉价硬件：HDFS 可以应用在普通 PC 机上，这种机制能够让一些公司用几十台廉价的计算机就可以撑起一个大数据集群
• 高可靠性（硬件故障处理）：HDFS 认为所有计算机都可能会出问题，为了防止某个主机失效读取不到该主机的块文件，它将同一个文件块副本分配到其它某几个主机上，如果其中一台主机失效，可以迅速找另一块副本取文件
• 高可用性：Hadoop 2.0 之前，NameNode 只有一个，存在单点问题（单点故障导致整个集群不可用，虽然 Hadoop1.0 有 SecondaryNameNode，CheckPointNode，BackupNode 这些来尽量满足 HA，但是单点问题依然存在），在 Hadoop 2.0 引入了新的 HA 机制，集群中会同时运行两个 Namenode，一个作为活动的 Namenode（Active），一个作为备份的 Namenode（Standby）；备份的 Namenode 的命名空间与活动的 Namenode 是实时同步的，所以当活动的 Namenode 发生故障而停止服务时，备份 Namenode 可以立即切换为活动状态，而不影响 HDFS 集群服务
• 最终一致性：HDFS 是一个松散的一致性检查的模型，它主要是为了追加（append）操作而不是覆盖重写（overwrite）操作，因为覆盖重写的话可能在一次读的操作会读到与其他副本不一致的数据，而在追加操作中，其中一个副本的不一致也不会导致客户端读到不一致的数据；同时 HDFS 在追加操作时采用租用（Lease）机制，即将块的写操作授权给主块服务器（primary chunk server），另外的副本称为次块服务器（secondary chunk server），当多个客户端的并发写操作时，主块服务器缓存其写的顺序，之后联系次服务器进行追加操作

不适用的场景

• 低延时的数据访问：对延时要求在毫秒级别的应用，不适合采用 HDFS，HDFS 是为高吞吐数据传输设计的，因此 HBase 更适合低延时的数据访问 
• 大量小文件：文件的元数据（如目录结构，文件 Block 的节点列表，Block-node Mapping）保存在 NameNode 的内存中， 整个文件系统的文件数量会受限于 NameNode 的内存大小； 经验而言，一个文件/目录/文件块一般占有150字节的元数据内存空间，如果有100万个文件，每个文件占用1个文件块，则需要大约 300M 的内存，因此上亿级别的文件数量在现有商用机器上难以支持 
• 多方读写：HDFS 采用追加（append-only）的方式写入数据，不支持文件任意 offset 的修改（文件中的地址与内存中的地址表示不同，使用偏移量 File Offset 来表示），不支持多个写入器（writer）

架构

HDFS 主要由 3 个组件构成，分别是 NameNode、SecondaryNameNode 和 DataNode。

HDFS 是以 Master/Slave 模式运行的，其中，NameNode 和 SecondaryNameNode 运行在 Master 节点 上，而 DataNode 运行在 Slave 节点上，所以 HDFS 集群一般由一个 NameNode、一个 SecondaryNameNode 和许多 DataNode 组成，其架构如下图所示：

在 HDFS 中，文件是被分成块来进行存储的，一个文件可以包含许多个块，每个块存储在不同的 DataNode 中。当一个客户端请求读取一个文件时，它需要先从 NameNode 中获取文件的元数据信息，然后从对应的数据节点上并行地读取数据块。

下面介绍 HDFS 架构中 NameNode、SecondaryNameNode 和 DataNode 的功能：

NameNode

NameNode 是主服务器，负责管理文件系统的命名空间以及客户端对文件的访问。当客户端请求数据时，仅仅从 NameNode 中获取文件的元数据信息，具体的数据传输不经过 NameNode，而是直接与具体的 DataNode 进行交互。

这里文件的元数据信息记录了文件系统中的文件名和目录名，以及它们之间的层级关系，同时也记录了每个文件目录的所有者及其权限，甚至还记录每个文件由哪些块组成，这些元数据信息记录在文件 fsimage 中，当系统初次启动时，NameNode 将读取 fsimage 中的信息并保存到内存中。

这些块的位置信息是由 NameNode 启动后从每个 DataNode 获取并保存在内存当中的，这样既减少了  NameNode 的启动时间，又减少了读取数据的查询时间，提高了整个系统的效率。

元数据

按类型分：

• 文件、目录自身的属性信息，例如文件名，目录名，修改信息等
• 与文件记录的信息的存储相关的信息，例如存储块信息，分块情况，副本个数等
• 记录 HDFS 的 Datanode 的信息，用于 DataNode 的管理

按形式分：