返回目錄
A
數據科學實戰：從問題到洞見 - 第 3 章
第3章：數據蒐集與資料治理
發布於 2026-03-05 10:52
# 第3章：數據蒐集與資料治理
本章聚焦於 **資料來源的選擇、資料管道的建構以及資料治理與合規的落地**。數據科學專案往往被「資料不完整」或「資料質量低下」所拖累，因此建立健全的資料蒐集機制與治理框架，是確保模型穩健與可持續發展的基礎。
## 3.1 資料來源與選擇
| 來源類型 | 主要特點 | 常見使用場景 | 風險與挑戰 |
| -------- | -------- | ------------- | ------------- |
| 內部資料 | 完全掌握、易於取得 | 交易紀錄、客戶資料、業務系統 | 需要跨部門協作、資料品質不一 |
| 外部資料 | 先前未被擁有的新資訊 | 公共開放資料、第三方 API、社群媒體 | 合規、版權、更新頻率不確定 |
| 雙向資料 | 內外部結合，擴充視角 | 物流、供應鏈、行銷活動 | 整合成本高、格式不一致 |
> **選擇建議**：先確定 *業務價值*，再考慮 *可取得性* 與 *合規性*。在不影響資料完整性的前提下，盡量使用內部資料；外部資料應作為補充，並在資料治理框架內評估可信度。
## 3.2 建構資料管道（ETL / ELT）
> **ETL**：Extract → Transform → Load；適用於 **批次處理**，資料量較大時可先儲存至資料湖，再做轉換。
> **ELT**：Extract → Load → Transform；適用於 **大數據平台**（如 Spark、Databricks），先將原始資料載入，再在資料倉儲內進行轉換。
### 3.2.1 典型資料管道架構
mermaid
flowchart TD
A[資料來源] --> B[資料收集層]
B --> C[資料湖 / Data Lakehouse]
C --> D[資料處理層]
D --> E[資料倉儲 / Data Warehouse]
E --> F[BI / 報表 / 研究]
### 3.2.2 實作工具
| 階段 | 工具 | 用途 |
| ---- | ---- | ---- |
| 提取 | **Python + Requests / BeautifulSoup**、**Scrapy**、**Airbyte**、**Fivetran** | 取得 Web / API 資料 |
| 轉換 | **Pandas / Dask**、**Spark**、**dbt** | 資料清洗、轉型 |
| 載入 | **Snowflake / BigQuery / Redshift**、**Delta Lake** | 儲存於資料倉儲 |
| 編排 | **Airflow / Prefect / Dagster** | 管道排程、監控 |
## 3.3 API 與 Web Scraping
### 3.3.1 API 使用
- **RESTful**：JSON、XML；
- **GraphQL**：一次查詢多個實體；
- **WebSocket**：實時資料流。
python
import requests
url = 'https://api.example.com/v1/users'
headers = {'Authorization': 'Bearer YOUR_TOKEN'}
response = requests.get(url, headers=headers)
users = response.json()
**最佳實踐**：
1. **速率限制**：遵守 `X-RateLimit-*` header；
2. **錯誤重試**：使用 `tenacity`；
3. **版本控制**：避免直接調用 `v1`，改用 `v2` 或 `preview`。
### 3.3.2 Web Scraping
- **BeautifulSoup**：簡易靜態頁面；
- **Selenium / Playwright**：動態頁面；
- **Scrapy**：大規模抓取。
python
from bs4 import BeautifulSoup
import requests
url = 'https://www.example.com/products'
page = requests.get(url)
soup = BeautifulSoup(page.content, 'html.parser')
for item in soup.select('.product'):
name = item.select_one('.name').text.strip()
price = item.select_one('.price').text.strip()
print(name, price)
> **注意**：尊重 robots.txt、避免對網站造成負載；若資料受版權保護，請先取得授權。
## 3.4 資料庫設計
### 3.4.1 交易型資料庫（OLTP）
- **關聯式**：MySQL、PostgreSQL、SQL Server。適用於日常交易、資料一致性要求高的情境。
- **結構化**：採用正規化，減少重複。
sql
CREATE TABLE orders (
order_id BIGINT PRIMARY KEY,
customer_id BIGINT NOT NULL,
order_date TIMESTAMP NOT NULL,
total_amount NUMERIC(12,2) NOT NULL,
status VARCHAR(20) NOT NULL
);
### 3.4.2 資料倉儲（OLAP）
- **星型/雪花型**：結合維度表與事實表，利於查詢。
- **分區與聚簇**：提高大表查詢效能。
sql
CREATE TABLE sales_fact (
sale_id BIGINT PRIMARY KEY,
product_id BIGINT,
customer_id BIGINT,
sale_date DATE,
quantity INT,
revenue NUMERIC(12,2)
) PARTITION BY RANGE (sale_date);
### 3.4.3 資料湖 (Data Lake)
- **原始資料**：保留原始 JSON、CSV、Parquet；
- **湖座 (Lakehouse)**：如 Delta Lake，提供 ACID 交易與版本控制。
## 3.5 資料治理、合規與隱私
| 原則 | 內容 | 具體實踐 |
| ---- | ---- | -------- |
| **資料品質** | 準確性、完整性、一致性 | **Great Expectations**、**Data Quality Dashboards** |
| **資料可追溯** | 來源、轉換、存儲 | **Metadata Catalog**（Amundsen、DataHub） |
| **資料安全** | 權限、審計 | **Lakehouse ACLs**、**Snowflake RBAC** |
| **隱私合規** | GDPR、CCPA、HIPAA | **Pseudonymisation**、**Data Masking**、**Consent Management** |
### 3.5.1 典型治理流程
1. **資料字典**：定義欄位、資料型別、範圍。
2. **資料質量規則**：缺失率、唯一性、正規化檢查。
3. **審計追蹤**：使用 `audit_log` 表記錄 CRUD 動作。
4. **資料保留策略**：根據法規設定保留期限與刪除流程。
> **案例**：某醫療保險公司將所有病歷資料加密後存入 Delta Lake，並使用 **OpenPolicyAgent (OPA)** 控制訪問權限，確保僅授權醫師可查閱特定病歷。
## 3.6 工具與流程實踐
| 分類 | 工具 | 主要功能 |
| ---- | ---- | -------- |
| **資料收集** | Airbyte、Fivetran、Python SDK | 連結多種資料來源 |
| **資料處理** | Apache Spark、Pandas、dbt | 批次轉換、增量更新 |
| **資料治理** | Great Expectations、Amundsen、DataHub | 資料品質檢測、元資料管理 |
| **資料安全** | Apache Ranger、Snowflake RBAC | 權限控制、審計 |
| **流程編排** | Airflow、Prefect、Dagster | 排程、監控 |
### 3.6.1 CI/CD 於資料管道
利用 **GitHub Actions** 或 **GitLab CI**，將資料管道程式碼推送至版本控制，透過自動化測試與部署，確保變更不破壞既有資料流。
yaml
# .github/workflows/data-pipeline.yml
name: Data Pipeline CI
on:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version: '3.10'
- name: Install dependencies
run: pip install -r requirements.txt
- name: Run tests
run: pytest tests/
## 3.7 案例與挑戰
### 案例 1：零售業客流預測
- **來源**：POS 系統（內部）、社群媒體、天氣 API（外部）。
- **管道**：Airbyte 將 POS 資料同步至 Snowflake；Airflow 排程天氣資料抓取；Spark 進行時間序列特徵擴充。 | **治理**：使用 Great Expectations 檢查 POS 資料完整度；資料庫採用 Snowflake RBAC 控制敏感資訊。 | **挑戰**：時區不一致、資料延遲、API 認證失效。
### 案例 2：金融風控信用評分
- **來源**：信用局（外部）、交易紀錄（內部）。
- **管道**：Fivetran 連結外部 API，Spark 進行特徵工程，Model 在 SageMaker 執行。 | **治理**：使用 Amundsen 建立資料線圖；使用 OPA 實作「僅風控團隊可存取信用分數」策略。 | **挑戰**：合規審核頻繁、資料更新速率高、模型漂移監控。
## 小結
- **資料蒐集** 不是單純「抓資料」，而是**對業務價值**、**合規性**與**可維護性**三重考量的平衡。
- 建構**可重複、可監控的資料管道**，並嵌入**資料治理**，能讓模型訓練與部署更具可持續性。
- **工具選擇** 應隨專案規模與技術棧調整；在大規模時可考慮 Spark、Delta Lake；小型則可用 Pandas + Airflow。
- **資料治理** 不是一次性工程，而是**持續迭代**，同時需要組織文化與政策的支援。
> **實戰建議**：先從最關鍵的資料來源做「資料品質金字塔」驗證，確保每一步都有可測試的品質指標；再逐步擴展至整體管道，形成可追溯、可治理的資料生態。