اوپن سورس ڈیٹا ہب: لنکڈ ان کا میٹا ڈیٹا سرچ اور ڈسکوری پلیٹ فارم

اوپن سورس ڈیٹا ہب: لنکڈ ان کا میٹا ڈیٹا سرچ اور ڈسکوری پلیٹ فارم

آپ کو جس ڈیٹا کی ضرورت ہے اسے تیزی سے تلاش کرنا کسی بھی کمپنی کے لیے ضروری ہے جو ڈیٹا پر مبنی فیصلے کرنے کے لیے بڑی مقدار میں ڈیٹا پر انحصار کرتی ہے۔ یہ نہ صرف ڈیٹا استعمال کرنے والوں (بشمول تجزیہ کاروں، مشین لرننگ ڈویلپرز، ڈیٹا سائنسدانوں، اور ڈیٹا انجینئرز) کی پیداواری صلاحیت کو متاثر کرتا ہے، بلکہ اس کا براہ راست اثر آخر پروڈکٹس پر بھی پڑتا ہے جو معیاری مشین لرننگ (ML) پائپ لائن پر منحصر ہیں۔ مزید برآں، مشین لرننگ پلیٹ فارمز کو نافذ کرنے یا بنانے کی طرف رجحان فطری طور پر یہ سوال اٹھاتا ہے: اندرونی طور پر خصوصیات، ماڈلز، میٹرکس، ڈیٹا سیٹس وغیرہ کو دریافت کرنے کے لیے آپ کا طریقہ کیا ہے؟

اس مضمون میں ہم اس بارے میں بات کریں گے کہ ہم نے اوپن لائسنس کے تحت ڈیٹا سورس کیسے شائع کیا۔ ڈیٹا ہب پراجیکٹ کے ابتدائی دنوں سے شروع ہونے والے ہمارے میٹا ڈیٹا کی تلاش اور دریافت کے پلیٹ فارم میں کہاں کیسے؟. LinkedIn DataHub کے اپنے ورژن کو اوپن سورس ورژن سے الگ رکھتا ہے۔ ہم یہ بتاتے ہوئے شروع کریں گے کہ ہمیں دو الگ الگ ترقیاتی ماحول کیوں درکار ہیں، پھر اوپن سورس WhereHows کو استعمال کرنے کے ابتدائی طریقوں پر تبادلہ خیال کریں گے اور DataHub کے ہمارے اندرونی (پروڈکشن) ورژن کا موازنہ کریں گے۔ GitHub کے. ہم دونوں ذخیروں کو مطابقت پذیر رکھنے کے لیے اوپن سورس اپ ڈیٹس کو آگے بڑھانے اور وصول کرنے کے لیے اپنے نئے خودکار حل کے بارے میں تفصیلات بھی شیئر کریں گے۔ آخر میں، ہم اوپن سورس ڈیٹا ہب کا استعمال شروع کرنے کے بارے میں ہدایات فراہم کریں گے اور اس کے فن تعمیر پر مختصراً گفتگو کریں گے۔

WhereHows اب ایک DataHub ہے!

LinkedIn کی میٹا ڈیٹا ٹیم نے پہلے پیش کیا تھا۔ ڈیٹا ہب (WhereHows کا جانشین)، LinkedIn کی تلاش اور میٹا ڈیٹا دریافت کرنے والا پلیٹ فارم، اور اسے کھولنے کے مشترکہ منصوبے۔ اس اعلان کے کچھ دیر بعد، ہم نے DataHub کا الفا ورژن جاری کیا اور اسے کمیونٹی کے ساتھ شیئر کیا۔ اس کے بعد سے، ہم نے ذخیرہ اندوزی میں مسلسل تعاون کیا ہے اور دلچسپی رکھنے والے صارفین کے ساتھ مل کر سب سے زیادہ درخواست کردہ خصوصیات کو شامل کرنے اور مسائل کو حل کرنے کے لیے کام کیا ہے۔ اب ہم باضابطہ ریلیز کا اعلان کرتے ہوئے خوش ہیں۔ GitHub پر ڈیٹا ہب.

اوپن سورس اپروچز

WhereHows، ڈیٹا تلاش کرنے کے لیے LinkedIn کا اصل پورٹل اور یہ کہاں سے آتا ہے، ایک داخلی پروجیکٹ کے طور پر شروع ہوا؛ میٹا ڈیٹا ٹیم نے اسے کھولا۔ 2016 میں سورس کوڈ. اس کے بعد سے، ٹیم نے ہمیشہ دو مختلف کوڈ بیسز کو برقرار رکھا ہے — ایک اوپن سورس کے لیے اور ایک LinkedIn کے اندرونی استعمال کے لیے — کیونکہ LinkedIn کے استعمال کے معاملات کے لیے تیار کردہ تمام پروڈکٹ فیچرز عام طور پر وسیع تر سامعین پر لاگو نہیں ہوتے تھے۔ مزید برآں، WhereHows میں کچھ اندرونی انحصار (انفراسٹرکچر، لائبریریز وغیرہ) ہیں جو اوپن سورس نہیں ہیں۔ اس کے بعد کے سالوں میں، WhoHows بہت سے تکرار اور ترقی کے چکروں سے گزرے، جس سے دونوں کوڈ بیسز کو ہم آہنگی میں رکھنا ایک بڑا چیلنج بن گیا۔ میٹا ڈیٹا ٹیم نے اندرونی اور اوپن سورس ڈویلپمنٹ کو ہم آہنگی میں رکھنے کی کوشش کرنے کے لیے کئی سالوں میں مختلف طریقے آزمائے ہیں۔

پہلی کوشش: "اوپن سورس پہلے"

ہم نے ابتدائی طور پر ایک "اوپن سورس فرسٹ" ڈویلپمنٹ ماڈل کی پیروی کی، جہاں زیادہ تر ترقی اوپن سورس ریپوزٹری میں ہوتی ہے اور اندرونی تعیناتی کے لیے تبدیلیاں کی جاتی ہیں۔ اس نقطہ نظر کے ساتھ مسئلہ یہ ہے کہ کوڈ کو ہمیشہ GitHub پر دھکیل دیا جاتا ہے اس سے پہلے کہ اس کا اندرونی طور پر مکمل جائزہ لیا جائے۔ جب تک اوپن سورس ریپوزٹری سے تبدیلیاں نہیں کی جاتیں اور ایک نئی داخلی تعیناتی نہیں کی جاتی، ہمیں پروڈکشن کا کوئی مسئلہ نہیں ملے گا۔ ناقص تعیناتی کی صورت میں مجرم کا تعین کرنا بھی بہت مشکل تھا کیونکہ بیچوں میں تبدیلیاں کی جاتی تھیں۔

مزید برآں، اس ماڈل نے نئی خصوصیات تیار کرتے وقت ٹیم کی پیداواری صلاحیت کو کم کر دیا جس کے لیے تیزی سے تکرار کی ضرورت تھی، کیونکہ اس نے تمام تبدیلیوں کو پہلے اوپن سورس ریپوزٹری میں دھکیلنے اور پھر اندرونی ذخیرے میں دھکیلنے پر مجبور کیا۔ پروسیسنگ کے وقت کو کم کرنے کے لیے، پہلے اندرونی ریپوزٹری میں مطلوبہ فکس یا تبدیلی کی جا سکتی تھی، لیکن یہ ایک بہت بڑا مسئلہ بن گیا جب ان تبدیلیوں کو اوپن سورس ریپوزٹری میں ضم کرنے کی بات آئی کیونکہ دونوں ریپوزٹریز کی مطابقت پذیری سے باہر تھے۔

یہ ماڈل مکمل خصوصیات والے کسٹم ویب ایپلیکیشنز کے مقابلے میں مشترکہ پلیٹ فارمز، لائبریریوں یا بنیادی ڈھانچے کے منصوبوں کے لیے نافذ کرنا بہت آسان ہے۔ مزید برآں، یہ ماڈل ان منصوبوں کے لیے مثالی ہے جو پہلے دن سے اوپن سورس شروع کرتے ہیں، لیکن WhoHows کو مکمل طور پر اندرونی ویب ایپلیکیشن کے طور پر بنایا گیا تھا۔ تمام اندرونی انحصارات کو مکمل طور پر ختم کرنا واقعی مشکل تھا، لہذا ہمیں اندرونی کانٹے کو برقرار رکھنے کی ضرورت تھی، لیکن اندرونی کانٹے کو برقرار رکھنا اور زیادہ تر اوپن سورس تیار کرنا کافی کام نہیں کر سکا۔

دوسری کوشش: "اندرونی پہلی"

**دوسری کوشش کے طور پر، ہم ایک "اندرونی فرسٹ" ڈویلپمنٹ ماڈل پر چلے گئے، جہاں زیادہ تر ترقی اندرون ملک ہوتی ہے اور اوپن سورس کوڈ میں مستقل بنیادوں پر تبدیلیاں کی جاتی ہیں۔ اگرچہ یہ ماڈل ہمارے استعمال کے معاملے کے لیے بہترین ہے، لیکن اس میں موروثی مسائل ہیں۔ تمام اختلافات کو براہ راست اوپن سورس ریپوزٹری کی طرف دھکیلنا اور پھر بعد میں انضمام کے تنازعات کو حل کرنے کی کوشش کرنا ایک آپشن ہے، لیکن یہ وقت طلب ہے۔ زیادہ تر معاملات میں ڈویلپر ہر بار اپنے کوڈ کا جائزہ لینے پر ایسا نہ کرنے کی کوشش کرتے ہیں۔ نتیجے کے طور پر، یہ بیچوں میں بہت کم کثرت سے کیا جائے گا، اور اس طرح بعد میں انضمام کے تنازعات کو حل کرنا مزید مشکل ہو جائے گا۔

تیسری بار اس نے کام کیا!

مذکورہ بالا دو ناکام کوششوں کے نتیجے میں WhoHows GitHub ذخیرہ ایک طویل عرصے تک پرانا پڑا۔ ٹیم نے پروڈکٹ کی خصوصیات اور فن تعمیر کو بہتر بنانا جاری رکھا، تاکہ LinkedIn کے لئے WhereHows کا اندرونی ورژن اوپن سورس ورژن سے زیادہ جدید بن گیا۔ یہاں تک کہ اس کا ایک نیا نام تھا - DataHub۔ پچھلی ناکام کوششوں کی بنیاد پر، ٹیم نے ایک توسیع پذیر، طویل مدتی حل تیار کرنے کا فیصلہ کیا۔

کسی بھی نئے اوپن سورس پروجیکٹ کے لیے، LinkedIn کی اوپن سورس ٹیم ایک ایسے ڈویلپمنٹ ماڈل کو مشورہ دیتی ہے اور اس کی حمایت کرتی ہے جس میں پروجیکٹ کے ماڈیول مکمل طور پر اوپن سورس میں تیار کیے جاتے ہیں۔ ورژن شدہ نمونے ایک عوامی ذخیرے میں تعینات کیے جاتے ہیں اور پھر ان کا استعمال کرتے ہوئے اندرونی لنکڈ ان آرٹفیکٹ میں دوبارہ چیک کیا جاتا ہے۔ بیرونی لائبریری کی درخواست (ELR). اس ترقیاتی ماڈل کی پیروی نہ صرف ان لوگوں کے لیے اچھا ہے جو اوپن سورس استعمال کرتے ہیں، بلکہ اس کے نتیجے میں زیادہ ماڈیولر، قابل توسیع، اور پلگ ایبل فن تعمیر بھی ہوتا ہے۔

تاہم، ڈیٹا ہب جیسی بالغ بیک اینڈ ایپلیکیشن کو اس حالت تک پہنچنے کے لیے کافی وقت درکار ہوگا۔ اس سے تمام داخلی انحصارات کو مکمل طور پر ختم کرنے سے پہلے اوپن سورسنگ کے مکمل طور پر کام کرنے والے عمل درآمد کے امکان کو بھی روک دیا جاتا ہے۔ اسی لیے ہم نے ایسے ٹولز تیار کیے ہیں جو اوپن سورس کے تعاون کو تیز تر اور بہت کم تکلیف کے ساتھ کرنے میں ہماری مدد کرتے ہیں۔ یہ حل میٹا ڈیٹا ٹیم (DataHub ڈویلپر) اور اوپن سورس کمیونٹی دونوں کو فائدہ پہنچاتا ہے۔ مندرجہ ذیل حصے اس نئے انداز پر بحث کریں گے۔

اوپن سورس پبلشنگ آٹومیشن

اوپن سورس ڈیٹا ہب کے لیے میٹا ڈیٹا ٹیم کا تازہ ترین نقطہ نظر ایک ایسا ٹول تیار کرنا ہے جو اندرونی کوڈ بیس اور اوپن سورس ریپوزٹری کو خود بخود ہم آہنگ کرے۔ اس ٹول کٹ کی اعلیٰ سطحی خصوصیات میں شامل ہیں:

1. LinkedIn کوڈ کو اوپن سورس سے مطابقت پذیر بنائیں، اسی طرح rsync.
2. لائسنس ہیڈر جنریشن، جیسا کہ اپاچی چوہا.
3. اندرونی کمٹ لاگز سے خودکار طور پر اوپن سورس کمٹ لاگز تیار کریں۔
4. اندرونی تبدیلیوں کو روکیں جو اوپن سورس کی تعمیرات کو توڑتی ہیں۔ انحصار کی جانچ.

مندرجہ ذیل ذیلی حصے مذکورہ بالا افعال کا جائزہ لیں گے جن میں دلچسپ مسائل ہیں۔

ماخذ کوڈ کی مطابقت پذیری۔

DataHub کے اوپن سورس ورژن کے برعکس، جو کہ ایک واحد GitHub ذخیرہ ہے، DataHub کا LinkedIn ورژن متعدد ذخیروں کا مجموعہ ہے (جسے اندرونی طور پر کہا جاتا ہے۔ ملٹی پروڈکٹس)۔ DataHub انٹرفیس، میٹا ڈیٹا ماڈل لائبریری، میٹا ڈیٹا ویئر ہاؤس بیک اینڈ سروس، اور اسٹریمنگ جابز LinkedIn پر الگ الگ ریپوزٹریز میں رہتی ہیں۔ تاہم، اوپن سورس صارفین کے لیے آسان بنانے کے لیے، ہمارے پاس ڈیٹا ہب کے اوپن سورس ورژن کے لیے ایک ہی ذخیرہ ہے۔

شکل 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 میپنگ ہے۔ فائل ایسوسی ایشن کی اس خودکار تخلیق سے وابستہ کئی اصول ہیں:

• اوپن سورس میں ٹارگٹ ماڈیول کے لیے متعدد سورس ماڈیولز کی صورت میں، تنازعات پیدا ہو سکتے ہیں، جیسے کہ وہی ایف کیو سی این، ایک سے زیادہ سورس ماڈیول میں موجود ہے۔ تنازعات کے حل کی حکمت عملی کے طور پر، ہمارے ٹولز "آخری ایک جیت" کے اختیار پر ڈیفالٹ ہوتے ہیں۔
• "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 کے پبلک ورژن اور LinkedIn سرورز پر پروڈکشن ورژن کے درمیان فرق درج کریں گے، اور ان اختلافات کی وجوہات کی وضاحت کریں گے۔

تضاد کا ایک ذریعہ اس حقیقت سے پیدا ہوتا ہے کہ ہمارے پروڈکشن ورژن میں کوڈ پر انحصار ہے جو ابھی تک اوپن سورس نہیں ہے، جیسے کہ LinkedIn's Offspring (LinkedIn کا اندرونی انحصار انجیکشن فریم ورک)۔ داخلی کوڈبیسز میں اولاد کو وسیع پیمانے پر استعمال کیا جاتا ہے کیونکہ یہ متحرک کنفیگریشن کے انتظام کے لیے ترجیحی طریقہ ہے۔ لیکن یہ اوپن سورس نہیں ہے۔ لہذا ہمیں اوپن سورس ڈیٹا ہب کے لیے اوپن سورس متبادل تلاش کرنے کی ضرورت تھی۔

اس کی اور وجوہات بھی ہیں۔ جیسا کہ ہم LinkedIn کی ضروریات کے لیے میٹا ڈیٹا ماڈل میں ایکسٹینشنز بناتے ہیں، یہ ایکسٹینشن عام طور پر LinkedIn کے لیے بہت مخصوص ہوتے ہیں اور ہو سکتا ہے کہ دوسرے ماحول پر براہ راست لاگو نہ ہوں۔ مثال کے طور پر، ہمارے پاس حصہ لینے والے IDs اور دیگر قسم کے مماثل میٹا ڈیٹا کے لیے بہت مخصوص لیبل ہیں۔ لہذا، ہم نے اب ان ایکسٹینشنز کو DataHub کے اوپن سورس میٹا ڈیٹا ماڈل سے خارج کر دیا ہے۔ جیسا کہ ہم کمیونٹی کے ساتھ مشغول ہیں اور ان کی ضروریات کو سمجھتے ہیں، ہم ان ایکسٹینشنز کے مشترکہ اوپن سورس ورژن پر کام کریں گے جہاں ضرورت ہوگی۔

اوپن سورس کمیونٹی کے لیے استعمال میں آسانی اور آسان موافقت نے بھی DataHub کے دو ورژن کے درمیان کچھ فرق کو متاثر کیا۔ اسٹریم پروسیسنگ انفراسٹرکچر میں فرق اس کی ایک اچھی مثال ہے۔ اگرچہ ہمارا داخلی ورژن ایک منظم اسٹریم پروسیسنگ فریم ورک کا استعمال کرتا ہے، ہم نے اوپن سورس ورژن کے لیے بلٹ ان (اسٹینڈ اکیلا) اسٹریم پروسیسنگ استعمال کرنے کا انتخاب کیا ہے کیونکہ یہ انفراسٹرکچر پر ایک اور انحصار پیدا کرنے سے گریز کرتا ہے۔

فرق کی ایک اور مثال ایک سے زیادہ GMSs کے بجائے اوپن سورس کے نفاذ میں ایک GMS (جنرلائزڈ میٹا ڈیٹا اسٹور) کا ہونا ہے۔ GMA (Generalized Metadata Architecture) DataHub کے بیک اینڈ آرکیٹیکچر کا نام ہے، اور GMS GMA کے تناظر میں میٹا ڈیٹا اسٹور ہے۔ GMA ایک بہت ہی لچکدار فن تعمیر ہے جو آپ کو ہر ڈیٹا کنسٹرکٹ (جیسے ڈیٹا سیٹس، صارفین وغیرہ) کو اس کے اپنے میٹا ڈیٹا اسٹور میں تقسیم کرنے، یا ایک ہی میٹا ڈیٹا اسٹور میں متعدد ڈیٹا کنسٹرکٹس کو اسٹور کرنے کی اجازت دیتا ہے جب تک کہ رجسٹری میں ڈیٹا اسٹرکچر میپنگ پر مشتمل ہو۔ GMS اپ ڈیٹ ہو گیا ہے۔ استعمال میں آسانی کے لیے، ہم نے ایک واحد GMS مثال کا انتخاب کیا جو اوپن سورس DataHub میں تمام مختلف ڈیٹا کنسٹرکٹس کو اسٹور کرتا ہے۔

دو نفاذ کے درمیان فرق کی ایک مکمل فہرست نیچے دی گئی جدول میں دی گئی ہے۔

مصنوعات کی خصوصیات
لنکڈ ان ڈیٹا ہب
اوپن سورس ڈیٹا ہب

معاون ڈیٹا کنسٹرکٹس
1) ڈیٹا سیٹس 2) صارفین 3) میٹرکس 4) ایم ایل فیچرز 5) چارٹس 6) ڈیش بورڈز
1) ڈیٹا سیٹ 2) صارفین

ڈیٹا سیٹس کے لیے معاون میٹا ڈیٹا ذرائع
1) ایمبری 2) کاؤچ بیس 3) ڈالیڈس 4) یسپریسو 5) HDFS 6) Hive 7) کافکا 8) MongoDB 9) MySQL 10) اوریکل 11) پنٹ 12) پریسٹو 12) ہو 13) ٹیراڈیٹا 13) ویکٹر 14) وینس
Hive Kafka RDBMS

پب ذیلی
لنکڈ ان کافکا
سنگم کافکا

سٹریم پروسیسنگ
منظم
ایمبیڈڈ (اسٹینڈ تنہا)

انحصار انجیکشن اور متحرک ترتیب
لنکڈ ان اولاد
موسم بہار

ٹولنگ بنائیں
Ligradle (LinkedIn کا اندرونی Gradle ریپر)
گریڈلو

CI / CD
CRT (LinkedIn کا اندرونی CI/CD)
TravisCI اور ڈوکر حب

میٹا ڈیٹا اسٹورز
تقسیم شدہ متعدد GMS: 1) ڈیٹا سیٹ GMS 2) صارف GMS 3) میٹرک GMS 4) فیچر GMS 5) چارٹ/ڈیش بورڈ GMS
سنگل GMS برائے: 1) ڈیٹا سیٹس 2) صارفین

ڈوکر کنٹینرز میں مائیکرو سروسز

میں Docker کے ساتھ درخواست کی تعیناتی اور تقسیم کو آسان بناتا ہے۔ کنٹینرائزیشن. DataHub میں سروس کا ہر حصہ اوپن سورس ہے، بشمول انفراسٹرکچر کے اجزاء جیسے کافکا، Elasticsearch, neo4j и MySQL، اس کی اپنی ڈوکر امیج ہے۔ ڈوکر کنٹینرز کو آرکیسٹریٹ کرنے کے لیے ہم نے استعمال کیا۔ Docker Compose.

شکل 2: فن تعمیر ڈیٹا ہب *آزاد مصدر**

آپ اوپر کی تصویر میں ڈیٹا ہب کے اعلیٰ سطحی فن تعمیر کو دیکھ سکتے ہیں۔ بنیادی ڈھانچے کے اجزاء کے علاوہ، اس میں چار مختلف ڈوکر کنٹینرز ہیں:

datahub-gms: میٹا ڈیٹا اسٹوریج سروس

datahub-frontend: درخواست کھیلیں، DataHub انٹرفیس کی خدمت کر رہا ہے۔

datahub-mce-consumer: درخواست کافکا اسٹریمز، جو میٹا ڈیٹا چینج ایونٹ (MCE) اسٹریم کا استعمال کرتا ہے اور میٹا ڈیٹا اسٹور کو اپ ڈیٹ کرتا ہے۔

datahub-mae-consumer: درخواست کافکا اسٹریمز، جو میٹا ڈیٹا آڈٹ ایونٹ اسٹریم (MAE) کا استعمال کرتا ہے اور سرچ انڈیکس اور گراف ڈیٹا بیس بناتا ہے۔

اوپن سورس ریپوزٹری دستاویزات اور اصل ڈیٹا ہب بلاگ پوسٹ مختلف خدمات کے افعال کے بارے میں مزید تفصیلی معلومات پر مشتمل ہے۔

DataHub پر CI/CD اوپن سورس ہے۔

اوپن سورس ڈیٹا ہب ریپوزٹری استعمال کرتا ہے۔ TravisCI مسلسل انضمام اور ڈوکر حب مسلسل تعیناتی کے لیے۔ دونوں میں اچھا گٹ ہب انضمام ہے اور سیٹ اپ کرنا آسان ہے۔ کمیونٹی یا نجی کمپنیوں کے ذریعہ تیار کردہ زیادہ تر اوپن سورس انفراسٹرکچر کے لیے (جیسے میں confluent)، Docker امیجز کو کمیونٹی کے استعمال میں آسانی کے لیے Docker Hub میں بنایا اور لگایا جاتا ہے۔ Docker Hub میں پائی جانے والی کوئی بھی Docker امیج ایک سادہ کمانڈ کے ساتھ آسانی سے استعمال کی جا سکتی ہے۔ ڈاکر ھیںچو.

DataHub اوپن سورس ریپوزٹری کے ساتھ ہر عہد کے ساتھ، تمام Docker امیجز خود بخود بن جاتی ہیں اور "تازہ ترین" ٹیگ کے ساتھ Docker Hub میں لگائی جاتی ہیں۔ اگر ڈوکر حب کو کچھ کے ساتھ ترتیب دیا گیا ہے۔ ریگولر ایکسپریشن شاخوں کا نام دینا، اوپن سورس ریپوزٹری میں موجود تمام ٹیگز بھی ڈوکر ہب میں متعلقہ ٹیگ کے ناموں کے ساتھ جاری کیے گئے ہیں۔

ڈیٹا ہب کا استعمال

DataHub ترتیب دینا بہت آسان ہے اور تین آسان مراحل پر مشتمل ہے:

1. اوپن سورس ریپوزٹری کو کلون کریں اور فوری آغاز کے لیے فراہم کردہ ڈوکر کمپوز اسکرپٹ کا استعمال کرتے ہوئے تمام ڈوکر کنٹینرز کو ڈوکر کمپوز کے ساتھ چلائیں۔
2. کمانڈ لائن ٹول کا استعمال کرتے ہوئے ریپوزٹری میں فراہم کردہ نمونہ ڈیٹا ڈاؤن لوڈ کریں جو بھی فراہم کیا گیا ہے۔
3. اپنے براؤزر میں ڈیٹا ہب کو براؤز کریں۔

فعال طور پر ٹریک کیا گیا۔ گیٹر چیٹ فوری سوالات کے لیے بھی ترتیب دیا گیا ہے۔ صارف گٹ ہب ریپوزٹری میں براہ راست مسائل بھی بنا سکتے ہیں۔ سب سے اہم بات، ہم تمام آراء اور تجاویز کا خیرمقدم کرتے ہیں اور ان کی تعریف کرتے ہیں!

مستقبل کے لئے منصوبوں

فی الحال، اوپن سورس ڈیٹا ہب کے لیے ہر انفراسٹرکچر یا مائیکرو سروس کو ڈوکر کنٹینر کے طور پر بنایا گیا ہے، اور پورا سسٹم اس کے استعمال سے ترتیب دیا گیا ہے۔ ڈوکر کمپوز. مقبولیت اور وسیع پیمانے پر دیکھتے ہوئے Kubernetes، ہم مستقبل قریب میں کوبرنیٹس پر مبنی حل بھی فراہم کرنا چاہیں گے۔

ہم عوامی کلاؤڈ سروس پر ڈیٹا ہب کی تعیناتی کے لیے ٹرنکی حل فراہم کرنے کا بھی ارادہ رکھتے ہیں جیسے Azure, AWS یا گوگل کلاؤڈ. Azure میں LinkedIn کی منتقلی کے حالیہ اعلان کے پیش نظر، یہ میٹا ڈیٹا ٹیم کی داخلی ترجیحات کے مطابق ہوگا۔

آخری لیکن کم از کم، اوپن سورس کمیونٹی میں DataHub کے تمام ابتدائی اختیار کرنے والوں کا شکریہ جنہوں نے DataHub الفا کی درجہ بندی کی ہے اور مسائل کی نشاندہی کرنے اور دستاویزات کو بہتر بنانے میں ہماری مدد کی ہے۔

ماخذ: www.habr.com