建議先看完對應教學影片再作答，效果加倍。 👉 YouTube 教學頻道
第 1 題
某零售集團需要建立資料平台，同時滿足三個需求：儲存來自 POS 系統、社群媒體、IoT 感測器的原始多格式資料（結構化、半結構化、非結構化）；支援資料科學家的探索性分析與機器學習模型訓練；以及支援財務部門每日執行的 BI 報表查詢。架構師評估了三種方案後建議採用 Data Lakehouse。下列何者最能正確描述 Data Lakehouse 相較於純 Data Lake 或純 Data Warehouse 的核心優勢？
(A) Data Lakehouse 結合 Data Lake 的彈性儲存（Schema-on-read，支援原始多格式資料）與 Data Warehouse 的結構化查詢優化能力（ACID 事務、索引、SQL 查詢加速），讓同一平台同時支援 ML 訓練與 BI 報表，避免資料在兩套系統間複製
(B) Data Lakehouse 是 Data Warehouse 的雲端版本，差異只在部署環境，將 Data Warehouse 遷移到雲端即可自動獲得 Data Lakehouse 的所有功能，無需更換架構設計
(C) Data Lakehouse 主要優勢是儲存成本最低，透過壓縮非結構化資料並統一使用物件儲存，讓所有格式的資料儲存成本比 Data Warehouse 降低 90% 以上
(D) Data Lakehouse 只適合非結構化資料的儲存，若同時需要處理結構化交易資料，仍需保留獨立的 Data Warehouse，兩者並行使用才能滿足混合需求
答案：A
深度導讀解析
正確答案：A
核心技術點：Data Lakehouse 的架構設計邏輯——整合 Data Lake 彈性與 Data Warehouse 查詢能力
中級理論拆解：Data Lake 支援 Schema-on-read（讀取時才解析格式），能儲存任何格式的原始資料，但查詢效能差、缺乏 ACID 事務支援，BI 工具難以直接使用。Data Warehouse 採用 Schema-on-write（寫入時強制格式），查詢快、支援 SQL，但只能儲存預先定義好格式的結構化資料。Data Lakehouse 透過在物件儲存（如 S3）上加入元資料層（如 Delta Lake、Apache Iceberg），同時獲得 Schema-on-read 的儲存彈性和 ACID 事務、索引、查詢優化的能力，消除了需要維護兩套系統並定期在兩者間同步資料的成本。
選項坑洞掃描：B 說 Lakehouse 只是 Data Warehouse 的雲端版，這是根本性的誤解，Lakehouse 是全新的架構概念，不是將既有架構搬到雲端就能實現。C 說主要優勢是儲存成本最低，成本是優點之一但不是核心優勢，Lakehouse 的核心是架構統一而非成本壓縮。D 說 Lakehouse 只適合非結構化資料，Lakehouse 的設計目的恰好是同時處理結構化和非結構化資料，這個描述完全相反。
破題反射字：Schema-on-read → Data Lake 特性 ／ ACID + 查詢優化 → Data Warehouse 特性 ／ Data Lakehouse → 兩者整合避免資料重複
第 2 題
某金融機構的核心交易系統每天產生數百萬筆異動記錄，需要即時同步至資料倉儲供風控模型使用。資料工程師評估三種同步策略：全量載入（Full Load）、基於時間戳記的增量載入（Timestamp-based Incremental）、變更資料捕獲（Change Data Capture, CDC）。資料長要求選擇「對來源系統負載最小且能捕捉刪除操作」的方案。下列何者最能正確描述三種策略的差異，以及哪種最符合此要求？
(A) 全量載入最符合需求，因為它每次都傳輸完整資料，確保資料倉儲與來源系統完全一致，不會遺漏任何異動包括刪除操作
(B) CDC 最符合需求，它透過監控資料庫的事務日誌（Transaction Log）捕捉每一筆 INSERT、UPDATE、DELETE 操作，只傳輸異動資料而非全量，對來源系統負載極低，且能捕捉刪除操作
(C) 基於時間戳記的增量載入最符合需求，透過查詢更新時間大於上次同步時間的記錄，只傳輸有異動的資料，且因為不依賴資料庫日誌所以對來源系統負載最低
(D) 三種策略對來源系統的負載完全相同，差異只在傳輸的資料量，應選擇全量載入確保資料倉儲的一致性，再透過網路壓縮降低傳輸成本
答案：B
深度導讀解析
正確答案：B
核心技術點：CDC 透過事務日誌捕捉異動的機制，以及它與增量載入在「捕捉刪除操作」上的關鍵差異
中級理論拆解：全量載入每次傳輸所有資料，對來源系統壓力最大，且百萬筆記錄的全量傳輸延遲高。基於時間戳記的增量載入只查詢 updated_at > 上次同步時間的記錄，但有一個致命限制：刪除操作不會更新時間戳記，被刪除的記錄在來源系統消失，增量載入完全無法偵測到，資料倉儲會保留已刪除的記錄。CDC 監控資料庫的 binlog（MySQL）或 WAL（PostgreSQL），在日誌層面捕捉每一個事務，包含 DELETE，且不需要對來源資料庫執行查詢，對來源系統負載極低。
選項坑洞掃描：A 說全量載入負載最小，全量載入需要讀取所有記錄，是三種方法中對來源系統負載最大的。C 說增量載入比 CDC 負載更低，增量載入需要執行時間戳記查詢，CDC 讀取日誌不執行查詢，CDC 對來源系統的負載通常更低，且 C 忽略了增量載入無法捕捉刪除操作的致命問題。D 說三種方法負載相同，全量載入對來源系統的負載明顯高於其他兩種方法，這個說法完全不正確。
破題反射字：CDC → 監控事務日誌 ／ 增量載入的盲點 → 無法捕捉 DELETE ／ binlog / WAL → CDC 的技術基礎
第 3 題
某跨國零售集團在五個國家各有獨立的 CRM、ERP、電商系統，各系統對「客戶」的定義和識別方式不同，導致同一個客戶在不同系統中有不同的 ID 和資料格式。集團希望建立「單一客戶視圖（Single Customer View）」，讓所有系統都使用一致的客戶主數據。下列何者最能正確描述解決此問題的核心技術方向？
(A) 部署資料虛擬化（Data Virtualization）層，讓各系統透過統一 API 查詢各自的客戶資料，不需要實際整合資料，使用者感覺像在使用同一個系統
(B) 建立 ETL 管線將所有系統的資料每日全量匯入中央資料倉儲，透過定期全量同步讓中央資料庫成為最新的客戶資料來源
(C) 導入主數據管理（Master Data Management, MDM）系統，建立客戶主數據的黃金記錄（Golden Record），透過實體解析統一跨系統的客戶識別，並將主數據同步回各業務系統
(D) 要求所有國家的系統統一更換為同一套 ERP，從根本上消除異構系統的存在，避免主數據不一致的問題
答案：C
深度導讀解析
正確答案：C
核心技術點：MDM 的黃金記錄概念與跨系統主數據統一的架構邏輯
中級理論拆解：MDM（Master Data Management）專門解決企業最核心的共享資料實體（客戶、產品、供應商）在多系統間不一致的問題。MDM 建立的「黃金記錄（Golden Record）」是每個客戶實體的單一權威版本，整合了所有系統的資料，透過實體解析（Entity Resolution）識別跨系統的同一客戶，解決識別碼不同的問題。建立後，MDM 將黃金記錄作為主數據同步回各業務系統，確保全球所有系統都使用一致的客戶定義。這和資料倉儲的目的不同，資料倉儲是分析用途，MDM 是讓業務系統使用一致的主數據。
選項坑洞掃描：A 說資料虛擬化可以解決此問題，資料虛擬化讓查詢跨越多個系統，但不解決各系統對同一客戶有不同識別碼的根本問題，查詢時仍然不知道 CRM 的 C001 和 ERP 的 E-00123 是同一人。B 說每日 ETL 全量同步，ETL 可以匯集資料，但若沒有 MDM 的實體解析機制，同一客戶仍然以多個記錄存在於中央資料庫。D 說強制換系統，更換 ERP 是巨大的業務風險和成本，且全球五國統一換系統在實務上極難執行。
破題反射字：主數據不一致 → MDM ／ 黃金記錄 → 單一權威版本 ／ 實體解析 → 識別跨系統同一實體
第 4 題
某科技公司的資料工程師正在設計資料管線，需要決定採用 ETL（Extract, Transform, Load）還是 ELT（Extract, Load, Transform）架構。公司剛完成雲端資料湖的建置，具備強大的彈性運算能力，且資料來源包含大量原始 JSON 日誌和影像後設資料，未來的分析需求尚不明確。下列何者最能正確描述此情境下選擇 ELT 優於 ETL 的核心理由？
(A) ELT 在所有情境下都優於 ETL，因為 ELT 利用目標系統的運算能力進行轉換，ETL 在中間層進行轉換的做法已經過時，現代資料工程應全面採用 ELT
(B) ELT 在此情境更合適，原因是：原始 JSON 和影像後設資料格式多樣，ETL 需要事先定義轉換邏輯才能載入，而 ELT 先將原始資料載入資料湖（Schema-on-read），未來分析需求確定後再在湖內執行轉換，保留最大彈性；且能充分利用已建置的雲端彈性運算資源
(C) ELT 優於 ETL 的唯一原因是成本，ELT 不需要獨立的 ETL 伺服器，只靠目標系統的資源執行轉換，所有公司在任何情況下都能透過 ELT 降低 50% 以上的基礎設施成本
(D) ETL 在此情境更合適，因為資料湖的 Schema-on-read 特性讓查詢速度較慢，應先在 ETL 階段完成所有轉換再載入，確保分析師查詢時不需要等待轉換運算
答案：B
深度導讀解析
正確答案：B
核心技術點：ELT 的 Schema-on-read 彈性與 ETL 的 Schema-on-write 限制，以及選型的情境依賴
中級理論拆解：ETL 需要在載入前定義好目標 Schema 並完成轉換，適合需求明確、資料格式固定的場景。本題有兩個關鍵條件：格式多樣的原始資料（JSON + 影像後設資料）且未來需求不明確。ETL 強迫在不確定需求的情況下提前定義轉換邏輯，靈活性極低。ELT 先將所有原始格式載入資料湖，待分析需求確定後再在湖內執行轉換（使用 Spark SQL 等），且直接利用已建置的雲端彈性運算，不需要額外的 ETL 伺服器。Schema-on-read 讓同一份原始資料可以依照不同分析需求進行不同的轉換，最大化彈性。
選項坑洞掃描：A 說 ELT 在所有情境都優於 ETL，若目標系統是傳統 Data Warehouse（如 Oracle），沒有彈性運算能力，ETL 可能更合適；且對需求明確、格式固定的資料，ETL 的預先轉換反而讓查詢更快。C 說 ELT 的唯一優勢是成本，ELT 的核心優勢是彈性和充分利用目標系統運算能力，而非單純的成本，且「降低 50%」是沒有依據的具體數字。D 說 ETL 在此情境更合適，未來需求不明確時強制 ETL 預先定義 Schema 是資料工程的典型反模式，靈活性極低。
破題反射字：需求不明確 + 格式多樣 → ELT 更合適 ／ Schema-on-read → 載入後才定義格式 ／ ETL 適用 → 需求明確、格式固定
第 5 題
某電商公司的資料架構師在設計即時風控系統時，需要同時處理兩種任務：即時偵測可疑交易（延遲需求 < 200 毫秒）以及每日生成詐欺行為的趨勢報表（可接受小時級延遲）。架構師評估純串流處理（Stream Processing）、純批次處理（Batch Processing）、Lambda 架構三個方案。下列何者最能正確描述 Lambda 架構選擇此情境的合理性，以及其速度層（Speed Layer）與批次層（Batch Layer）的分工邏輯？
(A) Lambda 架構不適合此情境，因為同時維護串流和批次兩套管線的運維成本過高，應選擇純串流處理方案，批次報表也可透過串流的時間窗口（Time Window）聚合取代
(B) Lambda 架構將即時任務交由速度層（串流處理，如 Kafka + Flink）以毫秒級延遲輸出近似結果；批次層（如 Spark Batch）定期處理完整歷史資料輸出精確的趨勢報表；服務層整合兩者結果，這個分工正好對應此情境的雙重需求
(C) Lambda 架構的批次層負責即時偵測，速度層負責批次報表，兩層分工與 Kappa 架構相同，差異只在 Lambda 架構額外維護一個用於容錯的備援層
(D) Lambda 架構只適合資料量超過 PB 級的大型企業，中小型電商的交易量不足以體現 Lambda 架構的優勢，應根據資料量選擇更輕量的單一處理架構
答案：B
深度導讀解析
正確答案：B
核心技術點：Lambda 架構的三層設計邏輯——速度層、批次層、服務層的分工
中級理論拆解：Lambda 架構設計來解決「低延遲近似結果」和「高延遲精確結果」無法同時被單一處理系統滿足的問題。速度層（Speed Layer）使用串流處理（Kafka + Flink / Spark Streaming），以毫秒到秒級的延遲產出近似結果，供即時決策使用；批次層（Batch Layer）定期（如每小時或每日）對完整歷史資料重新計算，產出高準確度的結果用於報表和模型訓練；服務層（Serving Layer）合併兩層的輸出，讓查詢端可以同時存取即時近似值和歷史精確值。本題的 200ms 即時風控 + 每日趨勢報表正好是 Lambda 架構的經典應用場景。
選項坑洞掃描：A 說應選純串流，串流的時間窗口聚合確實可以做批次報表，但準確性和歷史回溯能力不如批次處理，且重新計算歷史資料（Late Data Correction）在純串流架構中複雜度很高。C 把速度層和批次層的分工說反，速度層負責即時處理、批次層負責歷史精確計算，說法完全顛倒。D 說 Lambda 只適合 PB 級企業，Lambda 架構的適用性取決於是否有雙重延遲需求，與資料量無直接關係，中小型電商若同時需要毫秒級即時和日級精確，Lambda 是合理選擇。
破題反射字：Lambda 架構 → 速度層 + 批次層 + 服務層 ／ 速度層 → 近似結果低延遲 ／ 批次層 → 精確結果高延遲 ／ Kappa 架構 → 只用串流取代批次層
還在用零散筆記備考？
這份《iPAS 中級白話備考筆記》把三科考綱重點全部用人話整理好，考點速記、實戰場景、常見陷阱一次收錄。適合非本科、時間有限、想快速抓住考試方向的自學者。
👉 立即取得備考筆記
