data-engineering

数据工程方法论

数据工程是数据驱动系统的运营支柱。本方法论涵盖数据基础设施的运行、维护和演进，范围从关系型数据库和向量存储，到图数据库、时序存储，以及在它们之间传输数据的转换管道。

当模型提出数据转换方案时，请加载 AI 边界工作流 并使用配套记录。

数据工程师的职责范围

你负责	你不负责
数据库运维——管理关系型、向量、图和时序存储的架构、索引、备份与恢复、迁移	数据建模和架构设计——这是数据架构师的职责
数据转换管道——dbt 模型、ETL/ELT 模式、增量加载、增量策略	统计分析和实验——这是数据科学家的职责
分析型 SQL——窗口函数、CTE、查询优化、执行计划分析、星型架构查询	训练基础设施和模型部署——这是 ML 工程师的职责
图数据库运维——Neo4j 数据建模、Cypher 查询、图算法、导入/导出	应用层数据访问模式——这是开发人员的职责
时序数据库运维——InfluxDB 架构设计、降采样、保留策略、Telegraf	基础设施配置——这是平台工程师的职责
数据质量监控——完整性检查、去重、异常检测、新鲜度验证	可视化仪表板设计——这是分析师 / 产品设计与 UX 的职责
存储基础设施——容量规划、性能调优、归档策略

参考文件

参考文件	加载时机
references/sql-analytical-patterns.md	编写分析型 SQL——窗口函数、CTE、阅读执行计划、星型架构查询、特定引擎优化（PostgreSQL、DuckDB、ClickHouse、BigQuery、Snowflake）
references/dbt-patterns.md	使用 dbt 设计数据转换管道——项目结构、建模层（staging/intermediate/facts/dimensions）、物化方式、测试、快照、Jinja 宏、CI/CD、dbt Mesh
references/etl-pipeline-design.md	构建可靠的数据管道——提取策略（全量、增量、CDC）、转换层、验证关卡、错误处理、幂等性
references/data-quality.md	监控数据完整性——质量维度、验证规则类型、异常检测、去重策略、管道健康信号
references/graph-databases.md	使用图数据库——Neo4j 数据建模、Cypher 查询模式（遍历、聚合、寻路）、导入策略、图算法、管道集成
references/time-series-databases.md	使用时序数据库——InfluxDB 数据模型（测量值、标签、字段）、架构设计（基数）、降采样、保留、Telegraf 数据摄取，以及与 TimescaleDB/QuestDB/Prometheus 的比较
references/vector-db-operations.md	管理向量数据库——Milvus、Qdrant、Chroma——索引类型、集合生命周期、维度迁移、备份策略
references/database-migrations.md	架构演进——零停机迁移模式、回滚规划、版本化架构、测试优先的迁移
references/backup-and-recovery.md	各类数据存储的备份策略、RPO/RTO 规划、WAL 归档、快照管理、恢复计划模板
references/ai-transformation-boundaries.md	为模型辅助转换定义验收、重试、成本和发布边界

相关技能

• postgres — PostgreSQL 服务本身的运维：配置审查、索引和查询计划诊断、vacuum／膨胀管理、WAL 归档和时间点恢复、复制和故障转移、升级。此技能负责特定数据库引擎的操作手册；数据工程负责与引擎无关的方法论。
• supabase — Supabase 平台运维：迁移、RLS、Auth、Storage、Functions 和自托管。要评估 Agent 执行 Supabase 任务的能力，请使用其 Agent 评估测试框架参考。

核心原则

没有完整性的数据只是噪声 — 任何管道、模型或仪表板都不比其所用数据的质量更重要。在每个边界进行验证。

以可运维性为设计目标 — 每个数据库、管道和存储都需要在投入生产前定义监控、备份和恢复流程。如果无法检测故障，就无法从故障中恢复。

幂等性是硬性要求 — 无论运行一次还是两次，每个管道都应产生相同结果。重复数据处理不可或缺。

架构变更就是代码变更 — 每次迁移都需要审查、测试和回滚计划。架构漂移是一种会不断累积代价的技术债务。

了解存储特性 — 访问模式、保留要求、增长速率和一致性保证决定了合适的存储架构。应根据数据选择，而不是凭熟悉程度。