当前位置：首页 > 行业动态 > 正文

hdfs的存储方式

HDFS采用块存储，将大文件拆分为固定大小的数据块（默认128MB），分散存储于集群节点，每块默认3副本，通过NameNode管理元数据，DataNode存储数据，保障高容错与可靠性

HDFS（Hadoop Distributed File System）是大数据领域广泛使用的分布式存储系统，其存储方式以高可靠性、可扩展性和高效处理大规模数据为核心目标，以下从架构设计、数据分块、副本机制、元数据管理、读写流程等多个维度详细解析HDFS的存储方式。

HDFS架构与存储角色

HDFS采用主从架构，核心组件包括NameNode和DataNode,两者协同实现存储功能。

组件 功能 数据存储
NameNode 管理文件系统元数据（如文件目录结构、块位置信息），协调客户端与DataNode交互 不存储实际数据，仅维护元数据
DataNode 存储实际数据块，执行NameNode指令（如创建/删除块、复制数据），定期发送心跳和块报告 存储数据块（默认128MB/块）

架构特点：

  • NameNode是单点故障源，可通过Active/Standby模式（HA集群）或Secondary NameNode（非高可用方案）缓解。
  • DataNode通过心跳机制向NameNode汇报状态,块报告包含存储的块列表及健康状态。

数据分块存储机制

HDFS将文件拆分为固定大小的块（Block），默认128MB，支持配置，分块存储的核心优势包括：

  1. 数据分布均匀：大文件被切分为多个块，分散存储到不同节点，避免单点负载过高。
  2. 并行处理：MapReduce任务可直接针对块进行计算，提升数据处理效率。
  3. 容错性：单个块损坏仅需修复对应副本,不影响全局数据可用性。

分块逻辑示例：

  • 文件A（500MB）被分为4个块：Block1（0-127MB）、Block2（128-255MB）、Block3（256-383MB）、Block4（384-499MB），剩余15MB空间浪费。
  • 文件B（10MB）占用单个块，浪费118MB空间,体现HDFS对小文件不友好的特性。

副本存储策略

HDFS通过副本机制保证数据可靠性，默认每个块存储3个副本，副本分布遵循以下规则：

策略 说明
第一个副本 随机选择第一个DataNode（通常为客户端本地节点）
第二个副本 放置在与第一个副本不同的机架（Rack）中的节点
第三个副本 放置在与第二个副本相同机架但不同节点
机架感知（Rack Awareness） NameNode根据网络拓扑优化副本分布，减少跨机架流量

副本分布示例：

hdfs的存储方式 第1张

  • 假设集群包含两个机架（RackA和RackB），DataNode分布如下：
    • RackA：Node1, Node2
    • RackB：Node3, Node4
  • 文件F的Block1副本可能分布在：Node1（RackA）、Node3（RackB）、Node2（RackA）。

副本作用：

  • 提供数据冗余，防止节点或机架故障导致数据丢失。
  • 支持并发读取（客户端可选择最近副本读取，降低延迟）。

元数据管理

NameNode维护文件系统的元数据，包括：

  • 文件目录结构：类似传统文件系统，支持层级路径（如/user/data/file.txt）。
  • 块映射表：记录每个文件对应的块列表及块所在的DataNode地址。
  • 文件属性：权限、所有者、修改时间等。

元数据存储：

  • 元数据存储在NameNode内存中，并通过EditLog（事务日志）持久化到磁盘。
  • Secondary NameNode定期合并EditLog与元数据快照,减轻NameNode启动时的加载压力。

数据写入流程

客户端写入HDFS的流程如下：

  1. 文件切分：客户端将文件按块大小切分为多个Block。
  2. 请求分配副本：向NameNode申请存储块的DataNode列表（基于副本策略）。
  3. 流水线复制：
    • 客户端将Block的第一个副本写入第一个DataNode。
    • 第一个DataNode将数据转发给第二个DataNode，第二个转发给第三个，形成流水线。
    • 所有副本写入成功后，NameNode记录块信息,客户端收到成功响应。

流程示意图： 

客户端 → Block1 → DataNode1 → DataNode2 → DataNode3

数据读取流程

客户端读取HDFS的流程如下：

  1. 查询元数据：客户端向NameNode请求文件的块位置信息。
  2. 就近读取：NameNode返回距离客户端最近的副本所在DataNode地址。
  3. 直接获取数据：客户端直接从DataNode读取数据，无需经过NameNode中转。

优化点：

  • 数据本地性：优先读取本机或同机架内副本，减少网络传输。
  • 校验和验证：读取时校验数据完整性（如CRC校验）,防止损坏数据被使用。

故障恢复与数据一致性

HDFS通过以下机制保障数据可靠性：

  1. 心跳与块报告：
    • DataNode每3秒发送心跳，证明自身存活。
    • 每6小时发送块报告，同步元数据状态。
  2. 副本自动重建：

    当NameNode检测到某个块的副本数低于设定值（如3个），会触发副本重建流程。

  3. 数据一致性模型：
    • 写操作遵循“一次写入，多次读取”（Write-Once, Read-Many），写入完成后立即可见。
    • 最终一致性：客户端读取可能短暂滞后于最新写入（需等待副本同步）。

存储效率与局限性

HDFS的存储设计适用于大文件场景，但对小文件存在明显缺陷：
| 场景 | 优势 | 局限性 |
|—————-|———————————–|————————————-|
| 大文件存储 | 分块均匀分布，并行处理效率高 | |
| 小文件存储 | 每个文件占用一个块，元数据压力大 | 块浪费严重，NameNode内存消耗高 |

优化方案：

  • 文件合并：通过工具（如Hadoop Archive）将小文件合并为大文件。
  • 分层存储：结合Alluxio等内存级缓存处理小文件访问。

安全性与权限管理

HDFS支持类Unix的文件权限模型：

  • 三明治权限模型：用户、组、其他用户的读/写/执行权限。
  • ACL（访问控制列表）：细化权限控制，支持用户/组的额外权限设置。
  • 认证与加密：
    • 通过Kerberos实现身份认证，防止未授权访问。
    • 使用SSL/TLS加密客户端与NameNode/DataNode的通信。

与其他分布式文件系统的对比

特性 HDFS Ceph/GlusterFS
架构 主从式（NameNode单点） 无中心节点，对等式架构
副本策略 固定副本数，机架感知 动态副本，支持EC纠删码
小文件支持 较差 较好（通过对象存储优化）
扩展性 横向扩展（需增加NameNode HA） 线性扩展，无单点瓶颈

FAQs

Q1：为什么HDFS默认块大小是128MB？

A1：

  • 减少NameNode负载：大块减少文件数量，降低元数据管理压力。
  • 优化吞吐量：大块更适合连续读写，减少网络开销和寻道时间。
  • 匹配MapReduce任务：单个任务处理一个块,128MB可平衡任务粒度与资源利用率。

Q2：HDFS副本数为什么默认是3？

A2：

  • 容错性：3个副本可容忍单个节点或机架故障（如两个副本在同一机架，一个在另一机架）。
  • 读写性能平衡：更多副本可提升读取并发能力，但会增加存储成本和写入延迟。
  • 可配置性：实际部署中可根据硬件可靠性调整副本数（如EC纠
0

相关文章