返回目錄
A
決策的數據語言：從原始數據到洞察力 - 第 2 章
第 2 章：數據採集與儲存
發布於 2026-03-03 08:48
# 第 2 章：數據採集與儲存
在數據科學的流程中，**數據採集與儲存**是決定後續分析品質與效率的基石。本章將帶領讀者從原始資料的取得，到結構化與非結構化資料的儲存，並探討設計資料管道時必須考量的關鍵原則與實務範例。
---
## 2.1 何謂「數據採集」？
- **定義**：從外部或內部來源，使用各種技術手段將資訊轉換成機器可讀的格式。<br>
- **分類**：
- **結構化資料**：表格、資料庫、CSV。<br>
- **半結構化資料**：JSON、XML、YAML。<br>
- **非結構化資料**：文字、圖片、影片、音訊。
- **目標**：保留資料完整性、可追溯性與可擴充性，為「資料品質管理」與「資料治理」奠定基礎。
---
## 2.2 API（Application Programming Interface）採集
### 2.2.1 為什麼選擇 API？
| 優點 | 說明 |
|------|------|
| **即時性** | 透過 REST / GraphQL 可在毫秒級取得最新數據。 |
| **結構化** | 回傳 JSON / XML，方便直接轉換為 DataFrame。 |
| **授權機制** | OAuth、API Key 可確保資料安全。 |
| **可測試性** | 可用 Postman / curl 進行單元測試。 |
### 2.2.2 實作範例：使用 Python 取得 Twitter Streaming API
python
import requests
import json
# 1. 設定授權資訊（示例，實務上請勿硬編碼）
headers = {
"Authorization": "Bearer YOUR_ACCESS_TOKEN"
}
# 2. 發送 GET 請求（此為舊版 REST 範例）
url = "https://api.twitter.com/2/tweets/search/recent"
params = {
"query": "#DataScience -is:retweet",
"max_results": 100
}
response = requests.get(url, headers=headers, params=params)
# 3. 解析回傳 JSON
tweets = response.json()
print(json.dumps(tweets, indent=2, ensure_ascii=False))
> **實務建議**：使用 `aiohttp` 或 `httpx` 進行非同步呼叫，可大幅提升吞吐量。
---
## 2.3 Web Scraping
### 2.3.1 適用場景
- 無法透過官方 API 取得資料。<br>
- 需要收集公開網站中的表格、文章或評論等資料。
### 2.3.2 工具與框架
| 工具 | 說明 |
|------|------|
| BeautifulSoup | Python HTML 解析，適合簡單抓取。 |
| Scrapy | 完整的爬蟲框架，支援分布式、異步。 |
| Selenium | 需要執行 JavaScript 的網站可使用。 |
### 2.3.3 範例：Scrape 商品價格
python
import requests
from bs4 import BeautifulSoup
url = "https://www.example.com/products/123"
headers = {"User-Agent": "Mozilla/5.0"}
response = requests.get(url, headers=headers)
soup = BeautifulSoup(response.text, "html.parser")
price = soup.select_one("span.price").text.strip()
print(f"商品價格：{price}")
> **注意**：遵守網站的 robots.txt 規範，避免對服務造成過度負載。
---
## 2.4 資料倉儲（Data Warehouse） vs 資料湖（Data Lake）
| | 資料倉儲 | 資料湖 |
|---|---|---|
| **資料類型** | 結構化 | 非結構化、半結構化與結構化 |
| **模式** | 模式先行（Schema‑on‑write） | 模式後行（Schema‑on‑read） |
| **使用者** | 業務分析師、BI 工具 | 數據科學家、機器學習工程師 |
| **技術棧** | Snowflake、Redshift、BigQuery | Hadoop、AWS S3、Azure Data Lake Storage |
| **主要用途** | 報表、OLAP | 大數據處理、資料探索 |
### 2.4.1 資料倉儲設計原則
1. **主題導向**：以業務主題（如銷售、客戶、財務）作為分區。<br>
2. **星型 / 雪花型模型**：主表 (Fact) + 事實維度 (Dimension)。<br>
3. **ETL/ELT 流程**：提取 → 轉換 → 加載；或提取 → 加載 → 轉換。<br>
4. **資料治理**：版本控制、資料品質審核、資料字典管理。
### 2.4.2 資料湖設計原則
1. **分層架構**：Raw、Curated、Refined 三層。<br>
2. **資料格式**：原始資料儲存為 Parquet / ORC；結構化資料可轉成 Delta Lake。<br>
3. **資料分類**：使用元資料 (Metadata) 進行標記，便於搜尋與重複使用。<br>
4. **存取權限**：使用 IAM、ACL 或 Lake Formation 等工具進行細粒度授權。
---
## 2.5 設計資料管道的關鍵考量
| 步驟 | 重要點 | 工具範例 |
|------|--------|----------|
| **需求定義** | 商業 KPI、資料來源、更新頻率 | 需求文檔、Stakeholder 會議 |
| **資料來源評估** | API、文件、傳感器、第三方資料 | Postman、SFTP、MQTT |
| **ETL/ELT 工程** | 可擴充、可重複使用、容錯 | Airflow、Prefect、Databricks Jobs |
| **資料品質** | 完整性、正確性、時效性 | Great Expectations、dbt |
| **安全與合規** | 加密、審計、隱私保護 | Vault、Snowflake Vault Integration |
| **監控與告警** | 成功率、延遲、資源利用率 | Prometheus、Grafana |
### 2.5.1 實務示例：金融交易數據管道
1. **來源**：交易系統 REST API + 日誌檔案。<br>
2. **ETL 工具**：Airflow DAG，使用 PythonOperator 下載 API，Spark 作業做資料清洗。<br>
3. **儲存**：Raw 資料放於 S3 Glacier，Curated 資料寫入 Snowflake。<br>
4. **資料品質**：利用 Great Expectations 在 Spark 作業中校驗欄位非空、數值範圍。<br>
5. **監控**：Airflow UI + Grafana 監控 DAG 執行時間，失敗即發送 Slack 通知。
---
## 2.6 小結
- **數據採集**：選擇合適的技術（API、Web Scraping）以符合資料時效與結構化需求。<br>
- **儲存結構**：資料倉儲適合業務報表，資料湖則更適合機器學習與大數據探索。<br>
- **設計原則**：從商業需求出發，結合資料品質、安全合規與可監控性，構築穩定且可擴充的資料管道。<br>
- **下一章**：將深入「數據清洗與前處理」，說明如何將「原始」資料轉化為「可分析」的乾淨資料集。
> **實務提示**：在每一步都加入版本控制（Git、DVC）與自動化測試，確保資料流的可追溯性與可靠性。