1. Spark核心架构解析

Apache Spark作为当今最主流的分布式计算框架之一，其架构设计充分体现了"内存计算"和"弹性数据集"的核心思想。我在实际生产环境中部署过多个Spark集群，发现其架构主要由以下关键组件构成：

Driver Program：这是整个Spark应用的"大脑"，负责将用户代码转换为DAG（有向无环图）并拆分为多个Task。我常遇到新手混淆Driver和Master的概念——Driver是逻辑控制中心，而Master是物理资源调度节点。

Cluster Manager：支持Standalone、YARN和Mesos三种模式。以YARN为例，在部署时需要注意：

• ResourceManager的内存分配策略
• NodeManager的本地磁盘空间配置
• 队列资源的动态划分机制

Worker Node：每个Worker可以运行多个Executor。在性能调优时，需要特别关注：

spark.executor.cores # 建议4-8核 spark.executor.memory # 需预留20%给系统 spark.local.dir # 使用SSD能显著提升shuffle性能

Executor：这是实际执行任务的JVM进程。通过JMX监控其堆内存使用情况时，我发现常见的OOM问题往往源于：

• 不合理的序列化配置
• 广播变量过大
• 数据倾斜导致单个Task负载过高

2. Spark运行原理深度剖析

2.1 弹性分布式数据集(RDD)

RDD是Spark最核心的抽象，其五大特性在源码中体现为：

1. partitions列表（数据分片）
2. compute函数（计算逻辑）
3. dependencies（依赖关系）
4. partitioner（分区策略）
5. preferredLocations（数据本地性）

在开发中，我总结出RDD操作的黄金法则：

• 窄依赖（如map）优先于宽依赖（如join）
• persist()缓存级别选择顺序：MEMORY_ONLY > MEMORY_AND_DISK > DISK_ONLY
• 避免创建超过10万个小文件（会压垮NameNode）

2.2 DAG调度与任务执行

当用户提交Spark作业时，会经历以下关键阶段：

1. 逻辑计划生成：将代码转换为RDD转换操作链
2. 物理计划生成：通过Catalyst优化器进行：
   • 谓词下推
   • 列裁剪
   • 常量折叠
3. Stage划分：根据shuffle依赖划分Stage边界
4. Task调度：采用FIFO或FAIR调度模式

我在调试Spark UI时，发现这些指标最值得关注：

Scheduler Delay > 200ms 说明资源不足 Task Deserialization Time > 1s 需要检查序列化方式 Shuffle Write Time 突增往往预示数据倾斜

3. 性能优化实战技巧

3.1 内存管理详解

Spark内存分为四大区域：

遇到频繁GC时，建议：

• 使用G1垃圾回收器
• 增加executor数量而非单个executor内存
• 对于Spark SQL作业，适当调大codegen缓存

3.2 数据倾斜解决方案

处理数据倾斜的七种武器：

1. 加盐处理：对倾斜key添加随机前缀

# 原始key为user_id的处理示例 df = df.withColumn("salted_key", concat(col("user_id"), lit("_"), (rand()*10).cast("int")))

2. 两阶段聚合：先局部聚合再全局聚合
3. 倾斜分离：将大key单独处理
4. 广播小表：小于100MB的表直接广播
5. 增加shuffle分区：spark.sql.shuffle.partitions=2000
6. 使用map-side join：对于大表join小表情形
7. 自适应查询执行(AQE)：Spark 3.0+自动处理倾斜

4. 生产环境部署指南

4.1 硬件配置建议

根据负载类型推荐配置：

• ETL作业：CPU密集型，建议：
  • 16-32核/节点
  • 64-128GB内存
  • 万兆网络
• 机器学习：内存密集型，建议：
  • 32+核/节点
  • 256GB+内存
  • GPU加速卡

4.2 高可用配置

确保关键服务HA：

1. ZooKeeper集群：至少3节点
2. HDFS JournalNode：奇数个节点
3. Spark History Server：配合S3持久化事件日志
4. 监控体系：
   • Prometheus + Grafana采集指标
   • ELK收集日志
   • 自定义报警规则示例：

     avg_over_time(spark_executor_metrics_memoryUsed[5m]) > 0.9 * spark_executor_memory

5. 典型问题排查手册

5.1 Executor丢失分析

错误现象：

ExecutorLostFailure: Executor 3 exited unexpectedly

排查步骤：

1. 检查对应节点的系统日志/var/log/messages
2. 分析YARN的nodemanager日志
3. 确认是否触发Linux OOM killer
4. 检查磁盘空间（df -h）
5. 验证网络连通性（ping/iperf）

5.2 Shuffle故障处理

当出现"Missing output location for shuffle"时：

1. 首先检查磁盘IO负载（iostat -x 1）
2. 确认spark.local.dir权限正确
3. 对于K8s环境，需要设置emptyDir sizeLimit
4. 极端情况下可以尝试：

   spark.shuffle.file.buffer=1MB spark.reducer.maxSizeInFlight=48MB

在Spark 3.x版本中，AQE（自适应查询执行）能自动解决80%以上的性能问题，建议通过以下配置开启：

spark.sql.adaptive.enabled=true spark.sql.adaptive.coalescePartitions.enabled=true spark.sql.adaptive.advisoryPartitionSizeInBytes=256MB