hadoop2.2.0 HDFS没有文件,也无法创建文件夹

Posted 2023-04-11

安装了hadoop 2.2.0 ，jps显示启动了DataNode,SecondaryNameNode,NodeManager,NameNode,ResourceManager这五个进程
使用hadoop fs -ls /
等待一会后没有任何输出。就和按回车一个效果。
使用hadoop fs -mkdir /usr/admin
提示：mkdir: `/usr/admin': No such file or directory
使用dfs指令，显示用hdfs命令替换执行，同样没有任何输出。

参考技术A 把命令hadoop fs -mkdir 改成 hdfs dfs -mkdir 参考技术B 请截图jps打印结果，以及如上命令的执行结果本回答被提问者采纳

2021年大数据Hadoop：HDFS分布式文件系统简介

目录

HDFS分布式文件系统简介

一、HDFS概述

二、HDFS发展历史

三、HDFS设计目标

四、HDFS应用场景

适合的应用场景

不适合的应用场景

五、HDFS的架构

六、HDFS的副本机制

HDFS文件副本机制

HDFS副本放置策略（机架感知）

---

HDFS分布式文件系统简介

 

一、HDFS概述

在现代的企业环境中，单机容量往往无法存储大量数据，需要跨机器存储。统一管理分布在集群上的文件系统称为分布式文件系统 。

​ HDFS（Hadoop Distributed File System）是 Apache Hadoop 项目的一个子项目. Hadoop 非常适于存储大型数据 (比如 TB 和 PB), 其就是使用 HDFS 作为存储系统. HDFS 使用多台计算机存储文件, 并且提供统一的访问接口, 像是访问一个普通文件系统一样使用分布式文件系统.

   分布式文件系统解决的问题就是大数据存储。它们是横跨在多台计算机上的存储系统。分布式文件系统在大数据时代有着广泛的应用前景，它们为存储和处理超大规模数据提供所需的扩展能力。

 

二、HDFS发展历史

 

1. Doug Cutting 在做 Lucene 的时候, 需要编写一个爬虫服务, 这个爬虫写的并不顺利, 遇到 了一些问题, 诸如: 如何存储大规模的数据, 如何保证集群的可伸缩性, 如何动态容错等。
2. 2013年的时候, Google 发布了三篇论文, 被称作为三驾马车, 其中有一篇叫做 GFS, 是描述了 Google 内部的一个叫做 GFS 的分布式大规模文件系统, 具有强大的可伸缩性和容错。
3. Doug Cutting 后来根据 GFS 的论文, 创造了一个新的文件系统, 叫做 HDFS。

三、HDFS设计目标

1、硬件故障是常态， HDFS将有成百上千的服务器组成，每一个组成部分都有可能出现故障。因此故障的检测和自动快速恢复是HDFS的核心架构目标。

2、HDFS上的应用与一般的应用不同，HDFS被设计成适合批量处理，而不是用户交互式的。相较于数据访问的反应时间，更注重数据访问的高吞吐量。

3、典型的HDFS文件大小是GB到TB的级别。所以，HDFS被调整成支持大文件。它应该提供很高的聚合数据带宽，一个集群中支持数百个节点，一个集群中还应该支持千万级别的文件。

4、大部分HDFS应用对文件要求的是write-one-read-many访问模型。一个文件一旦创建、写入、关闭之后就不需要修改了。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。

5、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好。

6、在异构的硬件和软件平台上的可移植性。这将推动需要大数据集的应用更广泛地采用HDFS作为平台。

 

 

四、HDFS应用场景

适合的应用场景

• 存储非常大的文件：这里非常大指的是几百M、G、或者TB级别，需要高吞吐量，对延时没有要求。
• 采用流式的数据访问方式: 即一次写入、多次读取，数据集经常从数据源生成或者拷贝一次，然后在其上做很多分析工作 ，且不支持文件的随机修改。
• 正因为如此，HDFS适合用来做大数据分析的底层存储服务，并不适合用来做.网盘等应用，因为，修改不方便，延迟大，网络开销大，成本太高。
• 运行于商业硬件上: Hadoop不需要特别贵的机器，可运行于普通廉价机器，可以处节约成本
• 需要高容错性 
• 为数据存储提供所需的扩展能力

不适合的应用场景

• 低延时的数据访问 对延时要求在毫秒级别的应用，不适合采用HDFS。HDFS是为高吞吐数据传输设计的,因此可能牺牲延时
• 大量小文件 文件的元数据保存在NameNode的内存中， 整个文件系统的文件数量会受限于NameNode的内存大小。 经验而言，一个文件/目录/文件块一般占有150字节的元数据内存空间。如果有100万个文件，每个文件占用1个文件块，则需要大约300M的内存。因此十亿级别的文件数量在现有商用机器上难以支持。
• 多方读写，需要任意的文件修改 HDFS采用追加（append-only）的方式写入数据。不支持文件任意offset的修改，HDFS适合用来做大数据分析的底层存储服务，并不适合用来做.网盘等应用，因为，修改不方便，延迟大，网络开销大，成本太高。

 

五、HDFS的架构

HDFS采用Master/Slave架构，一个HDFS集群有两个重要的角色，分别是Namenode和Datanode。Namenode是管理节点，负责管理文件系统的命名空间(namespace)以及客户端对文件的访问。Datanode是实际存储数据的节点。HDFS暴露了文件系统的命名空间，用户能够以操作文件的形式在上面操作数据。

HDFS的四个基本组件:HDFS Client、NameNode、DataNode和Secondary NameNode。

 

 1、Client：就是客户端。

• 文件切分。文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储
• 与 NameNode 交互，获取文件的位置信息。
• 与 DataNode 交互，读取或者写入数据。
• Client 提供一些命令来管理 和访问HDFS，比如启动或者关闭HDFS。

2、NameNode：就是 master，它是一个主管、管理者。

• 管理 HDFS 的名称空间
• 管理数据块（Block）映射信息
• 配置副本策略
• 处理客户端读写请求。

3、DataNode：就是Slave。NameNode 下达命令，DataNode 执行实际的操作。

• 存储实际的数据块。
• 执行数据块的读/写操作。
• 定时向namenode汇报block信息

4、Secondary NameNode：并非 NameNode 的热备。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。

• 辅助 NameNode，分担其工作量。
• 定期合并 fsimage和fsedits，并推送给NameNode。
• 在紧急情况下，可辅助恢复 NameNode。

 

六、HDFS的副本机制

HDFS文件副本机制

HDFS被设计成能够在一个大集群中跨机器可靠地存储超大文件。它将每个文件存储成一系列的数据块，这个数据块被称为block，除了最后一个，所有的数据块都是同样大小的。

为了容错，文件的所有block都会有副本。每个文件的数据块大小和副本系数都是可配置的。

所有的文件都是以 block 块的方式存放在 HDFS 文件系统当中,作用如下

1、一个文件有可能大于集群中任意一个磁盘，引入块机制,可以很好的解决这个问题

2、使用块作为文件存储的逻辑单位可以简化存储子系统

3、块非常适合用于数据备份进而提供数据容错能力

4、副本优点是安全，缺点是占空间。

在 Hadoop1 当中, 文件的 block 块默认大小是 64M, hadoop2 当中, 文件的 block 块大小默认是 128M（134217728字节）。假设文件大小是100GB，从字节位置0开始，每128MB字节划分为一个block，依此类推，可以划分出很多的block。每个block就是128MB大小。

block块的大小可以通过 hdfs-site.xml 当中的配置文件进行指定，Hadoop默认的副本数为3,也就是每个block会存三份。

<property>

   <name>dfs.block.size</name>

   <value>块大小以字节为单位</value>

</property>

注意当一个文件的大小不足128M时，比如文件大小为2M，那么这个文件也占用一个block，但是这个block实际只占2M的空间，所以从某种意义上来讲，block只是一个逻辑单位。

 

 

HDFS副本放置策略（机架感知）

HDFS分布式文件系统的内部有一个副本存放策略，默认副本数为3,在这里以副本数=3为例：

第一副本：优先放置到离写入客户端最近的DataNode节点，如果上传节点就是DataNode，则直接上传到该节点，如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点。

第二个副本：放置在于第一个副本不同的机架的节点上（随机选择）

第三个副本：与第二个副本相同机架的不同节点中。