ma-大数据HDFS

 

 0 引子：

提出两个问题，是对上面 ma-大数据mapreduce思想和数据切割 的深入提问以及hdfs的引入：

 

1、对每一次的MapReduce作业来说，JobTracker可能会启动个数不同的mapper，且可能调度它们运行于不同的TaskTracker上，那么，这些个mapper如何获取要处理的数据(split)，以及如何高效获取所需的数据？


2、如果存储了数据的设备发生了故障，MapReduce是否还能继续运行？如果能，如何进行？

 

 

1  hadoop的mapreduce和hdfs关系：

 

MapReduce并非依赖于分布式文件系统，只不过运行在非分布式文件系统的MapReduce的诸多高级特性将无用武之地.

 

 

2 hdfs设计理念：

 

和传统文件系统相同处：

文件数据存储于“数据块(block)”中、通过“元数据”将文件名与数据块建立映射关系、文件系统基于目录实现树状组织结构、通过元数据保存文件权限及时间戳等。

和传统文件不同处：

1 HDFS是用户空间的文件系统，



2 传统文件系统的“块大小(block size)”通过为1KB、2KB或4KB等，而HDFS的块大小为64MB，且在生产环境中使用时，此块大小通常还会被调整为128MB、256MB甚至是512MB等。

因为HDFS专为存储大文件而设计，较大的块可以减少磁盘的寻道次数，进而提升I/O性能



3 HDFS将所有文件的元数据存储于名称节点(NameNode)的内存中，对于有着海量小文件的应用场景则会给名称节点的内存空间带去巨大压力并使得其很可能成为系统性能瓶颈。



4 HDFS为MapReduce的计算框架而设计，存储下来数据主要用于后续的处理分析，其访问模型为“一次写入、多次读取”；因此，数据在HDFS中存储完成后，仅能在文件尾部附加新数据，而不能对文件进行修改。



5 HDFS专为了高效地传输大文件进行了优化，其为了完成此目标，在“低延迟”特性上做出了很大让步，因此，其不适用于较小访问延迟的应用

 

 

3 hdfs节点：

 

 

 

namenode(名称节点):

 

 名称节点负责管理HDFS的名称空间，即以树状结构组织的目录及文件的元数据信息，
这些信息持久存储于名称节点本地磁盘上并保存为名称“空间镜像(namespace image)”和“编辑日志(edit log)”两个文件。
并不存储数据块，仅需要知道每个文件对应数据块的存储位置(存储在数据节点的位置)

但是名称节点并不会持久存储数据块所与其存储位置的对应信息，
        这个对应信息是HDFS集群启动时由名称节点根据各数据节点发来的信息进行重建而来，这个重建过程叫做hdfs的安全模式。

 

 

datanode(数据节点)：

 

    根据名称节点或客户的要求完成存储或读取数据块，并周期性地将其保存的数据块相关信息报告给名称节点

 

关于存储节点的分配：

 

默认情况下，HDFS会在集群中为每个数据块存储三个副本以确保数据的可靠性、可用性及性能表现。
在一个大规模集群中，这三个副本一般会保存至不同机架中的数据节点上以应付两种常见的故障：
单数据节点故障和导致某机架上的所有主机离线的网络故障。另外，如前面MapReduce运行模型中所述，
为数据块保存多个副本也有利于MapReduce在作业执行过程中透明地处理节点故障等，
并为MapReduce中作业协同处理以提升性能提供了现实支撑。名称节点会根据数据节点的周期性报告来检查每个数据块的副本数是否符合要求，
低于配置个数要求的将会对其进行补足，而多出的将会被丢弃。 

 

 

 

4 hdfs特点：

 

1 用来存储大文件

2  构建在用户空间的文件系统 ，压根就不是内核中的文件

3  HDFS不支持修改，存好后就不能动了， 新版本支持追加    (一次建立 多次读取 不允许随便修改 新版本支持追加)

4 不支持挂载，不支持系统调用访问，  只能通过专门客户端工具 API 或者 hdfs shell 

 

 

5 解答问题:

 

job的多个task(eg: map task或者mapper) 如何知道要处理的 split的数据：

回答：这其实就是客户端如何读取hdfs文件的流程：

 

HDFS提供了POSIX网络的访问接口，所有的数据操作对客户端程序都是透明的，

以先存后取的流程介绍如下：  

当需要存储文件并写数据到hdfs时，客户端程序首先会向名称节点发起名称空间更新请求，
名称节点检查用户的访问权限及文件是否已经存在，如果没有问题，名称空间会挑选一个合适的数据节点分配一个空闲数据块给客户端程序，
此时名称节点内存中会增加维护这段数据在datanode节点的blockid和存储在datanode的节点信息
客户端程序直接将要存储的数据发往对应的数据节点，在完成存储后，数据节点将根据名称节点的指示将数据块复制多个副本至其它节点。

当客户端程序需要访问HDFS中的数据时(即mapper要处理对应split时)，它首先基于TCP/IP协议与名称节点(namenode)监听的TCP端口建立连接，
接着通过客户端协议(Client Protocol)发起读取文件的请求，而后名称节点根据用户请求返回相关文件的块标识符(blockid)及存储了此数据块的数据节点。
接下来客户端向对应的数据节点监听的端口发起请求并取回所需要数据块。

 

 

 

 

6 hdfs 读写数据具体介绍：

 

6.1 写数据：

 

 对上述流程文字描述如下：

(1) 向HDFS集群中保存数据之前，HDFS客户端需要事先知悉目标文件系统使用的“块大小”以及“复制因子(Replication Factor，即每一个块需要保存的副本数目)”。在提交数据至HDFS之前，HDFS客户端需要将要保存的文件按块大小进行分割，并将其逐个向名称节点发起块存储请求，此时，根据复制因子，客户端会要求名称节点给出与复制因子相同个数的空闲块，这里假设为3个；

(2) 名称节点需要从找出至少3个具有可用空闲块的数据节点(同复制因子)，并将这3个节点的地址以距客户端的距离由近及远的次序响应给客户端；

(3) 客户端仅向最近的数据节点(假设为DN1)发起数据存储请求；当此最近的数据节点存储完成后，其会将数据块复制到剩余的数据节点中的一个(假设为DN2)，传输完成后，由DN2负责将数据块再同步至最后一个数据节点(假设为DN3)；这个也称为“复制管道(replication pipeline)；

(4) 当三个数据节点均存储完成后，它们会将“存储完成(DONE)”的信息分别通知给名称节点；而后，名称节点会通知客户端存储完成；

(5) 客户端以此种方式存储剩余的所有数据块，并在全部数据块存储完成后通知名称节点关闭此文件，名称节点接着会将此文件的元数据信息存储至持久存储中；

 

6.2 读操作：

 对上述流程文字描述如下：

(1) 客户端向名称节点请求访问某文件；

(2) 名称节点向客户端响应两个列表：(a)此文件包含的所有数据块，(b)此文件的每个数据块所在的数据节点列表；

(3) 客户端将每一个数据块从存储列表中最近的数据节点读取，而后在本地完成合并； 

 

 

 

7 名称节点可用性

 

名称节点的宕机将会导致HDFS文件系统中的所有数据变为不可用，而如果名称节点上的名称空间镜像文件或编辑日志文件损坏的话，
整个HDFS甚至将无从重建，所有数据都会丢失。因此，出于数据可用性、可靠性等目的，必须提供额外的机制以确保此类故障不会发生，Hadoop为此提供了两种解决方案。

 

1 最简单的方式是将名称节点上的持久元数据信息实时存储多个副本于不同的存储设备中。
Hadoop的名称节点可以通过属性配置使用多个不同的名称空间存储设备，而名称节点对多个设备的写入操作是同步的。
当名称节点故障时，可在一台新的物理主机上加载一份可用的名称空间镜像副本和编辑日志副本完成名称空间的重建。
然而，根据编辑日志的大小及集群规模，这个重建过程可能需要很长时间。

 

2 另一种方式是提供第二名称节点(Secondary NameNode)。第二名称节点并不真正扮演名称节点角色，
它的主要任务是周期性地将编辑日志合并到名称空间镜像文件中，以免编辑日志变得过大。
它运行在一个独立的物理主机上，并需要跟名称节点同样大的内存资源来完成文件合并(即要和namenode的内存保持一致)。
另外，它还保存一份名称空间镜像的副本。然而，根据其工作机制可知，第二名称节点要滞后于主节点，因此名称节点故障时，部分数据丢失仍然不可避免。

 

单节点的坏处：

尽管上述两种机制可以最大程序上避免数据丢失，但其并不具有高可用的特性，名称节点依然是一个单点故障，因为其宕机后，所有的数据将不能够被访问，
进而所有依赖于此HDFS运行的MapReduce作业也将中止。就算是备份了名称空间镜像和编辑日志，
在一个新的主机上重建名称节点并完成接收来自各数据节点的块信息报告也需要很长的时间才能完成。
在有些应用环境中，这可能是无法接受的，为此，Hadoop 0.23引入了名称节点的高可用机制——设置两个名称节点工作于“主备”模型，
主节点故障时，其所有服务将立即转移至备用节点。

 

联盟概念：

在大规模的HDFS集群中，为了避免名称节点成为系统瓶颈，在Hadoop 0.23版本中引入了HDFS联邦(HDFS Federation)机制。
HDFS联邦中，每个名称节点管理一个由名称空间元数据和包含了所有块相关信息的块池组成名称空间卷(namespace volume)，
各名称节点上的名称空间卷是互相隔离的，因此，一个名称节点的损坏并不影响其它名称节点继续提供服务。

关于Hadoop联盟 参看文章： hadoop2 federation 联盟 简介

  

 

 

ha搭建见：hadoop2 搭建自动切换的ha集群 yarn集群 

 

 

8 hdfs容错能力

 

HDFS故障的三种最常见场景为：节点故障、网络故障和数据损坏。

 

 1 节点故障：

在不具备名称节点HA功能的Hadoop中，名称节点故障将会导致整个文件系统离线；因此，名称节点故障具有非常严重的后果，细则看 7 名称节点可用性

 

2 网络故障判断和集群处理

在HDFS集群中，各数据节点周期性地(每3秒钟)向名称节点发送心跳信息(HEARTBEAT)以通告其“健康”状况；相应地，名称节点如果在10分钟内没有收到某数据节点的心跳信息，则认为其产生了故障并将其从可用数据节点列表中移除，无论此故障产生的原因是节点自身还是网络问题。

客户端与数据节点之间的数据传输基于TCP协议进行，客户端每发送一个报文给数据节点，数据节点均会返回一个响应报文给客户端；因此，如果客户端重试数次后仍未能正常接收到来自数据节点的响应报文，其将放弃此数据节点转而使用名称节点提供的列表中的第二个数据节点。 

 

3 数据损坏：

 

网络传输中的噪声等都有可能导致数据讹误，为了避免数据节点存储错误的数据，客户端发送数据至数据节点时会一并传送此数据的校验和，
而数据节点会连同数据一起存储此校验和。HDFS集群中，数据节点周期性地每将自己持有的所有数据块信息报告给名称节点，但在发送每个数据块的相关信息之前，
其会根据校验和检验此数据块是否出现了讹误，如果检验出错，
数据节点将不再向名称节点通告自己持有此数据块，名称节点从而可以得知此数据节点有数据块损坏