核心用法
该 Skill 是一套结构化的 ETL/ELT 设计工作流，通过六个明确阶段指导用户构建健壮的数据管道：
1. 源契约阶段：记录上游系统的 schema、主键、变更标识符（如 updated_at 或 CDC 日志位置）及访问约束（速率限制、只读副本等），建立数据血缘的基础文档。
2. 提取策略阶段：权衡全量导出、增量水位标记与变更数据捕获（CDC）三种模式，根据数据规模、新鲜度要求和源系统负载选择最优方案。
3. 转换规则阶段：定义确定性转换逻辑，使用代理键隔离业务规则版本，明确删除处理策略（逻辑删除/墓碑标记 vs 物理删除）。
4. 加载与去重阶段：实现幂等的 upsert 机制，确保相同批处理 ID 重复执行产生一致结果，结合分区策略优化存储。
5. 验证阶段：建立行数核对、校验和、主键唯一性、引用完整性等多层检查，设置阈值告警机制。
6. 运维与回填阶段：支持按日期范围重放，监控延迟，对异常行进行死信队列隔离并标注原因代码。
显著优点
- 完整性覆盖：从源系统契约到运维监控的全生命周期设计视角，避免"只关注转换逻辑"的常见陷阱
- 工程严谨性：强调幂等性、确定性、可重放性等分布式系统核心原则，适配云原生数据架构
- 决策框架清晰：每个阶段提供明确的权衡维度（如 CDC vs 快照的取舍标准），降低架构决策的主观性
- 风险前置识别：内置对迟到事实（late-arriving facts）和渐变维度（slowly changing dimensions）的处理建议
- 零依赖零风险：纯文档型 Skill，无可执行代码，无外部 API 调用，无供应链攻击面
潜在缺点与局限性
- 非自动化工具：仅为设计指导文档，不提供代码生成、管道编排或实际的数据处理能力，需配合 data-pipelines 等技能使用
- 批处理导向：明确标注为批处理场景设计，近实时/流式场景需额外文档说明
- 技术中立性：未绑定特定技术栈（如 dbt、Spark、Flink），既带来灵活性也意味着需要自行映射到具体实现
- T3 来源：由个人开发者维护，虽采用 MIT-0 开源许可证，但缺乏企业级 SLA 保障
适合的目标群体
- 数据工程师：设计新数据管道或重构遗留系统时的架构评审参考
- 数据架构师：制定团队 ETL 标准规范，统一设计语言
- 技术负责人：评估数据项目技术方案时的检查清单（Checklist）工具
- 云迁移团队：将本地 ETL 作业迁移至云数据仓库（Snowflake、BigQuery、Redshift）时的设计重构指导
使用风险
- 性能风险：无直接性能影响，但若严格遵循文档中的 CDC 建议而未评估源系统 binlog 负载，可能引发上游数据库性能瓶颈
- 依赖项风险：该 Skill 本身零依赖，但配套使用的 data-pipelines 等编排工具需独立评估安全等级
- 认知风险：六阶段框架对简单场景可能过度设计，小型团队需根据实际复杂度裁剪使用
- 版本漂移：ETL 最佳实践随技术演进持续变化（如湖仓一体架构对传统 ETL 模式的冲击），建议关注作者更新或社区 fork 版本