Day1: Spark+K8S+Agentic AI? 個人作品集的緣起與方向

明年暑假我就要從碩士班畢業，差不多該認真準備找工作了。盤點我會的東西：LangGraph 和 multi-agent 系統做得最多，data science 和 fintech 有一些累積，cloud 也碰過一點。但有一塊我經過了四次的實習都沒有好好的碰到，就是大規模資料處理和 Kubernetes 的實戰經驗。Spark 和 K8s 我都只算剛入門。

這個系列是我補上這一塊的紀錄。我打算做一個真的會上線、要自己付錢維護的專案，每天寫一篇短文記下進度，順便把荒廢一陣子的部落格救回來。

為什麼不做一個單純的 Spark 練習專案

照著教學跑一次 word count、再把它丟上 K8s，學得到東西，但放在作品集裡沒有人會多看一眼，現在做出大量沒人用的Project太簡單了，根本沒有人會在意。我想要的是把「我缺的」和「我會的」接在一起：Spark 和 K8s 是新學的，agent 是我熟的，中間需要一個合理的理由讓它們結合在一起。

靈感來源

之前在 Google 工作時，我處理的是內部測試失敗的問題：測試一掛掉，就把錯誤的過程和內容系統性地丟進一個 agent loop，讓它做歸因調查和分類。如果過去出現過類似的案件，就直接沿用之前的結論，不必重新調查一次，概念上很像 cache。

這套「triage、reasoning、reuse」的循環，搬到 Spark on K8s 上很合適：

• 訊號分散在三層。一個 Spark job 掛掉，線索可能在 K8s 事件、driver 或 executor 的 log，也可能在 Spark 自己的 event log。人工查很花時間，正好是 agent 能幫上忙的地方。
• 故障高度重複。executor 被 OOMKilled、資料傾斜拖垮某個 stage、spot 節點被回收，這些問題會一再出現。重複代表過往案例可以重複利用，如果hit的話就不用花很多錢來自己找根因。

要做的東西

一個公開的 Spark on K8s 故障分診與自動復原平台。核心循環長這樣：

失敗的 Spark job
  → 收集（K8s 事件、driver/executor log、event log）
  → 指紋化（去掉 ID、時間、路徑後的錯誤簽章 + embedding）
  → 查案例庫 ─ 命中   → 直接套用已驗證過的修法
              └ 未命中 → LangGraph 調查 → 歸因分類 → 提出修法
  → 復原（改設定後重送）→ 驗證 → 結果寫回案例庫

平台預計有三種使用方式：

1. 故障實驗室：我預先做好一批壞掉的 Spark job，訪客點選後可以看 agent 即時診斷並修復，以及修復前後的耗時與成本。
2. 上傳 event log 診斷：工程師上傳自己的 event log，agent 分析瓶頸並給調整建議。平台只分析，不執行別人的程式碼。
3. 自然語言跑 Spark：用中文提問，agent 寫 Spark SQL 丟到叢集上跑。這個要處理沙箱和配額，會排在比較後面。

故障實驗室同時是我的評測集。每個故障都有標準答案，所以分診準確率、案例庫命中率、有沒有 cache 的修復時間和 token 成本，都能量出數字。

目前定下來的幾個決定

• 資料：用 TPC-DS 當基準，這樣效能數字才能跟外界比較。展示情境暫時採用 Binance 的公開成交資料。
• 叢集：GKE 上的小型叢集，Spark executor 跑在可以縮到零的 spot 節點上。伺服器預算抓每月 US$50–150，要做預算管理不然我就要爆炸了。
• agent 的權限：第一版只能調整白名單內的設定，例如記憶體、分區數、AQE 開關，不讓它改寫程式碼。
• 先做故障，後做 agent：agent 是我的舒適圈，但這個專案要補的是 Spark 和 K8s。所以前幾週我會先親手把每一種故障做出來，搞懂它為什麼壞，再讓 agent 上場。

路線圖

我每週大概能投入 5–10 小時，照這個速度切成幾個階段：

目標是在明年春天開始投履歷之前，讓階段 3 上線。

接下來

下一步是階段 0：在自己的電腦上把 Spark Operator 裝起來，跑出第一個 job。這個系列之後的文章會比今天短，大致是當天做了什麼、卡在哪裡、學到什麼。