返回目錄
A
數據驅動決策：從分析到行動 - 第 2 章
第2章：資料蒐集與治理的藝術
發布於 2026-02-28 13:28
# 第2章：資料蒐集與治理的藝術
## 2.1 資料的起點：從需求到來源
資料科學的旅程，始於一個明確的「為什麼」。就像農夫先決定要種哪種作物，資料團隊必須先明白業務問題。
| 步驟 | 目的 | 典型問題 | 產出物 |
|------|------|----------|--------|
| 需求定義 | 讓業務與技術團隊對目標達成共識 | 目標模糊、指標不一致 | 需求文件、KPI列表 |
| 資料來源圖 | 可視化可用資料的分佈 | 資料孤島、重複資料 | 資料來源地圖、關聯圖 |
| 資料可行性評估 | 估算資料的質量、可用性 | 缺失、噪音 | 可行性報告、風險清單 |
> **案例**：某線上零售商想提升「推薦精準度」。他們先召集產品經理、行銷團隊與資料科學家，確定 KPI 為「平均客單價提升 10%」。接著列舉可用資料：使用者瀏覽歷史、購買紀錄、評價、社群媒體情緒。
## 2.2 來源多元，質量千差萬別
資料來源可分為**內部**與**外部**：
- **內部**：交易系統、CRM、行為追蹤。
- **外部**：公開資料集、第三方 API、社群媒體。
### 資料質量四大維度
1. **完整性**：缺失值比例
2. **一致性**：多源資料對照
3. **準確性**：實際值 vs 觀測值
4. **時效性**：資料更新頻率
> **技巧**：使用「資料健康檢查」工具，例如 Great Expectations 或 Deequ，定期自動驗證上述維度。
## 2.3 依法治理：隱私、合規與倫理
隨著資料量激增，合規成了硬硬的門檻。以下為實務操作流程：
1. **資料最小化**：只蒐集達成目標所需的欄位。
2. **匿名化 / 偽匿名化**：使用 K‑anonymity、Differential Privacy 等技術。
3. **資料存取權限**：基於角色的存取控制 (RBAC)。
4. **資料生命周期管理**：制定保留期、銷毀流程。
> **實例**：某銀行在構建風險評分模型時，將客戶身份資料匿名化，僅保留交易特徵，並在模型更新後即時刪除歷史資料，確保符合 GDPR 要求。
## 2.4 建立 ETL／ELT 流程：從「拉」到「推」
### 2.4.1 典型工作流程
```mermaid
graph TD
A[來源系統] -->|拉取| B[Staging]
B -->|清洗| C[Data Lake]
C -->|轉換| D[Data Warehouse]
D -->|分析| E[BI Dashboard]
```
- **Staging**：資料以原始形態存放，便於追溯。
- **Data Lake**：結構化、半結構化資料皆可。
- **Data Warehouse**：適合 OLAP 查詢。
### 2.4.2 工具選擇
| 類型 | 代表工具 | 特色 |
|------|----------|------|
| 數據管道 | Apache Airflow, Prefect | 可視化工作流，排程易於維護 |
| 數據建模 | dbt | 以 SQL 為主的轉換，版本控制友好 |
| 雲端倉儲 | Snowflake, BigQuery | 自動擴充，零管理 |
> **示範**：以下為一段 Airflow DAG，定時將日誌資料拉入 Staging。
```python
from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime
with DAG('daily_log_ingest', start_date=datetime(2023,1,1), schedule_interval='@daily') as dag:
t1 = BashOperator(
task_id='fetch_logs',
bash_command='aws s3 cp s3://bucket/logs/$(date +\"%Y-%m-%d\").json ./staging/'
)
t2 = BashOperator(
task_id='load_to_lake',
bash_command='aws glue start-job-run --job-name LogIngestJob'
)
t1 >> t2
```
## 2.5 資料治理大綱：從「資料血統」到「資料品質」
| 角色 | 責任 |
|------|------|
| 資料負責人 (Data Steward) | 定義資料標準、維持資料品質 |
| 資料架構師 (Data Architect) | 設計資料模型、確保可擴充 |
| 資料科學家 | 依據業務需求，選取合適資料 |
| 法務合規 | 驗證資料收集、使用符合規範 |
### 資料血統追蹤（Data Lineage）
- **定義**：資料從來源到最終使用者的完整旅程。
- **工具**：Alation, Collibra, Amundsen。
- **效益**：故障排除、合規審計、資料治理透明度。
## 2.6 小結與實踐建議
1. **需求為王**：始終以業務問題為導向，避免「資料收集就是收集」的心態。
2. **質量先行**：資料質量檢查應嵌入管道，而非事後修復。
3. **治理先於分析**：制定合規框架、資料治理流程，才能在後續建模中安心。
4. **工具是助力者**：選擇符合團隊能力、業務需求的工具，切勿盲目追求「最新」技術。
> **提示**：在實務中，往往是「資料可用」和「資料合規」之間的平衡。建議先建立「資料合規基準」，再根據業務價值進行「資料價值評估」。
---
> **小測驗**：
> 1. 你已經為資料治理建立了資料血統追蹤機制嗎？
> 2. 你是否在每個 ETL 步驟加入了質量驗證？
> 3. 你的資料團隊是否持續更新合規政策？
>
> **答案**：如果任何一項未達標，請在本章落實上述建議，為後續建模奠定堅實基礎。