在大數(shù)據(jù)處理領域，Apache Spark 憑借其卓越的性能、易用性和統(tǒng)一的計算引擎，已成為事實上的行業(yè)標準。而 Spark SQL 作為 Spark 生態(tài)系統(tǒng)中最為活躍和核心的模塊之一。提供了使用熟悉的 SQL 語言或 DataFrame/Dataset API 來處理結構化數(shù)據(jù)的強大能力。對于絕大多數(shù) Spark 用戶而言，spark.sql("SELECT ...") 或 df.write.save(...) 是他們與 Spark 交互的起點。然而，在這看似簡單的一行代碼背后，隱藏著一個極其復雜、精密且高效的執(zhí)行引擎。理解 Spark SQL 的全生命周期，不僅有助于我們編寫出性能更優(yōu)的代碼，更能讓我們在面對性能瓶頸或疑難雜癥時，具備庖丁解牛般的診斷能力。

本文將帶領讀者踏上一段深入 Spark 內(nèi)核的旅程，詳細剖析一條 Spark SQL 語句從被提交到最終執(zhí)行結束所經(jīng)歷的每一個關鍵階段。我們將從最上層的 API 入手，逐層深入，穿越邏輯計劃、物理計劃、執(zhí)行計劃，直至最終的 Task 調(diào)度與執(zhí)行，完整地揭示這條“數(shù)據(jù)之龍”是如何被 Spark 引擎一步步解析、優(yōu)化、編譯并最終“馴服”的。

第一階段：入口與解析（Parsing）—— 將文本轉化為邏輯樹

一切的起點始于在 Spark Shell、JDBC/ODBC 服務或應用程序中提交的一條 SQL 語句。這個階段的核心任務是將人類可讀的、非結構化的 SQL 文本，轉化為 Spark 內(nèi)部可以理解和處理的結構化數(shù)據(jù)表示形式——抽象語法樹（Abstract Syntax Tree, AST）。

1. Catalyst 的核心地位

Spark SQL 的強大能力源于其內(nèi)置的查詢優(yōu)化器——Catalyst。Catalyst 是一個基于 Scala 編寫的、可擴展的查詢優(yōu)化框架，它采用函數(shù)式編程的思想，將整個查詢處理過程分解為一系列可組合、可重用的規(guī)則（Rules）。Catalyst 的設計哲學是“規(guī)則驅動”，這使得 Spark SQL 的優(yōu)化過程既靈活又高效。

整個生命周期的第一步，就是由 Catalyst 的 Parser 模塊來完成的。

2. 詞法分析與語法分析

當 SparkSession.sql("SELECT name, age FROM people WHERE age > 30") 被調(diào)用時，SQL 字符串首先被傳遞給 SparkSession 的 sql 方法。該方法內(nèi)部會調(diào)用 SessionState.sqlParser.parsePlan(sqlText)。

sqlParser 的具體實現(xiàn)通常是 SparkSqlParser，它繼承自 AbstractSqlParser。parsePlan 方法是解析的入口點。

解析過程分為兩個經(jīng)典的編譯原理步驟：

(1) 詞法分析（Lexical Analysis）：將輸入的字符流（SQL 字符串）分解成一系列有意義的“詞法單元”（Tokens）。例如，SELECT、name、>、30 等都會被識別為不同的 Token。Spark 使用 ANTLR4（Another Tool for Language Recognition）作為其詞法和語法分析器的生成器。ANTLR4 會根據(jù)預定義的 SQL 語法規(guī)則（.g4 文件）自動生成詞法分析器（Lexer）和語法分析器（Parser）。

(2) 語法分析（Syntax Analysis）：語法分析器接收詞法分析器產(chǎn)生的 Token 流，并根據(jù) SQL 的語法規(guī)則（上下文無關文法）來構建 AST。如果 SQL 語句不符合語法規(guī)則（例如，缺少 FROM 子句），則在此階段就會拋出 ParseException 異常。

3. 生成 Unresolved Logical Plan

ANTLR4 生成的原始 AST 是一個通用的、與 Spark 無關的樹形結構。SparkSqlParser 的職責就是遍歷這個 ANTLR AST，并將其轉換為 Spark Catalyst 內(nèi)部定義的 LogicalPlan 樹。

此時生成的 LogicalPlan 被稱為 Unresolved Logical Plan。為什么叫“Unresolved”？因為在這個階段，Catalyst 對查詢中涉及的表、列等元數(shù)據(jù)信息一無所知。例如：

• people 表是否存在？
• people 表的 schema 是什么？它有哪些列？
• name 和 age 列是否真的存在于 people 表中？
• age 列的數(shù)據(jù)類型是什么？

這些問題在解析階段都無法回答。因此，UnresolvedLogicalPlan 中的 UnresolvedRelation("people") 和 UnresolvedAttribute("name") 等節(jié)點都只是占位符，等待后續(xù)階段去“解析”（Resolve）它們。

總結第一階段：提交的 SQL 文本被詞法和語法分析器轉換為一棵結構化的、但元數(shù)據(jù)信息缺失的邏輯計劃樹（Unresolved Logical Plan）。這是整個生命周期的基石，后續(xù)所有操作都基于這棵樹進行。

第二階段：分析（Analysis）—— 賦予邏輯計劃生命

解析階段產(chǎn)生的 Unresolved Logical Plan 是一個“空殼”。分析階段的任務就是通過查詢 Spark 的 Catalog（元數(shù)據(jù)目錄），為這個空殼注入真實的元數(shù)據(jù)信息，將其轉化為一棵“已解析”的、語義完整的 Analyzed Logical Plan。

1. Analyzer 與 Rule-Based Transformation

這個階段的核心執(zhí)行者是 Analyzer。與 Parser 一樣，Analyzer 也遵循 Catalyst 的規(guī)則驅動范式。它內(nèi)部維護了一個 RuleExecutor，其中包含了一系列預定義的分析規(guī)則（Analysis Rules）。

Analyzer 會反復應用這些規(guī)則到邏輯計劃樹上，直到樹的狀態(tài)穩(wěn)定（即應用規(guī)則后樹不再發(fā)生變化）或者達到最大迭代次數(shù)。

2. 關鍵的分析規(guī)則

讓我們通過一個例子來看看 Analyzer 是如何工作的。假設我們有如下邏輯計劃：

Filter (age > 30)
  +- Project (name, age)
      +- UnresolvedRelation ("people")

Analyzer 會依次應用以下關鍵規(guī)則：

(1) ResolveRelations：這是最核心的規(guī)則之一。它會遍歷計劃樹，找到所有的 UnresolvedRelation 節(jié)點。對于 UnresolvedRelation("people")，Analyzer 會向當前 SessionState 的 Catalog 發(fā)起查詢。Catalog 是 Spark 管理所有數(shù)據(jù)庫、表、函數(shù)、視圖等元數(shù)據(jù)的中心。它可以是內(nèi)置的 InMemoryCatalog（用于臨時視圖），也可以是外部的 HiveExternalCatalog（用于持久化的 Hive 表）。如果 people 表存在，ResolveRelations 規(guī)則會將其替換為一個具體的 LogicalRelation 節(jié)點，并附帶上該表的完整 schema 信息（例如，StructType(StructField("name", StringType, true), StructField("age", IntegerType, true))）。

(2) ResolveReferences：在表關系被解析后，下一步是解析列引用。ResolveReferences 規(guī)則會處理 Project 和 Filter 中的表達式。它會檢查 name 和 age 是否存在于剛剛解析出的 people 表的 schema 中。如果存在，就將 UnresolvedAttribute("name") 替換為一個綁定了具體數(shù)據(jù)類型和位置信息的 AttributeReference。同時，它還會處理表達式中的類型推斷。例如，在 age > 30 中，30 會被推斷為 IntegerType，以匹配 age 列的類型。

(3) CheckAnalysis：在所有引用都被解析后，Analyzer 會進行一次最終的合法性檢查。它會驗證計劃樹中的所有操作在語義上是否合法。例如，GROUP BY 子句中的列是否都出現(xiàn)在 SELECT 列表中（在非聚合查詢中），聚合函數(shù)的使用是否正確等。如果發(fā)現(xiàn)任何語義錯誤，會在此階段拋出 AnalysisException。

經(jīng)過 Analyzer 的洗禮，我們的邏輯計劃就變成了：

Filter (age#1 > 30)
  +- Project (name#0, age#1)
      +- LogicalRelation (HadoopFsRelation, [name#0, age#1])

這里的 #0, #1 是 Catalyst 為每個 AttributeReference 分配的唯一 ID，用于在后續(xù)的優(yōu)化和執(zhí)行中精確地追蹤列。

總結第二階段：通過與 Catalog 交互并應用一系列分析規(guī)則，Unresolved Logical Plan 被賦予了真實的元數(shù)據(jù)和語義信息，成為一棵完整、合法、可被進一步處理的 Analyzed Logical Plan。

第三階段：邏輯優(yōu)化（Logical Optimization）—— 智能的查詢重寫

現(xiàn)在我們有了一個語義正確的邏輯計劃，但這并不意味著它是最優(yōu)的。編寫的 SQL 往往不是最高效的，可能存在冗余操作、低效的連接順序或可以利用的謂詞下推等優(yōu)化機會。邏輯優(yōu)化階段的任務就是應用一系列基于規(guī)則的優(yōu)化（Rule-Based Optimization, RBO） 和 基于成本的優(yōu)化（Cost-Based Optimization, CBO） 策略，對 Analyzed Logical Plan 進行等價變換，生成一個執(zhí)行代價更低的 Optimized Logical Plan。

1. Optimizer 與優(yōu)化規(guī)則

這個階段的主角是 Optimizer。和 Analyzer 一樣，它也是一個 RuleExecutor，內(nèi)部包含了大量的優(yōu)化規(guī)則。Spark 的優(yōu)化規(guī)則庫非常豐富，涵蓋了從簡單常量折疊到復雜的連接重排序等各個方面。

2. 核心優(yōu)化規(guī)則詳解

讓我們繼續(xù)以我們的例子為基礎，并稍作擴展，來展示一些關鍵的優(yōu)化規(guī)則：

原始 Analyzed Plan:

Project (name)
  +- Filter (age > 30)
      +- Join (people, cities, people.city_id = cities.id)
          :- LogicalRelation (people, [name, age, city_id])
          +- LogicalRelation (cities, [id, city_name])

(1) 謂詞下推（Predicate Pushdown）：

規(guī)則：PushDownPredicate

作用：將過濾條件下推到數(shù)據(jù)源或連接操作之前，盡早地減少數(shù)據(jù)量，從而節(jié)省后續(xù)操作的 I/O 和計算開銷。

變換：Filter (age > 30) 會被下推到 people 表的掃描操作之前。優(yōu)化后的計劃變?yōu)椋?/p>

Project (name)
  +- Join (Filter(age > 30) on people, cities, people.city_id = cities.id)
      :- Filter (age > 30)
      |   +- LogicalRelation (people, ...)
      +- LogicalRelation (cities, ...)

更進一步：如果 people 表是 Parquet、ORC 等支持謂詞下推的列式存儲格式，Spark 甚至可以將這個過濾條件下推到數(shù)據(jù)源讀取層，讓底層存儲引擎在讀取文件時就跳過不滿足條件的行組（Row Group）或條帶（Stripe），實現(xiàn)極致的 I/O 優(yōu)化。

(2) 列裁剪（Column Pruning）：

規(guī)則：ColumnPruning

作用：只讀取查詢最終需要的列，避免讀取無用的數(shù)據(jù)，節(jié)省 I/O 和內(nèi)存。

變換：最終查詢只需要 name 列。通過分析計劃樹的依賴關系，Optimizer 會發(fā)現(xiàn) cities 表的 city_name 列在整個查詢中從未被使用。因此，對 cities 表的掃描操作會被裁剪為只讀取 id 列。同時，people 表也只需要 name 和 city_id（用于連接），age 列在過濾后也不再需要。優(yōu)化后：

Project (name#0)
  +- Join (...)
      :- Filter (age#1 > 30)
      |   +- LogicalRelation (people, [name#0, city_id#2]) // age#1 僅用于過濾，過濾后不再需要
      +- LogicalRelation (cities, [id#3]) // city_name 被裁剪

(3) 常量折疊（Constant Folding）與布爾表達式簡化：

規(guī)則：ConstantFolding, BooleanSimplification

作用：在編譯期就計算出可以確定的常量表達式，并簡化復雜的布爾邏輯。

例子：WHERE 1 = 1 AND age > 30 會被簡化為 WHERE age > 30。WHERE length("hello") > 3 會被直接計算為 WHERE true。

(4) 連接優(yōu)化（Join Optimization）：

規(guī)則：ReorderJoin, CostBasedJoinReorder (CBO)

作用：決定多表連接的最佳順序。RBO 通常采用啟發(fā)式策略（如將小表放在前面），而 CBO 則會利用表的統(tǒng)計信息（如行數(shù)、列的 NDV - Number of Distinct Values）來估算不同連接順序的代價，選擇最優(yōu)方案。

(5) 子查詢優(yōu)化：

規(guī)則：RewriteCorrelatedScalarSubquery 等

作用：將相關子查詢重寫為等價的連接（Join）操作，因為 Spark 的執(zhí)行引擎對 Join 的優(yōu)化和支持遠比對子查詢的要成熟和高效。

總結第三階段：Optimizer 通過應用一系列精心設計的規(guī)則，對邏輯計劃進行智能的、等價的重寫，旨在生成一個數(shù)據(jù)處理量最小、計算步驟最簡的 Optimized Logical Plan。這是 Spark SQL 性能卓越的關鍵所在。

第四階段：物理計劃生成（Physical Planning）—— 從邏輯到執(zhí)行

經(jīng)過邏輯優(yōu)化后，我們得到了一個理論上最優(yōu)的邏輯計劃。然而，邏輯計劃只描述了“做什么”（What to do），并沒有說明“怎么做”（How to do it）。物理計劃生成階段的任務就是將 Optimized Logical Plan 轉化為一個或多個具體的、可執(zhí)行的 Physical Plan（也稱為 Spark Plan）。

1. SparkPlanner 與策略（Strategies）

這個階段的執(zhí)行者是 SparkPlanner。與基于規(guī)則的 Analyzer 和 Optimizer 不同，SparkPlanner 采用的是基于策略（Strategy-Based） 的方法。它內(nèi)部維護了一系列 Planning Strategies。每個 Strategy 負責將特定類型的 LogicalPlan 芚點轉換為一個或多個 PhysicalPlan 節(jié)點。

SparkPlanner 會遍歷 Optimized Logical Plan，對于每個節(jié)點，嘗試應用所有可用的 Strategy，直到找到一個能夠處理它的 Strategy 為止。

2. 核心策略與物理操作符

讓我們看看一些關鍵的 LogicalPlan 節(jié)點是如何被轉換的：

(1) LogicalRelation -> FileSourceScanExec / HiveTableScanExec：

策略：FileSourceStrategy, HiveTableScanning

作用：將對表的邏輯引用轉換為具體的物理掃描操作。FileSourceScanExec 用于讀取 Parquet、JSON、CSV 等通用文件格式，而 HiveTableScanExec 用于讀取 Hive 表。這些物理操作符內(nèi)部封裝了與底層數(shù)據(jù)源交互的具體邏輯。

(2) Project -> ProjectExec：

策略：BasicOperators

作用：ProjectExec 是一個簡單的物理操作符，它接收上游的輸入行，并根據(jù)投影表達式計算出新的行。

(3) Filter -> FilterExec：

策略：BasicOperators

作用：FilterExec 對輸入的每一行應用謂詞表達式，只將滿足條件的行傳遞給下游。

(4) Join -> BroadcastHashJoinExec / ShuffledHashJoinExec / SortMergeJoinExec：

策略：JoinSelection

作用：這是最復雜的轉換之一。JoinSelection 策略會根據(jù)表的大小、數(shù)據(jù)的分布、配置參數(shù)（如 spark.sql.adaptive.enabled）以及是否存在廣播提示（Broadcast Hint）等因素，從多種物理連接實現(xiàn)中選擇最合適的一種。

• BroadcastHashJoinExec：如果一張表足夠?。ㄐ∮?nbsp;spark.sql.autoBroadcastJoinThreshold），Spark 會將其廣播到所有 Executor 節(jié)點，然后在每個節(jié)點上與大表的分區(qū)進行本地 Hash Join。這是最高效的連接方式，因為它避免了昂貴的 Shuffle 操作。
• ShuffledHashJoinExec：對兩張表都進行 Shuffle，按連接鍵分區(qū)，然后在每個分區(qū)內(nèi)部構建 Hash 表進行 Join。
• SortMergeJoinExec：對兩張表都進行 Shuffle 和排序，然后在每個分區(qū)內(nèi)進行歸并式的 Join。這是 Spark 默認的連接策略，適用于大表之間的連接。

(5) Aggregate -> HashAggregateExec / SortAggregateExec：

策略：Aggregation

作用：同樣，根據(jù)數(shù)據(jù)特性和配置，選擇基于 Hash 表或基于排序的聚合實現(xiàn)。

3. 生成多個物理計劃與成本模型

值得注意的是，對于某些復雜的邏輯操作（尤其是 Join），SparkPlanner 可能會生成多個可行的物理計劃。例如，對于一個三表連接，可能有多種不同的連接順序和連接算法組合。

在早期版本的 Spark 中，Planner 會直接選擇第一個生成的計劃。但從 Spark 2.2 開始，引入了 Cost Model。Planner 會為每個候選的物理計劃估算一個執(zhí)行成本（主要基于網(wǎng)絡 I/O 和磁盤 I/O 的估算），然后選擇成本最低的那個作為最終的物理計劃。

總結第四階段：SparkPlanner 將抽象的邏輯操作“翻譯”成具體的、可執(zhí)行的物理操作符，并考慮了數(shù)據(jù)分布、資源消耗等因素，生成了最終的執(zhí)行藍圖——Physical Plan。

第五階段：執(zhí)行準備與代碼生成（Preparation & Code Generation）

物理計劃雖然已經(jīng)很具體了，但它仍然是一個由 Scala 對象組成的樹形結構。直接解釋執(zhí)行這個樹的效率會非常低下。為了追求極致的性能，Spark 在執(zhí)行前會進行最后的準備工作，并利用 Whole-Stage Code Generation 技術將整個物理計劃（或其中連續(xù)的部分）編譯成高效的 Java 字節(jié)碼。

1. PrepareForExecution RuleExecutor

在物理計劃被提交給 Spark Core 的調(diào)度器之前，會經(jīng)過一個名為 PrepareForExecution 的 RuleExecutor。它會應用一些最后的、與執(zhí)行相關的規(guī)則：

• InsertAdaptiveSparkPlan：如果啟用了自適應查詢執(zhí)行（AQE），會在此處插入一個包裝節(jié)點，以便在運行時根據(jù)中間結果的統(tǒng)計信息動態(tài)調(diào)整后續(xù)的執(zhí)行計劃。
• PlanSubqueries：處理物理計劃中可能存在的子查詢。
• EnsureRequirements：確保物理計劃滿足數(shù)據(jù)分布的要求。例如，如果一個 SortMergeJoinExec 要求輸入數(shù)據(jù)按連接鍵排序，而上游操作沒有提供這種排序，那么 EnsureRequirements 會插入一個 SortExec 操作符來滿足這個要求。

2. Whole-Stage Code Generation 的魔力

這是 Spark Tungsten 引擎的核心優(yōu)化之一。其思想是，將物理計劃中連續(xù)的、不需要進行 Shuffle 或緩存的操作符（稱為一個 Codegen Stage）“融合”在一起，并生成一段單一的、高度優(yōu)化的 Java 代碼。

優(yōu)勢：

• 消除虛函數(shù)調(diào)用：傳統(tǒng)的解釋執(zhí)行模式下，處理每一行數(shù)據(jù)都需要調(diào)用一系列操作符的 processRow 虛函數(shù)，開銷巨大。代碼生成將這些調(diào)用內(nèi)聯(lián)（Inline）成直接的 Java 代碼，消除了函數(shù)調(diào)用開銷。
• 利用 CPU 寄存器：生成的代碼可以將頻繁訪問的中間變量保存在 CPU 寄存器中，而不是在內(nèi)存中反復讀寫。
• 循環(huán)展開與 SIMD 優(yōu)化：JIT 編譯器可以對生成的循環(huán)代碼進行進一步優(yōu)化，如循環(huán)展開（Loop Unrolling），甚至利用 CPU 的 SIMD（Single Instruction Multiple Data）指令集進行向量化計算。

例如，一個 FilterExec 后面跟著一個 ProjectExec 的組合，會被編譯成類似如下的 Java 代碼：

public void process() {
    while (input.hasNext()) {
        InternalRow row = input.next();
        // Filter condition: age > 30
        if (row.getInt(1) > 30) {
            // Project: create new row with name
            InternalRow newRow = new InternalRow(1);
            newRow.update(0, row.getString(0));
            output.write(newRow);
        }
    }
}

這段代碼直接、高效，沒有任何多余的抽象層。

總結第五階段：通過最后的執(zhí)行準備和革命性的代碼生成技術，Spark 將物理計劃轉化為了可以直接在 JVM 上高效運行的機器指令，為最終的執(zhí)行鋪平了道路。

第六階段：任務調(diào)度與執(zhí)行（Task Scheduling & Execution）—— 數(shù)據(jù)的最終處理

至此，Spark SQL 引擎的工作基本完成，它將最終的、準備好的物理計劃（現(xiàn)在可以看作是一個 DAG - 有向無環(huán)圖）交給了 Spark Core 的 DAGScheduler。

1. DAGScheduler 與 Stage 劃分

DAGScheduler 是 Spark Core 的核心調(diào)度器。它的主要任務是：

劃分 Stage：根據(jù)物理計劃中的 ShuffleDependency（寬依賴）來劃分 Stage。Shuffle 操作（如 ShuffledHashJoinExec, SortExec 等）是 Stage 的邊界。一個物理計劃會被劃分為多個 Stage，它們之間構成一個 DAG。沒有 Shuffle 依賴的連續(xù)操作符屬于同一個 Stage。

提交 Job：將整個 DAG 作為一個 Job 提交給底層的 TaskScheduler。

2. TaskScheduler 與 Task 提交

TaskScheduler 負責與集群管理器（如 Standalone, YARN, Kubernetes）交互，獲取計算資源（Executor），并將具體的 Task 分發(fā)到各個 Executor 上執(zhí)行。

• 每個 Stage 會被拆分成多個 Task，Task 的數(shù)量通常等于該 Stage 最后一個 RDD 的分區(qū)數(shù)。
• ResultTask：最后一個 Stage 中的 Task，它們負責將最終結果返回給 Driver。
• ShuffleMapTask：非最后一個 Stage 中的 Task，它們負責計算中間結果，并將結果寫入本地磁盤（Shuffle Write），供下游 Stage 的 Task 讀?。⊿huffle Read）。

3. Executor 上的執(zhí)行

在 Executor 進程中，ExecutorBackend 會接收來自 Driver 的 Task，并將其交給 Executor 線程池中的一個線程來執(zhí)行。

• Task 的核心邏輯就是執(zhí)行之前通過代碼生成得到的 Java 字節(jié)碼。
• 它會從數(shù)據(jù)源（如 HDFS）讀取數(shù)據(jù)塊（Block），或者從本地磁盤讀取 Shuffle 數(shù)據(jù)。
• 執(zhí)行計算邏輯，處理每一行數(shù)據(jù)。
• 對于 ShuffleMapTask，將結果按 Partitioner 規(guī)則寫入本地磁盤的 Shuffle 文件。
• 對于 ResultTask，將最終結果序列化后通過網(wǎng)絡發(fā)送回 Driver。

4. 自適應查詢執(zhí)行（AQE）的動態(tài)干預

如果啟用了 AQE（spark.sql.adaptive.enabled=true），那么在執(zhí)行過程中，Spark 還會進行動態(tài)優(yōu)化：

• 動態(tài)合并 Shuffle Partitions：如果某些 Shuffle 分區(qū)的數(shù)據(jù)量很小，AQE 會在運行時將它們合并，以減少小文件和調(diào)度開銷。
• 動態(tài)切換 Join 策略：在 Shuffle Read 階段，如果發(fā)現(xiàn)某個分區(qū)的數(shù)據(jù)量遠小于預期，AQE 可能會將原本計劃的 SortMergeJoin 動態(tài)切換為更高效的 BroadcastHashJoin。
• 動態(tài)優(yōu)化 Join 傾斜：自動檢測數(shù)據(jù)傾斜，并將傾斜的分區(qū)進行拆分和特殊處理。

AQE 使得 Spark SQL 的執(zhí)行計劃不再是靜態(tài)的，而是能夠根據(jù)實際運行時的數(shù)據(jù)特征進行自我調(diào)整，進一步提升了性能和穩(wěn)定性。

5. 結果返回與收尾

當所有的 ResultTask 都成功執(zhí)行完畢，并將結果發(fā)送回 Driver 后，Driver 會將這些結果收集起來（對于 collect() 操作）或者寫入到指定的輸出位置（對于 write 操作）。最后，Spark 會清理本次查詢產(chǎn)生的臨時文件、釋放資源，并返回最終的結果或成功狀態(tài)。

總結第六階段：Spark Core 的調(diào)度系統(tǒng)接管了執(zhí)行計劃，將其分解為可并行的 Task，在集群中調(diào)度執(zhí)行。Executor 負責具體的計算工作，最終將結果匯聚并返回。AQE 的引入讓這個過程變得更加智能和動態(tài)。

結語

從敲下回車鍵提交一條 SQL 語句，到最終看到查詢結果，Spark SQL 完成了一次令人嘆為觀止的“變形記”。這條旅程穿越了 解析（Parsing）、分析（Analysis）、邏輯優(yōu)化（Logical Optimization）、物理計劃生成（Physical Planning）、執(zhí)行準備與代碼生成（Preparation & Codegen） 以及 任務調(diào)度與執(zhí)行（Scheduling & Execution） 六大核心階段。

每一個階段都凝聚了 Spark 開發(fā)者們對查詢處理、分布式系統(tǒng)和性能優(yōu)化的深刻理解。Catalyst 優(yōu)化器的規(guī)則驅動架構、Tungsten 引擎的代碼生成技術、以及 AQE 的動態(tài)自適應能力，共同構成了 Spark SQL 強大性能的基石。

理解這個全生命周期，就如同掌握了一張 Spark SQL 的“藏寶圖”。它不僅能幫助我們寫出更高效的 SQL，更能讓我們在面對 EXPLAIN 命令輸出的計劃樹時，洞悉其背后的邏輯與意圖，從而成為一名真正駕馭 Spark 的數(shù)據(jù)工程師。