具有 Spark 的 Amazon EMR 加上用於編排的 AWS Step Functions 是 AWS 上規範的大規模資料處理模式。在 DEA-C01 考試中，網域 3 的問題中大約每六題就有一題涉及 EMR Spark 和 Step Functions。考試將大多數 EMR 問題框架化為「我們需要以 Y 語義處理 X TB 的資料，使用 EMR、Glue 還是 Athena」 — 而正確答案幾乎總是取決於工作負載是否需要自定義 Spark 程式碼、叢集是否需要長期運行，以及成本模型是否允許按作業計費或需要預留容量。來自 Tutorials Dojo、Camille Chang 以及 VivekR 的 30 天路線圖的研究指南都指出了同一個缺口：考生知道 EMR 執行 Spark，但無法在考試情境下區分 EMR on EC2、EMR on EKS 和 EMR Serverless，也無法在成本情境下區分 Step Functions 與 MWAA。
本指南旨在將 EMR Spark 和 Step Functions 轉化為維運肌肉記憶。內容涵蓋了 EMR 的定義及其三種部署模型、包含主節點 (master)、核心節點 (core) 和任務節點 (task) 的叢集架構、執行個體機群 (instance fleets) 與執行個體群組 (instance groups) 的對比、具有動態資源分配的 Spark on EMR、用於 SQL 工作負載的 Hive on EMR、對 Iceberg/Hudi/Delta Lake 的支援、EMR 與 Glue 的選擇、Step Functions 狀態機、用於扇出並行的 Map 狀態、使用 Retry 和 Catch 進行錯誤處理、標準 (Standard) 對比快速 (Express) 工作流程，以及隱藏在情境題中的規範 EMR vs Glue 與 MWAA vs Step Functions 考試陷阱。
什麼是 Amazon EMR？
定義 — 具有 Spark 的 EMR 與 Step Functions 編排。 此 DEA-C01 主題涵蓋了特定領域的 AWS 服務或模式。在依賴第三方摘要之前，請從 AWS 官方文件確認規範定義 — 服務名稱和功能範圍隨時間有所變化。
Amazon EMR 是一個受管的大數據平台，可在 AWS 佈建的叢集上執行開源框架（Hadoop, Spark, Hive, HBase, Presto, Trino, Flink）。EMR 適用於資料工程師需要編寫自定義 Spark 程式碼（PySpark, Scala, Java）、對 PB 級資料集執行耗時數小時的作業，或者使用 AWS 未單獨提供受管服務之開源工具的工作負載類別。
三種部署模型
EMR 提供三種截然不同的部署模型。EMR on EC2 是最初的版本 — 安裝了 EMR 軟體堆疊的長期執行 EC2 執行個體叢集。EMR on EKS 在 Kubernetes 叢集 (EKS) 上執行相同的 Spark 工作負載，讓已標準化使用 Kubernetes 的團隊可以為 ML、微服務和資料處理共享同一個編排平面。EMR Serverless 是按作業計費的模型 — 提交 Spark 或 Hive 作業，AWS 在幕後佈建、執行並拆除運算資源，無需管理叢集。
何時 EMR 是正確的工具
當工作負載需要超出 AWS Glue 受管 ETL 支援範圍的自定義 Spark 程式碼時、當資料量大到 Spark 的分散式混排 (shuffle) 和分區變得至關重要時、當團隊使用 Spark 生態系統庫（具有自定義寫入路徑的 Delta Lake, Hudi, Iceberg；用於 Spark 內 ML 的 MLlib）時，或當需要 EMR 特定功能（如自定義 JAR 提交、Hadoop 生態系統整合或 HBase）時，EMR 是正確的。當同樣的作業可以在維運開銷更低的 Glue 上執行且團隊不需要 EMR 特定功能時，EMR 就是錯誤的工具。
EMR 對比 Glue
這是 DEA-C01 中最常測試的 EMR 界限。Glue 適用於具有相對簡單 Spark 邏輯、透過爬蟲進行結構描述發現、用於增量處理的作業書籤以及與 Glue 資料目錄整合的受管 ETL。EMR 則適用於自定義 Spark 程式碼，可完全控制執行環境、庫版本和叢集組態。成本方面：Glue 按 DPU 小時計費，每 DPU 秒的費率較高；EMR 按 EC2 執行個體小時（費率較低）加上 EMR 服務費計費。對於長期運行的重型工作負載，EMR 更便宜；對於週期性的輕量級 ETL，Glue 更便宜。
EMR 叢集架構
了解主節點/核心節點/任務節點的拆分以及執行個體組態，是回答考試中每個 EMR 成本和效能問題的關鍵。
主節點 (Master Node)
主節點執行叢集協調員服務 — YARN ResourceManager, HDFS NameNode, Spark Master。每個叢集恰好有一個主節點（啟用 HA 的叢集則有三個）。主節點是單一協調點，不執行任務工作。在非 HA 叢集上，主節點故障會終止叢集，因此對於長期運行的生產叢集，要麼啟用 HA，要麼接受故障後重啟的模式。
核心節點 (Core Nodes)
核心節點執行 YARN NodeManager 和 HDFS DataNode 服務 — 它們儲存 HDFS 資料並執行任務容器。在生產環境中，核心節點不能使用 Spot 執行個體，因為丟失核心節點會丟失其儲存的 HDFS 區塊（除非 EMR 組態為將 S3 用作儲存層，這是現代模式）。核心節點的數量根據 HDFS 儲存需求以及所需的基準運算能力來確定大小。
任務節點 (Task Nodes)
任務節點僅執行 YARN NodeManager — 它們執行任務容器但不儲存 HDFS 資料。丟失任務節點不會丟失資料，只會丟失進行中的任務（YARN 會重新排程這些任務）。這使得任務節點成為 Spot 執行個體的理想選擇，相對於按需 (On-Demand) 執行個體，通常可以節省 70% 到 90% 的成本。規範的生產模式：少量的核心節點機群以保證穩定性，大量的任務節點機群採用 Spot 以獲取彈性運算能力。
執行個體機群 (Instance Fleets) 對比 執行個體群組 (Instance Groups)
執行個體群組 (Instance Groups) 將每個節點群組定義為單一執行個體類型 — 例如，「核心：5x m5.4xlarge，任務：20x m5.4xlarge」。簡單但缺乏靈活性 — 如果 m5.4xlarge 的 Spot 容量不足，叢集就會等待。
執行個體機群 (Instance Fleets) 將每個節點群組定義為一組可接受的執行個體類型清單，並設定 EC2 單位的目標容量 — 例如，「任務：200 個 EC2 單位，分佈在 m5.4xlarge, m5.8xlarge, r5.4xlarge, c5.4xlarge，偏好 Spot」。EMR 會分配可用且最便宜的組合，如果 Spot 完全耗盡，則回退到按需模式。執行個體機群是 Spot 密集型叢集成本最佳化的推薦模式。
針對任務節點使用帶有 Spot 容量的執行個體機群，可為 EMR 上的彈性運算提供比按需模式節省 70% 到 90% 的成本。 核心節點應保持按需（或預留）模式，因為 Spot 中斷會導致 HDFS 資料丟失（除非叢集完全以後端 S3 為基礎）；任務節點是無狀態的，非常適合 Spot。執行個體機群模型允許 EMR 跨多種執行個體類型進行分配，以減少 Spot 容量耗盡的可能性 — 宣告「任務機群：跨六種執行個體類型的 200 個 EC2 單位」可為 EMR 提供足夠的靈活性，即使在某個執行個體系列受限時也能維持容量。配合 EMR 受管擴展，可根據 YARN 待處理容器數量調整任務節點數量。對於 DEA-C01 考試中關於 EMR 成本削減的情境，答案幾乎總是「透過執行個體機群將任務節點設為 Spot」，而不是「縮小叢集規模」。
EMR Serverless — 無需叢集管理
EMR Serverless 是一種完全消除叢集管理的部署模型。
工作原理
您建立一個 EMR Serverless 應用程式（限定於某個 Spark 或 Hive 執行階段版本的邏輯容器）並向其提交作業。AWS 在幕後為作業佈建背景運算能力、執行作業並按每秒使用的 vCPU 和記憶體計費。無需調整叢集大小、無需管理主節點、也無需佈建任務節點。
何時 EMR Serverless 是正確的
最適合長期運行叢集會閒置的零星工作負載。每晚執行 2 小時、其餘 22 小時無需求的 ETL 作業，在 EMR Serverless 上僅需支付這 2 小時的費用；而在 EMR on EC2 上，您要麼保持叢集運行（24 倍成本），要麼在每項作業中支付叢集啟動時間（10-15 分鐘）。EMR Serverless 也適用於叢集大小難以預測的分析師隨機 Spark 作業。
何時 EMR Serverless 是錯誤的
長期運行的串流應用程式需要 EMR on EC2 或 EMR on EKS — Serverless 是按作業計費的，不適用於持續性工作負載。需要 HDFS 或 HBase 的工作負載需要 EMR on EC2。極低延遲的互動式工作負載有時更偏向於「溫」叢集，而非 Serverless 的冷啟動。
計費模型權衡
Serverless 按分配容量的每秒支付費用，與 EMR on EC2 相比，每單位的費率略有溢價。損益平衡點取決於叢集利用率：如果叢集 24/7 以 40% 的利用率運行，Serverless 更便宜；如果利用率達到 80% 以上，則採用預留或 Spot 的 EMR on EC2 更便宜。
Spark On EMR
Spark 是迄今為止資料工程中最常用的 EMR 框架。
作業提交
spark-submit --deploy-mode cluster --num-executors 20 --executor-memory 16G --executor-cores 4 myjob.py 是規範的提交方式。EMR 也接受 EMR Steps（步驟是透過 EMR API 提交的一次性作業），這是 Step Functions 和其他編排器的整合點。
動態資源分配 (DRA)
DRA 允許 Spark 根據工作負載向上或向下擴展執行器 (executors)。閒置的執行器在超時後釋放，為同一叢集中的其他作業騰出資源。在共享叢集上執行多租戶 Spark 時這是必需的；在單作業叢集上則不那麼關鍵。
Spark UI 與歷史伺服器 (History Server)
執行中叢集的 Spark UI 會顯示即時作業進度；Spark 歷史伺服器（EMR 會將其封存到 S3）則提供已完成作業的分析。Spark UI 是對緩慢 Spark 作業進行除錯的主要工具 — 包含 DAG 視覺化、各階段持續時間以及執行器利用率。
Spark 組態調優
關鍵的 Spark 屬性：spark.sql.shuffle.partitions（預設 200，對於大數據通常太低）、spark.executor.memory 和 spark.executor.cores（根據執行個體類型確定大小）、spark.dynamicAllocation.enabled（DRA 開關）、spark.serializer=org.apache.spark.serializer.KryoSerializer（更快的序列化）。EMR 會套用合理的預設值，但生產環境的調優通常取決於具體工作負載。
Hive On EMR
Hive 是具有強大 S3 外部表支援的 SQL-on-Hadoop 層。
何時 Hive 是正確的
Hive 適用於 SQL 驅動的批次 ETL。雖然 Spark SQL 也能勝任，但若偏好 Hive 成熟的查詢最佳化器、分區處理和 HiveQL 語法，則選擇 Hive。EMR 上的 Hive 通常作為從本地部署 Hadoop 遷移過來的舊版 ETL 作業的 SQL 執行引擎。新工作負載通常會選擇 Spark SQL 或 Athena。
S3 上的外部表
CREATE EXTERNAL TABLE ... LOCATION 's3://bucket/path/' 讓 Hive 將 S3 前置詞視為資料表。Glue 資料目錄可以作為元儲存 (metastore)（取代 EMR 本地的 Hive 元儲存），這使得相同的資料表對 Athena、Spark 和其他引擎可見。
開放資料表格式 — Iceberg, Hudi, Delta Lake
EMR 透過原生執行階段整合支援這三種開放資料表格式。
Apache Iceberg
支援 ACID 交易、透過 FOR TIMESTAMP AS OF 進行時間旅行查詢、分區演進（不重寫資料即可更改分區）以及結構描述演進。EMR 上的 Iceberg 使用 Glue 資料目錄作為中繼資料存放區。Athena 引擎 v3 原生支援查詢 Iceberg 表。DEA-C01 考試指南明確列出 Iceberg 為考點。
Apache Hudi
針對寫入密集型工作負載（從 RDBMS 到資料湖的 CDC 管道）進行了最佳化。兩種資料表類型：寫入時複製 (Copy-on-Write, 更新時重寫資料檔案，讀取較快) 和讀取時合併 (Merge-on-Read, 記錄差異，寫入較快)。
Delta Lake
最初由 Databricks 開發，現已獲得廣泛支援。具有與 Iceberg 類似的 ACID 語義，但中繼資料佈局略有不同。在從 Databricks 遷移到 EMR 的團隊中很常見。
如何選擇
由於 Glue 資料目錄的整合和 Athena 的原生支援，Iceberg 是新的湖倉架構中 AWS 官方推薦的規範選擇。Hudi 是處理高頻更新 CDC 的正確答案。Delta Lake 則是已經投入 Delta 生態系統之團隊的正確答案。DEA-C01 考試雖然會提到這三者，但更強調 Iceberg。
什麼是 AWS Step Functions？
AWS Step Functions 是一個狀態機編排服務，用於將 AWS 服務呼叫串聯成一個協調的工作流程。
狀態機模型
工作流程是一個由 JSON 定義的狀態機：每個狀態可以是任務 (Task, 呼叫 AWS 服務或 Lambda)、選擇 (Choice, 根據條件分支)、等待 (Wait, 延遲)、平行 (Parallel, 並行執行狀態)、Map (為陣列中的每項執行一個狀態)、傳遞 (Pass, 直接通過) 或失敗/成功 (Fail/Succeed) 終端狀態。狀態之間的轉換是顯式的 — 一個狀態的輸出成為下一個狀態的輸入。
直接的 AWS 服務整合
Step Functions 與 200 多個 AWS 服務具備直接整合功能，包括 Glue (執行作業)、EMR (增加步驟、終止叢集)、Athena (執行查詢)、Lambda (呼叫)、Redshift Data API (執行 SQL 陳述式) 以及 S3 (讀寫物件)。直接整合跳過了 Lambda 膠水程式碼，降低了成本和複雜性。
標準對比快速工作流程
標準 (Standard) 工作流程 支援長達 1 年的執行時間、恰好一次 (exactly-once) 的執行語義、完整的執行歷史記錄保留，並按狀態轉換次數計費。最適合長時間運行的資料管道。
快速 (Express) 工作流程 支援最多 5 分鐘的持續時間、至少一次 (at-least-once) 的語義，並按執行次數加每毫秒執行時間計費。最適合高容量、短時間的工作流程，如 API 請求處理。
對於資料工程管道，標準工作流程幾乎總是正確的，因為管道執行通常需要數分鐘到數小時。
Step Functions Map 狀態 — 扇出並行
Map 狀態為輸入陣列中的每個項目執行一個子工作流程 — 這是規範的扇出 (fan-out) 模式。
內嵌 Map (Inline Map) 對比 分佈式 Map (Distributed Map)
內嵌 Map 支援多達 40 個並發反覆運算，且支援高達 256 KB 的狀態大小。足以應付小規模的扇出（並行處理幾百個檔案）。
分佈式 Map 支援多達 10,000 個並發反覆運算，並且透過從 S3 讀取輸入陣列來支援數百萬個項目。這是處理大型 S3 前置詞中的每個檔案或大型資料集中每一行的正確答案。
常見使用案例
並行處理每個 Glue 資料表、為大型資料集的每個分區執行 Glue 作業、對存放在 S3 擷取區中的每個檔案進行轉換。分佈式 Map 狀態從根本上將 Step Functions 從「線性編排器」轉變為資料工程使用案例中的「真正並行執行器」。
錯誤處理 — Retry 與 Catch
生產環境中的資料管道經常會以暫時性的方式失敗；Step Functions 的錯誤處理是保持其彈性的紀律。
重試 (Retry) 組態
每個任務 (Task) 狀態都可以宣告 Retry 區塊，包含錯誤類型、最大嘗試次數、間隔秒數和退避率 (backoff rate)。一個典型的 Glue 作業重試：Retry: [{ErrorEquals: ['Glue.AWSGlueException'], MaxAttempts: 3, IntervalSeconds: 30, BackoffRate: 2.0}] 會以指數退避方式重試最多 3 次。
Catch 區塊
Catch 將特定錯誤路由到備用狀態 — 通常是通知狀態、補償狀態或優雅失敗狀態。Catch: [{ErrorEquals: ['States.ALL'], Next: 'NotifyOps'}] 將任何未捕獲的錯誤路由到 SNS 通知。
活動 (Activity) 與 回呼 (Callback) 模式
活動狀態會等待外部工作者認領並完成任務 — 適用於人工審批步驟或外部系統協調。回呼模式允許 Lambda 或 Glue 作業透過 SDK 向 Step Functions 發出完成信號，使長時間運行的任務能夠適應狀態轉換模型。
在生產環境的資料管道中，務必在每個任務 (Task) 狀態上宣告 Retry 區塊，並組態指數退避。 AWS 服務節流、暫時性網路錯誤和短暫的運算失敗在生產中司空見慣；如果沒有 Retry 區塊，每一次暫時性故障都會變成管道故障並喚醒維運人員。推薦基準：3 次嘗試、30 秒初始間隔以及 2.0 的退避率。結合 Catch 區塊將最終失敗路由到 SNS 通知或 CloudWatch 警報。Step Functions 中 Retry 區塊的成本是按狀態轉換計算的（幾微美分）；而因缺失重試導致的管道失敗成本則是真實且巨大的。對於 DEA-C01 考試中關於彈性管道的情境，答案是 Retry 加上 Catch，而不是外部監控。
Step Functions vs MWAA vs EventBridge
三種編排工具涵蓋了資料工程工作流程空間的不同部分。DEA-C01 考試會反覆測試此決策。
Step Functions
最適用於：具有分支、錯誤處理、平行扇出和直接 AWS 服務整合的狀態機風格管道。定價：按狀態轉換次數計費（每次執行幾美分）。閒置時無基準成本。編寫方式：JSON 或 AWS Workflow Studio 視覺化編輯器。
Amazon MWAA (受管 Apache Airflow)
最適用於：具有廣泛開源生態系統（針對數百種服務的 Airflow 運算子）、基於 Python 的管道定義、大型現有 Airflow 程式碼庫的複雜 DAG 管道。定價：按環境每小時計費，且具有基準執行成本（環境持續運行）。編寫方式：Python DAG 檔案。
EventBridge Scheduler
最適用於：排程觸發 Lambda、Step Functions、Glue、ECS 任務。取代了舊有的 EventBridge Rules cron 風格排程和 CloudWatch Events。定價：按呼叫次數計費。最適合觸發層，而非編排層本身。
決策規則
如果團隊擁有現有的 Airflow DAG 或強烈偏好使用 Python 定義管道，選擇 MWAA。如果工作流程是狀態機形狀的（具有分支和並行性的序列步驟），選擇 Step Functions。對於啟動這兩者的排程觸發器，選擇 EventBridge Scheduler。成本陷阱：MWAA 具有持續的基準運行成本（每月最低約 300 美元），這對稀疏的管道影響很大；Step Functions 的閒置成本為零。DEA-C01 考試將此設為「團隊每天執行一個管道，什麼最具成本效益」 — 答案是 Step Functions 加上 EventBridge Scheduler。
MWAA 即使在沒有 DAG 執行時也有持續的基準運行成本，這使得它對於稀疏的資料管道工作負載來說非常昂貴，在這種情況下，Step Functions 加上 EventBridge Scheduler 會便宜得多。 每天執行 1 個管道的團隊使用 MWAA 環境可能需要支付 300 美元/月，而等效的 Step Functions 加上 EventBridge 設定僅需 1-5 美元/月。只有當 DAG 複雜度、基於 Python 的管道定義或現有的 Airflow 程式碼超過成本考量時，MWAA 才是正確答案；對於典型工作流程，Step Functions 在成本上勝出。DEA-C01 考試將此設為「團隊有一個每晚執行的單一批次管道且編排需求有限，推薦一項服務」 — MWAA 是陷阱；Step Functions 是答案。
白話文解釋 EMR Spark 與 Step Functions
三個具體的類比使 EMR 的部署模型和 Step Functions 的編排變得直觀。
類比 1 — 三種僱傭模式的建築工地
想像一家建造自定義房屋（Spark 作業）的建築公司。該公司有三種僱傭模式。EMR on EC2 是按長期合約僱傭一支永久的建築工人團隊（主節點、核心節點、任務節點） — 無論是否有活幹，工人們每天都會出現，工頭（主節點）負責協調每日的施工。EMR on EKS 是與公司的其他部門（用於 ML、微服務、批次的 Kubernetes）共享一個工人群組 — 工人來自一個池，被派遣到今天需要他們的任何部門。EMR Serverless 是每當需要蓋房子時就打電話給人力派遣公司 — 工人到達、完成專案、離開，公司僅支付工作小時的費用。任務節點上的 Spot 執行個體就像臨時工 — 較便宜，但如果臨時工在中途找到了更好的差事走掉了，工頭只需再叫一個。執行個體機群就像是在說「我總共需要 200 個工時，我不在乎他們是木工、電工還是普通勞工，今天什麼最便宜就送什麼過來」。Step Functions 是工頭隨身攜帶的專案計畫書 — 一份包含「如果框架搭建失敗三次，呼叫建築師，否則繼續鋪設屋頂，與水電安裝並行」的逐步排程。MWAA 則是僱傭一名全職專案經理，他每天都出現來協調那份計畫書，無論當天是否有專案都要付薪水。DEA-C01 的成本問題在於，你是否有足夠多的專案來支撐那名全職經理 (MWAA)，還是帶著計畫書的工頭 (Step Functions) 就足夠了。
類比 2 — 餐廳廚房與食譜協調員
想像一個擴展到工業規模的餐廳廚房。二廚們（Spark 執行器）需要一個廚房（EMR 叢集）來工作。有些餐廳 24/7 擁有自己的廚房 (EMR on EC2) — 固定成本高，但廚房每分鐘都預熱就緒。有些餐廳與其他企業共享一個共享廚房 (EMR on EKS) — 為你使用的位置付費。有些餐廳僅在訂單進來時才租用廚房空間 (EMR Serverless) — 閒置成本為零，但每班次前需要幾分鐘的預熱。值班的主廚（主節點）負責協調二廚（核心和任務節點）；核心二廚將食材儲存在冷凍庫 (HDFS) 中，任務二廚僅執行訂單。Iceberg、Hudi 和 Delta Lake 是不同的食譜系統，用於追蹤食譜隨時間的變化 — Iceberg 是 AWS 認可的標準，Hudi 適用於快速變化的食譜 (CDC)，Delta Lake 適用於從 Databricks 起家的餐廳。Step Functions 是訂單協調員，他閱讀「先做前菜，然後是主菜，最後是甜點；如果前菜失敗三次呼叫經理；並行製作主菜和配菜」 — 一個確定性的狀態機在廚房中分發訂單。Map 狀態是為桌上的每位顧客複製同一份訂單給每位廚師。MWAA 則是僱傭一名 Airflow DAG 協調員，他擅長處理流程但即使在淡季也收取日薪；Step Functions 則是按訂單計費。
類比 3 — 具備分揀機和工作流軟體的郵政分揀設施
EMR 是分揀設施本身 — 成排的物理處理包裹的分揀機。EMR on EC2 是 24/7 擁有設施並配備全體員工。EMR on EKS 是在多租戶物流中心租用空間。EMR Serverless 是按分揀的包裹數量向第三方物流公司付費。主節點是檢查每日計畫的監督員；核心節點是帶有包裹儲存空間的分揀機；任務節點是隨時可以離開 (Spot 執行個體) 且不會丟失庫存的臨時分揀機。Spark 是機器上運行的分揀程式；Hive 是 SQL 驅動的標籤列印程式；Iceberg 是支援時間點查詢（昨天中午的庫存是多少）的倉庫清單系統。Step Functions 是在樓上辦公室運行的工作流軟體 — 「早上 8 點接收卡車，運行分揀程式，產生標籤，下午 5 點派遣卡車；如果分揀程式失敗 3 次，警報經理」。Map 狀態是「對於今天進貨清單中的每輛卡車，並行執行相同的分揀工作流」。標準工作流程處理長達 1 年的運輸；快速工作流程處理 5 分鐘的 API 請求處理。MWAA 就像聘請一名全職工作流顧問；Step Functions 則是按工作流事件付費。EventBridge Scheduler 是辦公室時鐘，定時觸發「早上 8 點，啟動每日工作流」。DEA-C01 考試會問：讀取包裹量和頻率，選擇正確的部署模型，然後選擇正確的編排器。
EMR 與 Step Functions 的常見考試陷阱
DEA-C01 考試設置了一套穩定的陷阱。請記住這五個。
陷阱 1 — 需要 EMR 時卻選擇 Glue
情境描述了具有非平凡庫和巨量資料量的自定義 Spark 程式碼。錯誤答案：Glue（因為「受管 ETL」聽起來更容易）。正確答案：EMR。Glue 最適合相對標準的 ETL；複雜的 Spark 應放在 EMR 上。
陷阱 2 — 在 Spot 上執行核心節點
考生為了節省成本將所有節點都移至 Spot。錯誤 — 丟失核心節點會丟失 HDFS 資料。任務節點設為 Spot，核心節點設為按需或預留。
陷阱 3 — 為稀疏工作流程選擇 MWAA
情境中有一個每晚執行的管道。MWAA 的基準成本使其成為錯誤選項；Step Functions 加上 EventBridge Scheduler 才是正確的。
陷阱 4 — 為長管道選擇快速工作流程
考生為了成本選擇快速 (Express) 模式。錯誤 — 快速模式有 5 分鐘的限制。長管道必須使用標準 (Standard) 模式。
陷阱 5 — 為大型扇出選擇內嵌 Map
情境需要扇出到 10,000 個項目並選擇了內嵌 Map (Inline Map)。錯誤 — 內嵌 Map 最高僅支援 40 個並發。分佈式 Map 則可處理高達 10,000 個。
EMR 用於自定義 Spark 和大數據；Glue 用於邏輯較簡單的受管 ETL。EMR Serverless 用於零星作業，EMR on EC2 用於穩態工作負載。任務節點設為 Spot，核心節點設為按需。Step Functions 標準工作流程用於資料管道（1 年時長）；快速工作流程用於高容量短工作流（5 分鐘上限）。超過 40 個項目的扇出使用分佈式 Map。MWAA 用於成本較高的高級 Python DAG；Step Functions 用於按狀態轉換計費的狀態機管道。 這是每個 DEA-C01 關於 EMR 加 Step Functions 問題需要記住的一段話。反覆出現的考試模式是在成本、規模和複雜度約束下選擇服務組合；正確答案幾乎總是那個能最小化閒置成本且符合工作流形狀的選項。
關鍵數字與必須記住的 EMR 與 Step Functions 事實
EMR 部署模型
- EMR on EC2：長期運行叢集，完全控制
- EMR on EKS：共享 Kubernetes 池
- EMR Serverless：按作業計費，無需叢集
EMR 叢集架構
- 主節點 (Master)：1 個（或 3 個供 HA），僅負責協調
- 核心節點 (Core)：儲存 HDFS，按需或預留
- 任務節點 (Task)：無狀態，Spot 的理想選擇（節省 70-90%）
- 跨多種執行個體類型的執行個體機群以增強彈性
EMR 上的開放資料表格式
- Iceberg：AWS 推薦，與 Glue 目錄整合，Athena 原生支援
- Hudi：針對更新插入 (upsert) 最佳化，對 CDC 友好
- Delta Lake：源自 Databricks，廣泛支援
Step Functions 工作流程類型
- 標準 (Standard)：長達 1 年，恰好一次，按轉換計費
- 快速 (Express)：最多 5 分鐘，至少一次，按執行次數加執行時間計費
Step Functions 狀態類型
- Task (任務), Choice (選擇), Wait (等待), Parallel (平行), Map, Pass (傳遞), Fail (失敗), Succeed (成功)
- 內嵌 Map：最多 40 個並發
- 分佈式 Map：最多 10,000 個並發
編排成本模型
- Step Functions：按狀態轉換計費，零閒置成本
- MWAA：按環境每小時計費，基準成本約 300 美元/月
- EventBridge Scheduler：按呼叫次數計費的觸發器
DEA-C01 考試優先事項 — 具有 Spark 的 EMR 與 Step Functions 編排。 此主題在 DEA-C01 考試中佔有很大權重。掌握每種 AWS 服務公開的權衡、決策邊界以及成本/效能觸發因素 — 考試將測試那些取決於了解哪種服務是錯誤答案的情境，而不僅僅是哪種是正確答案。
FAQ — EMR Spark 與 Step Functions 常見問題
Q1 — 我該在什麼時候使用 EMR on EC2 而非 EMR Serverless？
對於叢集持續或接近持續運行且叢集利用率很高（60% 以上）的穩態工作負載，請使用 EMR on EC2。EC2 上的預留執行個體或節省計畫定價加上任務節點的 Spot，可以在高利用率下提供最低的每 DPU 小時成本。當工作負載稀疏且叢集大部分時間處於閒置狀態時、對於叢集大小難以預測的隨機 Spark 作業，以及希望實現零叢集管理開銷的團隊，請使用 EMR Serverless。損益平衡點大約在 40% 的利用率 — 低於此值 EMR Serverless 在總成本上勝出；高於此值則 EMR on EC2 勝出。EMR on EKS 介於兩者之間，非常適合已經標準化使用 Kubernetes 並希望在資料、ML 和微服務工作負載之間共享叢集池的組織。
Q2 — 如何為 ETL 工作負載在 EMR Spark 和 AWS Glue 之間做決定？
對於具備受管爬蟲、用於增量處理的作業書籤、Glue 資料目錄整合以及符合 Glue 執行階段之 PySpark 程式碼的相對標準 ETL，請使用 Glue。對於具有非標準庫的自定義 Spark 程式碼、能從叢集級別最佳化中受益的大數據量、Hive 或 HBase 需求，或者 Glue 未公開的開源生態系統功能，請使用 EMR。成本方面：Glue 按每 DPU 小時較高費率計費但無叢集管理開銷；EMR 按 EC2 每小時較低費率計費但需要調整叢集大小和維運關照。對於週期性的輕量級 ETL，Glue 勝出。對於長期運行的重型工作負載，帶有 Spot 任務節點的 EMR 勝出。DEA-C01 考試會根據工作負載特性提供情境，並要求選擇正確的服務。
Q3 — 為什麼在 EMR 任務節點上使用 Spot 執行個體，而在核心節點上不使用？
核心節點儲存 HDFS 區塊；丟失核心節點會導致其儲存的資料丟失，除非叢集已組態為將 S3 用作儲存層（現代的 EMRFS 模式，其中 HDFS 基本未被使用）。在一個使用 HDFS 的叢集上，核心節點的 Spot 中斷會損壞叢集。任務節點則是無狀態的 — 它們執行 YARN 容器但不儲存任何持久性資料。丟失任務節點僅會丟失進行中的任務工作，YARN 會在存活的節點上重新排程這些工作。這就是為什麼生產模式是將核心節點放在按需（或預留執行個體以降低成本）上，而任務節點則透過執行個體機群放在 Spot 上。任務節點上的 Spot 節省通常相對於按需模式可達 70% 到 90%，且適用於叢集的大部分。
Q4 — 我該什麼時候使用 Step Functions 的標準對比快速工作流程？
對於執行時間為數分鐘到數小時且需要恰好一次執行語義的資料工程管道（Glue 作業、EMR 步驟、多階段 ETL、週期性批次處理），請使用標準 (Standard) 模式。標準模式支援長達 1 年的持續時間，保留完整的執行歷史以供稽核，並按狀態轉換次數計費。對於高容量、短時間的工作流程（如 API 請求編排、IoT 事件處理或微服務協調），請使用快速 (Express) 模式 — 快速模式每次執行上限為 5 分鐘，支援至少一次語義，並按執行次數加每毫秒執行時間計費。對於 DEA-C01 資料管道情境，標準模式幾乎總是正確的，因為管道會超過快速模式的限制且需要恰好一次。陷阱：考生為了節省成本選擇快速模式而未檢查時長上限。
Q5 — 我該如何在 Step Functions、MWAA 和 EventBridge Scheduler 之間做出選擇？
Step Functions 是針對具有分支、並行性、錯誤處理和直接服務整合的 AWS 原生管道的狀態機編排選擇。MWAA (受管 Apache Airflow) 則是當團隊擁有現有的 Airflow DAG、偏好使用 Python 定義管道，或者需要廣泛的 Airflow 運算子生態系統時的正確選擇。EventBridge Scheduler 是觸發層 — 它排程呼叫 Step Functions、MWAA DAG、Lambda、Glue 或 ECS 任務，但本身不負責編排狀態機。成本規則：MWAA 具有持續的基準成本（最小環境約 300 美元/月），這對稀疏的工作負載來說很昂貴；Step Functions 的閒置成本為零。對於單個每晚運行的管道，Step Functions 加上 EventBridge Scheduler 比 MWAA 便宜得多。對於數十個具備分支的複雜 DAG，MWAA 的生產力優勢可能抵消其成本。
Q6 — 我該如何在 Step Functions 資料管道中處理錯誤和重試？
在每個任務 (Task) 狀態上宣告具有合理預設值的 Retry 區塊 — 通常為 3 次嘗試、30 秒初始間隔、2.0 的指數退避率。將 Retry 與 Catch 區塊配合使用，後者將未捕獲的錯誤路由到通知狀態（發佈到 SNS 以觸發運維告警）或補償狀態（清理部分完成的工作）。對於等冪的 Glue 或 EMR 作業，Retry 是安全的；對於非等冪操作（如沒有等冪令牌的 INSERT 陳述式），Retry 必須與去重邏輯配合使用以避免重複處理。Retry 加上 Catch 模式將暫時性失敗（AWS 服務節流、短暫執行個體失敗）轉化為成功完成，並將需要人工處理的失敗留給真正的生產問題。對於 DEA-C01 關於彈性管道的情境，Retry 加上 Catch 就是答案。
Q7 — Step Functions 中的分佈式 Map 狀態何時適用？
當扇出超過內嵌 Map (Inline Map) 的 40 個並發限制，或者當輸入陣列超過 256 KB 時，請使用分佈式 Map (Distributed Map)。分佈式 Map 從 S3 讀取輸入（JSON, JSONL, CSV 檔案或 S3 金鑰清單），並執行多達 10,000 個子工作流程的並發反覆運算。規範使用案例：處理大型 S3 前置詞中的每個檔案、為數千個分區資料表的每個分區執行 Glue 作業、轉換大型資料集的每一行。內嵌 Map 對於輸入能適應狀態大小的小型扇出（幾十個項目）仍然是正確的。DEA-C01 考試會透過並行處理數千個檔案的情境來測試這一點 — 分佈式 Map 就是答案。
延伸閱讀 — EMR 與 Step Functions 官方 AWS 文件
權威的 AWS 來源包括 Amazon EMR 管理指南（部署模型、叢集調整大小、執行個體機群）、EMR 版本指南（Spark, Hive, Iceberg, Hudi, Delta Lake 組態）、Step Functions 開發人員指南（狀態類型、錯誤處理、標準對比快速模式）以及分佈式 Map 狀態文件。AWS 大數據部落格有多篇關於 EMR Spot 模式、EMR 上的 Iceberg 以及 Step Functions 資料管道模式的深度探討文章。AWS Well-Architected Data Analytics Lens 涵蓋了資料處理和編排階段中的 EMR 和 Step Functions。AWS Samples GitHub 存儲庫包含了結合 EMR, Step Functions, Glue 和 Athena 的端到端管道範例。最後，Skill Builder DEA-C01 Exam Prep Standard Course 有專門針對 EMR 和編排的模組，以情境形式講解了規範的考試陷阱。