小菜鸟

spark入门实战：WordCount 程序全解析

WordCount（单词计数）是大数据领域的 “Hello World”，通过它可以快速理解 Spark 的核心概念和编程模型。本文以 Scala 为例，从环境准备、代码实现到执行原理，全方位讲解 Spark WordCount 程序，帮助初学者入门 Spark 分布式计算。

环境准备：版本匹配与依赖配置

Spark 对 Scala 版本有严格依赖，错误的版本组合会导致兼容性问题（如类找不到、方法异常），需提前确认版本对应关系。

版本选择原则

• Spark 2.x 主要支持 Scala 2.11、2.12；
• Spark 3.x 主要支持 Scala 2.12、2.13（但部分早期 3.x 版本对 2.13 支持不完善）；
• 推荐组合：Spark 3.1.1 + Scala 2.12.x（稳定性好，生态支持完善）。

Maven 依赖配置

在 pom.xml 中添加 Spark Core 和 Scala 依赖：

1
2
3
4
5
6
7
8
9
10
11
12
13

<!-- Scala 核心库 -->  
<dependency>  
  <groupId>org.scala-lang</groupId>  
  <artifactId>scala-library</artifactId>  
  <version>2.12.13</version>  <!-- 与 Spark 版本匹配 -->  
</dependency>  

<!-- Spark 核心依赖 -->  
<dependency>  
  <groupId>org.apache.spark</groupId>  
  <artifactId>spark-core_2.12</artifactId>  <!-- _2.12 表示适配 Scala 2.12 -->  
  <version>3.1.1</version>  
</dependency>  

注意：spark-core artifactId 中的 _2.12 必须与 Scala 版本一致，否则会出现 ClassNotFoundException。

WordCount 核心代码实现

WordCount 的核心逻辑是 “读取文本 → 拆分单词 → 计数聚合”，Spark 通过 RDD 算子实现分布式计算。

完整代码

spark与hadoop深度对比：从架构到场景的全方位解析

Spark 和 Hadoop 是大数据领域的两大核心技术，常被用于海量数据的存储、处理与分析。尽管两者都服务于大数据场景，但在设计理念、架构组成和适用场景上存在显著差异。本文从核心定位、架构组件、性能特性、适用场景等维度进行对比，帮助读者理解两者的区别与联系，合理选择技术方案。

核心定位与设计理念

Hadoop：分布式存储与计算的奠基者

Hadoop 是最早成熟的开源大数据框架，核心定位是 “分布式存储 + 批处理计算”，解决了海量数据的存储和离线处理问题。其设计理念源于 Google 的三篇论文：

• GFS（Google 文件系统） → HDFS（分布式存储）；
• MapReduce → Hadoop MapReduce（分布式计算）；
• BigTable → HBase（分布式数据库）。

Hadoop 的核心目标是通过廉价硬件集群实现高容错的大规模数据处理，强调 “磁盘友好” 和 “高容错性”，适合处理 PB 级离线数据。

Spark：内存计算驱动的通用引擎

Spark 诞生于 UC Berkeley AMP 实验室，核心定位是 “快速、通用的分布式计算引擎”，设计理念是 “内存优先” 和 “多场景融合”。Spark 不局限于批处理，而是通过统一引擎支持批处理、流处理、SQL、机器学习等多种场景，强调 “计算速度” 和 “开发效率”。

Eureka 简介：Spring Cloud 生态的经典服务注册中心

Eureka 是 Netflix 开源的服务发现组件，作为 Spring Cloud 早期推荐的注册中心，凭借高可用性设计和与 Spring 生态的无缝集成，成为微服务架构中服务治理的经典方案。它通过Eureka Server（注册中心）和Eureka Client（服务端 / 客户端）的角色分工，实现服务的注册、发现和健康管理。

Eureka 的核心架构

Eureka 的设计遵循AP 原则（可用性优先，兼顾最终一致性），核心组件包括：

Eureka Server（注册中心）

• 提供服务注册接口，存储所有可用服务的元数据（IP、端口、状态等）；
• 支持集群部署，通过节点间数据复制实现高可用；
• 提供 Web 控制台（默认地址 http://localhost:8761），直观展示服务状态。

Eureka Client（服务端 / 客户端）

• 服务提供者：启动时向 Eureka Server 注册自身信息，定期发送心跳证明可用性；

• 服务消费者：从 Eureka Server 拉取服务列表并缓存到本地，通过服务名调用接口；

  这种方式可以使得微服务不需要每次请求都查询Eureka Server，从而降低了Eureka Server的压力，如果Eureka Server所有节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者完成调用

• 内置轮询负载均衡算法，简化服务调用流程。

Eureka 的核心特性

Eureka 服务下线机制：确保注册中心实例准确性

在 Eureka 架构中，服务下线是维持注册中心注册表准确性的关键环节。默认情况下，Eureka 通过心跳检测机制自动剔除失效服务，但在某些场景（如服务异常崩溃）下可能出现延迟，导致无效实例残留。本文详细介绍 Eureka 服务下线的实现方式及手动干预手段。

Eureka 服务下线的默认机制

Eureka 通过心跳检测和自动剔除实现服务下线管理：

1. 心跳续约
   服务提供者（Eureka Client）启动后，会定期向 Eureka Server 发送心跳（默认每 30 秒一次），证明自身可用。心跳请求格式为：

   1	PUT /eureka/apps/{服务名}/{实例ID}?status=UP

2. 自动剔除

   • 若 Eureka Server 在90 秒内未收到心跳（可通过lease-expiration-duration-in-seconds配置），会将该实例标记为DOWN；
   • 标记后，Eureka Server 不会立即删除实例，而是等待一段时间（受自我保护机制影响）后从注册表中移除。

3. 自我保护机制的影响
   当 Eureka Server 触发自我保护（如网络分区导致心跳骤减），会暂停自动剔除功能，此时即使服务已下线，仍可能保留在注册表中，避免误删健康服务。

服务下线不及时的问题与原因

常见问题

• 服务已手动停止，但 Eureka Server 仍显示为UP状态，导致消费者调用失效实例报错；
• 服务异常崩溃（如进程被 kill），未执行正常下线流程，Eureka Server 无法及时感知。

原因分析

Spring Bean 实例化完整流程解析：从配置加载到 Bean 就绪

Spring Bean 的实例化是 IOC 容器的核心能力，并非简单的 “new 对象”，而是一套包含 “配置元信息解析→BeanDefinition 注册→容器增强→实例化→属性注入→初始化” 的完整链路。本文结合 BeanDefinitionReader、BeanDefinitionRegistry、BeanFactoryPostProcessor 等核心组件，从 “阶段拆解→组件作用→实战细节” 三个维度，彻底讲透 Bean 实例化的每一步。

Bean 实例化的整体链路（宏观视角）

Bean 实例化的本质是 “将配置元信息（XML / 注解）转化为可使用的 Bean 实例”，整体流程可分为 4 大阶段，每个阶段对应特定组件和职责：

graph TD
    A[阶段1:配置元信息加载] --> B[阶段2:BeanDefinition生成与注册]
    B --> C[阶段3:BeanFactoryPostProcessor增强]
    C --> D[阶段4:Bean实例化与初始化]
    D --> E["Bean就绪:可通过getBean()获取"]

每个阶段的核心目标：

• 阶段 1：读取外部配置（XML / 注解 / JavaConfig），转化为 Spring 可识别的 “元信息”；
• 阶段 2：将元信息封装为 BeanDefinition（Bean 的 “蓝图”），并注册到容器；
• 阶段 3：修改 / 增强 BeanDefinition（如替换占位符、动态注册新 Bean）；
• 阶段 4：基于 BeanDefinition 创建实例、注入属性、执行初始化，最终生成可用 Bean。

阶段 1：配置元信息加载 —— 告诉 Spring “要创建哪些 Bean”

Spring 无法主动感知需要创建的 Bean，必须通过配置元信息明确告知。配置方式分为 “XML 配置”“注解配置”“JavaConfig 配置”，对应不同的 BeanDefinitionReader 来加载。

1. 核心组件：BeanDefinitionReader（元信息读取器）

BeanDefinitionReader 是加载配置元信息的顶层接口，不同配置方式对应不同实现类：