HDFS是Hadoop应用程序使用的主要分布式存储。 HDFS集群主要由管理文件系统元数据的NameNode和存储实际数据的DataNode组成。 “HDFS体系结构指南”详细介绍了HDFS。HDFS体系结构图描述了NameNode，DataNode和客户端之间的基本交互。 客户联系NameNode文件元数据或文件修改，并直接与DataNode执行实际的文件I / O。
以下是许多用户可能感兴趣的一些显着特性。
- Hadoop，包括HDFS，非常适合使用商品硬件的分布式存储和分布式处理。 它具有容错性，可扩展性，并且非常易于扩展。 MapReduce以其简单和适用于大型分布式应用程序而闻名，是Hadoop不可分割的一部分。
- HDFS具有高度可配置性，其默认配置非常适合许多安装。 大多数情况下，配置只能针对非常大的群集进行调整。
- Hadoop是用Java编写的，并且在所有主要平台上都受支持。
- Hadoop支持shell-like命令直接与HDFS交互。
- NameNode和Datanodes内置了Web服务器，可以轻松检查集群的当前状态。
- HDFS中定期实施新功能和改进。 以下是HDFS中有用功能的一个子集：
- 文件权限和身份验证。
- 机架感知：在调度任务和分配存储时考虑节点的物理位置。
- 安全模式：维护的管理模式。
- fsck ：诊断文件系统健康的实用程序，用于查找丢失的文件或块。
- fetchdt ：用于获取DelegationToken并将其存储在本地系统文件中的实用程序。
- 平衡器：当数据在数据节点之间分布不均匀时，平衡集群的工具。
- 升级和回滚：软件升级后，升级前可以回滚到HDFS状态，以防出现意外问题。
- Secondary NameNode：执行命名空间的定期检查点，并有助于将包含HDFS修改日志的文件的大小保持在NameNode的一定范围内。
- 检查点节点：执行命名空间的定期检查点，并帮助最小化存储在包含对HDFS的更改的NameNode中的日志的大小。 替换之前由Secondary NameNode填充的角色。 NameNode同时允许多个Checkpoint节点，只要没有备份节点注册到系统。
- 备份节点：对检查点节点的扩展。 除了检查点之外，它还接收来自NameNode的编辑流，并维护其自己的内存拷贝，该拷贝始终与活动的NameNode命名空间状态同步。 一次只能向NameNode注册一个备份节点。
Web界面
NameNode和DataNode各自运行一个内部Web服务器，以显示有关集群当前状态的基本信息。 使用默认配置，NameNode首页位于http//namenode-name:50070/ 。 它列出了集群中的DataNode和集群的基本统计信息。Web界面也可用于浏览文件系统（使用NameNode首页上的“浏览文件系统”链接）。
Shell命令
Hadoop包括各种类似shell的命令，可直接与HDFS和Hadoop支持的其他文件系统进行交互。 命令bin/hdfs dfs -help列出了Hadoop shell支持的命令。 此外，命令bin/hdfs dfs -help命令名显示更详细的命令帮助。 这些命令支持大多数正常的文件系统操作，如复制文件，更改文件权限等。它还支持一些HDFS特定的操作，如更改文件的复制。
DFSAdmin命令
bin/hdfs dfsadmin命令支持一些HDFS管理相关的操作。 bin/hdfs dfsadmin -help命令列出当前支持的所有命令。 例如：
- -report ：报告HDFS的基本统计信息。 NameNode首页上也提供了这些信息中的一部分。
- -safemode：虽然通常不需要，可以手动进入或离开安全模式。
- -finalizeUpgrade ：删除上次升级过程中创建的集群的先前备份。
- -refreshNodes ：使用允许连接到namenode的一组datanodes更新namenode。 默认情况下，Namenodes重新读取由dfs.hosts ， dfs.hosts.exclude定义的文件中的数据 节点主机名dfs.hosts中定义的主机是属于集群一部分的数据节点 。 如果dfs.hosts中有条目， 则只允许其中的主机注册namenode。 dfs.hosts.exclude中的条目是需要停用的datanode。 或者，如果dfs.namenode.hosts.provider.classname设置为org.apache.hadoop.hdfs.server.blockmanagement.CombinedHostFileManager ，则在由dfs.hosts定义的JSON文件中指定所有包含和排除主机。 当Datanodes中的所有副本都复制到其他Datanode时，Datanodes完成停用。 退役的节点不会自动关闭，也不会选择写入新副本。
- -printTopology ：打印群集的拓扑。 显示由NameNode附加的机架和datanode树。
次要名称节点
NameNode将对文件系统的修改存储为附加到本地文件系统文件的日志，进行编辑。 当NameNode启动时，它从图像文件fsimage读取HDFS状态，然后应用来自edits日志文件的日志。然后将新的HDFS状态写入fsimage，并使用空的edits文件开始正常操作。 由于NameNode仅在启动期间合并fsimage和edits文件，因此在繁忙的群集上，edits日志文件可能会随着时间的推移变得非常大。 更大的edits文件的另一个副作用是下一次重新启动NameNode需要更长的时间。
辅助NameNode定期合并fsimage和编辑日志文件，并将编辑日志大小保持在限制范围内。 它通常在与主NameNode不同的机器上运行，它的内存要求与主NameNode的顺序相同。
辅助NameNode上检查点进程的启动由两个配置参数控制。
- dfs.namenode.checkpoint.period ，默认设置为1小时，指定两个连续检查点之间的最大延迟
- dfs.namenode.checkpoint.txns ，默认设置为1百万，在NameNode中定义了未被检查的事务的数量，这将强制紧急的检查点，即使还没有达到检查点周期。
辅助NameNode将最新的检查点存储在与主NameNode的目录结构相同的目录中。 这样检查指向的图像总是可以被主NameNode读取（如果需要的话）。
检查点节点
NameNode使用两个文件来保存它的命名空间：fsimage，它是命名空间和edits日志的最新检查点，是自检查点以来对命名空间进行更改的日志（日志）。 当NameNode启动时，它将合并fsimage和edits日志以提供文件系统元数据的最新视图。 NameNode然后用新的HDFS状态覆盖fsimage并开始一个新的edits日志。
检查点节点定期创建名称空间的检查点。 它从活动的NameNode下载fsimage和edits日志，在本地合并它们，并将新的image上传回活动的NameNode。 检查点节点通常运行在与NameNode不同的机器上，因为它的内存需求与NameNode的顺序相同。 检查点节点由配置文件中指定的节点上的bin/hdfs namenode -checkpoint启动。
检查点（或备份）节点及其相应的Web界面的位置通过dfs.namenode.backup.address和dfs.namenode.backup.http-address配置变量进行配置。
检查点节点上检查点进程的启动由两个配置参数控制。
- dfs.namenode.checkpoint.period ，默认设置为1小时，指定两个连续检查点之间的最大延迟
- dfs.namenode.checkpoint.txns ，默认设置为1百万，在NameNode中定义了未被检查的事务的数量，这将强制紧急的检查点，即使还没有达到检查点周期。
Checkpoint节点将最新的检查点存储在与NameNode的目录结构相同的目录中。 这允许检查点映像在必要时总是可用于由NameNode读取。
可以在集群配置文件中指定多个检查点节点。
备份节点
备份节点提供与检查点节点相同的检查点功能，以及维护始终与活动的NameNode状态同步的内存中最新的文件系统名称空间副本。 除了接受来自NameNode的文件系统编辑的日志流并将其保存到磁盘之外，备份节点还将这些编辑应用到它自己的内存中的名称空间的副本，从而创建名称空间的备份。
备份节点不需要从活动的NameNode下载fsimage和编辑文件，以创建一个检查点，就像Checkpoint节点或Secondary NameNode所要求的那样，因为它已经具有最新的命名空间状态在记忆中。 备份节点检查点进程效率更高，因为它只需要将名称空间保存到本地fsimage文件并重置编辑。
由于“备份”节点在内存中维护名称空间的副本，因此其RAM要求与NameNode相同。
NameNode一次支持一个备份节点。 如果正在使用“备份”节点，则不会注册任何检查点节点。 同时使用多个备份节点将在未来支持。
备份节点的配置方式与检查点节点相同。 它以bin/hdfs namenode -backup开始 。
备份（或检查点）节点及其相应的Web界面的位置通过dfs.namenode.backup.address和dfs.namenode.backup.http-address配置变量进行配置。
使用“备份”节点提供了运行NameNode而不使用持久性存储的选项，将所有责任用于将名称空间的状态保留到备份节点。 为此，使用-importCheckpoint选项启动NameNode，同时指定NameNode配置中没有类型为edits dfs.namenode.edits.dir的持久存储目录。
导入检查点
如果图像和编辑文件的所有其他副本都丢失，则可以将最新检查点导入到NameNode。 为了做到这一点，应该：
- 创建一个在dfs.namenode.name.dir配置变量中指定的空目录;
- 指定检查点目录在配置变量dfs.namenode.checkpoint.dir中的位置 ;
- 并使用-importCheckpoint选项启动NameNode。
NameNode将从dfs.namenode.checkpoint.dir目录中上传检查点，然后将其保存到dfs.namenode.name.dir中设置的NameNode目录中。 如果 legal image包含在dfs.namenode.name.dir中，则NameNode将启动失败。 NameNode验证dfs.namenode.checkpoint.dir中的 image是否一致，但不以任何方式进行修改。
平衡器
HDFS数据可能并不总是被统一放置在DataNode中。 一个常见的原因是将新的DataNode添加到现有集群。 在放置新块（文件的数据存储为一系列块）时，NameNode在选择DataNode接收这些块之前会考虑各种参数。一些考虑因素是：
- 保留与正在写入块的节点位于同一节点上的块的副本之一的策略。
- 需要在机架上传播一个块的不同复制品，以便群集可以在整个机架丢失的情况下生存下来。
- 其中一个副本通常放在与写入文件的节点相同的机架上，以减少跨机架网络I / O。
- 将HDFS数据统一分布在集群中的DataNode上。
由于多种竞争的考虑，数据可能不会统一放置在DataNodes中。 HDFS为管理员提供了一个工具，用于分析整个数据节点上的数据块放置和回溯数据。
安全模式
在启动期间，NameNode从fsimage和edits日志文件中加载文件系统状态。 然后等待DataNode报告它们的块，以便它不会过早地开始复制块，尽管集群中已经存在足够的副本。 在此期间，NameNode保持安全模式。NameNode的安全模式本质上是HDFS群集的只读模式，在这种模式下，它不允许对文件系统或块进行任何修改。 通常情况下，NameNode会在DataNodes报告大多数文件系统块可用后自动离开Safemode。 如果需要，可以使用bin/hdfs dfsadmin -safemode命令显式地将HDFS置于安全模式 。 NameNode首页显示Safemode是打开还是关闭。
fsck
HDFS支持fsck命令来检查各种不一致。它设计用于报告各种文件的问题，例如，文件块丢失或块复制不足。 与传统的本地文件系统的fsck实用程序不同，此命令不会更正它检测到的错误。 通常NameNode会自动纠正大部分可恢复的故障。 默认情况下，fsck忽略打开的文件，但提供了一个选项来选择报告过程中的所有文件。HDFS fsck命令不是Hadoop shell命令。 它可以作为bin/hdfs fsck运行。fsck可以在整个文件系统或文件的一个子集上运行。
fetchdt
HDFS支持fetchdt命令来获取委托令牌并将其存储在本地系统的文件中。 此令牌稍后可用于从非安全客户端访问安全服务器（例如NameNode）。 实用程序使用RPC或HTTPS（通过Kerberos）获取令牌，因此需要kerberos票据才能运行（运行kinit获取票据）。 HDFS fetchdt命令不是Hadoop shell命令。 它可以作为bin/hdfs fetchdt DTfile运行 。 获得令牌之后，可以通过将HADOOP_TOKEN_FILE_LOCATION环境变量指向委托令牌文件来运行HDFS命令，而无需拥有Kerberos票据。
恢复模式
通常，配置多个元数据存储位置。 如果一个存储位置损坏，则可以从其他存储位置之一读取元数据。
但是，如果可用的唯一存储位置已损坏，该怎么办？ 在这种情况下，有一个称为恢复模式的NameNode特殊启动模式，可以恢复大部分数据。
像这样在恢复模式下启动NameNode： namenode -recover
在恢复模式下，NameNode将在命令行中交互式地提示采取哪些措施能够恢复数据。
如果不想被提示，可以给-force选项。 此选项将强制恢复模式始终选择第一个选项。这也是官方推荐的选择。
由于恢复模式可能会导致数据丢失，因此在使用之前应始终备份编辑日志和fsimage。
升级和回滚
在现有群集上升级Hadoop时，与任何软件升级一样，可能会出现新的错误或不兼容的更改，这些更改会影响现有的应用程序，并且不会提前发现。 在任何的HDFS安装中，都不能丢失任何数据，更不要说重装HDFS集群。 HDFS允许管理员回滚到早期版本，并将群集恢复到升级前的状态。HDFS一次只能有一个这样的备份。 在升级之前，管理员需要使用bin/hadoop dfsadmin -finalizeUpgrade命令删除现有的备份。 以下简要介绍典型的升级过程：
- 在升级Hadoop软件之前，请确定是否存在已有的备份。
- 停止集群并分发新版本的Hadoop。
- 使用-upgrade选项运行新版本（ bin/start-dfs.sh -upgrade ）。
- 大多数时候，群集工作得很好。 一旦新的HDFS被认为运行良好（可能在几天的运行后），最终确定升级。 请注意，在群集完成之前，删除升级之前存在的文件不会释放DataNode上的实际磁盘空间。
- 如果需要回到旧版本，
- 停止集群并分发早期版本的Hadoop。
- 在namenode（ bin/hdfs namenode -rollback ）上运行rollback命令。
- 使用回滚选项启动群集。 （ sbin/start-dfs.sh -rollback ）。
升级到HDFS的新版本时，需要重新命名或删除HDFS新版本中保留的路径。 如果NameNode在升级过程中遇到保留路径，则会显示如下所示的错误：
/.reserved是保留路径，.snapshot是此版本HDFS中的保留路径组件。 请回滚并删除或重命名此路径，或者使用-renameReserved [键值对]选项升级以在升级过程中自动重命名这些路径。
指定-upgrade -renameReserved [可选的键值对]使NameNode自动重命名在启动期间找到的任何保留路径。 例如，要将所有名为.snapshot的路径重命名为.my-snapshot，并将.reserved重命名为.my-reserved ，则指定-upgrade -renameReserved .snapshot = .my-snapshot，.reserved = .my-reserved 。
如果没有使用-renameReserved指定键值对，那么NameNode将后缀为.<LAYOUT-VERSION> .UPGRADE_RENAMED的保留路径，例如.snapshot.-51.UPGRADE_RENAMED 。
这个重命名过程有一些注意事项。 如果可能的话，建议在升级之前首先使用hdfs dfsadmin -saveNamespace 。 这是因为如果编辑日志操作引用自动重命名文件的目标，则可能会导致数据不一致。
DataNode热插拔驱动器
Datanode支持热插拔驱动器。 用户可以在不关闭DataNode的情况下添加或替换HDFS数据卷。 下面简要介绍典型的热插拔驱动程序：
- 如果有新的存储目录，用户应该格式化并适当地安装它们。
- 用户更新DataNode配置dfs.datanode.data.dir以反映将被主动使用的数据卷目录。
- 用户运行dfsadmin -reconfig datanode HOST:PORT start启动重新配置过程。 用户可以使用dfsadmin -reconfig datanode HOST:PORT状态查询重配置任务的运行状态。
- 重新配置任务完成后，用户可以安全地卸载已删除的数据卷目录并物理删除磁盘。
不适用于HDFS的场景：
1) 低延迟
HDFS不适用于实时查询这种对延迟要求高的场景，例如：股票实盘。往往应对低延迟数据访问场景需要通过数据库访问索引的方案来解决，Hadoop生态圈中的Hbase具有这种随机读、低延迟等特点。
2) 大量小文件
对于Hadoop系统，小文件通常定义为远小于HDFS的block size（默认64MB）的文件，由于每个文件都会产生各自的MetaData元数据，Hadoop通过Namenode来存储这些信息，若小文件过多，容易导致Namenode存储出现瓶颈。
3) 多用户更新
为了保证并发性，HDFS需要一次写入多次读取，目前不支持多用户写入，若要修改，也是通过追加的方式添加到文件的末尾处，出现太多文件需要更新的情况，Hadoop是不支持的。
针对有多人写入数据的场景，可以考虑采用Hbase的方案。
4) 结构化数据
HDFS适合存储半结构化和非结构化数据，若有严格的结构化数据存储场景，也可以考虑采用Hbase的方案。
5) 数据量并不大
通常Hadoop适用于TB、PB数据，若待处理的数据只有几十GB的话，不建议使用Hadoop，因为没有任何好处。
文章评论