Executors और Deployment विकल्प

Tasks असल में कहाँ चलते हैं

Executor तय करता है कि tasks कैसे चलें। LocalExecutor उन्हें scheduler मशीन पर processes के रूप में चलाता है (सरल, छोटे setups के लिए ठीक)। CeleryExecutor message broker (Redis या RabbitMQ) के ज़रिए tasks को लंबे समय से चल रहे worker मशीनों के pool तक बाँटता है: scalable और शुरू होने में तेज़। KubernetesExecutor हर task के लिए नया pod शुरू करता है: मज़बूत अलगाव और प्रति-task संसाधन, शुरू होने के अतिरिक्त समय के साथ। हाल के Airflow versions कई executors साथ भी चला सकते हैं। आप Airflow ख़ुद चला सकते हैं (Docker Compose, Kubernetes पर official Helm chart) या शुल्क लेकर upgrades और scaling सँभालने वाली managed service (Amazon MWAA, Google Cloud Composer, Astronomer) उपयोग कर सकते हैं।

एक मशीन से टीम के platform तक

Executor चुनें, DAGs को Git और CI से भेजें, और scheduler तक पहुँचने से पहले उन्हें परखें।

Executor चुनना

शुरुआती मार्गदर्शिका; अपने workload पर benchmark करें।

Learning / tiny team          LocalExecutor (or standalone)
Steady load, many short tasks   CeleryExecutor (Redis/RabbitMQ + worker pool)
Mixed/heavy tasks, isolation    KubernetesExecutor (pod per task) or KubernetesPodOperator
Small platform team, want less ops   managed service (MWAA / Composer / Astronomer)

Metadata DB के लिए PostgreSQL

SQLite सिर्फ़ सीखने के लिए है। Production deployments metadata database के लिए PostgreSQL (या MySQL) उपयोग करते हैं, backups और monitoring के साथ, क्योंकि scheduler और हर task उसे पढ़ते-लिखते हैं।

त्वरित जाँच: कौन-सा executor हर task के लिए नया pod शुरू करता है?

• कोई executor ऐसा नहीं करता
• LocalExecutor
• CeleryExecutor
• KubernetesExecutor