第2章 資料蒐集與整合

# 第2章 資料蒐集與整合 > **學習目標**：\ > 1. 理解資料蒐集的主要來源與方式；\ > 2. 掌握建立統一資料倉儲的流程與工具；\ > 3. 能夠設計可擴充、可維護的資料整合管道。 --- ## 2.1 何謂資料蒐集？ 資料蒐集（Data Acquisition）是將「業務需求」轉化為「可用數據」的第一步。它不僅僅是把資料從源頭搬運到工作站，而是一個關於資料品質、可追蹤性與治理的完整流程。<br> > **核心問題** > - 哪些資料能支持決策？ > - 資料來源的合法性與可用性如何確保？ > - 如何以成本效益最大化資料價值？ ## 2.2 資料來源分類 | 類型 | 典型來源 | 特色 | 主要挑戰 | |------|----------|------|------------| | **內部系統** | ERP、CRM、POS、BI 報表 | 結構化、規範化 | 版本迭代、權限控制 | | **外部 API** | Google Maps、社群媒體、金融行情 | 時效性高、API 限流 | 認證機制、網路可靠性 | | **網路爬蟲** | 商品評論、競爭對手網站 | 非結構化、頻繁變動 | 反爬機制、資料合法性 | | **物聯網（IoT）** | 感測器、車載數據 | 大量、即時 | 資料吞吐、時間同步 | | **傳統媒體** | 報紙、期刊、電子書 | 內容豐富、文本 | PDF 解析、版權問題 | > **實務提示**：在確定資料來源前，先進行「資料治理需求分析」— 風險、合規、成本三方面綜合評估。 ## 2.3 資料蒐集流程（Data Acquisition Pipeline） 1. **需求定義**：確定業務指標（KPI）所需的資料指標。 2. **來源評估**：判斷資料的可得性、品質與合法性。 3. **連線設計**：採用批量（Batch）或即時（Streaming）方式。 4. **提取 (Extraction)**：抓取資料並轉存暫存區。 5. **轉換 (Transformation)**：資料清洗、格式轉換、欄位映射。 6. **載入 (Loading)**：將資料寫入資料倉儲或資料湖。 7. **監控與治理**：即時報告、元資料管理、資料血緣追蹤。 > **關鍵術語**：ETL（Extract‑Transform‑Load）與 ELT（Extract‑Load‑Transform）。在大資料環境下，ELT 以資料湖為主，後續在倉儲或分析平台完成轉換。 ## 2.4 內部系統的資料抽取 ### 2.4.1 從資料庫抽取 sql -- 以 MySQL 為例，抽取客戶資料 SELECT customer_id, name, email, signup_date FROM customers WHERE signup_date >= '2023-01-01'; ### 2.4.2 從 OLAP 系統抽取 使用 **SQL on Hadoop** 或 **Presto** 抽取聚合報表。 sql SELECT region, SUM(sales) AS total_sales, COUNT(*) AS orders FROM sales_fact WHERE order_date BETWEEN '2024-01-01' AND '2024-03-31' GROUP BY region; > **實務小技巧**：使用 **CDC（Change Data Capture）** 技術，實時同步變更資料到資料倉儲，降低資料延遲。 ## 2.5 外部 API 的資料抓取 ### 2.5.1 認證與速率限制 - **OAuth 2.0**：使用 refresh token 交換 access token。<br> - **API Key**：在 headers 或 query string 送入。<br> - **速率限制**：使用回退機制（Exponential Backoff）。 ### 2.5.2 Python 範例（Requests） python import requests import time API_URL = "https://api.example.com/v1/data" HEADERS = { "Authorization": "Bearer YOUR_ACCESS_TOKEN", "Accept": "application/json" } params = {"date_from": "2024-01-01", "date_to": "2024-01-31"} while True: response = requests.get(API_URL, headers=HEADERS, params=params) if response.status_code == 200: data = response.json() # 進行資料寫入或暫存 break elif response.status_code == 429: retry_after = int(response.headers.get("Retry-After", 60)) time.sleep(retry_after) else: response.raise_for_status() > **實務提示**：在公司環境下，將 API 呼叫包裝成 **Python 包**，並使用 **Airflow** 或 **Prefect** 定義 DAG 進行排程。 ## 2.6 網路爬蟲的實作與倫理 | 步驟 | 目的 | 工具 | 需要注意的法規 | |------|------|------|-----------------| | **目標設定** | 確定需要爬取的資料 | Selenium, Scrapy | 版權、商業秘密 | | **robots.txt** | 確認網站允許爬取範圍 | urllib | 遵守網站政策 | | **請求頻率** | 避免造成伺服器負擔 | time.sleep, RequestRateLimiter | 服務條款 | | **資料存儲** | 結構化存儲 | PostgreSQL, MongoDB | 資料保護 | | **數據清洗** | 去除重複、格式化 | Pandas | 資料質量 | python import scrapy class ProductSpider(scrapy.Spider): name = "product" start_urls = ["https://example.com/products"] def parse(self, response): for product in response.css(".product-item"): yield { "id": product.css("::attr(data-id)").get(), "name": product.css(".name::text").get(), "price": product.css(".price::text").get(), } > **倫理提醒**：確保爬取資料不違反任何版權或隱私條例，必要時取得資料所有者同意。 ## 2.7 資料湖 VS 資料倉儲 | 特色 | 資料湖（Data Lake） | 資料倉儲（Data Warehouse） | |------|--------------------|-----------------------------| | 資料格式 | 原始（Raw）可存放結構化、半結構化、非結構化 | 結構化（Schema‑on‑Write） | | 目的 | 事前探索、機器學習 | 報表、BI、決策支援 | | 技術 | Hadoop, S3, Delta Lake | Snowflake, BigQuery, Redshift | | 元資料 | 大量元資料管理需求 | 內建模式 | | 成本 | 较低（按需存儲） | 高（結構化儲存） | > **實務建議**：先將原始資料存入資料湖，完成清洗、轉換後再載入資料倉儲。這樣可以保持「一次寫入，重複使用」的原則。 ## 2.8 資料治理與血緣追蹤 1. **資料標準化**：制定統一的命名規範、資料類型、單位。 2. **元資料管理**：使用 **Data Catalog**（如 Collibra、Alation）記錄資料來源、擁有者、更新頻率。 3. **資料血緣追蹤**：從源頭到最終使用，記錄所有轉換步驟，確保可追溯性。 4. **資料品質指標**：完整度、準確度、一致性、及時性。 5. **安全與合規**：符合 GDPR、CCPA 等隱私規範，設置角色權限、加密傳輸。 ## 2.9 案例研究：零售業的資料蒐集與整合 | 步驟 | 需求 | 技術棧 | 成果 | |------|------|--------|------| | 1. 需求 | 追蹤客戶購買行為、商品庫存 | 需求討論、KPI 定義 | 具體數據指標確定 | | 2. 來源 | POS 系統、ERP、第三方物流 API、網站日誌 | MySQL、REST API、ElasticSearch | 多源資料整合 | | 3. ETL | 使用 Airflow + Python | Airflow DAG、pandas | 定時提取、清洗、載入 | | 4. 資料湖 | S3 + Delta Lake | Delta Lake | 原始資料備份、探索 | | 5. 資料倉儲 | Snowflake | Snowflake | 報表、BI | | 6. 監控 | Datadog + Airflow SLA | 監控腳本 | 即時錯誤告警 | | 7. 治理 | Collibra | 元資料管理 | 可追溯性、合規 | > **關鍵洞察**：透過跨部門協作，資料科學團隊能夠在 6 個月內把「客戶流失預測模型」落地，提升客戶留存率 12%。 ## 2.10 小結 資料蒐集與整合是數據科學的基礎，任何後續的清理、探索、建模都建立在此之上。掌握多元來源的抓取技巧、合理設計資料管道、重視資料治理與血緣追蹤，才能確保資料品質與合規，為企業創造真正的價值。 --- > **下一章預告**：在第3章「資料清理與前處理」中，我們將深入討論缺失值處理、異常偵測以及資料標準化的實務技巧，進一步把資料從「原始」轉化為「可用」的形式。