डेटा मोनोलिथ को कैसे तोड़ना है, इसके बारे में एक पूर्ण मार्गदर्शिका।

सॉफ्टवेयर की दुनिया में नए बड़े लक्ष्य से कैसे निपटा जाए।

डेटा मोनोलिथ तोड़ो!

प्रेरणा

डेटा मोनोलिथ

मानव एकमात्र ऐसा जानवर है जो एक ही चट्टान पर दो बार यात्रा करता है। सेवाओं में मोनोलिथ को तोड़ने की बात करने के वर्षों के बाद, हमने फिर से वही काम किया है: डेटा मोनोलिथ (उर्फ डेटा झीलों और डेटा वेयरहाउस)।

मैं पिछले सालों से कई परियोजनाओं (विभिन्न कंपनियों में) पर काम कर रहा हूं और मैंने देखा है कि डेटा मोनोलिथ की समस्याएँ इस प्रकार हैं:

  • परिवर्तनों के कारण डेटा में त्रुटियां कोड और डेटा पाइपलाइनों के बीच समन्वयित नहीं होती हैं।
  • आमतौर पर, मोनोलिथ सूचना सिलोस बनाता है क्योंकि हमें डेटा और मशीन सीखने में कोड विशेषज्ञों और विशेष टीमों की आवश्यकता होती है।
  • जैसे-जैसे कंपनियां बढ़ती हैं, हमारे पास डेटा के अधिक स्रोत होते हैं, और यह एक ऐसी चीज है जो केवल बढ़ती है, जो डेटा को एक जगह पर एक कठिन चुनौती बनाती है।
  • आमतौर पर डेटा पाइपलाइनों में काम करने वाले लोगों के लिए डेटा के अर्थ को ठीक से समझना मुश्किल है (कम से कम उन लोगों से बेहतर नहीं है जो इसे पैदा करते हैं) क्योंकि उनके पास कम संदर्भ है।
  • ईटीएल प्रक्रियाओं में गलतफहमी और असंगत डेटा को ठीक करने के लिए डेटा वेयरहाउस में बल्क अपडेट करने के लिए कभी-कभी आवश्यकता होती है।
  • एक नए विचार और जब यह विचार उत्पादन में है, के बीच अंतर को कम करना मुश्किल है। इसलिए हम कुछ नया नहीं कर सकते। यदि आप धीमे हैं, तो आपके पास एक तेज़ परीक्षा नहीं हो सकती है और चक्र सीख सकते हैं और इसके बिना, आप कुछ नया नहीं कर सकते।

इसके अलावा, डेटा मोनोलिथ, वास्तव में, एक मोनोलिथ है, और हम बहुत सारी बुरी चीजों (और कुछ अच्छे) को समझते हैं; इसलिए हमें यह समझाने की आवश्यकता नहीं है कि यह सामान (युग्मित सेवाएं, नई सुविधाओं को जारी करने में समस्याएं, निरंतर तैनाती, गड़बड़ परीक्षण रणनीति, आदि…) में कोई समस्या हो सकती है।

इसे करने का सामान्य तरीका

वास्तविक तरीका हमारी सेवाओं में ध्यान केंद्रित करना है और फिर, एक ईटीएल द्वारा डेटा को उन सेवाओं / स्रोतों का उत्पादन किया जाता है और कुछ परिवर्तनों के बाद डेटा को एक ऐसी जगह पर रख दिया जाता है, जहाँ बाद में इसका उपयोग किया जाएगा / सेवा (डेटा मौसा, एपीआई,) BigQuery, मॉडल पाइपलाइन, आदि)। ये प्रक्रियाएँ डेटा पाइपलाइनों के अंदर की जाती हैं और जैसा कि हमने कहा कि इससे पहले कि हम तीन स्पष्ट भागों (ETL) में अंतर कर सकें:

  • सबसे पहले, एक प्रक्रिया जो विभिन्न स्रोतों से डेटा को निगला करती है।
  • एक प्रसंस्करण हिस्सा जहां हम डेटा को साफ करते हैं और डेटा पाइपलाइनों के साथ कुछ परिवर्तन करते हैं।
  • डेटा का चरणवार कार्य विफल हो गया। हमारे मामले में, BigQuery डेटा की इस सेवा को बनाता है।
डेटा मोनोलिथ पैटर्न

मोनोलिथ को कैसे तोड़ना है

इस डिकम्पलिंग का विचार इस पाइपलाइन को कुछ पाइपलाइनों में, डोमेन या कुएं द्वारा, उसी तरह से सेवाओं द्वारा तोड़ना है जिस तरह से हम कोड सेवाओं के साथ करते हैं।

तो, क्या होगा अगर, केवल एक पाइपलाइन होने के बजाय, प्रत्येक सेवा का अपना (या अधिक) ऐसा था जो अपने डेटा को संसाधित करेगा? इसलिए, प्रत्येक सेवा को उत्पादों के रूप में अपरिवर्तनीय डेटासेट में अपने स्वयं के डेटा को साफ करने, बदलने और साझा करने के लिए जिम्मेदार होना चाहिए।

इस बदलाव से हम क्या जीत सकते हैं? सबसे पहले, हमें यह नहीं भूलना चाहिए कि विभिन्न सेवाओं में बहुत सारे बदलाव हैं। यहां तब है जब समस्याएं शुरू होती हैं, या हम परिवर्तनों के बारे में डेटा लोगों के साथ समन्वय करना भूल जाते हैं या इस समय यह समन्वय संभव नहीं है। वास्तव में, ऐसा लगता है कि एनालिटिक्स को नहीं तोड़ने या डेटा में अन्य सेवाओं की जिम्मेदारी टीम की सेवाओं को बदल रही है, है ना? इसके अलावा, इस टीम से बेहतर कौन जानता है कि डेटा कैसे हैं और इसका प्रारूप क्या है?

इसलिए, सारांश में, प्रत्येक डोमेन अपना डेटा तैयार करता है, इसे एक उत्पाद के रूप में मैसेजिंग ब्रोकर में डालता है जहां से अन्य सेवाओं, स्ट्रीमिंग टूल, गवर्नेंस, एनालिटिक्स, डेटा साइंटिस्ट टूल्स (ज्यूपिटर नोटबुक के रूप में), मशीन लर्निंग पाइपलाइन, एक वैश्विक भंडारण और बहुत कुछ अधिक, उन्हें प्राप्त कर सकते हैं।

डेटा वितरित रणनीति

इसके अलावा, मुझे यकीन है कि यदि आप अब मशीन सीखने के साथ कुछ नहीं कर रहे हैं, तो आप करेंगे। तो, इसके बारे में सोचें, क्या अच्छे डेटा के बिना एक अच्छा मॉडल बनाना संभव है? यदि आप ML में एक अच्छा काम करना चाहते हैं, तो आपको संभवतः एक मॉडल पाइपलाइन की आवश्यकता है, वह भी डोमेन द्वारा, और उसे इस डेटा पाइपलाइन की आवश्यकता होगी। यदि आप इस विषय के बारे में अधिक जानकारी चाहते हैं, तो आप मेरे द्वारा लिखी गई एक और पोस्ट पढ़ सकते हैं: मशीन लर्निंग सिस्टम में निरंतर तैनाती।

एक मंच के रूप में डेटा अवसंरचना

इसलिए, हम डेटा मोनोलिथ को तोड़ने जा रहे हैं और हम इसे डोमेन द्वारा जा रहे हैं, लेकिन वास्तव में, टीमों के पास अपना स्वयं का डेटा इन्फ्रास्ट्रक्चर बनाने के लिए समय नहीं है। इस समस्या को हल करने के लिए, कंपनियों को एक सामान्य डेटा इन्फ्रास्ट्रक्चर बनाने पर ध्यान केंद्रित करना होगा।

मार्टिन फाउलर के ब्लॉग (थॉटवर्क्स ज़माह देहगानी में मेरे पूर्व साथी द्वारा लिखे गए) के डेटा मेष लेख में उन्होंने लिखा है कि इस बुनियादी ढांचे में कुछ क्षमताएं होनी चाहिए, उनमें से कुछ: स्केलेबल पॉलीग्लॉट डिजी डेटा स्टोरेज, डेटा वर्जनिंग, डेटा वर्सा, डेटा वंश, डेटा मॉनिटरिंग / चेतावनी / लॉग, डेटा उत्पाद गुणवत्ता मैट्रिक्स, डेटा शासन, सुरक्षा और गणना और डेटा स्थानीयता।

इस डेटा प्लेटफ़ॉर्म के साथ, टीमों (डेवलपर्स और डेटा साइंटिस्ट) को केवल इस बात का ध्यान रखना होगा कि वे उन डेटा के साथ क्या करना चाहते हैं जो वे पैदा करते हैं और वे इस डेटा को अन्य टीमों को कैसे परोसने जा रहे हैं, जैसे अब हम CircleCi के साथ कर रहे हैं या जेनकिंस (टीमों को केवल यह सोचने की ज़रूरत है कि वे अपना सीआई कैसे बनाना चाहते हैं, बुनियादी ढांचा नहीं)। उदाहरण के लिए, इस छवि में, मेटाफ़्लो डेटा वैज्ञानिकों के दृष्टिकोण से बुनियादी ढांचे की व्याख्या करता है:

मेटाफ़्लो से छवि

और अगली छवि (मार्टिन फावलर के ब्लॉग के डेटा जाल पोस्ट से) एक संभावित अंतिम स्थिति हो सकती है। इस स्कीमा में, आप अलग-अलग डोमेन को अपनी पाइपलाइन और ट्रांसवर्सल डेटा प्लेटफ़ॉर्म के साथ देख सकते हैं।

मार्टिन फाउलर के ब्लॉग से डेटा मेष स्कीमा

ठीक है, ठीक है ठीक है ... मैं अवधारणा और बाकी सब कुछ समझता हूं, लेकिन ... इसे प्राप्त करने की रणनीति के बारे में क्या?

ठीक है, सबसे पहले, हम कोड से प्यार करते हैं, और सालों से हम कोड में सर्वोत्तम प्रथाओं और सर्वोत्तम तरीकों और सभी तकनीकों में सुधार कर रहे हैं जिनमें XP शामिल हैं। तो, चलिए डेटा में कोड और उन सभी सर्वोत्तम प्रथाओं का भी उपयोग करते हैं जिन्हें हम जानते हैं।

हम कोड के साथ अपने डेटा पाइपलाइन बनाने के लिए बहुत सारे टूल और फ्रेमवर्क का उपयोग कर सकते हैं। पैकलिंक की इंजीनियरिंग टीम में, हम GCP से प्यार करते हैं इसलिए इस पोस्ट में मैं Airflow के साथ इस सामान की व्याख्या करने जा रहा हूं क्योंकि Google प्लेटफ़ॉर्म में एक क्लिक और प्ले है और Airflow में निर्मित पूरी तरह से प्रबंधित वर्कफ़्लो ऑर्केस्ट्रेशन: क्लाउड कंपोज़र।

याद रखें कि महत्वपूर्ण बिंदु (सेवाओं में समान हैं यदि आप सर्किलसीई, जेनकिंस, आदि का उपयोग करते हैं) विचार हैं, तो उपकरण केवल हमारे उद्देश्यों को प्राप्त करने का एक तरीका है। अन्य अच्छे उपकरण / रूपरेखा मेटाफ्लो, लुइगी, प्रीफेक्ट, पिनबॉल हैं। इस समय प्रत्येक कंपनी अपने स्वयं के ढांचे का निर्माण कर रही है और उन सभी को अलग-अलग लेकिन, जोर देकर कह रही है, यह विचार ही विचार है और उनमें से प्रत्येक कोड है। अगले भाग में मैं जा रहा हूँ:

  • स्ट्रेंगलर पैटर्न: इसे प्राप्त करने की रणनीति के रूप में।
  • डेटा पाइपलाइन: यह पाइपलाइन कैसी होनी चाहिए?
  • कोड: पाइपलाइन लिखने के लिए परीक्षण किया गया कोड।

स्ट्रेंगलर पैटर्न

मैं मान रहा हूं कि अभी आपके पास एक डेटा मोनोलिथ है। यदि नहीं, तो यदि आपके पास एक ग्रीनफ़ील्ड है, तो शायद यह अध्याय आपके लिए दिलचस्प नहीं है, लेकिन क्षमा करें, हम अखंड तोड़ने के बारे में बात कर रहे हैं।

हमारे पास डेटा मोनोलिथ है, जो सबसे अच्छी रणनीति है? ऐसा नहीं लगता है कि एक झरना बनाते हैं और एक ही बार में पूरे बुनियादी ढांचे को डालते हैं, इसलिए यह एक अच्छा विचार है कि अपने उद्देश्य को प्राप्त करने के लिए हम स्ट्रैंग्लर पैटर्न का उपयोग करने जा रहे हैं। यह विरासत प्रणालियों में मोनोलिथ को तोड़ने का एक विशिष्ट तरीका है, और जैसा कि मैंने पहले कहा था, हमने बहुत कुछ सीखा है और हम इस ज्ञान का पुन: उपयोग करना चाहते हैं।

यह पैटर्न उपयोग करने के लिए अच्छा है क्योंकि; हमारे पास बहुत सी चीजें चल रही हैं और हम इस काम को इन तीन चरणों में एक उपयोगी और चुस्त मानसिकता में करना चाहते हैं:

  • एक नई पाइपलाइन में इसे बनाने वाले मोनोलिथ से एक डोमेन निकालें।
  • उत्पादन में लगाइए और जांचिए कि सब कुछ ठीक चल रहा है जबकि दोनों तरीके सह-जीवित हैं।
  • इस बस विरासत भाग को मोनोलिथ से हटा दें।
एक्शन में स्ट्रेंगलर पैटर्न

तो, शुरू करने के लिए, हम सबसे सरल डोमेन चुन सकते हैं, और एक नई डेटा पाइपलाइन का निर्माण कर सकते हैं, फिर एक आलसी माइग्रेशन को सह-जीवित दोनों सिस्टम बना सकते हैं और जब हम सुरक्षित होते हैं कि सब कुछ अच्छी तरह से चल रहा है, तो विरासत वाले हिस्से को हटा दें।

डेटा पाइपलाइन

इस पाइपलाइन के मुख्य बिंदु निम्न हैं:

  • डेटा की तकरार। सेवाओं द्वारा उत्पादित सभी डेटा साझा नहीं किए जाते हैं और न ही उत्पादित किए गए सभी डेटा कच्चे किए जाते हैं। कभी-कभी हमें कुछ परिवर्तन करने की आवश्यकता होती है। हम कोड के साथ करेंगे और जैसा कि मैं हमेशा कहता हूं, कोड कोड है इसलिए हमें हमेशा सर्वोत्तम प्रथाओं को लागू करने की आवश्यकता है।
  • स्कीमा जाँच। यदि हम अपने डेटा की गुणवत्ता सुनिश्चित करना चाहते हैं, तो हमें एक स्कीमा का उपयोग करने की आवश्यकता है जब हम इसे कंपनी के अन्य हिस्सों (सेवाओं, विश्लेषिकी आदि) के साथ साझा कर रहे हैं। उदाहरण के लिए, हमारे पास उन लोगों की आयु है जिन्हें हम यह सुनिश्चित करना चाहते हैं कि यह मान एक पूर्णांक है और अधिकतम मान है ... 150? 150 इसे प्राप्त करने के लिए आप विभिन्न डेटा क्रमांकन प्रणालियों का उपयोग कर सकते हैं, मैं प्रोटोकॉल बफ़र्स या एवरो की सलाह देता हूं। इसके साथ, निर्माता और उपभोक्ता दोनों जानते हैं कि प्रत्येक डेटा बिंदु का क्या मतलब है।
  • उत्पादों के रूप में अपरिवर्तनीय डेटासेट का निर्यात। प्रत्येक सेवा संगठन के साथ सूचना साझा करने के लिए जिम्मेदार है। इष्टतम एक काफ़्का या पब / उप जैसे मैसेजिंग ब्रोकर के माध्यम से अपरिवर्तनीय डेटासेट साझा करना है। वितरित सिस्टम में शेयर डेटा के बारे में बात करने वाली एक अच्छी पोस्ट यहां पढ़ी जा सकती है। कृपया इस पर ध्यान दें: डेटा, जैसा कि हमने कार्यात्मक प्रोग्रामिंग में भी सीखा है, अपरिवर्तनीय होना चाहिए और साथ ही यह हमें संपूर्ण इतिहास रखने और बाद में उन्हें सहेजे बिना एकत्रीकरण करने की अनुमति देता है।
  • कोड के रूप में डेटा संस्करण / डेटा। जैसा कि हमने कोड में बनाया है, हमें अपने डेटासेट को संस्करणबद्ध करने की आवश्यकता है, इससे भी अधिक, हम कोड के रूप में डेटा चाहते हैं। इसके कुछ लाभ हैं: हम आसानी से त्रुटियों को पुन: उत्पन्न कर सकते हैं, हमारे परीक्षणों और हमारे पाइपलाइनों में डेटासेट का उपयोग कर सकते हैं, मशीन सीखने में बहुत अधिक लाभ (यहां अधिक जानकारी) और निश्चित रूप से सभी अच्छी चीजों में कोड है। DVC, एक डेटा और मॉडल संस्करण नियंत्रण प्रणाली, जो कि git पर आधारित है, मेरे लिए, समाधान है, जो डेटा जगत के सर्वश्रेष्ठ उपकरणों में से एक है।
DVC कोड और शेयरिंग डेटा के रूप में डेटा और मॉडल के बारे में आरेख
  • डेटा शासन और वंश। यह डेटा पाइपलाइन में मेरे लिए सबसे महत्वपूर्ण बिंदुओं में से एक है अगर हम डेटा मोनोलिथ को तोड़ना चाहते हैं। सबसे पहले, हमें डेटा प्लेटफ़ॉर्म में इसे बचाने के लिए एक उपकरण की आवश्यकता है। कुछ अच्छे विकल्प हैं, लेकिन मैं केवल दो की सिफारिश करने जा रहा हूं: Lyft Ammundsen और यदि आप GCP, डेटा कैटलॉग का उपयोग करते हैं। इन दोनों में डेटा की ऑटो-खोज है। यहाँ महत्वपूर्ण उपकरण नहीं है, यह अवधारणा भी है। हमें अपनी पाइपलाइनों में हमारे द्वारा साझा किए जा रहे डेटा और मेटाडेटा को एपीआई के माध्यम से हमारे टूल में सेव करना होगा, जैसे कि यह डेटा कैटलॉग में लाइब्रेरी करता है और डेटा का सही वंशज होना आवश्यक है। इसके लिए धन्यवाद कि हर कोई जानता है कि डेटा कहां है, मालिक कौन है, यह कैसे है और प्रत्येक मूल्य का क्या अर्थ है।
Lyft Ammundsen के साथ डेटा शासन
  • Observability। हमें यह समझने की आवश्यकता है कि हमारा सिस्टम कैसे काम कर रहा है, और हम इसे तीन प्रकार के स्तरों से ऊपर काम करने जा रहे हैं: इन्फ्रास्ट्रक्चर स्तर, जॉब स्तर की घटनाएं और डेटा स्तर। स्पष्ट और उपयोगी जानकारी के साथ एक डैशबोर्ड बनाएं। यह मुख्य बिंदु है। हम जटिल सिस्टम कर रहे हैं इसलिए हमें आसानी से समझने के लिए सबसे महत्वपूर्ण जानकारी के साथ एक डैशबोर्ड होना चाहिए अगर हमारे सिस्टम ठीक से चल रहे हैं। इसके साथ, जब जहाज होता है, और यह होगा, तो आप इसे खोजने वाले पहले व्यक्ति होंगे। डेटा में एक विशिष्ट त्रुटि मूक विफलताओं को भूलना है। यदि कोई स्रोत नए डेटा का उत्पादन करना बंद कर देता है, तो हमें इसके बारे में जल्दी पता होना चाहिए क्योंकि शायद हमारे मॉडल, अन्य सेवाएं या व्यवसाय, इस डेटा पर उच्च प्रतिशत में निर्भर हैं। इसके अलावा, एक अच्छी डेटा पाइपलाइन के लिए धन्यवाद, हम विफलताओं का एक स्वचालित विसंगति का पता लगा सकते हैं, उदाहरण के लिए, जब समय की अवधि में कम घटनाएं होती हैं।
  • आँकड़े की गुणवत्ता। परीक्षण, परीक्षण और अधिक परीक्षण। हम परीक्षण करते हैं। और कोड में परीक्षणों के अलावा, हमें डेटा के साथ कुछ परीक्षणों की आवश्यकता है। उदाहरण के लिए, आप इस पाइपलाइन में एक परीक्षण के बारे में क्या सोचते हैं जो हमें सलाह देता है कि क्या हम उत्पादों की तुलना में अधिक ऑर्डर दे रहे हैं? यह तर्कसंगत और उपयोगी लगता है, है ना?
  • डेटा प्रशिक्षण प्राप्त करें। यदि आप मशीन लर्निंग के साथ भी काम कर रहे हैं और क्योंकि हम अपने डेटा वैज्ञानिकों का जीवन बनाना चाहते हैं, तो आपको प्रशिक्षण डेटा प्राप्त करने की आवश्यकता है। यहां बहुत सारे महत्वपूर्ण बिंदु हैं: महत्व-वजन का नमूना, डेटा को छोटे स्लाइस में काटें, सभी संवेदनशील डेटा को अनामांकित करें ... यहां अधिक जानकारी प्राप्त करें।
  • हम अपने ग्राहकों का ध्यान रखते हैं, इसलिए हमें उनके डेटा का ध्यान रखना होगा, इसलिए हमें इस डेटा भाग में बहुत अधिक सुरक्षा की आवश्यकता है। यदि हम उनके साथ काम करना चाहते हैं तो सभी संवेदनशील डेटा को गुप्त रखना महत्वपूर्ण है।

हाँ जुआन बहुत सुंदर है, लेकिन ...

बचाव के लिए चरम प्रोग्रामिंग

सबसे पहले, हम सब कुछ कोड के रूप में ट्रेंड करना जारी रखते हैं, इसलिए डेटा पाइपलाइन भी।

स्ट्रगलर दृष्टिकोण के साथ, और पहले पुनरावृत्ति में, तार्किक तर्क का हिस्सा है जिसे हमने पहले किया है, और हम इसे TDD के साथ करने जा रहे हैं, जैसा कि XP ​​और हमारे सामान्य ज्ञान कहते हैं।

यदि आप इस बारे में सोच रहे हैं कि मैं इसे सरल तरीके से कैसे प्राप्त करने के लिए एक सरल विधि की व्याख्या करने जा रहा हूं। इसके अलावा, आपको लंबी अवधि में अपनी रणनीति तय करनी चाहिए।

यदि आप एयरफ्लो जानते हैं तो आप जानते हैं कि प्रत्येक DAG में आप जिस तरह का कोड डालना चाहते हैं, उसके आधार पर कई ऑपरेटर (python_operator, http_operator, bash_operator, mysql_operator और एक लंबा वगैरह) हैं। इन ऑपरेटरों को कुछ समस्याएं हैं। मेरे लिए बदतर परीक्षण का जटिल और बदसूरत तरीका है, इसके अलावा, यदि आप पायथन का उपयोग कर रहे हैं, तो आपने निर्भरता गड़बड़ के बारे में कुछ सुना होगा। इन ऑपरेटरों के साथ आपको सभी परियोजना में सभी निर्भरताएं स्थापित करने की आवश्यकता होती है, उन्हें एक अलग संस्करण की आवश्यकता नहीं होती है और वे पायथन के एक ही संस्करण का उपयोग करते हैं। इसके अलावा, हम एक आधुनिक कंपनी हैं और हम एक बहुभाषाविद प्रणाली चाहते हैं और नई भाषाओं को आजमाना चाहते हैं!

मेरा समाधान उपयोग करना है, जबकि हम स्ट्रगलर पैटर्न, डॉक ऑपरेटर, कुबेरनेत्स_पोड_परेटर कर रहे हैं। यदि आप Google संगीतकार का उपयोग करते हैं, तो आपको Kubernetes का उपयोग करना चाहिए और कभी भी GKEContainerOperator का उपयोग नहीं करना चाहिए क्योंकि इससे संसाधन प्रतियोगिता हो सकती है। इन ऑपरेटरों के साथ, प्रत्येक डीएजी में निष्पादित कोड एक कंटेनर में होगा (इसमें अजगर कोड, स्काला, जावा, बीम प्रक्रियाएं, स्पार्क प्रक्रियाएं, काफ्का धाराएं, संक्षेप, जो कुछ भी आप कल्पना कर सकते हैं ...) हो सकते हैं, ताकि आप कर सकें अपने टीडीडी का उपयोग उस भाषा में करें, जिसे आप चाहते हैं और आप अपने कुछ विरासत कोड का पुन: उपयोग कर सकते हैं। यूनिट परीक्षण और एकीकरण परीक्षण किया जाता है ... लगभग!

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

इसलिए, जैसे हम TDD करते हैं, पहले इकाई परीक्षण:

यह पाइपलाइन का उत्पादन कोड है जो हमने टीडीडी के साथ उत्पन्न किया है:

लेकिन यूनिट परीक्षण पर्याप्त नहीं है, पैकलिंक इंजीनियरिंग में पता है कि परीक्षण कोड का सबसे महत्वपूर्ण हिस्सा हैं। तो, चलो अधिक परीक्षण के साथ चलते हैं।

अब एयरफ्लो भाग में एकीकरण परीक्षणों का समय है (कंटेनरों की अपनी इकाई और एकीकरण परीक्षण हैं)। इस दृष्टिकोण के साथ, यहाँ एकीकरण परीक्षण Airflow config और XComs से संबंधित हैं जो सारांश में airflow में जिस तरह से हम एक DAG में कार्यों के बीच जानकारी साझा करना है। हमारे उदाहरण में, हमें यह जांचने की आवश्यकता है कि packlink_hello_task में सहेजी गई जानकारी stream_data_task द्वारा ली गई है:

पिरामिड परीक्षण का अंतिम भाग ई 2 ई परीक्षण है। पिरामिड में, e2e परीक्षण हमेशा छोटे पक्ष पर होते हैं क्योंकि वे बहुत महंगे होते हैं। Airflow में शायद और भी। आप यहाँ एक अच्छा उदाहरण देख सकते हैं: https://github.com/chandulal/airflow-testing। मैं इसे बेहतर नहीं कर सकता था।

निष्कर्ष

यह मुझे पोस्ट के अंत में लाता है। मैं यहाँ पोस्ट के सारांश के लिए कुछ निष्कर्ष रखना चाहता था:

  • कोड कोड है। XP प्रथाओं का उपयोग करें।
  • कोड मोनोलिथ के रूप में डेटा मोनोलिथ में समान समस्याएं हैं।
  • उत्पादों के रूप में अपरिवर्तनीय डेटासेट साझा करें।
  • अपनी तिथि को जानें, डेटा गवर्नेंस में प्रेम रखें। कंपनी में हर किसी को डेटा को समझने में सक्षम होना चाहिए।
  • शिट होता है। अवलोकन में ध्यान दें।
  • उनके डेटा के बारे में डोमेन से बेहतर कोई नहीं जानता। डेटा के लिए एक DDD दृष्टि लागू करें।
  • पैकलिंक नियम !.

संसाधन और लिंक