Arch Day 18: 数据架构(高级)

日期: 2026-04-17 (Day 18) 阶段: 第一阶段 - 架构基础 标签: #数据架构 #DataMesh #DataLakehouse #数据血缘 #Lambda #Kappa #合规

---

核心概念

一句话定义

高级数据架构是在组织层面设计数据的存储、流转、治理和合规体系的系统方法，它不只是"选用什么数据库"，而是解决"数据如何被组织拥有、如何在合规边界内流动、如何同时服务实时和批量场景"的全局问题。

为什么资深架构师仍需关注

数据架构是金融系统中最复杂、影响最深远的架构决策之一。在我十年金融零售软件经验中，数据相关的问题占据了大量架构讨论：

1. 数据孤岛：每个部门一套数据存储，客户在A系统叫"张三"在B系统叫"ZHANG SAN"
2. 实时与批量的割裂：业务要求实时看板，但数据仓库只能T+1
3. 合规压力：GDPR要求"被遗忘权"，但数据已经散落在20个系统中
4. 跨境数据：中国的客户数据能不能存在新加坡的AWS？答案很复杂

数据架构不是一个纯技术问题，它深刻地涉及组织结构(谁拥有数据)、合规法规(数据能存在哪里)、业务需求(实时还是离线)。资深架构师需要在这些维度之间做出平衡的决策。

常见误区与反模式

---

知识点详解

知识点一：Data Mesh vs Data Lake vs Data Lakehouse

这三种数据架构范式代表了数据平台的演进方向，选型决策对组织影响深远。

Data Lake(数据湖)：

┌──────────────────────────────────────────┐
│              Data Lake                    │
│                                          │
│  ┌──────┐  ┌──────┐  ┌──────┐          │
│  │原始层 │→│清洗层 │→│加工层 │          │
│  │(Raw) │  │(Clean)│  │(Curated)│       │
│  │      │  │      │  │        │         │
│  │CSV   │  │Parquet│  │聚合表  │         │
│  │JSON  │  │标准化 │  │宽表   │         │
│  │日志  │  │去重   │  │指标   │         │
│  └──────┘  └──────┘  └──────┘          │
│                                          │
│  存储: S3/HDFS/ADLS                      │
│  计算: Spark/Presto/Hive                 │
│  管理: 中央数据团队                       │
└──────────────────────────────────────────┘

优点: 集中管理/成本低/灵活schema
问题: 容易变成数据沼泽/中央团队瓶颈/数据质量难保障

Data Lakehouse(数据湖仓一体)：

┌──────────────────────────────────────────┐
│            Data Lakehouse                 │
│                                          │
│  ┌──────────────────────────────┐       │
│  │     开放表格式层               │       │
│  │  (Delta Lake / Iceberg / Hudi)│       │
│  │                               │       │
│  │  • ACID事务                   │       │
│  │  • Schema演进                 │       │
│  │  • 时间旅行(版本管理)          │       │
│  │  • 统一批流处理               │       │
│  └──────────────────────────────┘       │
│              │                           │
│        ┌─────┴─────┐                     │
│        ▼           ▼                     │
│  ┌──────────┐ ┌──────────┐              │
│  │ BI/报表   │ │ ML/AI    │              │
│  │ (SQL查询) │ │ (Python) │              │
│  └──────────┘ └──────────┘              │
│                                          │
│  存储: S3/ADLS(低成本对象存储)            │
│  能力: 数据湖的灵活性 + 数仓的管理能力     │
└──────────────────────────────────────────┘

关键创新: 在数据湖上加了一层"表格式"(Table Format)
使得数据湖获得了:
- ACID事务(之前数据湖没有)
- Schema强制/演进(之前是无Schema)
- 高性能SQL查询(之前查询慢)
- 批流统一(之前批和流是两套)

Data Mesh(数据网格)：

┌──────────────────────────────────────────┐
│              Data Mesh                    │
│                                          │
│  ┌──────────────┐  ┌──────────────┐     │
│  │ 支付领域       │  │ 风控领域      │     │
│  │ (数据所有者)   │  │ (数据所有者)  │     │
│  │               │  │              │     │
│  │ ┌──────────┐ │  │ ┌──────────┐│     │
│  │ │数据产品   │ │  │ │数据产品   ││     │
│  │ │•交易流水  │ │  │ │•风险评分  ││     │
│  │ │•支付统计  │ │  │ │•异常交易  ││     │
│  │ └──────────┘ │  │ └──────────┘│     │
│  └──────┬───────┘  └──────┬──────┘     │
│         │                 │             │
│  ┌──────┴─────────────────┴──────┐      │
│  │      自助数据基础设施平台        │      │
│  │   (Self-serve Data Platform)   │      │
│  │                                │      │
│  │  • 数据目录/发现                │      │
│  │  • 数据管道模板                 │      │
│  │  • 数据质量框架                 │      │
│  │  • 访问控制/合规                │      │
│  └────────────────────────────────┘      │
│                                          │
│  ┌────────────────────────────────┐      │
│  │      联邦治理(Federated Gov.)   │      │
│  │  • 全局标准(数据格式/命名)      │      │
│  │  • 互操作性规范                 │      │
│  │  • 合规策略                    │      │
│  └────────────────────────────────┘      │
└──────────────────────────────────────────┘

Data Mesh四原则:
1. 领域数据所有权(Domain Ownership)
2. 数据即产品(Data as a Product)
3. 自助数据基础设施(Self-serve Platform)
4. 联邦计算治理(Federated Governance)

三种范式对比：

知识点二：数据血缘治理和元数据管理

数据血缘(Data Lineage)追踪数据从产生到消费的全链路，是数据治理的基础能力。

数据血缘示例:

源系统                    数据管道                   消费端
┌─────────┐    ┌────────────────────┐    ┌────────────┐
│交易核心   │───→│ CDC → Kafka →      │───→│ 交易查询API │
│transactions│  │ Flink → ES        │    │ (实时)     │
└─────────┘    └────────────────────┘    └────────────┘
     │
     │         ┌────────────────────┐    ┌────────────┐
     └────────→│ Spark ETL →       │───→│ 交易报表    │
               │ 聚合 → 数仓       │    │ (T+1)     │
               └────────────────────┘    └────────────┘
                    │
                    └──→ 字段映射:
                         transaction.amount → report.daily_volume
                         transaction.currency → report.currency_code

元数据管理的三个层次：

数据目录(Data Catalog)架构：

┌────────────────────────────────────────────┐
│              Data Catalog                   │
│                                            │
│  ┌──────────────┐  ┌──────────────┐       │
│  │ 数据发现       │  │ 数据血缘      │       │
│  │ (搜索数据集)   │  │ (追踪来源)    │       │
│  └──────────────┘  └──────────────┘       │
│                                            │
│  ┌──────────────┐  ┌──────────────┐       │
│  │ 数据质量       │  │ 访问控制      │       │
│  │ (质量评分)    │  │ (权限管理)    │       │
│  └──────────────┘  └──────────────┘       │
│                                            │
│  ┌──────────────┐  ┌──────────────┐       │
│  │ 数据分类       │  │ 合规标记      │       │
│  │ (PII/敏感)    │  │ (GDPR/本地化) │       │
│  └──────────────┘  └──────────────┘       │
│                                            │
│  数据源自动爬取:                             │
│  PostgreSQL / Kafka / S3 / ES / Redis      │
└────────────────────────────────────────────┘

知识点三：Lambda vs Kappa架构

Lambda和Kappa是两种处理实时+批量混合需求的架构模式。

Lambda架构：

┌────────────────────────────────────────────┐
│              Lambda 架构                    │
│                                            │
│            ┌──────────────────┐            │
│  数据源 ──→│  批处理层(Batch)   │──→┐       │
│     │      │  Spark/MapReduce  │   │       │
│     │      │  每天跑一次        │   │  ┌────┴───┐
│     │      └──────────────────┘   ├─→│Serving │
│     │                             │  │ Layer  │
│     │      ┌──────────────────┐   │  │合并结果 │
│     └─────→│  速度层(Speed)    │──→┘  └────────┘
│            │  Flink/Storm     │              │
│            │  实时处理         │              ▼
│            └──────────────────┘         查询接口
│                                            │
│  批处理层: 保证数据正确性(全量重算)           │
│  速度层: 保证数据时效性(增量计算)             │
│  服务层: 合并批和流的结果                    │
└────────────────────────────────────────────┘

优点: 容错性强(批处理可以纠正流处理的错误)
缺点: 两套代码逻辑/维护成本高/合并逻辑复杂

Kappa架构：

┌────────────────────────────────────────────┐
│              Kappa 架构                     │
│                                            │
│  数据源 ──→ Kafka(不可变日志) ──→ Flink ──→ 结果 │
│                │                           │
│                │  需要重算时:                │
│                │  从Kafka的早期offset重新消费 │
│                │  用同一套流处理逻辑重算      │
│                │                           │
│  只有一套处理逻辑(流处理)                    │
│  通过重放(Replay)实现"批处理"效果            │
└────────────────────────────────────────────┘

优点: 只维护一套代码/架构简单
缺点: 依赖Kafka长期保留数据/超大规模重放成本高
前提: 流处理框架足够成熟可靠(Flink已经做到了)

选型决策矩阵：

知识点四：金融数据合规

金融数据合规是数据架构必须优先考虑的硬性约束。

主要合规框架对比：

数据本地化架构：

跨国零售银行数据架构示例:

┌───────────────────────────────────────────────┐
│                 全球数据架构                     │
│                                               │
│  中国区域(数据主权: 中国境内)                     │
│  ┌──────────────────────────┐                 │
│  │ 中国AWS/阿里云 Region     │                 │
│  │ ┌────────┐ ┌──────────┐ │                 │
│  │ │客户数据 │ │交易数据   │ │                 │
│  │ │(PII)   │ │(本地存储) │ │                 │
│  │ └────────┘ └──────────┘ │                 │
│  │ ┌────────┐              │                 │
│  │ │分析数据 │ ← 只有脱敏后 │                  │
│  │ │(脱敏)  │   的聚合数据  │                  │
│  │ └────┬───┘   可以出境   │                  │
│  └──────┼───────────────────┘                 │
│         │ 脱敏+聚合(无PII)                      │
│         ▼                                     │
│  全球分析中心(新加坡)                             │
│  ┌──────────────────────────┐                 │
│  │ 全球聚合数据(无PII)        │                 │
│  │ ┌────────┐ ┌──────────┐ │                 │
│  │ │全球报表 │ │全球风控   │ │                 │
│  │ │(聚合)  │ │(脱敏特征) │ │                 │
│  │ └────────┘ └──────────┘ │                 │
│  └──────────────────────────┘                 │
│                                               │
│  欧盟区域(数据主权: EU境内, GDPR)                │
│  ┌──────────────────────────┐                 │
│  │ EU AWS Region(Frankfurt)  │                 │
│  │ ┌────────┐ ┌──────────┐ │                 │
│  │ │客户数据 │ │被遗忘权   │ │                 │
│  │ │(PII)   │ │删除能力   │ │                 │
│  │ └────────┘ └──────────┘ │                 │
│  └──────────────────────────┘                 │
└───────────────────────────────────────────────┘

GDPR"被遗忘权"的数据架构挑战：

用户要求删除所有个人数据:

挑战1: 数据分布在多个系统中
  解决: 数据目录记录PII数据位置

挑战2: 数据已经被ETL到数据仓库
  解决: 数据仓库也要支持删除/数据保留软删标记

挑战3: 数据在Kafka消息中(不可变日志)
  解决: Kafka加密方案——删除密钥等于删除数据(Crypto Shredding)

挑战4: 数据在备份中
  解决: 备份恢复后重新执行删除/备份数据加密+密钥销毁

挑战5: 数据在ML模型训练集中
  解决: 模型定期用排除已删除数据的数据集重训练

关键架构决策: 所有PII数据用用户级密钥加密
删除用户 = 销毁该用户的加密密钥(Crypto Shredding)
这比物理删除分布在20个系统中的数据高效得多

知识点五：实时+批量混合架构设计

在金融系统中，实时和批量处理通常需要共存。

实时+批量混合架构(金融系统):

┌──────────────────────────────────────────────────────┐
│                                                      │
│  OLTP层(在线交易处理)                                  │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐           │
│  │交易核心DB │  │用户中心DB │  │风控引擎DB │           │
│  │(PG/Aurora)│  │(PG/Aurora)│  │(PG/Aurora)│          │
│  └─────┬────┘  └─────┬────┘  └─────┬────┘           │
│        │              │              │                │
│        └──────────────┼──────────────┘                │
│                       │                               │
│  CDC层(近实时数据同步)  │                               │
│  ┌────────────────────┴────────────────────┐         │
│  │         Debezium → Kafka                 │         │
│  └─────────┬──────────┬──────────┬─────────┘         │
│            │          │          │                    │
│            ▼          ▼          ▼                    │
│  实时处理层                                            │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐           │
│  │Flink     │  │ES        │  │Redis     │           │
│  │(实时计算) │  │(实时查询) │  │(实时缓存) │           │
│  │          │  │          │  │          │           │
│  │•实时风控  │  │•交易搜索  │  │•热点数据  │           │
│  │•实时指标  │  │•模糊查询  │  │•会话数据  │           │
│  └──────────┘  └──────────┘  └──────────┘           │
│                                                      │
│  批处理层(T+1数据仓库)                                 │
│  ┌──────────────────────────────────────────┐       │
│  │         数据湖仓(Lakehouse)                │       │
│  │                                           │       │
│  │  原始层 → 清洗层 → 加工层 → 应用层          │       │
│  │  (S3)    (Spark)  (dbt)    (BI/报表)      │       │
│  │                                           │       │
│  │  • 日终对账                                │       │
│  │  • 监管报表                                │       │
│  │  • 用户画像                                │       │
│  │  • 风控模型训练                             │       │
│  └──────────────────────────────────────────┘       │
└──────────────────────────────────────────────────────┘

---

对比分析

数据存储技术选型对比(金融场景)

数据处理框架对比

---

架构设计实操

实操目标

设计"跨国零售银行"数据架构，覆盖OLTP/OLAP分离、实时+批量处理、跨境数据合规。

业务背景

组织: 跨国零售银行
业务: 零售银行(储蓄/贷款/支付/理财)
地域: 中国/东南亚/欧洲
数据量:
  - 客户数: 5000万
  - 日交易量: 2000万笔
  - 历史数据: 10年
合规要求:
  - 中国: 个保法/数安法(数据本地化)
  - 欧盟: GDPR(被遗忘权)
  - 全球: PCI-DSS(支付卡数据)

数据架构设计

数据分类与分级：

数据分级:
┌────────────────────────────────────────────┐
│ Level 4 - 极度敏感                          │
│ 密码/密钥/生物识别                          │
│ 处理: 加密存储/最小权限/HSM管理              │
├────────────────────────────────────────────┤
│ Level 3 - 高度敏感(PII)                     │
│ 身份证号/银行卡号/手机号                     │
│ 处理: 加密+令牌化/数据本地化/被遗忘权支持     │
├────────────────────────────────────────────┤
│ Level 2 - 内部敏感                          │
│ 交易记录/余额/信用评分                       │
│ 处理: 访问控制/审计日志/脱敏后可用于分析      │
├────────────────────────────────────────────┤
│ Level 1 - 一般数据                          │
│ 产品信息/公开汇率/系统配置                    │
│ 处理: 基本访问控制                          │
└────────────────────────────────────────────┘

跨境数据架构：

# 跨境数据流转规则

china_region:
  storage: "AWS China(北京/宁夏)"
  data_scope: "所有中国客户的PII + 交易数据"
  outbound_rule: "只允许脱敏聚合数据出境(需安全评估)"
  encryption: "国密SM4(境内要求)"

eu_region:
  storage: "AWS EU(Frankfurt)"
  data_scope: "所有EU客户的PII + 交易数据"
  outbound_rule: "需要SCC(标准合同条款)"
  special: "支持GDPR被遗忘权(Crypto Shredding)"

sea_region:
  storage: "AWS Singapore"
  data_scope: "东南亚客户数据"
  outbound_rule: "各国规定不同，保守处理"

global_analytics:
  storage: "AWS Singapore(全球分析中心)"
  data_scope: "各区域脱敏聚合数据"
  purpose: "全球报表/风控模型训练/业务分析"
  restriction: "不包含任何PII数据"

ADR记录

# ADR-S-018: 跨国零售银行数据架构策略

## 状态: Accepted

## 决策
1. 数据架构采用"区域自治 + 全局聚合"模式
2. 每个合规区域独立部署OLTP + 数据湖
3. 全球分析中心只接收脱敏聚合数据
4. PII数据采用Crypto Shredding方案(用户级密钥加密)
5. 实时层用Flink，批处理层用Spark + dbt
6. 元数据管理用DataHub

## 关键权衡
- Crypto Shredding增加了加密管理复杂度，但大幅简化了"被遗忘权"的实现
- 区域自治增加了运维成本(每个区域独立运维)，但满足了数据本地化要求
- 全局分析只用聚合数据，可能影响某些精细分析的准确性，但合规优先

---

AI增强实践

AI辅助数据治理

AI数据质量监控：

# 概念：AI驱动的数据质量监控
class AIDataQualityMonitor:
    """
    传统数据质量检查: 固定规则(如字段非空/范围检查)
    AI增强: 自动学习数据模式，检测异常

    示例:
    - AI发现"交易金额"字段过去30天的分布突然变化
    - AI发现某个ETL管道的数据量比历史同期少了30%
    - AI发现两个表的JOIN结果比预期多了10倍(可能是数据重复)
    """

    def detect_distribution_drift(self, column, window="30d"):
        """检测数据分布漂移"""
        pass

    def detect_volume_anomaly(self, table, window="7d"):
        """检测数据量异常"""
        pass

    def suggest_data_quality_rules(self, table_schema):
        """基于Schema自动推荐数据质量规则"""
        pass

AI辅助数据分类：

利用AI自动识别和分类敏感数据:

输入: 数据库Schema + 采样数据
AI分析:
  - user.phone_number → PII(手机号) → Level 3
  - user.email → PII(邮箱) → Level 3
  - transaction.amount → 内部敏感 → Level 2
  - product.name → 一般数据 → Level 1
  - user.id_card → PII(身份证号) → Level 3

输出: 数据分类标记 + 建议的处理策略

AI辅助数据架构设计

Prompt模板:

你是一位有金融数据架构经验的高级架构师。

业务场景: [描述]
数据特征: [数据量/增长率/访问模式]
合规要求: [GDPR/数据本地化/PCI-DSS等]
技术约束: [云平台/团队能力/预算]

请设计数据架构方案:
1. 数据存储选型(OLTP/OLAP/缓存/搜索)
2. 数据流转方案(CDC/ETL/实时/批量)
3. 数据合规策略(分级/加密/本地化)
4. 数据质量方案
5. 成本估算

---

与Web3/DeFi的关联

链上数据 vs 链下数据架构

DeFi系统有一个独特的数据架构挑战：数据天然分布在链上和链下。

DeFi数据架构:

链上数据(不可变/公开)              链下数据(私有/可变)
┌──────────────────┐          ┌──────────────────┐
│ • 交易记录        │          │ • 用户偏好设置    │
│ • 合约状态        │          │ • 通知配置        │
│ • Token余额      │          │ • KYC信息(如有)   │
│ • 历史事件        │          │ • 前端分析数据    │
└────────┬─────────┘          └──────────────────┘
         │
    ┌────┴────┐
    │ Indexer  │ (如The Graph/自建)
    │ (链上→  │
    │  链下)  │
    └────┬────┘
         │
    ┌────┴────┐
    │ 查询层   │ (GraphQL/REST API)
    └─────────┘

DeFi数据架构的PM启示：

---

今日思考

问题一：Data Mesh是否适合金融行业？

金融行业有极强的合规要求和数据管控需求。Data Mesh的"去中心化数据所有权"理念与金融行业的"集中合规管控"是否矛盾？如何在Data Mesh的灵活性和金融合规的严格性之间找到平衡？

问题二：实时 vs 正确

金融系统中，"实时但可能有误差"和"延迟但保证正确"之间如何选择？实时风控需要毫秒级决策，但数据可能还在传输中。如何设计一个"渐进式正确"的数据架构——先给一个快速但近似的结果，然后逐步修正？

问题三：数据合规的架构成本

Crypto Shredding、数据本地化、分级加密这些合规措施都有显著的架构复杂度和成本。如何向业务方清晰地传达"合规不是免费的"？如何在合规投入和业务发展之间找到最优平衡？

---

面试题准备

面试题1: Data Mesh适合什么组织？

30秒回答：

Data Mesh适合已经采用领域驱动设计、有多个独立业务领域团队、且中央数据团队已经成为瓶颈的大型组织。它不是技术问题，而是组织问题——如果组织结构不支持领域数据自治，硬推Data Mesh只会增加混乱。

2分钟回答：

Data Mesh是Zhamak Dehghani在2019年提出的数据架构范式，核心思想是把数据的所有权从中央数据团队下放到各业务领域团队。适合的组织需要满足四个条件：

第一，已有清晰的领域划分。如果组织连业务领域都没划清楚，数据所有权就无从谈起。

第二，中央数据团队已经成为瓶颈。如果中央团队能满足需求，不需要Data Mesh。

第三，各领域团队有数据工程能力。Data Mesh要求领域团队自己管数据管道和数据质量，如果团队没有这个能力，会变成灾难。

第四，有统一的数据基础设施平台。Data Mesh不是"各干各的"，而是在统一平台上的联邦自治。

在金融行业，我认为Data Mesh适合大型银行集团(如零售/对公/投行各有独立数据需求)，但需要在数据自治和合规管控之间找到平衡——合规策略必须是全局统一的。

追问准备：

• Q: Data Mesh和微服务有什么关系？ A: Data Mesh是微服务思想在数据领域的延伸——就像微服务把"代码所有权"下放到领域团队，Data Mesh把"数据所有权"下放。两者配合使用效果最好。

面试题2: 金融数据跨境有什么限制？

30秒回答：

各国对金融数据跨境有不同规定。中国要求数据本地化(重要数据和个人信息须境内存储，出境需安全评估)；欧盟GDPR要求有充分性认定或标准合同条款；新加坡/香港相对宽松但也有通知要求。架构上需要"区域自治+全局聚合脱敏"模式。

2分钟回答：

（展开各区域的具体合规要求，以及Crypto Shredding等架构方案。重点强调"合规是架构设计的第一约束，不是事后补丁"。）

---

学习资源

---

明日预告

Day 19: 安全架构(金融级) —— 从"数据如何治理"转向"数据如何保护"。我们将深入零信任架构的落地步骤、mTLS服务间通信、密钥管理(HSM/KMS/Vault)、数据加密策略(TDE/FPE/令牌化/FHE)，以及金融行业特有的合规审计要求(SOC2/PCI-DSS)。数据架构决定了数据存在哪里，安全架构决定了数据如何被保护。