AWS Glue ETL — Job Bookmarks、DynamicFrames 與 PySpark

AWS Glue 是 AWS 資料工程技術堆疊中的 ETL 核心服務，也是 DEA-C01 考試中測試最密集的服務之一。領域 1（資料擷取與轉換，權重 34%）在多個任務陳述中都高度依賴 Glue。來自 Tutorials Dojo、Digital Cloud Training 和 ExamCert.App 的社群學習指南都指出了相同的痛點 — 考生容易混淆 DynamicFrames 與 DataFrames、誤用工作書籤 (job bookmarks)、掉進會建立重複資料表的爬網程式分割區陷阱，並為工作負載選擇了錯誤的工作節點類型。在考試中選錯答案通常也意味著在實際生產環境中會出錯：配置錯誤的爬網程式會建立五十張資料表而不是一張，進而破壞下游的所有 Athena 查詢；針對錯誤鍵值配置的書籤會導致每次執行都重複處理數 TB 的資料；而為 Parquet 彙總任務配置的 G.1X 叢集則可能在批次處理一小時後發生 OOM（記憶體耗盡）。

本指南從資料工程師的角度出發，涵蓋了 AWS Glue 的定義、三種工作類型及其適用場景、DynamicFrame 抽象化、Glue 上的 PySpark 轉換、用於增量處理的工作書籤、包含多表分割區陷阱在內的爬網程式行為、小檔案問題與 groupFiles 選項、工作節點類型與 DPU 分配、用於多步驟流水線的 Glue 工作流程 (Workflows)、連接類型與 VPC 配置，以及最常讓資料工程師失分的典型考試陷阱。讀完本指南後，您應該會對 Glue ETL 的操作介面感到如魚得水。

什麼是 AWS Glue？

AWS Glue 是一項全託管、無伺服器的 ETL（擷取、轉換、載入）服務，它將基於 Spark 的執行引擎、中繼資料目錄和工作流程編排器整合到一個平台中。它的存在是因為在原始 EMR 或自管 Spark 上構建資料流水線需要資料工程師處理叢集佈建、自動擴展、程式庫管理、排程和中繼資料控管 — 而 Glue 處理了所有這些事務，並僅按工作執行期間消耗的運算資源計費。DEA-C01 考試將 Glue 視為「AWS 上託管 ETL」的預設答案，並測試將其與 EMR 或基於 Lambda 的替代方案區分開來的操作細節。

Glue 工作類型 — Spark、Python Shell、Ray

Glue 提供三種工作類型，每種都適合不同的工作負載規模和語言。Spark 工作（最常見）使用 PySpark 或 Scala 在多個工作節點上運行分散式 Apache Spark — 適用於超過幾 GB 的任何 ETL 工作負載。Python shell 工作運行單個 Python 程序，最多使用 1 DPU，非常適合輕量級任務，例如調用 API、運行小型 SQL 轉換或在排程環境中調用其他 AWS 服務。Ray 工作（較新）使用 Ray 框架運行分散式 Python 工作負載，適用於不符合 Spark RDD 模型的平行 Python 任務 — 典型場景包括機器學習預處理或圖形計算。

Glue 版本與執行期

Glue 版本固定了底層的 Spark、Python 和程式庫版本。Glue 3.0 提供 Spark 3.1，Glue 4.0 提供帶有自適應查詢執行的 Spark 3.3，而 Glue 5.0 則提供 Spark 3.5。每個版本都有不同的每 DPU 小時價格和功能支持 — 例如，Iceberg 原生支持是在 Glue 4.0 中引入的。考試預計您知道較新的 Glue 版本提供較新的 Spark，且自適應查詢執行 (AQE) 和動態分割區修剪 (DPP) 是 3.0 之後的版本功能，可以在不更改程式碼的情況下提高性能。

白話文解釋 AWS Glue ETL

Glue ETL 的操作介面屬於那種光看名稱無法傳達其權衡取捨的系統。以下三個具體的類比可以幫助您牢記其結構。

類比 1 — 餐廳備料廚房與食譜卡

想像一個餐廳的備料廚房。主廚寫了一張食譜卡，詳細說明了切什麼、順序為何、放入什麼容器以及使用什麼調味料。這張食譜卡就是 PySpark 腳本 — 它用程式碼拼寫出轉換邏輯。備料廚師就是 DPU 工作節點 — 他們是平行執行食譜卡指令的分散式勞動力。大型冷藏庫存放原始食材（來源 S3 儲存桶）和完成的備料容器（目標 S3 儲存桶）。主廚的筆記本記錄了哪些進貨已經處理過，這樣早班團隊就不會重複昨天的行程 — 那本筆記本就是 Glue 工作書籤。廚房裡所有食材和容器的清單就是 Glue 資料目錄 (Data Catalog)。

當 Glue 工作執行時，食譜卡（腳本）被發送給備料廚師 (DPU)，他們讀取原始食材（S3 來源），遵循食譜（轉換），寫入備料容器（S3 目標），然後主廚更新筆記本（書籤）。如果廚房很忙，更多的備料廚師（更多 DPU）可以更快完成但成本更高 — 常規食譜選擇 G.1X（每個工作節點 4 vCPU, 16 GB RAM），而對於彙總數百萬行等記憶體密集型食譜則選擇 G.2X（每個工作節點 8 vCPU, 32 GB RAM）。爬網程式是調度員，他穿梭於冷藏庫，並在有新食材到達時更新清單 — 沒錯，如果調度員做事馬虎，將每次到貨都標記為不同食材，就會為同一種番茄建立五十個項目，這正是爬網程式分割區陷阱。

類比 2 — 圖書館採訪與編目部門

想像一個研究圖書館。採訪部門接收成箱的新書（原始 S3 資料），編目員閱讀每本書並分配中繼資料（爬網程式填充 Glue 資料目錄），而謄寫團隊將舊手稿重寫為現代版本（ETL 工作轉換資料）。編目員的紀錄簿記錄了哪些書已經處理過，以免重複編目 — 那本紀錄簿就是書籤。中央卡片目錄就是 Glue 資料目錄，可由 Athena、Redshift Spectrum 和 EMR 查詢。

圖書館針對不同工作量有不同的編目人員 — 一名管理員（Python shell 工作，1 DPU）處理少量捐贈，一組分散的編目員（具有多個 DPU 的 Spark 工作）處理成千上萬箱的遺產捐贈。DynamicFrames 就像編目員的工作筆記 — 結構描述靈活，允許欄位缺失或類型模糊的項目，並使用 resolveChoice 決定當同一欄位在不同書籍中具有兩種類型時該怎麼辦。DataFrames 是最終的卡片目錄格式 — 嚴格的結構描述，針對檢索進行了優化。編目員先在 DynamicFrame 中草擬，潤飾結構描述，然後轉換為 DataFrame 以生成最終的 Parquet 輸出。

類比 3 — 郵政服務分揀設施

想像一個郵政分揀設施。郵務車從區域辦事處到達（S3 來源），分揀員按目的地路由每個包裹（DPU 上的 PySpark 轉換），然後出境貨車出發前往遞送路線（S3 目標）。設施備有一份遞送日誌，標記哪些郵件批次已經分揀，這樣下一班次就不會重新分揀昨天的郵件 — 那份日誌就是書籤。描述每條街道和郵遞區號的地址簿就是資料目錄。

主管決定每班配備多少名分揀員 — 這就是 DPU 分配。工作書籤只有在每個包裹都有唯一的追蹤號碼，以便分揀員可以與日誌比對時才有效 — 這就是書籤鍵選擇，如果鍵值選錯（使用非唯一欄位），意味著包裹會被重新分揀或遺漏。爬網程式是檢查員，他們巡視接收碼頭並將新的寄件人地址添加到地址簿中 — 如果檢查員馬虎，將來自「五大道 100 號 A 單元」和「五大道 100 號 B 單元」的包裹視為完全不同的地址，這就是爬網程式分割區陷阱，當分割區前綴被誤讀時會建立重複的資料表。

DynamicFrames — 針對凌亂資料的結構描述彈性

DynamicFrame 是 Glue 在 Spark 之上構建的結構描述靈活的資料抽象化。

為什麼需要 DynamicFrames

Apache Spark DataFrames 要求預先定義結構描述 — 每個欄位只有一種類型，且行資料必須符合規範。現實中的資料，特別是來自 API 或串流日誌的半結構化 JSON，經常違反這一點。一個欄位可能在一條記錄中是字串，而在另一條記錄中是整數。舊記錄中可能缺少某個欄位。當 Spark 在預期整數的地方看到字串時，讀取時結構描述推斷 (Schema-on-read inference) 就會失敗。DynamicFrames 通過為每個欄位承載多個類型選項，並將解析推遲到工程師控制的顯式操作來解決這個問題。

resolveChoice — 當存在多種類型時選擇一種

當 DynamicFrame 欄位承載 Choice(string, int) 時，resolveChoice 轉換會告訴 Glue 如何處理：將所有內容強制轉換為單一類型、投影到兩個獨立的欄位，或捨棄模糊的行。常見模式包括 make_cols（拆分為 colname_string 和 colname_int）、cast:string（強制轉換為字串）或 match_catalog（使用 Glue 資料目錄結構描述作為目標類型）。考試預計您知道 DynamicFrames 用於處理髒資料，而 resolveChoice 是在下游取用者查詢結果之前消除類型模糊的操作。

何時將 DynamicFrame 轉換為 DataFrame

DynamicFrames 在擷取資料時很方便，但在進行 SQL 風格的轉換時比 DataFrames 慢，因為它們承載了額外的中繼資料。標準模式是：將來源讀取為 DynamicFrame，運行諸如 resolveChoice 和 relationalize 之類的結構描述靈活性操作，然後調用 toDF() 轉換為 DataFrame 以進行聯接 (join)、彙總 (aggregation) 和寫入。當您需要通過 Glue 的目錄感知接收器 (catalog-aware sink) 進行寫入時，反向路徑 fromDF() 會將 DataFrame 重新包裝為 DynamicFrame。

考試中的 DynamicFrames vs DataFrames

如果情境是「具有不一致欄位的原始 JSON 需要 ETL」，請選擇 DynamicFrames。如果情境是「在已知結構描述上進行最快彙總」，請選擇 DataFrames。如果情境是「兩者兼得」，請選擇 DynamicFrame 後轉換為 toDF 的模式。請記住：DynamicFrames 解決的是髒資料問題，DataFrames 解決的是性能問題，兩者之間的轉換只是單行 API 調用。

Glue 上的 PySpark — 轉換詞彙表

PySpark 是 Glue Spark 工作的主流語言。

使用 GlueContext 讀取來源

GlueContext.create_dynamic_frame.from_catalog 方法讀取在 Glue 資料目錄中註冊的來源，並套用您提供的任何分割區下推述句 (partition pushdown predicate)。from_options 變體則直接從 S3、JDBC 或其他來源讀取，無需目錄項目。基於目錄的讀取是推薦模式，因為它們會自動獲取爬網程式更新的結構描述。

常見轉換

Glue 上的 PySpark 支持完整的 Spark API 以及 Glue 特有的轉換。過濾使用 Filter.apply，聯接對於 DynamicFrames 使用 Join.apply 或對於 DataFrames 使用標準 DataFrame.join，彙總使用 groupBy().agg()，而欄位選擇則使用 SelectFields 或 DropFields。Map.apply 轉換將 Python 函數逐行應用於 DynamicFrame，適用於不符合 SQL 表達式的複雜逐行邏輯。對於結構描述重塑，ApplyMapping 可在一個步驟中重命名並強制轉換欄位。

寫入目標

GlueContext.write_dynamic_frame.from_options 將 DynamicFrame 以多種格式寫入 S3，包括 Parquet（首選）、ORC、Avro、JSON 和帶有壓縮選項的 CSV。from_catalog 變體通過目錄資料表定義進行寫入，如果目標已分割，它會自動在目錄中註冊新分割區。對於 DataFrames，標準的 df.write.parquet() 可以直接運行。

分割寫入

寫入分割輸出需要在連接選項中指定 partitionKeys。然後，Glue 會為每個分割值寫入一個 Parquet 檔案（或多個，取決於分割資料量）。分割欄位會從資料檔案中移除，並表示為 S3 前綴 — 典型的 Hive 佈局 year=2026/month=05/day=02/。Athena 和 Redshift Spectrum 通過 Glue 目錄自動發現這些分割區。

工作書籤 — 無需重複處理的增量處理

工作書籤是每次執行僅處理新資料的核心機制。

什麼是書籤

Glue 工作書籤是每個工作的狀態物件，用於追蹤哪些輸入資料已經處理過。在第一次執行時，工作會處理所有內容。在啟用書籤的後續執行中，工作僅處理自上次成功執行以來出現的資料 — 對於 S3 來源基於檔案修改時間，對於 JDBC 來源則基於追蹤的欄位。

書籤模式 — 啟用、停用、暫停

書籤有三種模式。啟用 (Enabled) 在執行結束時更新狀態，並將其用作下次執行的下限。停用 (Disabled) 忽略任何先前的書籤狀態並處理所有輸入。暫停 (Pause) 使用現有書籤作為下限，但在結束時不更新它 — 適用於應從上一個正常檢查點恢復而不前進的重試。

書籤鍵選擇

對於 S3 來源，Glue 預設使用檔案修改時間作為書籤鍵 — 處理在書籤之後修改的檔案。對於 JDBC 來源，書籤鍵必須是您指定的欄位，通常是單調遞增的主鍵或時間戳記欄位。選擇非單調欄位（例如不隨插入順序按字典排序的字串 ID）會破壞書籤語義並導致無聲的資料丟失或重複。

書籤範圍 — 依工作而非全局

書籤是依工作定義的，由工作名稱識別。讀取同一 S3 來源的兩個不同工作維護獨立的書籤。重新命名工作會重置其書籤 — 新名稱沒有歷史記錄。複製工作不會複製書籤。考試常將此設定為「我們刪除並重新建立了工作，現在它重新處理了所有內容」 — 答案是書籤與舊工作名稱綁定，而新工作沒有書籤。

Glue 爬網程式 — 目錄填充與分割區陷阱

爬網程式是 Glue 的中繼資料發現端。

爬網程式的作用

Glue 爬網程式掃描資料存儲（S3 前綴、JDBC 資料庫、MongoDB），推斷結構描述，並在 Glue 資料目錄中註冊資料表。它按排程或按需運行。一旦編入目錄，資料即可由 Athena、Redshift Spectrum、EMR 以及任何使用 Glue 資料目錄作為中繼資料存儲的取用者查詢。

爬網程式配置 — 分類器與排除模式

分類器告訴爬網程式如何解析檔案：內建分類器處理 CSV、JSON、Parquet、ORC、Avro 和 XML；自定義分類器通過 grok 模式處理專有格式。排除模式告訴爬網程式跳過符合模式的檔案 — 例如，**/_temp/** 以跳過暫存目錄，或 **.bak 以跳過備份檔案。配置錯誤的排除模式是導致資料表不完整的常見原因。

多表分割區陷阱

引用最多的 Glue 考試陷阱：掃描具有多個子資料夾的 S3 前綴的爬網程式可能會為每個子資料夾建立一個資料表，而不是為整個前綴建立一個分割資料表。當子資料夾的結構描述略有不同（欄位數量不同、類型不同、檔案格式不同）時，就會發生這種情況 — 爬網程式將它們視為不同的資料表。解決方法是 爬網程式分組行為 (crawler grouping behavior) 選項 — 設定「為每個 S3 路徑建立單一結構描述 (Create a single schema for each S3 path)」以強制爬網程式將各個子資料夾的結構描述合併為一個分割資料表。社群確認的痛點：資料工程師在預期一張 Athena 資料表的地方看到了五十張，偵錯數小時後才發現這個核取方塊。

增量爬取

預設情況下，爬網程式在每次執行時都會掃描整個資料存儲。增量爬取 (Incremental crawls) 僅掃描自上次執行以來新增的新分割區，從而大大降低大型資料湖的爬網成本。通過「僅爬取新子資料夾 (Crawl new sub-folders only)」選項啟用。這要求新資料落在遵循現有佈局的新分割區前綴中 — 向現有分割區添加檔案對增量爬取是不可見的。

DPU 分配與工作節點類型

Glue Spark 工作在可配置的工作節點機群上運行。

什麼是 DPU

DPU (Data Processing Unit) 是 Glue 的計費單位。1 DPU 等於 4 vCPU 和 16 GB 記憶體。您按 DPU 小時付費，按秒計費，且有 1 分鐘的最低限制。DPU 數量乘以工作持續時間即為帳單。

工作節點類型 — Standard、G.1X、G.2X、G.4X、G.8X

工作節點類型定義了每個工作節點的資源形狀。Standard（舊版）為 4 vCPU + 16 GB RAM = 1 DPU，50 GB 本地磁碟。G.1X（大多數工作負載的推薦類型）為 4 vCPU + 16 GB RAM = 1 DPU，64 GB 本地磁碟，網路吞吐量優於 Standard。G.2X 翻倍至 8 vCPU + 32 GB RAM = 每個工作節點 2 DPU，128 GB 本地磁碟 — 適用於大型彙總和聯接等記憶體密集型工作。G.4X 和 G.8X 則針對超大型資料集或記憶體壓力巨大的工作負載（超大型事實表聯接、大型視窗函數）進行進一步擴展。

工作節點數量 vs 自動擴展

您可以手動設定工作節點數量，或啟用自動擴展 (auto-scaling)，這允許 Glue 根據 Spark 階段的需求添加和移除工作節點。自動擴展降低了具有不均勻平行配置之工作的成本（在小型叢集上執行小型最後階段比在最初佈建的大型叢集上執行小型最後階段更便宜）。自動擴展需要 Glue 3.0+，且是依工作啟用的。

選擇正確的工作節點類型

推薦的起點是啟用了自動擴展的 G.1X。當您在 CloudWatch 日誌中看到執行程式 OOM 錯誤，或洗牌 (shuffle) 階段過度溢出到磁碟時，請移至 G.2X。對於非常大的事實表聯接或記憶體受壓的彙總，請移至 G.4X+。考試常將此設定為「工作在 200 GB 洗牌時發生 OOM」 — 答案是升級到 G.2X 或 G.4X。

小檔案問題與 groupFiles

S3 小檔案問題是 Glue 考點中投資報酬率最高的主題之一。

為什麼小檔案會損害 Spark

S3 中的每個檔案都由 Spark 作為一個任務打開、讀取和關閉。如果有 100,000 個小檔案，Spark 會排程 100,000 個任務，其中大多數幾乎不執行任何工作，卻支付了完整的每任務開銷。工作持續時間主要被排程器開銷而非資料處理所佔據。成本激增，且工作會逾時或比應有時間長出數小時。

groupFiles 選項

Glue 的 groupFiles 連接選項告訴讀取器將多個小檔案分組到一個任務中。將 groupFiles 設定為 inPartition，Glue 會在每個分割區內對檔案進行分組。結合 groupSize（每組的目標位元組數，預設為 1 MB 到 1 GB，取決於檔案數量），這將數千個微小任務合併為數百個大小合適的任務。在任何檔案小於 100 MB 的 S3 來源上都應使用此選項。

壓實 (Compaction) 作為永久解決方案

groupFiles 是一種讀取時的緩解措施。永久解決方案是通過定期 Glue 工作將小檔案壓實為大檔案，該工作讀取、重新分割並寫回。Glue 4.0+ 中的 Iceberg 託管表具有內建壓實功能。對於非 Iceberg 佈局，請編寫一個排程 Glue 工作，執行 coalesce(N).write.parquet() 進行合併。目標檔案大小通常為 128 MB 到 1 GB，取決於下游查詢模式。

Glue 工作流程與觸發條件 — 多步驟編排

Glue 工作流程 (Workflows) 在 Glue 內部編排多步驟 ETL。

工作流程結構

Glue 工作流程是觸發條件 (triggers) 和工作 (以及爬網程式) 的有向無環圖 (DAG)。觸發條件根據排程、上游工作完成或按需觸發。每個觸發條件會觸發一個或多個下游工作或爬網程式。Glue 主控台中的視覺化編輯器可構建這些圖形，或者您也可以通過 CloudFormation 或 SDK 進行編寫。

觸發條件類型 — 排程、條件、按需

排程觸發條件按 cron 表達式執行。條件觸發條件在受監視的工作或爬網程式達到目標狀態（成功、失敗、停止）時執行。按需觸發條件僅在通過 SDK 或主控台調用時執行。考試常將「ETL 必須在每日爬網程式之後運行」設定為條件觸發條件的答案。

工作流程執行屬性

執行屬性是工作流程級別的鍵值對狀態，在單次工作流程執行中的各個工作之間共享。使用它們在步驟之間傳遞小型資料 — 例如執行的時間戳記、要處理的分割區值或早期驗證步驟的狀態標誌。執行屬性不能替代通過 S3 進行的適當資料傳遞 — 它們的大小以 KB 為單位，而非 GB。

Glue 工作流程 vs Step Functions vs MWAA

當整個流水線全是 Glue 工作和爬網程式時，Glue 工作流程是正確答案。當流水線跨越 Glue、Lambda、EMR、Redshift 和外部服務時，Step Functions 是正確選擇。對於具有嚴格可觀察性要求的複雜、運行時間長、Python 密集型 DAG，MWAA (Managed Airflow) 是正確選擇。考試會將此作為服務選擇問題；對於僅限 Glue 的流水線，預設選擇 Glue 工作流程。

Glue 連接與 VPC 配置

連接描述了 Glue 如何連接到資料存儲。

連接類型

Glue 支持 JDBC、Kafka、MongoDB、網路 (Network) 和 Marketplace 連接器。JDBC 連接存儲資料庫 URL、憑證（從 Secrets Manager 引用）和 JDBC 驅動程序類。網路連接描述了 Glue 工作在需要訪問私有資源時使用的 VPC 子網和安全群組。

VPC 配置

要訪問私有 VPC 中的資源（RDS 資料庫、私有 API），Glue 工作會通過網路連接在您的 VPC 中運行。這需要 NAT 閘道或適用於 S3 及工作使用的任何其他 AWS 服務的 VPC 端點，再加上允許 Glue ENI 連接目標的安全群組。配置錯誤的 VPC 連接是導致 Glue 工作在啟動時掛起並顯示「無可用 IP 地址」或「無法連接到目的地」錯誤的最常見原因。

跨區域訪問

一個區域中的 Glue 工作無法在不跨越公共網際網路或 VPC 對等互連的情況下直接訪問另一個區域中的資料。考試將此設定為「us-east-1 中的 Glue 工作需要讀取 us-west-2 中的 RDS」 — 答案涉及 VPC 對等互連和網路連接，而不是直接的跨區域讀取。

AWS Glue ETL 的常見考試陷阱

DEA-C01 考試圍繞 Glue 設定了一組一致的陷阱。請務必牢記這七個陷阱。

陷阱 1 — 爬網程式可以轉換資料

某個情境聲稱「我們使用爬網程式來清理和轉換 CSV 資料」。錯誤。爬網程式僅發現結構描述並註冊目錄項目 — 它們從不修改資料。轉換發生在 Glue ETL 工作中，而不是爬網程式中。

陷阱 2 — 書籤在工作之間是全局共享的

考生假設一個書籤涵蓋了讀取相同來源的所有工作。錯誤。每個工作都有自己的書籤，以工作名稱為鍵。重新命名工作會丟失其書籤。

陷阱 3 — DynamicFrames 總是更快

考生為每個工作負載都選擇 DynamicFrames，因為 Glue 文檔以它們為特色。錯誤。對於結構描述已知的操作，DynamicFrames 比 DataFrames 慢。對於凌亂的擷取使用 DynamicFrames，對於繁重的 SQL 轉換請轉換為 DataFrames。

陷阱 4 — G.1X 總是足夠的

考生為了節省成本將每個工作都設定為 G.1X。對於記憶體密集型工作負載（大型聯接和視窗彙總）來說，這是錯誤的，會導致執行程式 OOM。對於記憶體受壓的工作，請選擇 G.2X 或 G.4X，並接受較高的每 DPU 費率。

陷阱 5 — 爬網程式總是建立單個分割資料表

考生假設將爬網程式指向 s3://bucket/data/ 總是會為資料集生成單個分割資料表。如果子資料夾具有結構描述變異，則是錯誤的 — 除非啟用了分組行為，否則爬網程式會為每個子資料夾建立一個資料表。

陷阱 6 — groupFiles 是預設開啟的

考生假設 Glue 會自動批次處理小檔案。錯誤。必須顯式設定 groupFiles=inPartition。預設行為是每個檔案一個任務，這會在小檔案資料集上主導工作時間。

陷阱 7 — Lambda 可以取代 Glue

某種情境建議將 Lambda 用於批次 ETL。對於任何超過幾分鐘的工作負載來說都是錯誤的 — Lambda 的 15 分鐘逾時、10 GB 記憶體上限和 6 MB 有效載荷限制使其不適合批次 ETL。Glue（或調用 Glue 的 Step Functions）才是批次處理的正確答案。

關鍵數據與必背 Glue 事實

工作類型

• Spark — 分散式 PySpark 或 Scala, 2-100+ DPU
• Python shell — 單個 Python 程序, 最大 1 DPU
• Ray — 通過 Ray 框架執行的分散式 Python

工作節點類型

• Standard — 4 vCPU, 16 GB RAM, 1 DPU, 50 GB 磁碟 (舊版)
• G.1X — 4 vCPU, 16 GB RAM, 1 DPU, 64 GB 磁碟 (推薦預設值)
• G.2X — 8 vCPU, 32 GB RAM, 2 DPU, 128 GB 磁碟 (記憶體密集型)
• G.4X / G.8X — 更大的記憶體優化變體

工作書籤

• 模式：啟用、停用、暫停
• 依工作定義狀態，由工作名稱識別
• S3 來源使用檔案修改時間
• JDBC 來源使用配置的鍵值欄位
• 必須調用 job.commit() 才能使狀態持久化

爬網程式

• 發現結構描述，註冊目錄項目（從不轉換資料）
• 分組行為選項可將子資料夾結構描述合併為單個分割資料表
• 增量爬取僅掃描新分割區
• 排除模式可跳過匹配的檔案

DynamicFrames

• DataFrames 的結構描述靈活替代方案
• Choice 類型允許每個欄位同時承載多個類型選項
• resolveChoice 消除類型模糊
• 通過 toDF() 轉換為 DataFrame 以提升性能

小檔案優化

• groupFiles=inPartition 將小檔案批次處理為大小合適的讀取任務
• groupSize 每組目標位元組數（通常為 128 MB）
• 永久解決方案是定期的壓實工作

Glue 工作流程

• 觸發條件與工作/爬網程式組成的 DAG
• 觸發條件類型：排程、條件、按需
• 執行屬性在步驟之間傳遞小型狀態
• 對於非僅限 Glue 的流水線，請使用 Step Functions

常見問題 (FAQ) — AWS Glue ETL 熱門問題

Q1 — 我應該在什麼時候使用 Glue ETL、EMR 或 Lambda 進行資料處理？

當您需要託管 Spark 進行批次 ETL，且希望運作開銷極小（通過爬網程式發現結構描述、與 Athena 和 Redshift Spectrum 的目錄整合、用於增量處理的書籤以及按每 DPU 秒計費）時，請使用 Glue ETL。當您需要自定義 Spark 配置、非 Spark 框架（Hive、HBase、Presto、Flink）、可以分攤啟動時間的長期運行叢集，或對運行環境進行精細控制時，請使用 EMR。僅在低於 15 分鐘的短期事件驅動處理、有效載荷低於 6 MB 且記憶體低於 10 GB 時使用 Lambda — 典型模式是 S3 物件建立觸發器執行的輕量級轉換或路由。對於任何超過幾分鐘的批次 ETL，Lambda 都是錯誤的；對於具有自定義 Hadoop 生態系統依賴項的臨機 Spark 任務，Glue 則是錯誤的；對於叢集啟動時間主導整體時間的短期工作負載，EMR 則是錯誤的。

Q2 — 我該如何防止 Glue 爬網程式為同一個資料集建立多個資料表？

啟用爬網程式的「為每個 S3 路徑建立單一結構描述」選項（也稱為分組行為），這會強制將各個子資料夾的結構描述合併為單個分割資料表。預設行為會將每個具有略微不同結構描述的子資料夾視為獨立資料表 — 額外欄位、不同的檔案格式或不同的壓縮編解碼器都會觸發拆分。其他預防策略包括確保資料集的結構描述在所有分割區中嚴格一致（較新分割區不添加額外欄位）、在整個前綴中使用單一檔案格式和壓縮編解碼器，以及將爬網程式指向分割根目錄而非多個子資料夾。考試常將「爬網程式建立了 50 張資料表而非 1 張」的情境與啟用分組行為作為典型修復方案。

Q3 — 我應該在 Glue 工作中使用 DynamicFrames 還是 DataFrames？

對於擷取凌亂、半結構化或結構描述不一致的資料（例如具有可選欄位的 API JSON、具有混合類型的 CSV 或任何類型在行之間變化的來源），請使用 DynamicFrames。Choice 類型和 resolveChoice 操作是其價值所在。對於在已知結構描述資料上執行性能關鍵的操作（大型聯接、彙總、視窗函數），請使用 DataFrames。標準模式是將來源讀取為 DynamicFrame，執行 resolveChoice 和 relationalize 等結構描述靈活性操作，然後使用 toDF() 進行轉換並將繁重的轉換作為 DataFrames 運行。如果需要通過 Glue 目錄感知接收器寫入，請通過 fromDF() 轉換回來。不要僅僅因為 DynamicFrames 是 Glue 原生的就為所有任務都選擇它 — 它們在處理已知結構描述工作時比 DataFrames 慢。

Q4 — 當工作失敗或重新執行時，書籤會如何表現？

書籤僅在工作腳本於成功執行結尾調用 job.commit() 時才會推進。提交前的失敗會使書籤保持不變 — 下次執行會重新處理相同的資料，這是正確的重試語義。在提交後但在編排器標記執行成功前的失敗仍會使書籤推進 — 下次執行不會重複處理。停用書籤會重新處理所有內容，無論狀態為何。暫停書籤會使用現有的下限讀取但不前進 — 適用於在不丟失生產書籤的情況下測試重新執行。重新命名工作會丟失書籤；新名稱沒有歷史記錄。複製不會複製書籤狀態。考試常將「重新建立工作後，下次執行重新處理了所有資料」的情境與書籤綁定到舊工作名稱作為答案。

Q5 — 我該如何為 Glue 工作調整正確的 DPU 和工作節點類型？

對於中等強度的 ETL，預設從 G.1X（每個工作節點 4 vCPU, 16 GB RAM）和 10 個工作節點開始。執行工作，觀察 CloudWatch 指標中的執行程式 OOM 錯誤、洗牌溢出和 DPU 利用率。如果執行程式發生 OOM 或洗牌過度溢出到磁碟，請升級到 G.2X (8 vCPU, 32 GB RAM) 並減少工作節點數量以保持總計 DPU 相似 — 少量但更強大的工作節點比許多小型工作節點更能處理記憶體密集型任務。對於非常大的事實表聯接或視窗彙總，請使用 G.4X 或 G.8X。啟用 自動擴展 (Glue 3.0+) 讓 Glue 根據階段需求添加和移除工作節點 — 這可以在具有不均勻平行配置的工作上節省成本。在 CloudWatch 中監控 glue.driver.aggregate.shuffleBytesWritten 和 glue.driver.aggregate.shuffleLocalBytesRead 以檢測是否需要更強大工作節點的洗牌壓力。

Q6 — 我該如何解決 Glue 輸入端的小檔案問題？

有兩層修復方案。讀取時緩解 使用 Glue 的 groupFiles=inPartition 連接選項，並將 groupSize 設定為 128 MB 之類的目標值 — 這會在 Spark 排程器級別將小檔案批次處理成大小合理的讀取任務，從而避免每個檔案的任務開銷。這適用於任何檔案小於 100 MB 或每個分割區具有數千個檔案的 S3 來源。永久修復 是定期壓實：排程一個 Glue 工作來讀取小檔案資料集，重新分割成合理的檔案數量，並以較大的 Parquet 檔案（每個目標 128 MB 到 1 GB）寫回。Glue 4.0+ 中的 Iceberg 託管表具有內建壓實功能，可自動處理此問題。如果不進行壓實，小檔案數量會單調增加，查詢會隨著時間推移而變慢 — 這是長期運行資料湖上關鍵的運維衛生任務。

Q7 — 用於編排的 Glue 工作流程、Step Functions 和 MWAA 之間有什麼區別？

當整個流水線全是 Glue 工作和爬網程式時，Glue 工作流程 是正確答案 — Glue 主控台中有視覺化 DAG 編輯器、原生觸發條件類型（排程、條件、按需）、用於共享狀態的工作流程級別執行屬性，以及與 Glue 工作和爬網程式生命週期的緊密整合。當流水線跨越 Glue 加上 Lambda、EMR、Redshift、SageMaker 和外部服務時，Step Functions 是正確選擇 — 具有 Map（用於扇出）、Choice（用於分支）、Retry 和 Catch 錯誤處理以及按狀態轉換計費的完整狀態機模型。對於具有嚴格可觀察性要求的複雜、運行時間長、Python 密集型 DAG，或者團隊已經熟悉 Airflow，或者 DAG 在雲端或本地之間的遷移很重要時，MWAA (Managed Airflow) 是正確選擇。成本權衡：Glue 工作流程和 Step Functions 是按使用付費（每次執行），而 MWAA 不論 DAG 數量多少都有持續的環境成本。對於僅限 Glue 的流水線，預設選擇 Glue 工作流程；對於跨服務的 AWS 流水線，選擇 Step Functions；對於 Airflow 團隊，選擇 MWAA 流水線。

延伸閱讀 — AWS Glue 官方文件

權威的 AWS 來源包括：AWS Glue 開發人員指南概述頁面、涵蓋 Choice 類型和 resolveChoice 的 DynamicFrames 文檔、涵蓋模式和提交語義的工作書籤文檔、涵蓋分組行為和排除模式的爬網程式文檔、工作節點和 DPU 調整大小文檔、groupFiles 和小檔案優化文檔，以及 Glue 工作流程編排文檔。

《AWS Glue 最佳實踐》白皮書是 DEA-C01 最契合考試的資源 — 它在一個文件中涵蓋了 DynamicFrames vs DataFrames 的權衡、書籤語義、爬網程式分割區處理以及 DPU 調整大小。AWS 大數據部落格有多篇關於特定 Glue 主題的深入探討，包括小檔案處理、Iceberg 整合以及跨帳戶目錄共享。Glue API 參考詳細涵蓋了每個轉換方法的簽名和連接選項。最後，AWS Glue GitHub 示例存儲庫包含了常見 ETL 模式（包括增量載入、緩慢變化維度和 CDC 處理）的完整 PySpark 腳本 — 請閱讀這些腳本，將其作為 DEA-C01 測試模式的實際案例。