第二章：資料蒐集與治理的完整生態

# 第二章：資料蒐集與治理的完整生態 在資料科學的世界裡，**資料蒐集與治理**不僅是前置工作，更是後續建模品質的根基。若把資料視為石油，蒐集是抽取，治理是煉化；忽略任何一環，都會讓最終產品產生瑕疵。 ## 2.1 資料來源識別：從業務問題到數據門戶 - **業務問題對照表**：將業務痛點映射至可能的資料來源，確保收集的資料真正能回答「為什麼」與「怎麼做」。 - **資料門戶清單**：內部資料庫、第三方 API、網頁爬蟲、IoT 端點、社群媒體。每一個來源都要先做「合規可行性評估」。 - **案例**：某零售商想提升庫存周轉率，從 POS 系統、CRM、物流 ERP、甚至 Google Analytics 中抓取數據。 ## 2.2 資料蒐集技術：工具與流程 | 技術 | 主要用途 | 優點 | 缺點 | |------|----------|------|------| | SQL / ETL | 結構化資料提取 | 可靠、可維護 | 單機效能受限 | | Airflow / Prefect | 任務排程 | 可視化、易擴展 | 學習曲線較陡 | | Kafka / Pulsar | 流式資料 | 低延遲、彈性 | 初始設定複雜 | | Scrapy / Selenium | 網頁爬取 | 高效、靈活 | 受網站反爬限制 | > **實作小技巧**：用 Airflow 的 XCom 在不同 DAG 間傳遞關鍵變數，減少重複下載；用 Kafka 的 MirrorMaker 進行跨區域資料同步，保證時效。 ## 2.3 數據治理概念：治理框架與流程 1. **資料分類**：敏感、重要、普通。依據 GDPR、個人資料保護法（PDPA）等規範，確定處理層級。 2. **資料目錄**：利用 Amundsen 或 DataHub 建立元資料索引，讓開發者能快速定位。 3. **資料血緣追蹤**：透過 lineage 工具追蹤資料流向，確保可追溯。 4. **資料版本控制**：像 Git 版本控制資料，配合 Delta Lake 或 Iceberg 的時間旅行特性。 > **治理失敗案例**：一家金融機構在資料遷移時忽略資料版本控制，結果導致歷史交易資料錯亂，最終造成合規罰款 500 萬。 ## 2.4 隱私合規與倫理 - **同意機制**：在收集個人資訊前，必須明確取得使用者同意，並提供撤回權。 - **匿名化 / 擬化**：使用 K-anonymity、差分隱私等技術，減少個人識別風險。 - **倫理審查**：設置 Data Ethics Committee，對敏感資料使用做事前審核。 > **提示**：在模型訓練前，先對資料做「隱私風險掃描」，確保沒有違反任何法規或企業道德。 ## 2.5 資料品質管理：從 Clean 到 Reliable | 資料品質指標 | 描述 | 檢測方法 | |---------------|------|-----------| | 完整性 | 資料是否缺失 | Null Ratio、Missing Value Heatmap | | 一致性 | 同一實體不同來源是否一致 | Data Profiling、Record Linkage | | 可靠性 | 資料是否準確 | Sample Auditing、Ground Truth Verification | | 時效性 | 資料是否即時 | Timestamp Drift、Lag Analysis | > **工具**：Great Expectations、Deequ、Apache Griffin。將驗證規則寫成 YAML 或 Python，與 ETL 流程緊密結合。 ## 2.6 工具選型：從需求到投資 | 需求 | 推薦工具 | 主要功能 | |------|----------|----------| | 大規模批處理 | Apache Spark | 分散式計算、MLlib | | 實時流式 | Apache Flink | 事件時間處理、窗口算子 | | 資料倉儲 | Snowflake / BigQuery | Serverless、零維度縮放 | | 數據可視化 | Looker / Metabase | BI、資料探索 | | 監管合規 | Collibra / Informatica | Data Governance、Policy Enforcement | > **投資決策**：對於中小企業，先從開源工具 (Spark + Airflow) 開始，等規模擴大後再引入商業化平台。 ## 2.7 案例研究：從 0 到 1 的資料管道構建 - **背景**：一家電子商務平台希望透過「即時熱銷預測」提升營運效率。<br> - **步驟**： 1. **來源**：抓取 24/7 內部交易日誌、外部搜尋熱詞、社群評論。<br> 2. **蒐集**：使用 Kafka 將流式資料推送至 Spark Streaming，進行初步清洗。<br> 3. **治理**：在 Airflow DAG 中加入資料品質檢測，合規審核後寫入 Snowflake。<br> 4. **品質**：Great Expectations 每日執行 100 條規則，發現 3% 的資料錯誤即時通知。<br> 5. **結果**：預測模型準確率提升 12%，訂單缺貨率下降 4%。 > **關鍵成功因素**：即時性、嚴格治理、跨部門協作。 ## 2.8 小結 - **資料蒐集不是「抓」**，而是「有策略、有規則、有治理」的流程。<br> - **治理** 是品質與合規的雙重保證，缺失會在模型階段顯露為「偏差」或「風險」。<br> - **工具與流程** 的選型應以「可擴展性、易維護性、合規性」為核心。<br> - **跨部門協作** 是成功的關鍵：資料工程師、業務、法務、合規同仁需在同一平台上共創。 > 透過本章的實作框架，讀者已能從業務問題出發，搭建一個具備治理與合規的資料蒐集管道，為後續的資料工程與模型建構奠定堅實基礎。