Hadoop生态圈（三）- HDFS（分布式文件系统）

木鬼与槐

已于 2024-08-28 15:25:55 修改

阅读量956

点赞数 24

分类专栏： # Hadoop生态圈大数据文章标签： hadoop hdfs 大数据

于 2024-08-28 15:25:18 首次发布

本文链接：https://blog.csdn.net/weixin_58305115/article/details/141634292

版权

Hadoop生态圈同时被 2 个专栏收录

7 篇文章 0 订阅

订阅专栏

大数据

4 篇文章 0 订阅

订阅专栏

HDFS解决的是海量存储的问题

设计目标：

故障是常态，因此故障的检测和自动快速恢复是核心
适合批量处理，注重数据访问的高吞吐量。一旦写入不需要修改
支持大文件
文件一旦创建、写入、关闭之后就不需要修改
移动计算的代价比移动数据的代价低
可移植性强。其他软件平台或异构硬件

特性：

NameNode负责管理整个文件系统元数据；DataNode负责管理具体文件数据块存储；Secondary NameNode协助NameNode进行元数据的备份。
HDFS即是一个文件系统又是分布式。
主从架构（一个namenode和多个datanode），Namenode是HDFS集群主节点，Datanode是HDFS集群从节点，两种角色各司其职，共同协调完成分布式的文件存储服务。
文件是以128M块（block）存储，以64K的数据包传送。hadoop 1.X是64M
我们把目录结构及文件分块位置信息叫做元数据。元数据是关于数据的信息，包括文件名、文件大小、文件权限等。Namenode通过创建元数据本地存储目录和一些初始化的元数据相关文件来管理和维护这些信息。
datanode需要定时向namenode汇报自己的block信息时间间隔默认为6小时，会定期发送心跳，默认为3秒。
副本数量也可以通过参数设置dfs.replication，默认是3。
namenode是集群的单点故障，坏了就不可运行

HDFS基本原理

NameNode概述

NameNode是HDFS的核心。
NameNode也称为Master。
NameNode仅存储HDFS的元数据：文件系统中所有文件的目录树，并跟踪整个集群中的文件。
NameNode不存储实际数据或数据集。数据本身实际存储在DataNodes中。
NameNode知道HDFS中任何给定文件的块列表及其位置。使用此信息NameNode知道如何从块中构建文件。
NameNode并不持久化存储每个文件中各个块所在的DataNode的位置信息，这些信息会在系统启动时从数据节点重建。
NameNode对于HDFS至关重要，当NameNode关闭时，HDFS / Hadoop集群无法访问。
NameNode是Hadoop集群中的单点故障。
NameNode所在机器通常会配置有大量内存（RAM）。

DataNode概述

DataNode负责将实际数据存储在HDFS中。
DataNode也称为Slave。
NameNode和DataNode会保持不断通信。
DataNode启动时，它将自己发布到NameNode并汇报自己负责持有的块列表。
当某个DataNode关闭时，它不会影响数据或群集的可用性。NameNode将安排由其他DataNode管理的块进行副本复制。
DataNode所在机器通常配置有大量的硬盘空间。因为实际数据存储在DataNode中。
DataNode会定期（dfs.heartbeat.interval配置项配置，默认是3秒）向NameNode发送心跳，如果NameNode长时间没有接受到DataNode发送的心跳， NameNode就会认为该DataNode失效。
block汇报时间间隔取参数dfs.blockreport.intervalMsec,参数未配置的话默认为6小时.

HDSF读写操作

HDFS写数据流程

首先客户端向namenode发送写数据的请求，namenode接收到请求，需要判断是否有权限和目标文件是否存在，返回客户端是否可以上传，
接着客户端会向namenode询问block传输到哪些datanode上，namenode根据副本机制（一般默认为3副本策略）、网络拓扑关系、机架感知原理来进行分配。
客户端请求第一台上传数据，第一台收到请求继续调用第二台，以此类推，形成一个管道，后逐级返回客户端。
此时客户端向第一台上传block块，以64k的包为单位，第一台传给第二台，以此类推
数据被分割成数据包在管道上依次传输，在反方向上，逐个发送ack校验，最终由第一个datanode将ack发送给客户端
当一个block块传输完毕后，客户端会再向namenode请求下一个block的存放位置，直到所有的块传输完毕。

HDFS读数据流程

客户端向namenode发送请求，确定block在datanode上的位置。
namenode接收到请求后会判断是否有读数据的权限，再根据情况来返回部分或者全部的block列表且返回datanode地址。
这些返回的datanode地址，会根据网络拓扑关系得出datanode和客户端的距离，然后进行排序。
客户端会选择靠前的datanode来读取数据，如果客户端本身就是datanode，那么将从本地直接来获取数据。
当读完数据列表后，若文件读取还没有结束，客户端会继续向namenode获取下一个block列表和datanode地址，直到所有数据读取完毕。
最后将读取的数据进行排序，形成最终文件。

HDFS元数据管理

内存元数据（内存）

元数据文件（磁盘）：fsimage-存放大文件、edits-存放最近的记录

checkpoint：当edits到一定程度，就会和fsimage一起被secondarynamenode合并为一个新的fsimage文件中。

fsimage文件其实是Hadoop文件系统元数据的一个永久性的检查点，其中包含Hadoop文件系统中的所有目录和文件idnode的序列化信息；

fsimage包含Hadoop文件系统中的所有目录和文件idnode的序列化信息；对于文件来说，包含的信息有修改时间、访问时间、块大小和组成一个文件块信息等；而对于目录来说，包含的信息主要有修改时间、访问控制权限等信息。

edits文件存放的是Hadoop文件系统的所有更新操作的路径，文件系统客户端执行的所以写操作首先会被记录到edits文件中。

NameNode起来之后，HDFS中的更新操作会重新写到edits文件中，因为fsimage文件一般都很大（GB级别的很常见），如果所有的更新操作都往fsimage文件中添加，这样会导致系统运行的十分缓慢，但是如果往edits文件里面写就不会这样，每次执行写操作之后，且在向客户端发送成功代码之前，edits文件都需要同步更新。如果一个文件比较大，使得写操作需要向多台机器进行操作，只有当所有的写操作都执行完成之后，写操作才会返回成功，这样的好处是任何的操作都不会因为机器的故障而导致元数据的不同步。

HDFS shell

-ls:hadoop fs -ls /user/hadoop/file1 (这是查看hdfs的文件信息，是http://node1:9870那个页面上的目录）
-mkdir：hadoop fs -mkdir –p /user/hadoop/dir1
-put：hadoop fs -put -f localfile1 localfile2 /user/hadoop/hadoopdir （单个src或多个srcs从本地文件系统复制到目标文件系统hdfs上。）
1. -p：保留访问和修改时间，所有权和权限。
2. -f：覆盖目的地（如果已经存在）
-get：hadoop fs -get hdfs://host:port/user/hadoop/file localfile（将hdfs上的文件下载到本地）
-appendToFile：hadoop fs -appendToFile localfile /hadoop/hadoopfile （追加一个文件到已经存在的文件末尾）
-cat ：hadoop fs -cat /hadoop/hadoopfile （显示hdfs上某文件的内容）
-getmerge ：hadoop fs -getmerge /aaa/log.* ./log.sum（将目录下的多个文件合并）
-chmod、-chown、-cp、-mv、-rm