اوپن سورس DataHub: LinkedIn's Metadata Search and Discovery Platform
ڊيٽا ڳولڻ جيڪو توهان کي جلدي گهربل آهي ڪنهن به ڪمپني لاءِ ضروري آهي جيڪا ڊيٽا جي وڏي مقدار تي انحصار ڪري ٿي ڊيٽا تي ٻڌل فيصلا ڪرڻ لاءِ. اهو نه رڳو ڊيٽا استعمال ڪندڙن جي پيداوار تي اثر انداز ٿئي ٿو (جنهن ۾ تجزيه نگار، مشين لرننگ ڊولپرز، ڊيٽا سائنسدان، ۽ ڊيٽا انجنيئر شامل آهن)، پر اهو پڻ آخري پروڊڪٽس تي سڌو اثر رکي ٿو جيڪي معيار جي مشين لرننگ (ML) پائپ لائن تي منحصر آهن. اضافي طور تي، مشين لرننگ پليٽ فارم کي لاڳو ڪرڻ يا تعمير ڪرڻ جو رجحان قدرتي طور تي سوال اٿاري ٿو: اندروني طور تي خاصيتون، ماڊل، ميٽرڪس، ڊيٽا سيٽ، وغيره ڳولڻ لاء توهان جو طريقو ڇا آهي.
هن آرٽيڪل ۾ اسين ڳالهائينداسين ته ڪيئن اسان هڪ کليل لائسنس تحت ڊيٽا جو ذريعو شايع ڪيو اسان جي ميٽا ڊيٽا جي ڳولا ۽ دريافت جي پليٽ فارم ۾، منصوبي جي شروعاتي ڏينهن کان شروع ٿيندڙ . LinkedIn DataHub جي پنهنجي ورزن کي کليل ذريعو ورزن کان الڳ رکي ٿو. اسان وضاحت ڪندي شروع ڪنداسين ته ڇو اسان کي ٻه الڳ ترقي واري ماحول جي ضرورت آهي، پوء اوپن سورس کي استعمال ڪرڻ جي شروعاتي طريقن تي بحث ڪيو ويو آهي ڪٿي ڪيئن ۽ اسان جي اندروني (پيداوار) واري ڊيٽا هب جي ورزن سان موازنہ ڪريو. . اسان اسان جي نئين خودڪار حل بابت تفصيل پڻ شيئر ڪنداسين اوپن سورس تازه ڪاريون حاصل ڪرڻ ۽ وصول ڪرڻ لاءِ ٻنهي ذخيرن کي هم وقت سازي ۾ رکڻ لاءِ. آخرڪار، اسان هدايتون ڏينداسين ته ڪيئن شروع ڪجي اوپن سورس DataHub استعمال ڪرڻ ۽ مختصر طور تي ان جي فن تعمير تي بحث ڪيو وڃي.
ڪٿي هاؤس هاڻي هڪ DataHub آهي!
LinkedIn جي ميٽا ڊيٽا ٽيم اڳ ۾ پيش ڪئي وئي (WhereHows جو جانشين)، LinkedIn جي ڳولا ۽ ميٽا ڊيٽا دريافت پليٽ فارم، ۽ ان کي کولڻ لاءِ شيئر ڪيل منصوبا. هن اعلان کان ٿوري دير بعد، اسان DataHub جو الفا ورزن جاري ڪيو ۽ ان کي ڪميونٽي سان شيئر ڪيو. ان کان پوء، اسان مسلسل مخزن ۾ حصو ورتو آهي ۽ دلچسپي استعمال ڪندڙن سان گڏ ڪم ڪيو آهي سڀ کان وڌيڪ گهربل خاصيتون شامل ڪرڻ ۽ مسئلا حل ڪرڻ لاء. اسان هاڻي خوش آهيون ته سرڪاري رليز جو اعلان ڪريون .
اوپن سورس اپروچز
WhereHows, LinkedIn جو اصل پورٽل ڊيٽا ڳولڻ لاءِ ۽ اهو ڪٿان اچي ٿو، هڪ اندروني منصوبي جي طور تي شروع ڪيو ويو؛ ميٽاداٽا ٽيم ان کي کوليو . ان وقت کان وٺي، ٽيم هميشه ٻن مختلف ڪوڊ بيسز کي برقرار رکيو آهي- هڪ اوپن سورس لاءِ ۽ هڪ LinkedIn جي اندروني استعمال لاءِ- جيئن ته نه سڀئي پراڊڪٽ خاصيتون جيڪي LinkedIn استعمال جي ڪيسن لاءِ تيار ڪيون ويون آهن، عام طور تي وسيع سامعين لاءِ لاڳو نه ٿيون ٿين. اضافي طور تي، WhereHows وٽ ڪجھ اندروني انحصار آھن (انفراسٽرڪچر، لائبريريون، وغيره) جيڪي کليل ذريعو نه آھن. ايندڙ سالن ۾، ڪٿي هاؤس ڪيترن ئي ورهاڱي ۽ ترقي جي چڪر مان گذريو، ٻن ڪوڊ بيس کي هم وقت سازي ۾ رکڻ هڪ وڏو چئلينج آهي. ميٽا ڊيٽا ٽيم ڪيترن سالن کان مختلف طريقن جي ڪوشش ڪئي آهي ته جيئن اندروني ۽ اوپن سورس ڊولپمينٽ کي هم وقت سازي ۾ رکڻ جي ڪوشش ڪئي وڃي.
پهرين ڪوشش: "اوپن سورس پهرين"
اسان شروعاتي طور تي "اوپن سورس فرسٽ" ڊولپمينٽ ماڊل جي پيروي ڪئي، جتي سڀ کان وڌيڪ ترقي اوپن سورس ريپوزٽري ۾ ٿيندي آهي ۽ اندروني ڊيپلائيمينٽ لاءِ تبديليون ڪيون وينديون آهن. هن طريقي سان مسئلو اهو آهي ته ڪوڊ هميشه GitHub ڏانهن ڌڪيو ويندو آهي ان کان اڳ جو مڪمل طور تي اندروني طور تي جائزو ورتو ويو آهي. جيستائين اوپن سورس مخزن مان تبديليون نه ڪيون وڃن ۽ نئين اندروني ترتيب ڏني وڃي، اسان کي ڪو به پيداوار مسئلا نه ملندا. ناقص مقرري جي صورت ۾، مجرم جو تعين ڪرڻ به ڏاڍو ڏکيو هو، ڇاڪاڻ ته بيچ ۾ تبديليون ڪيون ويون.
اضافي طور تي، هن ماڊل ٽيم جي پيداوار کي گهٽائي ڇڏيو جڏهن نئين خاصيتن کي ترقي ڪرڻ لاء تيز رفتار جي ضرورت آهي، ڇاڪاڻ ته اهو سڀني تبديلين کي مجبور ڪيو ويو پهريون ڀيرو هڪ اوپن سورس مخزن ڏانهن ڌڪيو وڃي ۽ پوء اندروني مخزن ڏانهن ڌڪيو وڃي. پروسيسنگ جي وقت کي گھٽائڻ لاءِ، گھربل درستي يا تبديلي پھريائين اندروني مخزن ۾ ٿي سگھي ٿي، پر اھو ھڪڙو وڏو مسئلو بڻجي ويو جڏھن انھن تبديلين کي واپس اوپن سورس ريپوزٽري ۾ ضم ڪرڻ لاءِ آيو ڇو ته ٻئي ريپوزٽريون هم وقت سازيءَ کان ٻاھر ھيون.
هي ماڊل مڪمل خصوصيت رکندڙ ڪسٽم ويب ايپليڪيشنن جي ڀيٽ ۾ گڏيل پليٽ فارمن، لائبريرين، يا انفراسٽرڪچر منصوبن لاءِ لاڳو ڪرڻ تمام آسان آهي. اضافي طور تي، هي ماڊل پروجيڪٽ لاء مثالي آهي جيڪي اوپن سورس شروع ڪن ٿا پهرين ڏينهن کان، پر ڪٿي هاؤس مڪمل طور تي اندروني ويب ايپليڪيشن جي طور تي ٺاهيو ويو. تمام اندروني انحصار کي مڪمل طور تي ختم ڪرڻ واقعي ڏکيو هو، تنهنڪري اسان کي اندروني ڪانٽو رکڻ جي ضرورت هئي، پر اندروني ڪانٽو رکڻ ۽ گهڻو ڪري اوپن سورس کي ترقي ڪرڻ بلڪل ڪم نه ڪيو.
ٻي ڪوشش: ”اندر اول“
** ٻي ڪوشش جي طور تي، اسان هڪ "اندروني پهرين" ڊولپمينٽ ماڊل ڏانهن منتقل ٿي ويا آهيون، جتي اڪثر ترقي گهر ۾ ٿيندي آهي ۽ اوپن سورس ڪوڊ ۾ باقاعده بنياد تي تبديليون ڪيون وينديون آهن. جيتوڻيڪ هي ماڊل اسان جي استعمال جي صورت ۾ بهترين موزون آهي، ان ۾ موروثي مسئلا آهن. سڌو سنئون سڀني اختلافن کي اوپن سورس مخزن ڏانهن ڌڪڻ ۽ پوءِ بعد ۾ ضم ٿيڻ واري تڪرار کي حل ڪرڻ جي ڪوشش ڪرڻ هڪ آپشن آهي، پر اهو وقت وٺندڙ آهي. ڊولپر اڪثر ڪيسن ۾ اهو نه ڪرڻ جي ڪوشش ڪندا آهن هر وقت اهي انهن جي ڪوڊ جو جائزو وٺندا آهن. نتيجي طور، اھو گھڻو گھٽ ڪيو ويندو، بيچز ۾، ۽ اھڙيءَ طرح بعد ۾ ضم ٿيڻ واري تڪرار کي حل ڪرڻ وڌيڪ مشڪل بڻائيندو.
ٽيون ڀيرو اهو ڪم ڪيو!
مٿي ذڪر ڪيل ٻن ناڪام ڪوششن جي نتيجي ۾ ڪٿي هاؤس GitHub مخزن هڪ ڊگهي وقت تائين تاريخ کان ٻاهر آهي. ٽيم پراڊڪٽ جي خاصيتن ۽ فن تعمير کي بهتر ڪرڻ جاري رکي، انهي ڪري ته ڪٿي هاؤس فار LinkedIn جو اندروني ورزن اوپن سورس ورزن کان وڌيڪ ترقي يافته بڻجي ويو. اهو پڻ هڪ نئون نالو هو - DataHub. پوئين ناڪام ڪوششن جي بنياد تي، ٽيم هڪ اسپيبلبل، ڊگھي مدت جي حل کي ترقي ڪرڻ جو فيصلو ڪيو.
ڪنهن به نئين اوپن سورس پروجيڪٽ لاءِ، LinkedIn جي اوپن سورس ٽيم هڪ ڊولپمينٽ ماڊل جي صلاح ۽ سپورٽ ڪري ٿي جنهن ۾ پروجيڪٽ جا ماڊل مڪمل طور تي اوپن سورس ۾ ٺاهيا ويا آهن. ورزن ٿيل نمونن کي عوامي مخزن تي لڳايو ويو آهي ۽ پوءِ واپس چيڪ ڪيو ويو اندروني LinkedIn artifact ۾ استعمال ڪندي . هن ڊولپمينٽ ماڊل جي پيروي ڪرڻ نه رڳو انهن لاءِ سٺو آهي جيڪي اوپن سورس استعمال ڪن ٿا، پر اهو پڻ نتيجو آهي وڌيڪ ماڊلر، وسعت وارو، ۽ پلگ ايبل آرڪيٽيڪچر.
جڏهن ته، هڪ بالغ پٺتي-ايپليڪيشن جهڙوڪ DataHub هن حالت تائين پهچڻ لاء هڪ اهم وقت جي ضرورت هوندي. اهو پڻ کليل سورسنگ جي امڪان کي ختم ڪري ٿو مڪمل طور تي ڪم ڪندڙ عمل درآمد کان اڳ سڀني اندروني انحصار کي مڪمل طور تي ختم ڪيو ويو آهي. اهو ئي سبب آهي ته اسان اوزار ٺاهيا آهن جيڪي اسان جي مدد ڪن ٿا اوپن سورس تعاون تيزيءَ سان ۽ تمام گهٽ تڪليف سان. هي حل ٻنهي ميٽاداٽا ٽيم (DataHub ڊولپر) ۽ اوپن سورس ڪميونٽي کي فائدو ڏئي ٿو. هيٺيان حصا هن نئين طريقي تي بحث ڪندا.
اوپن سورس پبلشنگ آٽوميشن
اوپن سورس DataHub ڏانهن ميٽاداٽا ٽيم جو جديد طريقو هڪ اوزار تيار ڪرڻ آهي جيڪو خود بخود اندروني ڪوڊ بيس ۽ اوپن سورس ريپوزٽري کي هم وقت سازي ڪري ٿو. هن ٽول ڪٽ جي اعلي سطحي خاصيتون شامل آهن:
- LinkedIn ڪوڊ کي اوپن سورس کان/کان، ساڳيو .
- لائسنس هيڊر نسل، ساڳي طرح .
- اندروني ڪمٽ لاگز مان خودڪار طور تي اوپن سورس ڪمٽ لاگز ٺاھيو.
- اندروني تبديلين کي روڪيو جيڪو ٽوڙيو کليل ذريعو تعميرات ذريعي .
هيٺ ڏنل ذيلي ڀاڱا مٿي ذڪر ڪيل ڪمن ۾ شامل ٿيندا جن ۾ دلچسپ مسئلا آهن.
ماخذ ڪوڊ هم وقت سازي
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 آهي جنهن جون ڪنجيون آهن ٽارگيٽ ماڊلز جي اوپن سورس ريپوزٽري ۾ ۽ قيمتون آهن لنڪڊ ان مخزن ۾ ماخذ ماڊلز جي فهرست. اوپن سورس ريپوزٽري ۾ ڪو به ٽارگيٽ ماڊل ڪنهن به سورس ماڊلز جي ذريعي فيڊ ڪري سگهجي ٿو. ذريعن جي ماڊلز ۾ مخزن جا اندروني نالا ظاهر ڪرڻ لاءِ، استعمال ڪريو باش انداز ۾. ماڊل-سطح ميپنگ فائل استعمال ڪندي، اوزار لاڳاپيل ڊائريڪٽرن ۾ سڀني فائلن کي اسڪين ڪندي فائل-سطح ميپنگ فائل ٺاهي ٿو.
{
"${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 ميپنگ هڪ LinkedIn سورس فائل کي اوپن سورس ريپوزٽري ۾ فائل ڏانهن. فائل ايسوسيئيشن جي هن خودڪار تخليق سان لاڳاپيل ڪيترائي قاعدا آهن:
- اوپن سورس ۾ ٽارگيٽ ماڊل لاءِ گھڻن ذريعن جي ماڊلز جي صورت ۾، تڪرار پيدا ٿي سگھي ٿو، مثال طور ساڳيو هڪ کان وڌيڪ ماخذ ماڊل ۾ موجود آهي. تڪرار جي حل واري حڪمت عملي جي طور تي، اسان جا اوزار ڊفالٽ "آخري هڪ جيتري" اختيار تي.
- "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 جي عوامي ورزن ۽ LinkedIn سرورز تي پيداوار واري ورزن جي وچ ۾ فرق جي فهرست ڪنداسين، ۽ انهن اختلافن جا سبب بيان ڪنداسين.
تفاوت جو هڪ ذريعو ان حقيقت مان ٿئي ٿو ته اسان جي پيداوار واري ورزن ۾ ڪوڊ تي انحصار آهي جيڪو اڃا کليل ذريعو نه آهي، جهڙوڪ LinkedIn's Offspring (LinkedIn جو اندروني انحصار انجيڪشن فريم ورڪ). اولاد وڏي پيماني تي اندروني ڪوڊ بيس ۾ استعمال ڪيو ويندو آهي ڇاڪاڻ ته اهو متحرڪ ترتيب جي انتظام لاء ترجيح طريقو آهي. پر اهو کليل ذريعو نه آهي؛ تنهنڪري اسان کي اوپن سورس DataHub لاءِ اوپن سورس متبادل ڳولڻ جي ضرورت آهي.
ٻيا به سبب آهن. جيئن ته اسان LinkedIn جي ضرورتن لاءِ ميٽاڊيٽا ماڊل جي ايڪسٽينشن ٺاهيندا آهيون، اهي واڌايون خاص طور تي LinkedIn لاءِ خاص هونديون آهن ۽ شايد سڌي طرح ٻين ماحولن تي لاڳو نه ٿيون ٿين. مثال طور، اسان وٽ حصو وٺندڙ IDs ۽ ٻين قسمن جي ملندڙ ميٽا ڊيٽا لاءِ تمام خاص ليبل آھن. تنهن ڪري، اسان هاڻي انهن واڌارن کي DataHub جي اوپن سورس ميٽا ڊيٽا ماڊل مان خارج ڪيو آهي. جيئن اسان ڪميونٽي سان مشغول آهيون ۽ انهن جي ضرورتن کي سمجهون ٿا، اسان انهن ايڪسٽينشن جي عام اوپن سورس ورزن تي ڪم ڪنداسين جتي ضرورت هجي.
اوپن سورس ڪميونٽي لاءِ استعمال جي آسان ۽ آسان موافقت پڻ DataHub جي ٻن ورزن جي وچ ۾ ڪجهه فرقن کي متاثر ڪيو. اسٽريم پروسيسنگ انفراسٽرڪچر ۾ فرق هن جو هڪ سٺو مثال آهي. جيتوڻيڪ اسان جو اندروني ورزن هڪ منظم اسٽريم پروسيسنگ فريم ورڪ استعمال ڪري ٿو، اسان اوپن سورس ورزن لاءِ بلٽ ان (اسٽينڊ اڪيلو) اسٽريم پروسيسنگ استعمال ڪرڻ جو انتخاب ڪيو آهي ڇاڪاڻ ته اهو هڪ ٻيو انفراسٽرڪچر انحصار پيدا ڪرڻ کان پاسو ڪري ٿو.
فرق جو هڪ ٻيو مثال هڪ واحد GMS (جنرلائزڊ ميٽاداٽا اسٽور) آهي هڪ کليل ذريعو عمل ۾ ڪيترن ئي GMSs جي بدران. GMA (Generalized Metadata Architecture) DataHub لاءِ پٺتي پيل فن تعمير جو نالو آھي، ۽ GMS GMA جي حوالي سان ميٽاڊيٽا اسٽور آھي. GMA هڪ تمام لچڪدار فن تعمير آهي جيڪو توهان کي اجازت ڏئي ٿو ته هر ڊيٽا جي تعمير (مثال طور ڊيٽا سيٽ، استعمال ڪندڙ، وغيره) کي ان جي پنهنجي ميٽا ڊيٽا اسٽور ۾ ورهائي، يا هڪ واحد ميٽا ڊيٽا اسٽور ۾ ڪيترن ئي ڊيٽا تعميرات کي ذخيرو ڪري جيستائين رجسٽري ۾ ڊيٽا جي جوڙجڪ جي ميپنگ تي مشتمل آهي. GMS اپڊيٽ ٿيل آهي. استعمال جي آسانيءَ لاءِ، اسان ھڪڙو واحد GMS مثال چونڊيو آھي جيڪو ذخيرو ڪري ٿو سڀني مختلف ڊيٽا ٺاھڻ کي اوپن سورس DataHub ۾.
ٻن عملن جي وچ ۾ فرق جي مڪمل فهرست ھيٺ ڏنل جدول ۾ ڏنل آھي.
مصنوعات جون خاصيتون
LinkedIn DataHub
اوپن سورس DataHub
سپورٽ ٿيل ڊيٽا تعميرات
1) ڊيٽا سيٽس 2) استعمال ڪندڙ 3) ميٽرڪس 4) ايم ايل خاصيتون 5) چارٽس 6) ڊيش بورڊ
1) ڊيٽا سيٽ 2) استعمال ڪندڙ
ڊيٽا سيٽن لاءِ سپورٽ ميٽا ڊيٽا ذريعن
1) 2) ڪوچ بيس 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) پريسٽو 12) 13) ٽيراڊيٽا 13) ویکٹر 14)
Hive Kafka RDBMS
پب-ذيلي
سنگت ڪافڪا
وهڪرو پروسيسنگ
منظم
شامل ٿيل (اڪيلو)
انحصار انجکشن ۽ متحرڪ ترتيب
LinkedIn اولاد
اوزار ٺاھيو
Ligradle (LinkedIn جي اندروني Gradle لفافي)
CI/CD
CRT (LinkedIn جي اندروني CI/CD)
۽
Metadata اسٽور
ورهايل گھڻن GMS: 1) ڊيٽا سيٽ GMS 2) صارف GMS 3) ميٽرڪ GMS 4) خصوصيت GMS 5) چارٽ / ڊيش بورڊ GMS
سنگل GMS لاءِ: 1) ڊيٽا سيٽس 2) استعمال ڪندڙ
Docker ڪنٽينرز ۾ مائڪرو سروسز
ايپليڪيشن جي ترتيب ۽ تقسيم کي آسان بڻائي ٿو . DataHub ۾ خدمت جو هر حصو کليل ذريعو آهي، جنهن ۾ انفراسٽرڪچر جا حصا شامل آهن جهڙوڪ ڪافڪا، , и , ان جي پنهنجي Docker تصوير آهي. ڊاڪر ڪنٽينرز کي ترتيب ڏيڻ لاءِ اسان استعمال ڪيو .
شڪل 2: آرڪيٽيڪچر DataHub *کليل ذريعو**
مٿي ڏنل تصوير ۾ توهان DataHub جي اعلي سطحي فن تعمير کي ڏسي سگهو ٿا. انفراسٹرڪچر جي اجزاء کان علاوه، ان ۾ چار مختلف ڊاکر ڪنٽينرز آهن:
datahub-gms: ميٽا ڊيٽا اسٽوريج سروس
datahub-frontend: ايپليڪيشن , DataHub انٽرفيس جي خدمت ڪندي.
datahub-mce-صارف: ايپليڪيشن ، جيڪو استعمال ڪري ٿو ميٽاڊيٽا تبديلي ايونٽ (MCE) وهڪرو ۽ تازه ڪاري ڪري ٿو ميٽا ڊيٽا اسٽور.
datahub-mae-صارف: ايپليڪيشن ، جيڪو ميٽا ڊيٽا آڊٽ ايونٽ اسٽريم (MAE) استعمال ڪري ٿو ۽ سرچ انڊيڪس ۽ گراف ڊيٽابيس ٺاهي ٿو.
اوپن سورس مخزن جي دستاويز ۽ مختلف خدمتن جي ڪمن بابت وڌيڪ تفصيلي معلومات تي مشتمل آهي.
CI/CD DataHub تي کليل ذريعو آهي
کليل ذريعو DataHub مخزن استعمال ڪري ٿو مسلسل انضمام لاء ۽ مسلسل لڳائڻ لاء. ٻنهي وٽ سٺو GitHub انضمام آهي ۽ سيٽ ڪرڻ آسان آهن. اڪثر اوپن سورس انفراسٽرڪچر لاءِ جيڪي ڪميونٽي يا پرائيويٽ ڪمپنين پاران تيار ڪيا ويا آهن (مثال طور. )، ڊاڪر تصويرون ٺاهيا ويا آهن ۽ ڊاڪر هب ڏانهن موڪليا ويا آهن ڪميونٽي طرفان استعمال جي آسانيء لاء. Docker Hub ۾ مليل ڪو به ڊڪر تصوير آساني سان استعمال ڪري سگھجي ٿو سادي حڪم سان .
DataHub اوپن سورس مخزن جي هر وابستگي سان، سڀئي ڊاڪر تصويرون خودڪار طور تي ٺاهيا ويا آهن ۽ ڊاڪر هب تي "تازو" ٽيگ سان لڳايو ويو آهي. جيڪڏهن Docker Hub ڪجهه سان ترتيب ڏنل آهي ، اوپن سورس مخزن ۾ سڀئي ٽيگ پڻ جاري ڪيا ويا آهن لاڳاپيل ٽيگ نالن سان ڊڪر حب ۾.
DataHub استعمال ڪندي
تمام سادو آهي ۽ ٽن سادي قدمن تي مشتمل آهي:
- اوپن سورس ريپوزٽري کي ڪلون ڪريو ۽ تمام ڊاڪر ڪنٽينرز کي ڊاڪر ڪمپوز سان گڏ ھلايو ڊاڪر ڪمپوز اسڪرپٽ استعمال ڪندي جلدي شروعات لاءِ.
- ڪمانڊ لائن ٽول استعمال ڪندي مخزن ۾ مهيا ڪيل نموني ڊيٽا ڊائون لوڊ ڪريو جيڪا پڻ مهيا ڪئي وئي آهي.
- براؤز ڪريو DataHub توهان جي برائوزر ۾.
فعال طور تي ٽريڪ ٿيل جلدي سوالن لاء پڻ ترتيب ڏنل. صارف پڻ مسئلا پيدا ڪري سگھن ٿا سڌو GitHub مخزن ۾. سڀ کان وڌيڪ اهم، اسان ڀليڪار ڪيون ٿا ۽ سڀني راءِ ۽ تجويزن کي ساراهيو!
مستقبل لاء منصوبا
في الحال، اوپن سورس DataHub لاءِ هر انفراسٽرڪچر يا مائڪرو سروس ڊاڪر ڪنٽينر جي طور تي ٺهيل آهي، ۽ سمورو نظام ترتيب ڏنل آهي . ڏنو مقبوليت ۽ وسيع ، اسان پڻ مهيا ڪرڻ چاهيون ٿا Kubernetes جي بنياد تي حل ويجهي مستقبل ۾.
اسان هڪ عوامي ڪلائوڊ سروس تي DataHub کي ترتيب ڏيڻ لاء هڪ ٽرنڪي حل مهيا ڪرڻ جو منصوبو پڻ ڪيو آهي جهڙوڪ , يا . تازي اعلان کي ڏنو ويو آهي LinkedIn جي لڏپلاڻ جو Azure ڏانهن، هي ميٽا ڊيٽا ٽيم جي اندروني ترجيحن سان ترتيب ڏيندو.
آخري نه پر گهٽ ۾ گهٽ، اوپن سورس ڪميونٽي ۾ DataHub جي سڀني ابتدائي اپنائڻ وارن جي مهرباني جن DataHub الفا جي درجه بندي ڪئي ۽ اسان جي مدد ڪئي مسئلن جي نشاندهي ڪرڻ ۽ دستاويز کي بهتر ڪرڻ ۾.
جو ذريعو: www.habr.com