1、创建一个HDFS目录

命令：hdfs dfs -mkdir -p /usr/local/hadoop/data/txtdir

截图：

2、本地文件上传到HDFS

本地创建文件a.txt,b.txt,c.txt上传到HDFS /usr/local/hadoop/data/txtdir

命令：echo “I am student” > a.txt

一、读文件

HDFS有一个文件系统实例，客户端通过调用这个实例的open()方法就可以打开系统中希望读取的文件。

HDFS通过RPC调用NameNode获取文件块的位置信息，对于文件的每一个块，NameNode会返回该块副本DataNode的节点地址。

另外，客户端还会根据网络拓扑来确定它与每一个DataNode的位置信息，从离它最近的那个DataNode获取数据块的副本，最理想的情况是数据块就储存在客户端所在的节点上。

具体过程：

![image-20191216155358635](/assets/images/hdfs-read-file.png)

（1）客户端发起请求

（2）客户端与NameNode得到文件的块及位置信息列表

（3）客户端直接和DataNode交互读取数据

（4）读取完成关闭连接

这样设计的巧妙之处有：

（1）在运行MapReduce任务时，每个客户端就是一个DataNode节点。

（2）NameNode 仅需要相应块的位置信息请求，否则随着客户端的增加，NameNode会很快成为瓶颈。

Hadoop的网络拓扑。在海量数据处理过程中，主要限制因素时节点之间的带宽。衡量两个节点之间的带宽往往很难实现，在这里Hadoop采取了一个简单的方法，它把网络拓扑看成一棵树，两个节点的距离等于他们到最近共同祖先距离的综合，而树的层次可以这么划分：

a、同一个节点中的进程

b、同一机架上的不同节点

c、同一数据中心不同机架

d、不同数据中心的节点

本文权威指南读书笔记

一、HDFS的设计前提和目标

（1）存储大文件：HDFS支持GB级别大小的文件；

（2）流式数据访问：保证高吞吐量

（3）容错性：完善的冗余备份机制；

（4）简单的一致性模型：一次写入多次读取；

（5）移动计算优于移动数据：HDFS使应用计算移动到离他最近数据位置的接口；

（6）兼容各种硬件和软件平台。

HDFS不适合的场景：

（1）大量小文件：文件的元数据存储在NameNode内容中，大量小文件意味着元数据增加，会占用大量内存；

（2）低延迟数据访问：HDFS是专门针对吞吐量而不是用户低延迟；

（3）多用户写入：导致一致性维护困难。