Hadoop面试题及详细答案 110题 （16-35）-- HDFS核心原理与操作

《前后端面试题》专栏集合了前后端各个知识模块的面试题，包括html，javascript，css，vue，react，java，Openlayers，leaflet，cesium，mapboxGL，threejs，nodejs，mangoDB，SQL，Linux… 。

前后端面试题-专栏总目录

一、本文面试题目录

16. 什么是HDFS？它的设计理念是什么？

• 定义：HDFS（Hadoop Distributed File System）是Hadoop生态系统中的分布式文件系统，专为大规模数据存储和处理设计，运行在廉价的 commodity 硬件上。
• 设计理念：
  • 海量数据存储：支持PB级甚至EB级数据存储，适合处理大规模数据集。
  • 流式数据访问：强调数据的批量处理（一次写入、多次读取），而非低延迟的随机读写，优化了吞吐量。
  • 容错性：通过副本机制（默认3个副本）应对硬件故障，确保数据可靠性。
  • 简单的一致性模型：假设文件一旦写入后很少修改，主要支持追加操作（早期版本不支持，后期逐步完善），降低了分布式协调的复杂度。
  • 硬件友好：可运行在普通服务器上，降低成本，同时通过软件层面的设计弥补硬件可靠性不足的问题。

17. HDFS的架构由哪些组件构成？各组件的作用是什么？

HDFS采用主从（Master-Slave）架构，主要组件包括：

• NameNode（主节点）：
  • 管理文件系统的元数据（如文件名、目录结构、文件权限、文件与块的映射关系等）。
  • 协调客户端对文件的访问，决定块的存储位置。
  • 记录DataNode的状态，负责维护副本策略。
• DataNode（从节点）：
  • 实际存储数据块（Block），并根据NameNode的指令进行块的创建、删除、复制。
  • 定期向NameNode发送心跳（Heartbeat）和块报告（Block Report），汇报自身状态和存储的块信息。
• Secondary NameNode：
  • 并非NameNode的备用节点，主要作用是辅助NameNode管理元数据，定期合并NameNode的编辑日志（EditLog）和镜像文件（FSImage），减轻NameNode的负担，在NameNode故障时可辅助恢复元数据（但不能直接替代NameNode）。
• Client（客户端）：
  • 提供用户与HDFS交互的接口，如文件读写、目录操作等。
  • 读写文件时，客户端先与NameNode交互获取元数据，再直接与DataNode进行数据传输。

18. NameNode和DataNode的职责分别是什么？

• NameNode的职责：
  • 管理元数据：维护文件系统的目录树、文件属性（权限、大小等）、文件与数据块的映射关系。
  • 控制访问：处理客户端的文件操作请求（如创建、删除、重命名文件），决定数据块的存储和复制策略。
  • 监控DataNode：接收DataNode的心跳信息（确认节点存活）和块报告（了解节点存储的块），若发现DataNode故障，触发副本复制以维持副本数量。
• DataNode的职责：
  • 存储数据：实际存储数据块（Block），并按NameNode的指令进行块的读写、创建、删除和复制。
  • 汇报状态：定期向NameNode发送心跳（默认每3秒一次），证明自身存活；每小时发送一次块报告，告知NameNode当前节点存储的所有块信息。
  • 块校验：对存储的块进行校验，确保数据未被损坏，若发现损坏则报告NameNode，由其安排重新复制。

19. 简述HDFS的读写流程。

读流程：

1. 客户端向NameNode发送读文件请求，指定文件路径。
2. NameNode查询元数据，返回文件对应的所有数据块及存储这些块的DataNode列表（按距离客户端的远近排序）。
3. 客户端根据返回的DataNode列表，直接与距离最近的DataNode建立连接，读取数据块。
4. 客户端将读取到的所有数据块按顺序拼接，还原成完整文件。

写流程：

1. 客户端向NameNode发送写文件请求，NameNode检查文件是否已存在、权限是否允许等，若通过则返回可写入的DataNode列表（基于副本放置策略）。
2. 客户端将文件分割成数据块（默认128MB），并按NameNode指定的DataNode列表，以流水线（Pipeline）方式写入数据：
   • 先向第一个DataNode写入第一个块，该DataNode接收数据后，同时向第二个DataNode复制，第二个再向第三个复制（默认3个副本）。
   • 每个DataNode接收完数据后向客户端发送确认。
3. 所有块写入完成后，客户端通知NameNode，NameNode更新元数据。

20. HDFS中的块（Block）是什么？默认大小是多少？为什么块设置得较大？

• 定义：块是HDFS中数据存储的最小单位，一个大文件会被分割成多个块（最后一个块可能小于默认大小），每个块独立存储在不同的DataNode上。
• 默认大小：
  • Hadoop 2.x及以上版本默认块大小为128MB（Hadoop 1.x为64MB），可通过dfs.blocksize配置修改。
• 设置较大的原因：
  • 减少寻址开销：块越大，单个文件对应的块数量越少，客户端与NameNode交互获取块位置的次数减少，同时磁盘寻址（寻道时间）占比降低（磁盘传输速率远高于寻道速率，大文件连续读写更高效）。
  • 优化分布式处理：MapReduce等计算框架通常按块分配任务，较大的块可减少任务数量，降低任务调度和管理的开销。
  • 适合大数据场景：HDFS面向大规模数据，大文件分割为大尺寸块更符合其设计目标（小文件会导致元数据膨胀，增加NameNode负担）。

21. 什么是副本机制？HDFS默认副本数是多少？副本放置策略是什么？

• 副本机制：HDFS通过为每个数据块创建多个副本来保证数据可靠性，当某个DataNode故障时，可从其他副本读取数据。
• 默认副本数：3个（可通过dfs.replication配置修改）。
• 副本放置策略（默认）：
  • 第一个副本：放置在客户端所在的DataNode（若客户端不在集群内，则随机选择一个节点，倾向于非负载过高的节点）。
  • 第二个副本：放置在与第一个副本不同的机架上的任意节点（跨机架，提高容错性）。
  • 第三个副本：放置在与第二个副本相同机架的不同节点上（同机架内，减少跨机架带宽消耗）。
  • 更多副本：随机分配，但尽量避免集中在同一机架。

22. Secondary NameNode的作用是什么？它与NameNode的关系？

• 作用：
  • 辅助NameNode合并元数据：定期将NameNode的编辑日志（EditLog，记录实时元数据变更）与镜像文件（FSImage，元数据的快照）合并，生成新的FSImage，减少NameNode启动时加载EditLog的时间。
  • 存储合并后的FSImage：作为元数据的备份，当NameNode的FSImage损坏时，可从Secondary NameNode恢复。
• 与NameNode的关系：
  • 不是NameNode的备用节点，无法在NameNode故障时直接替代其工作（不具备实时元数据）。
  • 独立于NameNode运行，通常部署在不同的节点上，避免资源竞争。
  • 通过定期从NameNode获取EditLog和FSImage进行合并，减轻NameNode的IO压力。

23. NameNode如何管理元数据？元数据保存在哪里？

• 元数据管理：
  • NameNode存储的元数据包括：文件目录树、文件/目录属性（权限、创建时间、修改时间）、文件与数据块的映射、块的副本位置等。
  • 元数据全部加载到内存中，以提高查询和操作效率（因此NameNode的内存大小是HDFS集群扩展的瓶颈之一）。
  • 元数据的变更会实时记录到编辑日志（EditLog），同时定期合并到镜像文件（FSImage）。
• 元数据存储位置：
  • 内存：元数据实时存在内存中，供客户端快速访问。
  • 磁盘：
    • FSImage：元数据的快照，存储在dfs.namenode.name.dir配置的目录（通常是本地磁盘，可配置多个路径提高可靠性）。
    • EditLog：记录元数据的变更，存储在dfs.namenode.edits.dir配置的目录（与FSImage路径可相同，也可单独配置，建议使用SSD提升写入性能）。

24. 什么是NameNode的“安全模式”？如何进入和退出？

• 定义：安全模式是NameNode的一种特殊状态，此时集群仅允许读取数据，不允许写入、删除等修改操作。NameNode启动时会自动进入安全模式，用于检查数据块的副本是否满足预期。
• 进入安全模式：
  • 自动进入：NameNode启动时，会加载FSImage和EditLog，然后等待DataNode发送块报告，此时自动进入安全模式。
  • 手动进入：通过命令hdfs dfsadmin -safemode enter。
• 退出安全模式：
  • 自动退出：当NameNode确认足够多的数据块（默认99.9%）达到了最小副本数（dfs.namenode.safemode.threshold-pct配置），会自动退出安全模式。
  • 手动退出：通过命令hdfs dfsadmin -safemode leave（适用于需要强制退出的场景，如部分副本丢失但需紧急恢复服务）。
• 查看安全模式状态：hdfs dfsadmin -safemode get。

25. DataNode的心跳机制和块报告的作用是什么？

• 心跳机制：
  • DataNode每3秒向NameNode发送一次心跳信息，证明自身处于活跃状态。
  • 若NameNode超过10分钟（默认，dfs.namenode.heartbeat.recheck-interval配置）未收到某个DataNode的心跳，则认为该节点故障，会将其标记为“死亡”，并启动副本复制机制，在其他DataNode上重新创建该节点上的数据块副本，以维持预期的副本数量。
• 块报告：
  • DataNode每小时（默认）向NameNode发送一次块报告，包含该节点上存储的所有数据块的列表。
  • NameNode通过块报告验证数据块的完整性和副本数量，若发现某个块的副本不足，会安排其他DataNode复制该块；若发现无效块（如损坏），则标记为“损坏”并触发重新复制。

26. HDFS如何处理文件的追加操作？早期版本为什么不支持？

• 当前支持情况：Hadoop 2.x及以上版本支持文件追加操作（通过hdfs dfs -appendToFile命令），但仍不支持随机修改。
• 处理方式：
  • 客户端向NameNode请求追加数据，NameNode检查文件状态（是否可追加），并返回最后一个块的信息及存储该块的DataNode。
  • 客户端向对应DataNode追加数据，若当前块已满（达到默认大小），则创建新的块并写入，同时NameNode更新元数据。
• 早期版本（如Hadoop 1.x）不支持的原因：
  • 一致性难题：分布式环境下，追加操作需要保证多副本的一致性，若中途某个DataNode故障，可能导致副本数据不一致。
  • 设计目标：早期HDFS面向批量处理场景，假设文件“一次写入、多次读取”，追加需求较低，因此优先保证系统的简单性和吞吐量。
  • 元数据管理复杂：追加会频繁修改元数据（如块大小、文件长度），增加NameNode的负担。

27. HDFS的Federation（联邦）机制解决了什么问题？

HDFS Federation（联邦）通过引入多个NameNode，解决了传统单NameNode架构的以下问题：

• 元数据存储瓶颈：单NameNode的内存有限，无法存储大规模集群的元数据（如数百万甚至数亿个文件），Federation让每个NameNode管理一部分元数据（称为“命名空间卷”），突破内存限制。
• 命名空间隔离：不同NameNode可管理不同的命名空间（如按部门、项目划分），实现资源隔离和权限控制。
• 性能扩展：多个NameNode并行处理请求，避免单节点的性能瓶颈，提高集群的整体吞吐量。
• 独立故障域：单个NameNode故障不会影响其他NameNode管理的命名空间，提高了系统的可用性。

28. HDFS的HA（高可用）架构如何实现？解决了什么问题？

• 解决的问题：传统HDFS中NameNode是单点故障（SPOF），若NameNode故障，整个集群无法对外提供服务。HA架构通过部署多个NameNode（通常是2个），实现NameNode的故障自动切换，保证集群的持续可用。
• 实现方式：
  • Active/Standby NameNode：一个NameNode处于Active状态（处理客户端请求、管理元数据），另一个处于Standby状态（实时同步Active的元数据，随时准备接管）。
  • 元数据同步：
    • 采用JournalNode集群（通常3个节点）存储EditLog，Active NameNode的元数据变更会实时写入JournalNode，Standby NameNode通过读取JournalNode同步EditLog，并更新自身的FSImage，确保与Active节点的元数据一致。
  • 故障检测与切换：
    • 通过ZooKeeper监控NameNode的状态，若Active节点故障，ZooKeeper会触发自动切换，将Standby节点切换为Active状态。
    • 也可通过手动命令触发切换（如hdfs haadmin -failover）。
  • DataNode双连接：DataNode同时向Active和Standby NameNode发送心跳和块报告，确保切换后新的Active节点能获取集群的状态。

29. 如何在HDFS中创建、删除、复制文件？（命令行操作）

HDFS提供hdfs dfs命令行工具用于文件操作，常用命令如下：

• 创建文件：

  • 从本地文件上传到HDFS：hdfs dfs -put <本地文件路径> <HDFS目标路径>
  • 直接在HDFS创建空文件：hdfs dfs -touchz <HDFS文件路径>
  • 从标准输入写入HDFS文件：echo "content" | hdfs dfs -put - <HDFS文件路径>

• 删除文件：

  • 删除文件：hdfs dfs -rm <HDFS文件路径>
  • 递归删除目录及内容：hdfs dfs -rm -r <HDFS目录路径>
  • 强制删除（不提示）：hdfs dfs -rm -f <HDFS文件路径>

• 复制文件：

  • 在HDFS内部复制：hdfs dfs -cp <HDFS源文件路径> <HDFS目标路径>
  • 从HDFS复制到本地：hdfs dfs -get <HDFS源文件路径> <本地目标路径>
  • 复制目录（递归）：hdfs dfs -cp -r <HDFS源目录> <HDFS目标目录>

示例：

# 上传本地文件test.txt到HDFS的/user/hadoop目录
hdfs dfs -put ./test.txt /user/hadoop/# 删除HDFS的/user/hadoop/test.txt
hdfs dfs -rm /user/hadoop/test.txt# 将HDFS的/user/hadoop/file1复制到/user/hadoop/file2
hdfs dfs -cp /user/hadoop/file1 /user/hadoop/file2

30. HDFS的“均衡器”（Balancer）的作用是什么？如何使用？

• 作用：均衡器用于平衡HDFS集群中各DataNode的磁盘使用率。当集群中部分DataNode存储过满（或过空）时，均衡器会将数据块从负载高的节点迁移到负载低的节点，确保各节点的磁盘使用率差异在合理范围内（默认阈值为10%），避免因个别节点过载影响集群性能。
• 使用方法：
  • 启动均衡器：hdfs balancer -threshold <阈值>（阈值为0-100的整数，默认10，表示允许的最大使用率差异）。
  • 示例：hdfs balancer -threshold 5（将使用率差异控制在5%以内）。
  • 停止均衡器：hdfs balancer -stop。
• 注意事项：
  • 均衡器运行时会消耗网络带宽，建议在业务低峰期执行。
  • 仅平衡同一集群内的DataNode，跨联邦的命名空间不参与平衡。

31. 什么是HDFS的“回收站”机制？如何配置？

• 答案：HDFS的“回收站”（Trash）机制类似于操作系统的回收站，用于临时保存被删除的文件或目录，防止误删除导致数据丢失。当用户删除文件时，文件不会立即从HDFS中永久删除，而是被移动到回收站目录（默认路径为/user/<username>/.Trash），并在指定的保留时间后自动清理。

• 配置方式：

  • 通过core-site.xml配置全局回收站参数：

    <!-- 启用回收站，默认true -->
    <property><name>fs.trash.interval</name><value>1440</value> <!-- 回收站文件保留时间（分钟），默认1440分钟（24小时） -->
    </property>
    <property><name>fs.trash.checkpoint.interval</name><value>0</value> <!-- 检查点间隔时间（分钟），0表示与fs.trash.interval相同 -->
    </property>
    

  • 命令行操作：
    • 删除文件并移入回收站：hadoop fs -rm /path/to/file
    • 跳过回收站直接删除（谨慎使用）：hadoop fs -rm -skipTrash /path/to/file
    • 恢复回收站文件：hadoop fs -mv /user/<username>/.Trash/Current/path/to/file /target/path
    • 清空回收站：hadoop fs -expunge

32. HDFS支持的压缩格式有哪些？如何选择？

• 答案：HDFS支持多种压缩格式，各有优缺点，选择需结合压缩率、解压速度、是否可分割等因素：

  • DEFLATE：默认无扩展名，压缩率和速度平衡，不可分割，需结合gzip格式使用（.gz）。
  • gzip：压缩率高，速度较快，不可分割，适合一次性处理的静态数据。
  • bzip2：压缩率最高，速度慢，可分割（支持MapReduce并行处理），适合归档数据。
  • LZO：压缩/解压速度快，压缩率中等，可分割（需预处理索引），适合实时性要求高的场景。
  • Snappy：压缩/解压速度极快，压缩率低于gzip，不可分割，适合中间数据处理（如Spark shuffle）。

• 选择原则：

  • 若需并行处理大文件：优先选择可分割格式（bzip2、带索引的LZO）。
  • 若追求速度：选择Snappy或LZO。
  • 若追求压缩率：选择bzip2或gzip。
  • 示例：日志数据归档用bzip2，实时计算中间数据用Snappy。

33. 如何监控HDFS的状态？（如命令或工具）

• 答案：监控HDFS状态的常用方式包括：
  • 命令行工具：
    • 查看HDFS整体状态：hdfs dfsadmin -report（显示DataNode数量、磁盘使用率、块信息等）。
    • 检查文件系统健康：hdfs fsck /（检测损坏块、缺失副本等）。
    • 查看NameNode状态：hdfs dfsadmin -metasave <filename>（导出元数据信息到文件）。
  • Web界面：
    • NameNode管理界面：http://<namenode-host>:50070（查看集群状态、文件系统、数据节点等）。
    • DataNode界面：http://<datanode-host>:50075（查看节点存储、块信息等）。
  • 第三方工具：
    • Ambari：Hadoop集群管理工具，提供可视化监控、告警和配置管理。
    • Ganglia/Nagios：开源监控系统，可收集HDFS性能指标（如吞吐量、块数量）并设置告警。
    • Prometheus + Grafana：通过Hadoop Exporter采集 metrics，可视化展示集群状态。

34. HDFS中文件损坏如何检测和修复？

• 答案：HDFS通过以下机制检测和修复文件损坏：

  • 检测机制：

    1. DataNode定期对存储的块进行校验和（Checksum）验证，若发现数据与校验和不匹配，则标记块为损坏。
    2. NameNode通过DataNode的块报告（Block Report）跟踪块状态，若发现某个块的可用副本数低于配置的副本数（如默认3副本，仅剩2个可用），则判定为需要修复。
    3. 用户可手动执行hdfs fsck /path/to/file检查指定文件的块状态，例如：

       hdfs fsck /user/data/file.txt  # 检查文件是否有损坏块
       

  • 修复机制：

    1. NameNode自动调度副本复制：当检测到损坏块或副本不足时，NameNode会选择健康的副本，通过DataNode之间的复制生成新副本，直到满足预设的副本数。
    2. 手动修复：若损坏块无法自动修复（如所有副本均损坏），需通过备份恢复，或执行：

       hdfs fsck /path/to/file -delete  # 删除包含损坏块的文件（谨慎使用）
       

35. HDFS的局限性有哪些？（如不适合小文件、低延迟访问等）

• 答案：HDFS的主要局限性及应对方案：

  1. 不适合处理大量小文件：

     • 原因：每个小文件会占用NameNode的元数据内存（约150字节/文件），大量小文件会耗尽NameNode内存。
     • 应对：使用Hadoop Archive（HAR）合并小文件，或用SequenceFile/Avro将小文件打包存储。

  2. 低延迟访问支持不足：

     • 原因：HDFS设计目标是高吞吐量的批处理，读写操作需经过NameNode协调和多副本同步，延迟较高（毫秒级）。
     • 应对：实时场景改用HBase（随机读写支持）或本地缓存热点数据。

  3. 不适合随机写操作：

     • 原因：HDFS仅支持追加写（append），不支持随机修改文件中间内容。
     • 应对：需频繁修改的数据可先在本地处理，再整体写入HDFS；或使用HBase支持随机更新。

  4. 对硬件故障敏感：

     • 原因：依赖廉价硬件，节点故障概率较高，虽有副本机制，但极端情况下仍可能数据丢失。
     • 应对：配置合适的副本数（如重要数据设为3副本），定期备份元数据。

  5. 存储效率问题：

     • 原因：副本机制（默认3副本）会占用3倍存储空间。
     • 应对：非重要数据可降低副本数，或使用纠删码（Erasure Coding，Hadoop 3.x支持）替代副本，减少存储开销。

二、110道Hadoop面试题目录列表

文章序号	Hadoop面试题110道
1	Hadoop面试题及详细答案110道（01-15）
2	Hadoop面试题及详细答案110道（16-35）
3	Hadoop面试题及详细答案110道（36-55）
4	Hadoop面试题及详细答案110道（56-70）
5	Hadoop面试题及详细答案110道（71-85）
6	Hadoop面试题及详细答案110道（86-95）
7	Hadoop面试题及详细答案110道（96-105）
8	Hadoop面试题及详细答案110道（106-110）