د خلاصې سرچینې ډیټا هب: د لینکډین میټاډاټا لټون او کشف پلیټ فارم

د خلاصې سرچینې ډیټا هب: د لینکډین میټاډاټا لټون او کشف پلیټ فارم

د هغه معلوماتو موندل چې تاسو ورته اړتیا لرئ ژر تر ژره د هر شرکت لپاره اړین دي چې د ډیټا لخوا پرمخ وړل شوي پریکړې کولو لپاره په لوی مقدار ډیټا تکیه کوي. دا نه یوازې د ډیټا کاروونکو تولید باندې اغیزه کوي (د تحلیل کونکو ، د ماشین زده کړې پراختیا کونکو ، ډیټا ساینس پوهانو ، او ډیټا انجینرانو په شمول) ، بلکه دا په پای محصولاتو مستقیم اغیزه هم لري چې د کیفیت ماشین زده کړې (ML) پایپ لاین پورې اړه لري. سربیره پردې ، د ماشین زده کړې پلیټ فارمونو پلي کولو یا رامینځته کولو په لور تمایل په طبیعي ډول دا پوښتنه راپورته کوي: د داخلي ځانګړتیاو ، ماډلونو ، میټریکونو ، ډیټاسیټونو او نورو موندلو لپاره ستاسو میتود څه دی؟

پدې مقاله کې به موږ د دې په اړه وغږیږو چې څنګه موږ د خلاص جواز لاندې د معلوماتو سرچینه خپره کړه DataHub زموږ د میټاډاټا لټون او کشف پلیټ فارم کې ، د پروژې له لومړیو ورځو څخه پیل کیږي چیرته څنګه. LinkedIn د ډیټا هب خپل نسخه د خلاصې سرچینې نسخې څخه جلا ساتي. موږ به د دې تشریح کولو سره پیل وکړو چې ولې موږ دوه جلا پراختیایي چاپیریالونو ته اړتیا لرو، بیا د خلاصې سرچینې کارولو لپاره د لومړنیو لارو چارو په اړه بحث وکړو چیرته چې څنګه او زموږ د ډیټا هب داخلي (تولید) نسخه د نسخې سره پرتله کړئ. GitHub. موږ به د خلاصې سرچینې تازه معلوماتو فشارولو او ترلاسه کولو لپاره زموږ د نوي اتومات حل په اړه توضیحات هم شریک کړو ترڅو دواړه ذخیره په همغږي کې وساتو. په نهایت کې ، موږ به د خلاصې سرچینې ډیټا هب کارولو څرنګوالي په اړه لارښوونې چمتو کړو او د دې جوړښت په لنډ ډول بحث وکړو.

چیرته اوس یو ډیټا هب دی!

د LinkedIn میټاډاټا ټیم دمخه وړاندې شوی DataHub (WhereHows ته ځای ناستی)، د LinkedIn د لټون او میټاډاټا کشف پلیټ فارم، او د هغې د پرانستلو لپاره یې پالنونه شریک کړل. د دې اعلان څخه لږ وروسته، موږ د DataHub الفا نسخه خپره کړه او د ټولنې سره یې شریکه کړه. له هغه وخت راهیسې، موږ په دوامداره توګه په ذخیره کې مرسته کړې او د لیوالتیا کاروونکو سره یې کار کړی ترڅو ډیری غوښتل شوي ځانګړتیاوې اضافه کړي او ستونزې حل کړي. موږ اوس خوښ یو چې د رسمي خوشې کیدو اعلان وکړو په GitHub کې ډیټا هب.

د خلاصې سرچینې لارې چارې

چیرته هاؤس، د لینکډین اصلي پورټل د معلوماتو موندلو لپاره او له کوم ځای څخه راځي، د داخلي پروژې په توګه پیل شوی؛ د میټاډاټا ټیم دا خلاص کړ په 2016 کې د سرچینې کوډ. له هغه وخت راهیسې، ټیم تل دوه مختلف کوډبیسونه ساتلي دي - یو د خلاصې سرچینې لپاره او بل د LinkedIn د داخلي کارونې لپاره - ځکه چې د LinkedIn کارولو قضیو لپاره د محصول ټولې ځانګړتیاوې په عمومي ډول د پراخو لیدونکو لپاره د تطبیق وړ ندي. برسیره پردې، چیرته هاوس ځینې داخلي انحصارونه لري (بنسټیز، کتابتونونه، او نور) چې خلاصې سرچینې ندي. په هغه کلونو کې چې تعقیب شوي، چیرته هاوس د ډیری تکرارونو او پراختیا دورې څخه تیریږي، د دوو کوډبیسونو په ترکیب کې ساتل یوه لویه ننګونه ده. د میټاډاټا ټیم په تیرو کلونو کې مختلف طریقې هڅه کړې ترڅو د داخلي او خلاصې سرچینې پراختیا په همغږۍ کې وساتي.

لومړی هڅه: "لومړی خلاص سرچینه"

موږ په پیل کې د "خلاصې سرچینې لومړی" پرمختیا ماډل تعقیب کړ، چیرې چې ډیری پراختیا د خلاصې سرچینې ذخیره کې واقع کیږي او د داخلي ګمارلو لپاره بدلونونه رامینځته کیږي. د دې تګلارې سره ستونزه دا ده چې کوډ تل د GitHub ته فشار ورکول کیږي مخکې لدې چې دا په بشپړ ډول داخلي بیاکتنه وشي. تر هغه چې د خلاصې سرچینې ذخیره څخه بدلونونه رامینځته نشي او نوی داخلي ګمارل کیږي ، موږ به د تولید کومه مسله ونه موندلو. د ضعیف ګمارنې په صورت کې، د مجرم پیژندل هم خورا ستونزمن وو ځکه چې په بستونو کې بدلونونه راوستل شوي.

برسیره پردې، دې ماډل د ټیم تولید کم کړ کله چې نوي ځانګړتیاوې رامینځته کړي چې چټک تکرار ته اړتیا لري، ځکه چې دا ټول بدلونونه اړ کړي چې لومړی د خلاصې سرچینې ذخیره ته واړول شي او بیا داخلي ذخیره ته واړول شي. د پروسس کولو وخت کمولو لپاره، اړین اصلاحات یا بدلون لومړی په داخلي زیرمه کې ترسره کیدی شي، مګر دا یوه لویه ستونزه شوه کله چې دا بدلونونه بیرته د خلاصې سرچینې ذخیره کې یوځای کولو لپاره راغلل ځکه چې دوه زیرمې له همغږۍ څخه بهر وې.

دا ماډل د ګډو پلیټ فارمونو، کتابتونونو، یا زیربناوو پروژو لپاره پلي کول خورا اسانه دي په پرتله د بشپړ ځانګړي دودیز ویب غوښتنلیکونو لپاره. برسیره پردې، دا ماډل د هغو پروژو لپاره مثالی دی چې د لومړۍ ورځې څخه خلاصې سرچینې پیل کوي، مګر چیرته هاوس د بشپړ داخلي ویب غوښتنلیک په توګه جوړ شوی و. دا واقعیا ستونزمنه وه چې ټول داخلي انحصارونه په بشپړ ډول خلاص کړئ ، نو موږ اړتیا درلوده چې داخلي فورک وساتو ، مګر د داخلي فورک ساتل او ډیری خلاصې سرچینې رامینځته کول خورا کار نه و.

دوهمه هڅه: "لومړی داخلي"

** د دویمې هڅې په توګه، موږ د "داخلي لومړي" پراختیا ماډل ته لاړ، چیرې چې ډیری پرمختګ په کور کې واقع کیږي او په منظم ډول د خلاصې سرچینې کوډ کې بدلونونه راځي. که څه هم دا ماډل زموږ د کارونې قضیې لپاره غوره دی، دا اصلي ستونزې لري. په مستقیم ډول د خلاصې سرچینې ذخیره ته ټول توپیرونه فشار ورکول او بیا وروسته د ادغام شخړو حل کولو هڅه کول یو اختیار دی ، مګر دا وخت نیسي. په ډیری قضیو کې پراختیا کونکي هڅه کوي هرکله چې دوی د دوی کوډ بیاکتنه وکړي دا کار ونه کړي. د پایلې په توګه، دا به په کم وخت کې، په بستونو کې ترسره شي، او په دې توګه وروسته د انضمام شخړو حل کول خورا ستونزمن کوي.

دریم ځل دا کار وکړ!

پورته ذکر شوي دوه ناکامې هڅې د دې لامل شوې چې د چیرې هاوس ګیټ هب ذخیره د اوږدې مودې لپاره له نیټې پاتې وي. ټیم د محصول ب featuresو او جوړښت ته وده ورکولو ته دوام ورکړ ، ترڅو د LinkedIn لپاره د WhereHows داخلي نسخه د خلاصې سرچینې نسخې څخه خورا پرمختللې شوه. دا حتی یو نوی نوم درلود - DataHub. د پخوانیو ناکامو هڅو پراساس، ټیم پریکړه وکړه چې د توزیع وړ، اوږدمهاله حل رامینځته کړي.

د هرې نوې خلاصې سرچینې پروژې لپاره، د LinkedIn د خلاصې سرچینې ټیم د پراختیا ماډل ته مشوره ورکوي او ملاتړ کوي په کوم کې چې د پروژې ماډلونه په بشپړه توګه په خلاصې سرچینې کې رامینځته شوي. نسخه شوي اثار په عامه ذخیره کې ځای په ځای شوي او بیا د داخلي لینکډین آثارو په کارولو سره بیرته چیک شوي د بهرنۍ کتابتون غوښتنه (ELR). د دې پراختیا ماډل تعقیب نه یوازې د هغو کسانو لپاره ښه دی څوک چې خلاصې سرچینې کاروي ، بلکه د ډیر ماډلر ، توسع وړ ، او پلګ وړ جوړښت پایله هم لري.

په هرصورت، یو بالغ شاته پای غوښتنلیک لکه ډیټا هب به دې حالت ته د رسیدو لپاره د پام وړ وخت ته اړتیا ولري. دا د خلاصې سرچینې د بشپړ کاري پلي کولو امکان هم مخنیوی کوي مخکې لدې چې ټول داخلي انحصارونه په بشپړ ډول خلاص شوي وي. له همدې امله موږ داسې وسیلې رامینځته کړې چې موږ سره مرسته کوي د خلاصې سرچینې مرستې ګړندۍ او د ډیر کم درد سره. دا حل د میټاډاټا ټیم (DataHub پراختیا کونکي) او د خلاصې سرچینې ټولنې دواړو ته ګټه رسوي. لاندې برخې به د دې نوې طریقې په اړه بحث وکړي.

د خلاصې سرچینې خپرولو اتوماتیک

د خلاصې سرچینې ډیټا هب ته د میټاډاټا ټیم وروستۍ تګلاره د یوې وسیلې رامینځته کول دي چې په اوتومات ډول داخلي کوډبیس او د خلاصې سرچینې ذخیره ترکیب کوي. د دې وسیلې د لوړې کچې ځانګړتیاوې عبارت دي له:

1. د لینکډین کوډ له خلاصې سرچینې سره همغږي کړئ، ورته rsync.
2. د جواز سرلیک نسل، ورته ورته اپاچي موږک.
3. په اتوماتيک ډول د داخلي ژمنې لاګونو څخه د خلاصې سرچینې ژمنې لاګونه رامینځته کړئ.
4. د داخلي بدلونونو مخه ونیسئ چې د خلاصې سرچینې جوړونه ماتوي د انحصار ازموینه.

لاندې فرعي برخې به پورته ذکر شوي دندې ته پام وکړي کوم چې په زړه پوري ستونزې لري.

د سرچینې کوډ همغږي کول

د ډیټا هب د خلاصې سرچینې نسخې برخلاف ، کوم چې یو واحد GitHub ذخیره ده ، د ډیټا هب لینک شوي نسخه د ډیری ذخیره کولو ترکیب دی (د داخلي په نوم یادیږي) څو محصولات). د ډیټا هب انٹرفیس ، د میټاډاټا ماډل کتابتون ، د میټاډاټا ګودام بیکینډ خدمت ، او د سټینګ دندې په لینکډین کې په جلا ذخیره کې ژوند کوي. په هرصورت، د خلاصې سرچینې کاروونکو لپاره د اسانه کولو لپاره، موږ د ډیټا هب د خلاصې سرچینې نسخې لپاره یو واحد ذخیره لرو.

شکل 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 سرچینې فایل 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 عامه نسخه او په LinkedIn سرورونو کې د تولید نسخه ترمنځ توپیرونه لیست کړو، او د دې توپیرونو دلیلونه تشریح کړو.

د توپیر یوه سرچینه د دې حقیقت څخه رامینځته کیږي چې زموږ د تولید نسخه په کوډ باندې انحصار لري چې لاهم خلاص سرچینه نه ده ، لکه د لینکډین اولاد (د لینکډین داخلي انحصار انجیکشن چوکاټ). اولاد په پراخه کچه په داخلي کوډبیسونو کې کارول کیږي ځکه چې دا د متحرک ترتیب اداره کولو لپاره غوره طریقه ده. مګر دا خلاص سرچینه نه ده؛ نو موږ د خلاصې سرچینې ډیټا هب لپاره د خلاصې سرچینې بدیل موندلو ته اړتیا درلوده.

نور لاملونه هم شته. لکه څنګه چې موږ د لینکډین اړتیاو لپاره د میټاډاټا ماډل ته توسیعونه رامینځته کوو ، دا توسیعونه عموما د لینکډین لپاره خورا ځانګړي دي او ممکن په مستقیم ډول په نورو چاپیریالونو کې پلي نشي. د مثال په توګه، موږ د ګډون کونکي IDs او د ورته میټاډاټا نورو ډولونو لپاره خورا ځانګړي لیبلونه لرو. نو، موږ اوس دا توسیعونه د ډیټا هب د خلاصې سرچینې میټاډاټا ماډل څخه خارج کړي دي. لکه څنګه چې موږ د ټولنې سره ښکیل یو او د دوی اړتیاوې درک کوو، موږ به د اړتیا په صورت کې د دې تمدیدونو په عام خلاصې سرچینې نسخو کار وکړو.

د خلاصې سرچینې ټولنې لپاره د کارولو اسانتیا او اسانه موافقت هم د ډیټا هب د دوه نسخو ترمینځ ځینې توپیرونه هڅولي. د جریان پروسس کولو زیربنا کې توپیر د دې ښه مثال دی. که څه هم زموږ داخلي نسخه د مدیریت شوي جریان پروسس کولو چوکاټ کاروي، موږ د پرانیستې سرچینې نسخې لپاره د جوړ شوي (استیناد) جریان پروسس کولو لپاره غوره کړی ځکه چې دا د بل زیربنا انحصار رامینځته کولو مخه نیسي.

د توپیر بله بیلګه د ډیری GMSs پرځای د خلاصې سرچینې پلي کولو کې د واحد GMS (عمومي میټاډاټا سټور) درلودل دي. GMA (عمومي میټاډاټا آرکیټیکچر) د ډیټا هب لپاره د شاته پای جوړښت نوم دی ، او GMS د GMA په شرایطو کې د میټاډاټا پلورنځی دی. GMA یو ډیر انعطاف منونکی جوړښت دی چې تاسو ته اجازه درکوي هر ډیټا جوړښت (د بیلګې په توګه ډیټاسیټونه ، کارونکي او نور) په خپل میټاډاټا پلورنځي کې توزیع کړئ ، یا ډیری ډیټا جوړښتونه په یو واحد میټاډاټا پلورنځي کې ذخیره کړئ تر هغه چې راجسټري پکې د ډیټا جوړښت نقشه ولري. GMS تازه شوی. د کارونې اسانتیا لپاره، موږ یو واحد GMS مثال غوره کړ چې د خلاصې سرچینې ډیټا هب کې ټول مختلف ډیټا جوړښتونه ذخیره کوي.

د دوو تطبیقونو ترمنځ د توپیرونو بشپړ لیست په لاندې جدول کې وړاندې شوی.

د تولیداتو ځانګړتیاوی
LinkedIn DataHub
د خلاصې سرچینې ډیټا هب

د ملاتړ شوي ډیټا جوړښتونه
1) ډیټا سیټونه 2) کاروونکي 3) میټریک 4) ML ځانګړتیاوې 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

Pub-sub
LinkedIn کافکا
ملغلره کافکا

جریان پروسس کول
اداره
امبیډ شوی (مستقیم)

د انحصار انجکشن او متحرک ترتیب
LinkedIn اولادونه
د پسرلي

د اوزار جوړول
Ligradle (د لینکډین داخلي ګرډل ریپر)
ګرډلو

CI / CD
CRT (د لینکډین داخلي CI/CD)
TravisCI او ډاکر هب

د میټاډاټا پلورنځی
توزیع شوي ډیری GMS: 1) ډیټاسیټ GMS 2) د کارونکي GMS 3) میټریک GMS 4) فیچر GMS 5) چارټ/ډشبورډ GMS
د دې لپاره واحد GMS: 1) ډیټاسیټس 2) کاروونکي

په ډاکر کانټینرونو کې کوچني خدمتونه

ډاکر د غوښتنلیک پلي کول او توزیع ساده کوي کانتینر کول. په DataHub کې د خدماتو هره برخه خلاص سرچینه ده، په شمول د زیربناوو برخې لکه کافکا، الیسټسیکټ, neo4j и مای، د خپل ډاکر عکس لري. د ډاکر کانټینرونو تنظیم کولو لپاره موږ کارولی ډاکر جوړ کړئ.

شکل 2: معمارۍ DataHub *خلاصه سرچینه*

تاسو کولی شئ په پورته عکس کې د ډیټا هب د لوړې کچې جوړښت وګورئ. د زیربناوو برخو سربیره، دا څلور مختلف ډاکر کانټینرونه لري:

datahub-gms: د میټاډاټا ذخیره کولو خدمت

datahub-frontend: غوښتنلیک playد ډیټا هب انٹرفیس ته خدمت کول.

datahub-mce-consumer: غوښتنلیک د کافکا جریان، کوم چې د میټاډاټا بدلون پیښې (MCE) جریان کاروي او د میټاډاټا پلورنځی تازه کوي.

datahub-mae-consumer: غوښتنلیک د کافکا جریان، کوم چې د میټاډاټا پلټنې پیښې جریان (MAE) کاروي او د لټون شاخص او ګراف ډیټابیس رامینځته کوي.

د خلاصې سرچینې ذخیره کولو اسناد او اصلي DataHub بلاګ پوسټ د مختلفو خدماتو دندو په اړه نور تفصيلي معلومات لري.

په ډیټا هب کې CI/CD خلاص سرچینه ده

د خلاصې سرچینې ډیټا هب ذخیره کاروي TravisCI د دوامداره ادغام لپاره او ډاکر هب د دوامداره ګمارنې لپاره. دواړه ښه GitHub ادغام لري او تنظیم کول اسانه دي. د ډیری خلاصې سرچینې زیربنا لپاره چې د ټولنې یا خصوصي شرکتونو لخوا رامینځته شوي (د مثال په توګه متواضع) ، د ډاکر عکسونه رامینځته شوي او د ټولنې لخوا د کارولو اسانتیا لپاره د ډاکر هب ته ځای په ځای شوي. په ډاکر هب کې موندل شوي هر ډول ډاکر عکس په اسانۍ سره د ساده کمانډ سره کارول کیدی شي ډاکر کشول.

د ډیټا هب خلاصې سرچینې ذخیره کولو ته د هرې ژمنې سره ، د ډاکر ټول عکسونه په اوتومات ډول جوړ شوي او د "وروستي" ټاګ سره ډاکر هب ته ځای په ځای شوي. که د ډاکر هب د ځینې سره تنظیم شوی وي د منظم بیان څانګو نومول، د خلاصې سرچینې ذخیره کې ټول ټاګونه هم په ډاکر هب کې د ورته ټاګ نومونو سره خوشې شوي.

د ډیټا هب کارول

د ډیټا هب تنظیم کول خورا ساده دی او د دریو ساده ګامونو څخه جوړ دی:

1. د خلاصې سرچینې ذخیره کلون کړئ او د ګړندي پیل لپاره د چمتو شوي ډاکر - کمپوز سکریپټ په کارولو سره ټول ډاکر کانټینرونه د ډاکر - کمپوز سره پرمخ وړئ.
2. د کمانډ لاین وسیلې په کارولو سره په ذخیره کې چمتو شوي نمونې ډیټا ډاونلوډ کړئ چې چمتو شوی هم دی.
3. په خپل براوزر کې ډیټا هب براوز کړئ.

په فعاله توګه تعقیب شوی ګیټ چیټ د چټکو پوښتنو لپاره هم ترتیب شوی. کارونکي کولی شي مسلې په مستقیم ډول د GitHub ذخیره کې رامینځته کړي. تر ټولو مهم، موږ د ټولو نظریاتو او وړاندیزونو هرکلی کوو او ستاینه کوو!

د راتلونکي لپاره پلانونه

اوس مهال، د خلاصې سرچینې ډیټا هب لپاره هر زیربنا یا مایکرو سرویس د ډاکر کانټینر په توګه جوړ شوی، او ټول سیسټم د کارولو سره تنظیم شوی. ډاکر - بڼه. د شهرت او پراخوالي په پام کې نیولو سره کوبنیټس، موږ غواړو په نږدې راتلونکي کې د کبرنیټ پراساس حل چمتو کړو.

موږ دا پلان هم لرو چې په عامه کلاوډ خدمت کې د ډیټا هب ځای په ځای کولو لپاره د ټرنکي حل چمتو کړو لکه لاجوردو, AWS او یا ګوګل کلاډ. Azure ته د LinkedIn د مهاجرت وروستي اعلان ته په پام سره، دا به د میټاډاټا ټیم داخلي لومړیتوبونو سره سمون ولري.

په نهایت کې ، د خلاصې سرچینې ټولنې کې د ډیټا هب له ټولو لومړیو اخیستونکو څخه مننه چې د ډیټا هب الفا درجه یې کړې او موږ سره یې د مسلو پیژندلو او د اسنادو ښه کولو کې مرسته کړې.

سرچینه: www.habr.com