資料品質是每個從原型跨越到生產環境的資料管道的隱形殺手。在 DEA-C01 考試中，網域 3 任務 3.4 的情境題中，大約每 12 題就有一題測試考生是否知道如何將自動化品質檢查嵌入到 Glue ETL 工作流程中。陷阱很少關於品質是否重要 — 陷阱在於為工作選擇正確的 AWS 工具。Glue DataBrew、Glue 資料品質 (Glue Data Quality)、自定義 Glue ETL 斷言以及 EMR 上的 Deequ 都有功能重疊，如果考生在正確答案應為 Glue 資料品質時選擇了 DataBrew（或反之亦然），其錯誤性質與在正確答案應為 Redshift Spectrum 時選擇了 Athena 是一樣的。
本指南從資料工程師與 MLOps 的視角深入探討 AWS 上的資料品質 — 哪些資料品質維度至關重要、何時使用 Glue DataBrew 與 Glue 資料品質、如何編寫 DQDL (資料品質定義語言) 規則、如何將 DQ 檢查連線到具有「快速失敗 (fail-fast)」或「警告並繼續 (warn-and-continue)」模式的 ETL 管道、如何將 DQ 指標發佈到 CloudWatch，以及圍繞 DataBrew 與資料品質、自動化規則建議和資料合約強制執行的規範考試陷阱。
資料品質維度 — 六大標準檢查
在選擇工具之前，請先定義品質的含義。行業標準的六個維度直接體現在 DQDL 規則類型中。
完整性 (Completeness)
欄位中非 Null 值的比例。一個有 5% 為 NULL 的 customer_email 欄位的完整性為 95%。DQDL 規則：Completeness "customer_email" > 0.95。DEA-C01 考試中，這被設為最常見的品質維度，因為不完整的資料會靜默地破壞下游的聯結和聚合。
準確性 (Accuracy)
值與真實情況相符的比例 — 通常表示為自定義謂詞或針對已知良好來源的參照檢查。DQDL 規則：ColumnValues "country_code" in ["US","CA","UK","DE","JP"]。準確性最難衡量，因為它需要基準事實 (ground truth)。
一致性 (Consistency)
滿足跨欄位或跨表關係的值比例。DQDL 規則：ColumnCorrelation "order_total" "line_items_sum" > 0.99。如果 order_total 不等於 sum(line_items)，則該列是不一致的。
及時性 (Timeliness)
資料的新鮮度 — 最新記錄過時了多久？DQDL 規則：(now() - max("event_timestamp")) < 1 day。DEA-C01 考試將此設為管道監控情境，當擷取停滯時 DQ 規則會觸發。
唯一性 (Uniqueness)
沒有重複值的比例。DQDL 規則：Uniqueness "order_id" > 0.99。對於重複項會損壞聯結的主鍵欄位至關重要。
有效性 (Validity)
符合格式或模式的值比例。DQDL 規則：ColumnValues "email" matches ".*@.*\\..*"。與準確性不同 — 語法有效的電子郵件仍可能是錯誤的。
AWS Glue DataBrew — 視覺化資料剖析與準備
Glue DataBrew 是一個無程式碼的視覺化環境，用於在資料進入生產管道之前對資料集進行探索、剖析和清理。
DataBrew 的功能
DataBrew 將資料集樣本（來自 S3, Redshift, RDS, Snowflake, Glue 資料目錄或 JDBC）載入到類似電子試算表的視覺化網格中。分析師和資料工程師可以互動式地進行排序、過濾、轉換和檢查欄位統計資訊。在後台，DataBrew 將視覺化操作編譯成「方案 (recipe)」— 一個 JSON 格式的轉換步驟文件 — 可以透過 DataBrew 方案作業 (recipe job) 在大規模資料上重播。
剖析作業 (Profile Jobs)
DataBrew 剖析作業針對完整的資料集（不只是樣本）執行，並產生一份剖析報告：欄位類型、Null 計數、唯一值計數、最小值/最大值/中位數、值分佈以及欄位間的相關性。剖析作業在底層作為 Glue Spark 作業執行，並按節點小時 (node-hour) 計費。剖析報告儲存在 S3 中，可從 DataBrew 主控台引用。
方案作業 (Recipe Jobs)
DataBrew 方案作業將方案（分析師定義的視覺化轉換）套用於完整資料集，並將結果寫入 S3、Redshift 或其他目標。方案可以重新命名欄位、過濾資料列、取代值、套用正則表達式提取、填補 Null 值、根據公式衍生新欄位以及對敏感欄位進行 PII 遮罩。方案作業是從互動式分析工作開始的轉換在生產環境中的執行路徑。
何時 DataBrew 是正確的
當團隊有需要不寫程式碼即可清理資料的分析師或領域專家時、當轉換邏輯是視覺化且探索性的時，以及當需要在設計管道之前透過剖析來發現品質問題時，DataBrew 是正確答案。它是「我需要了解這 100 欄 CSV 中的內容並產生一個清理後的版本」阻力最小的路徑。
何時 DataBrew 是錯誤的
對於每執行一次都需要相同檢查且無人參與的生產管道、對於透過程式碼級最佳化更能發揮效益的極大型資料集，或對於串流資料品質（DataBrew 僅限批次），DataBrew 是錯誤的。DEA-C01 的陷阱：對於每個品質情境都預設選擇 DataBrew 的考生會忽略 Glue 資料品質才是生產管道的正確答案。
Glue DataBrew 是一款專為分析師設計的視覺化無程式碼資料準備工具，可針對 S3、Redshift 和其他來源中的資料集產生剖析報告並套用轉換方案 — 旨在進行探索性清理和剖析，而非用於管道內的品質強制執行。 DataBrew 內建 250 多種轉換，包括 PII 處理、格式轉換、值取代和統計推算。剖析作業呈現欄位統計資訊；方案作業大規模套用轉換。當 DEA-C01 情境強調「無程式碼」、「視覺化」、「分析師驅動」或「管道設計前的資料剖析」時，DataBrew 是正確答案。當情境描述「具有嵌入式品質檢查的生產 ETL 管道」時，則應選擇 Glue 資料品質。
AWS Glue 資料品質 — 管道中的規則
Glue 資料品質 (Glue Data Quality) 是直接整合到 Glue ETL 作業和 Glue 資料目錄中的基於規則的品質評估框架。
Glue 資料品質的功能
Glue 資料品質允許您定義「規則集 (ruleset)」— 一組以 DQDL 表示的 DQ 規則 — 並針對資料集進行評估，既可以作為獨立任務，也可以作為 Glue ETL 作業中的一個步驟。評估結果是每條規則的通過/失敗分數以及總分，這些分數會顯示在 Glue 主控台中、寫入 CloudWatch 指標，並作為事件發出，供下游系統反應。
DQDL — 資料品質定義語言
DQDL 是用於指定規則的宣告式語言。一個規則集看起來如下：
Rules = [
RowCount > 1000,
Completeness "customer_email" > 0.95,
Uniqueness "order_id" > 0.99,
ColumnValues "country_code" in ["US","CA","UK","DE","JP"],
ColumnCorrelation "order_total" "line_items_sum" > 0.99,
CustomSql "SELECT COUNT(*) FROM primary WHERE total < 0" = 0
]
DQDL 易於人類閱讀，可在 Git 中進行版本控制，並受 Glue Studio 視覺化規則建置器的支援，方便偏好 UI 的分析師使用。
內建規則類型
DEA-C01 考試要求熟悉規則類型的名稱：RowCount, Completeness, Uniqueness, IsComplete, IsUnique, ColumnCount, ColumnExists, ColumnDataType, ColumnValues, ColumnLength, ColumnCorrelation, DataFreshness, DistinctValuesCount, Sum, Mean, StandardDeviation, Entropy, CustomSql, ReferentialIntegrity, DatasetMatch。請記住最常見的八種：RowCount, Completeness, Uniqueness, ColumnValues, ColumnCorrelation, DataFreshness, CustomSql, ReferentialIntegrity。
規則建議 (Rule Recommendations)
Glue 資料品質可以分析資料集樣本並自動建議規則 — 例如根據觀察到的 Null 率設定欄位完整性閾值、根據觀察到的重複項設定唯一性閾值、根據觀察到的分佈設定值範圍約束。考試將此作為對「團隊在新資料表中有 200 個欄位，需要一個無需手動編寫的初始規則集」的回答。使用建議功能進行引導，然後再進行精煉。
與 Glue ETL 作業整合
Glue ETL 作業可以包含一個 EvaluateDataQuality 轉換，在管道中途執行規則集。失敗的規則可以組態為使作業失敗（快速失敗模式）或在繼續執行的同時發出警告（警告並繼續模式）。失敗的資料列可以使用 outcomes 和 rowLevelOutcomes 輸出路由到隔離的 S3 前置詞中。
與 Glue 資料目錄整合
規則集可以附加到 Glue 資料目錄表，為目錄提供一個在主控台中呈現的「品質分數」。Athena 和下游取用者可以查看他們即將查詢的資料表的新鮮度和品質狀態。
Glue 資料品質是基於規則的管道內品質框架 — 由 Glue ETL 作業評估 DQDL 規則集，這些作業會執行快速失敗、隔離錯誤行或發佈 CloudWatch 指標進行監控。 DEA-C01 考試將 Glue 資料品質設為以下情境的正確答案：「具有自動化品質強制執行的生產 ETL」、「在載入精選區前嵌入品質檢查」、「將品質指標發佈到 CloudWatch」以及「阻止錯誤資料到達下游」。DataBrew 負責剖析和準備；Glue 資料品質負責強制執行。兩者相輔相成 — DataBrew 用於管道設計期間，Glue 資料品質用於管道執行期間。陷阱：在自動化生產管道情境中選擇 DataBrew，或在 DQDL 規則足以應付的情境中選擇自定義 Spark 程式碼。
DQDL 模式 — 在現實世界中編寫規則
DQDL 是考試中可能以程式碼辨識風格出現的語法。
模式 1 — 結構描述與結構規則
RowCount > 1000
ColumnCount = 25
ColumnExists "customer_id"
ColumnDataType "order_total" = "Double"
這些是捕捉上游結構描述漂移 (schema drift) 的結構斷言。DEA-C01 考試將結構描述漂移設為常見的 Glue 爬蟲陷阱 — DQDL 可防止管道在發生非預期結構描述更改後繼續執行。
模式 2 — 完整性與唯一性
Completeness "customer_email" > 0.95
IsComplete "order_id"
Uniqueness "order_id" > 0.99
IsUnique "transaction_id"
IsComplete 是 Completeness > 1.0 (必須為 100%) 的簡寫，IsUnique 是 Uniqueness = 1.0 的簡寫。對主鍵類型的欄位使用嚴格變體，對具備容錯能力的規則使用百分比變體。
模式 3 — 值約束
ColumnValues "country_code" in ["US","CA","UK","DE","JP"]
ColumnValues "order_total" between 0 and 1000000
ColumnValues "email" matches ".+@.+\\..+"
ColumnLength "phone" between 10 and 15
值約束用於捕捉垃圾資料和不符合規範的輸入。
模式 4 — 跨欄位一致性
ColumnCorrelation "order_total" "shipping_cost" > 0.5
CustomSql "SELECT COUNT(*) FROM primary WHERE order_total < shipping_cost" = 0
使用 ColumnCorrelation 處理統計關係，使用 CustomSql 處理任意 SQL 斷言。CustomSql 是處理內建規則無法表達的任何檢查的逃生口。
模式 5 — 新鮮度與參照完整性
DataFreshness "ingestion_timestamp" <= 1 days
ReferentialIntegrity "customer_id" "reference.customers.id" = 1.0
DataFreshness 衡量欄位中最新時間戳記的年齡。ReferentialIntegrity 檢查欄位中的值是否與參考資料集中的值匹配 — 這是 Redshift 本身不強制執行的外鍵檢查。
快速失敗 vs 警告並繼續模式
管道對 DQ 失敗的反應是 DEA-C01 考試直接測試的設計決策。
快速失敗 (Fail-Fast)
當任何 DQ 規則失敗時，Glue ETL 作業就會失敗。上游資料不會到達精選區，下游取用者不會看到損壞的資料，管道操作員會收到 CloudWatch 警報。將快速失敗用於高嚴重性的品質門檻 — 主鍵必須唯一、財務總額必須對帳、受監管的資料必須驗證。
警告並繼續 (Warn-And-Continue)
作業記錄失敗、發佈 CloudWatch 指標並繼續處理。將警告並繼續用於低嚴重性的資訊檢查 — 完整性低於目標但非零、新鮮度略微過時但非關鍵。下游管道照常執行；操作員獲得指標進行分類，但不會自動停止。
隔離 (Quarantine) — 欄位級失敗路由
Glue DQ 支援資料列級別的結果 (row-level outcomes)，將單個記錄標記為通過或失敗每條規則。作業可以將失敗的列路由到隔離的 S3 前置詞，而通過的列則繼續前往精選區。這是「兩全其美」的模式：管道不會中斷，但錯誤資料被隔離以便調查。
模式選擇
DEA-C01 考試會根據情境細節考驗這一點。「財務對帳管道絕不能載入損壞資料」 => 快速失敗。「行銷管道容忍不完整欄位但追蹤新鮮度」 => 警告並繼續。「具有混合品質來源的客戶資料」 => 隔離錯誤列以供人工檢閱。
使用 Glue 資料品質規則建議為新表引導建立規則集，然後隨著管道成熟對規則進行疊代。 建議引擎會分析資料表樣本並提議規則 — 根據觀察到的 Null 設定完整性閾值、為高基數欄位設定唯一性閾值、為數值欄位設定值範圍檢查、為所有欄位設定類型和存在性檢查。輸出是一份 DQDL 規則集草稿，工程師可以檢閱、調整並提交。此模式將 DQ 採納過程從數週的手動編寫縮短為數小時的精選。DEA-C01 考試中，「團隊有數百個欄位且沒有現成規則」時的正確答案是建議功能 — 當 AWS 官方建議可用時，切勿選擇「從頭開始手動編寫規則」或「使用第三方工具」。引導完成後，隨資料表演進排程定期重新產生建議。
將 DQ 指標發佈到 CloudWatch
Glue 資料品質會自動將評估結果作為 CloudWatch 指標發佈，以便進行監控和警報。
每個規則集的自定義指標
每個規則集評估都會產生一個在資料集和規則集範圍內的 glue.data.quality.score CloudWatch 指標。分數是通過規則的百分比。儀表板可以繪製隨時間變化的分數趨勢；當分數低於閾值時可觸發警報。
每條規則的指標
單個規則的結果會作為獨立指標發出，允許操作員繪製「過去 30 天 customer_email 的完整性」圖表，並偵測漸進式的品質下降。
與 EventBridge 整合
DQ 規則失敗會發出 EventBridge 事件，下游規則可以對此做出反應 — 發送 Slack 通知、觸發修復 Lambda 或在工單系統中建立工單。
與 CloudWatch 警報整合
典型的生產模式：DQ 分數低於 0.95 觸發 CloudWatch 警報；警報向管道所有者發送 SNS 通知；所有者進行調查並確認警報。結合複合警報 (Composite Alarms) 建立跨管道的品質儀表板。
Glue 資料品質 vs Glue DataBrew vs 自定義 Spark — 決策樹
三個重疊的選項需要清晰的決策樹。
Glue 資料品質
適用時機：生產 ETL 需要在管道內進行規則評估、規則是宣告式且穩定的、團隊想要免費的 CloudWatch 指標、需要與 Glue 資料目錄整合以獲取表級品質分數。
Glue DataBrew
適用時機：需要視覺化無程式碼準備、分析師是主要使用者、工作流程是探索性剖析和一次性清理、轉換比完整的 ETL 簡單。
自定義 Spark 程式碼 (Glue ETL 或 EMR)
適用時機：規則是高度自定義的且不適用於 DQDL、團隊具備 Spark 專業知識、效能最佳化至關重要、需要與 Deequ (Amazon 的開源 DQ 庫) 整合。
組合模式
成熟的管道通常會結合使用：DataBrew 用於初始剖析和分析師驅動的準備，Glue 資料品質用於生產規則強制執行，自定義 Spark 用於奇特的檢查。DEA-C01 考試可能會將此設為多步驟情境，正確答案是「使用 DataBrew 剖析，然後編寫 DQDL 規則，最後在 Glue ETL 作業中執行它們」。
資料品質的常見考試陷阱
請記住這五個。
陷阱 1 — 將 DataBrew 用於生產 DQ
情境描述了一個需要品質門檻的自動化生產管道。錯誤答案：DataBrew。正確答案：在 Glue ETL 作業中使用具備 DQDL 規則集和 EvaluateDataQuality 轉換的 Glue 資料品質。
陷阱 2 — 為標準檢查編寫自定義 Spark
情境描述了基本的完整性、唯一性和值範圍規則。錯誤答案：編寫自定義 PySpark 程式碼。正確答案：使用 Glue 資料品質 DQDL — 內建、宣告式且具備 CloudWatch 整合。
陷阱 3 — 為 200 個欄位手動編寫規則
情境描述了一個需要初始規則的寬表。錯誤答案：為每個欄位手動編寫 DQDL。正確答案：使用 Glue 資料品質規則建議進行引導。
陷阱 4 — 將 DataBrew 用於串流資料
情境描述了需要品質檢查的 Kinesis 串流資料。錯誤答案：DataBrew（僅限批次）。正確答案：具有自定義驗證的 Managed Service for Apache Flink，或基於 Lambda 的驗證，或帶有嵌入式檢查的 Glue 串流 ETL。
陷阱 5 — 混淆 DataBrew 剖析作業與品質強制執行
情境詢問如何「發現 (discover)」資料品質問題。正確答案：DataBrew 剖析作業（一次性發現）。情境詢問如何在每次管道執行時「強制執行 (enforce)」資料品質。正確答案：Glue 資料品質（持續強制執行）。情境中的動詞會告訴您該用哪種工具。
DataBrew 方案作業和 Glue 資料品質規則集解決的是不同問題 — 方案作業轉換資料，規則集評估資料，而 DEA-C01 考試常設置讓考生混淆兩者的題目。 方案作業回答「我該如何清理和重塑這個資料集？」 — 重新命名欄位、填補 Null、套用正則表達式、過濾資料列、遮罩 PII。規則集回答「這個資料集根據我的規則是否有效？」 — 完整性是否高於 95%、主鍵是否唯一、值是否在預期範圍內。考試陷阱：情境要求「對具有品質檢查的客戶資料進行自動化清理」，選項包括「DataBrew 方案作業」、「Glue 資料品質規則集」和「DataBrew 剖析作業」。如果情境強調轉換，則選方案作業。如果強調驗證和通過/失敗強制執行，則選規則集。如果強調發現未知問題，則選剖析作業。請仔細閱讀動詞 — 清理 (clean) = 方案，驗證 (validate) = 規則集，剖析 (profile) = 剖析作業。
資料合約 (Data Contracts) — 架構模式
資料合約是資料生產者與資料取用者之間關於資料集內容和行為的正式協議。
合約指定的內容
結構描述（欄位名稱、類型、是否可為 Null）、品質閾值（完整性、唯一性、新鮮度）、更新頻率（每小時、每日、按需）、所有權（哪個團隊負責）以及 SLA（取用者何時可以期望獲得新資料）。合約是受版本控制且具備多個版本的 — 破壞性更改需要新版本。
Glue 資料品質作為合約強制執行
附加到 Glue 資料目錄表的 DQDL 規則集即是可執行的合約。當生產者的管道執行時，規則集會評估新資料是否符合合約；取用者可以在取用前查詢最新的評估分數。
用於結構描述演進的 Schema Registry
Glue Schema Registry 處理合約中的結構描述演進部分 — 向後、向前或完全相容模式決定了新結構描述版本是否可以與舊取用者共存。結合 Schema Registry（處理結構描述）和 Glue 資料品質（處理品質）即可實現完整的資料合約強制執行故事。
白話文解釋 Glue DataBrew 與 Glue 資料品質
三個具體的類比可以使 DataBrew 與資料品質的區分變得直觀。
類比 1 — 餐廳衛生檢查
DataBrew 就像餐廳的備菜廚師，在早晨備菜期間品嚐並調整配方 — 檢查食材、調整調味、決定扔掉什麼，一切都憑藉視覺檢查和專業知識。備菜廚師是親力親為、探索性的，並受過發現問題的訓練。Glue 資料品質就像中午到達的衛生檢查員，帶著一份清單：冰箱溫度是否正確、沒有過期食材、備有洗手日誌、標註過敏原。檢查員不品嚐任何東西；他們根據預先定義的規則進行評估，要麼通過廚房，要麼勒令停業。備菜廚師 (DataBrew) 在準備期間操作；檢查員 (Glue 資料品質) 在服務開始前的門檻處操作。DEA-C01 的陷阱是派備菜廚師去做衛生檢查 — 慢、不一致、沒有稽核追蹤 — 或要求衛生檢查員去修正錯誤的配方（他們做不到，那不是他們的工作）。
類比 2 — 圖書館採購與流通櫃檯
DataBrew 是採購館員：當有一批新的遺贈書籍到達時，採購館員會親自檢查每個箱子，剖析這批收藏（多少小說、多少非小說、保存狀況、語言種類），剔除重複項，填補缺失的索書號，並決定哪些上架、哪些丟棄。這是緩慢、親力親為的專家工作。Glue 資料品質是流通櫃檯的自動化檢查：每本進入借閱系統的書必須具有有效的 ISBN、非 Null 的索書號、唯一的條碼，且在初次進入時已借出標記為 false。這項檢查在每場交易中執行，對錯誤資料能快速失敗，並將指標寫入圖書館的品質儀表板。採購負責處理新奇、不尋常的事物；流通則在每項操作中強制執行標準。DataBrew 剖析作業是採購庫存報告；DataBrew 方案作業是採購清理流程；Glue 資料品質是流通看門人。
類比 3 — 郵政系統分揀與地址驗證
DataBrew 就像郵件分揀員，他打開一袋混合郵件，查看每一封，決定它該放入哪個目的地箱子，並套用「郵資受損的郵件進入特殊處理箱」等規則。這是親力親為、方案驅動的，且可以在下一袋郵件中重複執行。Glue 資料品質就像購買郵資時的地址驗證系統：每個包裹必須具有有效的郵遞區號、非空的街道地址、收件人姓名，以及在限制範圍內的宣告重量 — 任何檢查失敗，包裹就會在櫃檯被拒絕，永遠不會進入郵遞流程。兩者都為品質服務；分揀員處理混亂的現實世界，而驗證系統則強制執行標準。DataBrew 適用於「我們有百萬條形狀未知的記錄，需要了解它們」的場景。Glue 資料品質適用於「我們有已知結構描述，需要在每批次中強制執行它」的場景。
關鍵數字與必須記住的事實
Glue DataBrew
- 內建 250 多種轉換
- 支援 S3, Redshift, RDS, Glue 目錄, Snowflake, JDBC 來源
- 剖析作業產生統計資訊和相關性
- 方案作業大規模重播視覺化轉換
- 按節點小時 (Spark 後端) 計費
- 無程式碼視覺化介面，也可透過 CLI/API 存取
Glue 資料品質
- DQDL 是規則定義語言
- 內建 20 多種規則類型 (RowCount, Completeness, Uniqueness 等)
- 規則建議功能可根據樣本分析進行引導
- 與 Glue ETL 作業整合 (EvaluateDataQuality 轉換)
- 與 Glue 資料目錄整合 (資料表級別品質分數)
- 自動發佈 CloudWatch 指標
- 規則失敗時發出 EventBridge 事件
- 支援快速失敗、警告並繼續或隔離資料列級別模式
資料品質維度
- 完整性、準確性、一致性、及時性、唯一性、有效性
- DQDL 透過不同規則類型涵蓋這六個維度
- Custom SQL 是用於任意檢查的逃生口
決策規則
- DataBrew = 視覺化、探索性、分析師驅動、剖析
- Glue 資料品質 = 宣告式規則、管道內、自動化強制執行
- 自定義 Spark = 奇特檢查、效能關鍵、Deequ 整合
- Schema Registry + Glue DQ = 完整的資料合約強制執行
記住八種最常測試的 DQDL 規則類型：RowCount, Completeness, Uniqueness, ColumnValues, ColumnCorrelation, DataFreshness, CustomSql, ReferentialIntegrity。 RowCount 斷言表大小。Completeness 斷言非 Null 比例。Uniqueness 斷言無重複比例。ColumnValues 斷言集合或範圍內的成員身份。ColumnCorrelation 斷言欄位間的統計關係。DataFreshness 斷言最新時間戳記的年齡。CustomSql 是任意 SQL 斷言的逃生口。ReferentialIntegrity 斷言針對參考資料集的外鍵式匹配。DEA-C01 考試可能會在程式碼區塊中顯示 DQDL 語法並詢問「此規則檢查什麼？」或「哪種規則類型能捕捉此問題？」。記住這八個名稱及其語義含義幾乎涵蓋了所有可能出現的情境。
DEA-C01 考試優先事項 — Glue DataBrew 與 Glue 資料品質。 此主題在 DEA-C01 考試中佔有很大權重。掌握每種 AWS 服務公開的權衡、決策邊界以及成本/效能觸發因素 — 考試將測試那些取決於了解哪種服務是錯誤答案的情境，而不僅僅是哪種是正確答案。
FAQ — Glue DataBrew 與 Glue 資料品質常見問題
Q1 — 我什麼時候該用 Glue DataBrew 而非 Glue 資料品質？
當工作流程是探索性資料剖析、無程式碼視覺化準備或分析師驅動的清理（使用者希望視覺化檢查資料列並像電子試算表一樣套用轉換）時，請使用 Glue DataBrew。當工作流程是自動化、宣告式、管道內的規則強制執行（在每次 Glue ETL 執行時執行並發出 CloudWatch 指標）時，請使用 Glue 資料品質。兩者是互補的 — DataBrew 用於設計階段發現問題並建立清理邏輯原型，Glue 資料品質用於生產階段持續強制執行規則。DEA-C01 考試會使用情境動詞：發現 (discover)、探索 (explore)、剖析 (profile) => DataBrew；強制執行 (enforce)、驗證 (validate)、阻止錯誤資料 => Glue 資料品質。絕不要為生產自動化管道情境選擇 DataBrew，也不要為分析師驅動的探索性情境選擇 Glue 資料品質。
Q2 — 我該如何為新表編寫 DQDL 規則而不用手動寫 50 條規則？
使用 Glue 資料品質規則建議。該功能會分析資料集樣本，並根據觀察到的屬性提議初始規則集 — 如根據 Null 率設定完整性閾值、為可能是鍵的欄位設定唯一性閾值、為數值欄位設定值範圍約束、為所有欄位設定類型和存在性檢查。建議以 DQDL 文本形式產生，工程師可以複製、編輯並提交到版本控制中。引導完成後，隨著團隊了解哪些閾值過嚴或過鬆，再隨時間精煉規則。DEA-C01 考試將此作為「我們有一個沒有現成規則的寬表」的答案 — 當建議功能可用時，切勿手動編寫。
Q3 — 在不中斷整個管道的情況下，我該如何處理 DQ 失敗？
三種選擇。警告並繼續：組態 EvaluateDataQuality 轉換以記錄失敗並發出 CloudWatch 指標而不使作業失敗。管道執行到完成；操作員查看指標並在線外進行分流。隔離：使用資料列級別的結果將失敗的記錄路由到隔離的 S3 前置詞，而通過的列則繼續前往精選區。補償動作：利用規則失敗發出的 EventBridge 事件觸發修復 Lambda（例如重新從來源提取、填補 Null 或標記為人工檢閱）。根據嚴重程度選擇 — 關鍵規則（主鍵唯一性、財務對帳）應快速失敗，資訊性規則（完整性略微下降）應警告並繼續，混合嚴重程度的資料集應隔離。DEA-C01 考試將此作為情境設計：閱讀業務背景來決定。
Q4 — Glue 資料品質規則可以在串流資料上執行嗎？
Glue 資料品質主要針對 Spark 引擎上的批次 ETL 設計，在每次作業執行時針對有限資料集評估規則集。對於串流資料品質，模式有所不同：使用 Managed Service for Apache Flink 進行具狀態串流驗證、在 Kinesis 或 DynamoDB Streams 事件上進行基於 Lambda 的逐筆記錄檢查，或使用帶有嵌入式驗證邏輯的 Glue 串流 ETL。Glue 串流 ETL 可以對微批次包含 EvaluateDataQuality，但延遲剖析不同於真正的串流驗證。DEA-C01 考試將串流 DQ 設為 Flink 或 Lambda 問題，而非 Glue 資料品質問題 — 尋找情境中的「即時」或「亞秒級」提示。
Q5 — Glue 資料品質如何與 Glue 資料目錄整合？
規則集可以作為「資料品質」屬性附加到 Glue 資料目錄表，使目錄具有在主控台中可見的品質分數。Athena 和下游取用者可以在取用表之前查詢最新的評估分數。這種整合實現了「資料合約」模式，生產者的管道在每次載入時執行規則集，取用者可以根據新鮮度和品質是否滿足需求來決定是否啟動昂貴的分析查詢。DEA-C01 考試將此作為「無需手動協調即可向取用者呈現資料品質狀態」的正確答案。
Q6 — DQDL 中 IsComplete 和 Completeness 有什麼區別？
IsComplete "column_name" 是 Completeness "column_name" = 1.0 的簡寫 — 該欄位必須 100% 非 Null 且無容差。Completeness "column_name" > threshold 則允許容差 — 例如，Completeness "email" > 0.95 要求 95% 非 Null，但容忍 5% 缺失。對主鍵欄位和其他不可商量的欄位使用 IsComplete；對選填的聯繫資訊等具有容忍度的欄位使用 Completeness。類似模式：IsUnique 是 Uniqueness = 1.0 的簡寫，而 Uniqueness > 0.99 則允許容差。DEA-C01 考試可能會在選項中同時顯示兩者，測試考生是否知道「嚴格」與「容忍」的區別。
Q7 — 什麼是資料合約，Glue 資料品質如何強制執行它？
資料合約是資料生產者與取用者之間的正式協議，指定了結構描述、品質閾值、更新頻率、所有權和 SLA。合約受版本控制，且破壞性更改需要新版本。Glue 資料品質強制執行合約中可執行的部分 — 附加到 Glue 資料目錄表的 DQDL 規則集在每次管道執行時根據承諾的品質閾值評估資料集。結合 Glue Schema Registry 進行結構描述演進治理（向後、向前、完全相容模式），即可涵蓋合約中的結構描述部分。DEA-C01 考試將資料合約作為「生產者團隊和取用者團隊需要正式就資料集品質達成一致，而無需臨時協調」的架構答案 — Glue Schema Registry 加上 Glue 資料品質是 AWS 原生答案。
延伸閱讀 — 官方 AWS 文件
權威的 AWS 來源包括 Glue 資料品質文件（DQDL 語法、規則類型、建議、EvaluateDataQuality 轉換）、Glue DataBrew 文件（剖析作業、方案作業、轉換參考）、AWS 大數據部落格關於資料合約和資料品質模式的系列文章，以及涵蓋分析階段資料品質的 AWS Well-Architected Analytics Lens。Skill Builder DEA-C01 Exam Prep Standard Course 有專門針對網域 3 資料品質強制執行的模組。對於更深入的基於 Spark 的品質工程，GitHub 上的開源 Deequ 庫（由 AWS Labs 開發）是 Glue 資料品質構建的基礎 — 了解 Deequ 有助於處理自定義規則情境。AWS Samples GitHub 存儲庫包含了結合 DataBrew 剖析、Glue ETL 和 Glue 資料品質評估的端到端範例管道。