mcpField
D
data-pipeline

data-pipeline

github.com/rightnow-aiData & databases18.2k108 installsUpdated 25w ago
Repository

About data-pipeline

A data-engineering skill for designing and operating production ETL/ELT pipelines. It focuses on orchestration, data quality, incremental processing, and batch and streaming patterns using tools such as Airflow, Spark, and dbt.

Key features

  1. 01Airflow orchestration patterns
  2. 02Spark job design
  3. 03dbt project structure and tests
  4. 04Data quality checks
  5. 05Incremental loads and backfills

Use cases

  1. 01Design reliable production data pipelines
  2. 02Add validation between pipeline stages
  3. 03Reprocess historical data by date range
  4. 04Handle failed records without stopping a pipeline

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/rightnow-ai/openfang --skill data-pipeline

After installing, type/data-pipelinein Claude Code to confirm it loaded.

Details

From the project README

Data Pipeline Expert

A data engineering specialist with extensive experience designing and operating production ETL/ELT pipelines, orchestration frameworks, and data quality systems. This skill provides guidance for building reliable, observable, and scalable data pipelines using industry-standard tools like Apache Airflow, Spark, and dbt across batch and streaming architectures.

Key Principles

  • Prefer ELT over ETL when your target warehouse can handle transformations; load raw data first, then transform in place for reproducibility and auditability
  • Design every pipeline step to be idempotent; re-running a task with the same inputs must produce the same outputs without side effects or duplicates
  • Partition data by time or logical keys at every stage; partitioning enables incremental processing, efficient pruning, and manageable backfill operations
  • Instrument pipelines with data quality checks between stages; catching bad data early prevents cascading corruption through downstream tables
  • Separate orchestration (when and what order) from computation (how); the scheduler should not perform heavy data processing itself

Techniques

  • Build Airflow DAGs with task-level retries, timeouts, and SLAs; use sensors for external dependencies and XCom for lightweight inter-task communication
  • Design Spark jobs with proper partitioning (repartition/coalesce), broadcast joins for small dimension tables, and caching for reused DataFrames
  • Structure dbt projects with staging models (source cleaning), intermediate models (business logic), and mart models (final consumption tables)
  • Write dbt tests at multiple levels: schema tests (not_null, unique, accepted_values), relationship tests, and custom data tests for business rules
  • Implement data quality gates using frameworks like Great Expectations: define expectations on row counts, column distributions, and referential integrity
  • Use Change Data Capture (CDC) patterns with tools like Debezium to stream database changes into event pipelines without polling

Common Patterns

  • Incremental Load: Process only new or changed records using high-watermark columns (updated_at) or CDC events, falling back to full reload on schema changes
  • Backfill Strategy: Design DAGs with date-parameterized runs so historical reprocessing uses the same code path as daily runs, just with different date ranges
  • Dead Letter Queue: Route failed records to a separate table or topic for investigation and reprocessing instead of halting the entire pipeline
  • Schema Evolution: Use schema registries (Avro, Protobuf) or column-add-only policies to evolve data contracts without breaking downstream consumers

Pitfalls to Avoid

  • Do not perform heavy computation inside Airflow operators; delegate to Spark, dbt, or external compute and use Airflow only for orchestration
  • Do not skip data validation after ingestion; silent schema changes from upstream sources are the most common cause of pipeline failures
  • Do not hardcode connection strings or credentials in pipeline code; use secrets managers and environment-based configuration
  • Do not run full table scans on every pipeline execution when incremental processing is feasible; it wastes compute and increases latency

Comments

Markdown supported