大数据面经笔记

一、大数据部分

HDFS面试重点

1.HDFS的架构

（1）NameNode：是一个管理者，管理HDFS的名称空间；配置副本策略；管理数据块block的映射信息；处理客户端读写请求。
（2）DataNode：NameNode下达命令，DataNode执行实际的操作。存储实际的数据块；执行数据块的读写操作。
（3）Cient：就是客户端。文件切分，就是client上传文件到HDFS的时候，将文件切分为一个一个的block，然后进行上传；与NameNode交互，获取文件的位置信息；与DataNode交互，读取或者写入数据；Client提供一些命令来管理HDFS，比如NameNode格式化；Client可以通过一些命令来访问HDFS，比如对HDFS增删改查操作；。
（4）SecondaryNameNode：并非NameNode的热备，当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务。辅助NameNode，分担其工作量，比如定期Fsimage和Edits，并推送给NameNode；在紧急情况下，可辅助恢复NameNode。

2.HDFS的读写流程

首先是写过程：

1. 客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。
2. NameNode返回是否可以上传。
3. 客户端请求第一个 Block上传到哪几个DataNode服务器上。
4. NameNode返回3个DataNode节点，分别为dn1、dn2、dn3。
5. 客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。
6. dn1、dn2、dn3逐级应答客户端。
7. 客户端开始往dn1上传第一个Block（先从磁盘读取数据放到一个本地内存缓存），以Packet为单位，dn1收到一个Packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答。
8. 当一个Block传输完成之后，客户端再次请求NameNode上传第二个Block的服务器。（重复执行3-7步）。

接下来就是读过程：

1. 客户端通过DistributedFileSystem向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的DataNode地址。
2. 挑选一台DataNode（就近原则，然后随机）服务器，请求读取数据。
3. DataNode开始传输数据给客户端（从磁盘里面读取数据输入流，以Packet为单位来做校验）。
4. 客户端以Packet为单位接收，先在本地缓存，然后写入目标文件。

3.HDFS中，文件为什么以block块的方式存储

这么做是为了解决大文件存储和处理问题。
HDFS将大文件分割成若干块(block)，每块的大小通常设定为64M或128M。

4.小文件过多有什么危害，你知道的解决办法有哪些

危害大致有3点：

1. 存储空间浪费。每一个小文件都占有一个metadata的存储空间，导致存储空间资源被大量占用。此外，由于block块的设定，一个小文件也会占用至少一个block块的空间，造成存储空间的浪费。
2. Namenode压力大。因为NameNode是HDFS的主要管理节点，负责管理所有数据块和元数据信息，当小文件数量大到一定程度时，NameNode需要维护的metadata信息量就非常大，处理速度会变慢、响应时间变长甚至崩溃，使得整个系统性能受到限制。
3. 数据读写性能下降。当小文件过多时，我们在获取数据的过程中会产生大量的I/O操作，这样会极大地影响数据的读写效率，从而导致计算任务的延迟。

解决办法：

1. 将小文件合并，构建大文件。CombineTextInputFormat用于小文件过多的场景，它可以将多个小文件从逻辑上规划到一个切片中，这样，多个小文件就可以交给一个MapTask处理。
2. 利用SequenceFile将多个小文件打包成一个大文件。
3. 利用HBase进行存储。HBase是一种行式数据库，支持海量数据无限扩展，并且它可以提供快速的读取和写入操作，适用于高并发的场景。
4. 改变业务代码逻辑，避免产生大量的小文件。
   总之，应根据具体情况综合考虑以上措施，选择最适合自己的解决方案来做出改善。

5.在NameNode HA中，会出现脑裂问题吗？怎么解决脑裂

在NameNode HA中，的确会面临脑裂（Split Brain）的问题，具体表现为一个HA组中的多个节点彼此失去联系，各自认为自己属于正常工作状态，这样就会造成数据的不一致甚至损失。

为了避免脑裂，需要采取如下措施：

1. 使用专有硬件。一些大型企业通常会使用专有硬件，例如真实的高可用性软件解决方案，并将其整合进原有的数据中心架构以实践坚靠和速度快捷的架构等级。
2. 检查系统时间和NTP服务设置。由于分布式系统对于时间同步非常敏感，因此必须确保所有节点使用的时间是相同的，并且每个节点都应该配置一个NTP客户端来进行时间同步。
3. 使用专业能力强的负载均衡器。作为System Center Virtual Machine Manager(VMM)基础结构的核心组件之一，Windows Server中的虚拟网络负载均衡器已经被证实能够成功地规避了许多脑裂风险。
4. 手动释放竞争资源，请参阅Azure Stack教程。此外，您还可以借助应用程序代码锁定或协调机制帮助您规避脑裂的风险。

通过上述措施可以减少脑裂的风险，并确保HA组内节点之间能够相互通信，增强系统的健壮性和可靠性。

6.简述hadoop压缩和解压缩的框架

Hadoop提供了可定制的压缩和解压缩框架，可以在MapReduce作业和HDFS上使用。

Hadoop支持多种压缩算法，例如LZO、gzip、Snappy等。这些算法可用于压缩MapReduce中的输入和输出数据，也可用于对HDFS中存储的文件进行压缩和解压缩。

Hadoop的压缩和解压缩框架有以下几个主要组成部分：

1. 压缩Codec（编解码器）：为不同类型的压缩算法实现一个编码/解码器接口。它通常由两个类组成：一种是负责压缩数据的Compressor（压缩器），另一种是负责解压数据的Decompressor（解压器），它们以字节块的形式来读入和输出数据。
2. CompressionInputStream和CompressionOutputStream：它们是流过滤器，将原始输入或输出数据转换为压缩格式的数据。CompressionInputStream按照压缩数据块的大小从底层输入流中读取压缩数据，并将其解压并交还给用户。而CompressionOutputStream会把用户写入其中的数据压缩后再写入到底层的输出流中。
3. 输入输出格式InputFormat和OutputFormat：它们管理输入和输出数据的分片和格式化。Hadoop支持的所有标准输入和输出格式（如TextInputFormat和SequenceFileOutputFormat）也支持了压缩。

使用Hadoop的压缩/解压缩框架，我们可以在不影响代码的情况下使Hadoop MapReduce和HDFS中存储的数据获得更高的压缩比，并且不会对系统性能产生很大的影响。

7.Namenode的安全模式有了解吗

在HDFS上进行重大变更时（例如创建新的命名空间、将一个数据块移动到不同的目录等），Namenode会进入安全模式。安全模式是一种保护机制，它可以确保系统数据的完整性和一致性。当Namenode处于安全模式时，集群只允许读取数据，不允许写入或修改数据。

在安全模式下，Namenode会等待一定数量的数据节点连接，以确保至少有足够的数据副本来保障系统的可用性和数据的完整性。此外，在此阶段中，用户可以在不影响系统稳定性的前提下执行一些管理操作，例如添加或删除文件、修改数据块大小等。

由于安全模式会禁止写入操作，因此当变更完成后，需要手动退出安全模式以恢复正常写入操作。在退出安全模式时，Namenode会再次对元数据进行检查，以确认它们与存储在数据节点上的实际数据是一致的。

总之，Namenode的安全模式提供了一种保护机制，可以确保系统数据的完整性和一致性，并提供了一些管理操作以方便管理员进行必要的更改。

8.Secondary NameNode 了解吗，它的工作机制是怎样的

Secondary NameNode 是 HDFS 的一个组件，负责辅助 NameNode 负担某些工作。
Secondary NameNode 的主要工作是定期从主要的 NameNode 备份 HDFS 的编辑日志和元数据信息（Fsimage文件），以防止这些信息的损坏或丢失情况发生。它们通常被配置为每隔一段时间检查 NameNode，并在需要时备份其元数据。

Secondary NameNode 并不实际上代替主节点，它不能提供服务，也不参与用户请求的处理。相反，它只是一个辅助角色，帮助确保 NameNode 在失败情况下能够快速恢复数据服务，从而保证系统的可靠性和稳定性。

但需要注意的是，尽管 Secondary NameNode 能够提供一些保护措施，但是它并不能完全避免数据丢失或错误的情况发生。因此在进行重要任务和存储关键数据时，最好将备份策略与其他数据保护策略相结合，以确保数据最大程度上的可靠性和安全性。

9.在上传文件的时候，其中一个 DataNode 突然挂掉了怎么办

1. 客户端上传文件时与DataNode建立pipeline管道，管道正向是客户端向DataNode发送的数据包，管道反向是DataNode向客户端发送ack确认，也就是正确接收到数据包之后发送一个已确认接收到的应答；
2. 当DataNode突然挂掉了，客户端接收不到这个DataNode发送的ack确认，客户端会通知NameNode，NameNode检查该块的副本与规定的不符，NameNode会通知DataNode去复制副本，并将挂掉的DataNode作下线处理，不再让它参与文件上传与下载。

10.在读取文件的时候，其中一个块突然损坏了怎么办

客户端读取完 DataNode 上的块之后会进行 checksum 验证，也就是把客户端读取到本地的块与 HDFS 上的原始块进行校验，如果发现校验结果不一致，客户端会通知NameNode，然后再从下一个拥有该 block 副本的 DataNode 继续读。

11.介绍Namenode宕机的数据恢复过程

如果 NameNode 宕机了，可能会导致 HDFS 不可用。在这种情况下，需要一些步骤来恢复数据并重新启动 HDFS。以下是可能的 NameNode 宕机数据恢复过程：

1. 首先，通过备份机制和规范的操作方法，确保您有最新版本的 Fsimage 和编辑日志文件。
2. 手工启动一个 Secondary NameNode，以便将保存在 Fsimage 和编辑日志中的名称空间信息合并到新的 Fsimage 文件中。要做到这一点，运行 "hadoop namenode -checkpoint"命令可以强制执行 checkpoints 并减少数据损失风险。
3. 将新的 Fsimage 文件和编辑日志文件复制到另一个计算机上，并将配置文件更新为指向新计算机的地址，以确定该副本将成为新的 NameNode。
4. 在新计算机上启动 Hadoop 服务，并让其作为新的 NameNode 接管 HDFS 群集，从而继续提供服务并恢复数据。要启动服务，运行 “start-dfs.sh” 命令。
5. 配置相关集群参数。如允许 DataNodes 重新注册，等待集群稳定并允许所有节点重新注册以确保数据的复制与传输正常。

注意：频繁进行手动 Checkpoint 或在没有新写入 Fsimage 进行故障转移可能会严重影响性能，因此平衡 Fsimage备份和集群性能在 NameNode 安全和性能之间是必要的。

12.NameNode 在启动的时候会做哪些操作

当启动 NameNode 时，它会进行以下操作：

1. 加载文件系统元数据：NameNode 将从磁盘上的 Fsimage 文件和编辑日志文件中恢复文件系统元数据。然后，它将调用一个称为 “checkLeases()” 的过程来检查租约信息，并确保所有租约已经到期。
2. 启动 RPC 服务：NameNode 将启动 RPC 服务来处理客户端和 DataNode 节点的请求。它侦听名称节点与 DataNode 之间的通信，以及客户端向 HDFS 发出的请求。
3. 分配块 ID：NameNode 在运行时维护块标识符（ID）并为新创建的块生成唯一的块 ID。
4. 记录每个块存储位置信息：NameNode 通过在内存中保存各个块 ID 和它们所在 DataNode 的映射信息以记录哪个 DataNode 存储了每个块。这些信息在内存中缓存并定期写入硬盘持久化，以用于恢复和备份用途。
5. 处理各种状态更新：NameNode 处理 block 状态、DataNode 失效、副本错误等问题，例如，维护块的数量，范围和版本信息。
6. 初始化安全性相关内容：如果启用了 Hadoop 安全模式，则 NameNode 将加载关键库、证书、密钥表等安全性相关内容。

一旦完成上述操作，NameNode 就会准备好接收客户端和 DataNode 请求，并管理 HDFS 文件系统的元数据。

MapReduce面试重点

1. 简述MapReduce整个流程

1. 输入阶段：将需要进行分析和处理的数据存储在 HDFS 中，并将其拆分为多个块。然后将这些块作为输入传递给第一个 Map 阶段。
2. Map 阶段：在 Map 阶段中，每个数据块被发送到一个 Map 任务（或 Map 进程）中。在该任务内，数据块由 Mapper 函数转换为键值对。Mapper 函数将对每行文本应用特定的逻辑以提取所需数据。Map 阶段发生在每个 Map 任务处理的独立节点上；也就是说，每个 Map 任务都会产生一堆相同 key 的键值对。
3. Shuffle 阶段：Shuffle 过程是将 Map 阶段产生的输出（KeyValue 键值对）按照 Key 进行排序并分组。shuffle过程包括 3 个子阶段：分区（Partitioning）、排序（Sorting）、合并（Merging）。Shuffle 阶段是 MapReduce 架构非常关键的一步，用于将不同 Mapper 产生的 Intermediate Result 进行排序、归并，这一过程是整个 MapReduce 的瓶颈。
4. Reduce 阶段：在 Reduce 阶段中，Reducer 函数将按 key 分组的所有键值对提取出来并进行特定的计算操作。每个组合（key）结果会生成一个新文件。Reduce 阶段的输出通常是存储在 HDFS 或数据库中的结果集。
5. 输出阶段：最终的输出可以以多种格式进行保存，并以指定的目录结构存储在 HDFS 中，供后续的数据分析和业务使用。

详细介绍MapReduce

• map阶段：首先通过把输入目录下的文件进行逻辑切片，默认大小等于block大小，并且每一个切片由一个maptask来处理，同时将切片中的数据解析成<key,value>的键值对，k表示偏移量，v表示一行内容；紧接着调用Mapper类中的map方法。将每一行内容进行处理，解析为<k,v>的键值对，在wordCount案例中，k表示单词，v表示数字1 ；
• shuffle阶段：map端shuffle：将map后的<k,v>写入环形缓冲区【默认100m】，一半写元数据信息（key的起始位置，value的起始位置，value的长度，partition号），一半写<k,v>数据，等到达80%的时候，就要进行spill溢写操作，溢写之前需要对key按照【分区算法默认是，分区号是根据key的hashcode对reduce
  task个数取模得到的。这时候有一个优化方法可选，combiner合并，就是预聚合的操作，将有相同Key 的Value 合并起来,
  减少溢写到磁盘的数据量，只能用来累加、最大值使用，不能在求平均值的时候使用】；然后到文件中，并且进行（多个溢写文件）；
  reduce端shuffle：reduce会同一分区的各个maptask的结果到内存中，如果放不下，就会溢写到磁盘上；然后对内存和磁盘上的数据进行（这样就可以满足将key相同的数据聚在一起）；
  【Merge有3种形式，分别是内存到内存，内存到磁盘，磁盘到磁盘。默认情况下第一种形式不启用，第二种Merge方式一直在运行（spill阶段）直到结束，然后启用第三种磁盘到磁盘的Merge方式生成最终的文件。】
• reduce阶段：key相同的数据会调用一次reduce方法，每次调用产生一个键值对，最后将这些键值对写入到HDFS文件中。

2. 手写wordcount

public class WordCountMapper extends Mapper<LongWritable, Text, Text, IntWritable>  {
    private Text outK = new Text();
    private IntWritable outV = new IntWritable(1);

    @Override
    protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException {

        // 1 获取一行
        String line = value.toString();

        // 2 切割
        String[] words = line.split(" ");

        // 3 循环写出
        for (String word : words) {
            // 封装outK
            outK.set(word);

            // 写出
            context.write(outK, outV);
        }
    }
}

public class WordCountReducer extends Reducer<Text, IntWritable, Text, IntWritable> {
    IntWritable outV = new IntWritable();

    @Override
    protected void reduce(Text key, Iterable<IntWritable> values, Context context) throws IOException, InterruptedException {
        int sum = 0;
        // 累加
        for (IntWritable value : values) {
            sum += value.get();
        }

        outV.set(sum);

        // 写出
        context.write(key, outV);
    }
}

3. join原理

1. Map Join 的原理
   Map Join 是将小数据集放入内存中，与大数据集进行 Join 操作。它适用于一个表较小，可以完整地放置在一个节点的内存中时使用。
   使用 Map Join 时，可以避免大量的 I/O 操作和重复的计算。但是，其局限性在于，Map Join 只适合用于小表 Join 大表的情况，并且需要足够的内存空间来存储小表。
2. Reduce Join 的原理
   Reduce Join 是在 Reduce 阶段进行 Join 操作，主要适用于多个大表 Join 的情况。
   使用 Reduce Join 时，需要耗费更多的计算和 I/O 资源，因为在执行 Map 阶段时需要处理多个大表，而且在 Shuffle 过程中也会产生大量的网络通信。但是，在大型数据集合上执行 Join 时，Reduce Join 可以处理更多的数据，并且避免了内存溢出问题。

4. 文件切片相关问题

文件切片（File Splitting）也叫数据块（Data Block），是指将大型文件分割成多个较小的块，并将这些块存储在不同的计算机节点上，以便大量的数据可以并行处理。

文件切片操作可能会遇到以下问题，需要采取相应的解决办法：

1. 数据块丢失或损坏：当某个数据块在存储或传输过程中出现了丢失或者损坏，就会导致整个文件无法恢复。可以通过引入纠删码等技术来进行容错和数据校验，提高数据可靠性和一致性。
2. 过多的小文件：如果将一个大文件切分成过多的小文件，会增加元数据的数量，降低整体处理效率。需要合适地调整切片大小，使每个块能够更好地符合计算任务的需求。
3. 切片之间关联性不明显：对于涉及时间、空间等概念的文件，如果不能很好地确定切片之间的关联性，会影响数据分析结果，因此需要引入类似时间戳和位置信息等元数据来解决这些问题。
4. 跨计算机节点传输数据带来的网络负载大：当采用分布式存储进行数据块传输时，由于数据块的数量较大，可能会导致网络带宽占用较高，在处理时间上也可能增加延迟。可以通过数据压缩、数据去重等技术降低网络负载和增强数据传输效率。

5. 环形缓冲区的底层实现

环形缓冲区的底层实现通常采用数组实现。具体来说，我们可以定义一个 char 类型数组 buffer，同时使用两个指针 read_ptr 和 write_ptr 分别表示当前读取和写入数据的位置。

当需要向环形缓冲区中写入数据时，我们可以计算出待写入数据的长度 len，并通过 write_ptr 指针进行写入。如果缓冲区末尾没有足够的空间存储这些数据，那么我们还需要将 write_ptr 指针置为缓冲区开头，继续从头开始写入。

当需要从环形缓冲区中读取数据时，我们首先需要计算有效数据的长度 len，并通过 read_ptr 指针进行读取。如果缓冲区末尾没有足够的数据供读取，那么我们同样将 read_ptr 指针置为缓冲区开头，继续从头开始读取。

要特别注意的是，当读写指针等于缓冲区的末尾时，它们需要被重新设置为缓冲区的开头，以便继续循环使用缓冲区。

另外，为了保证多线程访问环形缓冲区的安全性，我们可以对 read_ptr 和 write_ptr 定义为原子变量或者使用互斥锁来进行保护。

6. 全排序

7. MapReduce实现TopK算法

1. Mapper 阶段：将输入数据按照一定的规则进行拆分，然后对每个记录进行处理，将其映射为 （key, value） 键值对。
   例如，如果要找出文本中出现次数最多的前 10 个单词，则 Mapper 需要将每个单词拆分出来，并以单词作为 key，value 则置为 1。
2. Shuffle 阶段：对 Mapper 阶段输出的每个键值对进行大小排序，将同一个 key 的所有记录组织到一起，形成一个子列表。
3. Reducer 阶段：对每个子列表进行处理，选择其中出现次数最多的前 K 个元素，并将结果作为输出数据。

Yarn面试重点

1. 简述yarn集群的架构

YARN 集群的架构主要包括以下三个组件：

1. ResourceManager（RM）：资源管理器是 YARN 的核心组件，负责集群资源的调度与管理，分配给正在运行的应用程序。
2. NodeManager（NM）：每个节点都有一个 NodeManager，用于管理该节点的计算资源和内存，并向 ResourceManager 报告可用资源为了让 RM 分配资源给正在等待资源的应用程序。NodeManager 负责启动和监控分配到本节点上的容器运行环境，保证应用程序能够运行。
3. ApplicationMaster（AM）：每个应用程序都会有一个唯一的 ApplicationMaster，它是应用程序的管理者。ApplicationMaster 向 ResourceManager 申请需要的资源，然后分配各个任务并协调任务的执行，以顺利地完成整个作业或应用程序。

2. yarn的任务提交流程是怎样的

1. 客户端提交应用程序
   首先，客户端需要将应用程序和相关参数提交给 YARN 集群，以便在集群中启动该应用程序。这一过程通常使用命令行界面或 API 接口来实现。
2. ResourceManager 接收应用程序请求。
   当客户端提交请求后，ResourceManager 会接收到该应用程序的请求，并执行相应的处理操作。ResourceManager 负责整个 YARN 集群的资源分配和管理，并且会在集群内检查可用资源量、各节点的 CPU 使用情况、磁盘使用率等信息。
3. ResourceManager 启动 ApplicationMaster。
   一旦 ResourceManager 确定了最适合运行该应用程序的 NodeManager，它就会向该节点的 NodeManager 发送命令启动 ApplicationMaster。ApplicationMaster 是该应用程序的主管，负责协调和管理应用程序的各个任务和容器之间的交互，同时向 ResourceManager 请求资源。
4. ApplicationMaster 向 ResourceManager 请求资源和节点。
   ApplicationMaster 向 ResourceManager 发送资源请求和节点分配请求，以确保应用程序有足够的计算和存储资源来运行。接下来 ResourceManager 在集群中寻找合适的节点上的空闲容器来分配运行该应用程序的各个任务。
5. NodeManager 运行任务。
   一旦 ResourceManager 分配给 NodeManager 的容器准备就绪，NodeManager 会使用 Linux 的控制组（cgroups）功能来确保该容器在节点上运行时不会超出约定的计算和内存限制。应用程序的各个任务会在分配给每个容器后运行于该容器中，并开始执行计算逻辑。
6. ApplicationMaster 监视任务状态。
   ApplicationMaster 将从各个容器上搜集和监视实时任务数据、统计结果和错误信息等所有数据，并推送这些信息到应用程序的管理者手中，以便进行处理或作为可视化展示供用户查看。如果某个任务失败，ApplicationMaster 将尝试重新启动该任务，直到它能够成功完成。
7. 应用程序结束。
   当 ApplicationMaster 确定所有任务都已完成或因某种错误导致无法继续运行时，它将向 ResourceManager 汇报状态并退出。ResourceManager 收到汇报后将会释放使用过的资源，并将消息反馈给客户端，表示该应用程序已经结束。

总体来说，YARN 的任务提交流程是一个复杂的过程，需要管理者多个组件之间的协调来实现。此流程充分利用了 YARN 的优点，使得分布式应用程序在 Hadoop 集群中更加高效地扩展和部署。

3. yarn的资源调度的三种模型

1. FIFO调度器（FIFO Scheduler）
   先进先出，但不适合资源公平性。
2. 容量调度器（Capacity Scheduler）
   独立的专门队列保证小作业也可以提交后就启动，队列容量是专门保留的。
   以整个集群的利用率为代价，与FIFO比，大作业执行的时间要长。
3. 公平调度器（Fair Scheduler）
   不需要预留资源，调度器可以在运行的作业之间动态平衡资源，大作业启动时，因为是唯一运行的，所以获得集群的所有资源，之后小作业启动时，被分配到集群的一半的资源，这样每个作业都能公平共享资源。

4. 简述Hadoop1.0 2.0 3.0区别

Hadoop 2.0 引入了 YARN 资源管理器，使得集群扩容更为方便，而 Hadoop 3.0 则进一步完善了 HDFS 文件系统以及 YARN 进行强化升级, 同时支持其它优秀生态组件同时运行在分布式计算框架上，提高了框架本身在大规模数据处理中的效率和灵活性。

5. 任务的推测执行（spark ui见过）

任务的推测执行是 Hadoop 中一项用于提高作业执行效率的功能。在 Hadoop 集群中，由于网络带宽、磁盘 IO、节点负载等因素的不确定性，总有一些任务会出现迟到或超时等问题。为了降低这种由于某一个任务处理速度过慢导致整个作业的完成时间延长的影响，Hadoop 引入了“推测执行”机制。

具体来说，在启用推测执行机制后，Hadoop 会在任务运行缓慢或者完成时间过长的时候会尝试启动一个备份任务，让两个任务并行执行，如果其中一个任务领先于另一个任务完成，则 Hadoop 就会杀死落后的任务以便占用更多的资源，从而加快整个作业的完成速度。需要注意的是，此方式仅适用于非常耗时的 MapReduce 任务，对于即时处理和时间敏感的任务不一定适用。

总之，任务的推测执行功能虽然不能解决所有的延迟问题，但能够有效地增加整个作业的执行效率，减少整个集群的闲置时间，并节省了大量的计算资源和经济成本。