🥇मुक्त स्रोत डेटाहब: लिंक्डइनचा शोध आणि मेटाडेटा शोध मंच

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

डेटा-आधारित निर्णय घेण्यासाठी मोठ्या प्रमाणात डेटावर अवलंबून असलेल्या कोणत्याही कंपनीसाठी आपल्याला आवश्यक असलेला डेटा द्रुतपणे शोधणे आवश्यक आहे. याचा केवळ डेटा वापरकर्त्यांच्या उत्पादकतेवरच परिणाम होत नाही (विश्लेषक, मशीन लर्निंग डेव्हलपर, डेटा सायंटिस्ट आणि डेटा अभियंता) पण त्याचा थेट परिणाम दर्जेदार मशीन लर्निंग (ML) पाइपलाइनवर अवलंबून असलेल्या अंतिम उत्पादनांवर होतो. याव्यतिरिक्त, मशीन लर्निंग प्लॅटफॉर्मची अंमलबजावणी किंवा तयार करण्याचा कल स्वाभाविकपणे प्रश्न उपस्थित करतो: वैशिष्ट्ये, मॉडेल्स, मेट्रिक्स, डेटासेट इ. अंतर्गत शोधण्यासाठी तुमची पद्धत काय आहे.

या लेखात आम्ही ओपन लायसन्स अंतर्गत डेटा स्रोत कसा प्रकाशित केला याबद्दल चर्चा करू DataHub आमच्या मेटाडेटा शोध आणि शोध प्लॅटफॉर्ममध्ये, प्रकल्पाच्या सुरुवातीच्या दिवसांपासून कुठे कसे. LinkedIn DataHub ची स्वतःची आवृत्ती ओपन सोर्स आवृत्तीपासून वेगळे ठेवते. आम्हाला दोन स्वतंत्र विकास वातावरणाची गरज का आहे हे आम्ही स्पष्ट करून सुरुवात करू, त्यानंतर ओपन सोर्स व्हेअरहाऊस वापरण्याच्या सुरुवातीच्या पद्धतींवर चर्चा करू आणि आमच्या DataHub च्या अंतर्गत (उत्पादन) आवृत्तीची वरील आवृत्तीशी तुलना करू. GitHub. दोन्ही रेपॉजिटरी समक्रमित ठेवण्यासाठी आम्ही ओपन सोर्स अपडेट्स पुशिंग आणि प्राप्त करण्यासाठी आमच्या नवीन ऑटोमेटेड सोल्यूशनबद्दल तपशील देखील शेअर करू. शेवटी, आम्ही ओपन सोर्स DataHub वापरून सुरुवात कशी करावी याबद्दल सूचना देऊ आणि त्याच्या आर्किटेक्चरची थोडक्यात चर्चा करू.

व्हेअरहाऊस आता डेटाहब आहे!

LinkedIn च्या मेटाडेटा टीमने यापूर्वी सादर केले होते DataHub (WhereHows चे उत्तराधिकारी), LinkedIn चा शोध आणि मेटाडेटा शोध प्लॅटफॉर्म आणि ते उघडण्याच्या योजना सामायिक केल्या. या घोषणेनंतर लवकरच, आम्ही DataHub ची अल्फा आवृत्ती जारी केली आणि ती समुदायासह सामायिक केली. तेव्हापासून, आम्ही सतत रिपॉझिटरीमध्ये योगदान दिले आहे आणि सर्वात जास्त विनंती केलेली वैशिष्ट्ये जोडण्यासाठी आणि समस्या सोडवण्यासाठी इच्छुक वापरकर्त्यांसोबत काम केले आहे. आता अधिकृत प्रकाशन जाहीर करताना आम्हाला आनंद होत आहे GitHub वर DataHub.

मुक्त स्रोत दृष्टीकोन

WhereHows, डेटा शोधण्यासाठी लिंक्डइनचे मूळ पोर्टल आणि ते कुठून येते, हे अंतर्गत प्रकल्प म्हणून सुरू झाले; मेटाडेटा टीमने ते उघडले 2016 मध्ये स्त्रोत कोड. तेव्हापासून, संघाने नेहमीच दोन भिन्न कोडबेस राखले आहेत—एक मुक्त स्रोतासाठी आणि एक लिंक्डइनच्या अंतर्गत वापरासाठी—कारण LinkedIn वापर प्रकरणांसाठी विकसित केलेली सर्व उत्पादन वैशिष्ट्ये सामान्यतः व्यापक प्रेक्षकांना लागू होत नाहीत. याव्यतिरिक्त, WhereHows मध्ये काही अंतर्गत अवलंबित्व (पायाभूत सुविधा, लायब्ररी इ.) आहेत जे मुक्त स्रोत नाहीत. त्यानंतरच्या वर्षांमध्ये, व्हेअरहाऊस अनेक पुनरावृत्ती आणि विकास चक्रांमधून गेले, ज्यामुळे दोन कोडबेस समक्रमित ठेवणे एक मोठे आव्हान बनले. मेटाडेटा टीमने अंतर्गत आणि मुक्त स्रोत विकास समक्रमित ठेवण्याचा प्रयत्न करण्यासाठी गेल्या काही वर्षांपासून वेगवेगळ्या पद्धती वापरल्या आहेत.

प्रथम प्रयत्न: "प्रथम मुक्त स्रोत"

आम्ही सुरुवातीला "ओपन सोर्स फर्स्ट" डेव्हलपमेंट मॉडेलचे अनुसरण केले, जिथे बहुतेक विकास ओपन सोर्स रिपॉझिटरीमध्ये होतो आणि अंतर्गत उपयोजनासाठी बदल केले जातात. या पध्दतीची समस्या अशी आहे की कोड नेहमी GitHub वर ढकलला जातो आधी त्याचे आंतरिक पुनरावलोकन केले जाते. जोपर्यंत ओपन सोर्स रिपॉजिटरीमधून बदल केले जात नाहीत आणि नवीन अंतर्गत उपयोजन केले जात नाही तोपर्यंत आम्हाला उत्पादन समस्या आढळणार नाहीत. खराब तैनातीच्या बाबतीत, गुन्हेगार निश्चित करणे देखील खूप कठीण होते कारण बॅचमध्ये बदल केले गेले होते.

याव्यतिरिक्त, या मॉडेलने नवीन वैशिष्ट्ये विकसित करताना संघाची उत्पादकता कमी केली ज्यासाठी जलद पुनरावृत्ती आवश्यक आहे, कारण यामुळे सर्व बदल प्रथम ओपन सोर्स रिपॉजिटरीमध्ये ढकलले जाण्यास भाग पाडले गेले आणि नंतर अंतर्गत भांडारात ढकलले गेले. प्रक्रिया वेळ कमी करण्यासाठी, आवश्यक निराकरणे किंवा बदल प्रथम अंतर्गत भांडारात केले जाऊ शकतात, परंतु जेव्हा हे बदल पुन्हा ओपन सोर्स रिपॉझिटरीमध्ये विलीन करण्यासाठी आले तेव्हा ही एक मोठी समस्या बनली कारण दोन रिपॉजिटरी सिंकच्या बाहेर होत्या.

हे मॉडेल पूर्ण-वैशिष्ट्यीकृत सानुकूल वेब अनुप्रयोगांपेक्षा सामायिक प्लॅटफॉर्म, लायब्ररी किंवा पायाभूत सुविधा प्रकल्पांसाठी लागू करणे खूप सोपे आहे. याव्यतिरिक्त, हे मॉडेल पहिल्या दिवसापासून ओपन सोर्स सुरू करणार्‍या प्रकल्पांसाठी आदर्श आहे, परंतु व्हेअरहॉज पूर्णपणे अंतर्गत वेब अनुप्रयोग म्हणून तयार केले गेले होते. सर्व अंतर्गत अवलंबित्व पूर्णपणे काढून टाकणे खरोखर कठीण होते, म्हणून आम्हाला अंतर्गत काटा ठेवणे आवश्यक होते, परंतु अंतर्गत काटा ठेवणे आणि मुख्यतः मुक्त स्त्रोत विकसित करणे फारसे कार्य करत नाही.

दुसरा प्रयत्न: “आतला पहिला”

**दुसरा प्रयत्न म्हणून, आम्ही "आंतरिक प्रथम" विकास मॉडेलकडे गेलो, जिथे बहुतेक विकास घरामध्येच होतो आणि ओपन सोर्स कोडमध्ये नियमितपणे बदल केले जातात. जरी हे मॉडेल आमच्या वापराच्या केससाठी सर्वात योग्य असले तरी त्यात अंतर्निहित समस्या आहेत. सर्व फरक थेट ओपन सोर्स रिपॉझिटरीमध्ये ढकलणे आणि नंतर विलीनीकरणातील विवादांचे निराकरण करण्याचा प्रयत्न करणे हा एक पर्याय आहे, परंतु तो वेळ घेणारा आहे. बहुतेक प्रकरणांमध्ये विकासक प्रत्येक वेळी त्यांच्या कोडचे पुनरावलोकन करताना असे न करण्याचा प्रयत्न करतात. परिणामी, हे बॅचेसमध्ये कमी वारंवार केले जाईल आणि अशा प्रकारे नंतर विलीनीकरण विवादांचे निराकरण करणे अधिक कठीण होईल.

तिसर्‍यांदा काम झाले!

वर नमूद केलेल्या दोन अयशस्वी प्रयत्नांमुळे व्हेअरहॉस गिटहब रेपॉजिटरी बर्याच काळासाठी कालबाह्य राहिली. टीमने उत्पादनाची वैशिष्ट्ये आणि आर्किटेक्चर सुधारणे सुरू ठेवले, जेणेकरून LinkedIn साठी WhereHows ची अंतर्गत आवृत्ती मुक्त स्त्रोत आवृत्तीपेक्षा अधिक प्रगत झाली. त्याचे एक नवीन नाव देखील होते - DataHub. मागील अयशस्वी प्रयत्नांवर आधारित, संघाने एक स्केलेबल, दीर्घकालीन उपाय विकसित करण्याचा निर्णय घेतला.

कोणत्याही नवीन ओपन सोर्स प्रोजेक्टसाठी, LinkedIn ची ओपन सोर्स टीम अशा डेव्हलपमेंट मॉडेलला सल्ला देते आणि समर्थन देते ज्यामध्ये प्रोजेक्टचे मॉड्यूल्स पूर्णपणे ओपन सोर्समध्ये विकसित केले जातात. आवृत्तीकृत कलाकृती सार्वजनिक भांडारात तैनात केल्या जातात आणि नंतर अंतर्गत लिंक्डइन आर्टिफॅक्टमध्ये परत तपासल्या जातात बाह्य लायब्ररी विनंती (ELR). या डेव्हलपमेंट मॉडेलचे अनुसरण करणे केवळ ओपन सोर्स वापरणाऱ्यांसाठीच चांगले नाही तर अधिक मॉड्यूलर, एक्स्टेंसिबल आणि प्लग करण्यायोग्य आर्किटेक्चरमध्ये देखील परिणाम करते.

तथापि, DataHub सारख्या परिपक्व बॅक-एंड ऍप्लिकेशनला या स्थितीत पोहोचण्यासाठी बराच वेळ लागेल. हे सर्व अंतर्गत अवलंबित्व पूर्णपणे काढून टाकण्याआधी ओपन सोर्सिंगची पूर्णपणे कार्यरत अंमलबजावणीची शक्यता नाकारते. म्हणूनच आम्ही अशी साधने विकसित केली आहेत जी आम्हाला मुक्त स्रोत योगदान जलद आणि कमी वेदनासह करण्यात मदत करतात. या सोल्यूशनचा मेटाडेटा टीम (डेटाहब डेव्हलपर) आणि ओपन सोर्स समुदाय दोघांनाही फायदा होतो. पुढील विभाग या नवीन पद्धतीवर चर्चा करतील.

मुक्त स्रोत प्रकाशन ऑटोमेशन

ओपन सोर्स DataHub साठी मेटाडेटा टीमचा नवीनतम दृष्टीकोन हा एक साधन विकसित करणे आहे जे आपोआप अंतर्गत कोडबेस आणि ओपन सोर्स रेपॉजिटरी समक्रमित करते. या टूलकिटच्या उच्च स्तरीय वैशिष्ट्यांमध्ये हे समाविष्ट आहे:

ओपन सोर्सवर/वरून LinkedIn कोड सिंक करा, समान rsync.
परवाना शीर्षलेख निर्मिती, सारखे अपाचे उंदीर.
अंतर्गत कमिट लॉगमधून ओपन सोर्स कमिट लॉग स्वयंचलितपणे व्युत्पन्न करा.
ओपन सोर्स बिल्ड मोडणारे अंतर्गत बदल प्रतिबंधित करा अवलंबित्व चाचणी.

खालील उपविभाग वर नमूद केलेल्या फंक्शन्सचा शोध घेतील ज्यात मनोरंजक समस्या आहेत.

स्त्रोत कोड सिंक्रोनाइझेशन

DataHub च्या ओपन सोर्स आवृत्तीच्या विपरीत, जी एकल GitHub रिपॉजिटरी आहे, DataHub ची LinkedIn आवृत्ती एकाधिक रिपॉझिटरीजचे संयोजन आहे (ज्याला अंतर्गत म्हणतात बहुउत्पादने). DataHub इंटरफेस, मेटाडेटा मॉडेल लायब्ररी, मेटाडेटा वेअरहाऊस बॅकएंड सेवा आणि स्ट्रीमिंग जॉब्स लिंक्डइनवर स्वतंत्र भांडारांमध्ये राहतात. तथापि, मुक्त स्रोत वापरकर्त्यांसाठी हे सोपे करण्यासाठी, आमच्याकडे DataHub च्या मुक्त स्रोत आवृत्तीसाठी एकच भांडार आहे.

आकृती 1: रेपॉजिटरीजमधील सिंक्रोनाइझेशन संलग्न DataHub आणि एकच भांडार DataHub मुक्त स्रोत

स्वयंचलित बिल्ड, पुश आणि पुल वर्कफ्लोला समर्थन देण्यासाठी, आमचे नवीन साधन प्रत्येक स्त्रोत फाइलशी संबंधित फाइल-स्तरीय मॅपिंग स्वयंचलितपणे तयार करते. तथापि, टूलकिटला प्रारंभिक कॉन्फिगरेशन आवश्यक आहे आणि वापरकर्त्यांनी खाली दर्शविल्याप्रमाणे उच्च-स्तरीय मॉड्यूल मॅपिंग प्रदान करणे आवश्यक आहे.

{
  "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 मॅपिंग आहे. फाइल असोसिएशनच्या या स्वयंचलित निर्मितीशी संबंधित अनेक नियम आहेत:

ओपन सोर्समधील लक्ष्य मॉड्यूलसाठी एकाधिक स्त्रोत मॉड्यूल्सच्या बाबतीत, संघर्ष उद्भवू शकतात, उदा. समान FQCN, एकापेक्षा जास्त स्त्रोत मॉड्यूलमध्ये अस्तित्वात आहे. संघर्ष निराकरण धोरण म्हणून, आमची साधने डीफॉल्ट "शेवटचा एक जिंकला" पर्यायावर.
"null" चा अर्थ असा आहे की स्त्रोत फाइल ओपन सोर्स रिपॉजिटरीचा भाग नाही.
प्रत्येक ओपन सोर्स सबमिशन किंवा एक्सट्रॅक्शन नंतर, हे मॅपिंग आपोआप अपडेट केले जाते आणि स्नॅपशॉट तयार केला जातो. शेवटच्या कृतीपासून स्त्रोत कोडमधून जोडणे आणि हटवणे ओळखण्यासाठी हे आवश्यक आहे.

कमिट लॉग तयार करणे

ओपन सोर्स कमिटसाठी कमिट लॉग देखील अंतर्गत रेपॉजिटरीजचे कमिट लॉग विलीन करून स्वयंचलितपणे व्युत्पन्न केले जातात. आमच्या टूलद्वारे व्युत्पन्न केलेल्या कमिट लॉगची रचना दर्शविण्यासाठी खाली नमुना कमिट लॉग आहे. कमिट स्पष्टपणे सूचित करते की स्त्रोत रेपॉजिटरीजच्या कोणत्या आवृत्त्या त्या कमिटमध्ये पॅकेज केल्या आहेत आणि कमिट लॉगचा सारांश प्रदान करते. हे पहा वचनबद्ध आमच्या टूलकिटद्वारे व्युत्पन्न केलेल्या कमिट लॉगचे वास्तविक उदाहरण वापरणे.

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

अवलंबित्व चाचणी

LinkedIn आहे अवलंबित्व चाचणी पायाभूत सुविधा, जे हे सुनिश्चित करण्यात मदत करते की अंतर्गत मल्टीप्रॉडक्टमधील बदल अवलंबित मल्टीप्रॉडक्टचे असेंब्ली खंडित करत नाहीत. ओपन सोर्स DataHub रेपॉजिटरी हे मल्टी-प्रॉडक्ट नाही आणि ते कोणत्याही मल्टी-प्रॉडक्टवर थेट अवलंबित्व असू शकत नाही, परंतु ओपन सोर्स DataHub सोर्स कोड मिळवणाऱ्या मल्टी-प्रॉडक्ट रॅपरच्या मदतीने, आम्ही अजूनही ही अवलंबित्व चाचणी वापरू शकतो. प्रणाली. अशा प्रकारे, ओपन सोर्स DataHub रेपॉजिटरी फीड करणार्‍या कोणत्याही मल्टीप्रॉडक्टमध्ये कोणताही बदल (जे नंतर उघड होऊ शकते) शेल मल्टीप्रॉडक्टमध्ये बिल्ड इव्हेंट ट्रिगर करते. म्‍हणून, रॅपर उत्‍पादन तयार करण्‍यात अयशस्वी होणारा कोणताही बदल मूळ उत्‍पादन करण्‍यापूर्वी चाचण्‍यात अपयशी ठरतो आणि तो परत केला जातो.

ही एक उपयुक्त यंत्रणा आहे जी ओपन सोर्स बिल्ड खंडित करणार्‍या कोणत्याही अंतर्गत कमिटला प्रतिबंधित करण्यात मदत करते आणि कमिट वेळी ते शोधते. याशिवाय, कोणत्या अंतर्गत कमिटमुळे ओपन सोर्स रिपॉजिटरी बिल्ड अयशस्वी झाले हे निश्चित करणे खूप कठीण होईल, कारण आम्ही DataHub ओपन सोर्स रिपॉजिटरीमध्ये अंतर्गत बदल करतो.

मुक्त स्रोत DataHub आणि आमच्या उत्पादन आवृत्तीमधील फरक

या टप्प्यापर्यंत, आम्ही DataHub रेपॉजिटरीजच्या दोन आवृत्त्या समक्रमित करण्यासाठी आमच्या समाधानावर चर्चा केली आहे, परंतु आम्हाला प्रथम स्थानावर दोन भिन्न विकास प्रवाह का आवश्यक आहेत याची कारणे आम्ही अद्याप स्पष्ट केलेली नाहीत. या विभागात, आम्ही DataHub ची सार्वजनिक आवृत्ती आणि LinkedIn सर्व्हरवरील उत्पादन आवृत्तीमधील फरकांची यादी करू आणि या फरकांची कारणे स्पष्ट करू.

विसंगतीचा एक स्त्रोत या वस्तुस्थितीमुळे उद्भवतो की आमच्या उत्पादन आवृत्तीमध्ये अद्याप मुक्त स्त्रोत नसलेल्या कोडवर अवलंबित्व आहे, जसे की LinkedIn's Offspring (LinkedIn चे अंतर्गत अवलंबन इंजेक्शन फ्रेमवर्क). अंतर्गत कोडबेसमध्ये संतती मोठ्या प्रमाणावर वापरली जाते कारण ती डायनॅमिक कॉन्फिगरेशन व्यवस्थापित करण्यासाठी पसंतीची पद्धत आहे. पण तो ओपन सोर्स नाही; त्यामुळे आम्हाला ओपन सोर्स DataHub साठी ओपन सोर्स पर्याय शोधण्याची गरज होती.

इतरही कारणे आहेत. लिंक्डइनच्या गरजांसाठी आम्ही मेटाडेटा मॉडेलसाठी विस्तार तयार करत असल्याने, हे विस्तार विशेषत: LinkedIn साठी अतिशय विशिष्ट असतात आणि ते इतर वातावरणात थेट लागू होत नाहीत. उदाहरणार्थ, आमच्याकडे सहभागी आयडी आणि इतर प्रकारच्या जुळणार्‍या मेटाडेटांसाठी अतिशय विशिष्ट लेबले आहेत. त्यामुळे, आम्ही आता हे विस्तार DataHub च्या ओपन सोर्स मेटाडेटा मॉडेलमधून वगळले आहेत. आम्‍ही समुदायासोबत गुंतून राहिल्‍याने आणि त्‍यांच्‍या गरजा समजून घेत असल्‍याने आम्‍ही या एक्‍सटेंशनच्‍या सामायिक ओपन सोर्स आवृत्त्यांवर काम करू.

ओपन सोर्स कम्युनिटीसाठी वापरण्यात सुलभता आणि सुलभ रुपांतरण देखील DataHub च्या दोन आवृत्त्यांमधील काही फरकांना प्रेरित करते. प्रवाह प्रक्रिया पायाभूत सुविधांमधील फरक हे याचे उत्तम उदाहरण आहे. जरी आमची अंतर्गत आवृत्ती व्यवस्थापित प्रवाह प्रक्रिया फ्रेमवर्क वापरते, आम्ही ओपन सोर्स आवृत्तीसाठी अंगभूत (स्टँडअलोन) प्रवाह प्रक्रिया वापरणे निवडले कारण ते इतर पायाभूत सुविधा अवलंबित्व निर्माण करणे टाळते.

फरकाचे आणखी एक उदाहरण म्हणजे एकाधिक GMS ऐवजी एकच GMS (सामान्यीकृत मेटाडेटा स्टोअर) ओपन सोर्स अंमलबजावणीमध्ये असणे. GMA (जनरलाइज्ड मेटाडेटा आर्किटेक्चर) हे DataHub साठी बॅक-एंड आर्किटेक्चरचे नाव आहे आणि GMS हे GMA संदर्भात मेटाडेटा स्टोअर आहे. GMA हे एक अतिशय लवचिक आर्किटेक्चर आहे जे तुम्हाला प्रत्येक डेटा रचना (उदा. डेटासेट, वापरकर्ते इ.) त्याच्या स्वतःच्या मेटाडेटा स्टोअरमध्ये वितरित करण्यास किंवा एकाच मेटाडेटा स्टोअरमध्ये एकाधिक डेटा रचना संचयित करण्यास अनुमती देते जोपर्यंत रेजिस्ट्रीमध्ये डेटा स्ट्रक्चर मॅपिंग असते. GMS अद्यतनित केले आहे. वापराच्या सोप्यासाठी, आम्ही एकच GMS उदाहरण निवडले आहे जे ओपन सोर्स DataHub मध्ये सर्व भिन्न डेटा रचना संग्रहित करते.

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

उत्पादन वैशिष्ट्ये
लिंक्डइन डेटाहब
ओपन सोर्स DataHub

समर्थित डेटा रचना
1) डेटासेट 2) वापरकर्ते 3) मेट्रिक्स 4) ML वैशिष्ट्ये 5) चार्ट 6) डॅशबोर्ड
1) डेटासेट 2) वापरकर्ते

डेटासेटसाठी समर्थित मेटाडेटा स्रोत
1) अँब्री २) काउचबेस ३) डालिड्स 4) एस्प्रेसो 5) HDFS 6) पोळे 7) काफ्का 8) MongoDB 9) MySQL 10) ओरॅकल 11) पिनॉट 12) प्रेस्टो 12) व्हा 13) टेराडेटा 13) वेक्टर 14) व्हेनिस
पोळे काफ्का RDBMS

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

प्रवाह प्रक्रिया
व्यवस्थापित
एम्बेडेड (स्टँडअलोन)

अवलंबित्व इंजेक्शन आणि डायनॅमिक कॉन्फिगरेशन
लिंक्डइन संतती
वसंत ऋतू

टूलिंग तयार करा
Ligradle (LinkedIn चे अंतर्गत Gradle रॅपर)
Gradlew

सीआय / सीडी
सीआरटी (लिंक्डइनचे अंतर्गत सीआय/सीडी)
TravisCI आणि डॉकर हब

मेटाडेटा स्टोअर्स
वितरित एकाधिक GMS: 1) डेटासेट GMS 2) वापरकर्ता GMS 3) मेट्रिक GMS 4) वैशिष्ट्य GMS 5) चार्ट/डॅशबोर्ड GMS
यासाठी सिंगल GMS: 1) डेटासेट 2) वापरकर्ते

डॉकर कंटेनरमधील सूक्ष्म सेवा

गोदी कामगार सह अनुप्रयोग उपयोजन आणि वितरण सुलभ करते कंटेनरीकरण. DataHub मधील सेवेचा प्रत्येक भाग ओपन सोर्स आहे, ज्यात पायाभूत सुविधा घटक जसे की काफ्का, Elasticsearch, neo4j и , MySQL, ची स्वतःची डॉकर प्रतिमा आहे. डॉकर कंटेनर ऑर्केस्ट्र करण्यासाठी आम्ही वापरले डॉकर लिहिणे.

आकृती 2: आर्किटेक्चर DataHub *मुक्त स्रोत**

तुम्ही वरील इमेजमध्ये DataHub चे उच्च-स्तरीय आर्किटेक्चर पाहू शकता. पायाभूत सुविधांच्या घटकांव्यतिरिक्त, त्यात चार भिन्न डॉकर कंटेनर आहेत:

datahub-gms: मेटाडेटा स्टोरेज सेवा

datahub-frontend: अनुप्रयोग प्ले, DataHub इंटरफेस सेवा देत आहे.

datahub-mce-ग्राहक: अनुप्रयोग काफ्का प्रवाह, जे मेटाडेटा बदल इव्हेंट (MCE) प्रवाह वापरते आणि मेटाडेटा स्टोअर अद्यतनित करते.

datahub-mae-ग्राहक: अनुप्रयोग काफ्का प्रवाह, जे मेटाडेटा ऑडिट इव्हेंट स्ट्रीम (MAE) वापरते आणि शोध निर्देशांक आणि आलेख डेटाबेस तयार करते.

मुक्त स्रोत भांडार दस्तऐवजीकरण आणि मूळ DataHub ब्लॉग पोस्ट विविध सेवांच्या कार्यांबद्दल अधिक तपशीलवार माहिती समाविष्ट आहे.

DataHub वर CI/CD ओपन सोर्स आहे

ओपन सोर्स DataHub रेपॉजिटरी वापरते TravisCI सतत एकत्रीकरणासाठी आणि डॉकर हब सतत तैनातीसाठी. दोघांमध्ये चांगले GitHub एकत्रीकरण आहे आणि ते सेट करणे सोपे आहे. समुदाय किंवा खाजगी कंपन्यांनी विकसित केलेल्या बहुतेक मुक्त स्रोत पायाभूत सुविधांसाठी (उदा. संगम), डॉकर प्रतिमा समुदायाद्वारे वापरण्यास सुलभतेसाठी डॉकर हबमध्ये तयार केल्या जातात आणि तैनात केल्या जातात. डॉकर हबमध्ये आढळणारी कोणतीही डॉकर प्रतिमा सोप्या कमांडसह सहजपणे वापरली जाऊ शकते डॉकर पुल.

DataHub ओपन सोर्स रिपॉजिटरीशी प्रत्येक वचनबद्धतेसह, सर्व डॉकर प्रतिमा स्वयंचलितपणे तयार केल्या जातात आणि "नवीनतम" टॅगसह डॉकर हबमध्ये तैनात केल्या जातात. डॉकर हब काही सह कॉन्फिगर केले असल्यास नियमित अभिव्यक्ती शाखांचे नाव देणे, ओपन सोर्स रिपॉजिटरीमधील सर्व टॅग देखील डॉकर हबमध्ये संबंधित टॅग नावांसह रिलीझ केले जातात.

DataHub वापरणे

DataHub सेट करत आहे खूप सोपे आहे आणि तीन सोप्या चरणांचा समावेश आहे:

ओपन सोर्स रिपॉजिटरी क्लोन करा आणि त्वरित प्रारंभ करण्यासाठी प्रदान केलेल्या डॉकर-कंपोज स्क्रिप्टचा वापर करून डॉकर-कंपोझसह सर्व डॉकर कंटेनर चालवा.
रेपॉजिटरीमध्ये प्रदान केलेला नमुना डेटा देखील प्रदान केलेल्या कमांड लाइन टूलचा वापर करून डाउनलोड करा.
तुमच्या ब्राउझरमध्ये DataHub ब्राउझ करा.

सक्रियपणे ट्रॅक केले गप्पागोष्टी द्रुत प्रश्नांसाठी देखील कॉन्फिगर केले. वापरकर्ते GitHub रेपॉजिटरीमध्ये थेट समस्या देखील तयार करू शकतात. सर्वात महत्त्वाचे म्हणजे, आम्ही सर्व अभिप्राय आणि सूचनांचे स्वागत करतो आणि त्यांचे कौतुक करतो!

भविष्यासाठी योजना

सध्या, ओपन सोर्स DataHub साठी प्रत्येक पायाभूत सुविधा किंवा मायक्रोसर्व्हिस डॉकर कंटेनर म्हणून तयार केली गेली आहे आणि संपूर्ण प्रणाली वापरून ऑर्केस्ट्रेटेड आहे डॉकर-कंपोज. लोकप्रियता आणि व्यापकता दिली कुबेरनेट्स, आम्ही नजीकच्या भविष्यात कुबर्नेट्स आधारित समाधान देखील देऊ इच्छितो.

सार्वजनिक क्लाउड सेवेवर DataHub उपयोजित करण्यासाठी टर्नकी सोल्यूशन प्रदान करण्याची आमची योजना आहे जसे की अस्मानी, ऑव्हज किंवा Google मेघ. LinkedIn च्या Azure मध्ये स्थलांतराची अलीकडील घोषणा पाहता, हे मेटाडेटा टीमच्या अंतर्गत प्राधान्यांशी संरेखित होईल.

सर्वात शेवटी, ओपन सोर्स समुदायातील DataHub च्या सुरुवातीच्या अवलंबकर्त्यांना धन्यवाद ज्यांनी DataHub अल्फास रेट केले आहे आणि आम्हाला समस्या ओळखण्यात आणि दस्तऐवजीकरण सुधारण्यात मदत केली आहे.

स्त्रोत: www.habr.com