守株阁

上一篇解决了 Spark 在 YARN 和 K8s 上的部署模式。这一篇进入资源调度——在多个作业共享集群时，Spark 如何动态分配和回收资源。 默认情况下，一个 Spark 应用在启动时申请固定数量的 Executor，作业结束前一直占用。这在单用户开发环境下可以接受，在多租户生产集群中会造成严重的资源浪费——一个空闲的 Spark 应用占着 100 个 Executor 不释放，其他作业排队等待。 本文只抓一个问题：动态资源分配如何按需申请和释放 Executor，以及 FAIR 调度器如何在多个作业之间公平分配资源。 动态资源分配（DRA） Dynamic Resource Allocation（DRA）允许 Spark 应用根据工作负载动态增减 Executor 数量：有 pending Task 时申请新 Executor，Executor 空闲超时后释放。 12345678910111213141516作业生命周期中的 Executor 数量变化: Executor 数量 8 │ ┌────┐ 6 │ ┌────┤ ├──...

上一篇解决了流处理的时间语义。这一篇进入部署架构——Spark 如何在不同的集群管理器上运行。 Spark 的一个设计决策是把计算引擎和资源管理解耦。SparkContext 通过 SchedulerBackend 接口与集群管理器交互，不绑定任何特定的资源管理系统。这让同一份 Spark 代码可以运行在 Standalone、YARN、Kubernetes 或 Mesos 上，只需要切换启动参数。 本文只抓一个问题：Client Mode 和 Cluster Mode 的区别，以及 YARN 和 Kubernetes 两种主流部署模式各自的架构特点。 Driver 和 Executor 的角色 123456789101112131415┌──────────────────────────────────────────────────┐│ Driver (SparkContext 所在进程) ││ ├── DAGScheduler: RDD → Stage ││ ├── TaskScheduler...

上一篇解决了 Structured Streaming 的基本模型。这一篇进入时间语义——事件时间、水位线和状态管理。 流处理中的"时间"不是一个简单的概念。一条消息有两个时间戳：事件时间（Event Time，事件实际发生的时间）和处理时间（Processing Time，Spark 收到消息的时间）。两者可能差距很大——网络延迟、消费积压、跨时区传输都会导致消息乱序到达。 本文只抓一个问题：Watermark 如何告诉 Spark “多晚的数据还值得等”，以及 State Store 如何持久化窗口状态。 事件时间 vs 处理时间 123456789101112事件发生 网络传输 Spark 收到 t=10:00:01 ~~~延迟 3s~~~ t=10:00:04 (Processing Time) t=10:00:02 ~~~延迟 1s~~~ t=10:00:03 t=10:00:03 ~~~延迟 8s...

上一篇解决了数据源 API 和谓词下推。这一篇进入流处理——Structured Streaming。 Spark 的流处理经历了两代：DStream（基于 RDD 的离散化流）和 Structured Streaming（基于 DataFrame/Dataset 的结构化流）。DStream 已经停止演进，Structured Streaming 是当前唯一推荐的流处理 API。 Structured Streaming 的核心模型可以用一句话概括：把流数据看成一张不断追加新行的无界表，复用 Spark SQL 的 Catalyst 优化器和 Tungsten 执行引擎来处理。 本文只抓一个问题：无界表模型如何工作，以及 MicroBatch 执行引擎如何把连续的流切成离散的批次。 无界表模型 12345678传统流处理的心智模型: 消息 → 处理函数 → 输出 (一条一条处理，每条消息触发一次计算)Structured Streaming 的心智模型: 数据源不断追加行到一张"输入表" 查询在整张表上持续运行 结果写入一张"输出表&qu...

上一篇解决了 AQE 的运行时优化。这一篇进入数据源层——Spark 如何把计算推到存储层执行。 查询优化不只发生在执行引擎内部。如果存储层能在读取数据时就过滤掉不需要的行和列，引擎需要处理的数据量会大幅减少。Spark 通过 DataSource API 和 Catalyst 的优化规则把这个能力标准化了：谓词下推（Predicate Pushdown）让存储层只返回满足条件的行，列裁剪（Column Pruning）让存储层只返回查询需要的列。 本文只抓一个问题：谓词下推和列裁剪如何从 Catalyst 的逻辑计划传递到数据源实现。 DataSource API 的两代演进 Spark 的数据源 API 经历了两代： 12345678910DataSource V1 (Spark 1.3+): 接口: InputFormat / OutputFormat + createRelation 谓词下推: 通过 PrunedFilteredScan trait 可选实现 问题: API 不够灵活，不支持流式读写，难以做细粒度优化DataSource V2 (Spark 2.3...

上一篇解决了 DataFrame 和 Dataset 的 API 演进。这一篇进入运行时优化——Adaptive Query Execution（AQE）。 传统查询优化器的一个根本问题是：优化发生在执行之前，依赖的统计信息可能不准确或完全缺失。AQE 把优化推迟到执行过程中——在每个 Shuffle 边界，收集实际的数据统计信息，然后用这些精确的统计重新优化后续 Stage 的执行计划。 本文只抓一个问题：AQE 的三个核心优化分别解决什么问题，以及运行时优化的反馈循环如何工作。 运行时反馈循环 AQE 的工作方式可以用一句话概括：执行一个 Stage → 收集 Shuffle 输出的统计信息 → 用统计信息重新优化下一个 Stage 的计划 → 执行下一个 Stage。 123456789101112传统执行: 编译期确定完整计划 → Stage 0 → Stage 1 → Stage 2 (统计信息可能不准，计划一旦确定不可修改)AQE 执行: 编译期确定初始计划 → 执行 Stage 0 → 收集 Stage 0 的 Shuffle 输出统计 →...

上一篇解决了 Catalyst 优化器的四阶段流水线。这一篇进入用户 API 层——RDD、DataFrame、Dataset 三代 API 的演进逻辑。 三者的区别容易被简化为"RDD 是低级 API，DataFrame 是高级 API"。更准确的说法是：三代 API 在类型安全和执行优化之间做了不同的取舍。RDD 完全类型安全但无法被 Catalyst 优化；DataFrame 完全被 Catalyst 优化但放弃了编译期类型检查；Dataset 试图兼顾两者，但付出了 Encoder 序列化/反序列化的代价。 本文只抓一个问题：三代 API 在内部表示、优化路径和序列化机制上的具体差异。 三代 API 的内部表示 1234567891011121314RDD[Person] └─ 内部存储: JVM 堆上的 Java/Scala 对象 └─ 优化路径: 无（用户代码是黑盒，Spark 无法查看函数内部） └─ 类型信息: 编译期完整保留（泛型参数 T = Person）DataFrame (= Dataset[Row]) └─ 内部存储: Uns...

上一篇解决了 Spark 的容错机制。这一篇进入 SQL 引擎的核心——Catalyst 优化器。 Spark SQL 不只是"在 Spark 上跑 SQL"。它是一个完整的查询编译器，把 SQL 文本或 DataFrame API 调用翻译成优化后的物理执行计划。这个翻译过程由 Catalyst 优化器驱动，经过四个阶段：解析、分析、优化、物理计划生成。 本文只抓一个问题：一条 SQL 从文本到可执行的物理算子树，中间经历了什么变换。 下图展示了 Catalyst 四阶段流水线和一条 SQL 在各阶段的变换过程： 四阶段流水线 12345678910111213141516171819202122232425SQL 文本 / DataFrame API │ ▼┌─────────────────┐│ ① Parsing │ SQL 文本 → Unresolved Logical Plan│ (ANTLR 解析器) │ 列名和表名尚未绑定到实际 schema└────────┬────────┘ │ ...

上一篇解决了 BlockManager 的存储管理。这一篇进入容错机制——Spark 如何在节点故障时恢复计算。 分布式系统的容错通常有两条路线：数据副本（每份数据存多份，一份丢了从副本恢复）和计算重放（不存副本，丢了从头重算）。Spark 选择了第二条路线——通过 RDD 的 Lineage（血统）记录计算路径，丢失的分区沿着 Lineage 重算。 本文只抓一个问题：Lineage 容错的优势和代价，以及 Checkpoint 和推测执行如何补充 Lineage 的不足。 下图对比了无 Checkpoint 时的全链重算和有 Checkpoint 时的截断恢复： Lineage 容错原理 每个 RDD 记录了自己的 dependencies——从哪些父 RDD 经过什么变换得来。当一个分区丢失时（Executor 故障、磁盘损坏），Spark 不需要从副本恢复，只需要找到该分区的父 RDD 分区，重新执行 compute 函数。 12345678910RDD-0 (HDFS) → RDD-1 (map) → RDD-2 (filter) → RDD-3 (reduceByK...

上一篇解决了 Tungsten 的内存管理和代码生成优化。这一篇进入存储体系——Spark 如何管理分布在集群中的数据块。 BlockManager 容易被忽略，因为用户代码很少直接和它打交道。但 RDD 的 persist/cache、Shuffle 的中间文件、广播变量的分发、累加器的聚合，底层全部通过 BlockManager 完成。它是 Spark 存储层的统一入口。 本文只抓一个问题：BlockManager 如何在内存和磁盘之间管理数据块，以及广播变量和累加器在这个体系中的位置。 BlockManager 架构 每个 Executor 上运行一个 BlockManager 实例，Driver 上也有一个（主要用于接收广播变量和累加器结果）。BlockManager 内部包含三个核心组件： 1234BlockManager├── MemoryStore 内存存储（堆内/堆外）├── DiskStore 磁盘存储（本地目录）└── BlockTransferService 网络传输（Netty） MemoryStore 负责在 JVM 堆内或堆外内存...