HDFS 深度解析大数据存储的硬盘不够、单盘坏了怎么办做大数据的人绕不开 HDFS。你的数据量上了 PB 级单机硬盘装不下硬盘总会坏数据丢了怎么办HDFS 就是 Google GFS 的开源实现专门解决这两个问题存储不够加机器硬盘坏了多副本。HDFS 解决的两个核心问题问题1硬盘不够用单机硬盘容量有限比如一块 20TB但数据量可能是 PB 级。解决方案分布式存储——多台机器组成集群数据分散存到各个节点上。机器不够就加机器理论上无限扩展。问题2硬盘坏了数据丢单机硬盘会坏坏了数据就没了。解决方案多副本——每个数据块默认存 3 份分别放到不同的机器上。一台机器挂了数据还在。这就是 HDFS 的核心理念用廉价硬件的集群解决海量数据的可靠存储问题。HDFS 核心架构主从协同的三层模型HDFS 是典型的 Master-Slave 架构四个角色各司其职角色管什么特点NameNode管账本元数据一个集群只有一个存内存里DataNode管货实际数据每个节点一个存磁盘上Secondary NameNode帮 NameNode 合并账本不是备份是助手Client用户入口读写文件的接口1. 元数据交互2. 数据读写2. 数据读写2. 数据读写3. 心跳/块报告3. 心跳/块报告3. 心跳/块报告4. 元数据合并存储数据存储数据存储数据Client客户端NameNode主节点 元数据管理DataNode1DataNode2DataNode3Secondary NameNode辅助节点本地磁盘Block 副本核心分工 NameNode 管元数据,DataNode 存数据,Client 直接读写数据节点一句话总结NameNode 管什么东西存在哪DataNode 管东西本身Secondary NameNode 帮 NameNode 整理账本。NameNode存的是账本不是货NameNode 是 HDFS 的大脑但它不存实际数据只存元数据——文件在哪个目录、权限是什么、分成了几个块、每个块在哪些 DataNode 上。元数据存在哪两个文件FsImage某一时刻的元数据快照静态账本EditLog操作日志动态流水账记录每次文件操作启动的时候NameNode 把 FsImage 读到内存然后把 EditLog 里的操作重新执行一遍生成最新的元数据。NameNode 的瓶颈在哪所有元数据都在内存里。所以 HDFS 能存多少个文件取决于 NameNode 的内存大小。每个文件/目录的元数据大约占 150 字节如果内存是 128GB理论上限大约是 8 亿个文件——但实际远到不了这个数。小文件问题是真实存在的每个小文件都占一条元数据条目还意味着大量的 Map 任务开销。能合并就合并。DataNode存的是货货在磁盘上DataNode 是真正存数据的节点实际数据以 Block 为单位存在磁盘上。Block 大小默认 128MB大 Block 适合大文件减少寻址开销提升吞吐小于 Block 的文件不会占满整个 Block比如 1MB 文件只占 1MBDataNode 定期向 NameNode 汇报心跳Heartbeat默认每 3 秒一次告诉 NameNode “我还活着”块报告Block Report默认每 6 小时一次告诉 NameNode “我手里有哪些 Block”心跳停了NameNode 就把这个节点标记为死了然后把上面的 Block 在其他节点上补副本。Secondary NameNode不是备份是助手这个命名容易误导人。Secondary NameNode不是 NameNode 的热备不能直接接管 NameNode 的工作。它的职责是定期帮 NameNode 合并 FsImage 和 EditLog避免 EditLog 无限膨胀。合并流程Secondary NameNode 从 NameNode 拉取 FsImage 和 EditLog在本地加载 FsImage重放 EditLog 的操作生成新的 FsImage把新的 FsImage 传回 NameNode替换旧的如果 NameNode 挂了怎么办先用 Secondary NameNode 上的 FsImage 恢复元数据但会丢失一部分最新的操作EditLog 中尚未合并的部分。这只能算部分恢复不能完全替代 NameNode。客户端读写流程读文件Client 向 NameNode 请求文件位置 → NameNode 返回 Block 列表及所在 DataNodeClient 直接连 DataNode 读数据不经过 NameNode写文件Client 把文件拆成 Block向 NameNode 请求第一个 Block 的写入位置NameNode 返回一组 DataNode用于存放副本Client 以 pipeline 方式把数据依次发给第一个 DataNode第一个再发给第二个依次类推写完确认后向 NameNode 汇报元数据更新关键点NameNode 不参与数据传输只负责协调位置。数据直接走 Client ↔ DataNode 通道。HDFS 关键机制确保高可用与高效读写副本策略3 份副本怎么放默认 3 份副本分布策略如下第一份放在客户端所在节点如果客户端不在集群内随机选一个第二份放在与第一份不同机架的节点第三份放在与第二份同机架但不同节点为什么要跨机架一个机架的交换机坏了整个机架的节点都断连。如果 3 个副本都在同一个机架数据全丢。跨机架存储保证了即使单机架故障数据仍然可用。安全模式NameNode 启动时的保护期NameNode 启动时会进入安全模式Safe Mode此时只读不接收写请求NameNode 等待 DataNode 上报块报告检查每个 Block 的副本数是否达标当达标比例超过 99.9%且持续一段时间自动退出安全模式如果集群刚启动时某个机架没上线副本数不够安全模式会一直卡住。这时候可以手动hdfs dfsadmin -safemode leave强制退出但要确认数据完整性没问题。小文件处理优化 NameNode 内存占用过多小文件会消耗 NameNode 内存并降低处理效率解决方案包括合并小文件通过hadoop fs -getmerge将多个小文件合并为大文件使用 SequenceFile/ORC/Parquet将小文件打包成列式存储格式减少元数据量限制小文件数量在数据采集阶段如 Flume配置文件滚动策略避免生成过多小文件。HDFS 常见操作命令与最佳实践常用命令示例# 创建目录hdfs dfs-mkdir/user/hadoop/test# 上传本地文件到 HDFShdfs dfs-putlocalfile.txt /user/hadoop/test/# 下载 HDFS 文件到本地hdfs dfs-get/user/hadoop/test/localfile.txt ./# 查看文件内容hdfs dfs-cat/user/hadoop/test/localfile.txt# 删除文件hdfs dfs-rm/user/hadoop/test/localfile.txt# 查看目录下文件信息包括块大小、副本数hdfs dfs-ls-h/user/hadoop/test
HDFS 深度解析大数据存储的硬盘不够、单盘坏了怎么办做大数据的人绕不开 HDFS。你的数据量上了 PB 级单机硬盘装不下硬盘总会坏数据丢了怎么办HDFS 就是 Google GFS 的开源实现专门解决这两个问题存储不够加机器硬盘坏了多副本。HDFS 解决的两个核心问题问题1硬盘不够用单机硬盘容量有限比如一块 20TB但数据量可能是 PB 级。解决方案分布式存储——多台机器组成集群数据分散存到各个节点上。机器不够就加机器理论上无限扩展。问题2硬盘坏了数据丢单机硬盘会坏坏了数据就没了。解决方案多副本——每个数据块默认存 3 份分别放到不同的机器上。一台机器挂了数据还在。这就是 HDFS 的核心理念用廉价硬件的集群解决海量数据的可靠存储问题。HDFS 核心架构主从协同的三层模型HDFS 是典型的 Master-Slave 架构四个角色各司其职角色管什么特点NameNode管账本元数据一个集群只有一个存内存里DataNode管货实际数据每个节点一个存磁盘上Secondary NameNode帮 NameNode 合并账本不是备份是助手Client用户入口读写文件的接口1. 元数据交互2. 数据读写2. 数据读写2. 数据读写3. 心跳/块报告3. 心跳/块报告3. 心跳/块报告4. 元数据合并存储数据存储数据存储数据Client客户端NameNode主节点 元数据管理DataNode1DataNode2DataNode3Secondary NameNode辅助节点本地磁盘Block 副本核心分工 NameNode 管元数据,DataNode 存数据,Client 直接读写数据节点一句话总结NameNode 管什么东西存在哪DataNode 管东西本身Secondary NameNode 帮 NameNode 整理账本。NameNode存的是账本不是货NameNode 是 HDFS 的大脑但它不存实际数据只存元数据——文件在哪个目录、权限是什么、分成了几个块、每个块在哪些 DataNode 上。元数据存在哪两个文件FsImage某一时刻的元数据快照静态账本EditLog操作日志动态流水账记录每次文件操作启动的时候NameNode 把 FsImage 读到内存然后把 EditLog 里的操作重新执行一遍生成最新的元数据。NameNode 的瓶颈在哪所有元数据都在内存里。所以 HDFS 能存多少个文件取决于 NameNode 的内存大小。每个文件/目录的元数据大约占 150 字节如果内存是 128GB理论上限大约是 8 亿个文件——但实际远到不了这个数。小文件问题是真实存在的每个小文件都占一条元数据条目还意味着大量的 Map 任务开销。能合并就合并。DataNode存的是货货在磁盘上DataNode 是真正存数据的节点实际数据以 Block 为单位存在磁盘上。Block 大小默认 128MB大 Block 适合大文件减少寻址开销提升吞吐小于 Block 的文件不会占满整个 Block比如 1MB 文件只占 1MBDataNode 定期向 NameNode 汇报心跳Heartbeat默认每 3 秒一次告诉 NameNode “我还活着”块报告Block Report默认每 6 小时一次告诉 NameNode “我手里有哪些 Block”心跳停了NameNode 就把这个节点标记为死了然后把上面的 Block 在其他节点上补副本。Secondary NameNode不是备份是助手这个命名容易误导人。Secondary NameNode不是 NameNode 的热备不能直接接管 NameNode 的工作。它的职责是定期帮 NameNode 合并 FsImage 和 EditLog避免 EditLog 无限膨胀。合并流程Secondary NameNode 从 NameNode 拉取 FsImage 和 EditLog在本地加载 FsImage重放 EditLog 的操作生成新的 FsImage把新的 FsImage 传回 NameNode替换旧的如果 NameNode 挂了怎么办先用 Secondary NameNode 上的 FsImage 恢复元数据但会丢失一部分最新的操作EditLog 中尚未合并的部分。这只能算部分恢复不能完全替代 NameNode。客户端读写流程读文件Client 向 NameNode 请求文件位置 → NameNode 返回 Block 列表及所在 DataNodeClient 直接连 DataNode 读数据不经过 NameNode写文件Client 把文件拆成 Block向 NameNode 请求第一个 Block 的写入位置NameNode 返回一组 DataNode用于存放副本Client 以 pipeline 方式把数据依次发给第一个 DataNode第一个再发给第二个依次类推写完确认后向 NameNode 汇报元数据更新关键点NameNode 不参与数据传输只负责协调位置。数据直接走 Client ↔ DataNode 通道。HDFS 关键机制确保高可用与高效读写副本策略3 份副本怎么放默认 3 份副本分布策略如下第一份放在客户端所在节点如果客户端不在集群内随机选一个第二份放在与第一份不同机架的节点第三份放在与第二份同机架但不同节点为什么要跨机架一个机架的交换机坏了整个机架的节点都断连。如果 3 个副本都在同一个机架数据全丢。跨机架存储保证了即使单机架故障数据仍然可用。安全模式NameNode 启动时的保护期NameNode 启动时会进入安全模式Safe Mode此时只读不接收写请求NameNode 等待 DataNode 上报块报告检查每个 Block 的副本数是否达标当达标比例超过 99.9%且持续一段时间自动退出安全模式如果集群刚启动时某个机架没上线副本数不够安全模式会一直卡住。这时候可以手动hdfs dfsadmin -safemode leave强制退出但要确认数据完整性没问题。小文件处理优化 NameNode 内存占用过多小文件会消耗 NameNode 内存并降低处理效率解决方案包括合并小文件通过hadoop fs -getmerge将多个小文件合并为大文件使用 SequenceFile/ORC/Parquet将小文件打包成列式存储格式减少元数据量限制小文件数量在数据采集阶段如 Flume配置文件滚动策略避免生成过多小文件。HDFS 常见操作命令与最佳实践常用命令示例# 创建目录hdfs dfs-mkdir/user/hadoop/test# 上传本地文件到 HDFShdfs dfs-putlocalfile.txt /user/hadoop/test/# 下载 HDFS 文件到本地hdfs dfs-get/user/hadoop/test/localfile.txt ./# 查看文件内容hdfs dfs-cat/user/hadoop/test/localfile.txt# 删除文件hdfs dfs-rm/user/hadoop/test/localfile.txt# 查看目录下文件信息包括块大小、副本数hdfs dfs-ls-h/user/hadoop/test
