ओपन सोर्स डेटाहब: लिंक्डइन का मेटाडेटा सर्च और डिस्कवरी प्लेटफॉर्म

ओपन सोर्स डेटाहब: लिंक्डइन का मेटाडेटा सर्च और डिस्कवरी प्लेटफॉर्म

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

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

व्हेयरहाउज़ अब एक डेटाहब है!

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

मुक्त स्रोत दृष्टिकोण

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

पहला प्रयास: "पहले ओपन सोर्स"

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

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

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

दूसरा प्रयास: "आंतरिक प्रथम"

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

तीसरी बार यह काम कर गया!

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

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

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

मुक्त स्रोत प्रकाशन स्वचालन

ओपन सोर्स डेटाहब के लिए मेटाडेटा टीम का नवीनतम दृष्टिकोण एक उपकरण विकसित करना है जो आंतरिक कोडबेस और ओपन सोर्स रिपॉजिटरी को स्वचालित रूप से सिंक करता है। इस टूलकिट की उच्च-स्तरीय विशेषताओं में शामिल हैं:

1. लिंक्डइन कोड को ओपन सोर्स से/से सिंक करें, समान rsync.
2. लाइसेंस हेडर जनरेशन, के समान अपाचे चूहा.
3. आंतरिक कमिट लॉग से स्वचालित रूप से ओपन सोर्स कमिट लॉग जेनरेट करें।
4. ओपन सोर्स बिल्ड को तोड़ने वाले आंतरिक परिवर्तनों को रोकें निर्भरता परीक्षण.

निम्नलिखित उपखंड उपर्युक्त कार्यों पर प्रकाश डालेंगे जिनमें दिलचस्प समस्याएं हैं।

स्रोत कोड तुल्यकालन

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

चित्र 1: रिपॉजिटरी के बीच सिंक्रनाइज़ेशन लिंक्डइन डेटाहब और एक एकल भंडार डेटाहब खुला स्त्रोत

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

{
  "datahub-dao": [
    "${datahub-frontend}/datahub-dao"
  ],
  "gms/impl": [
    "${dataset-gms}/impl",
    "${user-gms}/impl"
  ],
  "metadata-dao": [
    "${metadata-models}/metadata-dao"
  ],
  "metadata-builders": [
    "${metadata-models}/metadata-builders"
  ]
}

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

{
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Foo.java":
"metadata-builders/src/main/java/com/linkedin/Foo.java",
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Bar.java":
"metadata-builders/src/main/java/com/linkedin/Bar.java",
  "${metadata-models}/metadata-builders/build.gradle": null,
}

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

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

प्रतिबद्ध लॉग बनाना

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

metadata-models 29.0.0 -> 30.0.0
    Added aspect model foo
    Fixed issue bar

dataset-gms 2.3.0 -> 2.3.4
    Added rest.li API to serve foo aspect

MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0

निर्भरता परीक्षण

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

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

ओपन सोर्स डेटाहब और हमारे उत्पादन संस्करण के बीच अंतर

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

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

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

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

अंतर का एक अन्य उदाहरण एक खुले स्रोत कार्यान्वयन में एकाधिक जीएमएस के बजाय एक एकल जीएमएस (सामान्यीकृत मेटाडेटा स्टोर) होना है। GMA (सामान्यीकृत मेटाडेटा आर्किटेक्चर) डेटाहब के लिए बैक-एंड आर्किटेक्चर का नाम है, और GMA के संदर्भ में GMS मेटाडेटा स्टोर है। GMA एक बहुत ही लचीली वास्तुकला है जो आपको प्रत्येक डेटा निर्माण (जैसे डेटासेट, उपयोगकर्ता, आदि) को अपने मेटाडेटा स्टोर में वितरित करने की अनुमति देती है, या एक ही मेटाडेटा स्टोर में कई डेटा निर्माणों को संग्रहीत करने की अनुमति देती है, जब तक कि रजिस्ट्री में डेटा संरचना मैपिंग होती है। जीएमएस अद्यतन है. उपयोग में आसानी के लिए, हमने एक एकल जीएमएस उदाहरण चुना जो सभी विभिन्न डेटा संरचनाओं को ओपन सोर्स डेटाहब में संग्रहीत करता है।

दोनों कार्यान्वयनों के बीच अंतर की पूरी सूची नीचे दी गई तालिका में दी गई है।

उत्पाद सुविधाएँ
लिंक्डइन डेटाहब
ओपन सोर्स डेटाहब

समर्थित डेटा संरचनाएँ
1) डेटासेट 2) उपयोगकर्ता 3) मेट्रिक्स 4) एमएल विशेषताएं 5) चार्ट 6) डैशबोर्ड
1) डेटासेट 2) उपयोगकर्ता

डेटासेट के लिए समर्थित मेटाडेटा स्रोत
1) अम्बरी 2) काउचबेस 3) दलिड्स 4) एस्प्रेसो 5) एचडीएफएस 6) हाइव 7) काफ्का 8) मोंगोडीबी 9) मायएसक्यूएल 10) ओरेकल 11) Pinot 12) प्रेस्टो 12) सागरों 13) टेराडेटा 13) वेक्टर 14) वेनिस
हाइव काफ्का आरडीबीएमएस

पब-उप
लिंक्डइन काफ्का
संगम काफ्का

स्ट्रीम प्रोसेसिंग
प्रबंधित
एंबेडेड (स्टैंडअलोन)

निर्भरता इंजेक्शन और गतिशील विन्यास
लिंक्डइन संतान
वसंत

टूलींग बनाएँ
लिग्राडल (लिंक्डइन का आंतरिक ग्रैडल रैपर)
Gradlew

सीआई / सीडी
सीआरटी (लिंक्डइन का आंतरिक सीआई/सीडी)
ट्रैविसी और डॉकर हब

मेटाडेटा स्टोर
वितरित एकाधिक जीएमएस: 1) डेटासेट जीएमएस 2) उपयोगकर्ता जीएमएस 3) मीट्रिक जीएमएस 4) फ़ीचर जीएमएस 5) चार्ट/डैशबोर्ड जीएमएस
इनके लिए एकल जीएमएस: 1) डेटासेट 2) उपयोगकर्ता

डॉकर कंटेनरों में माइक्रोसर्विसेज

डाक में काम करनेवाला मज़दूर एप्लिकेशन परिनियोजन और वितरण को सरल बनाता है कन्टेनरीकरण. डेटाहब में सेवा का प्रत्येक भाग खुला स्रोत है, जिसमें काफ्का जैसे बुनियादी ढांचे के घटक शामिल हैं। Elasticsearch, neo4j и MySQL, की अपनी डॉकर छवि है। डॉकर कंटेनरों को व्यवस्थित करने के लिए हमने उपयोग किया डॉकर लिखें.

चित्र 2: वास्तुकला डेटाहब *खुला स्त्रोत**

आप ऊपर की छवि में डेटाहब का उच्च-स्तरीय आर्किटेक्चर देख सकते हैं। बुनियादी ढांचे के घटकों के अलावा, इसमें चार अलग-अलग डॉकर कंटेनर हैं:

डेटाहब-जीएमएस: मेटाडेटा भंडारण सेवा

डेटाहब-फ्रंटएंड: एप्लिकेशन प्ले, डेटाहब इंटरफ़ेस की सेवा।

डेटाहब-एमसीई-उपभोक्ता: एप्लिकेशन काफ्का धाराएँ, जो मेटाडेटा चेंज इवेंट (एमसीई) स्ट्रीम का उपयोग करता है और मेटाडेटा स्टोर को अपडेट करता है।

डेटाहब-एमएई-उपभोक्ता: एप्लिकेशन काफ्का धाराएँ, जो मेटाडेटा ऑडिट इवेंट स्ट्रीम (MAE) का उपयोग करता है और एक खोज सूचकांक और ग्राफ़ डेटाबेस बनाता है।

ओपन सोर्स रिपॉजिटरी दस्तावेज़ीकरण और मूल डेटाहब ब्लॉग पोस्ट विभिन्न सेवाओं के कार्यों के बारे में अधिक विस्तृत जानकारी शामिल है।

डेटाहब पर सीआई/सीडी खुला स्रोत है

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

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

डेटाहब का उपयोग करना

डेटाहब की स्थापना यह बहुत सरल है और इसमें तीन सरल चरण शामिल हैं:

1. ओपन सोर्स रिपॉजिटरी को क्लोन करें और त्वरित शुरुआत के लिए प्रदान की गई डॉकर-कंपोज़ स्क्रिप्ट का उपयोग करके सभी डॉकर कंटेनरों को डॉकर-कंपोज़ के साथ चलाएं।
2. उपलब्ध कराए गए कमांड लाइन टूल का उपयोग करके रिपॉजिटरी में दिए गए नमूना डेटा को डाउनलोड करें।
3. अपने ब्राउज़र में डेटाहब ब्राउज़ करें।

सक्रिय रूप से ट्रैक किया गया गिटर चैट त्वरित प्रश्नों के लिए भी कॉन्फ़िगर किया गया। उपयोगकर्ता सीधे GitHub रिपॉजिटरी में भी समस्याएँ बना सकते हैं। सबसे महत्वपूर्ण बात यह है कि हम सभी फीडबैक और सुझावों का स्वागत करते हैं और उनकी सराहना करते हैं!

Планы на будущее

वर्तमान में, ओपन सोर्स डेटाहब के लिए प्रत्येक बुनियादी ढांचे या माइक्रोसर्विस को डॉकर कंटेनर के रूप में बनाया गया है, और पूरे सिस्टम को इसका उपयोग करके व्यवस्थित किया गया है डोकर-लिखें. लोकप्रियता और व्यापकता को देखते हुए Kubernetes, हम निकट भविष्य में कुबेरनेट्स आधारित समाधान भी प्रदान करना चाहेंगे।

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

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

स्रोत: www.habr.com