Amazon DEA-C01: 數據編目與中繼資料管理 — 學習指南

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

屬於 Amazon Data Engineer Associate DEA-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

此領域涵蓋了元數據層，它讓資料在 AWS 資料平台中變得可被探索、可查詢且可治理。有效的目錄化與元數據管理能減少分析工作的阻力，並確保下游的消費者可以找到結構描述、分割區、存取政策與資料血緣。此領域的 AWS 服務——Glue Data Catalog、Glue Schema Registry、Lake Formation、Athena 整合及 DataBrew——為資料探索、結構描述演進、治理和剖析提供了互補的工具。了解這些服務如何互動、其詳細配置以及典型的故障模式，對於確保維運的可靠性與安全性至關重要。

AWS Glue Data Catalog 的結構與操作

Glue Data Catalog 是一個區域性、集中式的元數據儲存庫，用於存放資料庫、資料表、分割區、連線以及使用者定義的分類器。其核心基元為：

• Database：一個邏輯容器（使用 aws cli：

undefined

）。

• Table：描述一個資料集（serde、輸入/輸出格式、欄位、tableType

undefined

）。您可以透過主控台、Glue API 或 CloudFormation 來建立/更新；例如：

undefined

。

• Partition：分割區鍵值與 S3 前綴之間的對應關係；分割區可由 Glue crawler 管理（

undefined

）或明確地新增（

undefined

）。

維運模式：

• 使用 Crawler 進行探索：為不斷變化的 S3 版面配置排程 crawler，選擇分類器順序（CSV/JSON/Parquet），並設定 crawler 政策以進行增量更新。
• 程式化控制：當有事件驅動的 S3 資料到達時，優先使用 Glue API 或 Lambda 來新增分割區，而不是僅依賴 crawler。
• 目錄複寫：Glue Data Catalog 是區域性的。對於跨區域讀取，可考慮在每個區域執行 crawler、建立自動化來複寫元數據，或使用資源連結模式；設計決策取決於成本、一致性需求以及跨區域的查詢模式。

決策標準：

• 當需要結構描述偵測且資料格式為異質時，使用 crawler；對於嚴格的結構描述以及大量、可預測的資料集，則使用明確的資料表建立方式。
• 對於高頻率的小檔案到達，使用 batch-create-partition 或基於 Lambda 的分割區管理，以避免 crawler 的延遲並降低 Glue API 成本。

結構描述的探索與演進

Schema Registry 和 Glue schema 支援 Avro、JSON 和 Protobuf，適用於串流和長期的生產者/消費者合約。關鍵功能包括：

• 透過主控台或 CLI 註冊結構描述（

undefined

）。

• 相容性模式：BACKWARD（消費者可以讀取新資料）、FORWARD（新消費者可以讀取舊資料）和 FULL（兩者皆可）。根據消費者部署模式進行選擇。
• 結構描述強制執行：對於串流，將註冊表與 Kinesis Data Streams、MSK 或 Kafka 客戶端及 AWS SDK 整合，以透過嵌入的結構描述版本與驗證來進行序列化/反序列化。

實務配置與演進模式：

• 對於擁有多個消費者的 Avro，使用 BACKWARD 相容性，以允許新增帶有預設值的新欄位；避免破壞性的移除操作。
• 對於跨團隊的嚴格合約演進，要求 FULL 相容性，並透過執行結構描述驗證的 CI 步驟來管制結構描述的變更。
• 對於欄位為可選且結構描述不固定的 JSON，使用具備寬鬆預設值的結構描述演進，但在目錄中對元數據進行版本控制，以防止消費者應用在無聲中被破壞。

決策標準：

• 當有多個消費者需要一個標準結構描述時，為串流事件使用 Schema Registry。對於批次資料集，其中格式（Parquet/ORC）提供了讀取時定義結構（schema on read）的功能，則使用 Glue 資料表結構描述。
• 透過評估您是否控制所有消費者（可以協調 FORWARD）或需要安全的加法式變更（選擇 BACKWARD）來挑選相容性模式。

使用 Lake Formation 進行資料血緣與治理

Lake Formation 建立在 Glue Data Catalog 之上，提供精細的存取控制、稽核與資料血緣控制。核心功能包括：

• LF-Tags：應用於資料庫、資料表和欄位的基於標籤的存取控制。在 Lake Formation 中建立 LF-Tags，指派鍵值對，然後透過基於標籤的授權（tag-based grants）而非基於資源的授權（resource-based grants）來授予 IAM 主體權限。
• 欄位層級控制：使用 LF-Tags 來遮罩或限制欄位；在 Lake Formation 主控台或使用

undefined

來配置欄位層級的權限。

• 資料血緣與稽核：啟用 CloudTrail 和 Glue job 指標以擷取 ETL 任務的資料血緣；使用 Glue job bookmarks 和目錄中的 job bookmarks 元數據來追蹤已處理的資料。

配置模式：

• 定義一小組一致的 LF-Tag 鍵（例如，sensitivity:public/private/PII），並在建立資料表時或透過 Glue crawler 使用其配置或後處理程式碼來自動化標記。
• 透過 Lake Formation 的委派管理員（Delegated Admin）角色來委派管理權限，並將 Lake Formation 權限授予分析團隊，同時限制 IAM 層級的 S3 存取。

決策標準：

• 當您需要對眾多消費者進行集中式、欄位層級和基於標籤的控制，且治理/可稽核性是強制要求時，請使用 Lake Formation。
• 如果您的存取控制需求很簡單（儲存桶層級），IAM+S3 政策可能就足夠了；若需要精細且與目錄整合的控制，請使用 Lake Formation。

Athena 與 Glue catalog 整合

Athena 依賴 Glue Data Catalog 來取得中繼資料。常見的整合點與操作要點如下：

• 分割區處理：Athena 從 Glue catalog 讀取分割區。當新的 S3 分割區被新增時，您必須更新 catalog。選項有：
  • 從 Athena 執行 MSCK REPAIR TABLE db.table;，或使用帶有該 SQL 的 aws athena start-query-execution 來更新在資料表位置下發現的分割區。
  • 在 S3 PUT 事件發生時，使用 aws glue batch-create-partition 以程式化方式新增分割區（建議用於事件驅動流程）。
  • 透過設定資料表屬性如 projection.enabled=true、projection.year.type=integer、projection.month.range=1 及 projection.year.range=2018,2026 來使用分割區投影 — 這能完全避免對 Glue 的查詢，對於分割區數量非常龐大的情況至關重要。
• 查詢效能與成本的權衡取捨：
  • 分割區投影移除了對 Glue API 的呼叫，並大幅降低了處理大量小型分割區時的延遲，但它要求分割區的命名方式必須是確定性的。
  • MSCK REPAIR TABLE 對於偶爾的臨時性資料新增來說很簡單，但對於大型資料集可能會很慢。

Glue DataBrew 的輔助作用：

• 使用 DataBrew 進行無程式碼的資料剖析與轉換；將 DataBrew 指向 Glue Catalog 中的資料表或 S3 路徑，執行剖析任務、建立配方，並將輸出結果發布回 S3 或成為新的 Glue 資料表。
• 當需要複雜的 Spark 邏輯時，可使用 DataBrew 進行探索性的品質檢查，並產生轉換邏輯，以便後續在 Glue ETL 中投入生產環境。

決策標準：

• 當分割區數量眾多且遵循可預測的結構（基於日期／數字）時，使用分割區投影。
• 對於事件驅動、近乎即時的資料擷取，使用程式化的 Glue 分割區更新。
• 僅在偶爾需要資料回填或無法實現自動化時，才執行 MSCK REPAIR TABLE。

常見陷阱與決策標準

• Athena 查詢失敗，因為 S3 資料到達後 Glue 分割區未更新：避免僅依賴 crawlers；應改為執行 MSCK REPAIR TABLE 進行偶爾的更新、在 S3 事件上觸發 aws glue batch-create-partition，或為大型且可預測的分割區集合實作分割區投影。
• 選擇錯誤的 schema 登錄檔相容性模式會導致消費者端出錯：對於附加性變更和消費者穩定性，選擇 BACKWARD；當生產者必須與舊版消費者保持相容時，選擇 FORWARD；當雙向都必須安全時，選擇 FULL；在 CI 流程中根據消費者的 schema 驗證變更。
• 假設 Glue Data Catalog 是全球性的：該 catalog 是區域性的。若要跨區域存取，需設計複寫機制或在目標區域中運行 catalog；不要假設 Glue 的中繼資料會自動在各區域間可用。
• 只授予 IAM S3 存取權限而未授予 Lake Formation 權限：Athena 和 Lake Formation 會強制執行目錄層級的權限；除了任何 IAM 政策外，務必也要授予 Lake Formation 權限（以及在有使用時授予 LF-Tags）。
• 過度的分割區粒度：使用太多微小的分割區會損害查詢規劃並增加中繼資料的開銷；應偏好使用較粗的分割區（例如每日而非每分鐘），或使用分割區投影。
• 忽略 DataBrew 角色權限：DataBrew 任務需要一個具備 Glue 和 S3 權限的服務角色；確保該角色擁有 Glue:GetTable、S3 讀寫權限，以及在資料集有加密時的 kms:Decrypt 權限。

實務問題：使用案例情境

Acme 零售公司每小時會將帶有日期／小時分割區的銷售檔案接收到 S3，分析師則在 Athena 中查詢這些資料；但在資料載入後，使用者會看到查詢失敗和過時的結果，因為分割區在 Glue Data Catalog 中不可見。

1. 實作一個 S3 PUT 事件通知來觸發一個 Lambda 函數，該函數會呼叫 aws glue batch-create-partition 以立即註冊新的分割區。
2. 對於較舊的資料或資料回填，排程一個執行 MSCK REPAIR TABLE db.sales_hourly; 的 Athena 查詢；或針對已知的範圍執行目標性的 aws glue batch-create-partition。
3. 如果分割區遵循嚴格的日期／小時命名慣例，則在 Glue 資料表上啟用分割區投影（設定 projection.enabled=true 並定義年／月／日／小時的屬性），以消除目錄更新的成本。
4. 為資料表新增表示敏感度的 LF-Tags，並授予分析師 Lake Formation 權限，以便 Athena 查詢被允許並受到治理。
5. 在預備環境中使用 Glue DataBrew 來剖析新的每小時檔案，以捕捉 schema 漂移；如果發現 schema 變更，則在 Glue Schema Registry 中註冊新的 schema 版本，並在部署到生產環境前驗證其相容性。

理由：自動化的分割區註冊或投影消除了導致 Athena 查詢失敗的中繼資料延遲；將此方法與 Lake Formation 的治理相結合可確保安全的存取，而由 DataBrew 驅動的剖析能及早捕捉到 schema 漂移，同時 Glue Schema Registry 保護了串流與批次消費者免受不相容 schema 變更的影響。

← 數據儲存與資料湖架構 · 所有領域 · 數據轉換與處理 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Amazon →