Hadoop、HDFS 相关面试题

文章目录

Hadoop 板块

什么是 Hadoop？

Hadoop 是一个开源的分布式存储和计算框架，最初由 Apache 软件基金会开发。它允许大规模数据处理和存储，具有高度可靠性和可扩展性。

Hadoop 由两个核心部分组成：

分布式文件系统 HDFS —— 用于数据存储
计算框架 YARN —— 用于资源管理和作业调度

Hadoop 的特点有哪些？

Hadoop 的主要特点有以下几个方面：

分布式存储：Hadoop 采用分布式文件系统（HDFS），可以将大规模数据分布式存储在多台服务器上，提供高容错性和可靠性。
分布式计算：Hadoop 使用 MapReduce 编程模型，能够将大规模数据分布式处理，通过并行计算加快数据处理速度。
可扩展性：Hadoop 可以很容易地扩展到数千台服务器，以应对不断增长的数据量和计算需求。
容错性：Hadoop 通过数据的冗余备份和自动故障转移，确保在硬件故障时不会丢失数据或中断作业。
成本效益：Hadoop 运行于廉价的商用硬件上，并能有效利用集群中的所有资源，从而降低了成本。
生态丰富：在 Hadoop 生态中，拥有多种数据处理框架。除了 MapReduce 之外，还包括多种工具和项目，如 Hive、HBase 和 Spark 等，支持不同类型的数据处理和分析需求。

Hadoop 生态圈的组件及其作用

Hadoop 生态系统包括多个组件和项目，每个都有不同的作用和功能。以下是一些常见的 Hadoop 生态系统组件及其主要作用：

HDFS：用于存储大规模数据集，并以高吞吐量访问这些数据。
YARN：用于集群资源管理和作业调度，使得不同类型的工作负载可以同时运行在 Hadoop 集群上。
MapReduce：用于将大规模数据进行分布式计算和处理，适用于批处理任务。
Hive：提供类似于 SQL 的查询语言，可用于在 Hadoop 上进行数据仓库和数据分析。
HBase：一个面向列的分布式数据库，用于实时读写大规模数据。
Spark：通用的大数据处理引擎，支持内存计算，适用于迭代计算、流处理和交互式查询等场景。
ZooKeeper：用于协调分布式应用程序的开源服务器，提供诸如数据管理、集群管理等功能。
Flume：用于大规模日志数据的收集、聚合和传输，支持将数据导入到Hadoop中。
Sqoop：用于在关系型数据库和 Hadoop 之间进行数据传输的工具，支持数据的导入和导出。这个工具已经被阿里巴巴的 DataX 开源项目取代。
Dolphinscheduler：用于协调 Hadoop 作业的工作流引擎，可以安排和管理复杂的作业流程。
Kafka：分布式流平台，用于处理实时数据流，支持发布和订阅消息系统。

还有很多其它组件工具，这里就不进行罗列了，读者可以在互联网上进行了解。

Hadoop 主要分哪几个部分？他们有什么作用？

这三个部分属于老生常谈了…

HDFS（数据存储）：HDFS 是 Hadoop 的分布式文件系统，用于存储大规模数据集。它可以将数据分布式存储在多台服务器上，并提供高吞吐量的访问，适用于大规模数据的持久性存储。

YARN（资源调度）：YARN 是 Hadoop 的资源管理器，负责集群资源的管理和作业调度。它允许不同类型的工作负载在 Hadoop 集群上同时运行，包括 MapReduce、Spark 等。YARN 的作用是使得 Hadoop 集群能够有效地管理和利用资源，以支持不同类型的应用程序。

MapReduce（计算+资源调度）：MapReduce 是 Hadoop 的编程模型和计算框架，用于将大规模数据进行分布式处理和计算。它由两个主要阶段组成：

Map 阶段：用于数据的分片和处理；
Reduce 阶段：用于结果的汇总和输出。

MapReduce 的作用是加速大规模数据集的处理，支持并行计算和分布式处理。

Hadoop 1.x，2x，3.x 的区别

Hadoop 1.x 主要由 HDFS 和 MapReduce 两部分组成，其中 MapReduce 既负责资源调度又负责逻辑运算，当单点产生故障时可能导致整个集群的作业和资源管理受到影响。
Hadoop 2.x 在 Hadoop 1.x 的基础上，将资源调度从 MapReduce 中进行了分离，也就产生了 YARN（用于管理集群的资源调度），MapReduce 主要负责逻辑运算工作。并且支持 MapReduce 以外的应用程序框架，扩展了 Hadoop 的计算能力。
Hadoop 3.x 在 Hadoop 3.x 中，结构组成上并没有发生变化，但是增加了许多新特性，在各个方面都进行了一系列改进和优化，改进了 NameNode 的内存管理，提高了 HDFS 的可伸缩性和容错性。

Hadoop 集群工作时启动哪些进程？它们有什么作用？

NameNode： NameNode 是 HDFS 的中央组件，负责管理文件系统的命名空间和数据块的映射信息。它维护着整个文件系统的元数据，包括文件、目录结构以及数据块的位置等。
DataNode： DataNode 负责存储实际的数据块，并根据 NameNode 的指示执行读取和写入数据的操作，并在工作过程中向 NameNode 报告数据块的存储信息。
ResourceManager： ResourceManager 是 YARN 的主要组件，负责集群资源的分配和作业调度。它接收来自客户端的作业提交请求，并将资源分配给各个应用程序。
NodeManager： NodeManager 在每个节点上运行，负责监控该节点上的容器（用于执行应用程序的环境）的使用情况，并与 ResourceManager 协调资源分配。
SecondaryNameNode： SecondaryNameNode 负责定期合并 FsImage 和 Edits 文件，以便减少 NameNode 重启时的恢复时间。
JobHistoryServer： JobHistoryServer 记录作业执行的历史信息，包括作业的状态、启动时间、完成时间等，方便后续查询和监控。

在 Hadoop 集群计算的时候，主要有什么瓶颈？

网络带宽：集群内部节点之间的数据传输需要大量的网络带宽，如果网络带宽不足，会导致数据传输速度变慢，影响整个计算过程的效率。
存储I/O：Hadoop 集群通常依赖于大量的磁盘存储，当存储设备的 I/O 能力无法满足计算需求时，会成为瓶颈，影响数据读取和写入的效率。
计算能力：集群中的计算节点的处理能力也是一个潜在的瓶颈。如果任务需要大量的计算资源而节点的计算能力有限，那么会导致任务运行缓慢。
内存：内存容量不足也可能成为瓶颈，特别是在需要进行大规模数据处理和复杂计算的情况下。内存过少会导致正在执行的作业失败，引发其他故障等。

搭建 Hadoop 集群时，主要有哪些文件？

core-site.xml：用于配置 Hadoop 的核心参数，如文件系统默认的 URI、数据存储的位置等。
hdfs-site.xml：用于配置 Hadoop 分布式文件系统（HDFS）的参数，如副本数量、块大小等。
mapred-site.xml：用于配置 MapReduce 框架的参数，如 JobTracker 的地址、TaskTracker 的最大任务数等。
yarn-site.xml：用于配置 YARN 资源管理器（ResourceManager）和节点管理器（NodeManager）的参数。
hadoop-env.sh：用于设置 Hadoop 环境变量和 Java 环境变量的脚本文件。
yarn-env.sh：用于设置 YARN 环境变量的脚本文件。
mapred-env.sh：用于设置 MapReduce 环境变量的脚本文件。

这些 XML 和脚本文件通常位于 Hadoop 的配置目录中，我们可以修改这些文件，进行定制化配置，提升 Hadoop 集群的性能。

Hadoop 的 Checkpoint 流程

Hadoop 中的 Checkpoint 流程通常指的是 HDFS 中的 SecondaryNameNode 执行 Checkpoint 的过程。

Checkpoint 是为了避免 NameNode 单点故障而设计的一种机制，它可以将内存中的编辑日志和文件元数据快照合并，生成新的文件系统镜像（fsimage），以提高系统的可靠性和恢复速度。

具体的 Checkpoint 流程如下：

收集编辑日志：SecondaryNameNode 首先从 NameNode 处获取当前的 edits 和 fsimage 文件。
合并编辑日志：SecondaryNameNode 将最新的 edits 文件与上一次Checkpoint 时的 fsimage 文件进行合并，得到新的 fsimage 镜像文件。
拷贝编辑日志：将合并后的 edits 文件拷贝到 NameNode 所在的主节点上。
替换 fsimage 镜像文件：将新生成的 fsimage 镜像文件拷贝到 NameNode 上，并替换旧的 fsimage 文件。
清理编辑日志：清空已经合并到新 fsimage 镜像文件中的旧 edits 文件（合并后清除旧的操作日志文件）。

通过这个 Checkpoint 流程，Hadoop 能够定期生成新的

fsimage

镜像文件，并保留操作日志历史的

edits

文件，以便在 NameNode 发生故障时能够快速地恢复文件系统的状态，确保数据的安全和可靠性。

在 HDFS 中，
fsimage
和
edits
是两个关键的文件，用于存储文件系统元数据以及记录文件系统操作的日志。
fsimage
文件（镜像文件）：包含了 HDFS 文件系统的元数据信息，例如文件和目录的命名空间、权限、块信息等。这些元数据描述了 HDFS 中的文件系统结构和属性。当 NameNode 启动时，会从
fsimage
文件中加载元数据，这样可以加速 NameNode 的启动过程。
edits
文件（编辑日志文件）：记录了对 HDFS 文件系统的所有修改操作，如文件创建、删除、重命名等。每个操作都会被追加到
edits
文件中，形成一个不断增长的日志序列，保证文件系统的一致性和容错性。

NameNode 将
fsimage
文件中的元数据与
edits
文件中的操作日志相结合，从而重建出完整的文件系统状态。在系统发生故障时，进行快速恢复。

Hadoop 的默认块大小是多少？为什么要设置这么大？

在 Hadoop 2.7.2 版本之前默认

64MB

，Hadoop 2.7.3 及以后都是默认

128MB

。

这样设置的主要原因包括以下几个方面：

减少寻址时间与元数据开销：较小的块大小会增加寻址时间并产生更多的元数据存储开销，因为每个块都需要占用一定的元数据空间，NameNode 内存压力大。相比之下，较大的块大小可以减少寻址时间与元数据存储的开销。
适应大文件处理：Hadoop 通常用于处理大规模的数据集，较大的块大小有利于更好地匹配大文件的处理需求，减少了小文件管理所带来的系统开销。
减少 NameNode 的负载：较大的块大小可以减少 NameNode 上的块数量，减轻了 NameNode 的负载压力，使其更好地管理大规模的文件系统。

现在之所以设置为

128MB

的大小，主要是取决于当前磁盘的传输速率（假设：

100MB/S

）。

其中寻址时间控制在整个传输时间的

1%

，假设寻址时间为

10ms

，那么可以得到传输时间为

10/0.01=1000ms

即

秒，吻合磁盘（假设）的传输速率，故可将块大小设置为

128MB

。

因为现在大部分服务器的磁盘速度都支持或者已经超过了 Hadoop 官方预设的

128MB

（每个 Block 默认的储存大小），为了向下兼容默认为

128MB

。

在实际开发中，这个块大小可以根据当前集群中的磁盘I/O速度进行适当的调整。

Hadoop 常见的压缩算法？

我这里只说两种压缩算法，也是最为常用的。

Gzip： Gzip 是一种通用的无损压缩算法，在 Hadoop 中被广泛使用。它能够显著减小文件的大小，从而减少存储空间和数据传输成本。（压缩比高，但时间效率低）
Snappy： Snappy 是 Google 开发的快速压缩/解压缩算法，特点是速度非常快，但压缩比一般略低于其他算法。（压缩比略低，但时间效率高）

在实际开发中，更推荐 Snappy 压缩方式，不过也要看具体的实际情况，时间效率和空间效率相比肯定是选择前者的。

我过去写过一篇 Hive 存储与压缩的对比文章，感兴趣的可以看看。

Hadoop 作业提交到 YARN 的流程？

我个人总结的流程，如果有错误请在评论区指出。

在这里插入图片描述

Hadoop 的 Combiner 的作用

Hadoop 中的 Combiner 是一个可选的优化工具，其作用是在 Map 阶段输出结果被发送到 Reducer 之前，在每个 Mapper 节点上进行本地汇总。它可以帮助减少数据传输量、降低网络负载和提高整体作业执行效率。

局部合并： Combiner 在 Map 阶段的输出结果中进行局部合并，将具有相同 key 的中间键值对进行合并，从而降低需要传输到 Reducer 的数据量。
减少网络传输： 通过在 Map 端进行合并，Combiner 可以减少需要通过网络传输的数据量，从而降低了网络开销，减轻了集群的负担。
降低 Reducer 负担： Combiner 的使用可以有效地降低 Reducer 的负担，因为经过 Combiner 处理后的数据量更小，Reducer 需要处理的数据也相应减少，从而提高了整体作业的执行效率。

在使用 Combiner 时需要注意！对于给定的输入，确保无论怎样进行分组和顺序处理，最终的结果都是一样的。

Hadoop 序列化和反序列化

序列化： 将内存中的对象，转换成字节序列（或其他数据传输协议）以便于存储到磁盘进行持久化存储和网络传输。

反序列化： 将收到字节序列（或其他数据传输协议）或是磁盘中存储的持久化数据，转换成内存中的对象。

之所以进行序列化，我在网上找到了一个比较容易理解的说法，转载帮助读者理解：

一般来说，“活的” 对象只生存在内存里，关机断电就没有了。而且 “活的” 对象只能由本地的进程使用，不能被发送到网络上的另外一台计算机。然而序列化可以存储 “活的” 对象，可以将 “活的” 对象发送到远程计算机。
【摘录自网络作者，没找到原出处】

Hadoop 的运行模式

本地模式（Local）： 在本地模式下，Hadoop 作业（如 MapReduce作业）在单个节点上运行，不涉及集群中的其他节点。这种模式适用于开发、调试和测试小规模数据时使用，通常用于在本地机器上快速验证代码逻辑和功能。

伪分布式模式： 在伪分布式模式下，Hadoop 集群包含多个组件（如HDFS、YARN），但这些组件都部署在单个物理机器上。每个组件运行在独立的进程中，并能够相互通信。这种模式通常用于在单台机器上模拟一个完整的 Hadoop 集群，用于开发、测试和学习 Hadoop 生态系统的特性和功能。

分布式模式： 在分布式模式下，Hadoop 集群由多台物理机器组成，每台机器都运行 Hadoop 的各个组件，如 NameNode、DataNode、 ResourceManager、NodeManager 等。这种模式适用于生产环境中对大规模数据进行处理和分析，能够实现高可用性、横向扩展和并行计算。

这里推荐一篇我写的 Hadoop 完全分布式搭建（超详细）文章，有需要的可以看看。

Hadoop 小文件处理问题

小文件产生的原因

采用动态分区的方式写入数据，产生大量的小文件，从而导致 Map 端数量剧增；
Reduce 数量设置不合理，Reduce 的个数和输出文件个数一致，Reduce 越多，小文件也就越多；
数据源本身就是大量的小文件，未进行合并操作；
数据处理与写入方式不当。

大量小文件造成的后果

当我们在 HDFS 中存储大量小文件时（存在许多远远小于 Block 大小的文件），会导致 NameNode 的内存消耗增加，增加访问数据的寻址时间，影响系统的安全和性能。

这是因为 NameNode 将 HDFS 文件系统的元数据存放在内存中，因此存储的文件数目受限于 NameNode 的内存大小。在 HDFS 中每个文件、目录、数据块占用

150Bytes

。如果存放的文件数目过多的话会占用很大的内存甚至撑爆内存，导致集群崩溃，产生非常严重的后果。

解决小文件问题

合并小文件：将多个小文件合并成较大的文件，减少文件数量，从而降低 NameNode 的负担和存储空间的浪费。（在 Map 端和 Reduce 端都进行合并）
使用归档技术：对于历史数据，可以将小文件进行归档或压缩存储，以减少存储空间占用。

具体如何操作，可以参考我写的下面几篇文章：

Spark SQL 与 Hive 的小文件调优
Hadoop 集群小文件归档 HAR、小文件优化 Uber 模式
Hadoop MapReduce 调优参数

Hadoop 为什么要从 2.x 升级到 3.x？

性能优化：Hadoop 3.x 引入了许多性能优化和改进，包括新的存储管理方式、数据处理算法的优化，以及更高效的资源利用，从而提高了整体的作业执行效率和系统吞吐量。
可伸缩性：Hadoop 3.x 对集群规模和数据规模的支持更加灵活和可伸缩，能够更好地适应大规模数据处理和存储需求，提供更好的横向扩展能力。
安全性增强：Hadoop 3.x 加强了安全性方面的功能，包括对数据的加密、用户身份验证和授权机制的改进，以及对集群通信的安全加固，提升了整体系统的安全性。
新特性引入：Hadoop 3.x 引入了许多新的特性和组件，如 HDFS Erasure Coding、YARN 容器复用、Hadoop RBF（Router-based Federation）等，为用户提供了更多选择和功能上的便利。
Bug修复和稳定性改进：Hadoop 3.x 版本针对之前版本中存在的一些缺陷和稳定性问题进行了修复和改进，提高了系统的稳定性和可靠性。

适应时代发展，满足了不断增长的大数据处理需求，并为用户提供了更稳定、高效的数据处理平台。

Hadoop 的优缺点

优点

横向扩展能力强：Hadoop 具备良好的横向扩展性，可以方便地向集群中添加更多的节点来处理不断增长的数据量。
容错性高：Hadoop 通过数据备份和任务重启等机制，提供了很好的容错性，即使在节点故障或任务执行失败的情况下，仍能保证作业的正常执行。
适用于大规模数据处理：Hadoop 适合处理大规模数据，能够对海量数据进行高效的存储、管理和计算，支持 PB 级别的数据处理。
开源社区活跃：Hadoop 作为开源项目，拥有庞大的开源社区，用户可以从社区中获取丰富的资源、工具和支持。
生态系统完整：Hadoop 生态系统包含了丰富的组件和工具，如 Hive、Spark、HBase 等，能够满足各种大数据处理需求。

缺点

适用场景受限：Hadoop 更适合于批处理和离线处理场景，对于实时处理和低延迟需求并不是最佳选择。
复杂度较高：搭建和维护 Hadoop 集群需要一定的技术知识和经验，对于初学者来说存在一定的学习曲线。
小文件处理效率低：Hadoop 对小文件的处理效率不高，可能会导致存储空间浪费和系统性能下降。
硬件成本较高：构建大规模的 Hadoop 集群需要大量的服务器和存储设备，对硬件资源有一定要求，因此构建和维护成本相对较高。

HDFS 板块

HDFS 文件写入和读取流程（存储机制）

HDFS 文件写入流程

客户端请求：客户端向 NameNode 发送文件写入请求，包括文件路径、文件大小等信息。
NameNode 分配数据节点： NameNode 接收到写入请求后，会选择适当的数据节点来存储文件数据，并向客户端返回这些数据节点的信息。
DataNode 数据节点写入：客户端根据 NameNode 返回的 DataNode 数据节点信息，直接连接到对应的数据节点，并将文件数据切分为数据块（通常大小为 128MB），然后依次写入到数据节点上。
数据复制：在数据节点上成功写入数据后，会进行数据的复制，以确保数据的容错性和可靠性。默认情况下，每个数据块会有三个副本分布在不同的数据节点上。
确认写入完成：当所有数据块都成功写入并复制完成后，客户端会向 NameNode 发送写入完成的确认信息。
元数据更新： NameNode 收到确认信息后，会更新文件的元数据信息，并将文件的位置信息记录在元数据中。

HDFS 文件读取流程

客户端请求读取：客户端向 NameNode 发送文件读取请求，包括文件路径等信息。
NameNode 返回数据节点信息： NameNode 根据文件路径查询元数据，找到存储文件数据的数据节点信息，并将其返回给客户端。
客户端连接数据节点：客户端根据 DataNode 数据节点信息直接连接到对应的数据节点，并请求读取文件数据。
数据传输：数据节点接收到读取请求后，会将文件数据传输给客户端，客户端将数据合并成完整的文件。

HDFS 组成架构

NameNode（名称节点）： NameNode 是 HDFS 的关键组件之一，负责维护文件系统的命名空间和元数据信息，包括文件、目录结构以及文件与数据块的映射关系。它记录了文件在集群中的分布情况，以及每个文件被划分为若干数据块的具体位置。

DataNode（数据节点）： DataNode 负责存储实际的数据块。它们根据 NameNode 的指示，管理文件数据的读取、写入和删除操作，并定期向 NameNode 报告自身的存储情况。

Secondary NameNode（辅助名称节点）： Secondary NameNode 负责定期合并编辑日志（edits log）和镜像文件（fsimage），以便减小 NameNode 启动时间和内存占用，同时降低数据丢失的风险。

客户端： 客户端是与 HDFS 交互的主体，可以通过 HDFS API 进行文件系统的读取、写入和管理操作。

块（Block）： HDFS 将文件切分为固定大小的数据块（通常默认为 128MB），并将这些数据块分布式地存储在不同的 DataNode 上。

介绍下 HDFS，说下 HDFS 优缺点，以及使用场景

HDFS 是 Hadoop 生态系统的核心组件之一，用于存储大规模数据，并提供高容错性和高吞吐量的分布式文件系统。

HDFS 优点

高吞吐量： HDFS 针对大文件进行了优化，能够提供较高的数据读写吞吐量。
可靠性和容错性： HDFS 通过数据块的复制和分布式存储实现了高度的容错性，即使某个节点发生故障，数据仍然可以被正常访问。
扩展性： HDFS 可以方便地扩展到大规模集群，支持 PB 级别的数据存储，并且能够处理大量的并发读写操作。
适合大数据处理：由于其分布式存储和处理特性，HDFS 在大数据处理和分析领域有着广泛的应用。

HDFS 缺点

不适合小文件存储：HDFS 更适合存储大文件，而不太适合存储大量小文件，因为每个文件都会被划分为若干个数据块，小文件过多会增加寻址时间并会导致 NameNode 负担过大。
延迟较高： HDFS 无法做到低延时，因为它更注重的是整体数据处理的吞吐量。
不支持并发写入与随机修改：一个文件只能由一个进程执行写操作，不允许多个线程同时写；在操作数据时，仅支持数据的追加操作，不支持文件的随机修改。

HDFS 使用场景

大数据存储与处理： HDFS 适用于存储和处理海量的结构化和非结构化数据，如日志文件、传感器数据、网页数据等。
数据仓库与数据湖： HDFS 可作为数据仓库或数据湖的底层存储，支持各种大数据处理框架（如 MapReduce、Spark 等）进行数据分析和挖掘。
日志收集与分析：通过将日志文件存储在 HDFS 上，可以方便地进行日志的集中管理和分析。
高可靠性需求：对于要求数据存储具有高可靠性和容错性的场景，如金融、医疗等领域，也适合采用 HDFS 进行数据存储。

HDFS 的容错机制

数据备份： HDFS 将每个数据块默认复制到三个不同的数据节点上，以提供冗余备份，从而在某个数据节点发生故障时，可以使用其它副本继续访问数据。
客户端写入确认：HDFS 的写入操作在客户端完成后并不立即返回成功，而是等待数据块的所有副本都成功写入后才返回成功。
心跳检测机制： HDFS 会定期对数据节点执行健康检查，如果发现某个 DataNode 数据节点出现故障或数据丢失，NameNode 将自动调度其他数据节点上的备份数据块来替代故障的数据块，保证数据的可用性。
Secondary NameNode 和 Checkpoint： Secondary NameNode 定期合并编辑日志和镜像文件，生成新的镜像文件，并清理旧的编辑日志，这样能够降低 NameNode 故障时的数据丢失风险，加快恢复速度。

HDFS 的副本机制（机架策略）

在 HDFS 中，系统默认的副本数量是

，具体放置策略如下：

第一副本——保存在客户端所在的 DataNode 节点上，如果客户端在集群外，则随机选择一个节点进行存储。
第二副本——保存在与第一副本同机架中的其它 DataNode 节点上。
第三副本——保存在不同机架中的 DataNode 节点上。
更多副本：如果设置了更多副本，数量大于 3，那么它会被随机放置到空闲的 DataNode 节点上。

不同机架指的是物理上相对独立的服务器和网络设备所组成的一个单元。

HDFS 的常见数据格式，列式存储格式和行存储格式异同点，列式存储优点有哪些?

HDFS中常见的数据格式包括文本文件（如CSV、JSON）、序列文件（SequenceFile）、Parquet、ORC 等。

列式存储格式
列式存储将表格的每列数据单独存储，可以提供更好的压缩比率，尤其对于大型数据集来说非常有效。另外，列式存储在处理需要读取特定列数据的查询时效率更高，因为只需读取所需列，而不必读取整行数据。

行存储格式
行式存储将完整的行数据存储在一起，适合于需要读取整行数据进行分析的场景。此外，行存储格式在写入新数据时速度通常较快，因为可以连续地写入新行数据，而不必关注列的顺序。

列式存储格式更适合于 OLAP（联机分析处理），注重大数据量下的查询效率。

行式存储格式则更适合于 OLTP（联机事务处理），注重增删改查等操作。

HDFS 如何保证数据不丢失？

数据冗余： HDFS 会将文件切分成多个数据块，并在集群中多个节点上存储这些数据块的副本。默认情况下，每个数据块会有

个副本，可以通过配置进行修改。如果某个节点发生故障或数据损坏，HDFS 可以从其它节点上的副本中恢复数据，从而避免数据丢失。

心跳机制： DataNode 会不定期的向 NameNode 发送当前的相关状态信息，如果 DataNode 没有在规定时间内发送状态信息，则会被 NameNode 认定为宕机，该 DataNode 节点不再进行 I/O 操作。

容错性： HDFS 采用主-从架构，包括一个单独的 NameNode 和多个 DataNode。NameNode 负责维护文件系统的命名空间和元数据信息，而DataNode 则负责实际存储数据。由于 NameNode 具有高可用性机制，能够通过备份、容错等手段保证其不成为单点故障，从而保证了文件系统的整体可靠性。

回收站： 在 HDFS 中删除的文件并不会直接彻底删除，而是先放入回收站，在经过一定时间后才会彻底删除。

检验和校验： 在传输和存储数据的过程中，HDFS 会对数据进行检验和校验，以确保数据的完整性。

HDFS NameNode 高可用如何实现？需要哪些角色？

HDFS NameNode 的高可用可以通过实现 NameNode 的主备模式（Active-Standby）来实现。

Active NameNode： 主 NameNode 节点，负责处理客户端的读写请求，并维护文件系统的命名空间和块映射信息。

Standby NameNode： 备用 NameNode 节点，处于预备状态，作为 Active NameNode 的备份，定期从 Active NameNode 同步命名空间和块映射信息，并在 Active NameNode 发生故障时接管其角色。

共享存储设备： 存储编辑日志（edits log）和镜像文件（fsimage），以便 Standby NameNode 能够快速恢复到与 Active NameNode 一致的状态。在进行主备切换的时候，新的主 NameNode 在确认元数据完全同步之后才能继续对外提供服务。

ZooKeeper 集群： 协调 Active 和 Standby NameNode 之间的切换过程和状态同步。

HDFS 的文件结构？

HDFS 的文件结构主要包含三个部分，分别是 NameNode、DataNode 以及 SecondaryNameNode。

其中 NameNode 负责管理和维护文件系统中的元数据信息；DataNode 负责存储真正的数据；SecondaryNameNode 负责保存镜像文件以及编辑日志，确保 NameNode 发生故障后能够及时恢复。

HDFS 的默认副本数？为什么是这个数量？如果想修改副本数怎么修改？

HDFS 默认的副本数量是

。

之所以设置成

和 HDFS 的副本放置策略有关。HDFS 会将第一副本放置在客户端上的 DataNode 数据节点上；将第二副本放置在同机架下的另一个 DataNode 数据节点上；将第三副本放置在不同机架下的 DataNode 数据节点上。当有更多副本时，会随机放置在空闲的 DataNode 节点上，故默认设置成

就行了，因为过多的副本会消耗系统的计算资源与存储资源。

如果想要修改副本数，可以配置

hdfs-site.xml

文件，调整

dfs.replication

的值，该值的数量必须小于当前系统中 DataNode 的数量。

介绍下 HDFS 的 Block

在 HDFS 中，数据都是通过块的方式来存放的，也就是 Block。

之所以通过块的方式来进行存储，是因为随机访问比直接访问效率要低很多。我们都知道计算机底层存储的数据块都是连续的，一般情况下，我们会访问很多数据，直接拿一整块加载到内存中减少寻址时间，这样效率会更高。

在 HDFS 中默认的块大小为

128MB

，在 Hadoop

2.7

以前默认的块大小为

64MB

。

Block 块大小和集群环境中的计算资源（MR）、内存空间、磁盘I/O速率有关，详情可以查看本篇文章中的 —— Hadoop的默认块大小是多少？为什么要设置这么大？

HDFS 的块默认大小，64M 和 128M 是在哪个版本更换的？怎么修改默认块大小？

在 Hadoop

2.7.2

之前 Block 块大小是

64MB

，之后的版本中默认都是

128MB

。

如果想要更改默认的块大小，可以配置

hdfs-site.xml

文件中的

dfs.blocksize

属性，单位是

byte

，如下所示：

<!-- 这里设置的是 128MB --><property><name>dfs.blocksize</name><value>134217728</value></property>

HDFS 的 block 为什么是 128M？增大或减小有什么影响？

块的大小会影响寻址时间、传输效率以及处理效率。

当将块增大时

当块越大时，NameNode 的压力就越小，块的寻址时间也就降低了，但传输时间会增加。通常情况下由一个

map

负责处理一个块的内容，块变大了处理的效率同时也会降低。

当将块减少时

当块越小时，会造成小文件过多，NameNode 的压力就越大，会因内存溢出导致系统故障。同时块的寻址时间也会增加，但传输时间会变短。

HDFS HA 怎么实现？是个什么架构？

HDFS HA（High Availability）是通过在 HDFS 中引入多个 NameNode 来实现故障转移和高可用性。在传统的 HDFS 架构中，只有一个 NameNode 负责管理文件系统的命名空间和访问控制信息，当发生单点故障时，可能导致整个 HDFS 集群不可用。

HDFS HA 实现方式

在 HDFS HA 中引入了两种节点：Active NameNode 和 Standby NameNode，它们共同工作以确保 HDFS 的高可用性，并通过持续不断的通信来保持数据同步。

HDFS HA 架构

共享存储：Active NameNode 和 Standby NameNode 使用共享存储来存储编辑日志（Edit Logs）和镜像文件（FsImage），确保数据一致性和持久性。
自动故障转移：当 Active NameNode 发生故障时，Standby NameNode 会接管其角色，并成为新的 Active NameNode，而无需人工干预。
健康检查和心跳：Active NameNode 和 Standby NameNode 之间定期进行健康检查和心跳通信，确保系统正常运行并快速检测故障。

HDFS 的 mapper 和 reducer 的个数如何确定？ reducer 的个数依据是什么？

mapper 的数量计算

mapper 的数量和输入文件的数量有关，有多少文件就会至少有多少个 mapper，具体的数量需要通过文件的大小来进行确定，默认情况下，mapper 分片的大小和 Block 块大小是一致的，也就是

128MB

（Hadoop

2.7

版本之后）。

当文件的大小超过分片大小时，就会增加 mapper 的数量，假设一个文件

200MB

，我们的分片大小为默认的

128MB

，故该任务需要两个 mapper 去执行。

调整参数：

mapreduce.job.maps 指定 mapper 的数量；
mapred.min.split.size 指定 mapper 分片的最小值，单位是 byte；

reducer 的数量计算

reducer 在默认情况下，只有一个，但用户可以通过参数

mapreduce.job.reduces

进行指定。

需要注意的是，有多少个 reducer 就会有多少个输出文件。

HDFS 通过哪个中间组件去存储数据

在 HDFS 中，通过 Client 客户端负责去执行数据的存储操作，将文件切分成若干物理块分布式的存储在 DataNode 节点中。

当我们需要读取数据时，先与 NameNode 进行交互，获取数据的元数据信息，然后从 DataNode 中获取对应的数据。

HDFS 跨节点怎么进行数据迁移

要在 HDFS 中跨节点进行数据迁移，可以使用 Hadoop 提供的命令

distcp

来实现，该命令专门用于在 HDFS 集群之间进行数据复制，其本质是执行一个 MapReduce 任务，但只有 Map，没有 Reduce。

示例如下：

hadoop distcp hdfs://source-cluster/file-path hdfs://destination-cluster/file-path

其中，

hdfs://source-cluster/file-path

是源文件路径，

hdfs://destination-cluster/file-path

是目标文件路径。

如果只需要在同一 HDFS 集群的不同节点之间进行数据迁移，直接使用

cp

命令即可。

例如，将数据从一个节点的

/directory1

目录复制到另一个节点的

/directory2

hdfs dfs -cp /directory1/* hdfs://destination-node:port/directory2/

在执行上述操作前，都需要确保操作用户是否拥有读写权限。

HDFS 的数据一致性靠什么保证？

副本机制
心跳机制
数据校验：HDFS 会记录并存储每个数据块的校验和信息。当客户端读取数据时，HDFS 会对读取的数据进行校验和验证，以确保数据的完整性和一致性。

数据校验操作： 当客户端在传输数据时，会根据文件的大小设定什么时候进行校验和，假设传输
1KB
的数据，每
256B
校验一次，那么最终的校验和值应该是
4
，这个值系统会先拿到。

然后通过一个初始状态值为
0
的变量来记录传输的次数，当数据传输完成后，对比该变量的值是否与系统校验和一致，从而确保数据的一致性。

HDFS 中向 DataNode 写数据失败了怎么办？

在 HDFS 中是通过管道的方式将数据写入 DataNode 节点中，当发生写故障后，会执行以下操作：

关闭管道，将已经写入到管道但没有收到确认反馈的数据重新添加到数据队列中，防止数据丢失。
将正常的 DataNode 节点重新分配一个新的版号，当故障节点恢复后，由于版本信息不对，则会被删除。
在管线中删除故障节点，并把数据写入管线中剩下正常的 DataNode 中，即新的管道。
当文件关闭后，NameNode 会检测副本数量是否满足，如果不满足则会在其余正常的节点上创建。

Hadoop 2.x HDFS 快照

HDFS 快照是存储某一时刻的文件系统映像，它并不会存储数据，而是进行一种状态记录，并不会进行数据拷贝。只记录 Block 块列表和文件大小，进行一种差异化对比。

快照相关命令：

# 设置一个目录为可快照
hdfs dfsadmin -allowSnapshot<path># 取消目录可快照
hdfs dfsadmin -disallowSnapshot<path># 生成快照
hdfs dfs -createSnapshot<path>[<snapshotName>]# 删除快照
hdfs dfs -deleteSnapshot<path><snapshotName># 列出所有可快照目录
hdfs lsSnapshottableDir 

# 比较快照之间的差异 
hdfs snapshotDiff <path><fromSnapshot><toSnapshot>

HDFS 文件存储的方式？

将文件按 Block 大小划分为块，进行存储。如果文件大小超过了 Block 块，则会划分为多个块进行分布式存储。

存储过程简述如下：

客户端向 NameNode 发起写文件请求。
NameNode 处理请求，分配 DataNode 反馈给客户端。
客户端向分配的 DataNode 中上传数据，期间会进行块划分以及数据校验操作。
根据副本机制对上传的文件进行备份。
备份完成后，客户端向 NameNode 进行反馈，NameNode 进行元数据更新，完成文件的存储工作。

HDFS 读写数据过程中有哪些故障，分别会怎么处理？

读数据故障

读取数据时，DataNode 挂了。
数据读取后，发现文件损坏。

对于这两种情况，其实都可以借助 HDFS 的副本机制来进行解决。

对于第一种情况，可以切换到其它正常的 DataNode 节点继续读取。

对于第二种情况，先向 NameNode 汇报损坏的 Block 块并进行删除，重新备份，如果要读取数据，我们同样可以切换到其它正常的 DataNode 节点进行读取。

写数据故障

写数据时，DataNode 挂了。
写数据时，NameNode 挂了。
写数据时，客户端超时。

对于第一种情况，在写数据时，DataNode 发生了故障，并不会马上终止写操作，而是尝试将故障的 DataNode 从管线中删除，然后继续进行写操作，这个过程称为

pipeline recovery

。

对于第二种情况，在写数据时，NameNode 发生了故障，该故障并不会终止 DataNode 的写操作，在完成写操作后，客户端会向 NameNode 汇报已完成写操作，请求关闭文件，但此时 NameNode 已经挂掉了，无法响应客户端的请求。如果是高可用集群，则会切换主备 NameNode 进行工作，完成任务。但如果是非高可用集群，则无法自动解决，需要人工干预，处理问题。

对于第三种情况，在写数据时，客户端超时，也就是客户端自己发生了故障。在客户端向 NameNode 发起写请求时，会给客户端设置一个租约，且需要定期续约，如果在经过一定时间后，未进行续约，则会被判定为超时，那么 NameNode 会关闭该文件并进行释放，避免该文件被一直占用，导致其它进程无法写入，这个过程称为

lease recovery

。在进行回收过程中，如果发现 Block 块副本在多个 DataNode 上处于不一致的状态，那么会将这些 DataNode 恢复到同一状态，这个过程称为

block recovery

。

NameNode 存数据吗?

NameNode 负责管理 HDFS 的命名空间，维护 HDFS 上所有的文件和目录，只保存文件相关的元数据信息，并不存储真正的数据。

使用 NameNode 的好处

使用 NameNode 能够快速定位到目标数据块的位置，处理高效，更方便的对文件进行管理，减轻用户对 HDFS 的维护成本。

并且 NameNode 通过

fsimage

镜像文件和

edits

操作日志文件对系统进行备份操作，当发生故障时，能够及时进行恢复。

HDFS 中 DataNode 怎么存储数据？

在 HDFS 中，DataNode 存储数据是通过以下步骤完成的：

分割文件：将要存储的文件分割成固定大小的数据块。
复制数据块：将数据块复制多份，通常默认为 3 份，然后存储到不同的 DataNode 上，以实现数据的冗余备份和容错能力。
存储数据：将数据块存储在本地文件系统上，并维护这些数据块的元数据信息。

直接将数据文件上传到 HDFS 的表目录中，如何在表中查询到该数据？

将数据文件直接上传到 HDFS 的表目录中，并不会使数据自动被表所识别。

如果使用 Hive：首先需要创建一个外部表，将表的逻辑结构与 HDFS 上的文件关联起来，然后定义表的元数据信息。之后就可以通过 Hive 语句对数据进行查询和分析。

如果使用 HBase：需要将 HDFS 上的数据导入到 HBase 表中，并确保表的列族和列与数据格式一致。之后就可以通过 HBase 提供的 API 或命令行工具对数据进行操作和查询。

如果只想查看文件内容，可以直接通过 HDFS 的命令行进行查看：

hdfs dfs -cat<filePath>

标签： hadoop hdfs 大数据

本文转载自: https://blog.csdn.net/weixin_46389691/article/details/136337997
版权归原作者 月亮给我抄代码 所有，如有侵权，请联系我们删除。