資料知識地圖 · 3. 資料管線
3. 資料管線
ETL/ELT & Storage
觀念教學
資料不會自己從來源走到分析桌上。中間那條自動化輸送帶,就是資料管線(Data Pipeline)——資料工程的核心。
核心觀念
管線把「搬運、轉換、儲存」串成可重複執行的流程,四大件:ETL/ELT(先轉換還是先載入)、批次與串流(多久搬一次)、儲存方案(資料庫 DB、資料倉儲 DW、資料湖 Data Lake)、交易一致性(ACID)與 Schema 欄位語意對齊(確保搬完的資料是對的、對得上的)。
白話理解
把它想成中央廚房:產地(來源系統)進貨,洗切調理(轉換),分裝進冷藏庫(DW)或大倉庫(Data Lake),門市(報表與模型)隨取隨用。批次處理(Batch)像每天凌晨進一次貨;串流處理(Streaming)像迴轉壽司,資料一產生就上軌道。
四大設計決策
- ETL 或 ELT:先轉換再載入,或先載入再轉換,取決於資料量與運算資源
- 批次或串流:日報表用批次;即時監控、詐欺偵測用串流,看處理延遲容忍度
- 存哪裡:結構化分析進 DW;原始多格式先進 Data Lake
- 品質底線:交易靠 ACID,跨系統欄位語意要對齊——「營收」含不含稅,先說清楚
- 資料新鮮度:下游看到的是幾分鐘前還是昨天的資料?這是管線的核心服務指標
🎯 口訣:管線四問——怎麼搬(ETL/ELT)、多快搬(批次/串流)、搬去哪(DW/Lake)、搬對沒(ACID/Schema)。
iPAS 考點
考資料工程師的核心職責——建置與維運資料管線,與資料科學家(分析建模)區隔。情境題:「需要即時反應」選串流、「每日彙總報表」選批次,判斷關鍵字是延遲容忍度。名詞題:處理延遲、資料新鮮度屬於管線監控指標,別和模型指標混在一起。
應用場景
評估指標
iPAS 歷屆考題詳解(1 題)
先自行作答,再展開詳解。題目出處均為 iPAS AI 應用規劃師正式考題,著作權屬原主辦單位。
某AI平台的資料工程師需要在 Apache Spark 叢集上，對包含 10億筆使用者行為紀錄的RDD/DataFrame 計算整體標準差（Standard Deviation）。請問下列哪種策略在分散式環境中最正確且有效率？
- A呼叫 collect()將所有資料傳回 Driver 節點的本機記憶體後，再使用 Python 的statistics.stdev()計算
- B先對資料進行全域排序（sortBy），再取中間值計算變異數
- C將資料輸出為 CSV，再以Excel 的STDEV函數計算
- D使用 DataFrame.agg({'col': 'stddev'})或 RDD.aggregate()等分散式統計方法，由各Executor計算局部統計量後再進行彙總
看正解與逐選項詳解
正解:D
正確答案:(D)
【正解解析】
分散式計算的基本原則是「把運算送往資料所在的節點,而不是把資料集中回單一機器」。DataFrame.agg({'col':'stddev'}) 或 RDD.aggregate() 會讓各 Executor 先在本地計算局部統計量(筆數、總和、平方和),再由 Spark 彙總為全域標準差;網路只需傳遞少量中間值,10 億筆資料也能有效處理,這是 Map 端聚合再 Reduce 彙總的標準模式,故 (D) 正確。
【為何其他選項錯了?】
- (A):collect() 會把 10 億筆資料全部拉回 Driver 節點的記憶體,幾乎必然造成記憶體不足(OOM);若資料能以單機處理,一開始就不需要 Spark 叢集。
- (B):標準差的計算與排序、中位數無關;全域排序(sortBy)是分散式環境中最昂貴的 shuffle 操作之一,徒增成本而對目標毫無幫助。
- (C):Excel 單一工作表僅約 104 萬列,遠不足以容納 10 億筆資料;此作法也完全放棄了分散式運算能力。
提示:Spark 聚合統計的正確模式是各節點計算局部量再彙總;看到 collect() 全量回收資料即應警覺記憶體風險。