ML 資料擷取與儲存模式是每個成功 ML 專案中最不顯眼、卻至關重要的一半——模型的好壞完全取決於餵進去的 pipeline，而在 MLA-C01 考試中，Domain 1 約三分之一的題目都落在這個範圍。MLA-C01（Machine Learning Engineer Associate）是一張工程師考試，不是資料科學考試，因此題目問的不是「哪種特徵縮放方法最好」，而是「你的團隊有 50 TB 訓練資料放在地端 NetApp 文件伺服器，SageMaker 訓練任務需要在週五前把它放進 S3——選出正確的擷取服務並給出吞吐量」。本指南從工程師角度完整涵蓋全部流程。
我們將涵蓋：每個 SageMaker 訓練任務都預設的 S3-as-data-lake 基礎、批次與串流擷取服務及各自的正確使用時機、讓多團隊資料湖不陷入混亂的 Lake Formation 與 Glue Data Catalog 治理平面、改變超大型訓練任務計算成本的高吞吐量共享儲存選項（FSx for Lustre 和 EFS），以及考試喜歡混入排序和配對題的跨帳號與跨 Region 模式。讀完之後，你應該能看到「1 PB 點擊流資料在 Snowflake，需要即時推薦，必須每小時訓練」這樣的考題幹，直接得出答案涉及 Kinesis Data Streams、Glue streaming ETL、Feature Store 線上與離線，以及批次再訓練路徑使用 SageMaker File mode。
MLA-C01 情境下的 ML 資料擷取是什麼
MLA-C01 中的資料擷取，是把資料從系統記錄來源（作業資料庫、SaaS API、IoT 裝置、日誌串流、地端資料倉儲）搬移到儲存層的學問，讓 SageMaker 訓練任務和推論端點能以低成本、可重複、完整追溯的方式使用資料。這比 ETL 更廣——它包含儲存架構選擇（S3 前綴佈局、檔案格式、分區方式）、資料目錄（Glue Data Catalog 作為中繼資料骨幹）以及治理平面（Lake Formation 權限、KMS 加密、VPC endpoints）。
為何儲存架構決策要在第一個模型之前就做好
一個常見的新手錯誤是把擷取和儲存當作「留到模型在 notebook 範例上跑通之後再說」的管路工程。等到模型好了、想擴展到完整資料的時候，才發現 S3 前綴佈局讓平行讀取根本不可能、檔案格式觸發 Spark task skew、VPC 沒有 S3 endpoint 導致每次訓練都走 NAT 付出口費，以及資料被複製到四個 bucket 卻沒有一個是標準版本。MLA-C01 的題目就是針對這些問題設計的——「你的團隊訓練任務跑了 12 小時；怎麼縮短到 2 小時」通常答案在擷取與儲存，而不在模型架構。
考試測驗擷取的三件事
第一是服務選擇——給定延遲、資料量和頻率的描述，從 AWS 工具箱中選出正確的擷取服務（Kinesis Data Streams、Kinesis Firehose、Glue、DMS、Snowball、Direct Connect、Transfer Family）。第二是儲存位置——選出正確的 S3 儲存類別、正確的跨帳號存取模式，以及正確的 SageMaker 訓練共享儲存選項。第三是故障模式認識——了解各種陷阱（Firehose 緩衝延遲、FSx for Lustre vs EFS 延遲、Pipe mode 不支援某些演算法），這些都會讓看似合理的答案變成錯誤答案。
白話文解釋 ML Data Ingestion and Storage
ML 資料擷取是一個六個 AWS 服務搶同一個段落的主題。三個具體類比能讓結構清晰易懂。
類比一：便利超商的冷鏈物流與後場冰箱
把一間忙碌的便利超商（你的 SageMaker 訓練任務）想像成每天需要新鮮食材（訓練資料）的廚房。後場的大型冷藏庫就是 Amazon S3——容量大、每公斤成本低、是每位師傅都能取用的共享資料來源。冷藏庫有按年、月、日分類的貨架（S3 前綴），讓備料人員能快速找到對的批次。部分食材由每天清晨四點固定到貨的卡車送來（批次擷取，透過 Glue 或 Snowball）——定時、可預測的配送。其他食材則是每分鐘從樓上水耕蔬菜園持續透過輸送帶送達（串流擷取，透過 Kinesis Data Streams）——連續、低延遲、單次量小。那個把輸送帶上的貨物緩衝 60 秒再打包送進冷藏庫的調度員就是 Kinesis Firehose——有效率，但會帶來已知的緩衝延遲。用於師傅晚餐時段超高速存取的頂級冷藏展示台（SageMaker 訓練讀取大量資料集）就是 FSx for Lustre——專用的高吞吐量快取，比每次都走回冷藏庫快得多，但維持冷藏的成本也較高。掛在冷藏庫門口、記錄每項食材名稱、供應商、到期日和貨架位置的剪貼板就是 Glue Data Catalog。決定哪位師傅能取用哪些食材的店長（Lake Formation）負責管理存取清單。
類比二：圖書館的典藏與書庫管理
把一座國家研究圖書館（你的資料湖）想像成有八十家分館（成員帳號）持續供書。新書以兩種方式到館：出版商每週大量捐書（批次擷取，透過 Glue jobs 和 Snowball），或每日訂閱期刊郵寄到館（串流擷取，透過 Kinesis）。採編部門對每本入館書核對現有記錄（Glue Crawler 更新 Data Catalog），賦予杜威十進制分類號（schema），再依照借閱頻率放入開架書庫（S3 Standard）或閉架書庫（S3 Glacier Instant Retrieval）。一位寫論文的研究生（你的 ML 訓練任務）需要同時參考幾百本資料——那個裝了高速書車、整天在書庫裡穿梭取書的研究小間就是 FSx for Lustre，而更一般性的共用閱覽座位就是 EFS。決定哪位學者能進入哪個書區的館員（Lake Formation）管理借閱權限。這整套圖書館系統——採編、分類、上架、門禁管制、查詢——就是 AWS 的 ML 用資料湖參考架構。
類比三：醫院檢體流程中心
把一個地區醫療網絡有六十家診所（成員帳號）的中央病理實驗室（你的資料湖）想像一下。檢體以兩種方式到達：每天清晨六點的快遞車（批次擷取），以及需要 60 秒內處理的急件透過氣動傳送管（串流擷取，透過 Kinesis Data Streams）緊急傳送。在將批量傳送管中的檢體緩衝 60 秒再轉送實驗室的接收台就是 Kinesis Firehose。存放十年份檢體在攝氏零下 80 度的冷鏈倉庫就是 S3 Glacier Deep Archive。放著今天早上檢體的活性實驗台冰箱就是 S3 Standard。為研究計畫同時處理幾百份檢體的高速離心機（SageMaker 訓練）從臨時平行文件系統讀取資料——那就是 FSx for Lustre，只在研究期間從 S3 水化，結束後釋放。記錄每份檢體來源、類型、採集時間和儲存位置的條碼系統就是 Glue Data Catalog。決定哪位研究者能申請哪些檢體的 HIPAA 主管就是 Lake Formation。這一切——條碼、冰箱分層、快遞 vs 氣動管、門禁——直接對應到 MLA-C01 的擷取架構。
S3 作為主要 ML 資料存儲
幾乎每道 MLA-C01 擷取題都落在 S3 上。SageMaker 訓練、Feature Store 離線存儲、Ground Truth 標注、Data Wrangler 匯入，以及 Pipelines artifacts 預設都使用 S3。掌握 S3 佈局模式，就能消除一半的考題陷阱面。
ML 的 Bucket 佈局與前綴策略
單一 bucket 給一個團隊沒問題，重要的是內部前綴結構。標準 ML 前綴模式：s3://team-ml-data/<dataset>/<version>/<partition>/data.parquet，其中 <partition> 採 Hive 風格（year=2026/month=05/day=02/），讓 Athena 和 Spark 可以剪枝分區。資料集版本管理放在前綴中，而不是 S3 物件版本管理——物件版本管理是防止誤刪的保護機制，不是訓練集沿革。對於極高請求速率，應避免以時間戳作為前綴開頭，因為 S3 依前綴分區；現代 S3 會自動擴展分區，但對持續 5000+ 請求/秒，雜湊前綴（<hash4>/<dataset>/...）仍有幫助。
檔案格式——Parquet、ORC、JSON、CSV
ML 訓練的預設格式是 Parquet——列式儲存、壓縮、可切割、內嵌 schema，Spark、Athena 和 SageMaker 內建演算法（表格式工作負載）均原生支援。若團隊統一使用 Hive 則用 ORC。CSV 只用於小型資料集或有嚴格互通性需求的情況（Athena 對同一查詢的費用是 CSV 比 Parquet 高 5-10 倍）。巢狀資料使用 JSON Lines。圖像資料集保持 .jpg 或 .png 格式，中繼資料放在 sidecar manifest；音訊保持 .wav 或 .flac；NLP 的文字通常經過 Tokenized + Parquet 處理後再用於訓練。
S3 版本管理 vs 資料集版本管理
S3 物件版本管理防止誤刪和覆寫——每個版本都保留直到生命週期規則到期。這對運維至關重要，但不是訓練集沿革。要達到訓練可重現性——「以完全相同的方式重跑 2026-04-30 的模型」——你需要明確的資料集版本管理，要麼在前綴中（s3://bucket/datasets/clickstream/v17/...），要麼使用 DVC（Data Version Control）這類工具，把指標檔案寫入 Git，將二進位資料存在 S3。SageMaker Pipelines 每次執行都記錄輸入 S3 URI，把 URI 鎖定在版本化前綴上，就能提供可驗證的沿革。
訓練資料集的 S3 儲存類別
熱訓練資料放在 S3 Standard。每月存取一次的資料集降至 S3 Standard-IA（儲存費用較低，每 GB 有取回費）。超過 90 天的封存資料集移至 S3 Glacier Instant Retrieval（毫秒取回，封存定價）或 S3 Glacier Flexible Retrieval（分鐘至小時取回）。7-10 年保留期的合規冷封存使用 S3 Glacier Deep Archive，費用約 $1/TB/月。生命週期政策自動執行層級轉換。
SageMaker 訓練要求資料集能在毫秒內存取——S3 Glacier Flexible 和 Deep Archive 不適合直接作為訓練輸入。 常見的 MLA-C01 陷阱是「我們把去年的訓練資料存到 Glacier Deep Archive 省成本；現在再訓練要花 24 小時才能啟動。」解決方法是將生命週期改為 Glacier Instant Retrieval（毫秒存取，封存定價），或承擔 Glacier Flexible 的還原等待時間和費用。請根據再訓練節奏規劃儲存層——如果每月以最近 12 個月的資料再訓練，就把這 12 個月的資料保持在 Standard 或 Standard-IA，而不是 Glacier。
批次擷取模式
批次擷取是排程性、可預測、高容量的大量傳輸。MLA-C01 測試四種情境。
從 RDS、Redshift、DynamoDB 排程 Glue Jobs
最常見的模式：一個 AWS Glue job 透過 EventBridge 排程每晚執行，連接 JDBC 來源（RDS、Redshift、地端 DB 透過 JDBC 連線），使用謂詞下推讀取，轉換後按日期分區寫入 Parquet 到 S3。Glue 處理連線認證（IAM、Secrets Manager）、schema 探索（Crawler）和平行度（DPUs）。Job bookmarks 追蹤哪些資料列已被讀取，避免重複處理。費用：Standard workers $0.44/DPU-hour。
S3 Transfer Acceleration
從遠端地端位置上傳大型訓練資料集到 S3 時，S3 Transfer Acceleration 把上傳請求透過最近的 CloudFront edge 路由到 AWS 骨幹。適合資料集幾十 GB 且地端到 S3 的路徑走公共網際網路的情況。在標準 S3 定價之上加上每 GB 費用——只在加速效果值得的情況下啟用。
AWS DataSync
從地端 NFS、SMB、HDFS 或其他雲端大量遷移時，AWS DataSync 以最高 10 Gbps 的速度透過網路傳輸 TB 級資料，內建加密和完整性驗證。最適合有 Direct Connect 或 VPN 的情況；沒有專用頻寬時，DataSync 仍然可用，但吞吐量受限於網際網路路徑。
Snowball / Snowmobile 用於 PB 級資料
網路傳輸需要好幾週的初始資料湖 PB 級播種，AWS Snowball Edge（80 TB 堅固型設備）或老款 AWS Snowmobile（100 PB 貨車）以實體運送方式搬運資料。常見 MLA-C01 題幹：「地端有 200 TB 歷史遙測資料，必須在 14 天內擷取，沒有 Direct Connect。」100 Mbps 網路傳輸需要 200 天；Snowball 含運輸往返 14 天完成。費用是每台設備費用加運費，通常每台 Snowball 數千美元。
AWS Database Migration Service (DMS) 用於持續複寫
要把作業資料庫持續複寫到 S3，DMS 做 change-data-capture（CDC）——讀取來源資料庫的交易日誌，將 insert/update/delete 複寫到 S3 為 Parquet。當 ML pipeline 需要關聯式資料的近即時新鮮度，又不想讓來源 DB 承受全表掃描負擔時使用。
需要讓訓練資料與作業資料庫保持同步的 ML pipeline，應選 AWS DMS CDC 模式到 S3，而非排程 Glue jobs。 Glue jobs 做的是每晚快照——你會遺失一整天發生的變更，且每次執行都對來源 DB 造成大量讀取壓力。DMS CDC 持續讀取交易日誌，以秒級延遲增量把 insert/update/delete 套用到 S3，且對來源 DB 的影響僅限於 log reader。MLA-C01 的提示訊號是「最小化對正式資料庫的影響」或「新鮮度在分鐘內」——答案是 DMS，不是 Glue。
串流擷取模式
串流擷取是事件驅動、低延遲、持續性的。MLA-C01 考試測試三個服務及其取捨。
Amazon Kinesis Data Streams (KDS)
KDS 是基礎串流——生產者寫入記錄，消費者（Lambda、Flink、KCL apps）以亞秒延遲讀取。吞吐量以 shard 計量（每 shard 1 MB/s 入、2 MB/s 出）或按需模式。記錄預設保留 24 小時，最多 365 天。對 ML 來說，KDS 是需要即時特徵計算（滑動視窗聚合）或多個消費者讀取同一串流時的正確答案（KDS 透過 enhanced fan-out 支援扇出）。
Amazon Data Firehose
Firehose 是受管傳送串流——生產者寫入記錄，Firehose 緩衝後傳送到 S3、Redshift、OpenSearch 或 HTTP endpoints。緩衝提示：1-15 分鐘，1-128 MB。沒有消費者程式碼；Firehose 處理傳送、分區、格式轉換（JSON 轉 Parquet）和重試。取捨是緩衝延遲——資料落地 S3 最少需要 60 秒。Firehose 是需要低成本把原始事件封存到 S3 且不需要即時處理的正確答案。
Amazon Managed Service for Apache Flink
Flink 是需要有狀態串流處理的正確答案——視窗聚合、session window、兩個串流的 join、exactly-once 語意。對 ML 來說，這是特徵計算：「計算使用者 5 分鐘點擊率」需要在點擊串流上做滑動視窗，這正是 Flink 的原生能力。Flink 從 KDS 或 MSK 讀取，將結果寫到 Feature Store 線上、S3 或另一個 KDS。
KDS vs Firehose 決策
- KDS：需要亞秒延遲、多個消費者、自訂處理邏輯、重播功能。
- Firehose：只需封存到 S3、需要格式轉換、可接受緩衝延遲、不想寫消費者程式碼。
- 兩者並用：KDS 是主串流，Firehose 作為分流管把資料寫到 S3 封存，同時 Flink 做即時處理。
Kinesis Data Firehose 最少有 60 秒的緩衝延遲，它不是即時 pipeline。 把 Firehose 和 Data Streams 搞混的工程師設計「即時詐欺偵測」時用了 Firehose，結果發現至少要等 60 秒才能對交易做出反應。Firehose 緩衝 1-128 MB 或 1-15 分鐘，以先到者為準。需要即時推論（亞秒決策）就要用 KDS 加上消費者（Lambda、Flink 或 KCL app）。MLA-C01 的提示訊號「即時」或「亞秒」或「在顧客離開頁面前做決策」排除了 Firehose；「近即時封存」或「分鐘級批次到 S3」則完全符合 Firehose。
AWS Lake Formation——集中式資料湖治理
Lake Formation 是 Glue Data Catalog 和 S3 之上的存取控制平面。MLA-C01 考試把它當作「多個 ML 團隊如何在不重複和不混亂的情況下共享資料」的答案。
Lake Formation 在 S3 + Glue 之上新增了什麼
S3 bucket policies 和 IAM policies 讓你能在 bucket 和前綴層級授予存取。Lake Formation 在 Glue Data Catalog 表上新增了表格層級、欄位層級、列層級和儲存格層級的權限。資料科學家可以被授予對 users 表的 SELECT 權限，但排除 pii_ssn 欄位（欄位篩選），且只能看到 region = 'US' 的資料列（列篩選）——無需建立自訂視圖，也不需要複製資料。
Lake Formation Tags（LF-Tags）
LF-Tags 把 key-value 中繼資料附加到資料庫、表和欄位；然後基於 tags 而非個別資源授予權限。「擁有 team=ml-platform 和 confidentiality=internal 的人可以讀取此欄位。」這種方式在大型組織中比逐一資源授權更具擴展性。
透過 Lake Formation 跨帳號共享
跨帳號 ML 資料共享時，Lake Formation Resource Links 搭配 AWS Resource Access Manager（RAM）把 Glue catalog 表共享給另一個帳號，而不複製資料。另一帳號建立一個 Resource Link，在外觀上像是一個本地表；底層 S3 讀取仍透過 Lake Formation 的儲存授權層存取來源 bucket。
Glue Data Catalog 與 Schema 演進
Glue Data Catalog 是中繼資料骨幹——每個 Athena 查詢、每個參考表的 SageMaker 訓練任務、每個 Lake Formation 權限都透過 Catalog 解析。
Glue Crawlers
Crawler 掃描 S3 前綴（或 JDBC 來源），從檔案格式推斷 schema，建立或更新 Glue 表定義，並偵測分區。每晚排程一次 Crawler 以抓到新分區和 schema 變更。限制：Crawler 在異質資料（同一前綴下有多個 schema）上可能不穩定——較好的做法是每個表前綴強制使用單一 schema。
Schema 演進模式
- 新增欄位——Crawler 會抓到，下游 Spark 和 Athena 查詢對較舊的分區回傳 null。
- 移除欄位——Crawler 除非你刪除並重跑，否則會保留舊欄位定義；現有查詢可繼續使用但可能回傳 null。
- 重新命名欄位——破壞性變更；把它視為新欄位，並用 Glue ETL job 遷移資料。
- 變更類型——有風險；Athena strict mode 會拒絕，Spark 可能靜默轉型。在推入正式環境前務必測試。
Catalog 作為權限錨點
Glue 表是 Lake Formation 的權限單位。把 catalog 做對，下游的權限授予就能自然流動。做錯了，你會得到一堆 bucket policy 義大利麵。
高吞吐量共享儲存——FSx for Lustre vs EFS
對於跨多個 GPU 讀取同一資料集的超大型訓練任務，S3 讀取吞吐量會成為瓶頸。兩個 AWS 服務以不同方式解決這個問題。
Amazon FSx for Lustre
FSx for Lustre 是專為 HPC 和 ML 工作負載打造的平行文件系統。吞吐量隨佈建容量線性擴展——持久 SSD 每 TiB 200 MB/s，高效能層每 TiB 1 GB/s。FSx for Lustre 與 S3 整合作為資料儲存庫——S3 中的檔案在首次存取時出現在 Lustre 文件系統中（懶載入），或透過批次水化。暖機後讀取延遲低於毫秒。這是大規模分散式訓練（多個 GPU 讀取同一資料集）的正確答案。
Amazon EFS
EFS 是通用 NFS 文件系統，適合共享應用程式存取——適合 SageMaker Studio 主目錄、notebook 協作、多用戶工作流程。延遲為個位數毫秒；吞吐量隨儲存資料擴展（Bursting mode）或按需佈建（Provisioned Throughput mode）。EFS 不是高吞吐量訓練的正確答案——Lustre 在平行讀取上完勝。
決策矩陣
- S3 File mode——小至中型資料集，在訓練開始前複製到執行個體暫存儲存空間。預設，最便宜。
- S3 Pipe mode——訓練期間串流的大型資料集，減少啟動時間。演算法支援有限。
- S3 FastFile mode——透過 FUSE 掛載存取的大型資料集，懶載入。現代預設選項。
- FSx for Lustre——超大型資料集（數百 GB 到 PB），跨多個 GPU 的分散式訓練，對同一資料的反覆訓練執行。
- EFS——共享 notebook 儲存，不適合高吞吐量訓練。
FSx for Lustre 是 SageMaker 訓練的高吞吐量低延遲文件系統；EFS 是 notebook 和協作用的通用共享文件系統。 MLA-C01 的陷阱是把兩者視為可互換——它們不是。Lustre 吞吐量是 200-1000 MB/s/TiB；EFS bursting 是個位數到幾百 MB/s。對於 32 個 GPU 讀取同一 5 TB 資料集的分散式訓練，Lustre 以小時完成訓練，EFS 則需要幾天。考試題幹訊號「超大型資料集、分散式訓練、多個 GPU 讀取同一資料」對應 FSx for Lustre；「共享 notebook 儲存」或「SageMaker Studio 主目錄」對應 EFS。
SageMaker Training Input Modes——File、Pipe、FastFile
SageMaker 訓練任務讀取 S3 資料的機制對成本和延遲有直接影響。
File Mode
預設。SageMaker 在訓練開始前把整個資料集從 S3 複製到執行個體的 EBS 磁碟區。簡單、可預測，但大型資料集啟動很慢——500 GB 資料集在訓練開始前需要 30 分鐘以上複製。複製後磁碟 I/O 是本地執行，速度最快。適合小至中型資料集。
Pipe Mode
SageMaker 透過 Unix FIFO pipe 直接把 S3 的資料串流傳入演算法。訓練立即開始；資料隨演算法讀取而消耗。節省前期複製時間和 EBS 費用。限制：並非所有內建演算法都支援 Pipe mode；XGBoost 和 Linear Learner 支援，但 BlazingText 等可能不支援。自訂容器必須實作 Pipe 協定。
FastFile Mode
現代預設。資料透過 POSIX 相容的 FUSE 掛載暴露；演算法像讀本地檔案一樣讀取，但底層讀取是按需從 S3 串流。支援隨機存取（Pipe 不支援）且支援大多數演算法。幾乎在任何情況下都是現代訓練任務的正確答案。
選擇 Mode
- File mode → 小型資料集，最簡單路徑。
- Pipe mode → 超大型循序讀取資料集，演算法支援。
- FastFile mode → 其他情況的現代預設。
跨帳號與跨 Region 資料存取
多帳號 ML 組織需要受控、可稽核的資料共享。
跨帳號 S3 存取的 IAM Roles
生產者帳號透過 bucket policy 參照消費者帳號 IAM role ARN 授予 S3 存取。消費者的 SageMaker 訓練 role 直接使用授予的權限。KMS 金鑰也必須授予消費者 role kms:Decrypt。透過 aws:SourceArn 和 aws:SourceAccount 條件進行 confused-deputy 防護。
多租戶 Bucket 的 S3 Access Points
S3 Access Points 建立有自己政策的具名端點。一個 bucket 可以有多個 access points，每個都限定在不同的消費者或 VPC。比一個 100 行的 bucket policy 更簡單。
S3 VPC Endpoints
對於在 VPC 模式（無網際網路存取）下執行的 SageMaker 訓練任務，需要 S3 Gateway VPC Endpoint 才能在不離開 VPC 的情況下到達 S3。沒有它，訓練任務無法讀取訓練資料。Endpoint policy 可以限制哪些 bucket 可存取。
跨 Region 複寫
對於多個 Region 都需要的資料集（DR、Regional ML 部署），S3 Cross-Region Replication（CRR）非同步複寫物件。RPO 通常是分鐘級。生命週期和 KMS 金鑰必須按 Region 配置。
ML 資料擷取常見考試陷阱
陷阱一——Firehose 是即時的
錯誤。最少有 60 秒的緩衝延遲。亞秒延遲請使用 KDS。
陷阱二——FSx for Lustre 和 EFS 可互換
錯誤。Lustre 是高吞吐量平行文件系統；EFS 是通用 NFS。分散式訓練用 Lustre。
陷阱三——Glacier Deep Archive 用於活躍訓練資料
錯誤。還原時間需要數小時。若需要封存定價，使用 Glacier Instant Retrieval。
陷阱四——Pipe Mode 適用於所有演算法
錯誤。某些內建演算法（BlazingText 特定模式、Object2Vec）不支援 Pipe。FastFile 相容性更廣。
陷阱五——S3 物件版本管理就是資料集版本管理
錯誤。物件版本管理是防刪保護；資料集版本管理是可重現性。使用前綴版本管理或 DVC。
陷阱六——跨帳號 S3 存取不需要 KMS 授予
錯誤。啟用 SSE-KMS 時，僅靠 bucket policy 不夠。消費者 role 也需要在生產者 KMS 金鑰上取得 kms:Decrypt。
陷阱七——DataSync 用於 PB 級遷移
效率不高。以 10 Gbps DataSync 移動 1 PB 需要約 10 天；Snowball 實體運送在這種規模更快。
擷取決策矩陣——使用案例對應服務
| 使用案例 | 正確答案 | 錯誤答案陷阱 |
|---|---|---|
| 即時詐欺偵測（亞秒） | Kinesis Data Streams + Lambda | Firehose（緩衝延遲） |
| 每晚從 RDS 刷新訓練資料 | Glue ETL + bookmarks，或 DMS CDC | Athena Federated Query |
| 14 天內遷移 200 TB 地端資料 | Snowball Edge | DataSync 走公共網際網路 |
| 持續複寫 DB 到 S3 | DMS CDC 模式 | 排程 Glue 快照 |
| 串流封存到 S3（可接受延遲） | Firehose 到 S3 | KDS 沒有消費者 |
| 分散式訓練，5 TB 資料集，32 個 GPU | FSx for Lustre | EFS |
| SageMaker Studio 共享 notebook | EFS | FSx for Lustre |
| 合規封存，7 年保留 | S3 Glacier Deep Archive + Object Lock | Glacier Flexible 無鎖定 |
MLA-C01 必記數字
- Kinesis Data Streams shard：1 MB/s 入、2 MB/s 出、1000 records/s
- Firehose 緩衝：最少 60 秒，1-128 MB
- FSx for Lustre 吞吐量：持久 SSD 200 MB/s/TiB，最高 1 GB/s/TiB
- S3 Glacier Deep Archive：$1/TB/月，12-48 小時取回
- S3 Glacier Instant Retrieval：封存定價，毫秒取回
- Snowball Edge 容量：每台 80 TB 可用
- Glue DPU：4 vCPU + 16 GB 記憶體，Standard $0.44/DPU-hour
MLA-C01 exam priority — ML 資料擷取與儲存模式 — MLA-C01 ML Engineer 學習筆記. This topic carries weight on the MLA-C01 exam. Master the trade-offs, decision boundaries, and the cost/performance triggers each AWS service exposes — the exam will test scenarios that hinge on knowing which service is the wrong answer, not just which is right.
Definition — ML 資料擷取與儲存模式 — MLA-C01 ML Engineer 學習筆記. This MLA-C01 topic covers a domain-specific AWS service or pattern. Confirm the canonical definition from official AWS documentation before relying on third-party summaries — service names and feature scoping have shifted over time.
常見問題——ML 資料擷取與儲存熱門問題
Q1——我們地端有 50 TB 的歷史點擊流資料，需要在週五前放進 S3 進行模型再訓練。網路是 100 Mbps 共享。正確的擷取路徑是什麼？
以 100 Mbps 共享（假設有效 40 Mbps），50 TB 需要超過 100 天——完全行不通。正確答案是 AWS Snowball Edge，實體運送一台 80 TB 設備到你的資料中心；你在本地以 10 Gbps 速度載入，運回後 AWS 匯入 S3。端到端包含運輸約 7-10 天。DataSync 也會因為頻寬限制而失敗。Direct Connect 需要好幾週才能開通，而且除非升級，否則 100 Mbps 仍然是瓶頸。MLA-C01 題幹訊號「數十 TB 以上、有限頻寬、幾天到幾週的截止日期」就是 Snowball 的特徵。
Q2——為什麼我的 SageMaker 訓練任務在真正開始訓練前要等 45 分鐘？
最可能的原因是 File mode 搭配大型資料集——SageMaker 在訓練開始前把整個 S3 資料集複製到執行個體的 EBS 磁碟區。500 GB 資料集依執行個體類型和 S3 吞吐量，需要 30-60 分鐘。切換到 FastFile mode（POSIX FUSE 掛載，從 S3 懶載入）作為現代預設，或若你的演算法支援，使用 Pipe mode（XGBoost、Linear Learner、影像分類器）。FastFile 幾乎總是正確答案；演算法看到的是普通檔案路徑，但讀取按需從 S3 串流，訓練在數秒內啟動。
Q3——SageMaker 訓練什麼時候應該選 FSx for Lustre 而不是直接存取 S3？
FSx for Lustre 是正確選擇的條件是：(a) 超大型資料集（數百 GB 到 PB）、(b) 跨多個執行個體讀取同一資料的分散式訓練，以及 (c) 對同一資料集反覆訓練（HPO sweep、多次實驗）。Lustre 文件系統從 S3 水化一次，然後以 200-1000 MB/s/TiB 的速度平行服務多個 GPU 讀取。對於 100 GB 資料集上的單次訓練，S3 搭配 FastFile mode 更簡單便宜——Lustre 的設置開銷和持久儲存費用只有在規模化和重複使用時才划算。MLA-C01 的陷阱是假設 Lustre 總是更快；對小型工作負載，S3 路徑在成本和簡單性上勝出。
Q4——我們的每晚 Glue job 從 RDS 讀取資料，DBA 在抱怨查詢負載。有什麼替代方案？
使用 AWS DMS CDC（change data capture）模式從 RDS 複寫到 S3。DMS 讀取資料庫交易日誌，而不是表本身，所以來源 DB 幾乎不承受查詢負載——只有 log reader 執行緒在運行。CDC 以近即時的方式把 insert/update/delete 串流到 S3 為 Parquet 檔案。這既降低了來源負載，又為 ML 再訓練提供了更新鮮的資料。Glue job 仍然可以後處理 DMS 輸出，但繁重的抽取工作現在是 CDC。MLA-C01 題幹訊號「最小化對正式資料庫的影響」或「DBA 不高興」就是 DMS CDC。
Q5——如何對訓練資料集進行版本管理，以便重現六個月前訓練的模型？
兩種可靠方法。方法一：前綴版本管理——把每個資料集版本寫入唯一 S3 前綴（s3://bucket/datasets/clickstream/v17/），並把 SageMaker 訓練任務的輸入鎖定在那個確切前綴上。簡單、可稽核、不需要額外工具。方法二：DVC（Data Version Control）——DVC 把指標檔案寫入 Git，以內容定址路徑把二進位資料存在 S3，並提供類似 git checkout 的資料版本管理。資料增量演進時更好用。不要單獨依賴 S3 物件版本管理——它防止誤刪，但不提供一流的資料集沿革。SageMaker Pipelines 每次執行都記錄輸入 S3 URI；把 URI 鎖定在版本化前綴上，就有可驗證的訓練可重現性。
Q6——Kinesis Data Streams 和 Kinesis Data Firehose 在 ML pipeline 中有什麼差別？
Kinesis Data Streams（KDS） 是基礎串流——亞秒延遲、多個消費者、支援重播、自訂處理邏輯。用於即時推論觸發、即時更新 Feature Store 線上、詐欺偵測 pipeline。Kinesis Data Firehose 是受管傳送服務——緩衝 1-15 分鐘或 1-128 MB，然後寫入 S3、Redshift、OpenSearch 或 HTTP。沒有消費者程式碼、無重播、最少 60 秒延遲。用於低成本把原始事件封存到 S3、格式轉換（JSON 轉 Parquet）和 ETL 準備。最常見的架構：KDS 作為直播串流有兩個消費者——Flink 做即時特徵計算，Firehose 分流到 S3 做封存。MLA-C01 題幹訊號「即時」排除 Firehose；「封存到 S3」包含 Firehose。
延伸閱讀——官方 AWS 文件
如需超出 MLA-C01 範圍的深度資料，權威的 AWS 來源包括：SageMaker 開發者指南（訓練資料存取章節）、Amazon Kinesis 開發者指南（Data Streams、Data Firehose、Managed Service for Apache Flink）、AWS Glue 開發者指南（Data Catalog、ETL jobs、crawlers）、AWS Lake Formation 開發者指南、Amazon FSx for Lustre 使用者指南（S3 整合）、Amazon S3 使用者指南（儲存類別、生命週期、Object Lock），以及 AWS Well-Architected Framework 的 Machine Learning Lens。AWS Big Data Blog 和 AWS Machine Learning Blog 有多年的客戶擷取架構文章，與 MLA-C01 題幹模式高度吻合。