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 儲存服務和資料庫引擎如何在現代資料平台中支援大規模資料擷取、持久性封存、查詢效能和安全治理。資料工程師在將 S3、Lake Formation、Redshift 和 DynamoDB 等服務整合到管線中時，必須在成本、存取延遲、持久性以及精細的存取控制之間取得平衡。了解儲存類別的權衡取捨、生命週期自動化、受管儲存與本機儲存的差異，以及分割模式，可以避免在生產環境中出現效能和成本上的意外。

Amazon S3 儲存類別與生命週期原則

S3 提供多種儲存類別和生命週期控制，以優化成本和存取模式。您可以在上傳時設定儲存類別（透過主控台或 CLI：aws s3 cp file s3://bucket/key –storage-class INTELLIGENT_TIERING），或使用儲存貯體生命週期規則（aws s3api put-bucket-lifecycle-configuration –bucket my-bucket –lifecycle-configuration file://lifecycle.json）。Intelligent-Tiering 會自動在頻繁存取和不頻繁存取層之間移動物件，並收取小額的監控費用；針對未知或變動的存取模式，建議啟用此功能。使用生命週期規則可將物件轉換到 GLACIER 或 DEEP_ARCHIVE 以進行長期保留，並使舊版本過期/刪除。

決策標準與權衡取捨：

• Intelligent-Tiering：對於變動存取，營運開銷低，但每個物件有月度監控費用；當存取模式無法預測時是最佳選擇。
• Glacier vs Glacier Deep Archive：Glacier 提供更快的標準和加速擷取選項，但儲存成本較高；Deep Archive 對於長達數年的保留，成本最低，但其批次/標準擷取時間以小時計。
• Standard-IA vs Intelligent-Tiering：Standard-IA 有 30 天的最低費用和擷取費——應避免用於頻繁存取的資料或生命週期短的物件。

操作注意事項：

• 啟用版本控制（aws s3api put-bucket-versioning –bucket my-bucket –versioning-configuration Status=Enabled）和物件鎖定（aws s3api put-object-lock-configuration –bucket my-bucket –object-lock-configuration file://lock.json）以實現不可變性；啟用 MFA Delete 需要特殊的 CLI 操作以及具備 MFA 的儲存貯體擁有者帳戶。
• 生命週期轉換適用於物件版本，且可依前綴/標籤限定範圍；使用 abort-incomplete-multipart-upload 來避免儲存空間洩漏。

使用 S3 和 Lake Formation 設計資料湖

將 S3 作為中央物件儲存來設計資料湖，並使用 Lake Formation 進行集中式存取控制和目錄製作。將 S3 位置註冊為 Lake Formation 資源，設定一個 AWS Glue Data Catalog，並對資料庫/資料表使用 Lake Formation 授權（aws lakeformation grant-permissions –principal arn:aws:iam::123456789012:user/analyst –permissions SELECT –resource ‘{…}’）。Lake Formation 可以強制執行精細控制：欄層級、列層級（篩選表達式），以及使用應用於 Glue/Athena 查詢的 LF-tags 和資料篩選器來進行儲存格層級的遮罩。

關鍵設定與治理模式：

• 註冊位置：使用 Lake Formation 主控台註冊 s3://bucket/path，並附加一個允許 Lake Formation 爬取/讀取的 IAM 角色。
• 精細原則：定義 LF-tags 並將其附加到資料表/欄；使用 column-list 授權以限制欄位，並使用列篩選表達式來限制為某個 principal 回傳的資料列。
• 請記住，對於 Glue/Athena 的存取，Lake Formation 權限可以覆寫或阻擋 IAM S3 權限——在需要時，應同時授予 Lake Formation 和 S3 層級的存取權限。

決策要點：

• 當您需要集中式目錄製作、LF-tags 以及跨多個分析引擎的精細強制執行時，請使用 Lake Formation。
• 對於簡單的存取控制或外部工具存取，可考慮使用 S3 儲存貯體原則和 IAM，但請注意：受 Lake Formation 治理的分析引擎可能會忽略僅限 IAM 的授權。

Amazon Redshift 架構與儲存

Redshift 在 RA3 節點上將運算和受管儲存分離，這與使用本機 SSD 支援的 DS2 節點不同。RA3 節點使用 Redshift Managed Storage (RMS)，其中資料存放在由叢集管理的 Amazon S3 上；選擇 RA3 以獲得可擴展的儲存和一致的查詢效能，並能夠分開支付運算費用。DS2 節點將資料儲存在執行個體本機磁碟上，當資料增長時需要仔細規劃大小和調整大小。

設定與操作細節：

• 透過主控台或 CLI 建立 RA3 叢集：aws redshift create-cluster –cluster-identifier my-cluster –node-type ra3.xlplus –number-of-nodes 2 –master-username admin –master-user-password Passw0rd。
• COPY 命令：必須在附加了授予 S3 讀取權限的 IAM 角色的叢集下執行。在建立叢集時附加角色，或修改叢集以新增 iam roles；角色 ARN (arn:aws:iam::acct:role/RedshiftS3Role) 在 COPY 中被引用為 credentials ‘aws_iam_role=arn:…’。
• 監控 WLM 佇列、短查詢加速、自動 vacuum，並使用 SORT/ENCODE 來優化儲存和效能。

比較 (RA3 vs DS2):

• RA3：解耦的儲存、自動將資料分層到 S3、較低的儲存管理負擔、最適合不斷增長的資料集。
• DS2：本機 SSD 儲存、本機資料的延遲較低，但容量有限且難以擴展。

DynamoDB 與針對特定用途的資料庫選擇

若要處理需要個位數毫秒延遲的高擴展性鍵值 (key-value) 與文件 (document) 工作負載，請選擇 DynamoDB。資料表的設計取決於分割區索引鍵 (partition key)（以及可選的排序索引鍵 (sort key)）的選擇：使用高基數 (high-cardinality)、分佈均勻的索引鍵以避免熱分割區 (hot partition)。對於循序或基於時間戳的索引鍵，請實作隨機前綴（分片）或使用 UUID 來分散寫入。使用隨需容量 (on-demand capacity) 以避免佈建，但對於可預測的工作負載，可考慮使用具備自動擴展功能的預置容量 (provisioned capacity)，並利用適應性容量 (adaptive capacity) 處理熱分割區。

實務設定注意事項：

• 建立資料表的 CLI 指令：aws dynamodb create-table –table-name Events –attribute-definitions AttributeName=pk,AttributeType=S AttributeName=sk,AttributeType=S –key-schema AttributeName=pk,KeyType=HASH AttributeName=sk,KeyType=RANGE –billing-mode PAY_PER_REQUEST。
• 使用 GSI 來支援替代存取模式，啟用 TTL 進行自動過期，並使用 DynamoDB Streams + Lambda 實作變更資料擷取 (change-data-capture) 模式。
• 對於讀取密集型的工作負載，可加入 DAX 進行快取；對於複雜查詢或關聯式需求，則根據查詢複雜度和一致性需求選擇 Aurora 或 Redshift Spectrum。

引擎選擇的決策標準：

• 使用 DynamoDB 處理可預測的單一資料表存取模式，以及需要大規模且低延遲的場景。
• 使用 Redshift 進行複雜的分析與大規模的 OLAP。
• 使用 Aurora 處理交易型關聯式工作負載。

常見陷阱與決策標準

• 對於頻繁存取的資料使用 S3 Standard-IA — Standard-IA 有最低 30 天的費用；對於生命週期短或頻繁存取的物件，應使用 Standard 或 Intelligent-Tiering。
• 忘記 Lake Formation 的權限會覆寫 Glue/Athena 的 IAM S3 權限 — 當使用 Glue/Athena 時，需同時授予 Lake Formation 和 S3 的存取權限，並在 Lake Formation 主控台中驗證有效權限。
• Redshift COPY 指令需要一個附加到叢集的 IAM 角色，而不僅僅是使用者權限 — 將一個具備 S3 存取權的 IAM 角色附加到叢集，並在 COPY 操作中引用其 ARN。
• 因循序索引鍵造成的 DynamoDB 熱分割區 — 避免使用單調遞增/遞減的索引鍵；改用雜湊鍵、隨機前綴或 UUID，並考慮使用隨需容量或具備自動擴展的預置容量。
• 不正確地啟用 S3 Object Lock 和 MFA Delete — 物件鎖定需要啟用版本控制和適當的權限；MFA Delete 只能由儲存貯體擁有者使用 CLI 搭配 MFA 啟用/停用，且有嚴格的要求。
• 未經測試擷取成本和時間就進行不當的生命週期轉換 — 應先測試 Glacier 等級的擷取工作流程，以避免預期外的擷取延遲和費用。

實務問題：使用案例情境

Acme Media 公司必須儲存 50 TB 的原始影片擷取資料，提供分析師查詢轉換後的中繼資料，並為不同業務單位強制執行資料列層級 (row-level) 和資料欄層級 (column-level) 的存取控制，同時將儲存成本降至最低。

1. 使用分段上傳 (multipart upload) 將原始影片擷取到 S3，依擷取日期和資料集為物件加上標籤，並對初始存取模式未知的資料使用 Intelligent-Tiering。
2. 設定生命週期規則，在可設定的保留期後將媒體轉換至 GLACIER 或 DEEP_ARCHIVE（若考慮使用 Standard-IA，需確保符合其 30 天以上的儲存要求）。
3. 在 Lake Formation 中註冊 S3 位置，建立 Glue 爬蟲程式 (crawler) 來填充資料目錄 (Data Catalog)，並授予各業務單位基於 LF-tag 的資料列和資料欄層級權限。
4. 將整理過的中繼資料儲存在 Redshift RA3 中以供分析；將一個 IAM 角色附加到叢集以執行從 S3 的 COPY 操作，並在維護時段使用 VACUUM/ANALYZE 操作。
5. 使用 DynamoDB 搭配雜湊 UUID 鍵作為高吞吐量的影片資訊清單查詢表，並啟用隨需容量以吸收流量高峰。

理由：此方法透過 Glacier 等級隔離了冷儲存成本，使用 Intelligent-Tiering 處理未知的存取模式，應用 Lake Formation 在各種分析引擎間實現安全、精細的存取控制，並選擇 RA3 作為可擴展的分析儲存，同時由 DynamoDB 處理低延遲的操作查詢。

← 數據攝取與收集 · 所有領域 · 數據編目與中繼資料管理 →

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

瀏覽 Amazon →