डेटा पाइपलाइन क्या है?

Scrapeless Scraping Browser वेब डेटा को पाइपलाइनों तक पहुंचाने के लिए ब्राउज़र-रेटर्ड सार्वजनिक वेब डेटा प्रदान करता है जिन्हें इनपुट स्रोत के रूप में गतिशील पृष्ठों की आवश्यकता होती है।

एक डेटा पाइपलाइन जुड़े हुए प्रोसेसेस का एक सेट है जो डेटा को एक या एक से अधिक स्रोतों से एक या एक से अधिक गंतव्यों तक ले जाता है। केवल गति ही कभी-कभी पर्याप्त नहीं होती। अधिकांश पाइपलाइन डेटा को मान्य, फ़िल्टर, सामान्य, समृद्ध, समेकित, जोड़ा, या रूट करती हैं ताकि एक एप्लिकेशन, गोदाम, मॉडल, खोज अनुक्रमणिका, या परिचालन सेवा एक विश्वसनीय उत्पाद प्राप्त करे न कि एक अनिर्वाचनित डंप।

IBM का डेटा-पाइपलाइन अवलोकन विवरण देता है कि कैसे डेटा का सेवन, रूपांतरण, और विश्लेषण या संचालन के लिए उपयोग किए जाने वाले गंतव्यों में लोड किया जाता है। उपयोगी इंजीनियरिंग सीमा अधिक व्यापक है: एक उत्पादन पाइपलाइन यह भी घोषित करती है कि यह कब चलती है, यह नए इनपुट का पता कैसे लगाती है, गलत रिकॉर्ड के साथ क्या होता है, आउटपुट का स्वामी कौन है, और ऑपरेटर कैसे जानते हैं कि परिणाम पूर्ण है।

डेटा पाइपलाइन आर्किटेक्चर

एक पाइपलाइन स्रोतों के साथ शुरू होती है। ये लेनदेन डेटाबेस, ऑब्जेक्ट स्टोरेज, इवेंट स्ट्रीम, SaaS एक्सपोर्ट, डिवाइस टेलीमेट्री, एप्लिकेशन लॉग, पार्टनर फीड, या सार्वजनिक वेब पृष्ठ हो सकते हैं। इनजेशन लेयर परिवर्तनों या स्नैपशॉट्स को पढ़ती है और उन्हें एक नियंत्रित प्रोसेसिंग सीमा में स्थानांतरित करती है। अच्छी इनजेशन स्रोत पहचानकर्ताओं और कैप्चर संदर्भ को संरक्षित करती है इससे पहले कि बाद के चरण डेटा को फिर से आकार दें।

प्रोसेसिंग उन नियमों को लागू करता है जो डेटा को उपयोगी बनाते हैं। एक काम प्रकारों को परिवर्तित कर सकता है, एकक को मानकीकृत कर सकता है, अमान्य पंक्तियों को हटा सकता है, पाठ को टोकनाइज़ कर सकता है, संस्थाओं को हल कर सकता है, मैट्रिक्स की गणना कर सकता है, या रिकॉर्ड्स को जोड़ सकता है। स्टोरेज फिर कच्चे, मध्यवर्ती, या क्यूरेटेड आउटपुट को उन प्रणालियों में रखता है जो पहुँच पैटर्न के लिए चुनी जाती हैं। ऑर्केस्ट्रेशन निर्भरताओं, कार्यक्रमों और पैरामीटर्स का समन्वय करता है; अवलोकन यह मापता है कि क्या प्रत्येक दौड़ ने अपने अनुबंध को पूरा किया।

बैच और स्ट्रीमिंग पाइपलाइन

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

एक स्ट्रीमिंग पाइपलाइन एक चल रहे घटनाओं के अनुक्रम को संभालती है। इसे घटना समय, अनुक्रम में आने में देरी, डुप्लिकेट्स, स्थिति, विंडो और चेकपॉइंट्स के लिए नियमों की आवश्यकता होती है। "वास्तविक समय" एक ही आर्किटेक्चर नहीं है; यह एक लेटेंसी आवश्यकतа है जिसे प्रणाली के मालिक द्वारा संख्यात्मक रूप से stated किया जाना चाहिए। कुछ मिनटों का माइक्रो-बैच निरंतर प्रसंस्करण से सरल और कम महंगा हो सकता है, फिर भी यह व्यावसायिक आवश्यकता को पूरा करता है।

एपाचे काफ्का स्ट्रीम दस्तावेज़ दूसरे की धारणा को प्रदर्शित करता है स्थायी स्ट्रीम प्रोसेसिंग, समय, और दोष-सहिष्णु राज्य भंडार। ये समस्याएँ तब उठती हैं जब परिणामों का निर्भरता घटना क्रम या रोलिंग राज्य पर होता है, चाहे वह किसी विशेष स्ट्रीमिंग इंजन पर हो।

ETL, ELT, और पाइपलाइन सीमा

ETL डेटा को निकालता है, इसे एक प्रसंस्करण प्रणाली में रूपांतरित करता है, और फिर प्रशासित परिणाम को लोड करता है। ELT पहले डेटा को निकालता और लोड करता है, फिर इसे गंतव्य प्लेटफ़ॉर्म में रूपांतरित करता है। दोनों पाइपलाइन पैटर्न हैं, लेकिन न तो शब्द खोज, अनुमतियों, अनुसूचियों, वंशावली, गुणवत्ता चेतावनियों, सेवा इंटरफेस या पूर्ण संचालन जीवनचक्र का वर्णन करते हैं।

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

डेटा अनुबंध और स्कीमा परिवर्तन

एक डेटा अनुबंध यह बताता है कि एक उत्पादक क्या वादा करता है और एक उपभोक्ता किस पर भरोसा कर सकता है। यह फ़ील्ड नाम, प्रकार, नलता, पहचानकर्ता, अपडेट معنا, ताजगी, अनुमत मान, और निरसन नियमों को कवर कर सकता है। अनुबंध के बिना, एक निर्दोष दिखने वाले स्रोत परिवर्तन चुपचाप डाउनस्ट्रीम मेट्रिक्स को भ्रष्ट कर सकता है या पाइपलाइन के सफल रिपोर्ट करने के बाद एक मॉडल को तोड़ सकता है।

स्कीमा ड्रिफ्ट को एक प्रेक्षणीय निर्णय उत्पन्न करना चाहिए। संगत जोड़ियों को स्वीकार किया जा सकता है और रिकॉर्ड किया जा सकता है। प्रकार परिवर्तन, गायब पहचानकर्ता, या अर्थ परिवर्तन को संगरोध की आवश्यकता हो सकती है। पाइपलाइन को हर आश्चर्यजनक मान को जब तक नौकरी हरी नहीं होती, तब तक मजबूर नहीं करना चाहिए; मौन मजबूरी घटना को एक डैशबोर्ड में ले जाती है जहां इसे ट्रेस करना कठिन हो जाता है।

आयोजन, वंशावली, और अवलोकनशीलता

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

द OpenLineage ऑब्जेक्ट मॉडल कार्य, रन और डेटासेट अवधारणाओं को रिकॉर्डिंग वंशावली घटनाओं के लिए परिभाषित करता है। एक व्यावहारिक कार्यान्वयन को उन रिकॉर्डों को स्वामित्व, अलर्ट, कोड संस्करणों और डेटा-गुणवत्ता परिणामों से कनेक्ट करना चाहिए। ऑपरेटरों को एक नाकाम डैशबोर्ड टाइल से वापस जिम्मेदार रन और इनपुट पर बिना मैनुअल अधिचारी के जाने की आवश्यकता है।

वेब निष्कर्षण कहाँ फिट बैठता है

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

गतिशील पृष्ठ एक रेंडरिंग सीमा जोड़ते हैं। पाइपलाइन को यह रिकॉर्ड करना चाहिए कि क्या इसने प्रारंभिक HTML, एक रेंडर किए गए DOM, एक नेटवर्क प्रतिक्रिया, या एक दृश्य परिणाम कैप्चर किया। एक चयनकर्ता परिवर्तन और एक वास्तविक व्यापार-डेटा परिवर्तन अलग-अलग घटनाएँ हैं। कच्चे अधिग्रहण आर्टिफैक्ट और पार्सर संस्करण को बनाए रखना टीम को उन्हें भेद करने की अनुमति देता है।

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

महत्वपूर्ण विश्वसनीयता पैटर्न

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

डेटा पाइपलाइन को कैसे डिज़ाइन करें

1. उपभोक्ता निर्णय या अनुप्रयोग व्यवहार से शुरू करें जिसे आउटपुट को समर्थन देना चाहिए।
2. आउटपुट स्कीमा, ताजगी लक्ष्य, सटीकता अपेक्षाएँ, और मालिक को परिभाषित करें।
3. स्रोत, अनुमतियाँ, परिवर्तन व्यवहार, मात्रा, और विफलता मामलों का इन्वेंटरी बनाएं।
4. लेटेंसी आवश्यकता के अनुसार बैच, माइक्रो-बैच, या स्ट्रीमिंग का चयन करें।
5. अधिग्रहण, मान्यता, परिवर्तन, भंडारण, और सेवा सीमाओं को अलग करें।
6. स्केल से दोष छिपाने से पहले वंशावली, गुणवत्ता की जांच, लागत उपाय, और कार्यन्वयनalerts जोड़ें।
7. पुनः परीक्षण, स्कीमा परिवर्तन, आंशिक इनपुट, डुप्लिकेट इनपुट, और डाउनस्ट्रीम अनुपलब्धता का परीक्षण करें।

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

पाइपलाइन का मूल्यांकन कैसे करें

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

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

निष्कर्ष

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