mcpField
D
data-architect

data-architect

github.com/rade-nugroho数据与数据库1241 次安装24 周前更新
代码仓库

关于 data-architect

用于企业及解决方案级数据架构决策、建模、平台选择与治理的技能，帮助架构师生成 ADR、数据模型、方案比较矩阵和政策模板等结构化成果。

主要功能

  1. 01加权架构决策评估
  2. 02从概念到物理的数据建模
  3. 03数据仓库、数据湖及平台选择
  4. 04治理与合规规划
  5. 05ADR 模板和利益相关方评审

适用场景

  1. 01比较湖仓与数据仓库方案
  2. 02为业务领域建立实体模型
  3. 03规划 GDPR 合规治理
  4. 04记录数据平台决策

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/rade-nugroho/agentic-enteprises-skill --skill data-architect

安装后在 Claude Code 中输入/data-architect确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
data_modeling.md
enterprise_architecture.md
governance_frameworks.md
platform_selection.md

详细介绍

数据架构师

概述

在企业和解决方案层面设计数据架构。本技能涵盖数据网格、湖仓一体、治理、领域驱动设计、概念／逻辑／物理数据建模、平台选择和合规框架。生成 ADR、数据模型图、平台对比矩阵和治理政策模板。

适用场景

  • 在数据仓库、数据湖、湖仓一体、数据网格或流式优先模式之间进行选择
  • 创建概念、逻辑或物理数据模型及 ADR
  • 定义数据治理、目录、质量和合规框架
  • 评估数据平台，以及长期 TCO 或供应商权衡

不适用场景

  • 日常管道值班、SLA 违约或轮班交接 → 使用 data-system-ops-lead
  • 单一平台的 SQL 调优或星型架构实现细节 → 使用 data-warehouse-engineer
  • dbt 项目实现、数据集市测试和分析 CI → 使用 analytics-data-engineer
  • 团队路线图、冲刺节奏或治理运营执行 → 使用 data-manager
  • OWL/RDF 本体或知识图谱构建 → 使用 ontology-engineer
  • 应用集成模式和非数据系统 ADR → 使用 senior-system-architecture
  • LLM/RAG/副驾驶解决方案架构和 AI ADR → 使用 applied-ai-architect-commercial-enterprise

功能

  • 采用加权标准评估的架构决策框架
  • 渐进式数据建模工作流（概念 → 逻辑 → 物理）
  • 数据仓库／数据湖／湖仓一体／数据网格／流式平台选择决策树
  • 治理支柱规划及工具建议
  • ADR 模板生成和利益相关方评审流程

用法

  1. 确定用户的数据架构需求（平台选择、建模、治理或决策框架）
  2. 按照下方相应的工作流执行
  3. 生成结构化输出：ADR、数据模型图、平台对比矩阵或治理政策

示例

  • 用户：“我们的分析应该使用数据湖还是数据仓库？” Agent：运行平台与技术选择工作流（工作流 3），评估结构化数据与原始数据需求，并权衡后推荐数据仓库／数据湖／湖仓一体

  • 用户：“我们需要对客户领域进行建模。” Agent：运行数据建模工作流（工作流 2），从概念模型（实体、关系）开始，逐步生成逻辑 ER 图，再生成物理 DDL

  • 用户：“我们如何建立数据治理以满足 GDPR 合规要求？” Agent：运行治理与合规规划（工作流 4），将 GDPR 要求映射到治理支柱，并推荐工具和控制措施

核心工作流

1. 架构决策框架

对任何重大数据架构决策，都使用以下 5 步流程：

  1. 定义决策背景

    • 业务驱动因素（规模、延迟、成本、合规）
    • 约束条件（预算、时间线、现有技术、团队技能）
    • 利益相关方（数据工程师、分析师、产品、法务）

  2. 确定备选方案

    • 至少 3 个选项（不采取行动、最小化改动、变革性方案）
    • 包括云原生、混合和开源方案

  3. 根据标准进行评估

    标准权重每个选项评分 1-5
    可扩展性高
    成本（3 年 TCO）高
    实现价值所需时间中
    运维复杂度中
    与团队的契合度中
    供应商锁定风险低

  4. 评估风险和缓解措施

    • 迁移风险、人才风险、运维风险
    • 为得分最高的 2 个选项制定 POC 计划

  5. 记录决策

    • 使用 ADR（架构决策记录）记录背景、决策和后果
    • 与利益相关方分享；每季度重新审视
2. 数据建模工作流

从业务到实现的渐进式细化：

阶段输出受众关键活动
概念模型实体列表、关系、业务术语表业务相关方研讨会、领域事件
逻辑模型规范化 ER 图、属性、键数据分析师、架构师识别实体、解决多对多关系
物理模型特定数据库的 DDL、分区、索引工程师平台优化、反规范化

关键原则：

  • 从业务问题出发，而不是从技术出发
  • 在物理模型中使用代理键；在逻辑模型中使用自然键
  • 只有在有性能要求时才进行反规范化
3. 平台与技术选型

决策树：

  • 需要大规模结构化分析和 BI？→ 数据仓库（Snowflake、BigQuery、Redshift）
  • 需要原始数据、ML 和灵活的架构？→ 数据湖（S3 + Athena/Spark）
  • 需要兼具两者并保证 ACID？→ 湖仓一体（Databricks、Iceberg、Hudi）
  • 需要领域所有权和联邦式治理？→ 数据网格（每个领域使用多个数据仓库/数据湖）
  • 需要实时性和低延迟？→ 流式优先（Kafka + Flink + 物化视图）
4. 治理与合规规划

治理支柱：

支柱活动工具
数据质量数据探查、验证规则、异常检测dbt tests、Great Expectations、Monte Carlo
数据目录元数据、数据沿袭、发现DataHub、Collibra、Alation
访问控制RBAC、ABAC、数据脱敏、加密平台原生功能 + Immuta/Okera
主数据管理黄金记录、去重Informatica、Reltio、自定义 MDM
合规GDPR、CCPA、HIPAA、SOC 2法律审查 + 技术控制

评论

支持 Markdown