HDFS

HDFS

Distributed File System

• 数据量越来越多，在一个操作系统管辖的范围存不下了，那么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，因此迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统 。

• 是一种允许文件通过网络在多台主机上分享的文件系统，可让多机器上的多用户分享文件和存储空间。

• 通透性。让实际上是通过网络来访问文件的动作，由程序与用户看来，就像是访问本地的磁盘一般。

• 容错。即使系统中有某些节点脱机，整体来说系统仍然可以持续运作而不会有数据损失。

• 分布式文件管理系统很多，hdfs只是其中一种，不合适小文件。

 

HDFS的Shell

• 调用文件系统(FS)Shell命令应使用 bin/hdfs dfs xxx 的形式。

• 所有的FS shell命令使用URI路径作为参数。

URI格式是scheme://authority/path。HDFS的scheme是hdfs，对本地文件系统，scheme是file。其中scheme和authority参数都是可选的，如果未加指定，就会使用配置中指定的默认scheme。

例如：/parent/child可以表示成hdfs://namenode:namenodePort/parent/child，或者更简单的/parent/child（假设配置文件是namenode:namenodePort）

• 大多数FS Shell命令的行为和对应的Unix Shell命令类似。

 

HDFS体系结构

 

HDFS中相关组件

Namenode

• 是整个文件系统的管理节点。它维护着整个文件系统的文件目录树，文件/目录的元信息和每个文件对应的数据块列表。接收用户的操作请求。

(见源码)

• 文件包括：

• fsimage:元数据镜像文件。存储某一时段NameNode内存元数据信息。
• edits:操作日志文件。
• fstime:保存最近一次checkpoint的时间

• 以上这些文件是保存在linux的文件系统中。

 

DataNode

• 提供真实文件数据的存储服务。

(见源码)

• 文件块（block）：最基本的存储单位。对于文件内容而言，一个文件的长度大小是size，那么从文件的０偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好的每一个块称一个Block。HDFS默认Block大小是128MB，以一个256MB文件，共有256/128=2个Block.

• 不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间

• Replication。多复本。默认是三个。

 

数据存储：block

• 试验：上传小于128MB的文件，观察块大小

 

数据存储：staging

• HDFS client上传数据到HDFS时，会首先在本地缓存数据，当数据达到一个block大小时，请求NameNode分配一个block。NameNode会把block所在的DataNode的地址告诉HDFS client。HDFS client会直接和DataNode通信，把数据写到DataNode节点一个block文件中。

 

数据存储：读文件解析

• 1.首先调用FileSystem对象的open方法，其实是一个DistributedFileSystem的实例

• 2.DistributedFileSystem通过rpc获得文件的第一批个block的locations，同一block按照重复数会返回多个locations，这些locations按照hadoop拓扑结构排序，距离客户端近的排在前面.

• 3.前两步会返回一个FSDataInputStream对象，该对象会被封装成DFSInputStream对象，DFSInputStream可以方便的管理datanode和namenode数据流。客户端调用read方法，DFSInputStream最会找出离客户端最近的datanode并连接。

• 4.数据从datanode源源不断的流向客户端。

• 5.如果第一块的数据读完了，就会关闭指向第一块的datanode连接，接着读取下一块。这些操作对客户端来说是透明的，客户端的角度看来只是读一个持续不断的流。

• 6.如果第一批block都读完了，DFSInputStream就会去namenode拿下一批blocks的location，然后继续读，如果所有的块都读完，这时就会关闭掉所有的流。

• 如果在读数据的时候，DFSInputStream和datanode的通讯发生异常，就会尝试正在读的block的排第二近的datanode,并且会记录哪个datanode发生错误，剩余的blocks读的时候就会直接跳过该datanode。DFSInputStream也会检查block数据校验和，如果发现一个坏的block,就会先报告到namenode节点，然后DFSInputStream在其他的datanode上读该block的镜像

• 该设计的方向就是客户端直接连接datanode来检索数据并且namenode来负责为每一个block提供最优的datanode，namenode仅仅处理block location的请求，这些信息都加载在namenode的内存中，hdfs通过datanode集群可以承受大量客户端的并发访问。

 

数据存储：写文件解析

• 1.客户端通过调用DistributedFileSystem的create方法创建新文件

• 2.DistributedFileSystem通过RPC调用namenode去创建一个没有blocks关联的新文件，创建前，namenode会做各种校验，比如文件是否存在，客户端有无权限去创建等。如果校验通过，namenode就会记录下新文件，否则就会抛出IO异常.

• 3.前两步结束后会返回FSDataOutputStream的对象，象读文件的时候相似，FSDataOutputStream被封装成DFSOutputStream.DFSOutputStream可以协调namenode和datanode。客户端开始写数据到DFSOutputStream,DFSOutputStream会把数据切成一个个小packet，然后排成队列data quene。

• 4.DataStreamer会去处理接受data quene，他先问询namenode这个新的block最适合存储的在哪几个datanode里（参考第二小节），比如重复数是3，那么就找到3个最适合的datanode，把他们排成一个pipeline.DataStreamer把packet按队列输出到管道的第一个datanode中，第一个datanode又把packet输出到第二个datanode中，以此类推。

• 5.DFSOutputStream还有一个对列叫ack quene，也是有packet组成，等待datanode的收到响应，当pipeline中的所有datanode都表示已经收到的时候，这时akc quene才会把对应的packet包移除掉。

• 如果在写的过程中某个datanode发生错误，会采取以下几步：1) pipeline被关闭掉；2)为了防止防止丢包ack quene里的packet会同步到data quene里；3)把产生错误的datanode上当前在写但未完成的block删掉；4）block剩下的部分被写到剩下的两个正常的datanode中；5）namenode找到另外的datanode去创建这个块的复制。当然，这些操作对客户端来说是无感知的。

• 6.客户端完成写数据后调用close方法关闭写入流

• 7.DataStreamer把剩余得包都刷到pipeline里然后等待ack信息，收到最后一个ack后，通知datanode把文件标示为已完成。

• 另外要注意得一点，客户端执行write操作后，写完得block才是可见的，正在写的block对客户端是不可见的，只有调用sync方法，客户端才确保该文件被写操作已经全部完成，当客户端调用close方法时会默认调用sync方法。是否需要手动调用取决你根据程序需要在数据健壮性和吞吐率之间的权衡。

 

Hadoop Archives

• Hadoop Archives (HAR files)是在0.18.0版本中引入的，它的出现就是为了缓解大量小文件消耗namenode内存的问题。HAR文件是通过在HDFS上构建一个层次化的文件系统来工作。一个HAR文件是通过hadoop的archive命令来创建，而这个命令实 际上也是运行了一个MapReduce任务来将小文件打包成HAR。对于client端来说，使用HAR文件没有任何影响。所有的原始文件都 （using har://URL）。但在HDFS端它内部的文件数减少了。

• 通过HAR来读取一个文件并不会比直接从HDFS中读取文件高效，而且实际上可能还会稍微低效一点，因为对每一个HAR文件的访问都需要完成两层 index文件的读取和文件本身数据的读取。并且尽管HAR文件可以被用来作为MapReduce job的input，但是并没有特殊的方法来使maps将HAR文件中打包的文件当作一个HDFS文件处理。

• 创建文件 hadoop archive -archiveName xxx.har -p  /src  /dest

• 查看内容 hadoop fs -lsr har:///dest/xxx.har

 

数据存储类型和存储策略

• 存储类型: ARCHIVE, DISK, SSD and RAM_DISK

• 存储策略: Hot, Warm, Cold, All_SSD, One_SSD and Lazy_Persist

• 显示存储策略bin/hdfs storagepolicies

• 设置bin/hdfs dfsadmin -setStoragePolicy <path> <policyName>

• 显示bin/hdfs dfsadmin -getStoragePolicy <path>

 

HDFS2的HA

HA的自动failover

• HDFS的HA，指的是在一个集群中存在两个NameNode，分别运行在独立的物理节点上。在任何时间点，只有一个NameNodes是处于Active状态，另一种是在Standby状态。 Active NameNode负责所有的客户端的操作，而Standby NameNode用来同步Active NameNode的状态信息，以提供快速的故障恢复能力。

• 为了保证Active NN与Standby NN节点状态同步，即元数据保持一致。除了DataNode需要向两个NN发送block位置信息外，还构建了一组独立的守护进程”JournalNodes”,用来同步FsEdits信息。当Active NN执行任何有关命名空间的修改，它需要持久化到一半以上的JournalNodes上。而Standby NN负责观察JNs的变化，读取从Active NN发送过来的FsEdits信息，并更新其内部的命名空间。一旦ActiveNN遇到错误，Standby NN需要保证从JNs中读出了全部的FsEdits，然后切换成Active状态。

HDFS2的federation

• HDFS Federation设计可解决单一命名空间存在的以下几个问题：

（1）HDFS集群扩展性。多个NameNode分管一部分目录，使得一个集群可以扩展到更多节点，不再像1.0中那样由于内存的限制制约文件存储数目。

（2）性能更高效。多个NameNode管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率。

（3）良好的隔离性。用户可根据需要将不同业务数据交由不同NameNode管理，这样不同业务之间影响很小。

 

HDFS2的federation

这个图过于简明，许多设计上的考虑并不那么直观，我们稍微总结一下

• 多个NN共用一个集群里DN上的存储资源，每个NN都可以单独对外提供服务

• 每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储

• DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况

• 如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN上必须存在相应的目录

这样设计的好处大致有：

• 改动最小，向前兼容

    现有的NN无需任何配置改动.

    如果现有的客户端只连某台NN的话，代码和配置也无需改动。

• 分离命名空间管理和块存储管理

    提供良好扩展性的同时允许其他文件系统或应用直接使用块存储池

    统一的块存储管理保证了资源利用率

    可以只通过防火墙配置达到一定的文件访问隔离，而无需使用复杂的Kerberos认证

• 客户端挂载表

    通过路径自动对应NN

    使Federation的配置改动对应用透明

 

• 在这个图里，我们可以看出HA的大致架构，其设计上的考虑包括：

• 利用共享存储来在两个NN间同步edits信息。

• 以前的HDFS是share nothing but NN，现在NN又share storage，这样其实是转移了单点故障的位置，但中高端的存储设备内部都有各种RAID以及冗余硬件包括电源以及网卡等，比服务器的可靠性还是略有提高。通过NN内部每次元数据变动后的flush操作，加上NFS的close-to-open，数据的一致性得到了保证。社区现在也试图把元数据存储放到BookKeeper上，以去除对共享存储的依赖，Cloudera也提供了Quorum Journal Manager的实现和代码，这篇中文的blog有详尽分析：基于QJM/Qurom Journal Manager/Paxos的HDFS HA原理及代码分析

• DataNode(以下简称DN)同时向两个NN汇报块信息。

• 这是让Standby NN保持集群最新状态的必需步骤，不赘述。

• 用于监视和控制NN进程的FailoverController进程

• 显然，我们不能在NN进程内进行心跳等信息同步，最简单的原因，一次FullGC就可以让NN挂起十几分钟，所以，必须要有一个独立的短小精悍的watchdog来专门负责监控。这也是一个松耦合的设计，便于扩展或更改，目前版本里是用ZooKeeper(以下简称ZK)来做同步锁，但用户可以方便的把这个ZooKeeper FailoverController(以下简称ZKFC)替换为其他的HA方案或leader选举方案。

• 隔离(Fencing))，防止脑裂)，就是保证在任何时候只有一个主NN，包括三个方面：

• 共享存储fencing，确保只有一个NN可以写入edits。

• 客户端fencing，确保只有一个NN可以响应客户端的请求。

• DataNode fencing，确保只有一个NN可以向DN下发命令，譬如删除块，复制块，等等。

 

HDFS 的Trash回收站

• 和Linux系统的回收站设计一样，HDFS会为每一个用户创建一个回收站目录：/user/用户名/.Trash/，每一个被用户通过Shell删除的文件/目录，在系统回收站中都一个周期，也就是当系统回收站中的文件/目录在一段时间之后没有被用户回复的话，HDFS就会自动的把这个文件/目录彻底删除，之后，用户就永远也找不回这个文件/目录了。

• 配置：在每个节点(不仅仅是主节点)上添加配置 core-site.xml,增加如下内容

<property>

    <name>fs.trash.interval</name>

    <value>1440</value>

</property>

 

小文件的解决方案

• 小文件指的是那些size比HDFS的block size(默认64M)小的多的文件。任何一个文件，目录和block，在HDFS中都会被表示为一个object存储在namenode的内存中，每一个object占用150 bytes的内存空间。所以，如果有10million个文件，每一个文件对应一个block，那么就将要消耗namenode 3G的内存来保存这些block的信息。如果规模再大一些，那么将会超出现阶段计算机硬件所能满足的极限。

• 应用程序自己控制

• archive

• Sequence File / Map File

• 合并小文件，如HBase部分的compact

• *CombineFileInputFormat

 

小文件的解决方案——应用程序自己控制

                   final Path path = new Path("/combinedfile");

                   final FSDataOutputStream create = fs.create(path);

                   final File dir = new File("C:\\Windows\\System32\\drivers\\etc");

                   for(File fileName : dir.listFiles()) {

                            System.out.println(fileName.getAbsolutePath());

                            final FileInputStream fileInputStream = new FileInputStream(fileName.getAbsolutePath());

                            final List<String> readLines = IOUtils.readLines(fileInputStream);

                            for (String line : readLines) {

                                     create.write(line.getBytes());

                            }

                            fileInputStream.close();

                   }

                   create.close();

 

小文件的解决方案——SequenceFile

• 通常对于“the small files problem”的回应会是：使用SequenceFile。这种方法是说，使用filename作为key，并且file contents作为value。实践中这种方式非常管用。回到10000个100KB的文件，可以写一个程序来将这些小文件写入到一个单独的 SequenceFile中去，然后就可以在一个streaming fashion(directly or using mapreduce)中来使用这个sequenceFile。不仅如此，SequenceFiles也是splittable的，所以mapreduce 可以break them into chunks，并且分别的被独立的处理。和HAR不同的是，这种方式还支持压缩。block的压缩在许多情况下都是最好的选择，因为它将多个 records压缩到一起，而不是一个record一个压缩。

 

Remote Procedure Call

• RPC——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

• RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

• hadoop的整个体系结构就是构建在RPC之上的(见org.apache.hadoop.ipc)。