architecting-data

数据架构

用途

指导架构师和平台工程师为现代云原生数据平台制定战略性数据架构决策。

何时使用此技能

在以下情况下调用此技能：

• 设计新的数据平台或对旧系统进行现代化改造
• 在数据湖、数据仓库或数据湖仓之间进行选择
• 决定数据建模方法（维度建模、规范化、数据仓库保险库、宽表）
• 评估集中式架构与数据网格架构
• 选择开放表格式（Apache Iceberg、Delta Lake、Apache Hudi）
• 设计奖牌架构（bronze、silver、gold 层）
• 实施数据治理和编目

核心概念

1. 存储范式

分析型数据存储的三种主要模式：

数据湖： 用于大规模存储原始数据的集中式存储库

• 读时定义架构，成本优化（每月 $0.02-0.03/GB）
• 适用场景：多种数据源、探索性分析、ML/AI 训练数据

数据仓库： 为 BI 优化的结构化存储库

• 写时定义架构、ACID 事务、快速查询
• 适用场景：BI 需求明确、需要强治理

数据湖仓： 结合数据湖的灵活性与数据仓库可靠性的混合方案

• 开放表格式（Iceberg、Delta Lake），在对象存储上支持 ACID
• 适用场景：混合 BI + ML 工作负载、成本优化（比数据仓库便宜 60-80%）

决策框架：

• 仅 BI/报表 + 查询明确 → 数据仓库
• 以 ML/AI 为主 + 需要原始数据 → 数据湖或数据湖仓
• 混合 BI + ML + 成本优化 → 数据湖仓（推荐）
• 探索性/未知用例 → 数据湖

如需详细比较，请参阅 references/storage-paradigms.md。

2. 数据建模方法

四种主要建模模式：

维度建模（Kimball）： 用于 BI 的星型/雪花型架构

• 适用场景：查询模式明确、BI 仪表板、趋势分析

规范化（3NF）： 消除冗余，适用于事务型系统

• 适用场景：OLTP 系统、频繁更新、强一致性

Data Vault 2.0： 带有完整审计跟踪的灵活模型

• 适用场景：合规要求、多数据源、敏捷数据仓库

宽表： 反规范化，为列式存储优化

• 适用场景：ML 特征存储、数据科学笔记本、高性能仪表板

决策框架：

• 分析型（BI）+ 查询明确 → 维度建模（星型架构）
• 事务型（OLTP）→ 规范化（3NF）
• 合规/审计 → Data Vault 2.0
• 数据科学/ML → 宽表

如需详细模式，请参阅 references/modeling-approaches.md。

3. 数据网格原则

适用于大型组织（>500 人）的去中心化架构。

四项核心原则：

1. 面向领域的去中心化
2. 数据即产品（SLA、质量、文档）
3. 自助式数据基础设施
4. 联邦式计算治理

就绪度评估（每项评分 1-5）：

1. 领域清晰度
2. 团队成熟度
3. 平台能力
4. 治理成熟度
5. 规模需求
6. 组织支持度

评分： 24-30：强有力的候选方案 | 18-23：混合方案 | 12-17：先夯实基础 | 6-11：集中式架构

警示信号： 小型组织（<100 人）、领域不明确、没有平台团队、治理薄弱

如需完整指南，请参阅 references/data-mesh-guide.md。

4. 奖牌架构

标准的数据湖仓模式：Bronze（原始）→ Silver（清洗后）→ Gold（业务级）

Bronze 层： 源数据的精确副本、不可变、仅追加

Silver 层： 已验证、已去重、类型已确定的数据

Gold 层： 业务逻辑、聚合、维度模型、ML 特征

各层的数据质量：

• Bronze → Silver：架构验证、类型检查、去重
• Silver → Gold：业务规则验证、引用完整性
• Gold：异常检测、统计检查

如需相关模式，请参阅 references/medallion-pattern.md。

5. 开放表格式

为数据湖启用 ACID 事务：

Apache Iceberg： 多引擎、厂商中立（Context7：79.7 分）

• 适用场景：避免厂商锁定，获得多引擎灵活性

Delta Lake： Databricks 生态系统，针对 Spark 优化

• 适用场景：已决定使用 Databricks

Apache Hudi： 针对 CDC 和频繁 upsert 优化

• 适用场景：以 CDC 为主的工作负载

建议： 新项目选择 Apache Iceberg（厂商中立，支持范围最广）

比较详情请参阅 references/table-formats.md。

6. 现代数据技术栈

标准层：

• 数据摄取：Fivetran、Airbyte、Kafka
• 存储：Snowflake、Databricks、BigQuery
• 转换：dbt（Context7：87.0 分）、Spark
• 编排：Airflow、Dagster、Prefect
• 可视化：Tableau、Looker、Power BI
• 治理：DataHub、Alation、Great Expectations

工具选择：

• Fivetran 与 Airbyte：预构建连接器，还是注重成本
• Snowflake 与 Databricks：侧重 BI，还是侧重 ML
• dbt 与 Spark：基于 SQL，还是大规模处理

详细建议请参阅 references/tool-recommendations.md 和 references/modern-data-stack.md。

7. 数据治理

数据目录： 可搜索的数据清单（DataHub、Alation、Collibra）

数据血缘： 跟踪数据流（OpenLineage、Marquez）

数据质量： 验证与测试（Great Expectations、Soda、dbt tests）

访问控制：

• RBAC：基于角色（sales_analyst 角色）
• ABAC：基于属性（行级安全）
• 列级：针对 PII 的动态数据脱敏

治理模式请参阅 references/governance-patterns.md。

决策框架

框架 1：存储范式选择

步骤 1：确定主要用例

• 仅用于 BI/报表 → 数据仓库
• 以 ML/AI 为主 → 数据湖或湖仓一体
• BI + ML 混合 → 数据湖仓一体
• 探索性分析 → 数据湖

步骤 2：评估预算

• 预算充足、查询已知 → 数据仓库
• 注重成本、要求灵活 → 数据湖仓一体

按组织规模给出的建议：

• 初创公司（<50）：数据仓库（简单）
• 成长期（50-500）：数据湖仓一体（平衡）
• 企业（>500）：混合架构或统一湖仓一体

请参阅 references/decision-frameworks.md。

框架 2：数据建模方法

决策树：

• 分析型（BI）工作负载 → 维度建模或宽表
• 事务型（OLTP）→ 规范化（3NF）
• 合规/审计 → Data Vault 2.0
• 数据科学/ML → 宽表

请参阅 references/decision-frameworks.md。

框架 3：数据网格就绪度

采用 6 项因素评估。分数解读：

• 24-30：采用数据网格
• 18-23：采用混合方法
• 12-17：先夯实基础
• 6-11：采用集中式架构

请参阅 references/decision-frameworks.md。

框架 4：开放表格式选择

决策树：

• 需要多引擎灵活性 → Apache Iceberg
• Databricks 生态系统 → Delta Lake
• 频繁 upsert/CDC → Apache Hudi

建议： 新项目选择 Apache Iceberg

请参阅 references/decision-frameworks.md。

常见场景

初创公司数据平台

背景： 50 人初创公司，使用 PostgreSQL + MongoDB + Stripe

建议：

• 存储：BigQuery 或 Snowflake
• 数据摄取：Airbyte 或 Fivetran
• 转换：dbt
• 编排：dbt Cloud
• 架构：简单的数据仓库

请参阅 references/scenarios.md。

企业现代化

背景： 遗留 Oracle 仓库，需要迁移到云端

建议：

• 存储：数据湖仓（Databricks 或采用 Iceberg 的 Snowflake）
• 策略：使用 CDC 增量迁移
• 架构：Medallion（bronze、silver、gold）
• 成本节省：60-80%

参见 references/scenarios.md。

Data Mesh 评估

背景： 200 人的公司，中央数据团队有 5 人

建议： 暂时不要。先打好基础。

• 组织规模太小（建议 500 人以上）
• 中央团队尚未成为瓶颈
• 投资建设自助服务平台和治理体系

参见 references/scenarios.md。

工具建议

经研究验证（Context7，2025 年 12 月）

dbt： 得分 87.0，3,532+ 个代码片段

• 基于 SQL 的转换、版本控制、测试
• 数据转换领域的行业标准

Apache Iceberg： 得分 79.7，832+ 个代码片段

• 开放表格式，支持多引擎，不依赖供应商
• 已可用于生产环境（Netflix、Apple、Adobe）

按使用场景划分的工具栈：

初创公司： BigQuery + Airbyte + dbt + Metabase（<$1K/月）

成长型企业： Snowflake + Fivetran + dbt + Airflow + Tableau（$10K-50K/月）

大型企业： Snowflake + Databricks + Fivetran + Kafka + dbt + Airflow + Alation（$50K-500K/月）

参见 references/tool-recommendations.md。

实施模式

模式 1：Medallion 架构

-- Bronze: Raw ingestion
CREATE TABLE bronze.raw_customers (_ingested_at TIMESTAMP, _raw_data STRING);

-- Silver: Cleaned
CREATE TABLE silver.customers AS
SELECT json_extract(_raw_data, '$.id') AS customer_id, ...
FROM bronze.raw_customers
QUALIFY ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY _ingested_at DESC) = 1;

-- Gold: Business-level
CREATE TABLE gold.fact_sales AS
SELECT s.order_id, d.date_key, c.customer_key, ...
FROM silver.sales s
JOIN gold.dim_date d ON s.order_date = d.date;

模式 2：Apache Iceberg 表

CREATE TABLE catalog.db.sales (order_id BIGINT, amount DECIMAL(10,2))
USING iceberg
PARTITIONED BY (days(order_date));

-- Time travel
SELECT * FROM catalog.db.sales TIMESTAMP AS OF '2025-01-01';

模式 3：dbt 转换

-- models/staging/stg_customers.sql
WITH source AS (SELECT * FROM {{ source('raw', 'customers') }}),
cleaned AS (
  SELECT customer_id, UPPER(customer_name) AS customer_name
  FROM source WHERE customer_id IS NOT NULL
)
SELECT * FROM cleaned

完整示例参见 examples/。

最佳实践

1. 从简单开始： 避免过度设计；从仓库或基础数据湖仓开始
2. 尽早投入治理： 从第一天起就建立目录、血缘和质量管理
3. Medallion 架构： 使用 bronze-silver-gold 划分清晰的质量层
4. 开放表格式： 优先选择 Iceberg 或 Delta Lake，避免被供应商锁定
5. 评估 mesh 准备情况： 不要过早去中心化（少于 500 人时）
6. 自动化质量检查： 将测试（Great Expectations、dbt）集成到 CI/CD 中
7. 监控管道： 可观测性至关重要（新鲜度、质量、运行状况）
8. 将文档作为代码管理： 使用 dbt docs、DataHub、YAML 支持自助服务
9. 增量加载： 仅加载新增或变更的数据（水位线列）
10. 与业务目标对齐： 架构应服务于成果，而不只是技术

反模式

• ❌ 数据沼泽：缺乏治理或目录管理的数据湖
• ❌ 过早采用 mesh：组织尚未准备好就采用 mesh
• ❌ 工具泛滥：工具过多且缺乏集成
• ❌ 没有质量检查：“垃圾进，垃圾出”
• ❌ 集中式瓶颈：大型组织（>500 人）仅由一个团队负责
• ❌ 被供应商锁定：使用专有格式且没有迁移路径
• ❌ 缺乏血缘：无法回答“这些数据从哪里来？”
• ❌ 过度设计：为简单用例采用复杂架构

与其他技能的集成

直接依赖：

• ingesting-data： ETL/ELT 机制、Fivetran、Airbyte 实施
• data-transformation： dbt 和 Dataform 详细实施
• streaming-data： 使用 Kafka、Flink 构建实时管道

互补技能：

• databases-relational： PostgreSQL、MySQL 作为源系统
• databases-document： MongoDB、DynamoDB 作为数据源
• ai-data-engineering： 特征存储、ML 训练管道
• designing-distributed-systems： CAP 定理、一致性模型
• observability： 监控管道运行状况和数据质量指标

下游技能：

• visualizing-data： BI 和仪表板模式
• sql-optimization： 查询性能调优

常见工作流：

端到端分析：

data-architecture (warehouse) → ingesting-data (Fivetran) →
data-transformation (dbt) → visualizing-data (Tableau)

面向 AI/ML 的数据平台：

data-architecture (lakehouse) → ingesting-data (Kafka) →
data-transformation (dbt features) → ai-data-engineering (feature store)

延伸阅读

参考文件：

• decision-frameworks.md - 详细介绍全部 4 种决策框架
• storage-paradigms.md - 数据湖、数据仓库与湖仓一体的比较
• modeling-approaches.md - 维度建模、规范化、数据仓库总线与宽表
• data-mesh-guide.md - 数据网格原则与实施
• medallion-pattern.md - 青铜层、白银层与黄金层
• table-formats.md - Iceberg、Delta Lake 与 Hudi 的比较
• tool-recommendations.md - 工具分析与建议
• modern-data-stack.md - 工具类别与选择
• governance-patterns.md - 目录、血缘、质量与访问控制
• scenarios.md - 初创公司、企业与数据网格场景

示例：

• examples/dbt-project/ - 采用奖章架构的 dbt 项目

外部资源：

• Apache Iceberg: https://iceberg.apache.org/
• dbt 文档: https://docs.getdbt.com/
• 数据网格（Zhamak Dehghani）: https://www.datamesh-architecture.com/
• Databricks 奖章架构: https://www.databricks.com/glossary/medallion-architecture