केस स्टडी: दैनिक Sales Pipeline

डिज़ाइन

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 बनाते हैं।

एक पन्ने पर pipeline

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

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 को नियमित सुधार बना देता है।

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

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