以 AWS Glue 與 EMR 轉換資料

AWS Glue ETL 與 Amazon EMR 是 AWS 上兩個將原始資料轉換為可分析資料的核心服務。在 AWS Certified Solutions Architect Associate（SAA-C03）考試中，任務說明 3.5 要求考生「決定高效能資料擷取與資料轉換方案」——這直接考驗你能否在正確情境下選出 AWS Glue ETL（小到中型無伺服器作業）、Amazon EMR（大規模 Spark 與 Hadoop 叢集），以及 AWS Step Functions（編排整條管線）。每次 SAA-C03 考試預計出現三到五題與 AWS Glue ETL、EMR 及 Step Functions 相關的題目。

本學習指南解析 AWS Glue ETL 家族的每個元件（Data Catalog、Glue Crawler、Glue Studio 視覺化 ETL、DataBrew recipe、Schema Registry、job bookmarks、triggers、PySpark 與 Python shell 作業、DPU 定價），逐一說明 Amazon EMR（EMR on EC2 vs EMR Serverless vs EMR on EKS、master／core／task 節點架構、HDFS vs EMRFS、task 節點使用 Spot），最後提供 Glue 與 EMR 的決策樹，讓你在三十秒內回答情境題。

AWS 分析生態系中的資料轉換是什麼？

資料轉換是經典模式擷取 → 儲存 → 轉換 → 建立目錄 → 查詢 → 視覺化的中間步驟。原始資料從 Amazon Kinesis Data Streams、Amazon Data Firehose、AWS Database Migration Service（DMS）或 AWS DataSync 等來源落地到 Amazon S3。在分析師或儀表板能夠使用之前，資料通常需要清洗（移除重複項、遮蔽個資）、重塑（join、彙總、pivot），以及重新編碼（CSV 轉 Apache Parquet、JSON 轉 ORC），使下游查詢引擎（如 Amazon Athena 與 Amazon Redshift Spectrum）執行得更快、更省錢。

AWS 提供三種主要的轉換運算選項，SAA-C03 考試測試它們之間的取捨：

1. AWS Glue ETL — 無伺服器 Spark（或輕量級 Python shell），零叢集管理。按 DPU-second 計費。
2. Amazon EMR — 託管 Hadoop 生態系（Spark、Hive、Presto、Flink、HBase），適合最大規模且高度客製化的工作負載。
3. AWS Lambda — 僅適合 15 分鐘以內、10 GB 記憶體以下的微型轉換；不是主要的 ETL 引擎，但對事件驅動的微轉換有效。

圍繞這三者，還有兩個目錄與治理服務（AWS Glue Data Catalog 與 AWS Lake Formation）、一個編排服務（AWS Step Functions），以及儲存層（Amazon S3）。考試測試的是你能否組合出正確的元件。

資料轉換為何對 SAA-C03 重要

任務說明 3.5 明確點名資料擷取與資料轉換。Glue 與 EMR 佔轉換類題目的絕大多數。錯過情境中的單一關鍵字（例如「serverless」、「Spark 程式碼控制」或「Spot task 節點」），是架構師在 Domain 3 失分的最大原因。

白話文解釋 AWS Glue ETL and EMR

三個類比讓 AWS Glue ETL 與 Amazon EMR 一目了然。

類比一 — 辦桌備料廚房

把資料湖想像成一間辦桌餐廳。

• Amazon S3 是後場冷藏室，所有原料（CSV、JSON、Avro、log）一箱箱卸到這裡。
• AWS Glue Data Catalog 是廚房備料單，列出每樣食材放在哪個層架、長什麼形狀（schema）。AWS Glue Crawler 是副廚，主動巡視架子並自動更新備料單。
• AWS Glue ETL 作業是打工備料師傅——無伺服器，有事才來，備料完就下班，不會領空班費。
• AWS Glue Studio 是視覺化食譜卡（拖拉介面），告訴備料師傅怎麼切菜。
• AWS Glue DataBrew 是品管師傅，用現成食譜修正錯字、去除多餘部分、統一份量——完全不需要寫程式。
• Amazon EMR 是大型工業廚房，配備二十四口瓦斯爐與客製設備。你要付整間廚房的費用（叢集），親自調整每口爐（Spark 設定），安排班表（節點規格）。適合一次辦幾千桌的大型工作量。
• AWS Step Functions 是總廚頭手，喊出出菜順序：「先 Glue、再 EMR、接著 Redshift COPY、最後通知」。它是編排者，本身不下廚。

情境說「每天 5 GB log、沒有維運團隊」，找打工備料師傅（AWS Glue ETL）。情境說「20 PB 點擊流、客製 Spark 調校、GPU 機器學習前處理」，開工業廚房（Amazon EMR）。

類比二 — 工廠輸送帶產線

想像一條輸送帶工廠。

• Amazon Kinesis 或 S3 上傳是原物料進貨碼頭。
• AWS Glue Crawler 是條碼掃描器，自動為每個棧板貼標（表格名稱、欄位、型別），並登錄到 AWS Glue Data Catalog 倉管系統。
• AWS Glue Schema Registry 是零件相容性手冊——每個生產者與消費者都必須符合宣告的 schema，避免下游發生螺絲規格不符的問題。
• AWS Glue ETL PySpark 作業是產線上的機械手臂，負責重塑零件（filter、join、aggregate、CSV 轉 Parquet）。
• AWS Glue job bookmarks 是貼在每個棧板上的「上次處理到此」貼紙——機械手臂記得上次停在哪，下次執行只處理新棧板（增量載入，不重複處理）。
• AWS Glue triggers 是產線啟動規則——cron、手動，或事件驅動（A 作業完成 → 啟動 B 作業）。
• Amazon EMR on EC2 是重型鍛造站，你掌控每把鐵鎚（master、core、task 節點）。EMR task 節點搭配 Spot Instance 就像臨時工，成本省 70–90%。
• HDFS 是鍛造站的本地零件箱（暫存）。EMRFS 是廠區共用的中央倉庫（Amazon S3）——叢集關閉後資料依然存在。
• EMR Serverless 是「隨需機器人租賃」——只按作業計費，不需規劃叢集。
• EMR on EKS 是 Kubernetes 管理版本，機器人以容器方式在公司統一的 K8s 叢集上運作。
• AWS Step Functions 是 PLC 控制器，把整條產線串成一個狀態機。

類比三 — 郵政分揀中心

資料湖是一個信件分揀中心。

• 原始信袋（Amazon S3 物件）送達卸貨區。
• Crawler（AWS Glue Crawler）巡視各卸貨區，讀取郵遞區號，更新中央分揀名冊（AWS Glue Data Catalog）。
• 備料員（AWS Glue ETL 作業）將信件重新整理進分類格（CSV → Parquet → 依日期分區）。
• 重型分揀機（Amazon EMR）在尖峰日啟動——就像春節前加開的整批作業叢集。
• Spot Instance task 節點是季節性臨時員工——便宜，但無法保證隨時到班。
• AWS Step Functions 是郵局長的每日工作排程：「先分揀、再重新派送、後出貨、最後報表」。
• 產線末端的 Amazon Athena 與 Amazon Redshift 是回答客戶問題的窗口人員。

三個類比共同遵循一個規則：**Glue 是無伺服器備料、EMR 是託管工廠、Step Functions 是編排者。**掌握這個心智模型，考試題目就變成關鍵字比對。

AWS Glue — 無伺服器 ETL 平台

AWS Glue 是 AWS 的無伺服器資料整合服務。它有五個主要子元件，SAA-C03 考試將它們作為一個整體測試。

AWS Glue Data Catalog — 集中式 metadata 儲存庫

AWS Glue Data Catalog 是一個集中式、相容 Apache Hive 的 metadata 儲存庫。它儲存資料庫（邏輯分組）、資料表（schema、欄位型別、分區規格）、連線（連向 RDS、Redshift、MongoDB、JDBC、Kafka），以及分類器（供 Crawler 偵測使用的規則）。

Data Catalog 前一百萬個物件免費，超過後按每月每十萬個物件計費。同一個 Catalog 可跨 Amazon Athena、Amazon Redshift Spectrum、Amazon EMR、AWS Glue ETL 作業與 AWS Lake Formation 共用。這意味著只需登錄一次資料表，帳號內所有 AWS 分析服務都能使用——設計上的重大優勢。

AWS Glue Crawler — 自動 schema 探索

Crawler 是一個託管程序，掃描資料來源（Amazon S3 前綴、Amazon DynamoDB 資料表、JDBC 資料庫、Delta Lake、Apache Iceberg 資料表、Apache Hudi 資料表），並自動在 AWS Glue Data Catalog 中新增或更新資料表。Crawler 會推斷欄位名稱、型別、壓縮格式、檔案格式（CSV、JSON、Avro、Parquet、ORC、XML），以及分區布局（例如 s3://bucket/year=2026/month=04/day=20/）。

Crawler 考試重點：

• Crawler 可隨需執行，也可依排程執行（cron 表達式）。
• Crawler 支援 Amazon S3 的增量爬取——只處理新增或異動的分區，降低成本。
• Crawler 使用 IAM role 讀取來源並寫入 Catalog。
• 分類器可以是內建或自訂（用於專有格式）。

AWS Glue ETL 作業 — PySpark 與 Python shell

AWS Glue 作業是執行資料轉換程式碼的運算單元。共有三種作業類型：

1. Spark（PySpark 或 Scala） — 分散式，在針對資料湖工作負載最佳化的無伺服器 Apache Spark 引擎上執行。適合大型資料集（GB 到 TB 級）、join、彙總與格式轉換。支援 Glue 的 DynamicFrame 抽象層，建立在 Spark DataFrame 之上，用於彈性處理 schema。
2. Spark Streaming — 從 Amazon Kinesis Data Streams 或 Amazon MSK 消費資料，輸出至 S3、DynamoDB 等。持續執行的作業類型。
3. Python shell — 單一 Python worker（無 Spark），適合小型作業（1 GB 以下）。理想用途包括輕量級 API 呼叫、小檔案轉換，或編排其他服務。因為以 1 DPU 或 1/16 DPU 執行，成本更低。

Glue 作業在 Data Processing Unit（DPU） 上執行。1 DPU = 4 vCPU + 16 GB 記憶體 + 64 GB 磁碟。Spark 作業預設 10 DPU（可設定 2–100+）。Python shell 作業預設 1/16 或 1 DPU。

AWS Glue Studio — 視覺化 ETL

AWS Glue Studio 是一個以瀏覽器為基礎的低程式碼視覺介面，用於建立、執行及監控 AWS Glue ETL 作業。使用者在畫布上拖拉來源 → 轉換 → 目標節點。底層 Glue Studio 會產生可編輯的 PySpark 程式碼。內建轉換包括 Join、Filter、SelectFields、ApplyMapping、Aggregate、SQL、Custom Transform 及資料品質規則。

當考試情境提到「沒有 Spark 經驗的資料工程師」或「視覺化無程式碼 ETL」，Glue Studio 就是正確選項。

AWS Glue DataBrew — 視覺化資料準備與 recipe

AWS Glue DataBrew 是一個純視覺化、無程式碼的資料準備工具，目標使用者是資料分析師（而非工程師）。DataBrew 內建 250 個以上的預建轉換（recipe），例如「移除特殊字元」、「依分隔符號分割」、「格式化日期」與「遮蔽個資欄位」。Recipe 可重複使用且受版本控制。

DataBrew 能對資料集進行剖析（統計數據、遺漏值、離群值），並可排程執行作業。它與 Glue Studio 不同——DataBrew 是分析師用來清洗資料的工具；Glue Studio 是工程師用來建立 ETL 管線的工具。

AWS Glue Schema Registry — 集中式結構描述治理

AWS Glue Schema Registry 讓串流資料的生產者與消費者能夠集中驗證並演進 schema。支援 Apache Avro、JSON Schema 與 Protobuf。整合 Amazon Kinesis Data Streams、Amazon MSK、AWS Lambda，以及 Amazon Managed Service for Apache Flink（前身為 Kinesis Data Analytics）。

考試重點：當情境強調「防止不相容的 schema 變更破壞串流管線的下游消費者」，選 Schema Registry。已登錄的 schema 具有相容性模式（BACKWARD、FORWARD、FULL、NONE）。

AWS Glue Job Bookmarks — 增量處理狀態

Job bookmarks 是 AWS Glue 的內建機制，用於記錄哪些檔案（或資料庫列）已經處理過。下次執行時，Glue 會跳過已處理的紀錄，只轉換新資料。

Job bookmark 模式：

• Enable — 追蹤並持久化狀態。
• Disable — 每次執行都重新處理所有資料。
• Pause — 執行但不更新狀態（適用於除錯或重新處理特定分區）。

Job bookmarks 是「增量 ETL 且不重複處理」和「從上次成功執行繼續」的考試正確答案。

AWS Glue Triggers — 自動啟動作業

Triggers 用於啟動 Glue 作業與 Crawler。三種 trigger 類型：

1. Scheduled — cron 表達式（例如每小時、每天 UTC 02:00）。
2. On-demand — 手動或 API 呼叫（StartJobRun）觸發。
3. Conditional（事件） — 當上游作業（或 Crawler）以 SUCCEEDED、FAILED、TIMEOUT 或 STOPPED 狀態完成時，啟動下游作業。支援純 Glue 的多步驟工作流程。

對於跨越非 Glue 服務（Lambda、EMR、Athena、SNS）的複雜多步驟編排，AWS Step Functions 是更好的選擇。

AWS Glue 定價 — DPU 模型

AWS Glue 按 DPU-hour 計費，以秒計算，ETL 作業最低計費 1 分鐘，Python shell 最低計費 1 分鐘，Crawler 最低計費 10 分鐘。以現行定價為例：

• Spark ETL 作業 — 約 $0.44 每 DPU-hour，每次執行最低計費 10 分鐘，最少 2 DPU。
• Python shell 作業 — 約 $0.44 每 DPU-hour，可選 1/16 或 1 DPU，最低計費 1 分鐘。
• Glue Streaming ETL — 約 $0.44 每 DPU-hour，最少 2 DPU，持續計費。
• Data Catalog — 前 100 萬個物件免費，之後每月每十萬個物件計費；前 100 萬次請求免費，之後按百萬次計費。
• Crawler — 約 $0.44 每 DPU-hour，最低計費 10 分鐘。
• DataBrew — 互動式按 session 分鐘計費，作業按節點-hour 計費。

Amazon EMR — 託管大資料叢集

Amazon EMR（Elastic MapReduce）是 AWS 的託管大資料平台，執行 Apache Spark、Apache Hadoop、Apache Hive、Presto/Trino、Apache HBase、Apache Flink、Apache Livy 與 Apache Zeppelin。當 AWS Glue 的無伺服器 Spark 不夠用時，EMR 是正確選擇：超大資料集（數百 TB 到 PB 級）、客製 Spark 調校、完整 Hadoop 生態系，或長期運行的互動式叢集。

EMR 部署模型 — 三種型態

Amazon EMR 提供三種型態，各自適合不同的運維需求。

1. EMR on EC2 — 經典託管叢集

原始 EMR 模型。你啟動一組 EC2 執行個體，EMR 安裝並設定 Hadoop／Spark。你負責叢集規格、自動擴縮策略、執行個體採購與終止。支援長期運行或瞬態（執行完即終止）兩種模式。

• 最適合 — 可預測的例行工作負載、混合框架管線（Spark + HBase + Hive）、整合客製 AMI 或 bootstrap action。
• 成本控制 — Core 節點使用 Reserved Instance 或 Savings Plan，Task 節點使用 Spot。

2. Amazon EMR Serverless — 按使用量付費的 Spark 與 Hive

Amazon EMR Serverless 無需佈建任何叢集即可執行 Spark 或 Hive 應用程式。你建立一個應用程式（執行環境），提交作業，AWS 自動處理容量。按實際消耗的 vCPU-second、記憶體 GB-second 與儲存 GB-second 計費。

• 最適合 — 爆發性或不可預測的 ETL、想要 Spark 能力卻不想管叢集的團隊、將長期運行的 EMR 叢集現代化為按作業計費。
• 考試重點 — EMR Serverless 消除了運行全天候叢集的運維負擔；精神上接近 Glue ETL，但提供完整 Spark 引擎控制（客製 Spark 設定、自訂 JAR）。

3. Amazon EMR on EKS — 在 Kubernetes 執行 Spark 作業

EMR on EKS 讓你在現有的 Amazon EKS 叢集上執行 Spark 應用程式。你透過 EMR API 提交 Spark 作業，EMR 將其排程為 EKS 節點上的 Pod。你可以將 EKS 叢集與其他非 Spark 工作負載共用，最大化使用率。

• 最適合 — 以 Kubernetes 為標準的組織、多租戶分析平台、跨團隊成本分攤、統一的 Kubernetes 可觀測性。
• 定價 — 支付 EMR on EKS 加價費用，加上底層 EKS／EC2 成本。

EMR 叢集架構 — Master、Core 與 Task 節點

EMR on EC2 叢集有三種節點類型，考試非常喜歡測試這個區別。

1. Master 節點（主要節點） — 每個叢集只有一個。執行 YARN ResourceManager、HDFS NameNode 及作業協調服務。在非 HA 叢集中，若 Master 節點故障，整個叢集將會遺失。EMR 支援三個 Master 節點的**多主節點（HA）**以達高可用性。
2. Core 節點 — 執行 HDFS DataNode 與 YARN NodeManager。在 HDFS 中儲存資料並執行運算任務。遺失 Core 節點可能導致資料遺失（除非複寫機制能救回）。Core 節點幾乎都應使用 On-Demand 或 Reserved——生產環境絕對不能只用 Spot。
3. Task 節點 — 只負責運算的 YARN NodeManager，沒有 HDFS。屬於無狀態 worker。遺失 Task 節點只會損失進行中的運算，YARN 會重新排程。Task 節點是 EC2 Spot Instance 的完美目標，可降低運算成本高達 90%。

EMR 儲存 — HDFS vs EMRFS

EMR 支援兩種檔案系統，SAA-C03 考試直接測試其差異。

• HDFS（Hadoop Distributed File System） — 在 Core 節點的 EBS／instance store 磁碟區上進行本機複寫儲存。暫存性 — 叢集終止後即消失。適合中間 shuffle 與暫時性 MapReduce 資料的快速存取。
• EMRFS（EMR File System） — 以 Amazon S3 為後端實作 HDFS 語意。持久性 — 叢集終止後依然存在。用於輸入、輸出及長期資料。支援瞬態叢集模式：啟動 EMR、從 S3 讀取、處理、寫回 S3、終止叢集。

在詢問「叢集終止後如何保存資料」的考試題目中，答案是 EMRFS（Amazon S3）。HDFS 用於叢集內的暫存資料。

EMR Instance Fleet 與自動擴縮

EMR 支援兩種佈建模型：

• Uniform instance groups — 每種節點角色（master、core、task）使用單一執行個體類型。簡單直觀。
• Instance fleets — 每種角色最多指定五種執行個體類型加上加權容量；EMR 選擇最便宜的組合來達到目標容量。支援 On-Demand 與 Spot 混用，並設定 Spot 備援。成本最佳化效果強。

EMR Managed Scaling 根據 YARN 指標自動調整 Task（以及選擇性的 Core）容量，在你設定的最小與最大範圍內運作。

AWS Step Functions — 編排 ETL 管線

AWS Step Functions 是一個無伺服器工作流程編排服務，將 AWS 服務協調成一個狀態機。對於資料管線，Step Functions 將 AWS Glue 作業、AWS Glue Crawler、Amazon EMR 步驟、AWS Lambda 函式、Amazon Athena 查詢、AWS Batch 作業、Amazon SageMaker 作業，以及自訂 HTTP 端點串接成一個耐久、可重試、可觀測的工作流程。

為何使用 Step Functions 進行 ETL 編排

• 耐久狀態 — 每次狀態轉換都有 checkpoint；故障後可恢復。
• 重試與捕捉 — 宣告式重試策略，支援指數退避。
• 平行分支 — 扇出與扇入的 Parallel 與 Map 狀態。
• 服務整合 — 針對 Glue StartJobRun、EMR RunJobFlow 或 AddStep、Athena StartQueryExecution、Lambda Invoke，以及「等待 callback token」的最佳化整合。
• 兩種工作流程類型 — Standard（最長 1 年、at-most-once、按狀態轉換計費）與 Express（最長 5 分鐘、at-least-once、按請求次數加持續時間計費；適合高流量事件驅動 ETL）。

由 Step Functions 編排的典型 ETL 管線

1. Lambda 在 S3 PutObject（檔案到達）時觸發。
2. Step Functions 啟動狀態機。
3. Glue Crawler 更新 Data Catalog。
4. Glue ETL 作業將原始 CSV 轉換為 Apache Parquet。
5. 平行分支 — 同時執行 EMR Serverless 重量級彙總（用於分析）與 Athena 資料品質查詢（用於驗證）。
6. Choice 狀態 — 若驗證通過則繼續；否則發送 SNS 告警。
7. Glue 作業載入至 Amazon Redshift。
8. SNS 發布「管線完成」通知。

在 SAA-C03 考試中，只要題目描述「具備條件分支、重試與可視性的多步驟 ETL 工作流程」，幾乎都指向 AWS Step Functions，而不是串接 Glue 條件 trigger 或純 Lambda 呼叫。

AWS Glue vs Amazon EMR — 決策框架

這是任務 3.5 中最常被測試的比較。

速記決策樹

1. 資料集幾百 GB 以下 + 不需要 Spark 專業知識 + 執行頻率不定或不頻繁 → AWS Glue ETL。
2. 資料集幾百 GB 到數 TB + 標準 Spark 模式 + 想要無伺服器 → AWS Glue ETL（或若需要 Spark 客製調校則選 EMR Serverless）。
3. 多 TB 資料集 + 完整 Spark 調校、自訂 JAR，或多框架（Spark + HBase + Flink） → Amazon EMR on EC2。
4. PB 規模 + 團隊已在 Kubernetes 上 → Amazon EMR on EKS。
5. 1 GB 以下的小型一次性 API 驅動轉換 → Glue Python shell（最省錢）或 AWS Lambda。
6. 從 Kinesis／MSK 的連續串流轉換 → Glue streaming ETL 或 EMR Serverless Spark Streaming。

ETL 模式手冊 — 從來源到 Athena

考試期望你熟悉的 AWS 資料湖典型模式：

1. 擷取 — 資料從 Amazon Kinesis Data Firehose、AWS DMS、AWS DataSync 或直接上傳，落地到 Amazon S3 原始區（s3://lake/raw/...）。
2. 建立目錄 — AWS Glue Crawler 將原始資料登錄為 AWS Glue Data Catalog 中的資料表。
3. 轉換 — AWS Glue ETL 作業（或 Amazon EMR Spark）將原始 CSV／JSON 轉換為 Apache Parquet 並加上分區（例如 year=/month=/day=），寫入精煉區（s3://lake/curated/...）。
4. 重新建立目錄 — 在精煉區執行 Glue Crawler，以新的 Parquet 資料表更新 Catalog。
5. 查詢 — Amazon Athena 透過 SQL 讀取精煉 Parquet 資料表；Amazon Redshift Spectrum 將其與倉儲資料表 join。
6. 視覺化 — Amazon QuickSight 透過 Athena 或 Redshift 建立儀表板。
7. 編排 — AWS Step Functions 將第 1–5 步串接在一起，並加入錯誤處理。
8. 治理 — AWS Lake Formation 透過 Data Catalog 對上述所有資料執行列／欄／儲存格層級的存取控制。

Parquet 與分區為何重要

Amazon Athena 與 Amazon Redshift Spectrum 按掃描的 TB 數計費。從 CSV（列式）轉換為 Apache Parquet（欄式 + 壓縮）通常能減少 30–90% 的掃描位元組。分區進一步依日期、地區或租戶修剪掃描資料。「如何降低 Athena 成本」的 SAA-C03 正確答案幾乎都是轉換為 Parquet + 分區 + 壓縮——而 AWS Glue ETL 是完成這件事的標準工具。

必背關鍵數字

• Glue DPU — 1 DPU = 4 vCPU + 16 GB RAM + 64 GB 磁碟。Spark ETL 作業預設 10 DPU。
• Glue 定價 — 約 $0.44 每 DPU-hour（以秒計費）。Spark ETL 每次作業最低 1 分鐘；Crawler 與 DataBrew 作業最低 10 分鐘。
• Glue Python shell — 1/16 DPU 或 1 DPU。微型作業的最省 Glue 選項。
• Glue Data Catalog — 每個帳號每月前 100 萬個物件與 100 萬次請求免費。
• Glue Studio — 視覺化 ETL，產生 PySpark，定價與 Glue ETL 相同。
• Glue DataBrew — 250 個以上預建 recipe，互動式按 session 計費加上作業按節點-hour 計費。
• Glue Schema Registry — 免費，支援 Avro、JSON Schema、Protobuf。
• Glue job bookmarks — Enable／Disable／Pause 三種模式。
• EMR Master 節點 — 每個叢集 1 個（或 Multi-Master HA 為 3 個），固定使用 On-Demand。
• EMR Core 節點 — 儲存 HDFS、執行運算，建議使用 On-Demand 或 Reserved。
• EMR Task 節點 — 僅負責運算，可使用 Spot，最多省 90%。
• EMR 檔案系統 — HDFS（暫存）+ EMRFS（S3，持久）。
• EMR Serverless — 按 vCPU-second + 記憶體 GB-second + 儲存 GB-second 計費。
• Step Functions Standard — 最長 1 年、at-most-once、按狀態轉換計費。
• Step Functions Express — 最長 5 分鐘、at-least-once、按請求次數加持續時間計費。
• Glue triggers — Schedule、On-demand、Conditional（事件）三種。

常見考試陷阱

• AWS Glue vs Amazon EMR — 無伺服器且最小化運維 vs 完整 Spark／Hadoop 控制。題目出現「不需管理基礎架構」且「作業不頻繁」表示 AWS Glue。題目出現「客製 Spark 調校」、「HBase」、「Presto」或「PB 級持續叢集」表示 EMR。
• DataBrew vs Glue Studio vs 純 Glue ETL — DataBrew 是給分析師用的無程式碼 recipe；Glue Studio 是給工程師用的低程式碼視覺化 ETL；純 Glue ETL 是 PySpark 程式碼。
• EMR 節點類型的 Spot 策略 — Spot 只用於 Task 節點。Core 節點使用 Spot 有 HDFS 資料遺失風險；Master 節點使用 Spot 有整個叢集遺失風險。
• HDFS vs EMRFS — HDFS 是 Core 節點上的暫存儲存；EMRFS 是 Amazon S3 上的持久儲存。叢集終止後必須保留的輸出資料要寫到 EMRFS。
• AWS Glue Crawler — 考試期望你選擇排程 Crawler，而非手動撰寫 ALTER TABLE ADD PARTITION 腳本來處理持續到來的 S3 資料。
• Glue job bookmarks vs 重新處理 — bookmarks 啟用增量載入；Disable 只用於完整重新執行或除錯。
• Glue triggers vs Step Functions — Glue 條件 trigger 只處理簡單的純 Glue 鏈。只要涉及 Lambda、EMR、Athena、SNS 或含指數退避的重試，就應使用 Step Functions。
• EMR Serverless vs EMR on EC2 — Serverless = 無叢集、按作業計費、僅支援 Spark／Hive。EMR on EC2 = 完整 Hadoop 生態系、長期運行、手動擴縮。
• EMR on EKS — 只有在組織已在運行 EKS 時才相關。其他情況不要選它。
• Glue Schema Registry — 當情境強調「跨串流生產者與消費者強制執行 schema 相容性」時，Schema Registry 是正確答案。
• CSV 轉 Parquet — 「降低 Athena 成本」的典型答案，使用 AWS Glue ETL 完成。
• Python shell 作業 — 適合 1 GB 以下的小型 Python 任務；避免為微型工作啟動 Spark 叢集。

AWS Glue、EMR 與 Step Functions vs 相鄰主題

Glue ETL vs Kinesis Data Firehose 轉換

兩者都能轉換資料格式並寫入 Amazon S3。差異如下：

• Amazon Data Firehose — 近即時串流傳輸，內建格式轉換（JSON → Parquet／ORC）與基於 Lambda 的行內轉換。典型緩衝時間約 60 秒。
• AWS Glue streaming ETL — 完整 PySpark 串流引擎，支援任意轉換、視窗操作，以及與參考資料的 join。

若情境是「將 Kinesis 資料傳輸到 S3 並做簡單格式轉換」，選 Firehose。若需要複雜 join 或視窗聚合，選 Glue streaming ETL 或 EMR Serverless Spark Streaming。

Glue Data Catalog vs Lake Formation

Glue Data Catalog 是 metadata 儲存庫。AWS Lake Formation 建立在其上，新增細粒度存取控制（列、欄、儲存格）、集中稽核，以及簡化設定。Lake Formation 底層使用 Glue Data Catalog。當情境說「對跨分析師的資料湖資料表進行細粒度權限控制」，正確選擇是 Lake Formation。

Glue vs AWS Data Pipeline

AWS Data Pipeline 是舊式編排服務——新設計中應避免使用。現代替代方案是 AWS Step Functions（一般編排）與 Amazon Managed Workflows for Apache Airflow（MWAA）（基於 Airflow 的團隊）。

FAQ — AWS Glue ETL 與 EMR 資料轉換常見問題

1. SAA-C03 考試中，什麼時候應選 AWS Glue，什麼時候應選 Amazon EMR？

當情境強調無伺服器操作、中小型資料集、不頻繁或不可預測的執行、標準 PySpark 轉換，以及緊密的 Data Catalog 整合時，選 AWS Glue ETL。當情境需要客製 Spark 調校、完整 Hadoop 生態系（HBase、Hive、Presto、Flink）、超大資料集（數百 TB 到 PB 級）、長期互動式叢集，或透過 Task 節點 Spot Instance 最佳化成本時，選 Amazon EMR。速記規則：Glue 追求無伺服器簡單性，EMR 追求規模與客製化。對於需要完整 Spark 引擎控制但不想管叢集的短期爆發性 Spark 工作負載，Amazon EMR Serverless 是中間地帶。

2. AWS Glue Studio 與 AWS Glue DataBrew 有何不同？

AWS Glue Studio 是給資料工程師使用的視覺化低程式碼 ETL 管線建構器——你在畫布上拖拉來源-轉換-目標方塊，Glue Studio 產生可編輯的 PySpark 程式碼，並以 AWS Glue ETL 作業執行。AWS Glue DataBrew 是給資料分析師使用的純無程式碼資料準備工具——套用 250 個以上的預建 recipe（移除空值、遮蔽個資、重新格式化日期、分割欄位）而無需撰寫任何程式碼。Glue Studio 產生完整 ETL 管線；DataBrew 產生清洗後的資料集與剖析報告。SAA-C03 情境若點名「不撰寫程式碼的資料分析師」，對應到 DataBrew；若點名「想要視覺化 Spark 撰寫的工程師」，對應到 Glue Studio。

3. AWS Glue job bookmarks 如何運作？什麼時候應停用？

Job bookmarks 追蹤已處理的檔案（S3 使用路徑與修改時間）或資料列（JDBC 使用有序欄位）的狀態。下次執行時，AWS Glue 跳過已處理的資料，只轉換新記錄——實現增量 ETL 而不重複處理。生產增量載入設為 Enable；Pause 用於執行而不更新狀態（當你需要重新處理特定分區但不想遺失整體 bookmark 進度時很有用）；Disable 用於需要重新處理所有資料的完整重新執行。SAA-C03 情境詢問「高效率每日增量 ETL」時，正確答案是啟用 job bookmarks。

4. 為何 EMR Task 節點應使用 Spot Instance，但 Core 節點不應如此？

Task 節點是無狀態的——它們只執行 YARN NodeManager 與運算任務，沒有 HDFS 儲存。Spot 中斷回收 Task 節點時，YARN 將其任務重新排程到其他存活節點。Task 節點使用 Spot 可省下高達 90%，且風險極低。Core 節點執行 HDFS DataNode 並保存複寫的 HDFS 資料；多個 Core 節點同時被 Spot 回收（這是可能發生的）會導致 HDFS 資料遺失與叢集故障。Master 節點執行叢集協調器；在非 HA 叢集中遺失 Master 節點會摧毀整個叢集。生產 EMR 定價模式：Master 與 Core 使用 On-Demand 或 Reserved，Task 節點透過多樣化 Spot 容量的 Instance Fleet 使用 Spot。

5. EMR Serverless 與 EMR on EKS 有何不同？

Amazon EMR Serverless 完全移除叢集管理——你建立一個 Spark 或 Hive 應用程式，提交作業，AWS 自動佈建容量，按 vCPU-second 與記憶體 GB-second 計費。你完全看不到節點。最適合希望擁有 Spark 能力卻不需要任何運維的團隊。Amazon EMR on EKS 將 Spark 作業以 Pod 形式運行在你自行管理的現有 Amazon EKS 叢集上。最適合已以 Kubernetes 為標準的組織，希望將 Spark 工作負載整合進同一個 EKS 叢集與其他服務共用容量與可觀測性。SAA-C03 情境：「不需管理叢集」指向 EMR Serverless；「我們已在運行 EKS，希望統一 Kubernetes 控制平面」指向 EMR on EKS。

6. 應該用 AWS Step Functions 還是 AWS Glue triggers 來編排多步驟 ETL 管線？

只有當管線是純 Glue 作業的簡單線性鏈（Glue 作業 A 完成 → Glue 作業 B 啟動）時，才使用 AWS Glue 條件 trigger。只要管線涉及非 Glue 服務——AWS Lambda、Amazon EMR、Amazon Athena 查詢、SNS 通知、外部 HTTP API、審核關卡，或含指數退避的重試——就使用 AWS Step Functions。Step Functions 提供耐久狀態機、視覺工作流程圖、內建重試與捕捉、平行分支，以及針對 Glue StartJobRun、EMR AddStep、Athena StartQueryExecution 與 Lambda Invoke 的原生服務整合。在 SAA-C03 中，「編排複雜 ETL 工作流程」幾乎都指向 Step Functions。

7. 將 S3 中的 CSV 檔案轉換為 Apache Parquet 以供 Athena 使用，最省錢的方式是什麼？

SAA-C03 的標準模式是：AWS Glue ETL 作業（Spark、PySpark）從 S3 原始前綴讀取 CSV，重新分區並轉換為 Apache Parquet（使用 Snappy 壓縮），寫入 S3 精煉前綴。轉換前後使用 AWS Glue Crawler 在 Data Catalog 中登錄 schema。以適度的 DPU 數量（2–10 DPU）執行作業，並設定每小時或每日排程。對於非常小的資料集（1 GB 以下，簡單 schema），使用 Glue Python shell 作業搭配 pandas/pyarrow 在 1/16 DPU 執行可能更便宜。轉換後的 Parquet 檔案通常能降低 Athena 掃描成本 30–90%。除非資料集超過數 TB，否則 Amazon EMR 對這種模式而言是過度設計。

延伸閱讀

• AWS Glue Developer Guide — ETL、Data Catalog、Crawler。https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html
• AWS Glue Studio User Guide — 視覺化 ETL。https://docs.aws.amazon.com/glue/latest/ug/what-is-glue-studio.html
• AWS Glue DataBrew Developer Guide — 視覺化資料準備。https://docs.aws.amazon.com/databrew/latest/dg/what-is.html
• AWS Glue Schema Registry。https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html
• AWS Glue Job Bookmarks。https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html
• AWS Glue Pricing — DPU 模型。https://aws.amazon.com/glue/pricing/
• Amazon EMR Management Guide。https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-what-is-emr.html
• Amazon EMR Master、Core 與 Task 節點。https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html
• Amazon EMR Serverless User Guide。https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/what-is-emr-serverless.html
• Amazon EMR on EKS。https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks.html
• AWS Step Functions Developer Guide。https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html
• AWS Step Functions — Glue 整合。https://docs.aws.amazon.com/step-functions/latest/dg/connect-glue.html
• AWS Certified Solutions Architect Associate（SAA-C03）考試指南。https://d1.awsstatic.com/training-and-certification/docs-sa-associate/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf

摘要

AWS Glue ETL 與 Amazon EMR 共同涵蓋 SAA-C03 上所有資料轉換情境。AWS Glue 是無伺服器答案：Crawler 自動探索 schema、Glue Data Catalog 集中管理 Athena／Redshift Spectrum／EMR 的 metadata、Glue Studio 在 PySpark 之上提供視覺化 ETL、DataBrew 為分析師提供無程式碼 recipe、Schema Registry 強制串流 schema 相容性、job bookmarks 啟用增量載入，以及 trigger 或 Step Functions 編排執行——全部按 DPU-second 計費。Amazon EMR 是完整控制的答案，提供三種型態：EMR on EC2（Master + Core + Task 節點，Spot 只用於 Task 節點，HDFS 用於暫存而 EMRFS 在 S3 上提供持久儲存）、EMR Serverless（按作業計費的 Spark／Hive，無叢集）、EMR on EKS（在現有 Kubernetes 上以 Spark Pod 形式運行）。AWS Step Functions 將整條管線串接成具備重試與平行分支的耐久狀態機。掌握 Glue 與 EMR 的決策樹，記住 Spot 只屬於 Task 節點，並記住 Parquet 加分區是降低下游 Athena 查詢成本的典型答案。