大数据开发之HDFS介绍
一.HDFS 简介
当数据集超过一个单独的物理计算机的存储能力时，便有必要将它分布到多个独立的计算机。管理着跨计算机网络存储的文件系统称为分布式文件系统 。因为它们是基于网络的，所有网络编程的复杂性都会随之而来，所以分布式文件系统比普通磁盘文件系统更复杂 。举例来说，使这个文件系统能容忍节点故障而不损失数据就是 一个极大的挑战 。
Hadoop有一个被称为HDFS的分布式系统，全称为Hadoop Distributed File system 。（有时可能简称为 HDFS ，在非正式情况或是文档和配置中 ，其实是一样 的。）
1.1 HDFS 的设计
HDFS 是为以流式数据访问模式存储超大文件而设计的文件系统 ，在商用硬件的集群上运行 。
-
超大文件
“ 超大文件” 在这里指几百 MB ，几百 GB 甚至几百 TB 大小的文件。目前已 经有 H adoop 集群存储 PB(petabytes）级的数据了。 -
流式数据库访问
HDFS 建立在这样一个思想上: 一次写入、多次读取筷式是最高效的 。一个数据集通常由数据源生成或复制，接着在此基础上进行各种各样的分析。每个分析至少都会捞及数据集中的大部分数据 （甚至全部） ，因此读取整个数据集的时间比读取第一条记录的延迟更为重要 。 -
商用硬件
Hadoop不需要运行在昂贵并且高可靠性的硬件上 。它被设计运行在商用硬件（在各种零售店都能买到的普通硬件）的集群上 ，因此至少对于大的集群来说，节点故障的几率还是较高的 。HDFS 在面对这种故障时，被设计为能够继续运 行而让用户察觉不到明显的中断。
同时，那些并不适合HDFS 的应用也是值得研究的 。
目前 ，HDFS 还不太适用于 某些领域 ，不过日后可能会有所改进。
-
低延迟数据访问
需要低延迟访问数据在毫秒范围内 的应用并不适合 HDFS。HDFS 是为达到高数据吞吐量而优化的，这有可能会以延迟为代价 。目前，对于低延迟访问 ，HBase是更好的选择 。 -
大量的小文件
名称节点（namenode）存储着文件系统的元数据，因此文件数量的限制也由名称节点的内存量决定 。根据经验，每个文件，索引 目录以及块占大约 150 个字 节 。因此，举例来说 ，如果有一百万个文件，每个文件占一个块，就至少需要 300 MB 的内存 。虽然存储上百万的文件是可行的，十亿或更多的文件就超出目前硬件的能力了。
3)多用户写人，任意修改文件
HDFS 中的文件只有一个写入者 ，而且写操作总是在文件的末尾 。它不支持多个写入者，或是在文件的任意位置修改 。（可能在以后这些会被支持 ，但它们也相对不那么高效）
1.2 HDFS的概念
1.2.1 块
一个磁盘有它的块大小 ，代表着它能够读写的最小数据量 。文件系统通过处理大小为一个磁盘块大小的整数倍数的数据块来运作这个磁盘 。文件系统块一般为几千字节，而磁盘块一般为512个字节。这些信息，对于仅仅在一个文件上读或写任意长度的文件系统用户来说是透明的 。但是，有些工具会维护文件系统，如df 和fsck , 它们都在系统块级上操作 。
HDFS 也有块的概念 ，不过是更大的单元，默认为64 MB(CDH 6.3版本默认已经公司128MB)。与单一磁盘上的文件系统相似，HDFS上的文件也被分为以块为大小的分块，作为单独的单元存储。但与其不同的是，HDFS中小子一个块大小的文件不会占据整个块的空间。
为何 HDFS 中的一个块那么大？
HDFS 的块比磁盘的块大，目的是为了减小寻址开销，通过让一个块足够 大，从磁盘转移数据的时可能够远远大于定位这个块开始端的时间．因此， 传送一个由多个块组成的文件的时间就取决于磁盘传输送率。
我们来做一个速算，如果寻址时间在10毫秒左右 ，传输速率是100 兆／秒， 为了使寻址时间为传输时间的1%，我们需要100MB左右的块大小。而默认的大小 实际为64MB，尽管很多HDFS设置使用128MB的块，这一数字将在以后随着新 一代磁盘驱动带来的传输速度加快而继续调整。
当然这种假定不应该如此夸张. MapReduce过程中的map任务通常是在一个时间内运行操作一个块，因此如果任务数过于 少（少 于某群上的节点数量）， 作业的运行速度显然就比预期的慢 ．
在分布式文件系统中使用抽象块会带来很多好处 。第一个最明显的好处是，一个文件可以大于网络中任意一个磁盘的容量 。文件的分块（block ，后文有些地方也简称 为 “ 块” ）不需要存储在同一个磁盘上 ，因此它们可以利用集群上的任意一个磁盘 。其实，虽然不常见，但对于HDFS 集群而言 ，也可以存储一个其分块占满集群中所有磁盘的文件 。
第二个好处是，使用块抽象单元而不是文件会简化存储子系统 。简单化是所有系统的追求，但对于故障种类繁多的分布式系统来说尤为重要的。存储子系统控制的是块 ，简化了存储管理 。（因为块的大小固定，计算一个磁盘能存多少块就相对容易），也悄除了对元数据的顾虑（块只是一部分存储的数据一而文件的元数据 ，如许可信息，不需要与块一同存储，这样一来 ，其他系统就可以正交地管理元数据 。）
不仅如此，块很适合子为提供容错和实用性而做的复制操作。为了应对损坏的块以及磁盘或机器的故障，每个块都在少数其他分散的机器（一般为 3 个）进行复制 。如果一个块损坏了，系统会在其他地方读取另一个副本，而这个过程是对用户透明的。一个因损坏或机器故障而丢失的块会从其他候选地点复制到正常运行的机器上，以保证副本的数量回到正常水平。同样，有些应用程序可能选择为热门的文件块设置更高的副本数量以提高集群的读取负载量。
与磁盘文件系统相似，HDFS中 fsck 指令会显示块的信息 。例如，执行以下命令将 列出文件系统中组成各个文件的块
1.2.2 名称节点与数据节点
HDFS 集群有两种节点 ，以管理者工作者的模式运行 ，即一个名称节点（管理者）和 多个数据节点（工作者）。名称节点管理文件系统的命名空间。它维护着这个文件系统树及这个树内所有的文件和索引目录。这些信息以两种形式将文件永久保存在本地磁盘上：命名空间镜像和编辑日志。名称节点也记录着每个文件的每个块所在的数据节 点，但它并不永久保存块的位置，因为这些信息会在系统启动时由数据节点重建 。客户端代表用户通过与名称节点和数据节点交互采访问整个文件系统 。客户端提供一个类似 POSIX（可移植操作系统界面）的文件系统接口 ，因此用户在编程时并不需要知道名称节点和数据节点及其功能 。
数据节点是文件系统的工作者 。它们存储并提供定位块的服务（被用户或名称节点调用时），并且定时的向名称节点发送它们存储的块的列表 。
没有名称节点 ，文件系统将无法使用。事实上，如果运行名称节点的机器被毁坏了，文件系统上所有的文件都会丢失，因为我们无法知道如何通过数据节点上的块来重建文件 。因此，名称节点能够经受故障是非常重要的，Hadoop 提供了两种 制来确保这一点。
第一种机制就是复制那些组成文件系统元数据持久状态的文件 。Hadoop 可以通过配置使名称节点、在多个文件系统上写入其持久化状态 。这些写操作是具同步性和原子性的。一般的配置选择是，在本地磁撞上写入的同时 ，写入一个 远程 NFS 挂载 (mount）。
另一种可行的方格是运行一个二级名称节点 ，虽然它不能作为名称节点使用 。这个二级名称节点的重要作用就是定期的通过编辑日志合并命名空间镜像，以防止编辑日志过大。这个二级名称节点一般在其他单独的物理计算机上运行 ，因为它也需要占用大量CPU和内存来执行合并操作 。它会保存合并后的命名空间镜像的副本 ， 在名称节点失效后就可以使用 。但是，二级名称节点的状态是比主节点滞后的，所以主节点的数据若全部丢失 ，损失仍在所难免 。在这种情况下，一般把存在NFS上的主名称节点元数据复制到二级名称节点上并将其作为新的主名称节点运行 。
1.3 命令行接口
现在我们将通过命令行与 HDFS 交互 。HDFS 还有很多其他接口 ，但命令行是最简 单的 ，同时也是许多开发者最熟悉的。
1.3.1 本地文件与HDFS交互
将本地/tmp/test.txt 传到 HDFS的/user/hive/warehouse 目录
代码:
hadoop fs -copyFromLocal /tmp/test.txt /user/hive/warehouse
hadoop fs -ls /user/hive/warehouse
测试记录:
[root@hp1 tmp]# more test.txt
1,'abc'
2,'def'
[root@hp1 tmp]#
[root@hp1 tmp]#
[root@hp1 tmp]# hadoop fs -copyFromLocal /tmp/test.txt /user/hive/warehouse
[root@hp1 tmp]#
[root@hp1 tmp]# hadoop fs -ls /user/hive/warehouse
Found 2 items
drwxrwxrwt - root hive 0 2020-11-25 10:48 /user/hive/warehouse/test.db
-rw-rw-rw- 3 root hive 16 2020-11-25 14:53 /user/hive/warehouse/test.txt
[root@hp1 tmp]#
将 HDFS上的 /user/hive/warehouse/test.txt 传到 /tmp目录，并改名
代码:
hadoop fs -copyToLocal /user/hive/warehouse/test.txt /tmp/test_copy.txt
测试记录:
[root@hp1 tmp]# hadoop fs -copyToLocal /user/hive/warehouse/test.txt /tmp/test_copy.txt
[root@hp1 tmp]#
[root@hp1 tmp]# more /tmp/test_copy.txt
1,'abc'
2,'def'
[root@hp1 tmp]#
二.HDFS 管理
2.1 安全模式
名称节点启动时 ，它所做的第一件事情是加载其镜像文件（fsimage）到内存 ，并应用 编辑日志（edits）中的编辑记录。一旦重新创建与文件系统元数据 一致的内存映像 ， 它就会创建一个新的 fsimage 文件（自 己创建一个检查点而不是求助于第 二名称节 点，这样的效率更高）和一个空的编辑日志。只有在这个时候 ，名称节点才开始监 听 RPC 和 HTTP 请求 。如果名称节点以安全模式运行 ，则意味着 它只向客户端提 供文件系统的只读视图。
回想一下 ，系统中的块的存储位置并不是由名称节点来保存的一一此信息以块列表的形式储存在数据节点中 。执行系统常规操作期间 ，名称节点在内存中储存块地址 的分布。在安全模式下，需要给数据节点一些时间来登入名称节点及其块列表，使名称节点能有足够多的块地址来高效运行文件系统。如果名称节点没有等到足够多的数据节点，则会启动程序 ，开始复制块到新的数据节点，在大多数情况下，都不需要如此（因为它只需要等更多数据节点整入），并且这将造成集群资源非常的紧张。 事实上 ，在安全模式下 ，名称节点并不为数据节点发出 任何块复制或者删除的指令。
到达最小副本条件后 ，再过30 秒，系统便退出安全模式。最小副本条件是指在整个文 件系统中 99.9%的块达到最低复制水平（默认是 1，由dfs .replication.min 设定）。
启动一个新格式化的HDFS 集群时，因为系统中没有数据块，所以名称节点不会 进入安全模式 。
查看是否处于保护模式:
[root@hp4 subdir0]# hadoop dfsadmin -safemode get
WARNING: Use of this script to execute dfsadmin is deprecated.
WARNING: Attempting to execute replacement "hdfs dfsadmin" instead.
Safe mode is OFF in hp1/10.31.1.123:8020
Safe mode is OFF in hp2/10.31.1.124:8020
进入和离开保护模式:
-- 进入安全模式
sudo -u hdfs hadoop dfsadmin -safemode enter
-- 退出安全模式
sudo -u hdfs hadoop dfsadmin -safemode leave
测试记录:
[root@hp1 ~]# sudo -u hdfs hadoop dfsadmin -safemode enter
WARNING: Use of this script to execute dfsadmin is deprecated.
WARNING: Attempting to execute replacement "hdfs dfsadmin" instead.
Safe mode is ON in hp1/10.31.1.123:8020
Safe mode is ON in hp2/10.31.1.124:8020
[root@hp1 ~]#
[root@hp1 ~]# sudo -u hdfs hadoop dfsadmin -safemode leave
WARNING: Use of this script to execute dfsadmin is deprecated.
WARNING: Attempting to execute replacement "hdfs dfsadmin" instead.
Safe mode is OFF in hp1/10.31.1.123:8020
Safe mode is OFF in hp2/10.31.1.124:8020
2.2 工具
2.2.1 dfsadmin工具
dfsadmin 工具是一个查询 HDFS 状态信息的多功能工具 ，能在HDFS 上执行管理 员的操作。可以使用 hadoop dfsadmin 调用其功能。
命令介绍:
hdfs dfsadmin [GENERIC_OPTIONS]
[-report [-live] [-dead] [-decommissioning]] #报告基本的文件系统信息和统计信息，包括测量所有dns上的复制、校验和、快照等使用的原始空间。
[-safemode enter | leave | get | wait | forceExit] #安全模式维护命令
#安全模式在namenode启动时自动进入，当配置的最小块百分比满足最小复制条件时自动离开安全模式。如果namenode检测到任何异常，
#则它将在安全模式下逗留，直到该问题得到解决。如果异常是故意操作的结果，那么管理员可以使用-safemode forceExit退出安全模式
[-saveNamespace] #将当前命名空间保存到存储目录并重置编辑日志。需要安全模式
[-rollEdits] #在活动的namenode上滚动编辑日志
[-restoreFailedStorage true |false |check] #此选项将打开或者关闭自动尝试还原失败的存储副本。如果失败的存储再次可用，
#系统将在检查点期间尝试还原编辑和fsimage。“check”选项将返回当前设置
[-refreshNodes] #重新读取主机并排除文件，以更新允许连接到namenode的数据节点集，以及应解除或重新启用的数据节点集
[-setQuota <quota> <dirname>...<dirname>]
[-clrQuota <dirname>...<dirname>]
[-setSpaceQuota <quota> [-storageType <storagetype>] <dirname>...<dirname>]
[-clrSpaceQuota [-storageType <storagetype>] <dirname>...<dirname>]
[-finalizeUpgrade] #完成hdfs的升级。datanodes删除它们以前版本的工作目录，然后namenode执行相同的操作。这就完成了升级过程
[-rollingUpgrade [<query> |<prepare> |<finalize>]]
[-metasave filename] #将namenode的主数据结构保存到hadoop.log.dir属性指定的目录中的filename。如果文件名存在，它将被覆盖。
#该文件包含带namenode的datanodes心跳，等待复制的块，当前正在复制的块，等待删除的块
[-refreshServiceAcl] #重新加载服务级别授权策略文件
[-refreshUserToGroupsMappings] #刷新用户到组的映射
[-refreshSuperUserGroupsConfiguration] #刷新超级用户代理组映射
[-refreshCallQueue] #从配置重新加载调用队列
[-refresh <host:ipc_port> <key> [arg1..argn]] #触发由<host:ipc port>上的<key>指定的资源的运行时刷新。之后的所有其他参数都将发送到主机
[-reconfig <datanode |...> <host:ipc_port> <start |status>] #开始重新配置或获取正在进行的重新配置的状态。第二个参数指定节点类型。目前，只支持重新加载datanode的配置
[-printTopology] #打印由namenode报告的机架及其节点的树
[-refreshNamenodes datanodehost:port] #对于给定的数据节点，重新加载配置文件，停止为已删除的块池提供服务，并开始为新的块池提供服务
[-deleteBlockPool datanode-host:port blockpoolId [force]] #如果传递了force，则将删除给定数据节点上给定block pool id的块池目录及其内容，否则仅当该目录为空时才删除该目录。
#如果datanode仍在为块池提供服务，则该命令将失败
[-setBalancerBandwidth <bandwidth in bytes per second>] #更改HDFS块平衡期间每个数据节点使用的网络带宽。<bandwidth>是每个数据节点每秒将使用的最大字节数。
#此值重写dfs.balance.bandwidthpersec参数。注意：新值在datanode上不是持久的
[-getBalancerBandwidth <datanode_host:ipc_port>] #获取给定数据节点的网络带宽（字节/秒）。这是数据节点在hdfs块平衡期间使用的最大网络带宽
[-allowSnapshot <snapshotDir>] #设置快照目录
[-disallowSnapshot <snapshotDir>] #禁止快照
[-fetchImage <local directory>] #从namenode下载最新的fsimage并将其保存在指定的本地目录中
[-shutdownDatanode <datanode_host:ipc_port> [upgrade]] #提交给定数据节点的关闭请求
[-getDatanodeInfo <datanode_host:ipc_port>] #获取有关给定数据节点的信息
[-evictWriters <datanode_host:ipc_port>] #使datanode收回正在写入块的所有客户端。如果由于编写速度慢而挂起退役，这将非常有用
[-triggerBlockReport [-incremental] <datanode_host:ipc_port>] #触发给定数据节点的块报告。如果指定了“增量”，则为“增量”，否则为完整的块报告
[-help [cmd]]
2.2.2 文件系统检查(fsck)
Hadoop 提供一个 fsck 工具来检查 HDFS 中文件的健康情况。该工具将查找所有据节点中丢失的块和副本不足或者副本过多的块 。
fsck递归走查文件系统的命名空间，从指定的路径开始（这里是文件系统的 root) , 然后检查它找到的文件 。它为每个检查的文件打上一个小圆点 。为了检查文件， fsck 会检索文件块的元数据 ．并查找有问题或者不一致的地方 。注意，fsck 检索名 称节点中色的所有信息，它并没有与任何数据节点通信来实际检索任何数据块 。
fsck 的大部分输出都很直观 ，但它查找的下面这些条件需要解释一下。
1） 过量复制块
指数量超过其所属文件目标副本数。过量复制并不常见 ，HDFS会自动删除多余的副本。
2） 复制不足块
指数量不足其所属文件目标副本数 。HDFS 会自动创建少量新的副本直到摘足 目标副本数 。可以使用 hadoop dfsadmin -metasave 得到正在复制（或等待复 制）的块的信息。
3） 复制错误的块
指不满足块副本放 置规则。例如 ，对于一个在多个机架 的集群中的三级副本 ， 如果三个块的副本全都在同一个机架上 ，那么这个块就是复制错误的块，因为 副本应该分布在至少两个机架上以 保证其可恢复 。
命令介绍:
hdfs fsck <path>
[-list-corruptfileblocks |
[-move | -delete | -openforwrite]
[-files [-blocks [-locations | -racks | -replicaDetails]]]
[-includeSnapshots]
[-storagepolicies] [-blockId <blk_Id>]
-delete 删除损坏的文件
-files 打印正在检查的文件.
-files -blocks 打印块报告
-files -blocks -locations Print out locations for every block.
-files -blocks -racks 打印每个块的位置
-files -blocks -replicaDetails 打印出每个副本的详细信息.
-includeSnapshots 如果给定路径指示SnapshotTable目录或其下有SnapshotTable目录，则包括快照数据
-list-corruptfileblocks 打印出所属丢失块和文件的列表.
-move 将损坏的文件移动到/lost+found.
-openforwrite 打印为写入而打开的文件.
-storagepolicies 打印块的存储策略摘要.
-blockId 打印出有关块的信息.
代码:
sudo -u hdfs hadoop fsck /
测试记录:
可以看到如CDH管理控制台提示的一样，我的文件系统有损坏
FSCK started by hdfs (auth:SIMPLE) from /10.31.1.123 for path / at Wed Nov 25 17:05:03 CST 2020
/user/oozie/share/lib/lib_20201115122055/distcp/hadoop-distcp.jar: MISSING 1 blocks of total size 4038448 B.
/user/oozie/share/lib/lib_20201115122055/distcp/netty-all-4.1.17.Final.jar: MISSING 1 blocks of total size 3780056 B.
/user/oozie/share/lib/lib_20201115122055/distcp/oozie-sharelib-distcp-5.1.0-cdh6.3.1.jar: MISSING 1 blocks of total size 12759 B.
/user/oozie/share/lib/lib_20201115122055/distcp/oozie-sharelib-distcp.jar: MISSING 1 blocks of total size 12759 B.
/user/oozie/share/lib/lib_20201115122055/git/HikariCP-2.6.1.jar: MISSING 1 blocks of total size 133942 B.
/user/oozie/share/lib/lib_20201115122055/git/HikariCP-java7-2.4.12.jar: MISSING 1 blocks of total size 134308 B.
/user/oozie/share/lib/lib_20201115122055/git/JavaEWAH-1.1.6.jar: MISSING 1 blocks of total size 165868 B.
**中间省略N行记录**
/user/oozie/share/lib/lib_20201115122055/sqoop/zookeeper.jar: MISSING 1 blocks of total size 1543701 B.
Status: CORRUPT
Number of data-nodes: 4
Number of racks: 1
Total dirs: 2243
Total symlinks: 0
Replicated Blocks:
Total size: 97305134279 B
Total files: 3546
Total blocks (validated): 4238 (avg. block size 22960154 B)
********************************
UNDER MIN REPL'D BLOCKS: 1814 (42.803207 %)
dfs.namenode.replication.min: 1
CORRUPT FILES: 1814
MISSING BLOCKS: 1814
MISSING SIZE: 1519384904 B
********************************
Minimally replicated blocks: 2424 (57.196793 %)
Over-replicated blocks: 0 (0.0 %)
Under-replicated blocks: 0 (0.0 %)
Mis-replicated blocks: 0 (0.0 %)
Default replication factor: 3
Average block replication: 1.7159038
Missing blocks: 1814
Corrupt blocks: 0
Missing replicas: 0 (0.0 %)
Blocks queued for replication: 0
Erasure Coded Block Groups:
Total size: 0 B
Total files: 0
Total block groups (validated): 0
Minimally erasure-coded block groups: 0
Over-erasure-coded block groups: 0
Under-erasure-coded block groups: 0
Unsatisfactory placement block groups: 0
Average block group size: 0.0
Missing block groups: 0
Corrupt block groups: 0
Missing internal blocks: 0
Blocks queued for replication: 0
FSCK ended at Wed Nov 25 17:05:03 CST 2020 in 81 milliseconds
The filesystem under path '/' is CORRUPT
[root@hp1 ~]#
参考
1.Hadoop权威指南
2.https://www.cnblogs.com/zsql/p/11580704.html
