Hadoop学习笔记之初步了解HDFS

因为工作需要开始了解Hadoop，做一个小小的学习笔记，总结下今天看的。

Hadoop：一个分布式系统架构，能够对大量数据进行分布式处理的软件框架。

可靠（维护多个工作数据副本），高效（并行处理），可伸缩（可以处理PB级数据）的方式进行处理。

优点：高可靠性，高扩展性，高效性，高容错性，低成本。

核心设计：HDFS（海量数据的存储）和MapReduce（海量数据的计算）

 

接下来主要介绍下HDFS：

HDFS(Hadoop Distributed File System)由Hadoop实现的一个分布式文件系统。高容错性的特点，并且设计用来部署在低廉的硬件上。而且它提供高传输率来访问应用程序的数据，是为以流的方式存取大文件而设计的，适合那些有着超大数据集的应用程序。HDFS支持大数据文件，能够提供大数据传输的带宽和数百个节点的集群的服务，能够支持千万级别的文件。并适合写一次读多次的场合。而对于低延时数据访问、大量小文件、同时写和任意的文件修改，则并不是十分适合存储Hadoop集群众所有存储节点上的文件，在Hadoop的最底部。可以创建，删除，重命名文件等。

HDFS是Apache Hadoop Core项目的一部分，开始是为开源的apache项目nutch的基础结构而创建，HDFS是hadoop项目的一部分，而hadoop又是lucene的一部分。

优点

 1）处理超大文件

这里的超大文件通常是指百MB、设置数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。

2）流式的访问数据

HDFS的设计建立在更多地响应"一次写入、多次读写"任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。

3）运行于廉价的商用机器集群上

Hadoop设计对硬件需求比较低，只须运行在低廉的商用硬件集群上，而无需昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性，安全性及高可用性。

缺点

1）不适合低延迟数据访问

如果要处理一些用户要求时间比较短的低延迟应用请求，则HDFS不适合。HDFS是为了处理大型数据集分析任务的，主要是为达到高的数据吞吐量而设计的，这就可能要求以高延迟作为代价。

2）无法高效存储大量小文件

因为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文件系统的服务器数量是巨大的，而且任一个服务器都有可能失效，这意味着总是有一部分HDFS的服务器是不工作的。因此错误检测和快速、自动的恢复是HDFS最为核心的架构目标。

流式数据访问：

运行在HDFS上的应用程序和普通的应用程序不同，它需要流式访问数据集。在HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理；相比数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。POSIX标准设置的很多硬性约束对HDFS应用程序不是必需的。为了提高数据的吞吐量，在一些关键方面对POSIX的语义做了一些修改。

大规模数据集：

运行在HDFS上的应用程序具有很大的数据集。HDFS上一个典型文件大小一般都在G字节至T字节。因此，HDFS被设计为支持大文件存储，且应该能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。一个单一的HDFS实例应该能支撑数以千万计的文件。

简单一致性模型：

HDFS应用程序需要一个“一次写入多次读取”的文件访问模型，要求一个文件经过创建、写入和关闭之后就不需要改变。该模型假设简化了数据一致性问题，并且使高吞吐量的数据访问成为可能。Map/Reduce应用或者网络爬虫应用都非常适合这个模型。

计算移到数据附近：

一个应用请求的计算，离它操作的数据越近就越高效，在数据达到海量级别的时候更是如此。因为这样就能降低网络阻塞的影响，提高系统数据的吞吐量。将计算移动到数据附近，比之将数据移动到应用所在显然更好。HDFS为应用程序提供了将它们移动到数据附近的接口。

可移植性：

HDFS在设计的时候就考虑到异构软硬件平台的可移植性。这种特性方便了HDFS作为大规模数据应用平台的推广。

基于一组特定的节点构建的如下图：（图片来自百度百科）

 


构成HDFS主要是Namenode（master）和一系列的Datanode（workers）。

HDFS支持传统的层次型文件组织。

所有的HDFS通讯协议都是构建在TCP/IP协议上。

HDFS的主要目标就是实现在失败情况下的数据存储可靠性。

HDFS给应用提供了多种访问方式。

NameNode在HDFS内部提供元素数据服务并且仅有一个，DataNode为HDFS提供存储块。与传统的RAID（磁盘阵列）架构不同，块大小和复制的数据量在创建文件时由客户机决定。NameNode可以控制所有文件操作。HDFS内部所有通信都基于标准的TCP/IP协议。

NameNode是一个通常在HDFS实例中的单独机器上运行的软件。负责管理文件系统名称空间和控制外部客户机的访问。NameNode决定是否将文件映射到DataNode上的复制块上。NameNode在文件FsImage中存储所有关于文件系统名称空间的信息。此文件和一个包含所有事务的记录文件EditLog均存储在NameNode的本地文件系统上。并且这两个文件也要复制副本，以防止文件损坏或NameNode系统丢失。

DataNode也是一个通常在HDFS实例中的单独机器上运行的软件通常以机架的形式组织，机架通过一个交换机将所有系统连接起来。Hadoop的一个假设：机架内部节点之间的传输速度快于机架间节点之间的传输速度。DataNode响应来自HDFS客户机的读写请求，NameNode的创建，删除和复制块的命令。NameNode依赖来自每个DataNode的定期心跳消息。每条消息都包含一个块报告，NameNode可以根据这个报告验证块映射和其他文件系统元素。如果DataNode不能发送心跳消息，NameNode将采取修复措施，重新复制在该节点上丢失的块。

文件操作：HDFS目的是支持以流的形式访问写入的大型文件。客户机要讲文件写入HDFS上，首先要讲该文件缓存到本地的临时存储。如果数据大于所需的HDFS块大小，创建文件的请求将发送给NameNode。NameNode将以DataNode标识和目的块相应客户机。同时还要保存文件块副本的DataNode。当客户机开始将临时文件发送给第一个DataNode时，将立即通过管道方式将块内容转发给副本DataNode。客户机也负责创建保存在相同HDFS名称空间中的校验和文件。在最后的文件块发送之后，NameNode将文件创建提交到他的持久化元数据存储（EditLog和FsImage文件）。