第2章 數據採集與存取

# 第2章 數據採集與存取 > **核心觀點**：資料來源決定了後續分析的深度與廣度，合理規劃採集與存取流程能為整個數據科學項目奠定堅實基礎。 ## 2.1 資料來源分類 在實務上，資料來源可大致分為三類： 1. **結構化資料** * 典型形式：關係型資料庫、CSV/TSV、Excel。 * 優點：易於驗證、符合模式、查詢高效。 * 典型案例：交易系統（Salesforce、SAP）、金融風險評估（交易日誌）。 2. **非結構化資料** * 典型形式：文字文件、PDF、影像、音訊、影片、社群媒體貼文。 * 優點：豐富語義，能提供深度洞察。 * 典型案例：客戶服務聊天紀錄、產品使用者評論、網路攝影機錄像。 3. **即時/流資料** * 典型形式：Kafka、Kinesis、Pub/Sub、WebSocket。 * 優點：支持實時監控、預警與動態決策。 * 典型案例：金融市場行情、IoT 感測器、網站點擊流。 ### 資料來源選型指標 | 指標 | 重要性 | 評估要點 | |------|--------|----------| | **資料量** | ★★★ | 需要的存儲容量與計算資源。 | **更新頻率** | ★★ | 是否需要批處理或即時處理。 | **結構化程度** | ★★★ | 是否可直接映射至資料模型。 | **成本** | ★★ | 取得、傳輸與存儲成本。 | **合規風險** | ★★ | 個人資料、版權、機密性。 > **實務建議**：在規劃專案初期，先以「資料源清單」完成可視化圖，標示每個來源的類別、頻率與存取方式，避免後續出現資料孤島或重複抓取。 ## 2.2 ETL 與 ELT > **ETL**：Extract ➜ Transform ➜ Load（提取 → 轉換 → 載入）。 > **ELT**：Extract ➜ Load ➜ Transform（提取 → 載入 → 轉換）。 ### 2.2.1 ETL - **優點**： * 在將資料載入目標系統前即完成清洗與轉換，確保載入後資料一致。 * 適用於傳統資料倉儲（RDBMS）與較舊的 BI 工具。 - **缺點**： * 轉換步驟耗費時間，對即時性要求高的場景不友善。 - **典型工具**：Informatica PowerCenter、Talend、IBM DataStage。 ### 2.2.2 ELT - **優點**： * 利用現代資料庫（如 Snowflake、BigQuery、Azure Synapse）內建的高效計算引擎進行轉換，減少 ETL 伺服器壓力。 * 支持大規模即時資料處理與資料湖（Data Lake）架構。 - **缺點**： * 需要目標系統具備足夠的計算與儲存能力。 - **典型工具**：dbt、Apache Spark、Snowflake Snowpipe。 ### 2.2.3 何時選擇 ETL vs ELT | 场景 | 建議流程 | |------|----------| | **批處理、歷史資料聚合** | ETL（事先轉換，保持資料品質） | | **大數據、即時資料** | ELT（先載入，後利用分布式引擎轉換） | | **合規要求高、需要資料治理** | ETL（轉換時即加入治理規則） | | **資料湖佈署** | ELT（將原始資料載入湖中，隨需轉換） | ## 2.3 數據湖與資料倉儲 ### 2.3.1 數據湖（Data Lake） - **定義**：將原始資料以其原生格式（如 Parquet、JSON、Avro）直接存入分佈式檔案系統（HDFS、S3、Azure Data Lake Storage）。 - **特點**： * **Schema‑On‑Read**：讀取時再定義結構，適合探索性分析。 * **低成本**：存儲成本低，支援大規模數據。 * **靈活性**：可同時存放結構化、半結構化與非結構化資料。 - **典型應用**：機器學習訓練資料集、原始日誌、物聯網感測資料。 ### 2.3.2 資料倉儲（Data Warehouse） - **定義**：為商業分析而設計的資料庫，通常採用 **Schema‑On‑Write**，在載入前就定義好資料模式。 - **特點**： * **OLAP**：適合複雜查詢、報表與分析。 * **高一致性**：資料經過清洗、校驗，確保品質。 * **性能優化**：使用星型、雪花型模式、分區與聚簇索引。 - **典型應用**：BI 報表、營收報表、客戶分析。 ### 2.3.3 結合使用策略 1. **先在數據湖收集原始資料**，保持資料完整與彈性。 2. **使用 ETL/ELT 將經過治理的資料抽取、轉換後載入資料倉儲**，供 BI 與決策使用。 3. **將資料湖與資料倉儲透過元資料管理層（Data Catalog）整合**，確保資料的可追溯性。 ## 2.4 典型工作流程示範 以下示範一個從資料來源到資料倉儲的完整流程，使用 Apache Airflow 進行排程與監控。 python # airflow-dag.py from datetime import datetime, timedelta from airflow import DAG from airflow.providers.apache.spark.operators.spark_submit import SparkSubmitOperator from airflow.operators.bash import BashOperator default_args = { 'owner': 'data_team', 'depends_on_past': False, 'retries': 1, 'retry_delay': timedelta(minutes=5), } dag = DAG( 'ingest_and_transform', default_args=default_args, schedule_interval='@daily', start_date=datetime(2024, 1, 1), catchup=False, ) # 1. 抓取結構化資料 extract_sql = BashOperator( task_id='extract_sql', bash_command='pg_dump -U user -h host db > /data_lake/raw/transactions/transactions_{{ ds }}.sql', dag=dag, ) # 2. 載入數據湖（ELT） load_to_lake = SparkSubmitOperator( task_id='load_to_lake', conn_id='spark_local', application='/spark/convert_to_parquet.py', dag=dag, ) # 3. 轉換並載入資料倉儲（ETL） transform_and_load = dbt.DbtRunOperator( task_id='dbt_transform', dir='/dbt_project', dag=dag, ) extract_sql >> load_to_lake >> transform_and_load > **重點**：在 DAG 中使用**回滾機制**與**告警**，確保任何一個步驟失敗時都能即時通知資料團隊，避免「資料缺口」影響商業決策。 ## 2.5 實務小貼士 | 實務點 | 說明 | |--------|------| | **資料品質先行檢核** | 在 ETL/ELT 前先用 **Data Quality Rules**（缺失值、重複、異常）驗證。 | **元資料管理** | 建立 Data Catalog（如 Amundsen、DataHub），並自動掃描資料湖與倉儲。 | **安全性分層** | 使用 IAM、存取權限、加密（SSE‑S3、AES‑256）來保護敏感資料。 | **彈性伸縮** | 在雲環境下採用 **Spot Instances** 或 **Auto‑Scaling** 以降低成本。 | **成本追蹤** | 定期審查存儲使用量與處理成本，對比專案 KPI，確保投資回報。 ## 小結 - **資料來源分類** 為採集策略決策提供指引。 - **ETL 與 ELT** 兩種資料搬移模式各有適用場景，需根據資料量、更新頻率與合規性選擇。 - **數據湖** 與 **資料倉儲** 可結合使用，保證資料完整性與分析性能。 - **排程與監控**（如 Airflow）是確保流程可靠運作的關鍵。 > **下一步**：在第3章中，我們將深入探討資料治理與元資料管理，確保這些採集與存取流程產生的資料能在整個組織內被有效利用。 --- > **延伸閱讀**： > - 《設計資料湖與資料倉儲》 > - 《Data Engineering Handbook》