CH4.3 數據處理技術與工具
數據處理技術與工具
資料準備與轉換（型別轉換 → 分箱與分類重組 → 類別變數編碼 → 標準化/正規化）→ 特徵工程三領域（特徵選擇 Filter/Wrapper/Embedded、特徵衍生與聚合、資料增強）→ 分散式運算框架（Hadoop/Spark/Flink/Beam）→ 資料處理管線工具（Airflow/Luigi/Prefect/Kubeflow）與自動化要點。
1. 資料準備與轉換
(1) 資料型別轉換與欄位整理
清理後常需進行類型強制轉換（如 int→float、str→datetime）與欄位重新命名/重組，以提升一致性與可讀性：數值轉型（字串轉整數）、時間轉換（統一為 ISO 8601 格式）、欄位重命名（cust_id → customer_id）、欄位重組（合併地址欄位、拆分姓名）。
(2) 分箱（Binning）與分類重組
| 分箱方法 | 說明 |
|---|---|
| 等寬分箱（Equal-width） | 數值範圍等距劃分（如 0–100 分為 5 區，每區寬度 20） |
| 等頻分箱（Equal-frequency/Quantile） | 使每個區間樣本數大致相同（如四分位數分箱） |
| K-Means 分箱 | 使用 K-Means 分群技術將連續變數分區 |
分類重組策略：合併樣本數過少的類別為「Other」、將細分類別整併為大類、對高基數（High Cardinality）欄位降維以降低過擬合風險。
(3) 類別變數編碼（Encoding）
大多數演算法（邏輯迴歸、決策樹、神經網路）無法直接處理類別變數，需先轉換為數值：
| 編碼方法 | 做法 | 適用情境 | 優點 | 風險/限制 |
|---|---|---|---|---|
| Label Encoding（標籤編碼） | 每個類別對應一個整數（如小學→0、高中→1） | 具明確順序關係的類別（Ordinal），如教育程度 | 轉換快速、佔用空間小 | 誤用於無序類別會讓模型誤解為有數學意義 |
| One-hot Encoding（獨熱編碼） | 每個類別新增一個 0/1 欄位 | 無序類別變數（Nominal），如城市名稱 | 保留完整資訊，不引入順序誤解 | 高基數類別會大幅增加特徵維度 |
| Target Encoding（目標編碼） | 以類別在目標變數上的統計量（平均值/轉換率）取代 | 高基數類別變數，且與目標變數高度關聯 | 保留目標相關資訊，不造成維度爆炸 | 需注意資料洩漏，應搭配交叉驗證使用 |
Label Encoding 若誤用於無序類別（如城市名稱、產品顏色），模型可能誤解類別之間存在數值大小或順序關係，正確做法是改用 One-hot Encoding；反之，若類別本身具有明確順序（如服務等級 Basic/Premium/VIP），Label Encoding 才是合適選擇。
(4) 數值標準化與正規化
當變數尺度差異大（如「年齡」數十、「收入」數萬），使用基於距離的演算法（KNN）、依賴梯度下降的模型或正則化模型（Lasso、Ridge）時，特徵縮放為必要前處理：
| 方法 | 做法 | 優點 | 限制 |
|---|---|---|---|
| Min-Max標準化（Min-Max Normalization） | 線性縮放至 [0,1] 區間 | 保留原始分佈比例，易解釋 | 對極端值敏感，異常值會壓縮其他數值範圍 |
| Z-score標準化（Z-score Standardization） | 轉為均值 0、標準差 1 | 適用於符合常態分佈的資料 | 對極端值仍敏感，偏態資料可能產生偏移 |
| Robust Scaling（穩健標準化） | 使用中位數與 IQR 進行縮放 | 對極端值具高度抵抗性，適合偏態或含離群值資料 | 轉換後不保證符合任何標準分佈 |
三種縮放方法的選擇取決於資料是否含離群值：資料乾淨且接近常態可用 Z-score，需固定區間可用 Min-Max，資料含大量離群值則應優先選擇 Robust Scaling（以中位數、IQR 取代均值、標準差），這正呼應 CH3.1 中「中位數與 IQR 對極端值較穩健」的概念。
2. 特徵工程三領域
特徵工程透過選擇、衍生或增強特徵，幫助模型更有效捕捉資料價值，需避免資料洩漏（Data Leakage），尤其在使用聚合特徵或目標編碼時應搭配交叉驗證或時間窗口劃分。
(1) 特徵選擇方法（Feature Selection）
| 方法 | 做法 | 優點 | 限制 |
|---|---|---|---|
| Filter（過濾法） | 透過統計量或相關係數獨立於模型篩選特徵（皮爾森相關係數、卡方檢定、ANOVA） | 速度快、不依賴特定模型 | 無法考慮特徵間交互作用 |
| Wrapper（包裝法） | 用模型表現作標準，透過遞迴特徵消除（RFE）或前向/後向選擇 | 精確考量特徵互動效果 | 計算成本高，可能過度擬合 |
| Embedded（嵌入法） | 訓練過程中內建特徵選擇機制（決策樹重要性、Lasso、Ridge） | 建模過程中同時完成特徵選擇 | 需特定模型支援，受超參數影響 |
(2) 特徵衍生與聚合技巧
- 交互特徵（Interaction Features）：特徵間數學運算（乘積、除法）產生新特徵，如「消費頻率」×「平均消費金額」=「年度消費總額」。
- 時間特徵（Temporal Features）：從時間資料衍生星期、假日標記、時間間隔（Recency）等。
- 聚合特徵（Aggregate Features）：群組統計計算，如顧客最近三個月平均交易額。
(3) 資料增強方法（Data Augmentation）
| 資料型態 | 方法 | 應用案例 |
|---|---|---|
| 圖像 | 隨機翻轉、旋轉、裁剪、色彩變換 | 人臉辨識、醫學影像分析 |
| 文字 | 同義字替換、隨機插入/刪除/交換字詞 | 情感分析、對話模型訓練 |
| 時序 | 增加噪音、局部時段調整、視窗裁切 | 設備故障預測、股市趨勢分析 |
| 表格 | SMOTE（Synthetic Minority Oversampling Technique） | 不平衡資料分類（詐欺偵測、疾病診斷） |
3. 分散式運算框架
| 框架 | 處理模式 | 適用情境 | 優點 | 缺點 |
|---|---|---|---|---|
| Apache Hadoop（MapReduce） | 批次處理（Batch Processing） | 大量離線作業、日誌彙總 | 成熟穩定、容錯強（HDFS）、易水平擴充 | 速度較慢，不適合即時運算 |
| Spark（Apache Spark） | 記憶體內運算，支援批次/即時/互動查詢（微批次） | 大規模快速批次處理、機器學習訓練（MLlib） | 運算速度快、函式庫豐富 | 記憶體需求高 |
| Apache Flink | 原生即時串流處理，也支援批次 | 高頻率即時事件處理（風險偵測、IoT） | 真正即時、高吞吐、狀態管理一致性佳 | 生態系統較 Spark 小 |
| Apache Beam | 統一批次與串流的抽象模型，可搭配多種後端引擎 | 跨平台運算、雲端與本地混合架構 | 可移植性強，多雲彈性部署 | 抽象層高，上手需較多工程經驗 |
四種框架的核心差異在於「批次 vs 即時」：Hadoop 是純批次、Spark 是記憶體內批次為主（可微批次模擬即時）、Flink 是原生即時串流、Beam 則是可移植的統一抽象層，可搭配不同後端引擎執行。
4. 資料處理管線與自動化
(1) 管線設計原則
可重現性（Reproducibility）、容錯性與回復機制（Fault Tolerance & Recovery）、擴充性與彈性（Scalability）、監控與可觀測性（Monitoring & Observability）。
常見管線架構：批次處理管線（定期啟動，如每日報表）、即時資料管線（持續運作、低延遲）、混合資料管線（批次+即時並行）。
(2) 管線工具比較
| 工具 | 特點 | 適用情境 | 優勢 | 缺點 |
|---|---|---|---|---|
| Apache Airflow | Python 編寫，豐富 Operators 與排程功能 | 大規模、結構複雜、多任務協調 | 開源、靈活、社群活躍 | 維護與部署相對複雜 |
| Luigi | Spotify 開發，架構清晰 | 中小型任務、簡單流程 | 易上手、部署快速 | 監控能力有限 |
| Prefect | 現代化設計，強大容錯與監控 | 現代資料科學團隊 | 錯誤處理強、友善 UI | 完整功能需雲端付費 |
| Kubeflow Pipelines | 以 Kubernetes 為基礎 | 機器學習/AI 模型訓練流程管理 | 原生整合 Kubernetes | 安裝設定複雜，學習曲線陡 |
(3) 建構管線自動化要點
任務拆解與模組化（Task Modularization）、版本控管與 CI/CD 整合（Git、GitHub Actions）、監控與警示設計（Grafana、Prometheus）、容器化與彈性擴充（Docker、Kubernetes）。
管線設計四原則可記為「重、容、擴、監」——可重現性、容錯性、擴充性、監控可觀測性，缺一都會讓大數據管線難以長期穩定運作。
📝 章節考題自測（先作答，再點開解答）
Q1. 某資料集有「教育程度」欄位（小學/國中/高中/大學/研究所），欄位本身具有明確順序關係，最適合採用下列哪一種編碼方式？
(A) One-hot Encoding (B) Label Encoding (C) Target Encoding (D) 不需編碼
解答與解析
參考 Ans: (B) 教育程度屬於具明確順序關係的類別變數（Ordinal Variables），適合使用 Label Encoding 將類別轉為有序整數；若改用 One-hot 反而會喪失原有的順序資訊。
Q2. 某資料集「城市名稱」欄位包含 20 個無序類別，若直接使用 Label Encoding，最可能產生下列哪一個問題？
(A) 特徵維度爆炸 (B) 模型可能誤解城市之間存在數值大小或順序關係 (C) 完全無法用於任何模型 (D) 會自動轉換為目標編碼
解答與解析
參考 Ans: (B) Label Encoding 誤用於無序類別（Nominal Variables）時，模型可能誤解類別之間具有數學意義上的大小或順序關係，正確做法應改用 One-hot Encoding 保留完整且無序的類別資訊。
Q3. 某資料集含有大量離群值且分佈明顯偏態，欲進行特徵縮放，下列何種方法最適合？
(A) Min-Max Normalization (B) Z-score Standardization (C) Robust Scaling (D) 不需要進行任何縮放
解答與解析
參考 Ans: (C) Robust Scaling 使用中位數與 IQR 進行縮放，對極端值具高度抵抗性，特別適合資料分佈偏態或含離群值的情境；Min-Max 與 Z-score 皆對極端值敏感。
Q4. 下列何者屬於 Wrapper 特徵選擇方法的特性？
(A) 使用皮爾森相關係數快速篩選特徵，不依賴模型 (B) 使用模型表現（如準確率）作為標準，透過遞迴特徵消除進行篩選 (C) 在決策樹訓練過程中內建特徵重要性分析 (D) 完全不需要任何計算成本
解答與解析
參考 Ans: (B) Wrapper（包裝法）使用模型實際表現作為評估標準，透過遞迴特徵消除（RFE）或前向/後向選擇進行特徵篩選，能精確考量特徵間的交互作用，但計算成本較高；(A) 為 Filter 方法，(C) 為 Embedded 方法。
Q5. 針對信用卡詐欺偵測中「詐欺樣本極少」的資料不平衡問題，下列哪一種資料增強技術最常被使用？
(A) 圖像旋轉 (B) 同義字替換 (C) SMOTE (D) 移動平均
解答與解析
參考 Ans: (C) SMOTE（Synthetic Minority Oversampling Technique）專門用於合成少數類別樣本，是處理表格式資料不平衡問題（如詐欺偵測、疾病診斷）最常見的資料增強技術。
Q6. 若企業需要處理「高頻率即時事件」（如即時風險偵測、IoT 資料流），下列哪一個分散式運算框架最適合？
(A) Apache Hadoop（MapReduce） (B) Apache Flink (C) 純批次 SQL 查詢 (D) 傳統單機程式
解答與解析
參考 Ans: (B) Apache Flink 原生支援即時事件導向的串流處理，具真正即時、高吞吐與良好的狀態管理一致性，最適合高頻率即時事件場景；Hadoop 屬於批次處理，速度較慢不適合即時需求。
Q7. 下列何者是特徵工程中應特別留意避免的風險？
(A) 特徵選擇時間過長 (B) 資料洩漏（Data Leakage），尤其在使用聚合特徵或目標編碼時 (C) 使用過多的視覺化圖表 (D) 模型過於簡單
解答與解析
參考 Ans: (B) 特徵工程應避免資料洩漏（Data Leakage），尤其使用聚合特徵或 Target Encoding 時，若未謹慎使用交叉驗證或時間窗口劃分，可能讓模型在訓練階段「看到」未來資訊，導致評估結果過於樂觀但實際部署效果不佳。
Q8. 下列關於 Apache Beam 的敘述，何者正確？
(A) 只能在單機環境執行 (B) 提供統一的批次與串流抽象模型，可搭配 Flink、Spark、Google Dataflow 等後端引擎執行 (C) 僅支援結構化資料 (D) 是一種資料庫查詢語言
解答與解析
參考 Ans: (B) Apache Beam 提供跨平台的統一批次與串流處理抽象模型（Unified Batch & Streaming Model），可移植性強，能搭配多種後端運算引擎（Flink、Spark、Google Dataflow）執行，適合跨平台或雲端與本地混合架構。