🥇खुला स्रोत DataHub: LinkedIn को खोज र मेटाडेटा खोज प्लेटफर्म

खुला स्रोत DataHub: LinkedIn को मेटाडेटा खोज र खोज प्लेटफर्म

डेटा-संचालित निर्णयहरू गर्नको लागि डेटाको ठूलो मात्रामा निर्भर गर्ने कुनै पनि कम्पनीको लागि तपाईंलाई चाँडै आवश्यक डेटा फेला पार्न आवश्यक छ। यसले डाटा प्रयोगकर्ताहरू (विश्लेषकहरू, मेसिन लर्निङ विकासकर्ताहरू, डाटा वैज्ञानिकहरू, र डाटा इन्जिनियरहरू सहित) को उत्पादकतामा मात्र प्रभाव पार्दैन, तर गुणस्तरीय मेसिन लर्निङ (ML) पाइपलाइनमा निर्भर हुने अन्तिम उत्पादनहरूमा पनि प्रत्यक्ष प्रभाव पार्छ। थप रूपमा, मेसिन लर्निङ प्लेटफर्महरू लागू गर्ने वा निर्माण गर्ने प्रवृत्तिले स्वाभाविक रूपमा प्रश्न उठाउँछ: आन्तरिक रूपमा सुविधाहरू, मोडेलहरू, मेट्रिक्स, डेटासेटहरू, आदि पत्ता लगाउनको लागि तपाईंको विधि के हो।

यस लेखमा हामी खुला इजाजतपत्र अन्तर्गत डाटा स्रोत कसरी प्रकाशित गर्यौं भन्ने बारेमा कुरा गर्नेछौं DataHub हाम्रो मेटाडेटा खोज र खोज प्लेटफर्ममा, परियोजनाको प्रारम्भिक दिनहरूबाट सुरु कहाँ कसरी। LinkedIn ले DataHub को आफ्नै संस्करण खुला स्रोत संस्करणबाट अलग राख्छ। हामी किन दुई छुट्टाछुट्टै विकास वातावरण चाहिन्छ भनेर व्याख्या गरेर सुरु गर्नेछौं, त्यसपछि खुला स्रोत whereHows प्रयोग गर्ने प्रारम्भिक दृष्टिकोणहरू छलफल गर्नेछौं र डाटाहबको हाम्रो आन्तरिक (उत्पादन) संस्करणको संस्करणसँग तुलना गर्नेछौं। GitHub। हामी दुबै रिपोजिटरीहरूलाई सिङ्कमा राख्नको लागि खुला स्रोत अद्यावधिकहरू पुश गर्ने र प्राप्त गर्ने हाम्रो नयाँ स्वचालित समाधानको बारेमा विवरणहरू पनि साझा गर्नेछौं। अन्तमा, हामी कसरी खुला स्रोत डाटाहब प्रयोग गरेर सुरु गर्ने भन्ने बारे निर्देशनहरू प्रदान गर्नेछौं र यसको वास्तुकलाको बारेमा संक्षिप्त रूपमा छलफल गर्नेछौं।

WhereHows अब एक DataHub छ!

LinkedIn को मेटाडाटा टोली पहिले प्रस्तुत गरियो DataHub (WhereHows को उत्तराधिकारी), LinkedIn को खोज र मेटाडेटा खोज प्लेटफर्म, र यसलाई खोल्ने योजना साझा गर्नुभयो। यो घोषणाको केही समय पछि, हामीले DataHub को अल्फा संस्करण जारी गर्यौं र समुदायसँग साझा गर्यौं। त्यसबेलादेखि, हामीले भण्डारमा निरन्तर योगदान दिएका छौं र इच्छुक प्रयोगकर्ताहरूसँग सबैभन्दा अनुरोध गरिएका सुविधाहरू थप्न र समस्याहरू समाधान गर्न काम गरेका छौं। हामी अब आधिकारिक विज्ञप्ति घोषणा गर्न खुसी छौं GitHub मा DataHub.

खुला स्रोत दृष्टिकोणहरू

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

पहिलो प्रयास: "खुला स्रोत पहिले"

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

थप रूपमा, यो मोडेलले द्रुत पुनरावृत्तिहरू आवश्यक पर्ने नयाँ सुविधाहरू विकास गर्दा टोलीको उत्पादकता कम गर्‍यो, किनकि यसले सबै परिवर्तनहरूलाई पहिलो खुला स्रोत भण्डारमा धकेल्न र त्यसपछि आन्तरिक भण्डारमा धकेल्न बाध्य तुल्यायो। प्रशोधन समय घटाउनको लागि, आवश्यक फिक्स वा परिवर्तन पहिले आन्तरिक भण्डारमा गर्न सकिन्छ, तर यो एक ठूलो समस्या भयो जब ती परिवर्तनहरूलाई खुला स्रोत भण्डारमा मर्ज गर्न आयो किनभने दुई भण्डारहरू सिङ्कबाट बाहिर थिए।

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

दोस्रो प्रयास: "आन्तरिक पहिलो"

** दोस्रो प्रयासको रूपमा, हामी "आन्तरिक पहिलो" विकास मोडेलमा सारियो, जहाँ अधिकांश विकास घरभित्रै हुन्छ र खुला स्रोत कोडमा नियमित रूपमा परिवर्तनहरू गरिन्छ। यद्यपि यो मोडेल हाम्रो प्रयोग केसको लागि उत्तम उपयुक्त छ, यसमा अन्तर्निहित समस्याहरू छन्। खुला स्रोत भण्डारमा सबै भिन्नताहरूलाई सीधा धकेल्नु र पछि मर्ज विवादहरू समाधान गर्ने प्रयास गर्नु एक विकल्प हो, तर यो समय खपत हो। धेरै जसो केसहरूमा विकासकर्ताहरूले उनीहरूको कोड समीक्षा गर्दा प्रत्येक पटक यो नगर्ने प्रयास गर्छन्। नतिजाको रूपमा, यो धेरै कम बारम्बार, ब्याचहरूमा गरिन्छ, र यसरी पछि मर्ज विवादहरू समाधान गर्न अझ गाह्रो बनाउँछ।

तेस्रो पटक काम भयो!

माथि उल्लिखित दुई असफल प्रयासहरूको परिणामस्वरूप WhoHows GitHub भण्डार लामो समयको लागि पुरानो रह्यो। टोलीले उत्पादनका सुविधाहरू र वास्तुकला सुधार गर्न जारी राख्यो, ताकि LinkedIn को लागि WhereHows को आन्तरिक संस्करण खुला स्रोत संस्करण भन्दा बढि उन्नत भयो। यसको नयाँ नाम पनि थियो - DataHub। अघिल्लो असफल प्रयासहरूको आधारमा, टोलीले स्केलेबल, दीर्घकालीन समाधान विकास गर्ने निर्णय गर्‍यो।

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

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

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

मेटाडेटा टोलीको खुला स्रोत डाटाहबको पछिल्लो दृष्टिकोण भनेको आन्तरिक कोडबेस र खुला स्रोत भण्डारलाई स्वचालित रूपमा सिङ्क गर्ने उपकरण विकास गर्नु हो। यस टूलकिटको उच्च स्तरका सुविधाहरू समावेश छन्:

लिङ्क्डइन कोड सिंक गर्नुहोस्/खुला स्रोतबाट, समान rsync.
लाइसेन्स हेडर जेनरेशन, जस्तै अपाचे मुसा.
आन्तरिक प्रतिबद्ध लगहरूबाट स्वचालित रूपमा खुला स्रोत प्रतिबद्ध लगहरू उत्पन्न गर्नुहोस्।
आन्तरिक परिवर्तनहरू रोक्नुहोस् जसले खुला स्रोत निर्माणलाई तोड्छ निर्भरता परीक्षण.

निम्न उपखण्डहरूले माथि उल्लेखित प्रकार्यहरूमा ध्यान दिनेछ जुन रोचक समस्याहरू छन्।

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

DataHub को खुला स्रोत संस्करणको विपरीत, जुन एकल GitHub भण्डार हो, DataHub को LinkedIn संस्करण धेरै भण्डारहरूको संयोजन हो (आन्तरिक रूपमा भनिन्छ। बहुउत्पादहरू)। DataHub इन्टरफेस, मेटाडाटा मोडेल पुस्तकालय, मेटाडाटा वेयरहाउस ब्याकएन्ड सेवा, र स्ट्रिमिङ कार्यहरू LinkedIn मा छुट्टै भण्डारहरूमा रहन्छन्। यद्यपि, खुला स्रोत प्रयोगकर्ताहरूलाई सजिलो बनाउन, हामीसँग DataHub को खुला स्रोत संस्करणको लागि एकल भण्डार छ।

चित्र 1: भण्डारहरू बीच सिंक्रोनाइजेसन LinkedIn 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 हो जसको कुञ्जीहरू खुला स्रोत भण्डारमा लक्षित मोड्युलहरू हुन् र मानहरू LinkedIn भण्डारहरूमा स्रोत मोड्युलहरूको सूची हुन्। खुला स्रोत भण्डारमा कुनै पनि लक्ष्य मोड्युल कुनै पनि स्रोत मोड्युलहरू द्वारा खुवाउन सकिन्छ। स्रोत मोड्युलहरूमा भण्डारहरूको आन्तरिक नामहरू संकेत गर्न, प्रयोग गर्नुहोस् स्ट्रिङ इन्टरपोलेसन बास शैलीमा। मोड्युल-स्तर म्यापिङ फाइल प्रयोग गरेर, उपकरणहरूले सम्बन्धित डाइरेक्टरीहरूमा सबै फाइलहरू स्क्यान गरेर फाइल-स्तर म्यापिङ फाइल सिर्जना गर्दछ।

{
  "${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,
}

फाइल स्तर म्यापिङ स्वचालित रूपमा उपकरणहरू द्वारा सिर्जना गरिएको छ; यद्यपि, यसलाई प्रयोगकर्ताद्वारा म्यानुअल रूपमा पनि अद्यावधिक गर्न सकिन्छ। यो खुला स्रोत भण्डारमा रहेको फाइलमा LinkedIn स्रोत फाइलको १:१ म्यापिङ हो। त्यहाँ फाइल संघहरूको यो स्वचालित सिर्जनासँग सम्बन्धित धेरै नियमहरू छन्:

खुला स्रोतमा लक्षित मोड्युलका लागि बहु स्रोत मोड्युलहरूको अवस्थामा, विवाद उत्पन्न हुन सक्छ, जस्तै उस्तै 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 को आन्तरिक निर्भरता इंजेक्शन फ्रेमवर्क)। Offspring व्यापक रूपमा आन्तरिक कोडबेसहरूमा प्रयोग गरिन्छ किनभने यो गतिशील कन्फिगरेसन प्रबन्ध गर्न मनपर्ने विधि हो। तर यो खुला स्रोत होइन; त्यसैले हामीले खुला स्रोत DataHub को लागि खुला स्रोत विकल्पहरू खोज्न आवश्यक छ।

अन्य कारण पनि छन् । हामीले LinkedIn को आवश्यकताहरूको लागि मेटाडेटा मोडेलमा विस्तारहरू सिर्जना गर्दा, यी विस्तारहरू सामान्यतया LinkedIn को लागि धेरै विशिष्ट हुन्छन् र अन्य वातावरणहरूमा प्रत्यक्ष रूपमा लागू नहुन सक्छ। उदाहरणका लागि, हामीसँग सहभागी ID हरू र अन्य प्रकारका मिल्दो मेटाडेटाहरूका लागि धेरै विशिष्ट लेबलहरू छन्। त्यसोभए, हामीले अब यी विस्तारहरूलाई DataHub को खुला स्रोत मेटाडेटा मोडेलबाट बहिष्कृत गरेका छौं। जब हामी समुदायसँग संलग्न हुन्छौं र तिनीहरूको आवश्यकताहरू बुझ्छौं, हामी यी विस्तारहरूको साझा खुला स्रोत संस्करणहरूमा काम गर्नेछौं जहाँ आवश्यक छ।

प्रयोगको सहजता र खुला स्रोत समुदायको लागि सजिलो अनुकूलनले पनि DataHub को दुई संस्करणहरू बीचको केही भिन्नताहरूलाई प्रेरित गर्‍यो। स्ट्रिम प्रशोधन पूर्वाधारमा भिन्नता यसको राम्रो उदाहरण हो। यद्यपि हाम्रो आन्तरिक संस्करणले व्यवस्थित स्ट्रिम प्रशोधन ढाँचा प्रयोग गर्दछ, हामीले खुला स्रोत संस्करणको लागि निर्मित (स्ट्यान्डअलोन) स्ट्रिम प्रशोधन प्रयोग गर्ने छनौट गर्यौं किनभने यसले अर्को पूर्वाधार निर्भरता सिर्जना गर्नबाट जोगाउँछ।

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

दुई कार्यान्वयनहरू बीचको भिन्नताहरूको पूर्ण सूची तलको तालिकामा दिइएको छ।

उत्पादन विशेषताहरु
LinkedIn DataHub
खुला स्रोत DataHub

समर्थित डाटा निर्माणहरू
1) डाटासेटहरू 2) प्रयोगकर्ताहरू 3) मेट्रिक्स 4) ML सुविधाहरू 5) चार्टहरू 6) ड्यासबोर्डहरू
१) डाटासेट २) प्रयोगकर्ताहरू

डाटासेटहरूको लागि समर्थित मेटाडेटा स्रोतहरू
1) एम्ब्रि २) काउचबेस ३) डालिड्स 4) एस्प्रेसो 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) Pinot 12) प्रेस्टो 12) हुनुहोस् 13) टेराडेटा 13) भेक्टर 14) भेनिस
Hive Kafka RDBMS

पब-उप
LinkedIn काफ्का
संगम काफ्का

स्ट्रिम प्रशोधन
व्यवस्थित
इम्बेडेड (स्ट्यान्डअलोन)

निर्भरता इंजेक्शन र गतिशील कन्फिगरेसन
LinkedIn सन्तान
वसन्त

उपकरण निर्माण गर्नुहोस्
Ligradle (LinkedIn को आन्तरिक Gradle र्यापर)
Gradlew

CI / CD
CRT (LinkedIn को आन्तरिक CI/CD)
TravisCI र डकर हब

मेटाडाटा स्टोरहरू
धेरै GMS वितरित: 1) डाटासेट GMS 2) प्रयोगकर्ता GMS 3) मेट्रिक GMS 4) सुविधा GMS 5) चार्ट/ड्यासबोर्ड GMS
एकल GMS का लागि: १) डाटासेट २) प्रयोगकर्ताहरू

डकर कन्टेनरहरूमा माइक्रो सेवाहरू

डकर अनुप्रयोग तैनाती र वितरणलाई सरल बनाउँछ कन्टेनराइजेशन। DataHub मा सेवाको प्रत्येक भाग खुला स्रोत हो, काफ्का जस्ता पूर्वाधार घटकहरू सहित, Elasticsearch, neo4j и MySQL, यसको आफ्नै डकर छवि छ। डकर कन्टेनरहरू अर्केस्ट्रेट गर्न हामीले प्रयोग गर्यौं डकर रचना गर्नुहोस्.

चित्र २: वास्तुकला 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 को लागि प्रत्येक पूर्वाधार वा माइक्रोसर्भिस डकर कन्टेनरको रूपमा बनाइएको छ, र सम्पूर्ण प्रणाली प्रयोग गरी व्यवस्थित गरिएको छ। डकर-रचना। लोकप्रियता र व्यापकता दिए कुबर्नेट्स, हामी निकट भविष्यमा Kubernetes आधारित समाधान पनि प्रदान गर्न चाहन्छौं।

हामी सार्वजनिक क्लाउड सेवा जस्तै DataHub को तैनाती को लागी एक टर्नकी समाधान प्रदान गर्ने योजना पनि गर्छौं ट्याबनेतृत्व, AWS वा गुगल क्लाउड। Azure मा LinkedIn को माइग्रेसन को हालको घोषणा दिएर, यो मेटाडेटा टोली को आन्तरिक प्राथमिकताहरु संग पङ्क्तिबद्ध हुनेछ।

अन्तिम तर होइन, खुला स्रोत समुदायमा DataHub को प्रारम्भिक अपनाउनेहरू सबैलाई धन्यवाद जसले DataHub alphas मूल्याङ्कन गरेका छन् र हामीलाई समस्याहरू पहिचान गर्न र कागजात सुधार गर्न मद्दत गरेका छन्।

स्रोत: www.habr.com