第二章：數據收集與清洗——從源頭到乾淨數據的轉化

# 第二章：數據收集與清洗 --- > **「收集」不是抓取，而是把握價值；「清洗」不是消除，而是塑造洞察。」 ## 2.1 需求與目標設定 在任何數據工程之前，先把問題定義清楚。\ - **業務問題**：公司想預測哪一類客戶最可能升級？\ - **決策需求**：需要一個可解釋的模型，並確保資料合規。\ - **資料指標**：客戶行為、交易歷史、客服交互。\ 把需求轉成 **KPIs** 與 **資料需求表**，再交由資料工程師制定采集規範。\ > **提示**：常見錯誤是把「想知道什麼」等同於「把所有資料都拿來」。結果會得到「噪聲多、成本高」的數據倉庫。 ## 2.2 資料來源與采集方法 | 來源 | 采集方式 | 特色 | 潛在風險 | |------|----------|------|-----------| | **關係型資料庫** | SQL ETL | 結構化、穩定 | 數據變動慢，版本控制困難 | | **Web API** | REST/GraphQL | 實時、靈活 | 速率限制、認證變更 | | **物聯網設備** | MQTT/CoAP | 大量、連續 | 裝置失效、資料遺失 | | **社群平台** | Web Scraper | 內容豐富 | 合規風險、版權問題 | | **雲端儲存** | S3、Blob | 可擴展、成本低 | 存取成本、資料一致性 | > **實務建議**：先跑小批量測試，確認數據結構、格式與頻率。若使用 API，考慮 **exponential backoff** 機制防止被封。 ## 2.3 數據存取與存儲 ### 2.3.1 目標設計 - **資料湖**（Data Lake）：存放原始、未處理的資料。適合多模態、非結構化。 - **資料倉庫**（Data Warehouse）：結構化、經過 ETL、為報表設計。 - **緩存層**（Redis、Memcached）：即時查詢、低延遲。 ### 2.3.2 存儲技術選擇 | 技術 | 優點 | 缺點 | |------|------|------| | **Parquet / ORC** | 列式存儲，壓縮高 | 需要 Spark 之類的引擎 | | **JSON Lines** | 易讀、流式 | 數據膨脹 | | **Delta Lake** | ACID 交易，版本控制 | 複雜度較高 | > **案例**：某電商公司將日交易資料存成 **Delta Lake**，利用 Hive Metastore 做元資料管理，實現「即時 + 歷史」分析。 ## 2.4 數據清洗流程 > **流程圖**：\ > 1️⃣ 采集 → 2️⃣ 存儲 → 3️⃣ 轉換 → 4️⃣ 清洗 → 5️⃣ 驗證 → 6️⃣ 加載 ### 2.4.1 缺失值處理 | 方法 | 適用場景 | 風險 | |------|----------|------| | **刪除** | 缺失率 < 5% | 可能失去關鍵樣本 | | **均值/中位數填補** | 連續變量 | 低估方差 | | **前向/後向填補** | 時序資料 | 產生偏差 | | **插值** | 連續、非隨機缺失 | 複雜度高 | ### 2.4.2 異常檢測 python import numpy as np from scipy import stats def detect_outliers(series): z = np.abs(stats.zscore(series)) return series[z > 3] > **說明**：對數據分布不明的變量，先做 **log** 轉換，再檢測異常。若發現異常值，先與原始業務人員核對，避免誤刪。 ### 2.4.3 重複值與衝突解決 1. **唯一鍵**：建立 Composite Key（客戶ID + 時間戳）\ 2. **版本號**：若多個來源更新同一筆資料，保留最高版本或最新時間戳。\ 3. **手動審核**：對重要決策資料，可設置 **Data Steward** 進行核對。 ### 2.4.4 資料格式化 - **日期時間**：統一為 **ISO 8601**（YYYY-MM-DDTHH:MM:SSZ）。\ - **數值**：統一為 **float64**，並做小數位校正。\ - **分類變量**：使用 **Label Encoding** 或 **One-Hot**，視模型需求決定。 ## 2.5 常見挑戰與對策 | 挑戰 | 來源 | 對策 | |------|------|------| | **資料偏差** | 采集時選擇性 | 設計 **Sampling Bias Mitigation** 模組 | | **資料遺失** | 網路斷線、裝置失效 | 使用 **Checkpointing** 與 **Redundancy** | | **合規風險** | GDPR、CCPA | 實作 **Data Masking**、**Consent Management** | | **資料不一致** | 多源同步 | 引入 **Event Sourcing** 或 **Kafka Streams** | > **小結**：清洗不是一次性工作，而是 **持續迭代** 的流程。每天至少跑一次 **Data Quality Report**，確保數據符合 SLA。 ## 2.6 案例實踐：零售業客戶行為數據清洗 ### 目標 - 建立客戶購買行為資料集，供風險模型與客戶分群使用。 ### 步驟 1. **ETL**：從 POS、網站、APP 三個系統拉取原始交易與瀏覽日志。\ 2. **結合**：以 **客戶ID + 交易時間** 為鍵，合併多來源資料。\ 3. **清洗**： - 刪除重複交易。\ - 填補缺失的 **付款方式**。\ - 轉換 **價格** 為統一貨幣。\ - 對 **時間戳** 做 **時區校正**。\ 4. **驗證**：利用 **Data Steward** 與線上客服核對 100 條樣本。\ 5. **加載**：寫入 **Delta Lake**，並註冊到 Hive Metastore。 ### 成效 - **清洗時間** 從 3 小時縮短到 30 分鐘。\ - **缺失率** 降至 0.3%。\ - **模型準確率** 提升 8%。 ## 2.7 小結與延伸閱讀 > **核心要點**： > 1. **需求驅動**，先把業務目標轉成資料指標。\ > 2. **源頭多元**，選擇合適的采集技術並預防合規風險。\ > 3. **清洗流程化**，設置自動化管道、質量指標與審核機制。\ > 4. **資料治理**，建立元資料、版本控制與安全管理。\ > > **延伸閱讀**： > - *Data Management for Researchers* – K. H. & P. C. 2022 > - *The Data Warehouse Toolkit* – R. Kimball & M. Ross 2019 > - *Clean Code for Data Engineers* – J. H. 2021 > **思考題**：設計一個「自動缺失值判斷」模組，並在此模組中加入 **機器學習** 來決定最合適的填補方法。你會如何落實？