第2章 數據基礎建設與治理

# 第2章 數據基礎建設與治理 本章將從企業資料科學的角度，深入探討構建可擴展、可靠且合規的數據基礎建設與治理機制。透過實際案例與工具選型，我們將呈現從原始資料湖到結構化資料倉儲的全流程，並說明如何確保資料品質、可追溯性與安全性。 ## 2.1 資料湖（Data Lake） | 項目 | 內容 | |------|------| | 定義 | 一種集中式存儲，容納原始結構化、非結構化與半結構化資料，採用分散式檔案系統，支持大數據工作負載。 | 核心特點 | * **彈性**：可按需擴充；<br>* **多樣性**：JSON、Parquet、CSV、圖片、音訊等；<br>* **即時可讀**：支持 Spark、Presto、Hive、SQL on Data Lake 等即時查詢。 | 典型工具 | Amazon S3 + Athena / EMR, Azure Data Lake Storage + Synapse, Google Cloud Storage + BigQuery, Snowflake External Tables, Databricks Delta Lake。 | 案例 | **零售業**：將 POS、物流、社群媒體互動等原始資料寫入 S3，並利用 Databricks 作為資料探索與機器學習平台。 ### 2.1.1 資料湖設計要點 1. **資料分層**： - *Raw*：未處理的原始資料。 - *Processed*：經過清洗、轉換後的中間資料。 - *Curated*：符合業務需求、可直接查詢的資料。 2. **Schema on Read**：延遲到查詢時再決定 schema，便於快速接入新資料來源。 3. **元資料管理**：利用 Glue Data Catalog、Lake Formation、AWS Glue 等工具自動生成元資料。 4. **安全控制**：角色基於策略（RBAC）與加密，確保合規性。 ## 2.2 資料倉儲（Data Warehouse） 資料倉儲是針對查詢優化的結構化儲存。與資料湖不同，它通常使用事先定義的 schema（Schema on Write）。 | 主要特性 | 說明 | |----------|------| | OLAP 優化 | 聚合、分區、列式存儲（如 Columnar Storage） | | ETL / ELT 支持 | 支援批量、即時資料匯入 | | 業務直覺 | 直觀的維度表、事實表 | | 工具範例 | Snowflake、Amazon Redshift、Google BigQuery、Azure Synapse、Oracle Autonomous Data Warehouse | ### 2.2.1 資料倉儲架構圖 mermaid graph TD A[資料源] --> B[ETL/ELT 工具] B --> C[資料湖 (Raw/Processed)] B --> D[資料倉儲 (Schema on Write)] D --> E[BI 工具] D --> F[機器學習] ### 2.2.2 典型資料倉儲設計 - **星型模型**：一個事實表與多個維度表。 - **雪花模型**：維度表進一步拆分，形成層次化維度。 - **聚合表**：預先聚合常見查詢，提升查詢速度。 ## 2.3 ETL / ELT 流程 | 步驟 | 主要工作 | 工具建議 | |------|-----------|----------| | Extract | 從各資料源擷取原始資料 | Airflow, Luigi, Azure Data Factory, AWS Glue, Talend | | Transform | 資料清洗、格式轉換、豐富化 | dbt, PySpark, Pandas, SQL | | Load | 寫入資料湖或資料倉儲 | Snowflake Connector, BigQuery API, Redshift COPY | > **ELT**：先將原始資料載入資料湖或倉儲，後續在目標系統內做轉換；適用於大規模數據。 > **ETL**：在資料來源端即完成轉換；適用於資料量較小或資料源限制。 ### 2.3.1 Airflow DAG 範例 python from airflow import DAG from airflow.providers.amazon.aws.operators.s3_copy_object import S3CopyObjectOperator from airflow.providers.amazon.aws.operators.redshift_copy import RedshiftCopyOperator from datetime import datetime with DAG( dag_id='etl_pipeline', start_date=datetime(2024, 1, 1), schedule_interval='@daily', catchup=False ) as dag: copy_s3_to_raw = S3CopyObjectOperator( task_id='copy_raw', source_bucket='source-bucket', source_key='raw/{{ ds }}/*.json', dest_bucket='lake-bucket', dest_key='raw/{{ ds }}/', ) load_to_redshift = RedshiftCopyOperator( task_id='load_redshift', table='staging.orders', s3_path='s3://lake-bucket/raw/{{ ds }}/*.json', copy_options=['json', 'auto'], ) copy_s3_to_raw >> load_to_redshift ## 2.4 資料品質管理（Data Quality Management） 資料品質直接影響分析結果與決策品質。常見品質指標包含： - **完整性**（Completeness） - **一致性**（Consistency） - **準確性**（Accuracy） - **時效性**（Timeliness） - **唯一性**（Uniqueness） ### 2.4.1 資料品質檢查規則表 | 規則 | 描述 | 範例 | |------|------|------| | NOT NULL | 欄位不可為空 | `customer_id IS NOT NULL` | | UNIQUE | 唯一性 | `ORDER_ID` 無重複 | | FOREIGN KEY | 參照完整 | `customer_id` 需存在於 `customers` 表 | | DATE RANGE | 日期範圍 | `order_date >= '2024-01-01'` | | FORMAT | 格式驗證 | `email ~* '^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}$'` | ### 2.4.2 工具與實踐 - **Great Expectations**：Python 框架，支持資料庫、Parquet、CSV 等。 - **AWS Glue DataBrew**：無程式資料品質檢查。 - **dbt tests**：在資料轉換階段嵌入測試。 sql -- dbt 範例：檢查 order_id 唯一性 SELECT order_id, COUNT(*) AS cnt FROM {{ ref('orders') }} GROUP BY order_id HAVING cnt > 1; ## 2.5 數據治理框架（Data Governance Framework） 治理是將策略、流程、技術與文化結合，以確保資料的可管理性、合規性與可用性。核心組件包括： 1. **資料策略（Data Strategy）**：企業層級對資料使用的願景與目標。 2. **角色與責任（Roles & Responsibilities）**：Data Owner、Data Steward、Data Curator、Data Engineer 等。 3. **元資料管理（Metadata Management）**：自動化元資料捕捉與可視化。 4. **資料血統（Lineage）**：追溯資料流向、變換歷程。 5. **存取控制（Access Control）**：基於角色、敏感資料分級、審計紀錄。 6. **合規性監控（Compliance Monitoring）**：GDPR、CCPA、PCI‑DSS、HIPAA 等。 ### 2.5.1 組合治理模型（Example Governance Stack） ┌───────────────────────────────┐ │ 企業治理委員會（Data Governance Board） │ └───────────────────────────────┘ │ ┌───────────────────────────────┐ │ 企業資料政策（Policies & Standards） │ └───────────────────────────────┘ │ ┌───────────────────────────────┐ │ 元資料目錄（Data Catalog） │ │ • AWS Glue Data Catalog │ • Azure Purview │ • Snowflake Information Schema └───────────────────────────────┘ │ ┌───────────────────────────────┐ │ ETL/ELT 工具（Airflow, dbt, dbt Cloud） │ └───────────────────────────────┘ │ ┌───────────────────────────────┐ │ 資料湖 / 資料倉儲（S3, Delta Lake, Snowflake） │ └───────────────────────────────┘ │ ┌───────────────────────────────┐ │ 端對端審計 & 監控（Lake Formation, AWS IAM, BigQuery IAM, Snowflake Role Hierarchy） │ └───────────────────────────────┘ > **治理重點**： > 1. **可追溯性**：每筆資料必須能追溯回其來源與轉換步驟。<br>2. **可執行性**：治理規則需嵌入資料管道，確保自動化執行。<br>3. **跨部門協作**：IT、法務、風控、業務必須在同一治理機制下協同。 ## 2.5 實作總結 | 步驟 | 目的 | |------|------| | 建立資料湖分層 | 支援多樣資料與即時探索 | | 設計星型/雪花模型 | 提升 OLAP 查詢效能 | | 配置 ETL / ELT | 保證資料流轉的可擴展性 | | 內嵌資料品質測試 | 保障資料可靠性 | | 實施元資料與血統管理 | 促進資料可追溯與治理 | | 執行安全與合規策略 | 確保資料合規性 | > **實際落地要點**： > - **先定義業務需求**，再選擇湖或倉，避免後期架構改動。 > - **分層儲存**與 **元資料管理** 必不可少，能大幅降低資料治理成本。 > - **自動化測試** 與 **CI/CD**（如 dbt、Airflow、GitHub Actions）能把治理落到程式碼層面。 > - **安全設計** 需同時兼顧加密、存取控制與審計紀錄，特別是在金融、醫療等高度合規行業。 --- > **延伸閱讀**： > - *“Designing Data-Intensive Applications”*（Martin Kleppmann） > - *Snowflake Snowpark 官方文件*、*Databricks Delta Lake Guide* > - *Great Expectations Cookbook* 本章結束後，讀者將能獨立設計一套從資料湖到資料倉儲的完整管道，並具備資料品質與治理的實務落地能力。