⚡

数据架构Skill architecting-data

数据架构技能提供设计现代云原生数据平台的战略指导，涵盖存储范式选择、数据建模方法、数据网格实施、开放表格式应用等。关键词：数据架构、数据平台、存储范式、数据建模、数据网格、数据治理、现代数据堆栈、奖章架构、Apache Iceberg、dbt、数据工程。

数据工程 0 次安装 0 次浏览 更新于 3/23/2026

name: 数据架构 description: 为设计现代数据平台提供战略指导，涵盖存储范式（数据湖、数据仓库、数据湖屋）、建模方法（维度建模、规范化、数据仓库、宽表）、数据网格原则和奖章架构模式。在架构数据平台、选择集中式与去中心化模式、选择表格式（Iceberg、Delta Lake）或设计数据治理框架时使用。

数据架构

目的

指导架构师和平台工程师在现代云原生数据平台上做出战略性的数据架构决策。

何时使用此技能

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

  • 设计新的数据平台或现代化遗留系统
  • 在数据湖、数据仓库或数据湖屋之间选择
  • 决定数据建模方法（维度建模、规范化、数据仓库、宽表）
  • 评估集中式与数据网格架构
  • 选择开放表格式（Apache Iceberg、Delta Lake、Apache Hudi）
  • 设计奖章架构（青铜、白银、黄金层）
  • 实施数据治理和目录化

核心概念

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系统、频繁更新、强一致性

数据仓库2.0： 具有完整审计跟踪的灵活模型

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

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

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

决策框架：

  • 分析（BI）+ 已知查询 → 维度建模（星型模式）
  • 事务（OLTP） → 规范化（3NF）
  • 合规/审计 → 数据仓库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. 奖章架构

标准数据湖屋模式：青铜（原始） → 白银（清理） → 黄金（业务级）

青铜层： 源数据的精确副本，不可变，仅追加

白银层： 验证、去重、类型化的数据

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

各层数据质量：

  • 青铜 → 白银：模式验证、类型检查、去重
  • 白银 → 黄金：业务规则验证、引用完整性
  • 黄金：异常检测、统计检查

模式请参见 references/medallion-pattern.md。

5. 开放表格式

在数据湖上启用ACID事务：

Apache Iceberg： 多引擎、供应商中立（Context7评分：79.7）

  • 使用场景：避免供应商锁定、多引擎灵活性

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

  • 使用场景：承诺使用Databricks

Apache Hudi： 为CDC和频繁更新优化

  • 使用场景：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 vs Airbyte：预建连接器 vs 成本敏感
  • Snowflake vs Databricks：BI专注 vs ML专注
  • dbt vs Spark：基于SQL vs 大规模处理

详细推荐请参见 references/tool-recommendations.md 和 references/modern-data-stack.md。

7. 数据治理

数据目录： 可搜索的库存（DataHub、Alation、Collibra）

数据谱系： 跟踪数据流（OpenLineage、Marquez）

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

访问控制：

  • RBAC：基于角色（销售分析师角色）
  • 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）
  • 合规/审计 → 数据仓库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
  • 频繁更新/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 或 Snowflake with Iceberg）
  • 策略：使用CDC进行增量迁移
  • 架构：奖章架构（青铜、白银、黄金）
  • 成本节省：60-80%

参见 references/scenarios.md。

数据网格评估

上下文： 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（<1,000美元/月）

增长期： Snowflake + Fivetran + dbt + Airflow + Tableau（10,000-50,000美元/月）

企业： Snowflake + Databricks + Fivetran + Kafka + dbt + Airflow + Alation（50,000-500,000美元/月）

参见 references/tool-recommendations.md。

实施模式

模式1：奖章架构

-- 青铜：原始摄取
CREATE TABLE bronze.raw_customers (_ingested_at TIMESTAMP, _raw_data STRING);

-- 白银：清理
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;

-- 黄金：业务级
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));

-- 时间旅行
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. 奖章架构： 使用青铜-白银-黄金层实现清晰的质量分层
  4. 开放表格式： 优选Iceberg或Delta Lake以避免供应商锁定
  5. 评估网格就绪度： 不要过早去中心化（<500人）
  6. 自动化质量： 将测试（Great Expectations、dbt）集成到CI/CD中
  7. 监控管道： 可观测性至关重要（新鲜度、质量、健康度）
  8. 代码化文档： 使用dbt文档、DataHub、YAML实现自助服务
  9. 增量加载： 仅加载新/更改的数据（水印列）
  10. 业务对齐： 根据结果对齐架构，而不仅仅是技术

反模式

  • ❌ 数据沼泽：无治理或目录的数据湖
  • ❌ 过早网格化：组织就绪前进行网格化
  • ❌ 工具泛滥：过多工具而无集成
  • ❌ 无质量检查：“垃圾进，垃圾出”
  • ❌ 集中化瓶颈：大型组织中的单一团队（>500人）
  • ❌ 供应商锁定：无迁移路径的专有格式
  • ❌ 无谱系：无法回答"这从哪里来？"
  • ❌ 过度工程化：简单用例的复杂架构

与其他技能的集成

直接依赖：

  • 数据摄取： ETL/ELT机制、Fivetran、Airbyte实施
  • 数据转换： dbt和Dataform详细实施
  • 流式数据： Kafka、Flink用于实时管道

补充：

  • 关系型数据库： PostgreSQL、MySQL作为源系统
  • 文档数据库： MongoDB、DynamoDB作为源
  • AI数据工程： 特征存储、ML训练管道
  • 设计分布式系统： CAP定理、一致性模型
  • 可观测性： 监控管道健康、数据质量指标

下游：

  • 数据可视化： BI和仪表板模式
  • SQL优化： 查询性能调优

常见工作流：

端到端分析：

数据架构（数据仓库） → 数据摄取（Fivetran） →
数据转换（dbt） → 数据可视化（Tableau）

AI/ML的数据平台：

数据架构（数据湖屋） → 数据摄取（Kafka） →
数据转换（dbt特征） → AI数据工程（特征存储）

进一步阅读

参考文件：

示例：

外部资源：