核心設計策略深度解析

1. 主檔管理策略（Master Data Management）

想像一下，如果圖書館裡，櫃台人員、管理員、採購部門各自都有一份自己的的會員名冊。

• 一位會員來櫃台更新了他的電話號碼。
• 但採購部門在通知他預定的新書到貨時，打的還是舊號碼。
• 管理員在寄送年度報告時，用的地址也是舊的。

這就是資料不一致所導致的混亂，而且是我們日常生活中永遠都會遇到的困擾。在企業中，這種混亂的代價是巨大的：送錯貨、開錯發票、失去客戶。

主檔管理(MDM) 的核心目的，就是為了解決這個混亂，建立一個全組織公認的、唯一的、可信的資料來源。

核心設計哲學：

單一事實來源（Single Source of Truth）

這是 MDM 的靈魂。它強制規定：「關於『客戶』的權威資料，只能從我這裡拿；關於『商品』的標準資訊，也只能問我。」

它不是資料的儲存中心，不是所有資料都放這裡。它是資料的權威中心，定義了最關鍵、最核心資料的「正確版本」。其他系統（如訂單系統、物流系統）可以複製這份資料去使用，但當需要最準確的資料時，都必須回來向主檔系統查詢。

快速摘要

• 所有系統都從同一個主檔獲取基礎資料
• 避免資料不一致的根本解決方案
• 減少維護成本和錯誤風險

參考資料與交易資料分離

• 主檔（參照資料）：
  • 本質：業務中的「名詞」。它們是相對靜態的、被反覆參考的實體。
  • 特性：變化緩慢，但一旦變更，影響範圍極廣。
  • 例子：股票上市代碼、客戶基本資料、商品規格、分店地址、國家代碼。
• 交易資料(行為依據資料)：變化頻繁、時效性要求高
  • 本質：業務中的「動詞」。它們是描述某個時間點發生的「事件」。
  • 特性：頻繁產生、數量龐大、通常產生後就不再修改。
  • 例子：一筆訂單、一次付款、一條出貨紀錄。

我們可以這樣想：一筆「訂單」（交易資料）會參考「客戶是誰」以及「買了什麼商品」（主檔資料）。

如果沒有主檔，每筆訂單裡都要重複記錄完整的客戶地址和商品描述，一旦客戶搬家，我們就得去修改歷史上所有的訂單，那是不可能的。

版本控制與時效性管理

生效日期 → 活躍期 → 失效日期 → 歷史保存

graph TB
    subgraph "主檔變更觸發"
        A[主檔資料更新] --> B[EventBridge 發布變更事件]
        B --> C{變更類型判斷}
    end

    subgraph "即時同步處理"
        C -->|客戶主檔變更| D[客戶服務系統]
        C -->|商品主檔變更| E[商品服務系統]
        C -->|供應商主檔變更| F[供應鏈系統]

        D --> D1[更新客戶快取]
        D1 --> D2[重新計算信用額度]
        D2 --> D3[更新風險評級]

        E --> E1[更新商品快取]
        E1 --> E2[重新計算庫存策略]
        E2 --> E3[調整推薦演算法]

        F --> F1[更新供應商快取]
        F1 --> F2[重新評估採購策略]
        F2 --> F3[調整付款條件]
    end

    subgraph "下游系統更新"
        D3 --> G[CRM 系統更新]
        E3 --> H[電商平台更新]
        F3 --> I[ERP 系統更新]

        G --> G1[銷售團隊通知]
        H --> H1[網站商品頁更新]
        I --> I1[財務部門通知]
    end

    subgraph "一致性檢查與回滾機制"
        G1 --> J{一致性驗證}
        H1 --> J
        I1 --> J

        J -->|驗證通過| K[更新完成通知]
        J -->|驗證失敗| L[觸發補償機制]

        L --> L1[記錄失敗原因]
        L1 --> L2[執行回滾操作]
        L2 --> L3[發送告警通知]
        L3 --> L4[人工介入處理]
    end

    subgraph "審計與監控"
        K --> M[記錄完整審計軌跡]
        L4 --> M
        M --> N[CloudWatch 指標更新]
        N --> O[儀表板即時更新]
        O --> P[合規報告生成]
    end

這是 MDM 在實務上最複雜也最價值的部分。主檔資料雖然變化慢，但終究會變，這意味著主檔不能只有「當前狀態」，它必須能回答：

• 「這個商品在過去某個時間點的價格是多少？」
• 「這個客戶在未來某個時間點的地址將會是什麼？」

所以， 生效日期 → 活躍期 → 失效日期 的生命週期管理，以及 AWS 範例程式碼中，同時有 master_data_versions（歷史版本表）和 master_data_current（當前活躍版本表 的設計，正是為了實現這種跨越時間的資料查詢能力。

這對於財務對帳、法律合規和商業分析至關重要。

基本讀寫流程

graph TD
    subgraph "寫入流程 update_master_record"
        A[開始更新請求] --> B(在 RDS 中開始事務)
        B --> C{1. 寫入新版本到<br/>master_data_versions}
        C --> D{2. 檢查是否立即生效}
        D -->|是| E{3. 更新 master_data_current}
        E --> F[4. 失效 ElastiCache 中的相關快取]
        F --> G[5. 透過 EventBridge 發布變更事件]
        G --> H(提交 RDS 事務)
        D -->|否 未來生效| H
        H --> I[結束]
    end

    subgraph "讀取流程 get_master_data"
        J[開始讀取請求] --> K{查詢歷史資料?}
        K -->|否 查詢當前資料| L{1a. 在 ElastiCache 中查詢快取}
        L -->|快取命中| M[返回快取資料]
        L -->|快取未命中| N{2a. 在 RDS master_data_current 中查詢}
        N --> O{找到資料?}
        O -->|是| P[3a. 將資料寫回 ElastiCache]
        P --> Q[返回資料]
        O -->|否| Q

        K -->|是 查詢歷史資料| R{1b. 在 RDS master_data_versions 中<br/>查詢特定時間點版本}
        R --> Q
        M --> S[結束]
        Q --> S
    end

寫入邏輯 (update_master_record)：

• 事務性：將所有寫入操作包裹在 transaction 中，確保了「要麼全部成功，要麼全部失敗」的原子性。
• 版本控制：同時寫入 versions 表和 current 表，完美實現了歷史追溯與當前查詢效能的平衡。
• 快取失效：在資料更新後，立刻執行快取失效，保證了資料的一致性。
  讀取邏輯 (get_master_data)：
• 快取優先 (Cache-Aside)：先查快取，沒有再查資料庫，並回填快取。這是最經典的快取模式。
• 支援時間旅行 (Time-Travel)：能夠根據 as_of_date 參數查詢特定時間點的歷史資料，這是 MDM 系統最有價值的功能之一。

AWS 實現：企業級主檔管理系統

AWS 服務架構組合

• RDS (PostgreSQL)：作為「單一事實來源 (SSoT)」，利用其事務能力（ACID）保證核心資料的強一致性，這是 MDM 的基石。選擇正確。
• ElastiCache (Redis)：作為「分發快取」，緩解主資料庫的讀取壓力，為下游系統提供高效能的資料存取。這是標準的高效能架構模式。
• DynamoDB：雖然 RDS 也能記錄變更，但使用 DynamoDB 可以建立一個快速、可擴展、獨立的審計日誌 (Audit Log)，供其他系統高速查詢變更歷史，而不會影響主資料庫效能。
• EventBridge：作為「事件通知」中心，在主檔變更後，主動通知所有相關系統。這實現了系統間的松耦合，是現代微服務架構的關鍵。

# 企業級主檔管理系統的 AWS 服務配置
MasterDataManagementServices:
  # 核心資料存儲層
  CoreStorage:
    PrimaryDatabase:
      Service: "Amazon RDS PostgreSQL"
      Instance: "db.r6g.2xlarge"
      Storage: "2TB gp3 SSD"
      MultiAZ: true
      ReadReplicas: 3
      BackupRetention: 35
      Encryption: "AES-256"

    VersioningStore:
      Service: "Amazon DynamoDB"
      TableName: "master-data-versions"
      BillingMode: "ON_DEMAND"
      GlobalTables: true
      PointInTimeRecovery: true

  # 分散式快取層
  CacheLayer:
    DistributedCache:
      Service: "Amazon ElastiCache Redis"
      NodeType: "cache.r6g.xlarge"
      Nodes: 3
      ClusterMode: true
      Encryption: "in-transit and at-rest"

    CDNCache:
      Service: "Amazon CloudFront"
      Origins: "ALB + ElastiCache"
      TTL: "3600 seconds"

  # 事件處理與通知
  EventProcessing:
    EventBus:
      Service: "Amazon EventBridge"
      Rules: "master-data-change-*"
      Targets: ["Lambda", "SQS", "SNS"]

    MessageQueue:
      Service: "Amazon SQS"
      Type: "FIFO Queue"
      VisibilityTimeout: "300s"
      DeadLetterQueue: true

    Notifications:
      Service: "Amazon SNS"
      Topics: ["master-data-updates", "system-alerts"]
      Subscriptions: ["Email", "SMS", "Lambda"]

  # 計算與處理
  ComputeServices:
    APIGateway:
      Service: "Amazon API Gateway"
      Type: "REST API"
      Authentication: "AWS Cognito"
      RateLimit: "1000 req/sec"

    BusinessLogic:
      Service: "AWS Lambda"
      Runtime: "Python 3.11"
      Memory: "1024 MB"
      Timeout: "15 minutes"
      Concurrency: "100"

    BackgroundProcessing:
      Service: "Amazon ECS Fargate"
      CPU: "2 vCPU"
      Memory: "4 GB"
      AutoScaling: true

  # 監控與審計
  ObservabilityStack:
    Monitoring:
      Service: "Amazon CloudWatch"
      Metrics: "Custom + Built-in"
      Alarms: "20+ alerts"
      Dashboards: "Executive + Technical"

    Logging:
      Service: "Amazon CloudWatch Logs"
      RetentionPeriod: "90 days"
      LogGroups: "by service"

    Tracing:
      Service: "AWS X-Ray"
      SamplingRate: "10%"
      TracingEnabled: true

    AuditTrail:
      Service: "AWS CloudTrail"
      LogFileValidation: true
      MultiRegion: true

  # 安全與合規
  SecurityServices:
    IdentityManagement:
      Service: "AWS IAM"
      Roles: "least-privilege"
      Policies: "resource-based"

    SecretsManagement:
      Service: "AWS Secrets Manager"
      AutoRotation: true
      CrossRegionReplication: true

    KeyManagement:
      Service: "AWS KMS"
      KeyRotation: "annual"
      CustomerManagedKeys: true

    NetworkSecurity:
      Service: "AWS VPC"
      Subnets: "private + public"
      SecurityGroups: "restrictive"
      NACLs: "additional layer"

  # 災難恢復
  DisasterRecovery:
    Backup:
      Service: "AWS Backup"
      Schedule: "daily + weekly"
      RetentionPeriod: "7 years"
      CrossRegionCopy: true

    ReplicationTarget:
      Service: "Secondary AWS Region"
      RPO: "< 1 hour"
      RTO: "< 4 hours"

# 成本估算 (月費用)
CostEstimation:
  RDS: "$2,400/month"
  ElastiCache: "$1,200/month"
  DynamoDB: "$800/month"
  Lambda: "$300/month"
  Other: "$800/month"
  Total: "$5,500/month"

AWS 服務架構圖

graph TB
    subgraph "用戶接入層"
        A[企業用戶] --> B[Amazon CloudFront]
        B --> C[Application Load Balancer]
        C --> D[Amazon API Gateway]
    end

    subgraph "安全認證層"
        D --> E[AWS Cognito]
        E --> F[AWS IAM]
        F --> G[AWS Secrets Manager]
    end

    subgraph "計算處理層"
        D --> H[AWS Lambda 函數]
        D --> I[Amazon ECS Fargate]
        H --> J[業務邏輯處理]
        I --> K[背景任務處理]
    end

    subgraph "核心資料層"
        J --> L[Amazon RDS PostgreSQL]
        L --> L1[主資料庫 db.r6g.2xlarge]
        L --> L2[讀取副本 x3]
        L --> L3[Multi-AZ 備援]

        J --> M[Amazon DynamoDB]
        M --> M1[版本控制表]
        M --> M2[審計軌跡表]
        M --> M3[Global Tables]
    end

    subgraph "快取加速層"
        J --> N[Amazon ElastiCache Redis]
        N --> N1[主節點]
        N --> N2[從節點 x2]
        N --> N3[叢集模式]

        M --> O[DynamoDB DAX]
        O --> O1[微秒級存取]
    end

    subgraph "事件處理層"
        L1 --> P[Amazon EventBridge]
        M1 --> P
        P --> Q[事件規則路由]
        Q --> R[Amazon SQS FIFO]
        Q --> S[Amazon SNS]
        R --> T[下游系統處理]
        S --> U[即時通知]
    end

    subgraph "監控與可觀測性"
        V[Amazon CloudWatch]
        W[AWS X-Ray]
        X[Amazon CloudWatch Logs]
        Y[AWS CloudTrail]

        L1 --> V
        M1 --> V
        N1 --> V
        H --> W
        I --> X
        P --> Y
    end

    subgraph "災難恢復"
        L1 --> Z[AWS Backup]
        M1 --> Z
        Z --> AA[跨區域備份]
        AA --> BB[Secondary Region]
    end

    subgraph "成本與治理"
        CC[AWS Cost Explorer]
        DD[AWS Config]
        EE[AWS Organizations]
        V --> CC
        Y --> DD
        F --> EE
    end