Enhydra school
考古題總覽 Enhydra Lab 企業平台

資料知識地圖 · 3. 資料管線

ETL / ELT

資料管線設計

在互動地圖中開啟 回資料知識地圖

觀念教學

搬資料的兩種流派:先洗好菜再進倉庫,還是整車先卸貨、要用再洗?這就是 ETL 與 ELT 的分水嶺。

核心觀念

ETL(Extract-Transform-Load):擷取來源資料,先在中繼環境轉換(清理、格式統一、去識別化),再載入目標資料庫——入庫的都是乾淨資料。ELT(Extract-Load-Transform):先原樣載入(通常進資料湖或雲端倉儲),之後用倉儲本身的運算力再轉換。怎麼選?看資料量與運算資源:傳統倉儲搭 ETL;雲端環境儲存與運算便宜,ELT 漸成主流。

白話理解

銀行每晚彙整分行交易:先統一幣別、遮罩卡號,再載入總行倉儲——ETL。網路公司把 App 原始事件全倒進雲端資料湖,分析師要用時再轉換——ELT。

關鍵細節

  • ETL:入庫即乾淨、治理容易;瓶頸在轉換伺服器
  • ELT:載入快、保留原始資料、彈性高;治理不嚴,資料湖變沼澤
  • 監控基本盤:各階段的處理時間與失敗率,失敗要能重跑
  • 敏感資料在轉換階段處理:去識別化、遮罩、彙總,讓下游拿到的資料先天無害
🎯 口訣:ETL 先洗再進門,ELT 先進門再洗;個資要在進門前洗掉。

iPAS 考點

三個真實考向:

  • ETL 順序題:擷取、轉換、載入;「先轉換再載入」是 ETL、「先載入再轉換」是 ELT,選項把順序顛倒就是陷阱
  • 政府釋出資料題:市民用電資料含可識別個資要開放研究——最適當做法是釋出前先去識別化/匿名化,必要時做彙總統計,而不是原樣釋出或只靠研究者切結
  • 生成式 AI 客服題:系統要引用歷史交易資料,想從資料層面降低敏感資訊暴露——答案方向是前處理階段先遮罩、去識別化敏感欄位,並最小化提供範圍,別選「靠模型自我約束」或「出事再過濾」
📝 本節掛載 3 題 iPAS 歷屆試題 — 讀完往下到「iPAS 考題練習」直接實戰。

應用場景

AirflowdbtSparkKafka

評估指標

處理時間失敗率

iPAS 歷屆考題詳解(6 題)

先自行作答,再展開詳解。題目出處均為 iPAS AI 應用規劃師正式考題,著作權屬原主辦單位。

第四梯次初級AI應用規劃師第一科人工智慧基礎概論 第3題

關於ETL(Extract-Transform-Load)，下列敘述何者為正確？

  1. AE 表示將資料直接儲存至目標儲存庫
  2. BETL 的處理順序可以自由調整為TEL
  3. CL 表示將目標儲存庫經過反加密處理載入資料
  4. DT 包括資料的清理與排序
看正解與逐選項詳解

正解:D

正確答案:(D) 【正解解析】 ETL 流程依序為擷取(Extract)、轉換(Transform)、載入(Load)。其中 T(轉換)是確保資料品質的核心階段,涵蓋資料清理(去除重複、修正錯誤、處理缺失值)、排序、格式轉換、彙總與商業規則套用,使資料在進入目標儲存庫前即符合分析需求,故 (D) 正確。 【為何其他選項錯了?】 - (A):E 是擷取(Extract),指從來源系統取出資料,而非將資料儲存至目標儲存庫;寫入目標儲存庫是 L(Load)的工作。 - (B):ETL 的順序有邏輯必然性:必須先取得資料(E)才能轉換(T),轉換完成才載入(L);「TEL」在尚未擷取資料前就執行轉換,流程不成立。實務上另有 ELT 模式(先載入、再於目標端轉換),但那是明確定義的另一種架構,不是把 ETL 順序任意調整。 - (C):L 是載入(Load),指把轉換完成的資料寫入目標儲存庫;「反加密處理」並非 Load 的定義,ETL 流程定義中也沒有此步驟。 提示:E 擷取、T 轉換(含清理與排序)、L 載入;順序固定,各階段職責不可互換。
115年第一次初級AI應用規劃師第一科人工智慧基礎概論 第35題

某市政府規劃釋出市民用電資料供學術研究使用,資料內容包含用電紀錄與部分 人口統計欄位。考量資料可能涉及可識別個人之資訊,且須符合個人資料保護相 關規範,下列哪一種資料處理方式最為適當?

  1. A提供完整資料集並透過合約約定研究用途與保密責任
  2. B僅保留用電數值資料,移除所有其他欄位以避免識別風險
  3. C對具識別風險的資料欄位進行轉換處理,並移除直接識別資訊
  4. D僅將資料加密後提供,確保資料在傳輸過程中的安全性
看正解與逐選項詳解

正解:C

正確答案:(C) 【正解解析】 題幹情境是政府釋出資料供學術研究,資料含用電紀錄與人口統計欄位,須兼顧研究價值與個資保護。最適當的作法是去識別化(De-identification):先「移除直接識別資訊」(如姓名、身分證字號、完整地址),再對具識別風險的準識別欄位「進行轉換處理」(如出生日期改為年齡區間、地址改為區域層級)。如此既保留資料的分析價值,又能降低重新識別風險,符合個人資料保護規範的要求,故 (C) 正確。 【為何其他選項錯了?】 - (A):提供完整資料集僅靠合約約束,屬於行政與法律手段,無法從技術上防止資料濫用或外洩,一旦外流損害即已發生。 - (B):移除所有其他欄位雖然降低識別風險,但人口統計欄位正是研究所需,資料的分析價值大幅流失,研究可能無法進行。 - (D):加密保護的是「傳輸與儲存過程」的安全;研究人員若無金鑰則無法使用資料,若交付金鑰則等同提供原始資料,未解決「資料使用階段」的識別風險。 提示:開放資料的隱私處理原則:移除直接識別欄位、轉換準識別欄位,在資料可用性與識別風險之間取得平衡。
115年第一次初級AI應用規劃師第二科生成式AI應用與規劃 第39題

某企業規劃導入生成式 AI 客服系統,需處理顧客查詢並引用歷史交易資料。法遵部門在風險評估中指出,系統若不當處理顧客個人資料,可能引發合規與法律責任。若專案初期希望從資料層面降低敏感資訊暴露風險,下列敘述何者最為合理?

  1. A強化模型輸出審查與遮罩機制,以過濾可能出現的敏感資訊
  2. B設定 AI 回覆範圍與角色權限,限制其存取特定類型資料
  3. C將資料集中於加密儲存環境,並加強系統存取控管
  4. D僅提供必要資料或數據欄位與去識別化策略,減少模型接觸可識別個資
看正解與逐選項詳解

正解:D

正確答案:(D) 【正解解析】 題幹明確要求「從資料層面」降低敏感資訊暴露風險,對應的根本原則是資料最小化(Data Minimization)與最小權限:在資料送入模型之前即從源頭把關,僅提供回覆查詢所必要的資料欄位,並對可直接或間接識別個人的資訊進行去識別化(移除或以代碼替換)。如此即使模型出現預期外的行為,也接觸不到完整的原始個資,從源頭阻斷洩漏風險,故 (D) 正確。 【為何其他選項錯了?】 - (A):輸出審查與遮罩屬於「事後補救」的輸出層防護,難以保證毫無疏漏;敏感資料已進入模型處理流程,風險已經存在,並非資料層面的源頭管控。 - (B):設定回覆範圍與角色權限屬於應用層與存取控制措施,可降低誤用,但模型實際接觸的資料內容並未減少,不是資料層面的作法。 - (C):加密儲存與存取控管保護的是靜態資料(Data-at-rest);模型處理時仍需使用解密後的資料(Data-in-use),無法防止處理過程中的暴露。 提示:題幹限定「資料層面」,答案應落在資料最小化與去識別化;輸出審查、權限控管、加密儲存都屬於其他防護層次。
114年第二梯次中級AI應用規劃師第二科大數據處理分析與應用 第19題

某製造企業導入上萬台物聯網（IoT）感測器以進行設備健康監測。系統需在毫秒級回應異常事件，並同時將完整資料保留於雲端供後續 AI 模型訓練與分析。若企業希望兼顧即時性、資料完整性與可擴展性，下列哪一種資料流程設計最符合此目標？

  1. A感測器 → 雲端 API Gateway → 分散式資料庫 → 批次特徵工程 → 模型推論
  2. B感測器 → MQTT Broker → 雲端資料倉儲 → 即時儀表板 → 模型再訓練
  3. C感測器 → 邊緣運算節點 → 流式資料處理框架(Stream Processing Framework)→ 雲端資料湖 → 模型推論
  4. D感測器 → 本地快取層 → RESTful API → 雲端報表系統 → 模型批次更新
看正解與逐選項詳解

正解:C

正確答案:(C) 【正解解析】 需求拆解:毫秒級回應異常,運算必須靠近資料來源,由邊緣運算節點就地執行即時初步處理與告警;持續不斷的感測資料流,以流式資料處理框架(如 Kafka 搭配 Flink 或 Spark Streaming)進行即時分析;完整資料保留供後續模型訓練,落地於雲端資料湖,保存原始明細且易於水平擴展。「邊緣、串流、資料湖、推論」的組合同時滿足即時性、資料完整性與可擴展性,是 IoT 即時架構的標準設計,故 (C) 正確。 【為何其他選項錯了?】 - (A):流程中的「批次特徵工程」與毫秒級即時回應互斥,異常事件須等待下一個批次才會被處理,無法滿足設備健康監測的即時需求。 - (B):MQTT Broker 收集資料可行,但直接寫入資料倉儲屬於結構化批次分析路線;即時儀表板供人員檢視,無法達成毫秒級的自動異常回應。 - (D):本地快取、RESTful API 與報表系統整條路徑皆為請求回應與報表思維,缺少串流處理與資料湖,即時性與擴展性均不足。 提示:IoT 即時監測三要件:邊緣運算(低延遲)、串流處理(即時分析)、資料湖(完整保留原始資料)。
115年第一次中級AI應用規劃師第二科大數據處理分析與應用 第12題

某資料工程師在建構 AI 訓練資料處理流程時，需要處理一個 50GB 的 CSV 檔案，其大小遠超過系統可用記憶體。他使用 Python 的 Pandas 進行資料前處理，但直接呼叫pd.read_csv()時出現記憶體溢位（Out of Memory, OOM）錯誤。在不改用其他分散式框架的前提下，下列哪個參數最能有效解決此問題？

  1. Anrows=10000：限制僅讀取前 N筆資料以避免記憶體溢位
  2. Busecols=0.5：隨機載入 50%的資料欄位，以減半記憶體使用量
  3. Cchunksize=10000：分批讀取資料並逐批處理，避免一次載入整個檔案
  4. Ddtype：指定欄位資料型別以降低記憶體使用量
看正解與逐選項詳解

正解:C

正確答案:(C) 【正解解析】 pd.read_csv(chunksize=10000) 會回傳迭代器,每次僅載入 1 萬列資料,處理完畢再讀取下一批,讓 50GB 檔案以「分批串流」方式通過有限的記憶體;搭配逐批聚合或逐批寫出,即可在不更換分散式框架的前提下完成前處理,是單機 Pandas 處理超出記憶體資料量的正規作法,故 (C) 正確。 【為何其他選項錯了?】 - (A):nrows=10000 只讀取前 1 萬筆,其餘資料完全未被處理;雖可避免記憶體溢位,但訓練資料嚴重殘缺,未達成處理整份檔案的目標。 - (B):usecols 參數接受的是欄位名稱或索引清單,不存在「傳入 0.5 即隨機載入一半欄位」的用法,語法即不成立;隨機捨棄欄位對需要完整欄位的前處理也不合理。 - (D):指定 dtype(如 float64 降為 float32、字串轉 category)確實能降低記憶體用量,是良好習慣;但檔案大小「遠超」可用記憶體時,節省比例有限仍無法完整載入,故不是最能有效解決的選項。 提示:單機處理超大檔案的首選是 chunksize 分批處理;dtype 屬輔助手段,資料量更大時再考慮 Dask、Spark 等框架。
115年第一次中級AI應用規劃師第二科大數據處理分析與應用 第47題

資料分析師載入一份電商交易紀錄的 Pandas DataFrame df,欄位包含 OrderID(訂單編號)、CustomerID(客戶編號)、Category(商品分類)、Revenue(該筆營收);另有一份客戶資料表 customers,包含 CustomerID(客戶編號)與 Region(所在地區)欄位。分析師想將 customers 表中的 Region 欄位加入到 df 交易紀錄中,且「只保留那些在 customers 表中有對應資料的交易紀錄」。下列哪一種合併方式最正確?

  1. Apd.concat([df, customers], axis=1)
  2. Bpd.merge(df, customers, on='CustomerID', how='outer')
  3. Cpd.merge(df, customers, on='CustomerID', how='inner')
  4. Ddf.join(customers, on='CustomerID')
看正解與逐選項詳解

正解:C

正確答案:(C) 【正解解析】 「把另一張表的欄位併入,且只保留兩邊都有對應鍵值的紀錄」正是內部合併(Inner Join)的定義:pd.merge(df, customers, on='CustomerID', how='inner') 以 CustomerID 為鍵進行配對,在 customers 中找不到對應客戶的交易列會被剔除,配對成功者則接上 Region 欄位,完全符合需求,故 (C) 正確。 【為何其他選項錯了?】 - (A):pd.concat(axis=1) 是「依索引位置」將兩張表左右拼接,不做任何鍵值配對;兩表列數與順序不同,拼接結果會出現客戶資料錯位對應的錯誤。 - (B):how='outer' 會保留兩邊「所有」紀錄:無對應客戶的交易仍保留(Region 補 NaN),沒有交易的客戶也會多出一列,與「只保留有對應者」的要求相反。 - (D):df.join(customers, on='CustomerID') 預設以 df 的 CustomerID 對應 customers 的「索引」,customers 未先 set_index('CustomerID') 會直接報錯;且 join 預設 how='left',仍會保留無對應的交易列,兩處都不符題意。 提示:merge 的 how 參數:inner 取交集、outer 取聯集、left/right 以單邊為準;「只留配對成功者」即為 inner。

相關節點

3. 資料管線ACID / SchemaDW / Lake