Airflow के शीर्ष 21 इंटरव्यू प्रश्न और उनके उत्तर देने का तरीका

Airflow इंटरव्यू के बेसिक्स और कोर कॉन्सेप्ट

टेक्निकल इंटरव्यू में इंटरव्यूअर आमतौर पर आसान से शुरू करते हैं—Airflow के फ्रेमवर्क और कोर कॉन्सेप्ट के बेसिक्स पर—और फिर धीरे-धीरे अधिक जटिल और तकनीकी प्रश्नों की ओर बढ़ते हैं।

इन प्रश्नों के उत्तर देते समय, सिर्फ तकनीकी विवरण ही नहीं, बल्कि यह भी बताएं कि यह डेटा इंजीनियरिंग और/या एंटरप्राइज डेटा वर्कफ़्लो से कैसे जुड़ता है।

1. Apache Airflow क्या है? इसका सबसे आम उपयोग कैसे होता है?

उत्तर: Apache Airflow एक ओपन-सोर्स डेटा ऑर्केस्ट्रेशन टूल है, जो Python की मदद से डेटा प्रैक्टिशनर्स को प्रोग्राममैटिकली डेटा पाइपलाइन परिभाषित करने देता है। Airflow का सबसे आम उपयोग डेटा इंजीनियरिंग टीमों द्वारा अपने डेटा इकोसिस्टम को इंटीग्रेट करने और डेटा को एक्सट्रैक्ट, ट्रांसफॉर्म और लोड करने में होता है।

और बताइए: Airflow Apache सॉफ्टवेयर लाइसेंस के तहत मेंटेन होता है (इसीलिए इसके आगे “Apache” जुड़ा है)।

डेटा ऑर्केस्ट्रेशन टूल ऐसी क्षमता देता है जिससे कई स्रोतों और सेवाओं को एक एकल पाइपलाइन में इंटीग्रेट किया जा सके।

Airflow को अलग बनाता है इसका Python द्वारा डेटा पाइपलाइन परिभाषित करना—जो ऐसी एक्स्टेंसिबिलिटी और नियंत्रण देता है जो अन्य डेटा ऑर्केस्ट्रेशन टूल अक्सर नहीं देते। Airflow में इनबिल्ट और प्रोवाइडर-सपोर्टेड टूल्स की बड़ी रेंज है जिससे किसी भी टीम के डेटा स्टैक को इंटीग्रेट किया जा सकता है, साथ ही अपने खुद के टूल डिजाइन करने की क्षमता भी।

Airflow से शुरुआत करने के लिए अधिक जानकारी हेतु यह DataCamp ट्यूटोरियल देखें: Getting Started with Apache Airflow। यदि आप Airflow के साथ डेटा ऑर्केस्ट्रेशन की दुनिया में और गहराई तक जाना चाहते हैं, तो यह Introduction to Airflow कोर्स शुरू करने के लिए बेहतरीन जगह है।

2. DAG क्या है?

उत्तर: DAG, या directed-acyclic graph, टास्क्स और उनके बीच के रिश्तों का एक संग्रह है। एक DAG की स्पष्ट शुरुआत और अंत होता है और इसमें टास्क्स के बीच कोई “साइकिल” नहीं होती। Airflow में “DAG” शब्द आम है और इसे सामान्यतः डेटा पाइपलाइन के रूप में समझा जा सकता है।

और बताइए: यह थोड़ा पेचीदा सवाल है। जब इंटरव्यूअर यह पूछे, तो DAG की औपचारिक “गणितीय” परिभाषा और Airflow में इसके उपयोग—दोनों को संबोधित करना ज़रूरी है। DAGs के बारे में सोचते समय विज़ुअल देखना मदद करता है। नीचे पहली छवि वास्तव में एक DAG है—इसकी स्पष्ट शुरुआत और अंत है और टास्क्स के बीच कोई साइकिल नहीं।

नीचे दिखी दूसरी प्रक्रिया DAG नहीं है। भले ही एक स्पष्ट स्टार्ट टास्क है, extract और validate टास्क्स के बीच एक साइकिल है, जिससे यह स्पष्ट नहीं कि load टास्क कब ट्रिगर होगा।

3. एक DAG परिभाषित करने के लिए किन तीन पैरामीटरों की जरूरत होती है?

उत्तर: DAG परिभाषित करने के लिए ID, start date और schedule interval देना आवश्यक है।

और बताइए: ID DAG की यूनिक पहचान है और आमतौर पर एक छोटा स्ट्रिंग होता है, जैसे "sample_da." Start date वह तारीख और समय है जब पहली बार DAG ट्रिगर होगा।

यह एक टाइमस्टैम्प होता है, यानी सटीक वर्ष, महीना, दिन, घंटा और मिनट निर्धारित होते हैं। Schedule interval बताता है कि DAG कितनी बार चलना चाहिए—हर सप्ताह, हर दिन, हर घंटे, या कुछ कस्टम।

इस उदाहरण में, DAG को dag_id "sample_dag" से परिभाषित किया गया है। datetime लाइब्रेरी के datetime फ़ंक्शन का उपयोग कर start_date को 1 जनवरी, 2024, सुबह 9:00 पर सेट किया गया है। यह DAG दैनिक (@daily) चलेगा (सुबह 9:00 पर)। और अधिक कस्टम शेड्यूल के लिए cron expressions या datetime लाइब्रेरी के timedelta फ़ंक्शन का उपयोग किया जा सकता है।

with DAG(
   	 dag_id="sample_dag",
	start_date=datetime(year=2024, month=1, day=1, hour=9, minute=0),
	schedule="@daily",
) as dag:
    …
संचालित द्वारा

4. Airflow टास्क क्या है? Airflow टास्क के तीन उदाहरण दीजिए।

उत्तर: Airflow टास्क Airflow फ्रेमवर्क में निष्पादन की सबसे छोटी इकाई है। एक टास्क आमतौर पर डेटा पाइपलाइन (DAG) में एक एकल ऑपरेशन को समाहित करता है। टास्क्स DAGs के निर्माण खंड हैं, और एक DAG के भीतर टास्क्स के बीच रिश्ते तय करते हैं कि वे किस क्रम में चलेंगे। तीन उदाहरण:

• किसी स्रोत प्रणाली (जैसे API या फ्लैट-फाइल) से डेटा निकालना
• डेटा को वांछित मॉडल या फ़ॉर्मेट में ट्रांसफॉर्म करना
• डेटा को किसी स्टोरेज टूल (जैसे डेटाबेस या डेटा वेयरहाउस) में लोड करना

एक ETL पाइपलाइन में, रिश्ते इस प्रकार होंगे:

• “transform” टास्क “extract” टास्क का डाउनस्ट्रीम है, यानी पहले “extract” लॉजिक चलता है
• “load” टास्क “transform” टास्क का डाउनस्ट्रीम है। यानी “transform” के बाद “load” चलेगा

और बताइए: टास्क्स बहुत जनरल भी हो सकते हैं और काफी कस्टम भी। Airflow इन्हें परिभाषित करने के दो तरीके देता है: पारंपरिक ऑपरेटर्स और TaskFlow API (इसके बारे में आगे)।

ओपन-सोर्स का एक लाभ व्यापक समुदाय का योगदान है—जिसमें व्यक्तिगत कॉन्ट्रिब्यूटर्स के साथ AWS, Databricks, Snowflake और बहुत से अन्य खिलाड़ी शामिल हैं।

संभावना है कि जिस टास्क को आप परिभाषित करना चाहते हैं, उसके लिए Airflow ऑपरेटर पहले से बना हो। अगर नहीं, तो अपना बनाना आसान है। कुछ उदाहरण हैं SFTPToS3Operator, S3ToSnowflakeOperator, और DatabricksRunNowOperator।

5. Airflow की आर्किटेक्चर के कोर कंपोनेंट्स क्या हैं?

उत्तर: Airflow की आर्किटेक्चर के चार कोर कंपोनेंट्स हैं: scheduler, executor, metadata database और webserver।

और बताइए: Scheduler हर मिनट DAG डायरेक्टरी की जाँच करता है और DAGs व टास्क्स की निगरानी करता है ताकि यह पहचाने कि कौन से टास्क ट्रिगर हो सकते हैं। Executor वह स्थान है जहां टास्क्स चलते हैं। टास्क्स लोकली (scheduler के भीतर) या रिमोटली (scheduler के बाहर) निष्पादित हो सकते हैं।

Executor पर ही प्रत्येक टास्क का कंप्यूटेशनल “काम” होता है। Metadata database में चल रहे Airflow प्रोजेक्ट से जुड़े DAGs और टास्क्स की सभी जानकारी होती है—जैसे ऐतिहासिक निष्पादन विवरण, कनेक्शंस, वेरिएबल्स और अन्य बहुत कुछ।

Webserver Airflow UI को रेंडर और इंटरैक्ट करने देता है—जब आप DAGs विकसित, उपयोग और मेंटेन करते हैं।

यह Airflow के कोर आर्किटेक्चरल कंपोनेंट्स का सिर्फ एक त्वरित अवलोकन है।

Airflow DAGs इंटरव्यू प्रश्न

आपने दिखा दिया कि आपको Airflow फ्रेमवर्क और उसकी आर्किटेक्चर के बेसिक्स आते हैं। अब, आपकी DAG लिखने की समझ की बारी है।

6. PythonOperator क्या है? इस ऑपरेटर का उपयोग करने की आवश्यकताएँ क्या हैं? आप कब PythonOperator का उपयोग करना चाहेंगे—एक उदाहरण दीजिए?

उत्तर: PythonOperator एक फ़ंक्शन है जो किसी Python फ़ंक्शन को Airflow टास्क के रूप में निष्पादित करने देता है। इस ऑपरेटर का उपयोग करने के लिए, किसी Python फ़ंक्शन को python_callable पैरामीटर में पास करना होता है। उदाहरण के लिए, जब आप डेटा निकालने के लिए किसी API को हिट करना चाहें।

और बताइए: PythonOperator Airflow के सबसे शक्तिशाली ऑपरेटर्स में से एक है। यह न सिर्फ कस्टम कोड को DAG के भीतर चलाने देता है, बल्कि परिणामों को XComs में लिखकर डाउनस्ट्रीम टास्क्स द्वारा उपयोग भी करने देता है।

op_kwargs पैरामीटर में एक dictionary पास करके, आप Python callable को कीवर्ड आर्ग्युमेंट्स दे सकते हैं—जो रनटाइम पर और अधिक कस्टमाइजेशन की सुविधा देता है। op_kwargs के अलावा भी कई पैरामीटर्स हैं जो PythonOperator की क्षमता बढ़ाते हैं।

नीचे PythonOperator का एक सैंपल कॉल है। सामान्यतः, python_callable को पास किया गया Python फ़ंक्शन DAG परिभाषा वाली फ़ाइल के बाहर परिभाषित होता है, लेकिन यहाँ विस्तार के लिए शामिल किया गया है।

def some_callable(name):
print("Hello ", name)

...

some_task = PythonOperator(
task_id="some_task",
	python_callable=some_callable,
	op_kwargs={"name": "Charles"}
)
संचालित द्वारा

7. यदि आपके पास तीन टास्क हैं और आप चाहते हैं कि वे क्रमिक रूप से चलें, तो आप उनके बीच डिपेंडेंसी कैसे सेट करेंगे? कौन-सा सिंटैक्स उपयोग करेंगे?

उत्तर: ऐसा करने के कई तरीके हैं। सबसे आम है >> बिट-शिफ्ट ऑपरेटर का उपयोग। दूसरा तरीका है .set_downstream() मेथड से किसी टास्क को दूसरे का डाउनस्ट्रीम सेट करना। chain फ़ंक्शन भी क्रमिक डिपेंडेंसी सेट करने में उपयोगी है। तीन उदाहरण:

# task_1, task_2, task_3 ऊपर instantiate किए गए हैं

# बिट-शिफ्ट ऑपरेटर्स का उपयोग
task_1 >> task_2 >> task_3

# .set_downstream() का उपयोग
task_1.set_downstream(task_2)
task_2.set_downstream(task_3)

# chain का उपयोग
chain(task_1, task_2, task_3)
संचालित द्वारा

और बताइए: डिपेंडेंसी सेट करना कभी सरल होता है, कभी काफी जटिल! क्रमिक निष्पादन के लिए, अधिक स्पष्टता हेतु बिट-शिफ्ट ऑपरेटर्स का उपयोग आम है। TaskFlow API का उपयोग करते समय, टास्क्स के बीच डिपेंडेंसी सेट करना थोड़ा अलग दिख सकता है।

यदि दो टास्क निर्भर हैं, तो ऊपर दिए तरीकों के बजाय एक फ़ंक्शन कॉल को दूसरे फ़ंक्शन में आर्ग्युमेंट के रूप में पास करके भी यह दर्शाया जा सकता है। Airflow की टास्क डिपेंडेंसी पर अलग लेख में और जानें।

8. Task Groups क्या हैं? इन्हें DAGs के भीतर कैसे उपयोग किया जाता है?

उत्तर: Task groups का उपयोग एक DAG के भीतर टास्क्स को समूहित कर व्यवस्थित करने के लिए किया जाता है। इससे Airflow UI में समान टास्क्स को एक साथ दर्शाना आसान हो जाता है। अलग-अलग टीमों से संबंधित डेटा के extract, transform, और load कार्यों को एक ही DAG में संभालते समय task groups उपयोगी हो सकते हैं।

Task groups का उपयोग अक्सर तब भी होता है जब कई ML मॉडलों को ट्रेन करना हो या एक ही DAG में कई (पर समान) स्रोत प्रणालियों से इंटरैक्ट करना हो।

Airflow में task groups उपयोग करने पर, प्राप्त ग्राफ व्यू कुछ ऐसा दिख सकता है:

और बताइए: पारंपरिक Airflow सिंटैक्स में, TaskGroup फ़ंक्शन का उपयोग task groups बनाने के लिए किया जाता है। Task groups स्पष्ट रूप से या डायनेमिक रूप से बनाए जा सकते हैं, लेकिन इनके IDs यूनिक होने चाहिए (DAGs की तरह)।

हालाँकि, एक ही DAG में अलग-अलग task groups में समान task_id वाले टास्क्स हो सकते हैं। तब टास्क को उसके task group ID और task ID के संयोजन से यूनिक पहचाना जाएगा। TaskFlow API का उपयोग करते समय, @task_group डेकोरेटर से भी task group बनाया जा सकता है।

9. आप बिना एक ही कोड को कॉपी-पेस्ट किए कई DAGs को डायनेमिक रूप से कैसे जेनरेट कर सकते हैं? किन बातों का ध्यान रखना चाहिए?

उत्तर: डायनेमिक रूप से DAGs जेनरेट करना एक उपयोगी तकनीक है जिससे एक ही “कोड के टुकड़े” से कई DAGs बनाए जा सकते हैं। कई लोकेशनों से डेटा खींचना इसका बढ़िया उदाहरण है। यदि आपको एक ही लॉजिक से तीन एयरपोर्ट्स से डेटा को extract, transform और load करना है, तो डायनेमिक DAGs इस प्रक्रिया को बेहतर बनाते हैं।

इसे करने के कई तरीके हैं। सबसे आसान है एक मेटाडेटा लिस्ट का उपयोग, जिस पर लूप चलाया जाए। फिर लूप के भीतर एक DAG instantiate किया जाए। ध्यान रखें कि हर DAG का यूनिक DAG ID होना चाहिए। कोड कुछ ऐसा दिख सकता है:

airport_codes = ["atl", "lax", "jfk"]

for code in airport_codes:
with DAG(
dag_id=f"{code}_daily_etl"
		start_date=datetime(2024, 1, 1, 9, 0),
		schedule="@daily"
) as dag:
# Rest of the DAG definition
...
संचालित द्वारा

यह कोड तीन DAGs बनाएगा, जिनके DAG IDs होंगे atl_daily_etl, lax_daily_etl, और jfk_daily_etl। आगे, टास्क्स को उसी एयरपोर्ट कोड से पैरामीटराइज़ किया जा सकता है ताकि हर DAG अपेक्षित रूप से चले।

और बताइए: डायनेमिक DAG जेनरेशन एंटरप्राइज सेटिंग में आम तकनीक है। जब एक ही DAG में प्रोग्राममैटिक रूप से task groups बनाने और डायनेमिक रूप से DAGs जेनरेट करने के बीच निर्णय लें, तो ऑपरेशंस के बीच रिश्तों पर विचार करें।

ऊपर के उदाहरण में, यदि एक एयरपोर्ट किसी exception का कारण बन रहा है, तो task groups उपयोग करने पर पूरा DAG फेल हो जाएगा। लेकिन यदि DAGs डायनेमिक रूप से जेनरेट किए गए हों, तो यह एकल फेल्योर दूसरे दो DAGs को प्रभावित नहीं करेगा।

Python iterable पर लूप चलाना डायनेमिक DAGs जेनरेट करने का एकमात्र तरीका नहीं है—create_dag फ़ंक्शन परिभाषित करना, variables/connections का उपयोग कर DAGs स्पॉन करना, या JSON कॉन्फ़िगरेशन फ़ाइल का लाभ उठाना—ये सभी सामान्य विकल्प हैं। gusty और dag-factory जैसे थर्ड-पार्टी टूल कॉन्फ़िगरेशन-आधारित अन्य अप्रोच भी देते हैं।

उन्नत Airflow इंटरव्यू प्रश्न

Airflow और DAG डेवलपमेंट के बेसिक्स को समझना और बताना, ज्यूनियर-लेवल की भूमिका के लिए अक्सर पर्याप्त होता है। लेकिन Airflow में महारत सिर्फ DAGs लिखने और चलाने से बढ़कर है।

नीचे दिए प्रश्न-उत्तर इंटरव्यूअर को Airflow की अधिक जटिल क्षमताओं की गहरी समझ दिखाने में मदद करेंगे—जो आमतौर पर सीनियर भूमिकाओं के लिए आवश्यक होती है।

10. data_interval_start और data_interval_end, दिए होने पर DAG कब निष्पादित होता है?

उत्तर: नाम से स्पष्ट है, data_interval_start और data_interval_end DAG रन के समय-सीमा निर्धारक हैं। यदि DAG को बैकफिल किया जा रहा है, और DAG के निष्पादन का समय data_interval_end से बड़ा है, तो DAG तुरंत रन के लिए क्यू किया जाएगा।

हालाँकि, “सामान्य” निष्पादन में, DAG तब तक नहीं चलेगा जब तक कि निष्पादन का समय **data_interval_end** से बड़ा न हो।

और बताइए: यह अवधारणा कठिन है, खासकर क्योंकि DAG रन कैसे लेबल होते हैं। इसे ऐसे समझें: आप 17 मार्च, 2024 के सभी डेटा किसी API से खींचना चाहते हैं।

यदि शेड्यूल इंटरवल डेली है, तो इस रन के लिए data_interval_start 2024-03-17, 00:00:00 UTC होगा और data_interval_end 2024-03-18, 00:00:00 UTC। 2024-03-17, 00:00:00 UTC पर DAG चलाना समझदारी नहीं, क्योंकि 17 मार्च का डेटा उपलब्ध नहीं होगा। इसके बजाय, DAG 2024-03-18, 00:00:00 UTC के data_interval_end पर निष्पादित होगा।

11. catchup पैरामीटर क्या है, और यह Airflow DAG के निष्पादन को कैसे प्रभावित करता है?

उत्तर: catchup पैरामीटर DAG instantiate करते समय परिभाषित होता है। catchup का मान True या False हो सकता है—डिफ़ॉल्ट True है यदि स्पष्ट रूप से न दिया जाए। यदि True, तो start date और वह समय जब DAG का स्टेटस पहली बार active किया गया—उनके बीच के सभी DAG runs चलेंगे।

मान लीजिए DAG का start date 1 जनवरी, 2024 है, शेड्यूल डेली है, और catchup=True है। यदि यह DAG पहली बार 15 अप्रैल, 2024 को active किया गया, तो 1 जनवरी, 2024 के data_interval_start वाला रन चलेगा, फिर 2 जनवरी, 2024 (और आगे ऐसे ही)।

यह तब तक जारी रहेगा जब तक DAG “कॅच अप” नहीं हो जाता—फिर सामान्य व्यवहार पर लौटेगा। इसे “backfilling” कहते हैं। बैकफिलिंग काफी तेज़ हो सकती है—यदि आपका DAG रन कुछ ही मिनट लेता है, तो कुछ महीनों के ऐतिहासिक रन कुछ घंटों में पूरे हो सकते हैं।

यदि False, तो कोई ऐतिहासिक रन निष्पादित नहीं होंगे, और पहला रन उस इंटरवल के अंत में शुरू होगा जिसके दौरान DAG स्टेटस रन पर सेट किया गया था।

और बताइए: बिना बड़े कोड बदलाव या मैनुअल प्रयास के DAG runs को बैकफिल करने की क्षमता Airflow की सबसे शक्तिशाली खूबियों में से एक है। मान लें कि आप पिछले एक वर्ष के सभी ट्रांज़ैक्शंस किसी API से खींचने का इंटीग्रेशन बना रहे हैं।

एक बार DAG बन जाने पर, बस मनचाहा start date सेट करें और catchup=True कर दें—हिस्टोरिकल डेटा निकालना आसान हो जाता है।

यदि आप पहली बार active करते समय बैकफिल नहीं करना चाहते, तो चिंता न करें! बैकफिल्स को व्यवस्थित रूप से ट्रिगर करने के और भी तरीके हैं—Airflow API और Airflow (और Astro CLI) से यह किया जा सकता है।

12. XComs क्या हैं, और आम तौर पर इनका उपयोग कैसे होता है?

उत्तर: XComs (cross-communications) Airflow की एक सूक्ष्म विशेषता है जो टास्क्स के बीच संदेशों को स्टोर और प्राप्त करने देती है।

XComs key-value पेयर्स में स्टोर होते हैं, और कई तरीकों से पढ़े-लिखे जा सकते हैं। PythonOperator का उपयोग करते समय, callable के भीतर .xcom_push() और .xcom_pull() मेथड्स से XComs में डेटा “push” और “pull” किया जा सकता है। XComs में छोटे डेटा—जैसे फाइल नाम या एक boolean फ्लैग—स्टोर किए जाते हैं।

और बताइए: .xcom_push() और .xcom_pull() के अलावा भी XComs में डेटा लिखने-पढ़ने के कई तरीके हैं। PythonOperator इस्तेमाल करते समय, do_xcom_push पैरामीटर को True देने पर callable द्वारा रिटर्न किया गया मान XComs में लिखा जाता है।

यह केवल PythonOperator तक सीमित नहीं—कोई भी ऑपरेटर जो कोई वैल्यू रिटर्न करता है, उसके रिटर्न मान को do_xcom_push पैरामीटर से XComs में लिखा जा सकता है। पृष्ठभूमि में, TaskFlow API भी टास्क्स के बीच डेटा साझा करने के लिए XComs का उपयोग करता है (आगे देखेंगे)।

13. TaskFlow API के बारे में बताइए, और यह पारंपरिक ऑपरेटर्स से कैसे अलग है?

उत्तर: TaskFlow API DAGs लिखने का एक नया, अधिक सहज और “Pythonic” तरीका देता है। पारंपरिक ऑपरेटर्स के बजाय, Python फ़ंक्शन्स को @task डेकोरेटर से सजाया जाता है, और बिना स्पष्ट रूप से परिभाषित किए यह टास्क डिपेंडेंसीज़ को infer कर सकता है।

TaskFlow API में लिखा टास्क कुछ ऐसा दिख सकता है:

import random

...

@task
def get_temperature():
# Pull a temperature, return the value
	temperature = random.randint(0, 100)
	return temperature
…
संचालित द्वारा

TaskFlow API के साथ, टास्क्स के बीच डेटा साझा करना आसान है। सीधे XComs का उपयोग करने के बजाय, एक टास्क (फ़ंक्शन) का रिटर्न मान दूसरे टास्क में आर्ग्युमेंट के रूप में सीधे पास किया जा सकता है। इस पूरी प्रक्रिया में पर्दे के पीछे XComs ही उपयोग होते हैं—यानी बड़े डेटा को टास्क्स के बीच साझा नहीं किया जा सकता, भले TaskFlow API इस्तेमाल हो।

और बताइए: TaskFlow API Airflow का DAG लेखन को आसान बनाने का प्रयास है, ताकि यह डेटा वैज्ञानिकों और विश्लेषकों जैसे व्यापक दर्शकों को आकर्षित करे। जबकि TaskFlow API क्लाउड डेटा इकोसिस्टम इंटीग्रेशन चाहने वाली डेटा इंजीनियरिंग टीमों की हर ज़रूरत नहीं पूरी करता, यह बेसिक ETL टास्क्स के लिए विशेष रूप से उपयोगी (और सहज) है।

TaskFlow API और पारंपरिक ऑपरेटर्स एक ही DAG में साथ उपयोग किए जा सकते हैं—पारंपरिक ऑपरेटर्स की इंटीग्रेबिलिटी और TaskFlow API की सरलता, दोनों का लाभ मिलता है। TaskFlow API के बारे में अधिक जानने के लिए यह डॉक्यूमेंटेशन देखें।

14. Idempotency क्या है? Airflow DAGs बनाते समय इसे ध्यान में रखना क्यों ज़रूरी है?

उत्तर: Idempotency किसी प्रक्रिया/ऑपरेशन का गुण है जो उस प्रक्रिया को कई बार करने पर भी प्रारंभिक परिणाम को नहीं बदलता। सरल शब्दों में, यदि आप DAG एक बार चलाएँ या दस बार—परिणाम समान होना चाहिए।

एक आम वर्कफ़्लो जहाँ ऐसा नहीं होता—स्ट्रक्चर्ड (SQL) डेटाबेस में डेटा insert करना। यदि primary key लागू किए बिना डेटा insert किया गया और DAG कई बार चला, तो टेबल में डुप्लिकेट्स आ जाएँगे। delete-insert या “upsert” जैसे पैटर्न का उपयोग डेटा पाइपलाइनों में idempotence लागू करने में मदद करता है।

और बताइए: यह पूरी तरह Airflow-विशिष्ट नहीं, पर डेटा पाइपलाइन्स डिजाइन व निर्माण करते समय अनिवार्य है। सौभाग्य से, Airflow कई टूल देता है जो idempotency लागू करना आसान बनाते हैं। फिर भी, इसका अधिकांश लॉजिक प्रैक्टिशनर को ही डिजाइन, विकसित और टेस्ट करना होगा।

प्रोडक्शन Airflow वर्कफ़्लोज़ का प्रबंधन और मॉनिटरिंग: इंटरव्यू प्रश्न

ज़्यादा तकनीकी भूमिकाओं में, इंटरव्यूअर प्रोडक्शन-ग्रेड Airflow डिप्लॉयमेंट के प्रबंधन और मॉनिटरिंग से जुड़े प्रश्न पूछ सकते हैं—जैसा वे अपनी टीम में चलाते हों। ये प्रश्न थोड़े मुश्किल होते हैं और इंटरव्यू से पहले अधिक तैयारी माँगते हैं।

15. एक DAG लिखने के बाद, आप उसे कैसे टेस्ट करेंगे? शुरुआत से अंत तक प्रक्रिया बताइए।

उत्तर: DAG लिखने के बाद उसे टेस्ट करने के कुछ तरीके हैं। सबसे आम है DAG को एक्जीक्यूट करके देखना कि वह सफलतापूर्वक चलता है या नहीं। यह लोकल Airflow वातावरण स्पिन-अप करके और Airflow UI से DAG ट्रिगर करके किया जा सकता है।

DAG ट्रिगर होने के बाद, उसके प्रदर्शन को मॉनिटर किया जा सकता है—यानी DAG और व्यक्तिगत टास्क्स की सफलता/असफलता, और रन में लगा समय व संसाधन।

मैन्युअल निष्पादन के अलावा, DAGs के यूनिट टेस्ट भी लिखे जा सकते हैं। Airflow CLI के माध्यम से टेस्ट एक्जीक्यूट करने के टूल देता है, या कोई स्टैंडर्ड टेस्ट रनर उपयोग किया जा सकता है। ये यूनिट टेस्ट DAG कॉन्फ़िगरेशन और निष्पादन—दोनों पर, और Airflow प्रोजेक्ट के अन्य कंपोनेंट्स (जैसे callables और plugins) पर भी लिखे जा सकते हैं।

और बताइए: Airflow DAGs की टेस्टिंग डेटा इंजीनियर का सबसे महत्वपूर्ण कार्यों में से एक है। यदि DAG टेस्ट नहीं हुआ, तो वह प्रोडक्शन वर्कफ़्लोज़ सपोर्ट करने के लिए तैयार नहीं है।

डेटा पाइपलाइनों की टेस्टिंग खास तौर से कठिन है; ऐसे edge और corner cases होते हैं जो अन्य विकास परिदृश्यों में आम नहीं। अधिक तकनीकी इंटरव्यू (खासकर लीड/सीनियर इंजीनियर) में, एंड-टू-एंड DAG टेस्टिंग के महत्व पर ज़ोर दें—साथ ही यूनिट टेस्ट लिखने और उनके परिणामों का दस्तावेज़ीकरण करने पर भी।

16. आप DAG फेल्योर को कैसे संभालते हैं? त्रिएज और फिक्स करने के लिए क्या करते हैं?

उत्तर: DAG फेल्योर किसी को पसंद नहीं, पर उन्हें शालीनता से संभालना आपको एक डेटा इंजीनियर के रूप में अलग खड़ा कर सकता है। सौभाग्य से, Airflow के पास फेल्योर को कैप्चर, अलर्ट और सुधारने के लिए ढेरों टूल हैं। पहले, DAG का फेल्योर Airflow UI में कैप्चर होता है। DAG की स्टेट “failed” में बदल जाएगी, और ग्रिड व्यू में इस रन के लिए लाल चौकोर/आयत दिखेगा। फिर, UI में ही इस टास्क के लॉग्स को मैन्युअली पार्स किया जा सकता है।

आम तौर पर ये लॉग्स वह exception देंगे जिसने फेल्योर कराया और आगे त्रिएज के लिए जानकारी देंगे।

मुद्दा पहचानने के बाद, DAG के अंतर्निहित कोड/कॉनफिग को अपडेट किया जा सकता है, और DAG को फिर चलाया जा सकता है—DAG की स्टेट क्लियर कर उसे “active” सेट करके।

यदि कोई DAG नियमित रूप से फेल होता है पर retry पर चल जाता है, तो Airflow के retries और retry_delay का उपयोग मददगार हो सकता है। ये दो पैरामीटर्स फेल्योर पर किसी टास्क को निर्दिष्ट बार retry करवाते हैं—निर्धारित विलंब के बाद। यह SFTP साइट से फाइल खींचने जैसे परिदृश्यों में उपयोगी है, जहाँ फाइल देर से आ सकती है।

और बताइए: DAG के फेल होने के लिए, कोई विशेष टास्क फेल होना चाहिए। पूरे DAG के बजाय उसी टास्क का त्रिएज करना ज़रूरी है। UI में निर्मित क्षमताओं के अलावा, DAG प्रदर्शन को मॉनिटर और मैनेज करने के और भी बहुत से टूल्स हैं।

Callbacks डेटा इंजीनियर्स को DAG सफलता और विफलता संभालने में लगभग असीम कस्टमाइज़ेशन देते हैं। on_success_callback और on_failure_callback पैरामीटर्स से, ऑपरेटर किसी चुनी हुई फ़ंक्शन को DAG की सफलता या विफलता पर चला सकता है। यह फ़ंक्शन PagerDuty जैसे टूल को संदेश भेज सकता है या परिणाम किसी डेटाबेस में लिख सकता है ताकि बाद में अलर्ट किया जा सके—दृश्यता बढ़ती है और फेल्योर होने पर त्रिएज जल्दी शुरू हो जाती है।

17. डेटाबेस, APIs, और SFTP साइट्स जैसे टूल्स से कनेक्ट करने के लिए क्रेडेंशियल्स प्रबंधित करने हेतु Airflow क्या सुविधा देता है?

उत्तर: Airflow का एक बेहद उपयोगी टूल है “connections।” कनेक्शंस से DAG ऑथर होस्ट, यूज़रनेम, पासवर्ड आदि जैसी कनेक्शन जानकारी कोड में हार्डकोड किए बिना स्टोर और एक्सेस कर सकता है।

कनेक्शंस स्टोर करने के कुछ तरीके हैं; सबसे आम Airflow UI का उपयोग है। कनेक्शन बनने के बाद, इसे कोड में सीधे “hook” से एक्सेस किया जा सकता है। हालाँकि, अधिकांश पारंपरिक ऑपरेटर्स जो किसी स्रोत प्रणाली से इंटरैक्शन माँगते हैं, उनके पास conn_id (या मिलता-जुलता) फ़ील्ड होता है—जो एक स्ट्रिंग लेता है और मनचाहे स्रोत से कनेक्शन बनाता है।

Airflow कनेक्शंस संवेदनशील जानकारी को सुरक्षित रखने में मदद करते हैं और इस जानकारी का भंडारण व पुनर्प्राप्ति बेहद आसान बनाते हैं।

और बताइए: Airflow UI के अलावा, CLI से भी कनेक्शंस स्टोर और रिट्रीव किए जा सकते हैं। एंटरप्राइज सेटिंग में अक्सर कस्टम “secrets backend” से कनेक्शन जानकारी प्रबंधित की जाती है। Airflow कनेक्शंस प्रबंधन हेतु कई सपोर्टेड secrets backends देता है। उदाहरण के लिए, AWS उपयोग करने वाली कंपनी आसानी से Secrets Manager को Airflow से इंटीग्रेट कर सकती है। आवश्यकता पड़ने पर, कनेक्शंस प्रोजेक्ट के environment variables में भी परिभाषित किए जा सकते हैं।

18. आप किसी Airflow प्रोजेक्ट को प्रोडक्शन-ग्रेड वातावरण में चलाने हेतु कैसे डिप्लॉय करेंगे?

उत्तर: प्रोडक्शन-ग्रेड वातावरण के लिए Airflow डिप्लॉय करना कठिन हो सकता है। Azure और AWS जैसे क्लाउड टूल्स Airflow डिप्लॉय और मैनेज करने के लिए managed services देते हैं—पर इनके लिए क्लाउड अकाउंट चाहिए और ये महंगे भी हो सकते हैं।

एक सामान्य विकल्प Kubernetes का उपयोग कर प्रोडक्शन Airflow वातावरण डिप्लॉय और रन करना है। इससे अंतर्निहित संसाधनों पर पूरा नियंत्रण मिलता है—पर उस इन्फ्रास्ट्रक्चर को मैनेज करने की ज़िम्मेदारी भी आती है।

क्लाउड-नेटिव और होमग्रोन Kubernetes डिप्लॉयमेंट्स से परे, Astronomer इस स्पेस में Airflow का सबसे लोकप्रिय managed service प्रदाता है।

वे अपने “Astro” PaaS ऑफ़रिंग के अलावा, कई ओपन-सोर्स टूलिंग (CLI, SDK, ढेर सारा डॉक्यूमेंटेशन) देते हैं—जिससे Airflow डेवलपमेंट और डिप्लॉयमेंट यथासंभव स्मूद हो। Astro के साथ, संसाधन आवंटन, प्लेटफ़ॉर्म एक्सेस कंट्रोल और इन-प्लेस Airflow अपग्रेड्स नैटिवली सपोर्टेड हैं—जिससे फोकस पाइपलाइन डेवलपमेंट पर लौट आता है।

परिदृश्य-आधारित Airflow इंटरव्यू प्रश्न

यद्यपि परिदृश्य-आधारित प्रश्न अत्यधिक तकनीकी नहीं होते, वे Airflow इंटरव्यू के सबसे महत्वपूर्ण प्रश्नों में से हैं। विस्तृत और सोच-समझकर दिए उत्तर न केवल Airflow, बल्कि डेटा आर्किटेक्चर और डिजाइन सिद्धांतों की गहरी दक्षता दिखाते हैं।

19. आपकी टीम वर्तमान में एक लेगेसी डेटा पाइपलाइन सपोर्ट कर रही है जो होमग्रोन टूलिंग का उपयोग करती है। आपको इस पाइपलाइन को Airflow में माइग्रेट करने का काम सौंपा गया है। आप इसे कैसे एप्रोच करेंगे?

उत्तर: यह मज़ेदार है! ऐसे प्रश्न में संभावनाएँ अनंत हैं। सबसे महत्वपूर्ण बात—प्रक्रिया बताते समय, लेगेसी डेटा पाइपलाइन के उन टूल्स और प्रक्रियाओं को चुनें जिनसे आप परिचित हैं। इससे आपकी विशेषज्ञता दिखेगी और उत्तर अधिक सूचित होगा।

यह आपके प्रोजेक्ट मैनेजमेंट और लीडरशिप स्किल्स दिखाने का भी उत्तम अवसर है। बताएं कि आप प्रोजेक्ट कैसे संरचित करेंगे, स्टेकहोल्डर्स और अन्य इंजीनियर्स से कैसे इंटरैक्ट करेंगे, और प्रक्रियाओं को कैसे डॉक्यूमेंट/कम्यूनिकेट करेंगे। इससे मूल्य देने और टीम का काम आसान बनाने पर आपका फोकस झलकेगा।

यदि किसी कंपनी के स्टैक में कोई खास टूल है (मान लें Google BigQuery), तो यह बताना तार्किक है कि आप कैसे किसी प्रक्रिया को Postgres से हटाकर BigQuery पर ले जा सकते हैं। इससे केवल Airflow ही नहीं, बल्कि कंपनी के अन्य इंफ्रास्ट्रक्चर कंपोनेंट्स की आपकी जानकारी भी झलकती है।

20. एक ऐसा DAG डिज़ाइन कीजिए जो किसी API से डेटा खींचे और प्रतिक्रिया को फ्लैट-फाइल में सुरक्षित करे, फिर डेटा को क्लाउड डेटा वेयरहाउस में लोड करे और उसके बाद ट्रांसफॉर्म करे। किन महत्वपूर्ण बातों का ध्यान रखना चाहिए?

उत्तर: इस DAG को डिज़ाइन करने के लिए, पहले API को हिट कर डेटा निकालना होगा। यह PythonOperator और कस्टम-बिल्ट callable से किया जा सकता है। उसी callable में, डेटा को किसी क्लाउड स्टोरेज लोकेशन—जैसे AWS S3—में सुरक्षित भी करना होगा।

डेटा सुरक्षित होने के बाद, S3ToSnowflakeOperator जैसे प्रीबिल्ट ऑपरेटर से S3 से Snowflake डेटा वेयरहाउस में डेटा लोड किया जा सकता है। अंततः, इस डेटा को ट्रांसफॉर्म करने के लिए DbtCloudRunJobOperator द्वारा कोई DBT जॉब चलाया जा सकता है।

आपको इस DAG को मनचाहे इंटरवल पर शेड्यूल करना होगा और फेल्योर को शालीनता (पर दृश्यता) से संभालने के लिए कॉन्फ़िगर करना होगा। नीचे दिए डायग्राम पर नज़र डालें!

ध्यान रखें कि Airflow एक क्लाउड स्टोरेज फाइल सिस्टम और एक डेटा वेयरहाउस—दोनों से इंटरैक्ट कर रहा है। इस DAG के सफल निष्पादन हेतु ये संसाधन मौजूद होने चाहिए और कनेक्शंस परिभाषित व उपयोग किए जाने चाहिए। ऊपर के आर्किटेक्चर डायग्राम में प्रत्येक टास्क के नीचे दिए आइकॉन्स से इन्हें दर्शाया गया है।

और बताइए: ये कुछ सबसे आम Airflow इंटरव्यू प्रश्न हैं—जो सूक्ष्म तकनीकी विवरणों के बजाय उच्च-स्तरीय DAG डिज़ाइन और इम्प्लीमेंटेशन पर केंद्रित हैं। इन प्रश्नों में, कुछ बातें ध्यान रखें:

• DAG को स्पष्ट, अलग-अलग टास्क्स में बाँटें। इस केस में, इंटरव्यूअर तीन टास्क्स वाला DAG देखना चाहेगा।
• वे विशिष्ट टूल्स बताएं जिन्हें आप इस DAG के लिए उपयोग कर सकते हैं, पर बहुत विस्तार में न जाएँ। उदाहरण के लिए, यदि आप DbtCloudRunJobOperator का उपयोग करना चाहते हैं, इसका ज़िक्र करें—पर तब तक विस्तार न करें जब तक पूछा न जाए।
• कुछ संभावित अड़चनों या ध्यान देने योग्य बातों का ज़िक्र करें—यह दर्शाता है कि डेटा पाइपलाइंस बनाते समय आप edge और corner cases संभालने का अनुभव व जागरूकता रखते हैं।

21. पारंपरिक डेटा इंजीनियरिंग वर्कफ़्लोज़ के बाहर, Apache Airflow का उपयोग डेटा टीमें और किन तरीकों से कर रही हैं?

उत्तर: Airflow की एक्स्टेंसिबिलिटी और डेटा समुदाय में बढ़ती लोकप्रियता ने इसे सिर्फ डेटा इंजीनियर्स से परे भी पसंदीदा टूल बना दिया है। डेटा साइंटिस्ट्स और मशीन लर्निंग इंजीनियर्स Airflow का उपयोग अपने मॉडलों को ट्रेन (और री-ट्रेन) करने और संपूर्ण MLOps के लिए करते हैं। AI इंजीनियर्स भी अब अपने जनरेटिव AI मॉडलों को मैनेज और स्केल करने के लिए Airflow का उपयोग करने लगे हैं—OpenAI, OpenSearch और Pinecone जैसे टूल्स के नए इंटीग्रेशंस के साथ।

और बताइए: पारंपरिक डेटा इंजीनियरिंग पाइपलाइंस के बाहर फलना-फूलना शायद Airflow के शुरुआती निर्माताओं की कल्पना में नहीं था। पर Python और ओपन-सोर्स दर्शन का लाभ उठाकर, Airflow ने तेज़ी से विकसित हो रहे डेटा/AI स्पेस की ज़रूरतों को पूरा करने के लिए खुद को बढ़ाया है। जब प्रोग्राममैटिक टास्क्स को शेड्यूल और निष्पादित करना हो, तो Airflow शायद काम के लिए सबसे अच्छा टूल है!

निष्कर्ष

शानदार काम! आपने मुश्किल चरण पार कर लिया। ऊपर दिए प्रश्न कठिन हैं, पर Airflow-केंद्रित तकनीकी इंटरव्यू में पूछे जाने वाले अधिकतर विषयों को समेटते हैं।

उपरोक्त प्रश्नों को दोहराने के अलावा, Airflow इंटरव्यू की तैयारी का एक श्रेष्ठ तरीका है—Airflow का उपयोग कर अपनी खुद की डेटा पाइपलाइंस बनाना।

कोई ऐसा डेटासेट खोजें जो आपको रुचिकर लगे, और अपनी ETL (या ELT) पाइपलाइन शून्य से बनाना शुरू करें। TaskFlow API और पारंपरिक ऑपरेटर्स—दोनों का अभ्यास करें। संवेदनशील जानकारी को Airflow connections से स्टोर करें। callbacks का उपयोग कर फेल्योर पर रिपोर्टिंग आज़माएँ, और अपने DAG को यूनिट टेस्ट्स और एंड-टू-एंड टेस्टिंग से परखें। सबसे महत्वपूर्ण—जो काम आपने किया, उसे डॉक्यूमेंट करें और साझा करें।

ऐसा प्रोजेक्ट न केवल Airflow में दक्षता दिखाता है, बल्कि सीखने और विकसित होने के प्रति आपका उत्साह भी। यदि आपको अभी भी बेसिक सिद्धांतों पर एक प्राइमर चाहिए, तो हमारा Introduction to Airflow in Python कोर्स, हमारा Airflow बनाम Prefect तुलना, और हमारा Getting Started with Apache Airflow ट्यूटोरियल देखें।

शुभकामनाएँ, और हैप्पी कोडिंग!