大数据技术之Hadoop-HDFS架构
官方网站
简介
Hadoop分布式文件系统（HDFS）是一种旨在在商品硬件上运行的分布式文件系统。它与现有的分布式文件系统有许多相似之处。但是，与其他分布式文件系统的区别也很明显。HDFS具有高度的容错能力，目的是为了能部署在低成本的硬件上。HDFS提供对应用程序数据的高吞吐量访问，并且适用于具有大数据集的应用程序。HDFS放宽了一些POSIX要求，以实现对文件系统数据的流式访问。HDFS最初是作为Apache Nutch Web搜索引擎项目的基础结构而构建的。HDFS是Apache Hadoop Core项目的一部分。项目的访问地址
假设与目标
硬件故障
硬件故障是正常现象，而非例外。HDFS实例可能包含成百上千个服务器计算机，每个服务器计算机都存储文件系统数据的一部分。存在大量组件并且每个组件的故障概率都很高的事实意味着HDFS的某些组件始终无法运行。因此，检测故障并快速，自动地从故障中恢复是HDFS的核心目标。
流式数据访问
在HDFS上运行的应用程序需要对其数据集进行流式访问。通常它们不是运行在普通的文件系统上的通用应用程序。HDFS被设计用于批处理，而不是用户交互使用。重点在于数据访问的高吞吐量，而不是数据访问的低延迟。POSIX提出了许多针对HDFS的应用程序不需要的硬性要求。在一些关键领域中，POSIX语义已经被交易以提高数据吞吐率。
大数据集
在HDFS上运行的应用程序具有大量数据集。HDFS中的典型文件大小为GB到TB。因此，HDFS已调整为支持大文件。它应提供较高的聚合数据带宽，并可以扩展到单个群集中的数百个节点。它应该在单个实例中支持数千万个文件。
简单一致性模型
HDFS应用程序需要文件一次写入多次读取访问模型。一旦创建，写入和关闭的文件，除了追加和删除外，无需更改。支持将内容追加到文件末尾，但不能在任意点更新。该假设简化了数据一致性问题并实现了高吞吐量数据访问。MapReduce应用程序或Web爬网程序应用程序非常适合此模型。
“移动计算比移动数据便宜”
如果应用程序所请求的计算在其所操作的数据附近执行，则效率会更高。当数据集的大小巨大时，尤其如此。这样可以最大程度地减少网络拥塞，并提高系统的整体吞吐量。假设通常是将计算迁移到更靠近数据的位置，而不是将数据移动到应用程序正在运行的位置。HDFS为应用程序提供了接口，使它们自己更靠近数据所在的位置。
跨异构硬件和软件平台的可移植性
HDFS的设计目的是可以轻松地从一个平台移植到另一个平台。这有助于将HDFS广泛用作大量应用程序的首选平台。
NameNode和DataNodes
HDFS具有主/从体系的架构。HDFS群集只包含了一个NameNode，它是一个master server，是用来管理文件系统的命名空间并规范客户端对文件系统的访问。此外，还包含了多个DataNodes节点，通常是集群中每个节点一个，用于管理正在运行的节点的存储。 HDFS公开了文件系统的名称空间，并允许用户数据存储在文件中。在文件系统的内部，文件被分成一个或多个块，这些块数据存储在多个DataNode中。NameNode执行文件系统名称空间操作，例如打开，关闭和重命名文件和目录。它还确定块到DataNode的映射。DataNodes负责处理来自文件系统客户端的读写请求。DataNode还根据NameNode的指令执行块创建，删除和复制。
NameNode和DataNode是旨在在商用机器上运行的软件。这些机器通常运行GNU / Linux操作系统（OS）。HDFS是使用Java语言编写的；任何支持Java的机器都可以运行NameNode或DataNode。使用高度可移植的Java语言意味着HDFS可以部署在各种各样的机器上。典型的部署有专用的计算机，该计算机仅运行NameNode软件。集群中的每台其他计算机都运行DataNode软件的一个实例。该架构并不排除在同一台机器上运行多个DataNode，而是在实际部署中很少出现这种情况。
群集中单个NameNode的存在极大地简化了系统的体系结构。NameNode是所有HDFS元数据的仲裁器和存储库。该系统的设计方式是，用户数据永远不会流过NameNode。
文件系统命名空间
HDFS支持传统的分层文件组织。用户或应用程序可以创建目录并将文件存储在这些目录中。文件系统名称空间层次结构与大多数其他现有文件系统相似。可以创建和删除文件，将文件从一个目录移动到另一个目录或重命名文件。HDFS支持用户配额和访问权限。HDFS不支持硬链接或软链接。但是，HDFS体系结构并不排除实现这些功能。
虽然HDFS遵循文件系统的命名约定，但某些路径和名称（例如/.reserved和.snapshot）被保留。透明加密和快照等功能使用保留的路径。
NameNode维护文件系统名称空间。对文件系统名称空间或其属性的任何更改均由NameNode记录。应用程序可以指定HDFS应该维护的文件副本的数量。文件的副本数称为该文件的复制因子。此信息由NameNode存储。
数据副本
HDFS旨在在大型群集中的计算机之间可靠地存储非常大的文件。它将每个文件存储为一系列块。文件的块的副本是为了容错。块大小和复制因子是每个文件可配置的。
文件中除最后一个块外的所有块都具有相同的大小，而在添加了对可变长度块的支持后，用户可以在不填充最后一个块的情况下开始新的块，而不用配置的块大小。
应用程序可以指定文件的副本数。复制因子可以在文件创建时指定，以后可以更改。HDFS中的文件只能写入一次（追加和截断除外），并且在任何时候都只能具有一个写入器。
NameNode做出有关块副本的所有决定。它定期从群集中的每个DataNode接收心跳信号和Blockreport。收到心跳信号表示DataNode正常运行。 Blockreport包含DataNode上所有块的列表。
第一步：副本的放置
副本的存放位置对于HDFS的可靠性和性能至关重要。优化副本的放置将HDFS与大多数其他分布式文件系统区分开来。这个功能需要大量调整和经验。支持机架的副本放置策略的目的是提高数据可靠性，可用性和网络带宽利用率。副本放置策略的当前实现是朝这个方向的第一步。实施这个策略的短期目标是在生产系统上对其进行验证，进一步了解其行为，并为测试和研究更复杂的策略奠定基础。
大型HDFS实例在通常分布在许多机架上的计算机群集上运行。不同机架中的两个节点之间的通信必须通过交换机进行。在大多数情况下，同一机架中的计算机之间的网络带宽大于不同机架中的计算机之间的网络带宽。
NameNode通过Hadoop机架感知中概述的过程确定每个DataNode所属的机架ID。一种简单但非最佳的策略是将副本放置在唯一的机架上。这样可以防止在整个机架出现故障时丢失数据，并允许在读取数据时使用多个机架的带宽。此策略在群集中平均分配副本，这使得在组件故障时轻松平衡负载成为可能。但是，此策略增加了写入成本，因为写入需要将块传输到多个机架。在通常情况下，当复制因子为3时，HDFS的放置策略是：如果写入器位于datanode上，则将一个副本放置在本地计算机上；否则，将与写入器位于同一机架的随机datanode放置在本地计算机上，将另一个副本放置在本地计算机上。 一个节点位于不同（远程）机架中，最后一个节点位于同一远程机架中的另一个节点上。该策略减少了机架间的写流量，通常可以提高写性能。 机架故障的机会远小于节点故障的机会。此策略不会影响数据的可靠性和可用性保证。但是，由于一个块仅放置在两个唯一的机架中，而不是三个，因此它确实减少了读取数据时使用的总网络带宽。使用此策略，文件的副本不会均匀分布在机架上。三分之一的副本位于一个节点上，三分之二的副本位于一个机架上，其余三分之一则均匀分布在其余机架上。此策略可提高写入性能，而不会影响数据可靠性或读取性能。
如果复制因子大于3，则在确定每个机架的副本数量低于上限（基本上是（副本-1）/机架+ 2）以下的同时，随机确定第4个及以下副本的位置。
由于NameNode不允许DataNode具有同一块的多个副本，因此创建的副本的最大数量是当时DataNode的总数。
将对存储类型和存储策略的支持添加到HDFS后，除了上述机架识别之外，NameNode还考虑了该策略的副本放置位置。首先，NameNode基于机架识别来选择节点，然后检查候选节点是否具有与文件关联的策略所需的存储。如果候选节点不具有存储类型，则NameNode将寻找另一个节点。如果在第一条路径中找不到足够的节点来放置副本，则NameNode将在第二条路径中查找具有备用存储类型的节点。
这里描述的当前默认副本放置策略是一项正在进行的工作。
副本的选择
为了最大程度地减少全局带宽消耗和读取延迟，HDFS尝试满足最接近读取器的副本的读取请求。如果在与读取器节点相同的机架上存在一个副本，那么该副本就可以满足读取请求。如果HDFS群集跨越多个数据中心，则驻留在本地数据中心的副本优先于任何远程副本。
安全模式
启动时，NameNode进入一个特殊的状态，称为安全模式。当NameNode处于安全模式状态时，不会发生数据块的复制。NameNode从DataNodes接收心跳和Blockreport消息。Blockreport包含DataNode托管的数据块列表。每个块都有指定的最小副本数。当已使用NameNode检入该数据块的最小副本数时，该块被视为已安全复制。在使用可配置百分比的安全复制数据块通过NameNode校验后（再加上30秒），NameNode退出安全模式状态。然后，它确定仍少于指定数量的副本的数据块列表（如果有）。然后，NameNode将这些块复制到其他DataNode。
文件系统元数据的持久化
HDFS命名空间由NameNode存储。NameNode使用一个称为EditLog的事务日志来永久记录文件系统元数据发生的每个更改。例如，在HDFS中创建一个新文件将导致NameNode将一条记录插入到EditLog中，以表明这一点。同样，更改文件的副本因子会导致将新记录插入到EditLog中。NameNode使用其本地主机OS文件系统中的文件来存储EditLog。整个文件系统名称空间（包括块到文件的映射和文件系统属性）存储在名为FsImage的文件中。FsImage也作为文件存储在NameNode的本地文件系统中。
NameNode在内存中保留整个文件系统名称空间和文件Blockmap的图像。当NameNode启动或由可配置的阈值触发检查点时，它会从磁盘读取FsImage和EditLog，将EditLog中的所有事务应用于FsImage的内存中表示形式，并将此新版本刷新为 磁盘上的新FsImage。然后，它可以删除旧的EditLog，因为其事务已应用于持久性FsImage。此过程称为检查点。检查点的目的是通过获取文件系统元数据的快照并将其保存到FsImage来确保HDFS具有文件系统元数据的一致视图。即使读取FsImage效率很高，但直接对FsImage进行增量编辑效率也不高。我们无需为每个编辑修改FsImage，而是将编辑保留在Editlog中。在检查点期间，来自Editlog的更改将应用于FsImage。 可以在以秒为单位的给定时间间隔（dfs.namenode.checkpoint.period）或累积一定数量的文件系统事务之后（dfs.namenode.checkpoint.txns）触发检查点。如果同时设置了这两个属性，则要达到的第一个阈值将触发检查点。
DataNode将HDFS数据存储在其本地文件系统中的文件中。DataNode不了解HDFS文件。它将每个HDFS数据块存储在其本地文件系统中的单独文件中。DataNode不会在同一目录中创建所有文件。而是使用启发式方法确定每个目录的最佳文件数，并适当创建子目录。在同一目录中创建所有本地文件不是最佳选择，因为本地文件系统可能无法有效地支持单个目录中的大量文件。当DataNode启动时，它将扫描其本地文件系统，生成与每个本地文件相对应的所有HDFS数据块的列表，并将此报告发送到NameNode。该报告称为Blockreport。
通讯协议
所有HDFS通信协议都位于TCP / IP协议之上。客户端建立与NameNode计算机上可配置TCP端口的连接。它将ClientProtocol与NameNode进行通信。DataNode使用DataNode协议与NameNode进行通信。远程过程调用（RPC）抽象包装了客户端协议和DataNode协议。按照设计，NameNode永远不会启动任何RPC。相反，它仅响应由DataNode或客户端发出的RPC请求。
可靠性
HDFS的主要目标是即使出现故障也能可靠地存储数据。三种常见的故障类型是NameNode故障，DataNode故障和网络分区。
数据磁盘故障，心跳和复制
每个DataNode定期向NameNode发送心跳消息。网络分区可能导致一部分DataNode失去与NameNode的连接。NameNode通过缺少心跳消息来检测到这种情况。NameNode将没有最近心跳的DataNode标记为已死，并且不会将任何新的IO请求转发给它们。已注册到失效DataNode的任何数据不再可用于HDFS。DataNode死亡可能导致某些块的副本因子降至其指定值以下。NameNode不断跟踪需要复制的块，并在必要时启动复制。由于许多原因，可能需要进行重新复制：DataNode可能不可用，副本可能损坏，DataNode上的硬盘可能发生故障或文件的副本因子增加。
集群的再平衡
HDFS体系结构与数据重新平衡方案兼容。如果DataNode的可用空间低于某个阈值，则方案可能会自动将数据从一个DataNode移至另一个DataNode。如果对特定文件的需求突然增加，则方案可能会动态创建其他副本并重新平衡群集中的其他数据。这些类型的数据重新平衡方案尚未实现。
数据的完整性
从DataNode提取的数据块可能会损坏。由于存储设备故障，网络故障或软件故障，可能会导致这种损坏。HDFS客户端软件对HDFS文件的内容执行校验和检查。客户端创建HDFS文件时，它将计算文件每个块的校验和，并将这些校验和存储在同一HDFS命名空间中的单独的隐藏文件中。客户端检索文件内容时，它将验证从每个DataNode接收的数据是否与存储在关联的校验和文件中的校验和匹配。如果不是，则客户端可以选择从另一个具有该块副本的DataNode中检索该块。
元数据磁盘的故障
FsImage和EditLog是HDFS的核心数据结构。这些文件损坏可能导致HDFS实例无法正常运行。因此，可以将NameNode配置为支持维护FsImage和EditLog的多个副本。FsImage或EditLog的任何更新都会导致FsImages和EditLogs中的每个同步更新。FsImage和EditLog的多个副本的这种同步更新可能会降低NameNode可以支持的每秒命名空间事务处理的速度。但是，这种降级是可以接受的，因为即使HDFS应用程序本质上是数据密集型的，但它们也不是元数据密集型的。当NameNode重新启动时，它将选择要使用的最新一致的FsImage和EditLog。
增强抗故障能力的另一种方法是使用多个NameNode来启用高可用性，这些NameNode可以在NFS上使用共享存储，也可以使用分布式编辑日志（称为Journal）。推荐使用后者。
快照
快照支持在特定时间存储数据副本。快照功能的一种用法可能是将损坏的HDFS实例回滚到以前已知的良好时间点。
数据组织
数据块
HDFS旨在支持非常大的文件。与HDFS兼容的应用程序是处理大型数据集的应用程序。这些应用程序仅写入一次数据，但读取一次或多次，并要求以流速度满足这些读取要求。HDFS支持文件上一次写入多次读取的语义。 HDFS使用的典型块大小为128 MB。因此，HDFS文件被切成128 MB的块，并且如果可能的话，每个块将驻留在不同的DataNode上。
复制管道
当客户端将数据写入复制因子为3的HDFS文件时，NameNode使用复制目标选择算法检索DataNode列表。该列表包含将托管该块副本的DataNode。该列表包含将托管该块副本的DataNode。然后，客户端会写入第一个DataNode。第一个DataNode开始分批接收数据，将每个部分写入其本地存储库，然后将该部分传输到列表中的第二个DataNode。第二个DataNode依次开始接收数据块的每个部分，将该部分写入其存储库，然后将该部分刷新到第三个DataNode。最后，第三个DataNode将数据写入其本地存储库。因此，DataNode可以从流水线中的前一个接收数据，同时将数据转发到流水线中的下一个。因此，数据从一个DataNode流水到下一个。
辅助功能
可以通过许多不同的方式从应用程序访问HDFS。HDFS本身就为应用程序提供了FileSystem Java API。也提供此REST API和REST API的C语言包装器。此外，HTTP浏览器还可以用于浏览HDFS实例的文件。通过使用NFS网关，HDFS可以作为在本地文件系统中已安装的客户端的一部分。
FS脚本
HDFS允许以文件和目录的形式组织用户数据。它提供了一个称为FS shell的命令行界面，该界面可让用户与HDFS中的数据进行交互。该命令集的语法类似于用户已经熟悉的其他的shell脚本（例如bash，csh）。以下是一些示例操作/命令对：
| 执行动作 | 命令 |
|---|---|
| 创建一个名为/ foodir的目录 | bin/hadoop dfs -mkdir /foodir |
| 删除名为/ foodir的目录 | bin/hadoop fs -rm -R /foodir |
| 查看名为/foodir/myfile.txt的文件的内容 | bin/hadoop dfs -cat /foodir/myfile.txt |
FS Shell适用于需要脚本语言与存储的数据进行交互的应用程序。
DFSAdmin
DFSAdmin命令集用于管理HDFS群集。这些是仅由HDFS管理员使用的命令。以下是一些示例操作/命令对：
| 执行动作 | 命令 |
|---|---|
| 将群集置于安全模式 | bin/hdfs dfsadmin -safemode enter |
| 生成数据节点列表 | bin/hdfs dfsadmin -report |
| 重新启用或停用DataNode | bin/hdfs dfsadmin -refreshNodes |
浏览器界面
典型的HDFS安装会将Web服务器配置为通过可配置的TCP端口公开HDFS命名空间。这允许用户使用Web浏览器浏览HDFS命名空间并查看其文件的内容。
空间的填充
文件删除和取消删除
如果启用垃圾箱配置，则不会立即从HDFS中删除由FS Shell删除的文件。HDFS将其移至废纸directory目录（每个用户在/user/‘username’/.Trash下都有自己的废纸directory目录）。只要文件保留在垃圾桶中，就可以快速恢复。
最近删除的文件被移动到当前的回收站目录（/user/‘username’/.Trash/Current），在一个可配置的时间间隔内，HDFS为当前垃圾目录中的文件创建检查点（在/user/‘username’/.Trash/'date’下），并在过期时删除旧的检查点。有关垃圾的检查点，请参见FS shell的expunge命令。
在垃圾桶中到期后，NameNode将从HDFS命名空间中删除该文件。文件的删除导致与文件关联的块被释放。请注意，在用户删除文件的时间与HDFS中相应的可用空间增加的时间之间可能会有明显的时间延迟。
下面是一个示例，它将显示FS Shell如何从HDFS删除文件。我们在目录delete下创建了2个文件（test1和test2）：
$ hadoop fs -mkdir -p delete/test1
$ hadoop fs -mkdir -p delete/test2
$ hadoop fs -ls delete/
Found 2 items
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 delete/test1
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:40 delete/test2
我们将删除文件test1。下面的注释显示文件已移至“废纸directory”目录。
$ hadoop fs -rm -r delete/test1
Moved: hdfs://localhost:8020/user/hadoop/delete/test1 to trash at: hdfs://localhost:8020/user/hadoop/.Trash/Current
现在我们要使用skipTrash选项删除文件，该选项不会将文件发送到Trash。它将从HDFS中完全删除。
$ hadoop fs -rm -r -skipTrash delete/test2
Deleted delete/test2
现在我们可以看到“废纸contains”目录仅包含文件test1。
$ hadoop fs -ls .Trash/Current/user/hadoop/delete/
Found 1 items\
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 .Trash/Current/user/hadoop/delete/test1
因此，文件test1进入垃圾箱，文件test2被永久删除。
减少副本因子
当减少文件的复制因子时，NameNode选择可以删除的多余副本。下一个心跳将此信息传输到DataNode。然后，DataNode删除相应的块，并且相应的可用空间出现在群集中。同样，在setReplication API调用完成与群集中的可用空间出现之间可能会有时间延迟。
270
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
