摘要： Databricks 於 2026 年 11 月 5 日發布 Apache Spark 4.3，隨 Databricks Runtime 19 推出。這版把串流聚合、去重與自訂有狀態處理帶進 Real-Time Mode，三個代表性 benchmark 的 P99 端到端延遲都低於 150 ms，同時加入季度發布節奏。對開發者來說，重點不是「又快了一點」，而是低延遲串流可能不再需要另外維護一套引擎。
有狀態串流的機制：shuffle 從阻擋變成流水線
先前 Real-Time Mode 只適合無狀態的處理；要記住跨事件的脈絡——詐欺偵測要看前幾筆交易、裝置監控要持續更新計數——就得換工具。Spark 4.3 把 streaming aggregation、dropDuplicates，以及 Scala/Java 的 transformWithState（SPARK-58635、SPARK-57228）加進 Real-Time Mode，而且沿用 Structured Streaming 既有 API、state store 與 checkpointing，不是另起一套程式模型。
能這樣做，靠的是執行模型的改動。傳統 blocking shuffle 必須等上游 stage 完全產出資料，下游才能開始；對長時間運行的串流任務來說，這種「階段式」節奏撐不住連續資料流。Spark 4.3 新增 PipelinedShuffleDependency（SPARK-58185），讓生產與消費 stage 同時運行，由 StreamingShuffleManager（SPARK-57141）把紀錄增量地送往下游負責該 key 的任務。由這種依賴連接的 stage 會被排程器視為一個 pipelined group：一起排程、一起失敗（SPARK-58263、SPARK-58398）。
三個數字，以及它們的限制
Databricks 在 SPARK-58884 回報的三個有狀態 workload，P99 端到端延遲分別是：dropDuplicates 136 ms、Window aggregation 139 ms、transformWithState 141 ms。公告原話是，對受支援的 workload 來說，達到毫秒級延遲不再需要另一套串流引擎。
但原文也寫明，這是三個受測 workload 的量測結果，不是對每一條 pipeline 的延遲保證。還有兩個工程上的取捨值得注意：pipelined group 內任何一個 stage 失敗，整組都會失敗；而且因為整組並行運行，Spark 只在任務槽位足夠容納全部任務時才准入這組，否則快速失敗而不是卡住。把這個模型放進生產前，資源規劃和失敗半徑要先算清楚。
Project Feather：小資料迭代提速，但需要手動開
LLM 輔助開發的迴圈常常是：生一小段轉換、跑在樣本上、看結果、再改。每次迭代可能只處理幾列資料，任務排程和 shuffle 的固定開銷卻比計算本身還貴。Project Feather 針對的就是這筆開銷：對符合條件的小型單一 partition 查詢片段，走免 shuffle 的單任務執行（SPARK-57851），讓實體計畫可以省掉 Exchange。預設資格限制下，合格的檔案掃描是一個放得進單一 partition 的非空小檔案，合格的 local in-memory relation 則最多 1,000 列；支援的查詢形狀包括掃描、聚合、distinct、window、排序與 limit。
另外還有選用的 Arrow 原生 Dataset 快取（SPARK-57268），把快取批次以 Arrow 格式儲存並附壓縮與欄位統計。啟用方式是啟動新的 Spark 應用時設定靜態組態 spark.sql.cache.serializer=org.apache.spark.sql.execution.columnar.ArrowCachedBatchSerializer——注意是靜態組態，得在應用啟動時就決定。更廣的 in-process local repartitioning 被排到下一版（SPARK-57399），這版拿不到。
SCD Type 2 Auto CDC：歷史留痕不再靠手寫 merge
只有現況表，回答不了「下單當時這位客戶屬於哪個區域」。Spark 4.3 替 Auto CDC 加上端到端的 SCD Type 2 支援（SPARK-56249），透過 Python、SQL 與 Spark Connect 都能用（SPARK-58321、SPARK-58247、SPARK-58261），自動套用變更而不必手寫 merge。輸出表裡每個唯一 key 會對應一串紀錄，用 __START_AT 和 __END_AT 兩個中繼資料欄標記各自的有效期間；原文舉的例子是客戶從 West 區搬到 East 區時，舊紀錄保留並以變更事件的時間作為結束點，再插入一筆新紀錄。
要誠實說明一件事：這次收集到的原文在這個例子中段被截斷，SCD Type 2 之後的內容、以及發布公告更後面的章節，這份素材並不完整，因此無法對那些部分下任何結論。
接下來該查什麼
Spark 4.3 也開始了季度功能發布節奏，從每六個月一次改成每三個月一次，完成的功能會更快落到使用者手上。這個節奏本身值得納入團隊的升級規劃。
Databricks 近期的動作不只這一件——這家公司先前的融資動態（見本站先前關於 Databricks 再融資、估值升至 1,880 億美元的分析）顯示它在資料與 AI 平台上持續加碼，開源 Spark 引擎正是其中的地基。按這份工程團隊的發布公告，由 Jungtaek Lim、Wenchen Fan、Reynold Xin 等人署名，下一步實際的驗證路徑是：拿你自己的有狀態 workload 在 Runtime 19 上重跑，對照那 136–141 ms 是否在你的資料形狀下成立；再確認 pipelined group 的任務槽位需求在你的叢集上不會造成快速失敗。原文沒有提供這三個 benchmark 之外的生產環境實測數據，這部分只能自己驗。
參考來源
在 X 上查看原貼文