AWS 資料服務：如何在它們之間做選擇

範圍 —— 資深資料工程面試中 AWS 的「服務選型」題：每個服務負責哪一層，以及如何在功能相近的服務之間選出一個並為它辯護 —— S3 vs EBS vs EFS、RDS vs DynamoDB vs Redshift、Kinesis Data Streams vs Firehose vs MSK、SQS vs SNS vs EventBridge vs Kinesis、Glue vs EMR vs Lambda、Athena vs Redshift、Step Functions vs MWAA vs EventBridge、Glue Data Catalog vs Lake Formation 以及決定資料存取權的各層、每一層要監控什麼與成本由什麼驅動、三個經典架構情境，以及回答「你為什麼選 X？」的結構。Glue、EMR、Iceberg、Athena、從 RDS 取資料、S3 + SQS + Lambda 資料攝取與 S3 檔案布局的深入內容歸 aws_data.md；Kafka 內部機制歸 kafka.md；串流語意歸 stream_pipeline.md。 另見：./aws_data.md —— 這裡每個 Glue、EMR、Athena、Iceberg、RDS、SQS 與 Lambda 答案背後的機制；./kafka.md —— MSK 跑的是什麼；./stream_pipeline.md —— event time、watermark、exactly-once；./sql_vs_nosql.md —— 與引擎無關的資料庫選型；../db/faq_redshift.md —— Redshift 筆記；../faq_DE_interview.md —— 總覽與考前檢查清單。

AWS 幾乎每件工作都有兩三個服務能做，而面試題從來不是「Kinesis 是什麼？」—— 而是 「為什麼用 Kinesis，不用 Firehose 或 MSK？」 所以這份文件依「決策」而不是依「服務」組織： 每一節是一組功能相近的服務、區分它們的表格、決定選哪一個的線索，以及大家對它們常說錯的話。 服務名稱最後再背；先學會每個服務所做的取捨。

0) 一句話回答 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

「S3 就是 data lake；其他一切都是在選擇：資料怎麼進來、怎麼轉換、怎麼查詢、怎麼排程執行。 我依需求來挑 —— 延遲、資料量、誰要消費它、團隊需要多少控制權、維運成本多少 —— 並說明 如果需求改變，我會改用什麼。」

被問到 「你為什麼選服務 X？」 時，用六個步驟回答：

1. 需求（Requirement） —— 限制住這個決定的資料量、延遲、吞吐量與 SLA。
2. 選擇（Choice） —— X 做到了哪件需求所要的事。
3. 替代方案（Alternative） —— 功能相近的服務，以及排除它的那個線索。
4. 取捨（Trade-offs） —— 成本、維運、效能、可靠性。
5. 失敗處理（Failure handling） —— 重試、重複資料、資料遺失、重播（replay）。
6. 監控（Monitoring） —— 哪個指標能說明管線是健康的。

「對於標準的批次 ETL 工作負載，我會選 AWS Glue，因為它提供代管的 Spark 執行環境，並且與 S3 和 Glue Data Catalog 整合；和 EMR 相比，它省去了叢集管理。如果我需要掌控 Spark runtime、 相依套件或叢集設定 —— 或是在規模大到 Spot 價格有意義時 —— 我會把它搬到 EMR。我會用一天 具代表性的資料對兩者做 benchmark，比較執行時間、資源用量與總成本，而不是假設哪個比較快。」

1) 地圖：每個服務負責哪一層 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

 Sources      RDS / Aurora · DynamoDB · SaaS / APIs · application logs · Kafka
                 |
 Ingestion    Kinesis Data Streams · Firehose · MSK · DMS · SQS · AppFlow · Transfer Family
                 |
 Storage      S3 data lake:  raw (bronze)  ->  cleaned (silver)  ->  curated (gold)
                 |
 Processing   Glue ETL · EMR (Spark, Flink, Trino) · Lambda · Athena CTAS
                 |
 Serving      Redshift · Athena · OpenSearch · QuickSight · DynamoDB (lookups)

 Cross-cutting
   orchestration  Step Functions · MWAA (Airflow) · EventBridge (schedules, events)
   catalog        Glue Data Catalog              governance  Lake Formation
   monitoring     CloudWatch · CloudTrail        security    IAM · KMS · Secrets Manager · VPC

下面每一節都是這張圖中「不只一個候選服務」的那一列。只有一個答案的那一層 —— S3 作為 data lake —— 是最該先說的，也是 aws_data.md §8 深入討論的部分。

2) 儲存與資料庫 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

2-1) S3 vs EBS vs EFS vs FSx ★★★★☆優先度 4／5 — 高價值 — 這裡有缺口就會掉關

「S3 是給 data lake 用的物件儲存；EBS 是一台機器的磁碟；EFS 是共享檔案系統；FSx 是我因為 特定理由需要的特定檔案系統。」

S3 是什麼、不是什麼：

• 物件不可變（immutable）。 你只能取代一個物件，不能編輯它 —— 這就是為什麼 Iceberg 這類表格格式 會寫新檔案再切換指標（aws_data.md §4-2）。
• 寫入後的讀取與列舉（list）都是強一致（自 2020 年 12 月起），所以「S3 是最終一致」這個 老說法已經過時。
• 小檔案是經典的失敗模式。 每個檔案都是一次要列舉、開啟、讀取的請求，所以一張由一百萬個 10 KB 檔案組成的表，比同樣資料放在一百個大型 Parquet 檔案裡更貴也更慢；而且請求速率是以 prefix 計（每個 prefix 每秒數千次讀寫），所以單一熱門 prefix 會被限流（aws_data.md §8-2）。
• 儲存層級與 Lifecycle 會把冷資料移到 Infrequent Access 與 Glacier 層；存取模式未知時， Intelligent-Tiering 會逐一物件自動處理。

2-2) OLTP vs NoSQL vs OLAP ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

先說出工作負載的類型；服務自然跟著決定。

2-3) RDS vs DynamoDB ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

設計題的答案是依存取模式切分資料，而不是把所有東西都放進擴展性最好的那個儲存：

• 帳號與付款 —— RDS / Aurora，因為需要交易與 JOIN；
• 依 user id 查 session 與個人資料 —— DynamoDB，因為 key 已知且延遲很重要；
• 完整的事件歷史 —— S3，因為資料量大且只會附加；
• 跨上述全部的分析 —— Athena 或 Redshift。

陷阱。「DynamoDB 擴展性好，所以全部放進去。」一個你沒有為它設計 key 或索引的查詢會變成 整表 scan，一個臨時問題會變成一個匯出作業。決定一切的是資料模型與存取模式，而不是擴展性。

3) 串流資料攝取：Kinesis Data Streams、Firehose 還是 MSK ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

3-1) 各自是什麼

• Kinesis Data Streams（KDS） —— 一個持久、有序的串流。Producer 帶著 partition key 寫入 record，record 在每個 shard 內有序，consumer 依自己的步調讀取，並可在保留期限內重新讀取 （預設 24 小時，可延長到 365 天）。
• Amazon Data Firehose —— 一個代管的**投遞（delivery）**服務。它緩衝收到的 record，再寫到目的地 —— S3、Redshift、OpenSearch、Splunk、HTTP endpoint、Iceberg 表 —— 途中可選擇用 Lambda 轉換， 或轉成 Parquet / ORC。你不用寫 consumer，也無法倒轉重讀。
• Amazon MSK —— 代管的 Apache Kafka（provisioned broker 或 MSK Serverless）。有 topic、 partition、consumer group、Kafka Connect（MSK Connect），以及整個 Kafka client 生態系 （kafka.md）。

3-2) 比較 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

3-3) 怎麼選 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

• 只是要把資料落地到 S3（或 Redshift、OpenSearch）？ → Firehose。 它會批次寫入、可以寫成 Parquet、可依 record 裡的欄位分區，而且不需要寫任何程式。
• 多個 consumer、自己的處理邏輯、需要 replay？ → Kinesis Data Streams，由 Flink （Amazon Managed Service for Apache Flink）、Spark Structured Streaming 或 Lambda 讀取。如果你也想把 原始串流存到 S3，就再加一個 Firehose 當作另一個 consumer。
• 已經在用 Kafka，或需要 Kafka Connect、Kafka 的語意，或能搬離 AWS 的可攜性？ → MSK。

延遲的問題：KDS 的 consumer 在遠低於一秒內就能看到 record（共享吞吐量的輪詢約 200 ms， enhanced fan-out 更低）。Firehose 的延遲來自它的緩衝：當緩衝達到一定大小（1–128 MB）或 時間間隔（0–900 秒）時才寫出 —— 寫到 S3 的預設是 5 MB 或 300 秒 —— 所以 S3 物件是以秒到分鐘 為單位抵達，而不是毫秒。

陷阱：

• 「Firehose 是比較便宜的 Kafka。」 它是一條投遞管線，不是事件平台：沒有 consumer group、沒有 offset、沒有 replay。目的地失敗時它會重試：寫 S3 時一直重試到來源的保留期限用完 —— Direct PUT 是 24 小時，之後資料就遺失；寫 OpenSearch、Splunk 或 HTTP 時重試一段設定的時間，再把失敗的 record 備份到 S3 的錯誤 prefix；寫 Redshift 時則保留已暫存在 S3 的物件，並在 errors/ 底下寫一份被略過 物件的 manifest，由你用 COPY 回補。所以要對投遞本身設告警，而不只是看錯誤 prefix。
• 「Kinesis 和 Kafka 是同一種東西。」 兩者都是有多個 consumer、可 replay 的分區 log，但擴展單位 不同（shard 的吞吐量是固定的；Kafka partition 受限於它所在的 broker），保留期限、consumer API 與生態系也不同。
• 熱點 shard（hot shard）。 低基數的 partition key（國家、常數）會把大部分 record 放到同一個 shard，它被限流（WriteProvisionedThroughputExceeded），其他 shard 卻閒著 —— 這是串流版的資料傾斜。
• 重複資料。 三者都會因 producer 重試與 consumer 重啟而重複投遞；sink 必須是冪等的 （aws_data.md §7-5）。

4) 佇列與事件：SQS、SNS、EventBridge 還是 Kinesis ★★★★☆優先度 4／5 — 高價值 — 這裡有缺口就會掉關

4-1) 四種形狀 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

佇列（queue）把每則訊息交給一個 worker；主題（topic）把它複製給每個訂閱者；事件匯流排（event bus） 依內容路由它；串流（stream）則依序保留它，讓任何人都能讀。

判斷線索：「每個工作由 N 個 worker 之一處理一次」 是 SQS；「每個事件下個月新的 consumer 也能 重讀」 是串流；「S3 物件落地或 Glue job 失敗時，啟動 X」 是 EventBridge。

4-2) 面試官會追問的 SQS 細節 ★★★★☆優先度 4／5 — 高價值 — 這裡有缺口就會掉關

• Standard queue —— 吞吐量幾乎無上限、至少一次（at-least-once）、盡力而為的順序： 會發生重複與亂序。
• FIFO queue —— 依 message group 保證順序、5 分鐘內去重，吞吐量上限較低。不同 group 之間不保證順序；一個卡住的 group 不會擋住其他 group。
• Visibility timeout —— consumer 收到訊息後，訊息會被隱藏這麼久；若沒有及時刪除，它會重新出現 並再被處理一次。依處理時間來設定它（aws_data.md §7-4）。
• DLQ —— 被接收超過 maxReceiveCount 次後，訊息會移到 dead-letter queue，讓一則壞訊息不再 卡住其他訊息；修好後再 redrive 回去（aws_data.md §7-6）。
• 保留期限 —— 最長 14 天；queue 是緩衝區，不是封存庫。

4-3) 其他資料攝取服務 ★★★☆☆優先度 3／5 — 值得會 — 多半是必備模式的變形

5) 資料處理：Glue、EMR 還是 Lambda ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

5-1) 三者一張表

「Glue 用來在沒有叢集的情況下跑 Spark，EMR 用來掌控叢集，Lambda 用來回應事件 —— 而不是用來 處理資料本身。」

包含 Athena 與 Redshift 的完整比較矩陣在 aws_data.md §1-2； Glue 還是 EMR 的決策在 §3-4；為什麼是 Lambda 啟動 Spark job、 而不是取代它，見 §7-1。

5-2) 怎麼選 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

陷阱：把「Glue 比較慢」或「EMR 比較便宜」當成事實說出來。 速度與成本取決於資料量、worker 或 instance 類型、job 的形態、啟動時間，以及 job 調校得多好。一般而言成立的是：EMR 提供更多旋鈕與 Spot 價格，在持續的大規模下如果有人調校並維運它就會勝出；Glue 每 DPU 的價格買到的就是省下這份 維運工作。說出你會量測什麼，而不是哪一個會贏。

5-3) Spark 的追問 ★★★★☆優先度 4／5 — 高價值 — 這裡有缺口就會掉關

選了 Glue 或 EMR，話題就會轉到底下的引擎。要準備好：減少 shuffle、處理傾斜、設定 executor 大小、 避免小檔案、選擇 partition 數量、從 Spark UI 找出慢的 stage，以及讓失敗的 job 能安全重跑。 這些都歸 spark.md 與 data_performance.md；重跑歸 batch_pipeline.md。

6) 查詢：Athena 還是 Redshift ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

6-1) 比較

「Athena 直接在資料所在的 lake 上查詢，依掃描量計費；Redshift 是我把資料載入進去的倉儲，所以 重複的重度查詢快且可預期。」

選 Athena：資料已經是 S3 上的 Parquet、查詢是探索性或偶發的、沒人想維運倉儲。選 Redshift： BI 工作負載整天跑同樣的重度 JOIN、需要在併發下維持可預期的延遲，或需要 workload management。 好的答案常常兩者並用：Athena 查 lake，Redshift 放 dashboard 會打的 gold 表 —— 再用 Redshift Spectrum 把兩邊 JOIN 起來。

6-2) 各自怎麼調校 ★★★★☆優先度 4／5 — 高價值 — 這裡有缺口就會掉關

Athena —— 帳單與延遲的原因相同，都是掃描的位元組數 （aws_data.md §5-2）：

• 欄式、壓縮的檔案（Parquet / ORC）；
• 依查詢會篩選的欄位分區，讓分區能被剪除（pruning）；
• 明確列出欄位 —— 不要 SELECT *；
• 合併小檔案；表格會被更新時用 Iceberg；
• 每個團隊一個 workgroup，並設定單次查詢的掃描上限。

Redshift —— 資料布局決定有多少資料要在節點之間搬動（faq_redshift.md）：

• distribution style：兩張大表的 JOIN 欄位用 KEY，讓相符的列落在同一個 slice；小型 dimension 用 ALL；沒有好的 key 時用 EVEN；AUTO 讓 Redshift 自己選。傾斜的 KEY 會把工作堆到一個 slice 上；
• sort key 設在用範圍篩選的欄位（通常是日期），讓資料區塊能被跳過；
• materialized view 給 dashboard 反覆計算的彙總；
• workload management 佇列，讓分析師的臨時查詢不會餓死 dashboard；
• 用 EXPLAIN 與系統 view 找出重新分配或廣播資料的那一步。

6-3) 分析工具架上的其他服務 ★★★☆☆優先度 3／5 — 值得會 — 多半是必備模式的變形

7) 工作流編排：Step Functions、MWAA 還是 EventBridge ★★★★☆優先度 4／5 — 高價值 — 這裡有缺口就會掉關

7-1) 比較

「由 AWS 服務呼叫組成的工作流用 Step Functions；有排程、相依關係與回補（backfill）的資料管線用 MWAA；某件事發生時要啟動東西，用 EventBridge。」

7-2) 怎麼選 ★★★★☆優先度 4／5 — 高價值 — 這裡有缺口就會掉關

• 幾個 AWS 步驟，加上分支與重試（啟動 Glue job、等待、跑 Athena、通知）→ Step Functions。 Standard workflow 最長可跑一年，每次嘗試中每個步驟只執行一次 —— 但 Retry policy 會重跑失敗的 task，所以 task 的副作用（一次寫入、啟動一個 job）仍必須是冪等的。Express workflow 用於短時間、大量的事件處理。
• 許多互相依賴的管線、排程、回補過去的日期、跨系統的任務 → MWAA。 回補一段日期範圍正是 Airflow 的核心設計；代價是一個全天候運行、全天候計費的環境。
• 「檔案落地時執行」或「每天 02:00 執行」 → 用 EventBridge（rule 或 Scheduler）啟動 state machine、Glue job 或 Lambda。它不追蹤多步驟的工作流。

Glue 自己的 workflow 與 trigger 也能串起 Glue job 與 crawler；每一步都是 Glue 時它們夠用， 只要有一步不是，就會處處受限。

8) Catalog、治理與存取權 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

8-1) 相關服務

一句話說明 Catalog vs Lake Formation： Data Catalog 說明資料是什麼；Lake Formation 決定 誰可以看到其中哪一部分 —— 對於與它整合的引擎（Athena、Redshift Spectrum、EMR、Glue）。

8-2) 為什麼「我給了它 IAM 權限」還不夠 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

從 lake 讀取資料，只有在它經過的各層沒有任何一層拒絕、而且適用的授權允許時才會成功：

 caller's IAM policy        may this role call s3:GetObject / glue:GetTable / athena:...?
 S3 bucket policy           cross-account: must allow this principal; same account: an IAM allow
                            is enough, so the bucket policy restricts only by explicit Deny
 KMS key policy             may this role kms:Decrypt with the key the object was written with?
 Lake Formation grant       does the role hold SELECT on this table / column / row?
 Glue catalog policy        is the catalog resource shared with this account?
 VPC endpoint policy        does the endpoint the request goes through allow it?
 Organizations SCP          does the account's guardrail allow the action at all?

任何一處的明確拒絕（explicit deny）都會勝出。在同一個帳號內，只要 identity policy 或 bucket policy 其中之一允許，S3 就會放行；跨帳號時則兩者都必須允許。無論哪種情況，permissions boundary、 session policy 或 SCP 都仍可能在沒有任何 deny 的情況下限制它。最常見的除錯盲點是 KMS：role 可以列舉並 get 物件，讀取卻仍然以存取錯誤失敗，因為它沒有解密的權限。

8-3) 「你怎麼保護 S3 data lake？」 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

1. 每個 job 與服務各自一個 IAM role，最小權限，範圍限定在它們的 prefix 與表格。
2. Bucket policy 用明確的 Deny 敘述 —— 拒絕預期範圍以外的 principal、沒有 TLS 的請求，以及 不經由 VPC endpoint 的請求。最後這條 deny 要為代表你呼叫 S3 的 AWS 服務留例外（aws:ViaAWSService、 Firehose 的 role 這類服務 principal），否則會擋掉 Athena、Lake Formation 或資料投遞。光靠允許清單 （allow-list），擋不住 IAM policy 已經授權的同帳號 role。
3. 在帳號層級開啟 Block Public Access。
4. 敏感資料用 SSE-KMS，並在 key policy 中指名誰可以解密。
5. 用 Lake Formation 做表、欄、列層級的存取控制，規模大時用 LF-tags。
6. 用 CloudTrail（加上 S3 data events）稽核誰做了什麼。
7. PII 在進入廣泛開放存取的層之前先做遮罩（masking）或 tokenization。

加密不等於存取控制。 加密在儲存外洩時保護位元組；IAM、bucket policy 與 Lake Formation 決定誰可以讀取它們。面試官會聽你是否把這兩件事分清楚。

9) 監控與可靠性 ★★★★☆優先度 4／5 — 高價值 — 這裡有缺口就會掉關

9-1) 相關服務

9-2) 每一層要看的指標 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

依 SLA 設告警，而不只是依錯誤：一條默默什麼都沒處理的管線不會丟出任何錯誤。新鮮度與資料量 檢查能抓到它。較完整的版本見 aws_data.md §9-2。

10) 每一層的成本 ★★★★☆優先度 4／5 — 高價值 — 這裡有缺口就會掉關

「用 Spot instance」的資深版本。 只說這句話不是答案；後續要回答的是：哪些工作可以被中斷、 checkpoint 存在哪裡、失去的 task 如何重試、被收回的容量會不會讓執行時間超過 SLA，以及省下的錢 值不值得這個風險。成本、可靠性與效能總是一起取捨，從來不是一次只考慮一個。更多槓桿見 aws_data.md §9-3。

11) 三個架構情境 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

11-1) 每日 1 TB 的批次處理 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

 RDS / APIs / CSV / logs
        |
 S3 raw (bronze)  --Glue or EMR Spark-->  S3 silver  -->  S3 gold (Iceberg, Parquet)
                                                               |
                                               Athena (ad hoc)   Redshift (dashboards)
 orchestration: Step Functions or MWAA      monitoring: CloudWatch alarms on freshness

為什麼： S3 便宜地存放原始與處理後的資料，並保留原始資料以便重新處理；Spark 負責分散式 轉換；Parquet 讓查詢只讀需要的欄位；分區讓它只讀需要的日期；Redshift 給 dashboard 穩定的 SLA； Athena 讓其他人都能直接查 lake。

資深追問 —— 怎麼讓它更快、更安全？

• 用增量處理（CDC、bookmark、watermark）取代每次全部重掃；
• 依查詢會篩選的欄位分區，不要過度分區；
• 合併小檔案；
• 調校 Spark job 的 shuffle、JOIN 與 partition 數量；
• 讓重跑是冪等的 —— 依 key 做 MERGE，或覆寫整個分區 —— 讓重試永遠不會產生重複列；
• 發布前做資料品質檢查、設定重試策略，並準備好回補的路徑。

完整的實作版本 —— 把 RDS 的訂單資料送進 Iceberg lakehouse —— 見 aws_data.md §11。

11-2) 即時應用程式 log ★★★★☆優先度 4／5 — 高價值 — 這裡有缺口就會掉關

 application logs / CloudWatch Logs
        |
 Kinesis Data Streams
        |---- Flink / Spark Structured Streaming ----> alerts, aggregates
        |---- Firehose ----> S3 (history, Parquet)  ----> Athena
        `---- Firehose ----> OpenSearch (log search)

為什麼選 KDS： 多個 consumer 讀同一批 record、串流可在保留期限內 replay、處理是即時的。 如果唯一的需求是「把 log 送進 S3」，單用 Firehose 就更簡單 —— 不需要 stream，也不需要 Spark。

「你怎麼處理重複事件？」

• 在來源端給每個事件一個穩定的 event_id；
• 讓處理是冪等的，必要時在有限的時間窗內依 event_id 去重；
• 對 consumer 的讀取位置做 checkpoint，讓重啟時是接續而不是從頭開始；
• 記住兩個 sink 之間沒有共同的分散式交易 —— 寫入 S3 與寫入 OpenSearch 可能一個成功一個失敗， 所以每個 sink 都必須能承受 replay（stream_pipeline.md）。

「那遲到的資料呢？」 —— 串流 job 裡用帶 watermark 的 event-time window；批次層則用 lookback， 重新處理最近幾個分區。

11-3) 把 RDS 同步進 data lake ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

 Amazon RDS / Aurora  --DMS: full load, then CDC-->  S3 raw  --Glue / EMR MERGE-->  Iceberg  -->  Athena / Redshift

為什麼選 DMS： 它先做初始的 full load，再從資料庫 log 串流變更，所以來源永遠不必被重新掃描。 以下追問在 aws_data.md §6 都有回答：

• 初始 snapshot 以及 CDC 開始的時間點，讓中間不漏掉任何資料；
• 刪除 —— DMS 用 Op = 'D' 標記；MERGE 必須套用它們；
• 順序 —— 依來源的變更序號套用變更，而不是用可能相同的時間戳；
• 重複 —— 依主鍵做 merge，讓重複投遞的變更無害；
• schema 演進 —— 來源新增欄位時不能讓 job 壞掉；
• 複寫延遲（replication lag） —— 對它設告警；在 PostgreSQL 上，停住的 consumer 還會讓 WAL 塞滿磁碟（aws_data.md §6-4）。

12) 面試工具箱 ★★★★★優先度 5／5 — 必備 — 幾乎每一輪面試都會出現

12-1) 服務選型表

12-2) 要演練的十五題

12-3) 大家常說錯的話

12-4) 考前最後複習清單

儲存與資料庫

• [ ] S3 vs EBS vs EFS
• [ ] S3 分區與小檔案問題
• [ ] RDS vs DynamoDB vs Redshift

資料攝取

• [ ] Kinesis Data Streams vs Firehose vs MSK
• [ ] SQS vs SNS vs EventBridge vs Kinesis
• [ ] DMS full load vs CDC

資料處理

• [ ] Glue vs EMR vs Lambda
• [ ] Spark 的 driver、executor、shuffle 與傾斜
• [ ] Parquet、壓縮與分區

分析

• [ ] Athena vs Redshift
• [ ] Redshift 的 distribution key 與 sort key
• [ ] EXPLAIN 與查詢調校

架構與維運

• [ ] Step Functions vs MWAA
• [ ] Glue Data Catalog vs Lake Formation
• [ ] IAM、KMS 與 Secrets Manager
• [ ] CloudWatch、重試、DLQ 與冪等性
• [ ] 每一層的成本

複習順序： 先掌握 S3、Glue、EMR、Spark、Kinesis、Redshift 與 Athena —— 它們撐起了 AWS 系統設計答案的大部分 —— 再深入 MWAA、Step Functions、DMS 與 Lake Formation。