返回目錄
A
資料洞察：企業數據分析與決策支援全攻略 - 第 2 章
第 2 章：數據蒐集與儲存架構
發布於 2026-03-01 11:47
# 第 2 章：數據蒐集與儲存架構
本章聚焦於企業如何從各種來源有效收集資料，並根據不同需求選擇合適的儲存解決方案。內容分為內部與外部資料來源、蒐集策略、ETL/ELT 流程、雲端與本地存儲、資料湖與資料倉、資料治理、技術選型、合規安全以及實際案例。
---
## 2.1 內部資料來源
| 資料類型 | 典型來源 | 特色與挑戰 |
|---|---|---|
| 業務交易資料 | ERP、CRM、POS 系統 | 高頻、結構化；需保持即時性與一致性 |
| 事件日誌 | Web 伺服器、應用程式、IoT 裝置 | 半結構化/非結構化；大量、速率高 |
| 內部文件 | SharePoint、企業郵件、協同平台 | 結構化程度低；版控與權限管理困難 |
| 人力資源 | HRIS、考勤系統 | 法規合規要求高；資料保留政策複雜 |
> **實務提示**：在設計資料蒐集時，先確認資料是否符合 *Data Governance* 需求（合法性、可追溯性、保留週期），避免後續合規風險。
## 2.2 外部資料來源
| 來源類型 | 典型服務 | 典型使用案例 |
|---|---|---|
| 公開資料集 | 政府統計、氣象、衛生數據 | 供需預測、風險評估 |
| 第三方 API | Google Maps、OpenWeather、社交媒體 API | 位置分析、情緒分析 |
| 資料交易市場 | Nielsen、Experian、Crunchbase | 市場趨勢、客戶分層 |
| 合作夥伴資料 | 供應商 ERP、物流追蹤 | 跨部門協同、供應鏈可視化 |
> **注意**：外部資料往往伴隨授權、費用、資料品質不確定等風險，需先行簽訂 SOW（服務協議）並建立資料驗證流程。
## 2.3 資料蒐集策略
1. **需求分析**：與業務部門共創「資料需求矩陣」，明確資料來源、頻率、精度。
2. **合法性審核**：確定資料蒐集符合 GDPR、個人資料保護法、SOX 等法規。
3. **技術選型**：選擇適合的采集技術（ETL、Stream、CDC 等）。
4. **安全規劃**：在傳輸階段使用 TLS/SSL，並在儲存前加密敏感欄位。
5. **監測與調整**：部署監控面板，追蹤采集速率、失敗率，並根據 KPI 進行優化。
## 2.4 ETL/ELT 流程
> **ETL**（Extract‑Transform‑Load）適合資料量較小、結構化程度高的場景；
> **ELT**（Extract‑Load‑Transform）則更適合大數據湖，利用雲端資料倉的計算資源進行後續轉換。
### 2.4.1 Airflow DAG 範例
python
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
from datetime import datetime, timedelta
# 1. 提取
def extract(**kwargs):
# 連接外部 API 並取得 JSON
import requests
resp = requests.get("https://api.example.com/data")
data = resp.json()
# 暫存至 S3
import boto3
s3 = boto3.client('s3')
s3.put_object(Bucket='raw-bucket', Key='data.json', Body=json.dumps(data))
return data
# 2. 轉換
def transform(**kwargs):
ti = kwargs['ti']
data = ti.xcom_pull(task_ids='extract')
# 進行清洗與標準化
cleaned = [{'id': d['id'], 'value': float(d['value'])} for d in data]
return cleaned
# 3. 加載
def load(**kwargs):
cleaned = kwargs['ti'].xcom_pull(task_ids='transform')
# 加載至 Snowflake
import snowflake.connector
ctx = snowflake.connector.connect(...)
cs = ctx.cursor()
for row in cleaned:
cs.execute("INSERT INTO raw_table (id, value) VALUES (%s, %s)", (row['id'], row['value']))
cs.close()
ctx.close()
with DAG('data_pipeline', schedule_interval='@daily', start_date=datetime(2024, 1, 1), catchup=False) as dag:
t1 = PythonOperator(task_id='extract', python_callable=extract)
t2 = PythonOperator(task_id='transform', python_callable=transform, provide_context=True)
t3 = PythonOperator(task_id='load', python_callable=load, provide_context=True)
t1 >> t2 >> t3
> **Tip**：對於大批量資料，可使用 Spark 作業或 Flink 作實時處理，並將結果寫入資料倉。
## 2.5 雲端 vs 本地儲存
| 需求 | 雲端解決方案 | 本地解決方案 |
|---|---|---|
| 成本 | S3、Blob Storage、Data Lake Storage（儲存低成本） | 大型磁碟陣列、NAS（前期投資高） |
| 合規 | 必須符合資料主權法規（如 EU‑GDPR、台灣個資法） | 內部控制較易，資料主權可完全掌控 |
| 擴展 | 彈性伸縮，按需付費 | 需預估容量，擴充成本較高 |
| 延遲 | 取決於網路、API 延遲 | 近即時，延遲可低至毫秒 |
| 運維 | 由雲端供應商管理硬體、備份 | 需自行維護、備份、災備 |
### 雲端典型方案
| 服務 | 主要特點 | 典型用例 |
|---|---|---|
| AWS S3 + Glue + Athena | 物件儲存 + ETL + Serverless 查詢 | 大型數據湖、資料探索 |
| Azure Data Lake Storage Gen2 + Synapse | HDFS 兼容 + 大數據分析 | 企業資料倉、混合雲 |
| GCP BigQuery | 完全 Serverless 資料倉 | 低成本、即時分析 |
### 本地解決方案
| 系統 | 優勢 | 缺點 |
|---|---|---|
| Snowflake（私有雲） | 雲原生、彈性 | 需要自行部署雲基礎設施 |
| Hadoop HDFS | 大容量、分布式 | 需要自行維護集群 |
| Teradata | 專業資料倉 | 成本高、部署複雜 |
## 2.6 資料湖 vs 資料倉
- **資料湖**：存放原始格式（JSON、Parquet、CSV），適合探索性分析、機器學習；
- **資料倉**：預先轉換為結構化模式（星型、雪花型），適合報表、BI。
mermaid
graph LR
A[資料源] --> B{ETL/ELT}
B -->|Raw| C[資料湖]
B -->|Transformed| D[資料倉]
C -->|探索| E[資料科學家]
D -->|報表| F[BI 使用者]
> **最佳實踐**：先建資料湖，做探索、機器學習；再透過資料倉提供業務報表。
## 2.7 資料治理在儲存層面
| 域 | 具體措施 |
|---|---|
| 元資料管理 | 建立資料目錄（Data Catalog）、自動化元資料抓取 |
| 存取控制 | 基於角色的存取控制（RBAC）、最小權限原則 |
| 資料分類 | 靈敏度分級（PII、敏感、非敏感） |
| 版本管理 | 使用 Delta Lake、Iceberg 等檔案格式支持快照 |
| 合規追蹤 | 審計日誌、資料使用歷史、合規報表 |
## 2.8 大數據技術選型
| 技術 | 主要用途 | 適用場景 |
|---|---|---|
| Hadoop MapReduce | 批量處理 | 大批量歷史資料處理 |
| Spark | 批量+實時混合 | 需要高效數據處理、機器學習 |
| Flink | 真實時流處理 | 需要毫秒級回應的事件流 |
| Kafka | 分布式訊息隊列 | 資料流、事件驅動架構 |
| Delta Lake / Iceberg | 資料湖元資料管理 | 版本控制、ACID 交易 |
> **選型指導**：以資料量、處理頻率、資料結構決定，並考量團隊熟悉度與成本。
## 2.9 儲存安全與合規
1. **加密**：靜態儲存加密（AES‑256）、傳輸加密（TLS 1.2+）
2. **審計**：所有資料存取均記錄、可追溯
3. **資料主權**：依照所在地區選擇雲區域或本地部署
4. **合規**：定期進行資料風險評估、資料保留政策審查
5. **災備**：多區域備份、災難復原演練
## 2.10 案例研究：零售業數據湖建置
| 步驟 | 描述 | 技術棧 |
|---|---|---|
| 需求定義 | 追蹤商品銷售、庫存、客戶行為 | 需求矩陣、業務 KPI |
| 資料蒐集 | POS、會員卡、網站 Click‑stream | Kafka、REST API |
| ETL | Airflow + Spark | Airflow, Spark, Python |
| 儲存 | AWS S3 + Glue + Athena | S3, Glue, Athena |
| 資料治理 | AWS Lake Formation、IAM | Lake Formation, IAM |
| 探索與報表 | Tableau、Power BI | Tableau, Power BI |
| 機器學習 | 需求預測、個人化推薦 | SageMaker, TensorFlow |
> **結果**：數據湖建立後，商品需求預測準確率提升 18%，庫存週轉率提升 12%。
## 2.11 小結
- **數據蒐集**：先確定業務需求與法規合規，再選擇合適的採集技術。
- **ETL/ELT**：根據資料特性與處理量選擇流程，並使用自動化工具降低人為錯誤。
- **儲存解決方案**：雲端與本地各有優缺點，企業應綜合成本、合規與延遲需求做決策。
- **資料湖/倉**：先建資料湖，後構建資料倉以支援報表與決策。
- **治理與安全**：元資料管理、存取控制、加密與審計是不可或缺的基石。
- **技術選型**：依據資料量、處理頻率與團隊熟悉度，挑選 Hadoop、Spark、Flink 等。
> **下一章**：資料清理與品質管理，將詳細說明重複、缺失值處理、標準化以及品質指標設計。