data-engineer

数据工程师

目的

提供专业的数据工程能力，用于构建可扩展的数据管道、ETL/ELT 工作流、数据湖和数据仓库。专注于分布式数据处理、流处理、数据质量和现代数据栈技术（Airflow、dbt、Spark、Kafka），并着重保障可靠性和优化成本。

适用场景

• 设计从数据源到消费层的端到端数据管道
• 实现包含错误处理和数据质量检查的 ETL/ELT 工作流
• 构建数据湖或数据仓库，并优化存储和查询
• 设置实时流处理（Kafka、Flink、Kinesis）
• 优化数据基础设施成本（存储分层、计算效率）
• 实施数据治理与合规措施（GDPR、数据血缘）
• 将旧版数据系统迁移到现代数据平台

快速入门

在以下情况调用此技能：

• 设计从数据源到消费层的端到端数据管道
• 实现包含错误处理和数据质量检查的 ETL/ELT 工作流
• 构建数据湖或数据仓库，并优化存储和查询
• 设置实时流处理（Kafka、Flink、Kinesis）
• 优化数据基础设施成本（存储分层、计算效率）
• 实施数据治理与合规措施（GDPR、数据血缘）

以下情况请勿调用：

• 只需优化 SQL 查询（改用 database-optimizer）
• 开发机器学习模型（改用 ml-engineer 或 data-scientist）
• 进行简单的数据分析或可视化（改用 data-analyst）
• 执行数据库管理任务（改用 database-administrator）
• 集成 API，但不进行数据转换（改用 backend-developer）

决策框架

管道架构选择

├─ Batch Processing?
│   ├─ Daily/hourly schedules → Airflow + dbt
│   │   Pros: Mature ecosystem, SQL-based transforms
│   │   Cost: Low-medium
│   │
│   ├─ Large-scale (TB+) → Spark (EMR/Databricks)
│   │   Pros: Distributed processing, handles scale
│   │   Cost: Medium-high (compute-intensive)
│   │
│   └─ Simple transforms → dbt Cloud or Fivetran
│       Pros: Managed, low maintenance
│       Cost: Medium (SaaS pricing)
│
├─ Stream Processing?
│   ├─ Event streaming → Kafka + Flink
│   │   Pros: Low latency, exactly-once semantics
│   │   Cost: High (always-on infrastructure)
│   │
│   ├─ AWS native → Kinesis + Lambda
│   │   Pros: Serverless, auto-scaling
│   │   Cost: Variable (pay per use)
│   │
│   └─ Simple CDC → Debezium + Kafka Connect
│       Pros: Database change capture
│       Cost: Medium
│
└─ Hybrid (Batch + Stream)?
    └─ Lambda Architecture or Kappa Architecture
        Lambda: Separate batch/speed layers
        Kappa: Single stream-first approach

数据存储选择

用例	技术	优点	缺点
结构化分析	Snowflake/BigQuery	SQL、查询速度快	大规模使用时成本高
半结构化数据	Delta Lake/Iceberg	ACID、架构演进	复杂
原始存储	S3/GCS	便宜、持久	无查询引擎
实时数据	Redis/DynamoDB	延迟低	分析能力有限
时间序列数据	TimescaleDB/InfluxDB	针对时间数据进行了优化	适用场景特定

ETL 与 ELT 的选择

因素	ETL（先转换）	ELT（先加载）
数据量	小到中等	大（TB+）
转换	复杂，加载前完成	基于 SQL，在仓库内完成
延迟	较高	较低
成本	加载前计算	仓库计算
最适合	旧版系统	现代云数据仓库

核心模式

模式 1：幂等分区覆盖

用例： 安全地重新运行批处理作业，避免产生重复数据。

# PySpark example: Overwrite partition based on execution date
def write_daily_partition(df, target_table, execution_date):
    (df
     .write
     .mode("overwrite")
     .partitionBy("process_date")
     .option("partitionOverwriteMode", "dynamic")
     .format("parquet")
     .saveAsTable(target_table))

模式 2：缓慢变化维度 2 型（SCD2）

用例： 跟踪变更历史，同时保留过去的状态。

-- dbt implementation of SCD2
{{ config(materialized='incremental', unique_key='user_id') }}

SELECT 
    user_id, address, email, status, updated_at,
    LEAD(updated_at, 1, '9999-12-31') OVER (
        PARTITION BY user_id ORDER BY updated_at
    ) as valid_to
FROM {{ source('raw', 'users') }}

模式 3：流处理死信队列（DLQ）

用例： 处理格式错误的消息，同时不中断管道。

模式 4：数据质量断路器

用例： 如果数据质量低于阈值，则停止管道执行。

质量检查清单

数据管道

• 幂等（可安全重试）
• 强制执行架构验证
• 包含重试机制的错误处理
• 自动执行数据质量检查
• 已配置监控和告警
• 已记录数据血缘

性能

• 管道在 SLA 规定时间内完成（例如，<1 小时）
• 在适用情况下采用增量加载
• 已优化分区策略
• 查询性能 <30 秒（P95）

成本优化

• 已实施存储分层（热/温/冷）
• 已配置计算自动扩缩
• 已启用查询成本监控
• 已启用压缩（Parquet/ORC）

更多资源

• 详细技术参考：参见 REFERENCE.md
• 代码示例与模式：参见 EXAMPLES.md