AWS Glue 資料目錄 (AWS Glue Data Catalog) 和 AWS Lake Formation 是每個 AWS 資料湖的兩大治理層。在 DEA-C01 考試中，它們橫跨網域 2 和 網域 4，出現在涉及中繼資料管理、串流下的結構描述演進、欄位和資料列級別的細粒度存取以及跨帳戶資料共享的情境中。來自 Tutorials Dojo、ExamCert.App 和 Camille Chang 的 dev.to 攻略的研究指南都指出了同一個痛點：考生常將 Glue 資料目錄與 Lake Formation 混為一談，忽略了 IAM 儲存貯體政策與 Lake Formation 必須同時允許存取的兩層存取模型，並忘記了基於標記的存取 (tag-based access) 是將權限擴展到數百張表以上的唯一方法。考試中的錯誤選擇與生產環境中的錯誤選擇如出一轍：在 Lake Formation 已註冊的儲存貯體上僅建置基於 IAM 的存取，查詢會靜默失敗並返回無用的「存取遭拒」錯誤；將資料庫共享給取用者帳戶卻未使用資源連結 (resource-link) 模式，取用者將完全找不到該目錄。
本指南專為資料工程師的視角編寫。內容涵蓋了 Glue 資料目錄的定義、目錄-資料庫-資料表-分區的層次結構、用於串流資料結構描述管理的 Glue Schema Registry、Lake Formation 在目錄之上的增強功能、Lake Formation 權限的四個層級（資料庫、資料表、欄位、資料列及單元格）、Lake Formation 與 S3 儲存貯體政策及 IAM 的互動方式、使用 LF-Tags 的基於標記的存取控制、使用資源連結和 AWS RAM 的跨帳戶共享、已註冊位置與治理強制執行邊界，以及規範的考試陷阱。到最後，目錄與 Lake Formation 的區分應該像圖書館索書卡與圖書館借閱政策之間的差異一樣自然。
什麼是 Glue 資料目錄？
Glue 資料目錄是一個集中化的、區域範圍的中繼資料存放庫，供每個 AWS 分析服務使用的資料表、資料庫和連線使用。
資料目錄存在的原因
在 Glue 資料目錄出現之前，每個 AWS 分析服務都有自己的中繼資料存放區。Athena 有自己的內部資料表定義，EMR 有 Hive Metastore，Redshift Spectrum 需要自己的外部結構描述。每個服務都必須單獨組態，且它們經常會失去同步。Glue 資料目錄是所有這些服務都讀取的單一中繼資料存放區 — 只需定義一次資料表，即可從 Athena、EMR、Redshift Spectrum、Glue ETL、SageMaker、Quicksight 和 Lake Formation 進行查詢而無需重新定義。
目錄層次結構
目錄具有四層層次結構：目錄 (catalog)（預設每個 AWS 帳戶每個區域一個）、資料庫 (database)（資料表的邏輯分組，相當於關係型資料庫中的結構描述）、資料表 (table)（S3 上的 Parquet/Avro/CSV/Iceberg 資料集或 JDBC 來源的中繼資料記錄）以及 分區 (partition)（對應於分區值的 S3 前置詞子目錄）。每張表都具有欄位、類型、分區鍵、儲存位置、檔案格式和 SerDe 組態。
目錄存儲內容對比 S3 存儲內容
目錄僅存儲中繼資料 (metadata) — 欄位名稱、類型、分區規格、S3 路徑。實際資料則存放在 S3（或 JDBC 來源）中。更新目錄不會更改資料；更新資料也不會自動更改目錄。這種解耦是許多錯誤和考試問題的根源：如果檔案到達但分區中繼資料未添加到目錄中，目錄可能會與 S3 失去同步。
白話文解釋 Glue 資料目錄與 Lake Formation
目錄與治理的分離可以從具體的類比中獲益。
類比 1 — 圖書館索書卡與圖書館借閱規則
想像一個研究圖書館。入口處的索書卡 (card catalog) 列出了館內的每本書 — 書名、作者、主題、書架位置。讀者瀏覽目錄，找到一本書，然後走向書架。索書卡不控制存取 — 任何進入圖書館的人都可以瀏覽它，任何找到書的人只要沒有其他規則阻止，都可以從書架上取下。這就是 Glue 資料目錄 — 一個發現索引，說明「這些表存在，這是它們的結構描述，這是它們的 S3 位置」。
圖書館的借閱政策 (borrowing policy) 是一份單獨的文件。它規定教職員可以借閱珍本書籍，大學生則不行，只有博士生可以從封閉式書架借閱，且預留書籍必須在館內閱讀。這份政策是櫃檯館員在讀者試圖借書時強制執行的。這就是 Lake Formation — 位於目錄之上的政策層，說明「你可以讀取這些欄位，不能讀取那些，只能讀取這些列，只能從這個帳戶讀取」。目錄告訴你存在什麼；Lake Formation 告訴你你被允許讀取什麼。
類比 2 — 醫院病歷索引與 HIPAA 存取控制
想像一間醫院。病歷索引 (medical records index) 按病患 ID 列出了每份病歷、測試結果和影像研究 — 該索引允許臨床醫生找到所需的記錄。該索引是全面的，列出了所有內容，無論誰被允許查看。這就是 Glue 資料目錄。
醫院的 HIPAA 存取控制系統 決定哪些臨床醫生可以閱讀哪些病歷。心臟科病房的護士可以閱讀心臟病人的病歷，但不能閱讀精神科病人的。研究分析師可以閱讀去識別化的聚合資料，但不能閱讀病患身份欄位。藥劑技術員可以查看藥物清單，但不能查看診斷歷史。這就是具備欄位、資料列和單元格級別權限的 Lake Formation。索引說明記錄存在；存取控制系統則說明該使用者實際上可以打開哪些記錄。
兩層安全性模型對應得很清晰：大門口的門禁讀卡機（IAM 和 S3 儲存貯體政策）決定誰被允許進入建築物；而病歷級別的存取控制 (Lake Formation) 則決定這個人在進入後可以閱讀哪些病歷。兩者都必須允許存取 — 透過了門禁但在病歷處被拒絕，你仍然無法閱讀。
類比 3 — 辦公大樓目錄與樓層存取
想像一棟企業辦公大樓。大廳目錄 (lobby directory) 列出了每個租戶 — 公司名稱、樓層、套房號碼。任何經過大廳的人都可以閱讀它；該目錄純粹是提供資訊的。這就是 Glue 資料目錄。
大樓有兩層保安：大廳的旋轉閘門 (IAM/S3) 允許任何持有有效樓層門禁卡的人進入，而每個樓層都有自己的門禁讀取器 (Lake Formation)，決定這個人可以進入該樓層的哪些租戶辦公室。一名顧問可能持有大廳門禁卡，並獲准進入 5 樓和 7 樓，但不獲准進入 8 樓。目錄對每個人都一樣；而樓層存取則是因人而異。考試中會設置這種模式：查詢失敗是因為 S3 儲存貯體政策允許但 Lake Formation 拒絕，或反之亦然 — 兩層都必須允許操作才能成功。
目錄組件 — 資料庫、資料表、分區、連線
目錄具有每個資料工程師都必須了解的結構化組件。
資料庫 (Database)
資料庫是資料表的邏輯分組 — 通常按業務領域或資料區域劃分。常見模式：raw_landing (原始投放), silver_curated (銀級精選), gold_marts (金級市集)，或 customer_data (客戶資料), transactions (交易), inventory (庫存)。目錄中的資料庫名稱不區分大小寫。權限可以在資料庫級別授予（涵蓋資料庫中的所有資料表及未來資料表）。
資料表 (Table)
資料表是描述資料集的中繼資料記錄。內容屬性包括欄位（名稱、類型、註釋）、分區鍵、儲存位置（S3 路徑或 JDBC URL）、輸入/輸出格式（Parquet, ORC, CSV）、SerDe（格式的序列化程式/還原序列化程式）、資料表類型（EXTERNAL_TABLE, GOVERNED, ICEBERG_TABLE）以及資料表參數（壓縮、投影規則等）。資料表可以由 Glue 爬蟲、寫入目標的 Glue ETL 作業、Athena DDL、Lake Formation 或直接呼叫 Glue API 建立。
分區 (Partition)
分區是資料表中某個分區值的中繼資料記錄。對於按日分區的表，每一天就是一個分區。分區具有自己的儲存位置（該分區的 S3 前置詞）和欄位統計資訊。Glue 目錄分區 API 每張表最多支援 1,000 萬個分區。當分區數量超過幾十萬時，為了查詢計畫程式的效能，分區投影 (partition projection) 優於目錄存儲的分區。
連線 (Connection)
連線存儲非 S3 資料來源（JDBC 資料庫、MongoDB、Kafka、Salesforce）的認證和網路組態。連線包含作業需要到達來源時的 VPC、子網路、安全性群組設定，以及 IAM 認證或 AWS Secrets Manager 的金鑰引用。
AWS Glue 資料目錄是一個區域範圍、帳戶級別的中繼資料存放庫，組織結構為目錄 → 資料庫 → 資料表 → 分區，被每個 AWS 分析服務（Athena, EMR, Redshift Spectrum, Glue ETL, SageMaker）用作資料表定義和儲存位置的單一來源。 目錄僅存儲中繼資料 — 結構描述、類型、分區規格、儲存路徑、資料表參數 — 而不存儲實際資料，資料存放在 S3 或 JDBC 來源中。資料目錄是 AWS 資料湖架構的骨幹；如果沒有它，每個分析服務都必須維護自己的資料表定義，這會導致它們失去同步。在 DEA-C01 中，「Athena 從哪裡獲取其資料表定義」或「EMR 和 Redshift Spectrum 如何共享結構描述」等情境都由 Glue 資料目錄來回答。
Glue Schema Registry — 串流結構描述管理
Schema Registry 是一個獨立但相關的 Glue 功能，用於串流資料。
Schema Registry 的功能
Schema Registry 為串流資料來源（Kafka 主題、Kinesis Data Streams）存儲 Avro、JSON Schema 和 Protobuf 結構描述。生產者註冊結構描述；取用者獲取它們。登錄檔會強制執行相容性規則，因此生產者無法發佈會破壞現有取用者的結構描述。
相容性模式
從最寬鬆到最嚴格共有五種模式：NONE (無強制執行，允許任何更改)、BACKWARD (向後相容，新結構描述讀取器可以讀取舊資料)、BACKWARD_ALL (與所有先前版本向後相容)、FORWARD (向前相容，舊讀取器可以讀取新資料)、FORWARD_ALL、FULL (全相容，雙向)、以及 FULL_ALL。最常見的生產模式是 BACKWARD 或 FULL — 向後相容意味著新取用者可以讀取主題中仍存在的舊訊息；完全相容則意味著生產者和取用者可以按任何順序部署。
結構描述演進規則
增加一個帶有預設值的全新增欄位：向後相容。移除一個選填欄位：向前相容。增加一個沒有預設值的必填欄位：破壞兩種相容性模式。重新命名欄位：破壞兩者。更改欄位類型（例如從 int 到 long）：破壞向前相容；將 int 擴大到 long 有時是向後相容的。登錄檔會在結構描述發佈時驗證這些規則，拒絕違反所組態相容性的更改。
Schema Registry 對比資料目錄
Glue 資料目錄與 Glue Schema Registry 是獨立的組件。資料目錄存儲用於分析 (Athena, EMR, Spectrum) 的資料表中繼資料。Schema Registry 存儲具有相容性規則的串流資料結構描述。它們都是 Glue 服務的一部分，但回答的是不同的問題。
Glue Schema Registry 存儲並驗證用於串流資料的 Avro、JSON Schema 和 Protobuf 結構描述，具備多種相容性模式 (BACKWARD, FORWARD, FULL)，可防止生產者發佈會破壞現有取用者的結構描述更改。 Schema Registry 是串流資料生產者 (Kafka, Kinesis, MSK) 與取用者之間的合約 — 註冊主題中的每條訊息都符合註冊的結構描述，且更改在傳播前會經過驗證。如果沒有 Schema Registry，結構描述演進錯誤只能在取用者執行階段（通常是在生產環境中）才能被發現。在 DEA-C01 中，Schema Registry 會在關於串流管道可靠性和結構描述相容性的情境中被測試 — 答案是使用適當的相容性模式註冊結構描述，而不是僅依賴生產者端的自律。
Glue 爬蟲 — 目錄填充
爬蟲 (Crawlers) 是從 S3 或 JDBC 來源自動填充目錄的方法。
爬蟲的工作原理
爬蟲掃描 S3 前置詞（或 JDBC 結構描述），從樣本資料中推斷結構描述，偵測分區結構，並將資料表定義寫入目標 Glue 資料庫。在新的 S3 前置詞上執行爬蟲，你就能獲得一個可以在 Athena 中立即查詢的資料表。在新檔案到達後再次執行，它會添加新分區並在必要時更新結構描述。
爬蟲組態
爬蟲具有目標（S3 路徑或 JDBC URL）、排程（按需、每小時、每日、自定義 cron）、分類器 (classifiers)（內建支援 Parquet, JSON, CSV 等常見格式；自定義 Grok 模式用於日誌格式）以及排除模式 (exclusion patterns)（用於跳過 _SUCCESS 標記或 .tmp 檔案）。權限：爬蟲執行時使用的 IAM 角色需要對來源儲存貯體具有 s3:GetObject 權限，並對目錄具有 glue:CreateTable/glue:UpdatePartition 權限。
「多張表」問題 (Multiple-Tables Gotcha)
一個常見的錯誤：爬蟲掃描 S3 前置詞並建立了多張表而非一張，因為子目錄具有不同的檔案結構或結構描述。應在爬蟲分組設定中組態 資料表層級 (TableLevel) — 設定到特定的路徑深度，使爬蟲將整個前置詞視為一張表。考試中常將此設為「爬蟲為本應是一張表的內容建立了 50 張表」 — 答案是調整資料表層級分組設定。
爬蟲對比分區投影
爬蟲透過掃描 S3 將分區添加到目錄中 — 在大規模情況下速度慢，每次執行都會消耗 DPU 分鐘。分區投影則在查詢時根據規則計算分區值 — 免費且瞬間完成。對於具有可預測分區結構的按時間分區的表，分區投影優於爬蟲。對於不可預測的結構描述或非平凡的分區發現，爬蟲則更合適。
Lake Formation 在目錄之上的增強功能
Lake Formation 是坐落在 Glue 資料目錄之上的治理層。
治理層
Lake Formation 為資料湖資源提供集中化的權限管理。如果沒有 Lake Formation，存取控制必須透過 Athena 上的 IAM 政策、S3 儲存貯體政策和 Glue 資源政策逐表組態 — 每個都在不同地方，難以稽核。有了 Lake Formation，所有這些都在一個具備單一主控台的權限模型下得到統一。
Lake Formation 權限模型
Lake Formation 授權分為多個層級：資料庫（涵蓋資料庫中的所有資料表及未來資料表）、資料表（特定資料表）、欄位（資料表內的特定欄位）、資料列（返回資料列子集的過濾表達式）以及 單元格 (cell)（結合欄位和資料列過濾器進行細粒度遮罩）。授權使用熟悉的 SQL 語義 — SELECT, INSERT, ALTER, DELETE, DESCRIBE, DROP，外加 Lake Formation 特有的權限如 CREATE_TABLE, GRANTABLE_PRINCIPAL。
已註冊位置 (Registered Locations)
為了讓 Lake Formation 對資料強制執行權限，底層的 S3 路徑必須在 Lake Formation 中進行 註冊 (registered)。註冊行為告知 Lake Formation「我對此 S3 路徑具有權威性」。註冊後，Lake Formation 會為授權的查詢發放短期 S3 認證 — Athena 和 Redshift Spectrum 等服務接收這些認證，並使用它們存取 S3，而非使用其自身的 IAM 身份。
用於擴展權限的 LF-Tags
直接的資料表級別授權無法擴展到幾百張表以上。LF-Tags 是附加到資料庫、資料表、欄位的鍵值對標記。權限授予在標記值而非特定資源上 — 「將 SELECT 權限授予所有標記為 Department=Finance 的資源給 finance-analyst 角色」。為新表貼上正確的標記，它就會自動繼承現有的權限。LF-Tags 是在擁有數千張表的目錄中管理權限的唯一切實可行的方法。
Lake Formation 權限和 S3 儲存貯體政策構成了兩層存取模型 — 兩者都必須允許操作，查詢才能成功，且衝突時預設為拒絕。 工程師通常會在資料表上授予 Lake Formation SELECT 權限，但在 Lake Formation 處於 IAMAllowedPrincipals 回退模式時忘記更新 S3 儲存貯體政策，或者遷移到 Lake Formation 但留下了限制性的儲存貯體政策，從而阻礙了新的流程。DEA-C01 考試將此設為疑難排解情境：「使用者在資料表上具有 Lake Formation SELECT 權限，但 Athena 返回存取遭拒」 — 答案是檢查 S3 儲存貯體政策、已註冊位置的 IAM 角色，以及如果使用了加密則需檢查 KMS 金鑰政策。所有四個（Lake Formation 授權、S3 儲存貯體政策、註冊位置角色、KMS 金鑰政策）都必須允許存取。將「我授予了 Lake Formation」與「存取已生效」混為一談是 Lake Formation 最常被引用的考試錯誤。
Lake Formation 細粒度存取 — 欄位、資料列、單元格
細粒度存取是 Lake Formation 相對於單純 IAM 的最大區別。
欄位級安全性 (Column-Level Security)
在具有「包含欄位 (Included Columns)」清單的資料表上授予 SELECT 權限，使用者就只能讀取這些欄位。其他欄位在查詢時會被過濾掉 — Athena 和 Redshift Spectrum 會遵循欄位過濾器，使用者永遠看不到排除的資料。用於 PII 欄位遮罩：授予分析師存取除客戶名稱和電子郵件以外的所有欄位；授予客戶服務團隊存取包含這些欄位的所有內容。
帶有資料篩選器的資料列級安全性
Lake Formation 資料篩選器 (data filters) 為每個（資料表，委託人）定義一個資料列過濾表達式（SQL 布林值）。授予帶有 region = 'us-east-1' 資料篩選器的 SELECT 權限，使用者就只能讀取這些行。用於多租戶資料湖中的租戶隔離 — 每個租戶只能看到自己的資料列，且全部來自同一張表。
單元格級安全性 (Cell-Level Security)
結合欄位級和資料列級過濾器，結果就是單元格級。使用者只能讀取特定資料列中的特定欄位。最常見的使用案例：分析師可以看到自己部門員工的薪資欄位，但不能看到其他部門的 — 欄位過濾器排除非授權部門的薪資，資料列過濾器則限定在授權部門內。
Athena, Spectrum, EMR 如何遵循這些篩選器
Athena 和 Redshift Spectrum 與 Lake Formation 原生整合 — 它們會詢問 Lake Formation 呼叫身份可以看見哪些欄位和資料列，並在查詢計畫階段套用篩選器。EMR Spark 整合則需要將 EMR 叢集組態為使用 Lake Formation EMR 安全組態。Glue 作業在使用具備 Lake Formation 授權的作業角色執行時也會遵循 Lake Formation。
跨帳戶資料共享
跨 AWS 帳戶共享目錄資源是頻繁出現的考試主題。
資源連結 (Resource Links)
資源連結是取用者帳戶中指向生產者帳戶內資料庫或資料表的指標。取用者帳戶的委託人在自己的目錄中看到該資源連結；透過連結進行的查詢會路由到生產者帳戶中底層的共享資源。資源連結模式意味著取用者無需切換帳戶或擔任跨帳戶角色即可查詢共享資料。
AWS RAM 整合
Lake Formation 跨帳戶共享在底層使用 AWS Resource Access Manager (RAM)。生產者為資料庫或資料表建立 RAM 共享並邀請取用者帳戶或組織。取用者接受邀請，然後建立指向共享資源的資源連結。如果沒有 RAM，就沒有跨帳戶共享；單憑資源連結是不夠的。
使用 LF-Tags 進行跨帳戶共享
基於 LF-Tag 的授權可以跨帳戶進行：「將 SELECT 權限授予取用者帳戶財務角色，針對所有標記為 Department=Finance 的資源」。取用者帳戶建立資源連結並透過其進行查詢。此模式可擴展到橫跨數十個帳戶共享的數千張表，而個別的資料表級別授權在這種情況下將無法管理。
跨帳戶 S3 與 KMS
持有資料的 S3 儲存貯體必須透過儲存貯體政策允許取用者帳戶存取。如果儲存貯體使用了 SSE-KMS 加密，KMS 金鑰政策必須對取用者帳戶授予解密 (decrypt) 權限。如果沒有這兩項底層組態，Lake Formation 跨帳戶共享將靜默失敗，並出現難以診斷的權限錯誤。
Lake Formation 對比 IAM — 何時使用
DEA-C01 考試中的關鍵區分。
僅限 IAM 用於粗粒度存取
IAM 適用於粗略的邊界：哪些 AWS 帳戶可以觸達資料湖、哪些 IAM 角色可以擔任特定的服務角色、哪些網路委託人可以使用哪些 VPC 端點。IAM 可以授予儲存貯體前置詞上的 s3:GetObject、目錄上的 glue:GetTable、用於執行查詢的 athena:StartQueryExecution。對於需求簡單的組織，僅使用 IAM 就足夠了。
Lake Formation 用於細粒度與集中化
當資料湖需要欄位或資料列級別的安全性、當權限管理必須橫跨數百張表集中化、當跨帳戶共享需要具備目錄意識的存取、或者當需要 LF-Tags 進行擴展時，Lake Formation 是合適的選擇。Lake Formation 並非取代 IAM — 它是在其之上增加了一個更細粒度的治理層。
混合模式 — IAMAllowedPrincipals
目錄物件上預設的 IAMAllowedPrincipals 設定意味著 Lake Formation 回退到該物件的 IAM 權限 — Lake Formation 是「透明」的且 IAM 規則適用。移除 IAMAllowedPrincipals 即可啟用 Lake Formation 嚴格模式，此時需要 Lake Formation 授權。大多數組織會逐步遷移：對舊表保留 IAMAllowedPrincipals，對新的敏感表啟用嚴格模式，最終遷移所有資料表。
Glue 資料目錄與 Lake Formation 的常見考試陷阱
DEA-C01 考試設置了一套一致的陷阱。請記住這六個。
陷阱 1 — 只有 IAM S3 允許而無 Lake Formation 授權會失敗
情境描述了 IAM 在 Lake Formation 註冊的儲存貯體上授予了 s3:GetObject 權限，但查詢失敗。答案：Lake Formation 同樣需要在資料表上授予 SELECT 權限；兩層都必須允許。
陷阱 2 — 只有 Lake Formation 授權而無 S3 存取權限會失敗
反之亦然：Lake Formation 授予了 SELECT 權限，但底層 S3 儲存貯體政策拒絕存取。答案：在 Lake Formation 中註冊 S3 位置，以便 Lake Formation 可以發放短期 S3 認證，或直接在 S3 上授予 IAM 角色存取權。
陷阱 3 — 跨帳戶無資源連結
情境描述將資料庫共享給另一個帳戶，但取用者找不到它。答案：取用者必須接受 AWS RAM 共享，並在自己的目錄中建立資源連結。
陷阱 4 — 混淆 Schema Registry 與目錄
情境描述了 Avro 串流訊息並詢問結構描述儲存在哪裡。錯誤答案：Glue 資料目錄。正確答案：Glue Schema Registry。它們是獨立的組件。
陷阱 5 — 爬蟲建立了多張資料表
情境描述爬蟲為本應是一張表的內容建立了 50 張表。答案：在爬蟲設定中組態資料表層級分組。
陷阱 6 — 為了擴展而選擇 LF-Tags 而非直接授權
情境描述了一個擁有 5000 張表的目錄並詢問如何管理權限。答案：LF-Tags。直接的資料表授權在超過幾百張後就無法擴展。
陷阱 7 — Lake Formation 不負責加密
考生假設 Lake Formation 會加密資料。錯誤。Lake Formation 負責治理存取；加密則是在 S3（使用 SSE-KMS）和 Glue 目錄（用於目錄中繼資料的 KMS 金鑰）上單獨組態的。
對於擁有超過幾百張表或超過少數取用委託人的資料湖，請使用 Lake Formation 基於標記的存取控制 (LF-TBAC) 而非直接的表級或欄位級授權 — LF-Tags 隨不同政策模式的數量線性擴展，而非隨表數量擴展。 定義一組小型的標記鍵（Department, Sensitivity, DataDomain），為每張表貼上適當的值，並針對標記組合授予權限，而非個別資源。新表在被正確標記後會自動繼承政策。對 5000 張表進行直接授權會產生數千條難以稽核的授權記錄；而 LF-Tags 則產生數十條能與組織政策清晰對應的授權記錄。DEA-C01 考試會設置擴展情境，此時 LF-Tags 是唯一正確答案。
關鍵數字與必須記住的目錄及 Lake Formation 事實
Glue 資料目錄
- 預設每個 AWS 帳戶每個區域一個目錄
- 目錄層次結構：目錄 → 資料庫 → 資料表 → 分區
- 每張表最多 1,000 萬個分區
- 原生支援 Iceberg 表，類型為 ICEBERG_TABLE
- 爬蟲建立表、更新分區並推斷結構描述
Glue Schema Registry
- 支援 Avro, JSON Schema, Protobuf
- 相容性模式：NONE, BACKWARD, FORWARD, FULL（及其 _ALL 變體）
- 與 Glue 資料目錄分離
- 被 Kafka, Kinesis, MSK 的生產者和取用者使用
Lake Formation 權限
- 資料庫、資料表、欄位、資料列、單元格級別授權
- 用於資料列級安全性的資料篩選器（SQL 布林表達式）
- 用於擴展權限的 LF-Tags（基於鍵值屬性）
IAMAllowedPrincipals預設用於透明的 IAM 透傳- 嚴格模式需要顯式的 Lake Formation 授權
跨帳戶共享
- 底層使用 AWS RAM
- 取用者帳戶目錄中的資源連結
- LF-Tag 授權支援跨帳戶運作
- 底層 S3 儲存貯體政策必須允許取用者帳戶
- KMS 金鑰政策必須向取用者帳戶授予解密權限
兩層存取模型
- IAM 與 S3 儲存貯體政策（粗粒度邊界）
- Lake Formation 授權（細粒度治理）
- 兩者均須允許操作方可成功
- 衝突時預設為拒絕
DEA-C01 考試優先事項 — Glue 資料目錄與 Lake Formation。 此主題在 DEA-C01 考試中佔有很大權重。掌握每種 AWS 服務公開的權衡、決策邊界以及成本/效能觸發因素 — 考試將測試那些取決於了解哪種服務是錯誤答案的情境，而不僅僅是哪種是正確答案。
必須記住的關鍵事實。 牢記與此主題相關的服務層級限制、預設行為和 SLA 承諾。考試經常測試對特定預設值（持續時間、限制、重試行為、免費方案邊界）的記憶，記住確切數字往往是「正確」與「幾乎正確」之間的區別。
FAQ — Glue 資料目錄與 Lake Formation 常見問題
Q1 — 我該何時使用 Glue 資料目錄，何時使用 Lake Formation？
Glue 資料目錄是必需的 — 每個 AWS 分析服務都使用它。Lake Formation 是坐落在目錄之上的治理層，當你需要細粒度存取控制（欄位或資料列級別）、集中化權限管理、具備目錄意識的跨帳戶資料共享，或者需要 LF-Tags 來擴展權限時，才需要它。存取要求簡單的小型資料湖可以僅依靠 Glue 資料目錄搭配 IAM 和 S3 儲存貯體政策執行。擁有敏感資料且取用者眾多的大型資料湖則會從 Lake Formation 中獲益。決策關鍵不是「二選一」，而是「在目錄之外，我是否還需要 Lake Formation」。
Q2 — 如何將資料庫從一個 AWS 帳戶共享到另一個帳戶？
共有三個步驟。首先，在生產者帳戶中，使用 Lake Formation 將資料庫（或特定資料表、LF-Tags）授權給取用者帳戶委託人。Lake Formation 在底層會建立一個 AWS RAM 資源共享。第二步，在取用者帳戶中，接受 RAM 資源共享邀請。第三步，在取用者帳戶中，在其 Glue 資料目錄中建立一個指向共享資料庫的資源連結 (resource link)。取用者帳戶的委託人隨後即可透過資源連結進行查詢，就像它是本地資料庫一樣。底層 S3 儲存貯體政策也必須允許取用者帳戶存取，且如果啟用了加密，KMS 金鑰政策必須授予解密權限。
Q3 — 為什麼我的使用者擁有 Lake Formation SELECT 權限，但 Athena 卻顯示存取遭拒？
可能由三個原因引起。第一，S3 位置未在 Lake Formation 中註冊，因此 Lake Formation 無法發放短期 S3 認證，使用者的 IAM 身份會直接針對 S3 進行檢查 — 由於儲存貯體政策具有限制性，IAM 拒絕了存取。第二，註冊位置時使用的 IAM 角色不正確，缺乏 S3 存取權限。第三，S3 儲存貯體上的 KMS 金鑰未授予使用者角色解密權限。修正路徑：檢查 Lake Formation 授權、檢查已註冊位置及其 IAM 角色、檢查 S3 儲存貯體政策、檢查 KMS 金鑰政策。所有四項必須一致。
Q4 — Glue 資料目錄與 Glue Schema Registry 有什麼區別？
Glue 資料目錄 存儲用於分析服務的資料表中繼資料 — 欄位名稱、類型、分區鍵、S3 路徑。Athena, EMR, Redshift Spectrum, Glue ETL 均從中讀取。Glue Schema Registry 存儲用於串流資料的結構描述 — Avro, JSON Schema, Protobuf — 被 Kafka 和 Kinesis 生產者及取用者使用，具備防止破壞性更改的相容性規則。它們是 Glue 服務內部的獨立組件。混淆兩者是常見的考試陷阱：關於「Athena 資料表在哪裡」的問題選目錄；關於「Kafka 結構描述在哪裡」的問題選 Schema Registry。
Q5 — Glue 爬蟲的分區處理如何運作，為什麼有時會建立多張資料表？
爬蟲掃描 S3 前置詞，推斷結構描述，並根據目錄結構和檔案相似性將檔案分組到表中。預設情況下，爬蟲會為其遇到的每個不同結構描述建立一張表。如果前置詞下的子目錄具有不同的檔案結構（欄位不同、分區不同），爬蟲會建立多張表。請在爬蟲的分組組態中組態 資料表層級分組 (TableLevel 參數) — 設定到你希望將所有子目錄歸為一張表的那個路徑深度。經典的反模式：爬蟲掃描 s3://bucket/events/ 且每個服務都有子目錄，爬蟲為每個服務建立了表，而意圖是所有事件共用一張表；將 TableLevel 設定為 2 即可修復。
Q6 — LF-Tags 如何擴展 Lake Formation 權限？
如果沒有 LF-Tags，你需要為每個委託人分別授予每張表、每個欄位和每個資料列篩選器的 SELECT 權限 — 對於 10 個委託人橫跨 1000 張表，那就是 10,000 條授權記錄。有了 LF-Tags，你只需為每張表貼上少量的屬性值（Department=Finance, Sensitivity=Public），並針對標記組合授予權限（「將 SELECT 權限授予財務角色，針對 Department=Finance 的資源」）。現在 10 個委託人加上 3 個各具 2 個值的標記鍵只需產生 60 條授權，而非 10,000 條。正確標記的新表會自動繼承現有權限。LF-Tags 是在大規模目錄中管理權限的唯一實際方法，也是將技術權限與組織政策清晰對應的唯一途徑。
Q7 — 如何組態 Lake Formation 嚴格模式與 IAMAllowedPrincipals？
目錄物件上的 IAMAllowedPrincipals 設定意味著 Lake Formation 回退到 IAM 權限 — 它是「透明的」，且現有的基於 IAM 的存取有效。要強制執行 Lake Formation 嚴格模式，需從資源（資料庫或資料表）中移除 IAMAllowedPrincipals，並為適當的委託人授予顯式的 Lake Formation 權限。使用欄位、資料列或單元格級別過濾需要嚴格模式 — 這些功能沒有 IAM 等效項。大多數組織對舊目錄保留 IAMAllowedPrincipals，對新的敏感資料集啟用嚴格模式，並逐步遷移。在未先授予 Lake Formation 權限的情況下進入嚴格模式會破壞所有人的現有存取 — 務必先授權，再移除 IAMAllowedPrincipals。
延伸閱讀 — 官方 AWS 文件
權威的 AWS 來源包括 Glue 開發人員指南中關於資料目錄組件、Schema Registry（概述、入門、相容性模式）和爬蟲（組態、分類器、排除模式）的章節。Lake Formation 開發人員指南涵蓋了 Lake Formation 定義、權限概述、基於標記的存取控制、跨帳戶資料共享、用於資料列及單元格級安全性的資料篩選器以及已註冊位置。
AWS 大數據部落格有多篇關於 Lake Formation 遷移模式、LF-Tag 採納策略和跨帳戶資料網格 (data mesh) 架構的深度探討文章。AWS Well-Architected Analytics Lens 涵蓋了治理和存取控制模式。SageMaker Unified Studio 文件描述了 Lake Formation 如何作為 SageMaker 功能存取的治理骨幹。最後，AWS 安全性部落格有關於結合 Lake Formation 與 IAM Access Analyzer 來識別目錄和 S3 資源上非預期跨帳戶存取的文章。