# केस स्टडी: दैनिक Sales Pipeline — Apache Airflow: Data Pipelines का Orchestration

Source: https://www.geekswithgeeks.com/hi/airflow/wrap-case

> ऐसी दैनिक pipeline डिज़ाइन करें जो orders लोड करे, revenue table बनाए और dashboard ताज़ा करे।

## डिज़ाइन

`0 1 * * *` (01:00 UTC) schedule, `catchup=False` और `max_active_runs=1`। Tasks: **deferrable sensor** दिन की export फ़ाइल का इंतज़ार करता है; **extract** कच्ची rows को `{{ ds }}` द्वारा partitioned `staging.orders` में लोड करता है; **dbt build** उन्हें warehouse के भीतर, तारीख़ के लिए **delete-फिर-insert** से, `analytics.daily_orders` में transform करता है; **डेटा-गुणवत्ता** task row counts और null दरें जाँचता है और गड़बड़ होने पर run विफल करता है; अंतिम task dashboard cache ताज़ा करता है। Defaults: घातीय backoff के साथ 3 retries, 1-घंटे का `execution_timeout`, टीम को alert करने वाला `on_failure_callback`, और 3 slots का `source_db` pool। DAG बदलाव CI में import test के साथ pull requests से गुज़रते हैं। किसी भी पिछले हफ़्ते का backfill सुरक्षित है क्योंकि हर task idempotent है और run की तारीख़ उपयोग करता है।

## भरोसेमंद दैनिक pipeline

Idempotent tasks, तारीख़-आधारित partitions, retries, जाँचें और alerts मिलकर भरोसेमंद pipeline बनाते हैं।

![चार हिस्से: extract, transform, जाँच, publish।](assets/figures/airflow/section-8-map.svg) — चित्र 8.1 — Extract, transform, जाँच और publish।

## एक पन्ने पर pipeline

हर पंक्ति इस कोर्स के एक खंड से जुड़ती है।

```text
wait_for_export (deferrable sensor, timeout)  --> extract (partition dt={{ ds }})   (Sec 4, 3)
  --> dbt_build (delete+insert for the date, in warehouse)                         (Sec 5)
  --> check_rows (fails run on bad counts)  --> refresh_dashboard                  (Sec 6)
Defaults: retries=3 + backoff, execution_timeout=1h, on_failure_callback, pool source_db=3 (Sec 6)
Schedule: 0 1 * * *, catchup=False, max_active_runs=1                              (Sec 2)
Deploy: Git + PR review + DagBag import test, pinned versions, PostgreSQL metadata (Sec 7)
```

## Runbook लिखें

हर alert के लिए दर्ज करें कि उसका क्या मतलब है, कैसे जाँचें, कैसे re-run या backfill करें, और मालिक कौन है। छोटा runbook रात 3 बजे के page को नियमित सुधार बना देता है।

**Quiz:** इस डिज़ाइन में किसी भी पिछले हफ़्ते का backfill सुरक्षित क्यों है?

- [ ] डेटा कभी रखा नहीं जाता
- [ ] Airflow backfills मना करता है
- [x] Tasks idempotent हैं और run की तारीख़ उपयोग करते हैं
- [ ] क्योंकि कोई retries नहीं हैं

*Answer:* Tasks idempotent हैं और run की तारीख़ उपयोग करते हैं. निश्चित, तारीख़-partitioned writes का मतलब है कि तारीख़ दोबारा चलाने पर वही नतीजा मिलता है।