AWS Glue 是連接 S3 原始資料與 Feature Store、訓練任務和推論 pipeline 的核心 ETL 服務。在 MLA-C01（Machine Learning Engineer Associate）考試中，Glue 題目在 Domain 1 佔有很重的分量，因為這張證照將自身定位為工程師考試——你不是決定使用哪種模型架構的資料科學家，而是決定每晚轉換任務該跑在 Glue Spark、Glue Python shell、Glue Ray、EMR 還是 SageMaker Processing 上的工程師。把服務選擇取捨搞對，你就能在接觸任何 PySpark 之前先拿下一大批 Domain 1 分數。
本指南涵蓋 Glue 的四種風格（Spark、Python shell、Ray、streaming）及各自的正確使用時機、DataBrew 低程式碼視覺化轉換工具及其與 SageMaker Data Wrangler 混淆的陷阱、你必須按名稱識別的 Glue Data Quality 規則類型、考試以外科手術般精確度測試的 Glue Crawler vs Glue ETL 區別，以及 Glue 輸出與 SageMaker 訓練任務的整合故事。讀完之後，你應該能看到「每晚預處理 500 GB 巢狀 JSON，加上特徵衍生，輸出 Parquet 到 S3 並帶有可驗證沿革」這樣的 MLA-C01 題幹，立即回答 Glue Spark 搭配 bookmarks，並知道為什麼 Python shell 和 Ray 對那個資料量是錯的。
AWS Glue 是什麼，為何 ML Pipeline 需要它
AWS Glue 是一個無伺服器資料整合服務，結合了受管 Spark/Python 執行引擎、中繼資料目錄（Glue Data Catalog，與 Athena 和 Lake Formation 共享）、schema 探索工具（Crawlers）、低程式碼轉換 UI（DataBrew）、資料品質驗證（Glue Data Quality）和協作原語（Workflows、Triggers）。對 ML pipeline 而言，Glue 是在需要以規模（GB 到 TB 每晚）轉換結構化或半結構化資料、使用受管基礎設施、按使用量計費、且與 AWS 資料湖其他部分緊密整合時的正確選擇。
Glue 在 ML Pipeline 中的位置
原始資料從作業來源（CDC 串流、批次轉儲、IoT）落地到 S3。Glue ETL jobs 讀取此原始資料，套用轉換（join、聚合、衍生特徵、類型轉換），驗證品質（Glue Data Quality 規則），並把 ML 就緒的 Parquet 寫入整理過的 S3 位置。SageMaker 訓練任務然後消費整理過的 S3 路徑，或 Feature Store 擷取 jobs 把 Glue 輸出推入 Feature Store。Glue Workflows 協作多步驟 DAG；EventBridge 在新分區落地時觸發再訓練。
為何 MLA-C01 大量測試 Glue
MLA-C01 社群的痛點研究反覆標記 Glue Crawler vs ETL 混淆、DataBrew vs Data Wrangler 混淆，以及 Glue job 類型選擇（Spark vs Python shell vs Ray）為常見考試錯誤。Pluralsight 部落格明確指出「從擷取到再訓練的 ML 生命週期」是一個被測試的端到端模式，而 Glue 就在那條路徑上。K21 Academy 把「Amazon EMR with Spark 用於資料轉換」列為學習重點，其中陷阱是 EMR 在大多數 MLA-C01 題幹中是錯誤答案，因為 Glue 覆蓋了相同功能，且費用更低、管理更少。
白話文解釋 AWS Glue ETL
Glue 是那種看起來像十個產品黏在一起的 AWS 服務（諷刺的是名字本身就暗示了這一點）。三個具體類比讓結構清晰易懂。
類比一：餐廳的備料廚房
想像一間高級餐廳，外場廚師（你的 SageMaker 訓練任務）無法直接從進貨月台拿原食材——肉需要修整、蔬菜需要清洗和切丁、醬汁需要收濃、過敏原標籤需要確認。外場後方的備料廚房就是 AWS Glue——接收原始進貨（S3 原始資料），套用標準化備料程序（PySpark 轉換），並把所有東西放在標有標籤的容器中，讓晚餐時段的廚師隨時可以取用。負責大量切工的備料廚師就是 Glue Spark job——處理繁重的平行工作，可以擴展到任何進來的量。在單一工作台執行單一小任務的學徒廚師（比如做油醋醬）就是 Glue Python shell job——小資料集、單執行緒、比啟動食物調理機便宜得多。處理食物調理機模式不適用的特殊 Python 函式庫的專業廚師就是 Glue Ray job——沒有 Spark 限制的分散式 Python。牆上顯示無程式碼拖拉轉換流程的視覺配方 iPad 就是 Glue DataBrew——給不想寫程式的備料廚師使用。對每批食材抽樣做食品安全檢查的食品安全督察就是 Glue Data Quality——規則如「沒有過期食材、沒有遺失標籤、完整性超過 95%」。記錄每批備料名稱、數量和貨架位置的庫存剪貼板就是 Glue Data Catalog。在白板上排列今天備料任務順序的備料主廚就是 Glue Workflows。
類比二：附品質檢驗站的製造裝配線
把一間汽車工廠想像成從一端接收原物料、從另一端出貨成品車的流程。Glue 是鑄造廠（原始 S3 資料）和最終裝配線（SageMaker 訓練）之間的子裝配大樓。把原始金屬加工成精密零件的 CNC 加工站就是 Glue Spark jobs——在大量資料上做繁重的平行工作。一位技術員在小工作台上做精細小任務就是 Glue Python shell job。使用 Ray 框架執行分散式 Python ML 函式庫的特殊工具區就是 Glue Ray job。讓初級技術員不需要寫程式就能設計轉換的拖拉式 CAD 工具就是 Glue DataBrew。帶著通過/不通過檢查清單（完整性、唯一性、新鮮度、範圍檢查）的品管督察就是 Glue Data Quality——每個不符合清單的批次都被拒絕，生產管理員（CloudWatch alarm）會被通知。品管督察查閱以了解每個零件應該長什麼樣的零件編號剪貼板就是 Glue Data Catalog。把各站串成每日組裝序列的生產排程員就是 Glue Workflows。
類比三：報社的編輯流程
把一家報社從接收原始電訊社稿件（原始 S3 資料）到印出最終版面（ML 就緒資料集）的整個流程想象一下。接收原始電訊社稿件並為篇幅、風格和正確性進行編輯的編輯台就是 Glue ETL——核心轉換功能。負責突發新聞大量內容的副編輯執行 Glue Spark job。在單一桌上處理一篇小稿件的獨立編輯就是 Glue Python shell job。執行平行 Python 腳本生成圖表的資料新聞專業團隊就是 Glue Ray job。美術編輯不需要寫標記語言就能排版的視覺排版工具就是 Glue DataBrew。帶著檢查清單（每個名字拼對、每個數字有來源、每個引言有出處）的事實查核團隊就是 Glue Data Quality。記錄每篇已刊出稿件供日後搜尋的資料庫索引就是 Glue Data Catalog。排列今天編輯週期的製作管理員壁掛圖表就是 Glue Workflows。當副編輯早上看壁掛圖表時，他們清楚地知道哪些桌上工作必須在截稿前完成——那就是考試期望你用 Glue Workflows 建構的依賴圖。
Glue ETL Job 類型——Spark、Python Shell、Ray
Glue 提供三種 ETL job 執行引擎。MLA-C01 考試測試哪種引擎匹配哪種工作負載。
Glue Spark Jobs（預設）
Glue Spark jobs 在受管叢集上執行 Apache Spark。兩種引擎選擇：標準 Spark（Scala 或透過 PySpark 的 Python）和 Glue ETL DynamicFrames（AWS 在 Spark DataFrames 上的擴充，具有 schema 彈性）。Worker 類型：G.1X（4 vCPU、16 GB）、G.2X（8 vCPU、32 GB）、G.4X、G.8X、G.025X（輕量）。Glue 3.0+ 支援 Auto Scaling。用於 GB 到 TB 級轉換、跨大型表的 join、分區寫入、分散式特徵工程。
Glue Python Shell Jobs
Glue Python shell jobs 在單一 worker 上執行單一 Python 腳本（1 DPU = 4 vCPU + 16 GB，或 0.0625 DPU 輕量 = 1 vCPU + 1 GB）。沒有 Spark，沒有分散式處理。用於小型資料（通常 10 GB 以下）、從 API 拉取資料的腳本任務、不值得啟動 Spark 的輕量清理、作為 workflow 一部分呼叫其他 AWS 服務。對於小型工作負載，費用遠比 Spark 便宜。
Glue Ray Jobs
Glue Ray jobs 執行在 Ray 上——一個開源的分散式 Python 框架。用於不適合 Spark 的分散式 Python ML 函式庫（Hugging Face transformers、自訂 PyTorch 預處理、大規模平行推論）。較新的功能，使用案例比 Spark 更窄。Worker 類型 Z.2X（8 vCPU、64 GB）及類似規格。
選擇正確的 Job 類型
- 資料大小 > 10 GB 或需要跨大型表的 join/聚合 → Spark
- 資料大小 < 10 GB、單一腳本邏輯、API 整合、輕量 → Python shell
- 分散式 Python ML 函式庫（Hugging Face 等）→ Ray
- 即時串流 ETL → Spark Streaming on Glue（Spark 的變體）
Glue Python shell jobs 不適合大資料——它們在單一 worker 上執行。MLA-C01 的陷阱是為 100 GB 資料集選擇 Python shell，因為它聽起來更簡單。 Python shell 最大只有 1 DPU（16 GB 記憶體），大約能放下 5-10 GB 的記憶體資料。超過這個大小，Spark 是必須的。訊號「資料能放進記憶體」或「小型查找表」或「API 驅動的腳本」是 Python shell。訊號「TB 級」或「join 兩個大型表」或「分散式特徵衍生」是 Spark。選錯會讓 job 因 OOM 被終止，並在考試中得到錯誤答案。
Glue DataBrew——低程式碼視覺化轉換
DataBrew 是無程式碼/低程式碼的轉換工具。工程師往往傾向忽視它；考試測試它是因為業務分析師和 ML 工程師用它做快速原型開發。
DataBrew 做什麼
DataBrew 提供類似試算表的 UI 來建立配方（recipes）——對資料樣本套用的命名函數序列（分類、篩選、join、編碼）。配方再透過 DataBrew job 套用到完整資料集，在 S3 中產生轉換後的輸出。
250+ 內建轉換
DataBrew 內建 250+ 預建轉換，涵蓋：類型轉換、字串操作、日期解析、統計聚合、one-hot 編碼、標準化、異常值處理、缺失值填補、group-by 聚合、join、樞紐。無需程式碼。
DataBrew 適合的時機
- 快速原型開發——資料分析師可以在 30 分鐘內組成 20 步的轉換。
- 可重複的批次轉換——配方按排程在新資料上執行。
- 資料品質檢查——DataBrew 有自己的資料剖析功能，標記缺失值、異常值、分佈偏移。
- 非工程師自助服務——業務分析師在不涉及資料工程團隊的情況下產生 ML 就緒的資料集。
DataBrew vs Data Wrangler——考試陷阱
這是 MLA-C01 Domain 1 中測試最多的混淆點。兩者都有視覺介面，感覺相似——但它們位於不同的服務，並在不同的點整合。
- Glue DataBrew——AWS Glue 的一部分，與 Glue Data Catalog 和 Lake Formation 整合，作為 Glue jobs 執行，輸出到 S3，由資料工程師和業務分析師用於 ML 之前的通用資料準備。
- SageMaker Data Wrangler——SageMaker 的一部分，與 SageMaker Studio、Feature Store 和 Pipelines 整合，在 SageMaker Processing 中執行，由資料科學家用於 SageMaker 工作流程內的 ML 特定特徵工程。
Glue DataBrew 和 SageMaker Data Wrangler 在視覺上幾乎相同，但解決不同階段的不同問題。 DataBrew 是通用資料準備，整合故事以 Glue/Lake Formation 為中心——輸出到 S3，Glue Catalog 被更新，下游消費者可以是 Athena、Redshift 或 SageMaker。Data Wrangler 是 ML 特定的特徵工程，整合故事以 SageMaker 為中心——輸出直接到 Feature Store 或 SageMaker Pipeline 步驟。MLA-C01 題幹訊號「在 SageMaker Studio 內工作的 ML 工程師」或「匯出到 Feature Store」或「SageMaker Pipeline 的一部分」對應 Data Wrangler。訊號「資料工程師產生整理過的 S3 資料集」或「Glue Catalog 表供 Athena 使用」或「跨非 ML 消費者共享」對應 DataBrew。
Glue Data Quality——內建規則類型
Glue Data Quality 根據聲明的規則驗證資料集，並在違規時使 pipeline 失敗。MLA-C01 期望你能按名稱識別規則分類。
六個規則類別
- Completeness（完整性）——欄位沒有 null 值，或 null 率低於閾值（例如
Completeness "user_id" > 0.99）。 - Uniqueness（唯一性）——欄位值是唯一的，或唯一性率高於閾值（例如
Uniqueness "transaction_id" > 0.999）。 - Freshness（新鮮度）——最新記錄在時間視窗內（例如
Freshness "event_time" < 1 day）。 - Conformance（合規性）——值匹配正規表達式或某個集合（例如
ColumnValues "country" in ["US", "UK", "JP"]）。 - Accuracy（準確性）——欄位值匹配預期統計數值（例如
Mean "amount" between 100 and 200）。 - Drift（偏移）——與基線的分佈比較（進階，需要基線 ruleset）。
Data Quality Definition Language（DQDL）
規則以 DQDL 編寫——一種為這些檢查專門設計的聲明式語言。範例：
Rules = [
Completeness "user_id" > 0.99,
Uniqueness "transaction_id" = 1.0,
ColumnValues "country" in ["US", "UK", "JP", "AU"],
IsComplete "amount",
Mean "amount" between 50.0 and 500.0
]
整合點
Data Quality 規則可作為 Glue ETL job 中的一個步驟、Glue Workflow 中的一個節點，或針對 Data Catalog 中的表執行。失敗的規則發出 CloudWatch metrics，並可觸發 EventBridge 事件以啟動修復工作流程或阻止下游訓練。
MLA-C01 為何在意
垃圾資料訓練出垃圾模型。考試期望你知道 Glue Data Quality 是 AWS 原生基於規則的驗證，有別於 SageMaker Data Wrangler 的剖析報告（視覺化且是一次性的，不是持續的規則），也有別於 SageMaker Model Monitor（監控已部署模型的推論輸入，不是訓練資料準備）。
Glue Crawlers 和 Data Catalog——Schema 探索
Crawlers 是最常被混淆的 Glue 功能。MLA-C01 會直接測試 Crawler 與 ETL 的區別。
Crawler 做什麼
Glue Crawler 掃描 S3 位置（或 JDBC 來源），從檔案格式和內容推斷 schema，並建立或更新 Glue Data Catalog 表。Crawler 不轉換資料，不複製資料，不驗證資料品質。它只寫入中繼資料。
Crawler 不做什麼
MLA-C01 最常見的單一陷阱：假設 Crawler 轉換或移動資料。錯誤。Crawler 讀取檔案頭和範例列，建立 schema 定義，在 Data Catalog 中登記，然後退出。S3 中的檔案保持原樣。
Crawler 排程和觸發
Crawler 按排程（cron）或按需執行。ML pipeline 的最佳實踐：每晚排程 Crawler 以偵測新分區和 schema 變更；或者在 ETL job 中直接使用 Glue ETL 的 enableUpdateCatalog 來更新分區，而不需要重新執行 Crawler。
Schema 演進處理
當 Crawler 偵測到 schema 變更（新欄位、類型變更）時，它更新 Data Catalog 表。針對舊 schema 的現有查詢可能中斷或對缺失欄位回傳 null。正式 ML pipeline 應透過 Lake Formation 或 DDL 管理的表明確鎖定 schema，而不是讓 Crawler 自動更新正式 schema。
Glue Crawler 探索 schema 並更新 Data Catalog。它不轉換、複製或驗證資料。 這是 MLA-C01 Domain 1 中測試最多的單一區別。錯誤答案模式：題幹描述「我需要把 CSV 轉換成 Parquet 供 SageMaker 使用」，候選答案中包含「對來源 bucket 執行 Glue Crawler」。錯誤——Crawler 不轉換格式。正確答案是「執行一個讀取 CSV 並寫出 Parquet 的 Glue ETL job，然後執行 Crawler（或在 ETL job 中使用 enableUpdateCatalog）把 Parquet 輸出登記到 Data Catalog。」Crawler = 中繼資料。ETL job = 資料移動和轉換。
PySpark on Glue——大規模特徵衍生
大多數 ML 的正式 Glue ETL 都是透過 Glue 的 notebook 或本地開發工作流程以 PySpark 編寫。考試不測試 PySpark 語法，但確實測試概念性的特徵工程模式。
常見特徵衍生模式
- 聚合特徵——
groupBy("user_id").agg(F.count("*"), F.sum("amount"))從交易層級資料行產生使用者層級特徵。 - 視窗特徵——
F.row_number().over(Window.partitionBy("user_id").orderBy("timestamp"))建立序號；滑動視窗計算「過去 5 分鐘的交易次數」。 - 時間衍生特徵——
F.hour("event_time")、F.dayofweek("event_time")產生類別型時間特徵。 - 與查找表 join——對小型表使用廣播，對大型表使用排序合併。
- 編碼——Spark MLlib 的
StringIndexer、OneHotEncoder用於類別變數。
DynamicFrame vs DataFrame
Glue 的 DynamicFrame 是一個 AWS 擴充，比 Spark DataFrames 更好地處理 schema 彈性——當來源資料每行有不一致的類型時很有用。轉換為 DataFrame 進行 Spark MLlib 操作，再轉換回 DynamicFrame 以利用 Glue 的 Catalog 整合。
Pushdown Predicates
對於分區表，把分區篩選下推到讀取中，讓 Glue 只載入相關分區。glueContext.create_dynamic_frame.from_catalog(database="db", table_name="t", push_down_predicate="year=2026 AND month=05") 只讀取 2026 年 5 月的分區，而不是整個表。對大型表的成本控制至關重要。
Glue Job Bookmarks——增量處理
Job bookmarks 追蹤哪些資料已被處理過，讓重新執行只處理新資料。這是增量再訓練的標準模式。
Bookmarks 如何運作
啟用後，Glue ETL job 在每次執行中記錄哪些輸入資料被讀取的狀態（S3 來源的 S3 keys，JDBC 來源的主鍵）。下次執行時，job 跳過已處理的資料。狀態按 job 和來源儲存。
Bookmark 模式
- Enable——預設；追蹤狀態，只處理新資料。
- Disable——每次執行都重新處理所有資料（用於一次性轉換或回填）。
- Pause——暫停 bookmark 前進（在不丟失狀態的情況下除錯很有用）。
Bookmark 限制
Bookmarks 對追加式來源（S3 中的新檔案、JDBC 表中的新資料列）運作正常。它們不追蹤更新或刪除——對於 CDC 式來源，使用 AWS DMS 到 S3，然後用處理 upsert 合併邏輯的 Glue ETL job。
何時在 ML 中使用 Bookmarks
每晚的 ML 再訓練通常只讀取前一天的資料，join 到緩慢變化維度表，並產生新的訓練分區。Bookmarks 使這個過程具有冪等性且低成本。
與 SageMaker 的整合
Glue ETL 的下游幾乎總是 SageMaker。整合模式不那麼光鮮，但與考試相關。
S3 路徑交接
最簡單的模式：Glue ETL 把 Parquet 寫入整理過的 S3 前綴；SageMaker 訓練從那個前綴讀取。整合點是 S3 路徑字串，作為 SageMaker 訓練 job 輸入傳入。
Glue Data Catalog 作為 SageMaker 表
SageMaker Data Wrangler 可以直接從 Glue Catalog 讀取，把表視為來源。這避免了硬編碼 S3 路徑，並繼承 Lake Formation 權限。
Glue ETL 作為 SageMaker Pipeline 步驟
SageMaker Pipelines 支援包裝任何計算 job 的 ProcessingStep，包括透過 Lambda 或直接呼叫的 Glue ETL。正式 ML pipeline 的最佳實踐：透過一個 Pipeline 協作 Glue ETL → Feature Store 擷取 → SageMaker 訓練 → Model Registry。
從 Glue 擷取到 Feature Store
Glue ETL 輸出可以透過呼叫 PutRecord 的 SageMaker Processing job 餵入 Feature Store 的線上端，或直接追加到離線 S3 位置。透過 PySpark 程式碼呼叫 Feature Store API，就是直接從 Glue 到 Feature Store 的擷取。
Amazon EMR vs Glue——何時使用各自
EMR 是更強大、更靈活的 Hadoop/Spark 平台；Glue 是無伺服器、更簡單的 ETL 服務。MLA-C01 考試測試 EMR 是正確答案的時機。
EMR 的優勢
- 自訂 Spark/Hadoop 版本——EMR 支援 Glue 不支援的特定開源版本。
- 自訂 bootstrap actions——在叢集啟動時安裝任意函式庫。
- 長期執行叢集——EMR 叢集可以持續運行數天，Glue jobs 是每次執行一次。
- 混合工作負載——同一叢集上同時執行 Hive、Presto、HBase、Flink 和 Spark。
- 超大規模的成本控制——EMR 搭配 Spot 和 Reserved Instances 在 24/7 高使用率下可能比 Glue 便宜。
Glue 的優勢
- 無伺服器——無需叢集管理，兩次執行之間縮至零。
- 更快啟動——分鐘級 vs EMR 更長的佈建時間。
- 內建 catalog 整合——Glue Data Catalog 是預設；EMR 可以使用但不附帶整合。
- 按 job 計費——只為執行時間付費。
決策啟發式
大多數 ML pipeline 的間歇性 ETL jobs（每晚、每小時），Glue 是正確答案。24/7 串流工作負載、非常大的持久 Spark 叢集，或需要自訂 Spark 版本的工作負載，EMR 是正確答案。MLA-C01 題幹訊號「受管無伺服器 Spark 用於每晚 ETL」是 Glue。訊號「長期執行叢集、自訂套件」是 EMR。
大多數 MLA-C01 ETL 題幹，Glue 是比 EMR 更好的答案——Glue 是 AWS 對無伺服器 ETL 的首選預設。 只有當題幹包含特定訊號時才選 EMR：「Glue 不支援的自訂 Spark 版本」、「長期執行 24/7 叢集」、「混合 Hadoop 生態系（Hive + Presto + HBase）」，或「非常高的持續使用率使 Spot Instances 讓 EMR 在規模化時更便宜」。沒有這些訊號時，選 EMR 而不是 Glue 會讓你失去簡單性、整合性和考試分數。
Glue Workflows 和 Triggers——多步驟協作
Glue Workflows 把多個 Glue jobs 和 crawlers 協作成一個 DAG。
Workflow 組件
- Triggers——根據排程、按需或其他 job/crawler 完成來啟動 jobs。
- Jobs——作為 workflow 節點的 Glue ETL jobs。
- Crawlers——作為 workflow 節點的 Glue Crawlers。
- 條件觸發器——當上游節點成功（或失敗）時觸發。
Workflow vs SageMaker Pipelines vs Step Functions
存在三個協作選項。Glue Workflows 只限 Glue 資源——純 ETL DAG。SageMaker Pipelines 協作 ML 特定步驟，包括訓練、調優、Registry。Step Functions 是通用的，可以協作 Glue、SageMaker、Lambda 和任何 AWS 服務。對於純 ETL DAG，Glue Workflows 最簡單。對於 ML 端到端（ETL → 訓練 → 部署），SageMaker Pipelines 是首選。
EventBridge 作為跨服務觸發器
EventBridge 排程觸發 Glue Workflows；來自 Glue 的 EventBridge 事件（job 狀態變更）觸發下游動作如 SageMaker Pipeline 執行。標準模式：每晚 EventBridge 排程 → Glue Workflow（ETL + Crawler）→ 成功時，EventBridge 事件 → SageMaker Pipeline。
ML 工作負載的成本模型和優化
Glue 費用由 DPU-hours 驅動。了解控制桿可以防止預算驚喜。
DPU 定價
- Glue 4.0+ Spark Standard worker（G.1X）：$0.44 每 DPU-hour。
- G.2X、G.4X、G.8X 按 DPU 線性擴展。
- Python shell（1 DPU）：$0.44/小時，或 0.0625 DPU 輕量版 $0.0275/小時。
- Glue Ray：按 Ray worker 容量計費。
Auto Scaling
Glue 3.0+ 支援 Auto Scaling——workers 擴展以處理負載，然後縮減。在工作負載突發時減少過度佈建的浪費。
成本優化控制桿
- 下推謂詞以只讀取相關分區。
- 使用 bookmarks只處理新資料。
- 調整 worker 大小——從 G.1X 開始，如果遇到記憶體壓力再擴展到 G.2X。
- 小 job 使用 Python shell——以 0.0625 DPU 輕量版，一個小任務只需幾美分。
- 使用 Glue Spark UI 識別慢步驟和偏斜 join。
- 在正式程式碼中避免
count()和show()——這些觸發完整掃描。
Glue job bookmarks 加上 pushdown predicates 是兩個在每次再訓練執行中都能自我回收成本的優化控制桿。 Bookmarks 確保 job 只處理新分區；pushdown predicates 確保只掃描相關分區。沒有它們，每晚的再訓練 job 每晚都重讀整個歷史資料集——1 TB 歷史資料集每晚處理會每月燒掉 30 TB 的讀取 I/O，而不是 30 GB/月。MLA-C01 題幹訊號「增量每晚 ML 再訓練」或「最小化重新處理的成本」對應 bookmarks + predicate pushdown。
Glue ETL 常見考試陷阱
陷阱一——Glue Crawler 轉換資料
錯誤。Crawler 探索 schema 並寫入中繼資料。ETL jobs 轉換資料。兩者是分開的。
陷阱二——Python Shell Job 用於大資料
錯誤。單一 worker，最大約 10 GB 記憶體資料。大資料用 Spark。
陷阱三——DataBrew 和 Data Wrangler 可互換
錯誤。不同的服務，不同的整合點。DataBrew = Glue/Lake Formation 為中心的通用資料準備。Data Wrangler = SageMaker 為中心的 ML 特徵工程。
陷阱四——EMR 總是比 Glue 便宜
錯誤。Glue 在間歇性工作負載下更便宜。只有在 24/7 高使用率下，EMR 搭配 Spot 才會更便宜。
陷阱五——Bookmarks 追蹤更新和刪除
錯誤。Bookmarks 追蹤追加式進度。CDC 用 DMS 到 S3，再加上 Glue 合併 job。
陷阱六——Glue Data Quality 和 Model Monitor 是一樣的
錯誤。Glue Data Quality 在訓練前驗證訓練資料。Model Monitor 在部署後監控推論資料。不同階段。
陷阱七——Glue Workflows 可以協作 SageMaker
錯誤。Glue Workflows 只限 Glue jobs/crawlers。ML 端到端協作使用 SageMaker Pipelines 或 Step Functions。
決策矩陣——Glue 服務選擇
| 使用案例 | 正確服務 | 錯誤答案陷阱 |
|---|---|---|
| 每晚 TB 級 ETL 帶 join | Glue Spark + bookmarks | Glue Python shell |
| 小型 API 驅動腳本（< 1 GB） | Glue Python shell | Glue Spark（殺雞用牛刀） |
| 分散式 Hugging Face 推論 | Glue Ray | Glue Spark |
| 分析師的視覺化轉換 | Glue DataBrew | Glue ETL notebook |
| SageMaker Studio 內的 ML 特徵工程 | SageMaker Data Wrangler | Glue DataBrew |
| 探索新 S3 資料的 schema | Glue Crawler | Glue ETL |
| 把 CSV 轉換成 Parquet | Glue ETL job | Glue Crawler |
| 24/7 長期執行 Spark 叢集 | Amazon EMR | Glue |
| 驗證訓練資料品質 | Glue Data Quality | SageMaker Model Monitor |
MLA-C01 必記數字
- Glue Spark G.1X：4 vCPU、16 GB、$0.44/DPU-hour（Glue 4.0）
- Glue Python shell：1 DPU 或 0.0625 DPU 輕量版
- Glue job bookmark：按來源追蹤追加式進度
- Glue Crawler：只寫入中繼資料，不轉換資料
- DataBrew：250+ 內建轉換，基於配方
- Glue Data Quality DQDL：completeness、uniqueness、freshness、conformance、accuracy、drift
- Glue Workflows：只協作 Glue jobs/crawlers，不協作 SageMaker
- EMR：長期執行叢集、自訂 Spark 版本、Hive/Presto/HBase 支援
MLA-C01 exam priority — AWS Glue ETL 用於 ML Pipeline — MLA-C01 ML Engineer 學習筆記. This topic carries weight on the MLA-C01 exam. Master the trade-offs, decision boundaries, and the cost/performance triggers each AWS service exposes — the exam will test scenarios that hinge on knowing which service is the wrong answer, not just which is right.
常見問題——AWS Glue ETL 用於 ML 熱門問題
Q1——何時應選擇 Glue Spark 而非 Glue Python shell？
決策在於資料量和平行度。Glue Python shell 在單一 worker 上執行（最大 1 DPU = 16 GB 記憶體），無法利用平行處理。對於超過約 5-10 GB 的資料集，或需要跨分區資料進行 join、聚合或視窗函數的工作負載，Glue Spark 是必須的。對於 5 GB 以下的資料集、單流 API 整合，或協作其他 AWS 服務的腳本，Python shell 的費用要便宜得多（特別是 0.0625 DPU 輕量版，$0.0275/小時）。MLA-C01 題幹訊號「TB 級」或「join 兩個大型表」指向 Spark；「小型 API 整合」或「放得進記憶體」指向 Python shell。
Q2——Glue DataBrew 和 SageMaker Data Wrangler 有什麼差別？
兩者都是視覺化的無/低程式碼資料轉換工具，感覺相似——但它們位於不同的服務，在 pipeline 的不同點整合。Glue DataBrew 是 AWS Glue 的一部分，與 Glue Data Catalog 和 Lake Formation 整合，作為 Glue jobs 執行，輸出到 S3。由資料工程師和業務分析師用於可能供 ML、BI 儀表板或資料倉儲使用的通用資料準備。SageMaker Data Wrangler 是 SageMaker Studio 的一部分，直接與 Feature Store 和 SageMaker Pipelines 整合，在 SageMaker Processing 中執行，由資料科學家和 ML 工程師用於 SageMaker 工作流程中的 ML 特定特徵工程。考試陷阱是問「在 SageMaker Studio 工作的 ML 工程師想做特徵工程」——那是 Data Wrangler，不是 DataBrew，即使兩者技術上都可以完成工作。
Q3——Glue Crawler 會把我的資料轉換成不同格式嗎？
不會。Glue Crawler 只探索 schema 並把中繼資料寫入 Glue Data Catalog。S3 中的資料檔案保持原來的格式不變。如果你需要把 CSV 轉換成 Parquet，你必須執行一個讀取 CSV 並寫出 Parquet 的 Glue ETL job——然後可選擇性地執行 Crawler（或在 ETL job 中直接使用 enableUpdateCatalog）把新的 Parquet 輸出登記到 Data Catalog。這個 Crawler 與 ETL 的區別是 MLA-C01 Domain 1 中測試最多的要點之一，錯誤答案模式是建議僅靠 Crawler 就能解決轉換問題。
Q4——如何在不每晚重新處理完整歷史資料集的情況下處理增量 ML 再訓練？
兩個機制一起運作。Glue job bookmarks 追蹤哪些資料已被處理（S3 來源的 S3 keys，JDBC 來源的主鍵），並在後續執行中跳過已見過的資料。Pushdown predicates 在讀取時篩選，只載入相關分區——push_down_predicate="year=2026 AND month=05 AND day=02" 只讀取一天的分區資料。結合兩者：bookmarks 用於「自上次執行以來有什麼是新的」，pushdown predicates 用於「只讀我現在關心的分區」。沒有它們，每晚的再訓練 job 每晚都重讀完整歷史，燒掉大量 I/O 費用。有了它們，job 在幾秒到幾分鐘內處理完新的每日分區。
Q5——何時應使用 Amazon EMR 而非 AWS Glue 做 ML 預處理？
EMR 在三種情況下是正確選擇。第一，當你需要 Glue 尚未支援的特定 Apache Spark 版本時（Glue 比最新的 Spark 版本落後幾個月）。第二，當你需要一個用於串流或互動式工作負載的 24/7 長期執行叢集時——Glue jobs 是每次執行一次且有啟動開銷，EMR 可以持續運行。第三，當你需要混合 Hadoop 生態系服務如 Hive、Presto、HBase 或 Flink 與 Spark 在同一叢集上時。對於典型的 MLA-C01 ETL 工作負載（每晚批次 ETL、每小時轉換、按需特徵衍生），Glue 是 AWS 推薦的答案，因為其無伺服器經濟性和更緊密的 Catalog 整合。考試題幹訊號「自訂 Spark 版本」或「長期執行」或「Hive + HBase」指向 EMR；否則預設選 Glue。
Q6——Glue Data Quality 規則如何融入 ML pipeline？
Glue Data Quality 作為 Glue ETL job 中的一個步驟或 Glue Workflow 中的一個節點執行，根據以 DQDL（Data Quality Definition Language）編寫的規則驗證資料集。常見 ML 規則：Completeness "user_id" > 0.99（無缺失 user ID）、Uniqueness "transaction_id" = 1.0（無重複交易）、Freshness "event_time" < 1 day（資料是最新的）、ColumnValues "country" in ["US", "UK", "JP"]（只有預期類別）。規則失敗時，job 要麼失敗並停止（阻止下游訓練），要麼發出 CloudWatch metrics 和 EventBridge 事件進行警報。把 Data Quality 放在原始資料擷取和 ML 訓練之間，這樣壞資料就永遠不會到達模型。這不同於 SageMaker Model Monitor，後者針對已部署模型的輸入執行，監控正式環境的偏移——Data Quality 是訓練前，Model Monitor 是部署後。
延伸閱讀——官方 AWS 文件
如需超出 MLA-C01 範圍的深度資料，權威的 AWS 來源包括：AWS Glue 開發者指南（job 類型、bookmarks、workflows）、AWS Glue DataBrew 開發者指南、AWS Glue Data Quality 文件（DQDL 參考）、Amazon EMR 管理指南（用於 EMR vs Glue 比較）、AWS Lake Formation 開發者指南（catalog 權限），以及 AWS Well-Architected Framework 的 Machine Learning Lens。AWS Big Data Blog 有豐富的 Glue ETL 模式報導，AWS Machine Learning Blog 有多篇端到端文章展示 Glue 餵送 SageMaker 訓練的流程。