HDFS_distcp断点续传-CSDN博客

本文链接：https://blog.csdn.net/qq_35180983/article/details/82734027

HDFS是Hadoop的核心组件，采用分而治之的策略存储超大文件，提供高容错、高可靠性和高吞吐率。尽管HDFS适合大数据批处理，但存在低延迟访问、小文件存储和并发写入等问题。为解决这些问题，可以采用缓存、多Master设计和小文件归档等方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、HDFS前言

设计思想：

分而治之：将大文件、大批量文件，分布式存放在大量服务器上，以便于采取分而治之的方式对海量数据进行运算分析

在大数据系统中作用：

为各类分布式运算框架（如：mapreduce，spark，tez，……）提供数据存储服务

二、HDFS介绍

HDFS（Hadoop Distributed File System）是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集（Large Data Set）的应用处理带来了很多便利。

首先，它是一个文件系统，用于存储文件，通过统一的命名空间——目录树来定位文件

其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色(namenode 、datanode 、secondarynamenode)；

重要特性如下：

HDFS中的文件在物理上是分块存储（block），块的大小可以通过配置参数( dfs.blocksize)来规定，默认大小在hadoop2.x版本中是128M，老版本中是64M
HDFS文件系统会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件，形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data
目录结构及文件分块位置信息(元数据)的管理由namenode节点承担，----namenode是HDFS集群主节点，负责维护整个hdfs文件系统的目录树，以及每一个路径（文件）所对应的block块信息（block的id，及所在的datanode服务器）
文件的各个block的存储管理由datanode节点承担---- datanode是HDFS集群从节点，每一个block都可以在多个datanode上存储多个副本（副本数量也可以通过参数设置dfs.replication）
HDFS是设计成适应一次写入，多次读出的场景，且不支持文件的修改

(注：适合用来做数据分析，并不适合用来做网盘应用，因为，不便修改，延迟大，网络开销大，成本太高)

HDFS优点

1.高容错性

数据自动保存多个副本。它通过增加副本的形式，提高容错性
某一个副本丢失以后，它可以自动恢复

2.适合批处理

它是通过移动计算而不是移动数据
它会把数据位置暴露给计算框架。

3.适合处理大数据

处理数据达到 GB、TB、甚至PB级别的数据。
能够处理百万规模以上的文件数量，数量相当之大。
能够处理10K节点的规模

4.流式文件访问

一次写入，多次读取。文件一旦写入不能修改，只能追加（这是算缺点吗）。
它能保证数据的一致性（通过校验机制）

5.可构建在廉价机器上

它通过多副本机制，提高可靠性。
它提供了容错和恢复机制。比如某一个副本丢失，可以通过其它副本来恢复。

HDFS 缺点

1.低延时数据访问

比如毫秒级的来存储数据，这是不行的，它做不到。
它适合高吞吐率的场景，就是在某一时间内写入大量的数据。但是它在低延时的情况下是不行的，比如毫秒级以内读取数据，这样它是很难做到的。

HDFS是单Master的，所有的对文件的请求都要经过它，当请求多时，肯定会有延时。

2.小文件存储

存储大量小文件的话，它会占用 NameNode大量的内存来存储文件、目录和块信息（元信息）。这样是不可取的，因为NameNode的内存总是有限的。
小文件存储的寻道时间会超过读取时间，它违反了HDFS的设计目标。

3、并发写入、文件随机修改

一个文件只能有一个写，不允许多个线程同时写。
仅支持数据 append（追加），不支持文件的随机修改。

三、针对HDFS缺点可能的改进措施

高延迟问题：

使用缓存或多master设计可以降低client的数据请求压力，以减少延时。

存储小文件问题：

1、利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。对于这种方法，如果想找回原来的小文件内容，那就必须得知道与归档文件的映射关系。

2、横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。

3、多Master设计，正在研发中的GFS II也要改为分布式多Master设计，还支持Master的Failover，而且Block大小改为1M，有意要调优处理小文件。（Alibaba DFS的设计，也是多Master设计，它把Metadata的映射存储和管理分开了，由多个Metadata存储节点和一个查询Master节点组成。）