二刷大数据（一）- Hadoop

大数据

4V

大数据的4V特征是描述大数据特性的四个关键维度，这四个特征分别为：

1. Volume（大量性）：

   • 大数据首先体现在其巨大的数据规模上，数据量极其庞大。传统的数据存储和处理系统难以有效应对如此大规模的数据集。数据不再是以MB或GB为单位，而是以TB（10¹²字节）、PB（10¹⁵字节）、EB（10¹⁸字节）乃至ZB（10²¹字节）来衡量，这些数据来源于各种各样的数据源，如社交媒体、传感器网络、交易记录、图像和视频文件等。

2. Velocity（高速性）：

   • 这个特征指的是大数据产生的速度之快以及需要实时或近实时处理的需求。数据不断快速生成并流动，要求分析系统能够迅速捕获、处理、分析与应用这些数据流。在许多应用场景中，如金融交易、物联网监控、社交媒体互动等，对数据的时效性有着极高的要求。

3. Variety（多样性）：

   • 数据类型的多样性意味着大数据不仅包含结构化的数据（如数据库表中的记录），还包含大量的半结构化和非结构化数据。这些数据形式多样，可以是文本、音频、视频、图像、地理位置信息、机器日志等，且不同数据间可能存在复杂的关联关系。处理多样化数据时，需要灵活的数据管理和分析工具。

4. Value（价值性）：

   • 尽管大数据本身具有低密度价值的特点，即大部分数据看似无用或价值不明显，但隐藏在其中的关键信息却可能极具商业价值、社会价值或科研价值。通过有效的数据挖掘、清洗、整合与分析，可以从庞杂的大数据中提取出有价值的知识和洞察，用于决策支持、趋势预测、个性化推荐等各种用途。因此，如何从海量数据中提炼价值是大数据应用的核心挑战之一。

Hadoop

概念

1. Hadoop是一个由Apache基金会所开发的分布式系统基础架构
2. 主要解决，海量数据的存储和海量数据的分析计算问题。
3. 广义上来说，Hadoop通常是指一个更广泛的概念-Hadoop生态圈

优势：

1. 高可靠性：Hadoop底层维护多个数据副本，所以即使Hadoop某个计算元素或存储出现故障，也不会导致数据的丢失。
2. 高扩展性：在集群间分配任务数据，，可方便的扩展数以干计的节点。
3. 高效性：在MapReduce的思想下，Hadoop是并行工作的，以加快任务处理速度。
4. 容错性：将失败的任务重新分配

Hadoop大版本区别

• 在 Hadoopl.x时代，Hadoop中的MapReduce同时处理业务逻辑运算和资源的调度，耦合性较大。
• 在Hadoop2.x时代，增加了Yarn。Yarn只负责资源的调度、MapReduce只负责运算
• Hadoop3.x在组成上没有变化。

Hadoop的主要版本迭代可以划分为三个大系列：

1. Hadoop 1.x：

   • 核心组件：主要包括Hadoop Distributed File System (HDFS) 和 MapReduce。
   • 设计特点：HDFS作为分布式存储系统，MapReduce作为并行计算模型，但在Hadoop 1.x中，MapReduce不仅是计算框架，还承担了作业调度和集群资源管理的角色。
   • 局限性：存在单点故障问题（NameNode没有高可用性）、不支持多租户和资源隔离、以及不灵活的计算框架（仅限于MapReduce）。

2. Hadoop 2.x：

   • 核心组件：同样包括HDFS，但引入了新的资源管理系统YARN (Yet Another Resource Negotiator)。
   • 改进之处：YARN解耦了资源管理和任务调度，使得Hadoop能够支持多个计算框架并存，比如MapReduce v2、Spark、Tez等。HDFS在2.x版本中添加了高可用（High Availability, HA）特性，通过Secondary
     NameNode或JournalNodes实现了NameNode的热备，消除了单点故障问题。此外，HDFS
     Federation增强了系统的可扩展性，允许多个NameNode管理集群的不同命名空间。

3. Hadoop 3.x：

   • 进一步增强：在Hadoop 2.x的基础上继续优化和增加新功能，例如：
     • HDFS：支持更大的文件块，提高了存储效率；可能还进一步提升了Namespace的扩展能力。
     • YARN：性能提升，资源分配策略更加精细，可能增加了更多容器级别的优化。
     • 其他改进：还包括对安全性和可管理性的增强，以及对容器化部署和云环境更好的支持。

总的来说，从1.x到3.x的演进过程中，Hadoop逐渐变得更加健壮、灵活和高效，不仅提升了自身的可靠性、可扩展性，也更好地适应了大数据生态系统不断发展的需求。各版本间还有许多具体的技术细节差异，例如网络协议的改进、API的变化以及对新硬件特性的支持等。

HDFS

Hadoop分布式文件系统（HDFS）是一种专为大型分布式计算和海量数据存储而设计的文件系统，它采用主/从（Master/Slave）架构来管理和存储数据。下面是HDFS工作原理的简单描述：

1. NameNode（主节点）：

   • HDFS集群有一个中心节点，即NameNode，它是整个文件系统的管理者，负责维护文件系统的命名空间，管理数据块映射信息，以及处理来自客户端的所有文件系统元数据相关的操作请求，如打开、关闭、重命名文件或目录等。

2. DataNode（从节点）：

   • 许多DataNode构成集群的主体，它们负责实际的数据存储。每个DataNode将数据存储在其本地硬盘上，按照HDFS的块（默认一般是128MB或256MB）进行切分。每一个数据块都会有多份副本存储在不同的DataNode上，以此提供数据冗余和容错机制。

3. 数据存储与冗余：

   • 当客户端写入数据时，NameNode指导客户端将文件拆分成数据块并将各个块存储到DataNode集群上。数据块的副本数量可以根据配置分布在不同的机架和节点上，确保即使部分硬件故障也能保证数据的完整性和可用性。

4. 数据读取：

   • 客户端读取数据时，首先向NameNode查询所需文件的数据块位置信息，然后直接与DataNode建立连接读取数据。HDFS能优化读取性能，例如当数据块有多个副本时，会选择网络距离最近或I/O性能最优的副本供客户端读取。

5. 心跳检测与块报告：

   • DataNode定期向NameNode发送心跳信号以表明其在线状态，并报告其所存储的数据块列表。这样，NameNode始终掌握着集群的全局视图，可以及时响应数据块的增删改查操作。

6. 故障检测与恢复：

   • 如果NameNode检测到某个DataNode失效，则会触发重新复制失效节点上的数据块至其他存活节点，以维持预设的冗余级别。同时，DataNode间的通信机制也支持数据完整性校验，确保数据正确无误。

综上所述，HDFS通过集中式的元数据管理、分散式的数据存储以及动态的块复制和故障恢复机制，有效地支持了大规模数据的存储和访问需求。

产生背景

随着数据量越来越大，在一个操作系统存不下所有的数据，那么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统。HDFS只是分布式文件管理系统中的一种。
适合一次写入，多次读出

1. 高容错性
   • 存储副本防止丢失后自动恢复
2. 大数据
3. 部署在廉价机器上

——

1. 不适合低延时数据访问，比如毫秒级的存储数据，是做不到的。
2. 无法高效的对大量小文件进行存储。
   • 存储大量小文件的话，它会占用NameNode大量的内存来存储文件目录和块信息。这样是不可取的，因为NameNode的内存总是有限的;小文件存储的寻址时间会超过读取时间，它违反了HDFS的设计目标。
3. 不支持并发写入、文件随机修改。
   • 一个文件只能有一个写，不允许多个线程同时写；仅支持数据append（追加），不支持文件的随机修改。

架构

HDFS官方架构

文件块大小

HDFS文件物理上是分块存储的，块大小可以通过配置决定，2.x 3.x 版本默认128M，可以在hdfs-default.xml中修改dfs.blocksize决定
寻址时间是传输时间1%最好

• HDFS的块设置太小，会增加寻址时间程序一直在找块的开始位置
• 如果块设置的太大，从磁盘传输数据的时间会明显大。导致程序在处理这块数据时，会非常慢

写文件流程

读数据流程

NameNode & SecondNameNode

HDFS（Hadoop Distributed File System）的NameNode和SecondaryNameNode共同作用于HDFS的元数据管理，确保数据的高可用性和安全性。以下是两者如何配合工作的详细说明：

1. NameNode（主节点）：

   • NameNode是HDFS集群的中心控制器，负责管理文件系统的命名空间，即文件和目录树结构。
   • 存储所有文件系统的元数据信息，如文件块到DataNode的映射、文件的属性（如权限、修改时间等）。
   • 接收客户端的所有元数据操作请求，如打开、关闭、重命名文件或目录等。
   • 维护一份FsImage文件，这是HDFS文件系统全局的静态视图，包含所有文件和目录的元数据信息。
   • 使用EditLog文件记录对元数据的所有修改操作。

2. SecondaryNameNode（辅助节点）：

   • SecondaryNameNode并非NameNode的实时备份，而是扮演一个合并和检查点服务的角色。
   • 定期（可通过配置参数设定间隔时间）从NameNode下载FsImage和EditLog文件。
   • 在本地磁盘上合并FsImage和EditLog，生成一个新的FsImage，这个过程叫做checkpointing。
   • 一旦合并完成，SecondaryNameNode将新的FsImage文件推送给NameNode，NameNode会替换旧的FsImage文件，并清空或截断EditLog，从而避免EditLog过度增长。

通过这种方式，SecondaryNameNode减轻了NameNode的压力，减少了重启NameNode时必须重放的EditLog记录的数量，加快了集群恢复速度。然而，SecondaryNameNode并不能替代NameNode的故障恢复，因为它并不提供高可用性解决方案，即在NameNode发生故障时，SecondaryNameNode无法立即接管NameNode的服务。

在较新的Hadoop版本中，尤其是在Hadoop 2.x及以后的版本，已经引入了HA（High Availability）架构，通过Active/Standby NameNode模式取代了SecondaryNameNode，从而实现了真正的NameNode高可用性。在这种模式下， standby NameNode可以实时地与active NameNode共享编辑日志，并时刻准备在active NameNode出现故障时切换为active状态。

DataNode工作机制

HDFS（Hadoop Distributed File System）的DataNode是HDFS集群中的工作节点，负责实际存储文件数据并执行与数据相关的读写操作。以下详述DataNode的主要工作机制：

1. 启动与注册:

   • 当DataNode启动时，它会向NameNode发送注册请求，报告其自身的身份信息（如主机名、端口等）和存储能力。
   • DataNode同时会告知NameNode它所持有（或新加载）的所有数据块（Block）的信息，包括数据块ID、数据长度、校验和、存储位置等元数据。NameNode将这些信息整合到全局的块映射表中，用于后续的文件定位和数据调度。

2. 心跳与块报告:

   • DataNode周期性地（通常为每3秒一次）向NameNode发送心跳消息，以表明其处于正常运行状态。心跳机制是NameNode监控DataNode存活状态的关键手段。
   • 心跳消息可能还包括一个块报告（BlockReport），该报告详列了DataNode上所有数据块的最新状态。块报告的提交频率通常远低于心跳频率（如每小时一次或根据配置设定），用于定期同步DataNode的完整数据块清单，确保NameNode的元数据与实际数据分布保持一致。

3. 数据读取服务:

   • 当客户端发起读取请求时，NameNode会返回文件的元数据信息，包括构成该文件的所有数据块及其对应的DataNode列表。
   • 客户端直接与包含所需数据块的DataNode建立连接，发起读取请求。DataNode接收到请求后，从本地磁盘读取数据，并通过网络流式传输给客户端。如果有多个副本，客户端可能会从多个DataNode并发读取以提高读取速度。

4. 数据写入服务:

   • 写入过程由客户端协调，首先客户端向NameNode申请新的数据块ID和目标存储DataNode列表。
   • 客户端将数据分块并直接写入选定的DataNode，每个DataNode接收数据后将其持久化到本地磁盘，并向客户端发送确认消息。
   • 为了保证数据冗余，HDFS通常会复制数据块到其他DataNode，这一过程也由客户端协调，确保所有指定的副本节点都成功写入数据后，才认为写操作完成。

5. 数据完整性保障:

   • DataNode在存储数据块时，除了实际数据外，还会维护与数据块相关的元数据，如数据块长度、时间戳、校验和等，用于验证数据的完整性。
   • 在读取数据时，DataNode会对读出的数据执行校验，确保传输给客户端的数据未被损坏。此外，客户端也可能执行额外的校验，如CRC校验，以双重保障数据的正确性。

6. 块复制与删除:

   • NameNode通过心跳响应或单独命令通知DataNode执行块级别的操作，如复制某个数据块到其他DataNode以满足冗余策略，或者删除不再需要的副本。
   • DataNode根据这些指令与其他DataNode直接交互，进行数据块的复制或删除操作。

7. 故障检测与恢复:

   • 如果DataNode未能在预设时间内发送心跳，NameNode会认为该节点已失效，并将其从活动节点列表中移除。
   • 对于失效节点上的数据块，NameNode会调度剩余的健康节点创建丢失副本，以恢复文件的冗余级别。当失效节点恢复后，它需要重新注册并向NameNode报告其数据块状态，NameNode会根据集群的整体状况决定是否需要恢复或删除该节点上的过期数据。

综上所述，DataNode作为HDFS的核心组件之一，主要负责存储数据、响应客户端读写请求、维持与NameNode的通信、执行数据块管理命令，并通过各种机制确保数据的可靠性和完整性。

YARN

资源管理器，管理的就是CPU and Mem

YARN是在Hadoop集群的计算节点上运行的软件服务，它并不涉及物理硬盘上的数据存储，而是专注于管理和调度计算任务所需的CPU、内存等资源，使得这些资源能够在众多并行任务之间合理、高效地分配和利用。而数据存储则由HDFS（Hadoop Distributed File System）负责，HDFS才是将数据分布存储在集群中各个节点的硬盘上的系统。

YARN（Yet Another Resource Negotiator）是Apache Hadoop的一个组件，它在Hadoop 2.x及更高版本中被引入，作为更通用的资源管理和调度平台。YARN的工作原理可以概括如下：

1. 角色划分：

   • ResourceManager（RM）：集群的全局资源管理器，负责整个集群的资源调度，它有两个主要子组件：

     • Resource Scheduler：根据特定策略（如公平调度器或容量调度器）将集群内的计算资源（CPU、内存等）分配给各个应用程序。
     • Application Manager：接收来自客户端的作业提交请求，为每个应用程序分配唯一的ApplicationMaster，并监控其生命周期。

   • NodeManager（NM）：在每台集群节点上运行，负责容器的启动、监控和管理。容器是YARN的基本资源单元，封装了CPU、内存等资源。

   • ApplicationMaster（AM）：每个提交到YARN的应用程序都有自己的AM，负责与ResourceManager协商资源，并与NodeManager协作，获取并分配容器，监控和管理容器内的任务执行，直到作业完成。

   • Container: 分配的执行任务的容器，相当于子虚拟机。

   • 客户端可以有多个、集群上可以有多个ApplicationMaster、每个NodeManager可以有多个Container
     

2. 工作流程：

   • 作业提交：用户通过客户端向ResourceManager提交作业，并上传作业相关的依赖文件到HDFS或其他存储系统。

   • 资源申请：ResourceManager接收到提交请求后，为该作业启动一个新的ApplicationMaster实例。ApplicationMaster启动后，向ResourceManager申请容器资源。

   • 资源分配：ResourceManager根据Resource Scheduler策略将容器资源分配给ApplicationMaster。

   • 任务执行：ApplicationMaster获得容器资源后，与NodeManager通信，指示其启动容器并在容器中执行具体的任务（如MapReduce任务、Spark任务等）。

   • 任务监控与管理：ApplicationMaster持续监控任务的状态，并在任务完成后释放容器资源，或在任务失败时重新申请资源以执行失败的任务。

   • 作业完成：当所有任务都成功完成时，ApplicationMaster向ResourceManager注册作业结束，释放所有已分配的资源。

通过这样的架构和工作流程，YARN实现了对集群资源的高效管理和灵活调度，支持多种计算框架在同一个集群上运行，极大地提高了Hadoop生态系统的利用率和兼容性。

MapReduce

算是一个框架，用户只需要关心逻辑，底层自动实现并发。。。

1. 于编程。用户只关心，业务逻辑。实现框架的接口。
2. 良好扩展性：可以动态增加服务器，解决计算资源不够问题
3. 高容错性。任何一台机器挂掉，可以将任务转移到其他节点。
4. 适合海量数据计算I(TB/PB）几千台服务器共同计算。
   不适合实时计算，流式计算

为什么不适合实时

MapReduce不适合进行实时计算的原因并非单一地由于其运行速度慢，而是由其设计哲学、执行模型以及对数据处理延迟的要求等多个因素综合决定的。以下是MapReduce不适合实时计算的主要原因：

1. 批处理性质：

   • MapReduce是一种批量处理模型，设计初衷是处理大规模离线数据集，如历史日志分析、大规模数据挖掘等场景。这类任务通常允许较长时间的延迟（分钟、小时甚至天级别），以便一次性处理大量数据。

2. 任务生命周期：

   • MapReduce作业的执行通常分为Map阶段（数据切片并行处理）、Shuffle阶段（中间结果排序、分区并传输）和Reduce阶段（全局聚合或复杂逻辑处理）。整个流程涉及多个阶段的启动、数据移动、合并等操作，导致端到端延迟较高，不适合对响应时间有严格要求的实时应用。

3. 数据处理模式：

   • MapReduce作业通常在数据完全生成并写入HDFS后开始处理，这意味着数据处理与数据生成之间存在明显的时滞。实时计算则要求数据几乎在生成瞬间就能得到处理和响应，这种“事件驱动”或“流式处理”的特性与MapReduce的批处理理念不符。

4. 缺乏低延迟交互：

   • 实时计算往往需要低延迟的查询响应，能够即时更新结果并反馈给用户或下游系统。MapReduce作业完成后才输出结果，无法满足实时查询和更新的需求。

5. 资源调度与启动成本：

   • MapReduce作业的提交、调度、任务分配、资源初始化等开销较大，对于小规模、频繁的实时查询来说，这种开销显得过于高昂且效率低下。

因此，MapReduce不适合实时计算并非单纯由于运行速度慢，而是由于其整体设计和执行模型与实时计算的需求（如低延迟、即时响应、流式处理）不匹配。对于实时计算任务，应选择专门的流处理技术来满足低延迟、高吞吐量和持续处理数据流的要求。

核心思想

1）MapReduce运算程序一般需要分成2个阶段：Map阶段和Reduce阶段
2）Map阶段的并发MapTask，完全并行运行，互不相干
3）Reduce阶段的并发ReduceTask，完全互不相干但是他们的数据依赖于上一个阶段的所有MapTask并发实例的输出
4）MapReduce编程模型只能包含一个Map阶段和一个Reduce阶段，如果用户的业务逻辑非常复杂，那就只能多个MapReduce程序，串行运行

### 使用自己的序列化？ Hadoop不使用Java提供的`Serializable`接口及其默认序列化机制，而是自定义了一套序列化体系（主要基于`Writable`接口），主要原因包括以下几个方面：

1. 性能优化：

   • 效率：Java标准序列化包含了较多元数据信息（如类名、签名等），这会导致序列化后的字节流相对庞大，不利于网络传输和磁盘存储，尤其是在处理大数据场景时，会对带宽和存储空间造成显著压力。Hadoop自定义的序列化机制（如Writable）通常更简洁、紧凑，专注于数据本身的编码，从而减少序列化后的数据体积，提高网络和磁盘I/O效率。

2. 对象复用：

   • 减少对象创建：Java标准序列化在反序列化时每次都会创建新对象，这在处理海量数据时可能导致大量的内存分配和垃圾回收，影响系统性能。Hadoop序列化允许对象的复用，即反序列化过程中可以重用已存在的对象实例，只需更新其字段值，从而降低内存消耗和GC负担。

3. 控制权与灵活性：

   • 定制化需求：Hadoop序列化机制允许开发者精细控制序列化过程，根据具体数据类型和应用场景定制高效的序列化和反序列化逻辑。这对于处理特定的大数据结构（如稀疏向量、压缩编码等）非常有利，可以实现更高的编码效率和解码速度。
   • 跨语言互操作性：虽然不是所有Hadoop序列化实现都具备此特点，但某些如Avro等支持跨语言的序列化格式，便于在不同编程语言间交换数据，而Java标准序列化主要局限于Java平台。

4. 兼容性与稳定性：

   • 版本变化：Java序列化依赖于类的详细结构，包括类名、字段顺序、继承关系等，一旦类的结构发生变化（如添加或删除字段、修改访问修饰符等），可能破坏序列化兼容性，导致旧数据无法正确反序列化。Hadoop序列化可以通过显式指定字段顺序和版本管理等方式更好地应对类结构变化，保证数据的长期稳定存储和迁移。
   • 安全性：Java标准序列化存在一定的安全风险，如远程代码执行漏洞，需要谨慎处理。Hadoop自定义序列化可以避免此类问题，提供更为安全的数据交换方式。

切片与MapTask原理

1kb数据启动多少个Task？1PB启动多少个Task？

• 数据块：Block是HDFS 物理上把数据分成一块一块。数据块是HDFS 存储数据单位。
• 数据切片：数据切片只是在逻辑上对输入进行分片，并不会在磁盘上将其切分成片进行存储。数据切片是MapReduce程序计算输入数据的单位，一个切片会对应启动一个MapTask。
  切片大小默认=blocksize，以文件为单位切片，一个文件单独切
  

MapTask机制

MapTask是MapReduce框架中负责执行Map阶段工作的独立任务单元。其工作机制可以概括为以下几个关键步骤：

1. Input Splitting and Record Reading（输入分片与记录读取）：

   • InputSplit：输入文件被逻辑划分为多个InputSplit（通常是与HDFS block大小相匹配的），每个InputSplit分配给一个MapTask处理。
   • RecordReader：MapTask使用指定的RecordReader（如默认的LineRecordReader）读取InputSplit中的数据。RecordReader按行（或其他指定格式）解析InputSplit，将其转换为键值对（<key, value>），如(key=行起始字节偏移量, value=整行文本)。

2. User-defined Map Function（用户自定义映射函数）：

   • Map(): 解析出的键值对被传递给用户编写的map()函数进行处理。在这个函数中，开发者可以执行特定的逻辑，如提取、清洗、转换数据，并生成新的键值对（<new_key, new_value>）。

3. Intermediate Key-Value Pair Collection（中间键值对收集）：

   • OutputCollector：经过map()函数处理后的键值对通过OutputCollector.collect(new_key, new_value)方法进行收集。此方法内部：
     • Partitioning：对新键进行分区，确定其应该被哪个Reducer处理。默认使用HashPartitioner基于键的哈希值将数据分发到不同的Reducer。
     • In-memory Buffering：将键值对写入到内存中的环形缓冲区。缓冲区的设计旨在暂时存储大量数据，减少频繁的磁盘I/O。

4. Spilling to Disk（溢写到磁盘）：

   • Sort and Spill：当环形缓冲区达到一定阈值（通常为内存的一定比例）时，触发溢写（spill）操作。溢写过程中：
     • Sorting：对缓冲区内的键值对进行排序（按照键），为后续的合并和Reducer阶段做好准备。
     • Write to Disk：将排序后的键值对写入到本地磁盘上的一个临时文件中。每个MapTask可能生成多个这样的临时文件。

     MapReduceApplicationMasterApplicationMaster

     MapReduceApplicationMaster是ApplicationMaster概念在MapReduce应用场景下的具体化实现。两者本质上是一致的，都是指在YARN环境中负责管理特定应用程序运行的实体，只不过前者是泛指所有类型应用程序的AM，而后者特指专用于MapReduce作业的AM实现。因此，可以说MapReduceApplicationMaster是ApplicationMaster的一个具体实例，是ApplicationMaster概念在MapReduce框架中的具体应用和体现

shuffle机制

MapReduce的Shuffle机制是连接Map阶段和Reduce阶段的关键步骤，负责将Map任务生成的中间键值对按照键进行重新分发，确保具有相同键的值能够被同一个Reducer处理。Shuffle过程包括以下几个核心环节：

1. Partitioning（分区）：

   • 在Map阶段，每个Mapper处理一部分原始数据，并为每对中间键值对（<key, value>）生成一个中间结果。这些结果需要按照键进行分区，确定它们应该被哪个Reducer接收。默认情况下，Hadoop使用HashPartitioner，通过哈希函数将键散列到固定数量的分区（与Reducer数量相等），保证相同键的值会被分配到同一个分区。

2. Sorting（排序）：

   • 在每个Mapper内部，对属于同一分区的所有中间键值对进行局部排序。排序依据是键，通常采用快速排序、归并排序等高效排序算法。排序确保了同一键的所有值在进入Reducer之前按键有序排列。

3. Spilling to Disk（溢写到磁盘）：

   • 当Mapper的内存缓冲区（环形缓冲区）填满时，MapReduce会启动溢写（spill）过程。溢写时，首先对内存中的键值对进行快速排序，然后写入到本地磁盘的一个临时文件中。这个过程可能会重复多次，每次溢写都会生成一个新的临时文件。

4. Intermediate Merge（中间合并）：

   • 当Mapper任务完成后，它拥有多个已排序的临时文件。此时，MapReduce会启动一个合并（merge）过程，将这些临时文件合并成一个或少数几个较大的、已排序的中间文件。合并过程中，如果配置了Combiner，还可以进行局部聚合，减少需要在网络上传输的数据量。

5. Transfer to Reducers（传输到Reducers）：

   • 合并后的中间文件被分割成多个分片（split），每个分片对应一个Reducer。TaskTracker（在YARN中为NodeManager）负责将分片通过网络传输到相应的Reducer所在的TaskTracker（或NodeManager）。Reducer接收到所有分片后，开始处理它们。

6. Final Merge（最终合并）：

   • Reducer接收到所有Mapper发送来的键值对后，对这些来自不同Mapper、但键相同的键值对进行合并（归并），形成一个全局有序的键值序列。在这个过程中，Reducer执行用户自定义的reduce函数，对每个键的所有值进行聚合运算，产生最终结果。

Shuffle机制确保了MapReduce框架能够高效、有序地处理大规模数据集，通过分区保证数据的均匀分布，通过排序为Reducer提供有序数据流以便高效聚合，通过溢写和合并优化内存使用和磁盘I/O，最后通过网络传输和Reducer处理完成全局的聚合和结果生成。Shuffle是MapReduce框架中最为复杂、也是最影响性能的部分，因此常常成为性能调优的重点。

ReduceTask

ReduceTask是MapReduce框架中负责执行Reduce阶段工作的独立任务单元。其工作机制主要包括以下几个关键步骤：

1. Copy阶段（数据复制）：

   • Fetcher：ReduceTask启动Fetcher线程，通过HTTP或类似协议从MapTask所在的节点远程拉取属于本ReduceTask的中间数据。这些数据是由MapTasks在完成Map阶段后生成并已排序的键值对集合。
   • Buffering：对于接收到的数据，如果其大小小于一定阈值，直接放入内存缓冲区；若超过阈值，则写入本地磁盘暂存。

2. Merge阶段（数据合并）：

   • In-Memory Merger：ReduceTask同时启动一个内存合并线程（inMemoryMerger），定期将内存缓冲区中的数据进行排序并与磁盘上已有的小文件进行合并，保持内存占用在合理水平。
   • On-Disk Merger：另一个磁盘合并线程（onDiskMerger）负责将磁盘上的多个小文件逐步合并成较大的、有序的中间文件，减少磁盘上的文件数量，优化后续读取效率。

3. Sort阶段（全局排序）：

   • Final Merge：当所有MapTask产生的中间数据都被Fetch到本地后，ReduceTask对内存和磁盘上的所有数据进行一次最终的归并排序。这一步确保所有属于同一ReduceTask的键值对按照键的顺序排列，满足Reduce函数所需的输入要求。

4. Reduce阶段（实际计算）：

   • Reducer：ReduceTask调用用户自定义的reduce()函数，该函数接收一个键及其对应的值列表（由Map阶段生成并经过排序的相同键的所有值）。reduce()函数对每个键的值列表进行聚合运算，产生最终的输出键值对。
   • Output Writing：Reducer产生的输出键值对被写入到HDFS（Hadoop Distributed File System），形成最终的处理结果。这个过程可能包括序列化、压缩等操作，以优化存储和后续访问。

5. Cleanup：

   • Resource Release：ReduceTask在完成所有计算和输出后，清理本地磁盘上临时存储的中间数据文件，释放占用的系统资源。

综上所述，ReduceTask机制主要围绕数据复制、多级合并排序、实际计算及结果输出展开，确保从Map阶段产生的大量中间数据经过高效整合与处理，最终转化为按应用需求组织的输出结果。这一过程中，ReduceTask有效地管理内存与磁盘资源，利用并行化手段加速数据移动与处理，确保整个MapReduce作业的顺利进行。

三者关系

常用端口

以下列举了Hadoop各个主要组件及其常用端口（基于Hadoop 2.x和3.x版本的信息汇总）：

Hadoop Distributed File System (HDFS)

• NameNode

  • RPC接口（内部通信）：8020 / 9000 / 9820（根据Hadoop版本和配置可能有所不同，其中9000通常是非HA模式下的默认端口）
  • Web UI端口：50070（Hadoop 2.x默认） / 9870（Hadoop 3.x默认）
  • HTTPS Web UI端口：50470（适用于安全Web访问）

• DataNode

  • 数据传输端口：50010（数据输出）和50020（数据输入）
  • 心跳与块报告端口：50075（管理和服务）
  • HTTP服务端口：通常用于Web UI展示

Yet Another Resource Negotiator (YARN)

• ResourceManager (RM)

  • RPC接口：
    • 主要RPC端口：8032
    • Scheduler IPC端口：8030（在某些旧版中提到过）
    • ResourceTracker IPC端口：8031
  • Web UI端口：8088（查看集群资源和应用程序状态）

• NodeManager (NM)

  • RPC通信端口：取决于配置，通常用于与ResourceManager和ApplicationMaster通信
  • Web UI端口：8042（用于查看NodeManager状态）

• ApplicationMaster (AM)

  • AM的具体端口因应用而异，由YARN动态分配