第二章：資料收集與管道設計

# 第二章：資料收集與管道設計 資料科學的第一步是確保資料來源完整、品質良好，並且能夠高效地進入分析流程。本章將從資料來源分類、收集方式、ETL 流程到資料湖與資料倉儲的設計與實務落地，為後續模型建構與部署奠定堅實基礎。 --- ## 2.1 資料來源概覽 | 資料類型 | 典型來源 | 特性 | 典型使用情境 | |---|---|---|---| | 結構化 | ERP、CRM、交易系統 | 完整表結構、鍵值關聯 | 財務報表、客戶關係管理 | | 半結構化 | JSON、XML、Log 檔 | 可解析字段、可擴充 | API 回傳、Web 伺服器日誌 | | 非結構化 | 影像、影片、語音、文字檔 | 無固定結構 | 產品照片、客服語音、社群貼文 | > **實務提示**：先針對業務目標確認「核心資料」與「輔助資料」的比例，避免在收集初期即投入大量資源於不必要的資料。 --- ## 2.2 內部系統資料 ### 2.2.1 企業關鍵系統 | 系統 | 典型表格 | 重要指標 | |---|---|---| | ERP（Enterprise Resource Planning） | `sales_order`, `inventory`, `purchase_order` | 交易金額、庫存週轉率 | | CRM（Customer Relationship Management） | `customer`, `lead`, `activity` | 客戶終身價值、轉化率 | | IoT 裝置 | `device_status`, `sensor_reading` | 設備可靠度、維修頻率 | ### 2.2.2 資料抽取方式 - **資料庫連線**：使用 JDBC / ODBC 直接讀取資料庫。 - **批次抽取**：利用 ETL 工具定時抽取資料表。 - **CDC（Change Data Capture）**：捕捉資料庫變更流，減少資料重複。 sql -- 範例：使用 Snowflake 提取 ERP 資料 SELECT * FROM ERP.SALES_ORDER WHERE ORDER_DATE >= '2024-01-01'; --- ## 2.3 第三方 API 第三方 API 提供即時或批次的業務數據，常見於金融、天氣、行銷等領域。 ### 2.3.1 RESTful API http GET https://api.example.com/v1/sales?date=2024-02-01 Accept: application/json - **認證**：OAuth2、API Key、JWT。 - **速率限制**：需設計重試機制與排程策略。 ### 2.3.2 GraphQL GraphQL 允許客戶端自行指定回傳欄位，減少不必要的資料傳輸。 graphql query { sales(date: "2024-02-01") { orderId amount customer { name region } } } > **實務建議**：使用 SDK 或自動生成程式碼（如 OpenAPI Codegen）可快速落地；同時將 API 請求結果緩存於資料湖，以利後續分析。 --- ## 2.4 網路爬蟲 對於公開網頁或社群平台，爬蟲是收集非結構化資料的重要手段。 ### 2.4.1 技術棧 | 工具 | 說明 | |---|---| | Scrapy | Python 網路爬蟲框架，支援異步、管道處理 | | BeautifulSoup | HTML 解析器，適合簡易抓取 | | Selenium | 虛擬瀏覽器，能處理 JavaScript 渲染 | ### 2.4.2 爬蟲流程 1. **目標定義**：確定要抓取的 URL 與資料結構。 2. **抓取**：使用 Scrapy 的 Spider 定義抓取邏輯。 3. **清洗**：在 Item Pipeline 中進行資料清洗、驗證。 4. **存儲**：輸出至 JSON、CSV 或直接寫入資料湖。 python # Scrapy 爬蟲範例：抓取商品價格 import scrapy class ProductSpider(scrapy.Spider): name = "product" start_urls = ["https://example.com/products"] def parse(self, response): for product in response.css('.product'): yield { 'name': product.css('.name::text').get(), 'price': product.css('.price::text').get(), 'url': product.css('a::attr(href)').get(), } > **注意**：爬蟲請遵守 robots.txt 規範，並避免對目標網站造成過度負載。 --- ## 2.5 ETL 基礎架構 ### 2.5.1 定義 - **ETL**：Extract（抽取）→ Transform（轉換）→ Load（載入）。 - **ELT**：Extract → Load → Transform，適用於資料湖。 ### 2.5.2 資料流程圖 ┌───────────────┐ ┌─────────────────┐ ┌───────────────┐ │ 資料來源 │──▶│ ETL/ELT 流程 │──▶│ 目的地 │ └───────────────┘ └─────────────────┘ └───────────────┘ ### 2.5.3 常見 ETL 工具 | 工具 | 優勢 | |---|---| | Airflow | 工作流編排、可視化、擴充性 | | Prefect | Python 原生、錯誤重試自動化 | | dbt | 資料轉換、測試、版本控制 | | Talend | 封裝化、可視化設計 | ### 2.5.4 轉換策略 - **Schema-on-read vs Schema-on-write**：資料湖常採 Schema-on-read，資料倉儲採 Schema-on-write。 - **資料清洗**：缺失值處理、重複刪除、資料類型轉換。 - **資料品質檢測**：數值範圍、字串格式、關聯完整性。 --- ## 2.6 資料湖 vs 資料倉儲 | 特色 | 資料湖 | 資料倉儲 | |---|---|---| | 儲存格式 | 原始檔案（Parquet、ORC、CSV、JSON） | 結構化表格（Star / Snowflake schema） | | 讀寫模式 | Schema-on-read | Schema-on-write | | 成本 | 低（存儲成本） | 高（運算 & 存儲） | | 目的 | 原始資料探索、機器學習 | 商業報表、BI 分析 | | 性能 | 依賴查詢引擎（Presto、Spark） | OLAP 引擎（Snowflake、Redshift） | > **實務建議**：以資料湖為核心，將需要即時報表的資料轉換為資料倉儲；同時保留原始資料以供模型訓練或追溯。 --- ## 2.7 建置要點 1. **統一元資料平台**：選擇雲端或自建，確保跨團隊存取一致。 2. **資料治理**：建立資料目錄、元資料管理、存取權限。 3. **安全機制**：加密（在傳輸與靜態）、身份驗證、審計日誌。 4. **彈性伸縮**：使用容器化（K8s）或無伺服器（Serverless）以降低運維成本。 5. **監控 & 報警**：ETL 作業失敗、資料延遲、容量告警等。 6. **成本管理**：利用預留實例、資料分層儲存（熱冷分層）。 --- ## 2.8 工具生態 | 類別 | 工具 | 主要功能 | |---|---|---| | 數據抽取 | Fivetran, Stitch | 雙向同步，支持多種資料源 | | 工作流 | Airflow, Prefect, Dagster | 任務排程、依賴關係管理 | | 資料轉換 | dbt, Spark | SQL / PySpark 轉換、測試 | | 資料湖 | AWS S3, Azure Data Lake, Google Cloud Storage | 大規模檔案儲存 | | 資料倉儲 | Snowflake, BigQuery, Redshift | OLAP、即時查詢 | | 元資料 | DataHub, Amundsen | 資料目錄、搜尋 | > **選型提示**：根據企業規模、技術棧與成本考量，逐步構建「金字塔式」資料平台：底層為資料湖，頂層為資料倉儲。 --- ## 2.9 實務案例 ### 2.9.1 零售客流分析 | 步驟 | 具體做法 | |---|---| | 1. 資料收集 | 透過 POS 系統、Wi‑Fi 熱點、客流監測攝像頭收集 | 2. ETL | 使用 Airflow 定時抽取，dbt 轉換為每日客流表 | 3. 資料湖 | 存於 S3，檔案格式為 Parquet | 4. 資料倉儲 | Snowflake 中建立星型 schema，供 BI 報表使用 | 5. 商業洞察 | 分析高峰時段、商品停留時間，優化陳列策略 | 6. 成效 | 平均客單價提升 5%，庫存周轉率提升 8% | ### 2.9.2 製造業機器維修預測 | 步驟 | 具體做法 | |---|---| | 1. 資料收集 | IoT 裝置發送實時溫度、振動資料至 MQTT | 2. ETL | 使用 Spark Structured Streaming 進行即時聚合 | 3. 資料湖 | 以 Delta Lake 格式儲存 30 天快照 | 4. 資料倉儲 | Redshift 中建立維修事件表 | 5. 模型 | 以歷史維修記錄訓練 LightGBM 預測維修機率 | 6. 部署 | 模型 API 部署於 SageMaker，Slack 事件通知 | 7. 成效 | 未預期停機時間降低 20%，維修成本降低 12% | --- ## 2.10 常見挑戰與解決方案 | 挑戰 | 可能原因 | 解決方案 | |---|---|---| | 資料不一致 | 不同系統格式差異 | 采用統一資料模式（JSON Schema）與 ETL 標準化流程 | | 資料延遲 | 網路或處理瓶頸 | 引入即時處理（Kafka + Spark Streaming）與資源擴容 | | 成本失控 | 大量資料存儲與運算 | 建立資料分層、冷熱分離、使用預留實例 | | 安全合規 | GDPR/個資法 | 數據加密、資料匿名化、訪問審計 | | 人才缺口 | 資料工程師短缺 | 內部培訓、外包平台（Upwork、Toptal） | --- ## 2.11 小結 本章從資料來源到管道設計，涵蓋了資料收集的全流程與實務工具。掌握資料湖與資料倉儲的設計要點，以及 ETL/ELT 的最佳實踐，將使資料科學團隊能夠快速、穩健地提供高品質資料，為後續分析、建模與決策提供堅實基礎。