Designing a Community Skill for AWS Transform Custom: AWS Glue 5.0 Upgrade Readiness 封面圖片

Dipayan Das

Designing a Community Skill for AWS Transform Custom: AWS Glue 5.0 Upgrade Readiness

TL;DR

我設計了一個提議的 AWS Transform Custom 社群技能，用來將 Glue 2.0、3.0 和 4.0 儲存庫準備升級至 Glue 5.0。它將安全的機械式轉換與需要人工證據的變更分開，產生遷移報告，並保留已相容的檔案不變。由於我沒有即時 atx 存取權限，本文中的基準測試明確標示為手動模擬，而非代理執行。這項提議以 issue #75 開放 — 尚未合併，也尚未成為 pull request。

缺少的資料工程轉換

AWS Transform Custom 可以透過代理驅動的程式碼轉換，套用至單一儲存庫 — 或透過 AWS Batch 和 Fargate 一次套用至數千個儲存庫。截至 2026 年 7 月 30 日，其公開範例儲存庫 aws-samples/aws-transform-custom-samples 包含三個社群貢獻的轉換：EKS 版本升級就緒技能、JBoss 轉 Spring Boot 遷移，以及 Kubernetes 就緒遷移。這些都未觸及資料工程。

由於我日常工作大多橫跨 AWS 資料工程、Databricks 和 Delta Lake，填補這個空白顯然是當務之急。

AWS Transform Custom「技能」的外觀

在撰寫任何內容之前，我深入研究了現有最完整的範例 jboss-to-springboot，因為它建立的模式實際上也是其他兩個技能的未書面規範：

  • README.md — 說明問題、技能功能，以及如何透過 atx CLI 呼叫。這也是儲存庫清楚劃分界線的地方：這些是就緒轉換。它們會修改儲存庫成品 — 程式碼和基礎設施即程式碼 — 但不會部署任務、呼叫 AWS API 變更執行中的資源，或聲明資料層級的等效性。這個區別在後續內容中非常重要。
  • SKILL.md — 面向代理的定義：YAML 前言包含觸發關鍵字、目標、明確的非目標、限制、已驗證的前後範例、「來源程式碼訊號 → 參考檔案」路由表，以及編號的驗證／結束條件清單。
  • references/ — 當偵測到特定訊號時，代理才會提取的聚焦深入探討檔案。
  • BENCHMARKS.md — 執行摘要表加上已記錄、可重現的方法論。

有兩個設計選擇值得完全複製。首先，技能會執行條件式 Phase 0，在接觸任何東西之前先偵測哪些遷移階段實際適用。其次，它們會維持僅標記類別：代理絕對不能自動轉換的項目 — 模稜兩可的相依性、自訂連接器、非機械式行為變更 — 而是必須在報告中呈現，供人工決定。後者最終成為我建立的任何東西中最重要的部分。

為什麼特別針對 Glue 5.0

AWS Glue 5.1 已於 2025 年 11 月正式推出，執行 Spark 3.5.6、Python 3.11、Scala 2.12.18 和 Java 17。Glue 5.0（Spark 3.5.4，相同 Python/Scala/Java 版本）仍完全支援。我將此技能的第一個版本 — 以及其中的每個 fixture 和基準測試 — 限定在 Glue 5.0，符合 issue #75 的提議。技能的結構可以乾淨地延伸至 5.1 作為後續版本；我寧願交付一個有實際執行基準測試的較窄技能，而不是一個有未經驗證聲明的較寬技能。

glue-version-upgrade-readiness 會分析 AWS Glue ETL 任務（PySpark 和 Scala）及其 IaC，並將它們從來源版本 2.0、3.0 或 4.0 準備升級至 Glue 5.0。透過 Phase 0 偵測旗標進行閘控，因此每個儲存庫只執行相關工作，涵蓋：

  • Spark 2.4/3.1/3.3 → 3.5 相容性和現代化模式 — 已棄用的 API，例如 registerTempTable（自 Spark 2.0 起已棄用，尚未移除，但值得與執行環境升級一起清理）、舊版日期時間剖析旗標，以及相關 SQL 語意變更
  • Python 3.7/3.10 → 3.11 相容性，包括相依性固定版本更新
  • Glue 特定 API 和記錄引數變更
  • 連接器和資料湖格式更新 — 較新 Glue 版本的原生 Iceberg/Delta/Hudi 支援
  • Terraform / CloudFormation / CDK 更新以指向新的執行環境

同時，故意不自動觸碰的項目：AWS Marketplace 連接器、已編譯／原生相依性，以及任何依賴 Spark 2.x 行為且沒有乾淨機械等效物的項目。這些會寫入 MIGRATION_REPORT.md 並附上理由，絕不靜默遷移。

沒有即時存取權限下的基準測試

驗證技能的預期方式是透過真實 atx CLI 對已植入的測試儲存庫執行。我在環境中沒有即時 AWS Transform Custom 存取權限，因此我沒有虛構數字或完全跳過驗證，而是植入了三個已知植入不相容性的 fixture 儲存庫 — 一個 PySpark Glue 2.0 任務、一個 Scala Glue 3.0 任務，以及一個 Terraform 管理的 Glue 4.0 任務 — 然後用手逐一走過技能的各個階段，再用真實的本機工具檢查結果：Python 3.11、Terraform、cfn-lint 和 sbt。

以下每個數字都標示為手動模擬，而非代理執行，且該標籤保留在公開 issue 中，沒有在任何地方加以美化：

Fixture 偵測到的發現 驗證的機械式修正 人工審查項目 誤報 結果
Glue 2.0 PySpark 5/5 4/4 1/1 0 部分就緒
Glue 3.0 Scala 5/5 3/3 2/2 0 因連接器而受阻
Glue 4.0 Terraform 4/4 3/3 1/1 0 部分就緒
總計 14/14 10/10 4/4 0 3/3 控制項未變更

這些數字衡量的是手動對 fixture 套用技能規定階段的結果。它們不是 AWS Transform Custom 自主執行準確度的衡量 — 我目前還沒有這些資料，而且我在所有出現數字的地方都已說明。

Scala 結果是我最信任的，正是因為它不是乾淨的通過。該 fixture 中刻意植入了未公開的自訂連接器。技能正確地拒絕猜測替換方案、標記它，而 sbt compile 在完整建置時確實失敗 — 然而轉換後的原始碼本身在隔離的測試環境中可以乾淨地編譯。一個在這裡回報「就緒」的技能會是錯誤的結果。

遷移技能不應該以最高通過率為最佳化目標。它應該以最高可辯護的通過率為最佳化目標。

我還將技能文件中的每個嵌入式程式碼範例 — Python、Terraform 和 CloudFormation 片段 — 都透過相同的真實驗證器執行，並在每個 fixture 中加入一個永遠不應變更的控制檔案，透過 SHA-256 在前後進行驗證。

發現自己的過度延伸

在開啟 issue 之前，我針對自己最沒有信心的兩個聲明進行了獨立的事實查核：AWS 文件是否普遍棄用 Glue DynamicFrames（它沒有 — 只在特定的 Lake Formation 細粒度存取控制情境中才棄用），以及 CDK 團隊是否規定 cdk synth 作為實驗性 aws-glue-alpha 模組的穩定性機制。

第二個聲明沒有成立。CDK 文件將該模組標示為實驗性，並警告跨版本的破壞性變更，但它沒有特別指出合成作為穩定性保證 — 這是我原本決定要求的驗證步驟，最初寫成好像是 AWS 自己的指導方針。我在技能檔案、參考文件和提議中重新措辭，因此現在正確地歸屬需求：這是此技能自己的安全閘門，而不是已記錄的 CDK 建議。

這本身是一個小小的修正，但這類事情要嘛在發布前被發現，要嘛在審查時被維護者發現。自己發現總是比較好 — 這是某人必須反駁的聲明，與他們可以直接驗證的聲明之間的差異。

目前狀態

這是一項提議，而不是已落地的貢獻。完整的技能、其參考文件和三個基準測試 fixture 已在本地建置和驗證，但尚未合併任何內容 — 我沒有在這裡連結分支，因為目前還沒有公開分支。根據儲存庫的貢獻指南，重大工作會在 pull request 之前先在 issue 中討論，所以這正是目前的位置：issue #75，開放供維護者回饋。

如果您正在大規模執行 AWS Glue，並遇到自己的 Glue 5.0 或 5.1 遷移邊緣案例，我很想聽聽您的經驗 — 可以在 issue 或本文的評論中分享。如果您是第一次接觸 AWS Transform Custom，community-sourced-transformations/ 是一個真正未被充分探索的入門點；除了現有的 Java 和 Kubernetes 範例外，還有很大的貢獻空間。