Spark 4.2 把 AI 搜尋收進 SQL

以前 AI 搜尋要三套系統接線，現在 Spark 4.2 想把查詢、向量、串流收回同一個引擎。

我用 Spark 很久了，老實說，平常升級說明我都只掃一眼：快一點、穩一點、Python 再順一點。看久了真的會麻木。但這次我停下來，因為我在公司和客戶那邊看到的 AI 架構，幾乎都長得一樣醜：一套管事件，一套管特徵，一套向量庫管檢索，外面再包一層 glue code，像把漏水管子用膠帶纏到看不見就算數。

那種架構不是不能跑，是很會偷你的時間。延遲忽快忽慢，資料治理分散在不同工具，團隊一直吵 embedding 到底放哪裡、freshness 誰負責、為什麼一個「簡單」AI 功能最後要三個服務、兩份監控、還有一個沒人信的 dashboard。這篇我主要拆 The New Stack 對 Spark 4.2 的整理，再對照 Apache Spark 官方文件和專案頁面，因為這種東西不能只看標題。

我先講結論：Spark 4.2 不是真的要把所有 AI 工具都吃掉。它更像是在把 AI serving 的重心往自己身上拉，讓 ingestion、feature prep、vector search、streaming、metrics 都有機會待在同一個 SQL/engine 裡。這種改法不只是在加功能，是真的會改你怎麼畫架構圖。

外部錨點很明確：觸發我寫這篇的就是 The New Stack 那篇文章，原文沒有提供觀看數或收藏數，我就不亂猜了。真正值得看的，是它把 Spark 4.2 說成 AI workloads 的基礎層，而不是另一個單點工具。

向量庫最容易先被懷疑，因為它本來就常是多餘的一層

“Spark 4.2 has a feature that could retire your vector database.”

這句話如果直翻，不是叫你明天把 Pinecone 刪掉。它的意思比較務實：Spark 正在往很多團隊原本會丟給專門向量庫的那一段靠攏。也就是說，如果 Spark 已經能把 embedding 建好、存好、查好，而且延遲和吞吐對你的工作負載夠用，那獨立向量庫就不再是必需品，而是選項。

我以前看過兩種很典型的翻車。第一種是先買了向量庫，覺得架構很乾淨，結果後面每次資料更新都要從 Postgres、Kafka、Spark job 一路同步過去，最後變成同步系統比檢索系統還難維護。第二種更慘，硬把向量檢索塞進一般資料庫，結果查詢慢、調參痛苦、大家都只想假裝沒看到。

所以我現在看向量庫，不會先問它酷不酷，我只問兩件事：source of truth 在哪裡，還有我到底想維護幾份同樣的資料。只要你開始多一份索引、多一份同步、多一份 drift，後面就是成本一路疊上去。

實操上我會這樣判斷：如果 embeddings 本來就在 Spark pipeline 裡產生，或 feature pipeline 也已經在 Spark 裡，那就先畫 retrieval path。看向量庫除了 similarity search 之外，有沒有真的提供你非它不可的能力。如果沒有，先把「一定要獨立一套」這個預設拿掉。

• 保留專門向量庫：當你有硬性低延遲 SLA，Spark 真的扛不住。
• 考慮 Spark-first retrieval：當 embeddings 與資料管線本來就綁在一起，freshness 比極致延遲更重要。
• 先算 duplication tax：每多一個 store，就多一份同步、多一份 drift、多一份故障面。

Spark 想變成 serving 層，這件事比加一個 API 重要

以前我對 Spark 的理解很簡單：它負責處理資料，真正對外服務的交給別的系統。這個切法在 batch 時代很合理，因為「serving」通常就是 app 去打資料庫，沒那麼多花樣。但 AI 工作負載把這條線弄模糊了，很多所謂 inference-adjacent 的東西，本質上就是資料工程加一個搜尋步驟。

Spark 4.2 讓我在意的地方，是它開始像一個 serving 中樞：同一個引擎既能 ingest、也能算特徵、也能查相似項。這代表少掉很多 handoff。少 handoff 通常就少 stale copy、少 sync job、少那種半夜才發現索引已經落後六小時的事故。

我之前做過一個推薦系統，特徵一套 pipeline、上線一套 pipeline、nearest-neighbor lookup 又是第三個 service。產品說要改一個小規則，我得先翻三個 codebase，再對兩個部署節奏。圖上看起來很整齊，實際上根本是 coordination tax 機器。

所以我現在會把 Spark 這條路理解成：它不是再多一層工具，而是把「查詢」變成 engine 的原生能力。當 retrieval、table、stream、Python logic 都在同一個地方時，很多原本要靠 glue code 撐住的東西就會消失。

實操寫法很直接：把你現在 AI request path 從 ingestion 畫到 response，逐段數系統切換次數。再把那些只是因為歷史包袱才存在的切換標出來。這些地方，就是 Spark 有機會吃掉的地方。

• 資料只 ingest 一次，不要三頭同步。
• Embeddings 和 feature derivation 盡量靠近。
• 架構還在變動時，先選一個 operational control plane。

治理過的 metrics 很無聊，但出事時最值錢

大家看到向量搜尋會興奮，我反而先盯住 governed metrics。來源文章提到 Spark 4.2 在 metrics 上也有治理能力，這種東西平常沒人想聊，等到第一次 audit、第一次 billing dispute、第一次模型事故，大家才開始追問：到底哪個數字是真的？

白話一點，就是 Spark 4.2 想讓 metric definitions 更集中、更可重複。聽起來很 boring，沒錯，這就是我喜歡的地方。因為最常出事的，不是模型本身，而是 training、offline evaluation、production monitoring 三邊各算各的 accuracy，最後每個人都覺得自己沒有錯。

我看過很多團隊把 metric 放在 notebook，之後搬到 BI tool，再後來又寫成一個沒人想接手的 custom service。只要 AI 系統開始影響產品行為，metric drift 就不是 data science 小事，而是治理問題。你沒辦法拿三個不同版本的「正確答案」去跟主管討論。

如果 Spark 把 metric 定義和計算都留在同一個 engine 裡，chain of custody 會乾淨很多。這不只對受監管產業有用，對一般團隊也有用，因為你終於不用一直吵誰的數字才算數。

實操上，我會先列出團隊所有 KPI、模型 metric、retrieval quality metric。每一個都回答三題：定義在哪、計算在哪、誰負責。只要這三個答案分散在三套系統，你就已經有一個治理問題了。

串流升級不是配角，它決定這套東西能不能真的近即時

只有 vector search 不夠。資料一 stale，檢索就 stale；事件一 lag，特徵就 lag。這也是為什麼 Spark 4.2 的 streaming 改進，我看得跟搜尋一樣重。

The New Stack 那篇提到 streaming upgrades，我覺得這是整個 AI-serving 敘事能不能成立的關鍵。真正的近即時系統，靠的不是某個酷炫 API，而是資料流能不能持續往前推。如果 Spark 能同時處理 streams，還能把結果直接餵給 retrieval，那你的索引就不需要靠 cron job 和祈禱維持新鮮。

我踩過太多這種坑：stream processor 看起來健康，indexer 看起來健康，產品卻還是錯。最後才發現問題不是單點壞掉，而是兩套系統之間的 handoff 慢到爆。使用者感受到的不是「系統很複雜」，而是「你這個 real-time 功能其實晚了快一小時」。

串流也會直接影響 embedding pipeline。只要 source data 持續變動，embedding 就不能用一個慢吞吞的離線流程硬拖。Spark 的方向，是把這件事收回同一個引擎處理，不要再把協調工作丟給另一套 stack。

實操寫法：先把所有依賴 freshness 的 AI 功能列出來，像推薦、fraud、search、ranking、support routing。接著問自己一句很殘酷的話：現在這套是不是 batch-first，外面再補一層 streaming？如果是，那這個設計多半已經老了。

Python 支援不是小事，因為 adoption 卡死通常卡在這裡

很多平台團隊會低估 Python 這件事，覺得反正底層 JVM 很穩，寫法漂亮一點就好。問題是，資料科學家和 ML 工程師大多活在 Python notebook 裡，你如果要他們為了平台切去另一種語言，阻力會很真實。

我對 Spark 4.2 的 Python 支援比較有感，因為它其實在做一件很務實的事：去接大家已經在用的工作方式。技術上很漂亮的系統，如果沒人想碰，還是失敗。這句很難聽，但我看過太多次了，工具差一點但好用，最後就是贏。

Python 也讓 AI prototype 到 production 的距離短一點。不是說會變簡單，而是少掉很多 runtime 邊界、wrapper、adapter、重寫邏輯。少掉這些，團隊才有機會把時間花在模型和資料，而不是花在「怎麼把同一段邏輯再包一次」。

實操上，我會先算你現在的 split brain 成本：Python 實驗環境和 JVM 生產環境之間，有多少轉譯、多少重寫、多少工具只存在於語言邊界？如果答案讓你皺眉，Spark 4.2 的 Python 方向就值得你認真看。

順手補兩個外部參考：Apache Spark docs 可以看官方能力邊界，專案首頁 可以看版本節奏。這些東西比社群轉貼更可靠。

我真正想省下來的是 babysit 系統的時間

講到底，Spark 4.2 最有意思的地方，不是它又多了一個 shiny feature，而是它提供了一條減少系統數量的路。這件事很無聊，但很值錢。因為在真實世界裡，省下來的通常不是算力，是人力和注意力。

每多一個 store、index、service，你就多一份 patch、多一份 monitor、多一份 backup、多一份 incident review 裡要解釋的東西。新同事來了還要教一次：這個為什麼存在？那個為什麼不能刪？如果 Spark 能吞掉 AI serving path 的一大段，架構就會比較好懂，也比較好養。

但我不想把話講死。不是每個工作負載都該被 Spark 吃掉。某些場景就是需要專門向量基礎設施，某些團隊就是已經把 retrieval 系統做得很好，硬搬反而更糟。只是預設值正在變：現在輪到獨立系統去證明自己值得存在。

實操上，我會做一次 stack audit。把一個 AI feature 相關的所有系統列出來，標成 source、transform、store、retrieve、serve。只要某個元件只是因為別人做不到才存在，就該被認真質疑。你要找的是能刪掉的地方，不是再多加一層。

• 先保留 rollback path，再談 cutover。
• 把 freshness、recall、query latency 分開量。
• 別把實驗 metric 和 production metric 混在一起。
• Python ergonomics 要當成正式需求，不是 bonus。

可抄的模板

# Spark 4.2 AI serving 模板（可直接改成你自己的版本）

## 目標
把 ingestion、feature prep、embeddings、retrieval、governed metrics 收進同一條 Spark pipeline。

## 適用情境
- embeddings 已經在 Spark 或靠近 Spark 的 Python jobs 裡產生
- 你想少掉同步 job，讓 retrieval 更新更快
- 你想把 batch、streaming、AI serving 放進同一個操作面
- 你想把 metric 定義和計算留在同一個地方

## 先保留獨立向量庫，如果你有這些需求
- 你有硬性低延遲 SLA，Spark 目前扛不住
- 你需要 Spark 環境裡沒有的專門 ANN 能力
- 你的 retrieval 工作負載已經很穩，沒必要重構

## 架構長相
1. 把來源資料 ingest 到 Spark
2. 做清理、正規化、去重
3. 產生 embeddings
4. 存到 Spark 可存取的 tables 或 indexes
5. 用 Spark 做相似項查詢
6. 在 Spark 裡計算 governed metrics
7. 把結果送到 app 或 model service

## 決策清單
- Spark 現在是不是資料 source of truth？
- embeddings 是否跟來源資料同一條 pipeline 更新？
- 是否已經有重複的 retrieval data copy？
- retrieval 和 quality metrics 能不能用 code 一次定義？
- freshness 是否比 sub-millisecond latency 更重要？

## 遷移步驟
### Phase 1：畫圖
先把目前 AI request path 的每個系統畫出來。

### Phase 2：收斂
把 embedding generation 和 metric computation 拉近 Spark。

### Phase 3：對照測試
拿現有 vector store 做 side-by-side retrieval 比對。

### Phase 4：切換
只切 latency 和 quality 都達標的 workload。

## 風險控管
- 保留回退到舊向量庫的路
- 分開量 freshness、recall、query latency
- 不要把實驗 metric 混進 production metric
- 把 Python ergonomics 當成正式需求

## 可直接放進評估文件的一句話
如果 Spark 4.2 能替這個工作負載承擔 ingestion、embeddings、retrieval 和 governed metrics，我們就能少一個專門系統和一條同步路徑。

這份模板我刻意寫得保守一點。我的經驗是，先少掉一個系統、少掉一條同步路徑，通常就已經很有感了；不要一開始就想玩平台純度競賽，最後把自己搞得更亂。

來源致謝：這篇拆解主要來自 The New Stack 的原文，以及 Apache Spark 官方專案與 文件。我寫的判斷、案例和模板是衍生整理，不是原文逐字翻譯。