ღია წყარო DataHub: LinkedIn-ის მეტამონაცემების ძიება და აღმოჩენის პლატფორმა

ღია წყარო DataHub: LinkedIn-ის მეტამონაცემების ძიება და აღმოჩენის პლატფორმა

თქვენთვის საჭირო მონაცემების სწრაფად პოვნა აუცილებელია ნებისმიერი კომპანიისთვის, რომელიც ეყრდნობა მონაცემთა დიდ რაოდენობას მონაცემების საფუძველზე გადაწყვეტილებების მისაღებად. ეს არა მხოლოდ გავლენას ახდენს მონაცემთა მომხმარებელთა პროდუქტიულობაზე (ანალიტიკოსების, მანქანათმცოდნეობის დეველოპერების, მონაცემთა მეცნიერების და მონაცემთა ინჟინრების ჩათვლით), არამედ პირდაპირ გავლენას ახდენს საბოლოო პროდუქტებზე, რომლებიც დამოკიდებულნი არიან ხარისხის მანქანათმცოდნეობის (ML) მილსადენზე. გარდა ამისა, მანქანათმცოდნეობის პლატფორმების დანერგვისა ან შექმნის ტენდენცია ბუნებრივად აჩენს კითხვას: რა არის თქვენი მეთოდი შინაგანად ფუნქციების, მოდელების, მეტრიკის, მონაცემთა ნაკრების და ა.შ.

ამ სტატიაში ვისაუბრებთ იმაზე, თუ როგორ გამოვაქვეყნეთ მონაცემთა წყარო ღია ლიცენზიით DataHub ჩვენს მეტამონაცემების ძიებისა და აღმოჩენის პლატფორმაში, დაწყებული პროექტის პირველივე დღეებიდან სად როგორ. LinkedIn ინახავს DataHub-ის საკუთარ ვერსიას ღია წყაროსგან დამოუკიდებლად. ჩვენ დავიწყებთ იმის ახსნით, თუ რატომ გვჭირდება განვითარების ორი ცალკეული გარემო, შემდეგ განვიხილავთ ადრეულ მიდგომებს ღია კოდის WhereHows-ის გამოყენების შესახებ და შევადარებთ DataHub-ის შიდა (წარმოების) ვერსიას. GitHub. ჩვენ ასევე გაგიზიარებთ დეტალებს ჩვენი ახალი ავტომატური გადაწყვეტის შესახებ ღია კოდის განახლებების გაშვებისა და მიღებისთვის, რათა ორივე საცავი სინქრონიზებული იყოს. და ბოლოს, ჩვენ მივცემთ ინსტრუქციას, თუ როგორ უნდა დავიწყოთ ღია კოდის DataHub-ის გამოყენება და მოკლედ განვიხილავთ მის არქიტექტურას.

WhereHows ახლა DataHub-ია!

LinkedIn-ის მეტამონაცემების გუნდი ადრე იყო წარმოდგენილი DataHub (WhereHows-ის მემკვიდრე), LinkedIn-ის საძიებო და მეტამონაცემების აღმოჩენის პლატფორმა და მისი გახსნის საერთო გეგმები. ამ განცხადებიდან მალევე, ჩვენ გამოვაქვეყნეთ DataHub-ის ალფა ვერსია და გავუზიარეთ ის საზოგადოებას. მას შემდეგ, ჩვენ განუწყვეტლივ ვაკეთებთ წვლილს საცავში და ვმუშაობდით დაინტერესებულ მომხმარებლებთან, რათა დავამატოთ ყველაზე მოთხოვნადი ფუნქციები და გადავჭრათ პრობლემები. ახლა ჩვენ მოხარული ვართ გამოვაცხადოთ ოფიციალური გამოშვება DataHub GitHub-ზე.

ღია კოდის მიდგომები

WhereHows, LinkedIn-ის ორიგინალური პორტალი მონაცემების საძიებლად და საიდან მოდის, დაიწყო როგორც შიდა პროექტი; მეტამონაცემების ჯგუფმა გახსნა წყაროს კოდი 2016 წელს. მას შემდეგ გუნდს ყოველთვის აქვს ორი განსხვავებული კოდის ბაზა - ერთი ღია კოდისთვის და მეორე LinkedIn-ის შიდა გამოყენებისთვის, რადგან LinkedIn-ის გამოყენების შემთხვევისთვის შემუშავებული პროდუქტის ყველა მახასიათებელი არ იყო ზოგადად გამოყენებული ფართო აუდიტორიისთვის. გარდა ამისა, WhereHows-ს აქვს გარკვეული შიდა დამოკიდებულებები (ინფრასტრუქტურა, ბიბლიოთეკები და ა.შ.), რომლებიც არ არის ღია წყარო. მომდევნო წლებში WhereHows-მა გაიარა მრავალი გამეორება და განვითარების ციკლი, რამაც ორი კოდის ბაზის სინქრონიზაცია დიდ გამოწვევად აქცია. მეტამონაცემების გუნდმა წლების განმავლობაში სცადა სხვადასხვა მიდგომა, რათა შეეცადა შეენარჩუნებინა შიდა და ღია კოდის განვითარება სინქრონიზებული.

პირველი სცადეთ: "პირველად ღია წყარო"

ჩვენ თავდაპირველად მივყვებოდით "ღია წყაროს პირველ რიგში" განვითარების მოდელს, სადაც განვითარების უმეტესი ნაწილი ხდება ღია კოდის საცავში და ცვლილებები ხდება შიდა განლაგებისთვის. ამ მიდგომის პრობლემა ის არის, რომ კოდი ყოველთვის პირველ რიგში გადადის GitHub-ში, სანამ იგი მთლიანად განიხილება შიდა. სანამ ცვლილებები არ განხორციელდება ღია კოდის საცავიდან და არ განხორციელდება ახალი შიდა განლაგება, ჩვენ ვერ ვიპოვით წარმოების პრობლემას. ცუდი განლაგების შემთხვევაში, ასევე ძალიან რთული იყო დამნაშავის დადგენა, რადგან ცვლილებები ხდებოდა პარტიებში.

გარდა ამისა, ამ მოდელმა შეამცირა გუნდის პროდუქტიულობა ახალი ფუნქციების შემუშავებისას, რაც მოითხოვდა სწრაფ გამეორებას, რადგან მან აიძულა ყველა ცვლილება ჯერ ღია კოდის საცავში გადასულიყო, შემდეგ კი შიდა საცავში. დამუშავების დროის შესამცირებლად, საჭირო შესწორება ან ცვლილება შეიძლება განხორციელდეს პირველ რიგში შიდა საცავში, მაგრამ ეს გახდა უზარმაზარი პრობლემა, როდესაც საქმე მიდგა ამ ცვლილებების შერწყმა ღია კოდის საცავში, რადგან ორი საცავი სინქრონიზებული იყო.

ამ მოდელის დანერგვა ბევრად უფრო ადვილია საერთო პლატფორმებისთვის, ბიბლიოთეკებისთვის ან ინფრასტრუქტურული პროექტებისთვის, ვიდრე სრულფასოვანი მორგებული ვებ აპლიკაციებისთვის. გარდა ამისა, ეს მოდელი იდეალურია პროექტებისთვის, რომლებიც ღია წყაროდან იწყება პირველივე დღიდან, მაგრამ WhereHows აშენდა, როგორც მთლიანად შიდა ვებ აპლიკაცია. მართლაც რთული იყო ყველა შიდა დამოკიდებულების სრულად აბსტრაქცია, ამიტომ გვჭირდებოდა შიდა ჩანგლის შენარჩუნება, მაგრამ შიდა ჩანგლის შენარჩუნება და ძირითადად ღია წყაროს განვითარება არ გამოვიდა.

მეორე მცდელობა: "პირველი შინაგანი"

**როგორც მეორე მცდელობა, ჩვენ გადავედით განვითარების „შიდა პირველ“ მოდელზე, სადაც განვითარების უმეტესობა ხდება შიდა და რეგულარულად ხდება ცვლილებები ღია კოდის კოდში. მიუხედავად იმისა, რომ ეს მოდელი საუკეთესოდ შეეფერება ჩვენს გამოყენებას, მას თანდაყოლილი პრობლემები აქვს. ყველა განსხვავებების პირდაპირ გადატანა ღია კოდის საცავში და შემდეგ შერწყმის კონფლიქტების მოგვიანებით გადაჭრის მცდელობა არის ვარიანტი, მაგრამ ეს შრომატევადია. დეველოპერები უმეტეს შემთხვევაში ცდილობენ არ გააკეთონ ეს ყოველ ჯერზე, როცა განიხილავენ თავიანთ კოდს. შედეგად, ეს გაკეთდება ბევრად უფრო იშვიათად, ჯგუფურად, რაც ართულებს მოგვიანებით გაერთიანების კონფლიქტების მოგვარებას.

მესამედ იმუშავა!

ზემოთ ნახსენებმა ორმა წარუმატებელმა მცდელობამ გამოიწვია WhereHows GitHub საცავი დიდი ხნის განმავლობაში მოძველებული. გუნდმა განაგრძო პროდუქტის მახასიათებლებისა და არქიტექტურის გაუმჯობესება, ისე, რომ WhereHows-ის შიდა ვერსია LinkedIn-ისთვის უფრო მოწინავე გახდა, ვიდრე ღია კოდის ვერსია. მას ახალი სახელიც კი ჰქონდა - DataHub. წინა წარუმატებელი მცდელობების საფუძველზე, გუნდმა გადაწყვიტა შეემუშავებინა მასშტაბური, გრძელვადიანი გადაწყვეტა.

ნებისმიერი ახალი ღია კოდის პროექტისთვის, LinkedIn-ის ღია კოდის გუნდი ურჩევს და მხარს უჭერს განვითარების მოდელს, რომელშიც პროექტის მოდულები მთლიანად ღია კოდით არის შემუშავებული. ვერსიული არტეფაქტები განლაგებულია საჯარო საცავში და შემდეგ კვლავ შემოწმდება LinkedIn-ის შიდა არტეფაქტში. გარე ბიბლიოთეკის მოთხოვნა (ELR). განვითარების ამ მოდელის დაცვა არა მხოლოდ კარგია მათთვის, ვინც იყენებს ღია წყაროს, არამედ იძლევა უფრო მოდულურ, გაფართოებულ და ჩართვის არქიტექტურას.

თუმცა, სექსუალურ back-end აპლიკაციას, როგორიცაა DataHub, დასჭირდება მნიშვნელოვანი დრო ამ მდგომარეობის მისაღწევად. ეს ასევე გამორიცხავს ღია წყაროს სრულად მოქმედი განხორციელების შესაძლებლობას, სანამ ყველა შიდა დამოკიდებულების სრულად აბსტრაქცია არ მოხდება. სწორედ ამიტომ, ჩვენ შევიმუშავეთ ინსტრუმენტები, რომლებიც დაგვეხმარება ღია კოდის წვლილის შეტანაში უფრო სწრაფად და გაცილებით ნაკლები ტკივილით. ეს გადაწყვეტა სარგებელს მოაქვს როგორც მეტამონაცემების გუნდს (DataHub დეველოპერი) ასევე ღია კოდის საზოგადოებას. შემდეგი სექციები განიხილავს ამ ახალ მიდგომას.

ღია კოდის გამოცემის ავტომატიზაცია

მეტამონაცემების გუნდის უახლესი მიდგომა ღია კოდის DataHub-ის მიმართ არის ინსტრუმენტის შემუშავება, რომელიც ავტომატურად სინქრონიზებს შიდა კოდების ბაზას და ღია წყაროს საცავს. ამ ინსტრუმენტთა ნაკრების მაღალი დონის მახასიათებლები მოიცავს:

1. LinkedIn-ის კოდის სინქრონიზაცია ღია წყაროდან/ღია წყაროდან, მსგავსი rsync.
2. ლიცენზიის სათაურის გენერაცია, მსგავსი აპაჩის ვირთხა.
3. ავტომატური გენერირება ღია კოდის ჩანაწერების ჩაწერის შიდა ჟურნალებიდან.
4. თავიდან აიცილეთ შიდა ცვლილებები, რომლებიც არღვევს ღია წყაროს შენობებს დამოკიდებულების ტესტირება.

შემდეგ ქვეთავებში განვიხილავთ ზემოხსენებულ ფუნქციებს, რომლებსაც აქვთ საინტერესო პრობლემები.

წყაროს კოდის სინქრონიზაცია

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-ის წყაროს ფაილის 1:1 დახატვა ღია კოდის საცავში არსებულ ფაილზე. არსებობს რამდენიმე წესი, რომელიც დაკავშირებულია ფაილების ასოციაციების ავტომატურ შექმნასთან:

• ღია კოდის სამიზნე მოდულის მრავალი წყაროს მოდულის შემთხვევაში, შეიძლება წარმოიშვას კონფლიქტები, მაგ. FQCN, რომელიც არსებობს ერთზე მეტ წყაროს მოდულში. როგორც კონფლიქტის მოგვარების სტრატეგია, ჩვენი ხელსაწყოები ნაგულისხმევად აყენებენ „ბოლო მოგების“ ვარიანტს.
• "null" ნიშნავს, რომ წყაროს ფაილი არ არის ღია წყაროს საცავი.
• ყოველი ღია წყაროს წარდგენის ან ამოღების შემდეგ, ეს რუკა ავტომატურად განახლდება და იქმნება სნეპშოტი. ეს აუცილებელია ბოლო მოქმედების შემდეგ საწყისი კოდიდან დამატებებისა და წაშლის დასადგენად.

შეთანხმების ჟურნალების შექმნა

ჩაწერის ჩანაწერები ღია კოდის ჩაწერებისთვის ასევე ავტომატურად გენერირდება შიდა საცავების commit ჟურნალების შერწყმით. ქვემოთ მოცემულია დავალების ჟურნალის ნიმუში, რათა აჩვენოს ჩვენი ხელსაწყოს მიერ გენერირებული ვალდებულებების ჟურნალის სტრუქტურა. commit ნათლად მიუთითებს წყაროს საცავების რომელი ვერსიებია შეფუთული ამ commit-ში და უზრუნველყოფს commit ჟურნალის შეჯამებას. შეამოწმეთ ეს ერთი ჩაიდინოს ჩვენი ინსტრუმენტარიუმის მიერ გენერირებული ვალდებულებების ჟურნალის რეალური მაგალითის გამოყენებით.

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 საცავს, იწვევს build მოვლენას shell multiproduct-ში. ამიტომ, ნებისმიერი ცვლილება, რომელიც ვერ ახერხებს შეფუთვის პროდუქტის შექმნას, ვერ ახერხებს ტესტებს ორიგინალური პროდუქტის ჩადებამდე და უბრუნდება.

ეს არის სასარგებლო მექანიზმი, რომელიც ეხმარება თავიდან აიცილოს ნებისმიერი შიდა ჩადენა, რომელიც არღვევს ღია კოდის კონსტრუქციას და ამოიცნობს მას ჩადენის დროს. ამის გარეშე საკმაოდ რთული იქნებოდა იმის დადგენა, თუ რომელმა შიდა commit-მა გამოიწვია ღია კოდის საცავის აწყობის მარცხი, რადგან ჩვენ ვაერთიანებთ შიდა ცვლილებებს DataHub ღია წყაროს საცავში.

განსხვავებები ღია კოდის DataHub-სა და ჩვენს წარმოების ვერსიას შორის

ამ მომენტამდე, ჩვენ განვიხილეთ ჩვენი გადაწყვეტა DataHub საცავების ორი ვერსიის სინქრონიზაციისთვის, მაგრამ ჯერ კიდევ არ გამოვთქვით მიზეზები, რის გამოც პირველ რიგში გვჭირდება განვითარების ორი განსხვავებული ნაკადი. ამ განყოფილებაში ჩვენ ჩამოვთვლით განსხვავებებს DataHub-ის საჯარო ვერსიასა და LinkedIn სერვერების წარმოების ვერსიას შორის და განვმარტავთ ამ განსხვავებების მიზეზებს.

შეუსაბამობის ერთ-ერთი წყარო გამომდინარეობს იქიდან, რომ ჩვენი წარმოების ვერსია დამოკიდებულია კოდზე, რომელიც ჯერ არ არის ღია წყარო, როგორიცაა LinkedIn's Offspring (LinkedIn-ის შიდა დამოკიდებულების ინექციის ჩარჩო). შთამომავლობა ფართოდ გამოიყენება შიდა კოდების ბაზებში, რადგან ეს არის სასურველი მეთოდი დინამიური კონფიგურაციის მართვისთვის. მაგრამ ეს არ არის ღია წყარო; ამიტომ დაგვჭირდა ღია კოდის ალტერნატივების პოვნა ღია კოდის DataHub-ისთვის.

სხვა მიზეზებიც არის. ვინაიდან ჩვენ ვქმნით მეტამონაცემების მოდელის გაფართოებებს LinkedIn-ის საჭიროებებისთვის, ეს გაფართოებები, როგორც წესი, ძალიან სპეციფიკურია LinkedIn-ისთვის და შეიძლება პირდაპირ არ ვრცელდება სხვა გარემოზე. მაგალითად, ჩვენ გვაქვს ძალიან კონკრეტული ლეიბლები მონაწილეთა ID-ებისთვის და სხვა სახის შესატყვისი მეტამონაცემებისთვის. ასე რომ, ჩვენ ახლა გამოვრიცხეთ ეს გაფართოებები DataHub-ის ღია კოდის მეტამონაცემების მოდელიდან. როდესაც ჩვენ ვთანამშრომლობთ საზოგადოებასთან და გვესმის მათი საჭიროებები, ჩვენ ვიმუშავებთ ამ გაფართოებების საერთო ღია კოდის ვერსიებზე, სადაც საჭიროა.

გამოყენების სიმარტივე და ღია კოდის საზოგადოებისთვის უფრო მარტივი ადაპტაცია ასევე შთააგონებდა ზოგიერთ განსხვავებას DataHub-ის ორ ვერსიას შორის. ნაკადის დამუშავების ინფრასტრუქტურაში არსებული განსხვავებები ამის კარგი მაგალითია. მიუხედავად იმისა, რომ ჩვენი შიდა ვერსია იყენებს მართული ნაკადის დამუშავების ჩარჩოს, ჩვენ ავირჩიეთ ჩაშენებული (დამოუკიდებელი) ნაკადის დამუშავება ღია კოდის ვერსიისთვის, რადგან ის თავიდან აიცილებს სხვა ინფრასტრუქტურის დამოკიდებულების შექმნას.

სხვაობის კიდევ ერთი მაგალითია ერთი GMS (განზოგადებული მეტამონაცემების მაღაზია) ღია კოდის დანერგვაში, ვიდრე მრავალჯერადი GMS. GMA (განზოგადებული მეტამონაცემების არქიტექტურა) არის DataHub-ის back-end არქიტექტურის სახელი, ხოლო GMS არის მეტამონაცემების მაღაზია GMA-ს კონტექსტში. GMA არის ძალიან მოქნილი არქიტექტურა, რომელიც საშუალებას გაძლევთ გაავრცელოთ თითოეული მონაცემთა კონსტრუქცია (მაგ. მონაცემთა ნაკრები, მომხმარებლები და ა. GMS განახლებულია. გამოყენების სიმარტივისთვის, ჩვენ ავირჩიეთ ერთი GMS მაგალითი, რომელიც ინახავს მონაცემთა ყველა სხვადასხვა კონსტრუქციას ღია კოდის DataHub-ში.

ამ ორ განხორციელებას შორის განსხვავებების სრული სია მოცემულია ქვემოთ მოცემულ ცხრილში.

პროდუქტის მახასიათებლები
LinkedIn DataHub
ღია წყარო DataHub

მხარდაჭერილი მონაცემთა კონსტრუქციები
1) მონაცემთა ნაკრები 2) მომხმარებლები 3) მეტრიკა 4) ML მახასიათებლები 5) დიაგრამები 6) დაფები
1) მონაცემთა ნაკრები 2) მომხმარებლები

მხარდაჭერილი მეტამონაცემების წყაროები მონაცემთა ნაკრებისთვის
1) ამბრი 2) Couchbase 3) დალიდები 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 Offspring
გაზაფხული

Build Tooling
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-ში არის ღია წყარო, ინფრასტრუქტურის კომპონენტების ჩათვლით, როგორიცაა კაფკა, ელასტიური ძებნა, ნეო 4 ჯ и MySQL, აქვს საკუთარი Docker იმიჯი. Docker კონტეინერების ორკესტრირებისთვის ჩვენ გამოვიყენეთ Docker შედგენა.

სურათი 2: არქიტექტურა DataHub *საჯარო წყარო**

ზემოთ მოცემულ სურათზე შეგიძლიათ იხილოთ DataHub-ის მაღალი დონის არქიტექტურა. ინფრასტრუქტურის კომპონენტების გარდა, მას აქვს ოთხი განსხვავებული Docker კონტეინერი:

datahub-gms: მეტამონაცემების შენახვის სერვისი

datahub-frontend: აპლიკაცია თამაში, ემსახურება DataHub ინტერფეისს.

datahub-mce-consumer: აპლიკაცია კაფკას ნაკადები, რომელიც იყენებს მეტამონაცემების ცვლილების მოვლენის (MCE) ნაკადს და აახლებს მეტამონაცემების მაღაზიას.

datahub-mae-consumer: განაცხადი კაფკას ნაკადები, რომელიც იყენებს მეტამონაცემების აუდიტის მოვლენის ნაკადს (MAE) და ქმნის საძიებო ინდექსს და გრაფიკის მონაცემთა ბაზას.

ღია კოდის საცავის დოკუმენტაცია და ორიგინალური DataHub ბლოგის პოსტი შეიცავს უფრო დეტალურ ინფორმაციას სხვადასხვა სერვისების ფუნქციების შესახებ.

CI/CD DataHub-ზე არის ღია წყარო

ღია კოდის DataHub საცავი იყენებს TravisCI უწყვეტი ინტეგრაციისთვის და დოკერის ცენტრი უწყვეტი განლაგებისთვის. ორივეს აქვს კარგი GitHub ინტეგრაცია და მარტივია დაყენება. საზოგადოების ან კერძო კომპანიების მიერ შემუშავებული ღია კოდის ინფრასტრუქტურის უმეტესობისთვის (მაგ. Confluent), Docker-ის სურათები იქმნება და განლაგებულია Docker Hub-ზე საზოგადოების მიერ მარტივად გამოყენებისთვის. Docker Hub-ში ნაპოვნი Docker-ის ნებისმიერი სურათი შეიძლება ადვილად გამოიყენოთ მარტივი ბრძანებით დოკერის მოზიდვა.

DataHub-ის ღია წყაროს საცავში ყოველი ჩაბარებისას, Docker-ის ყველა სურათი ავტომატურად შენდება და განლაგებულია Docker Hub-ზე „უახლესი“ ტეგით. თუ Docker Hub კონფიგურირებულია ზოგიერთთან რეგულარული გამოხატვის ტოტების დასახელება, ღია კოდის საცავში ყველა ტეგი ასევე გამოშვებულია შესაბამისი ტეგების სახელებით Docker Hub-ში.

DataHub-ის გამოყენებით

DataHub-ის დაყენება არის ძალიან მარტივი და შედგება სამი მარტივი ნაბიჯისგან:

1. კლონირეთ ღია კოდის საცავი და გაუშვით Docker-ის ყველა კონტეინერი docker-compose-ით მოწოდებული docker-compose სკრიპტის გამოყენებით სწრაფი დაწყებისთვის.
2. ჩამოტვირთეთ საცავში მოწოდებული მონაცემების ნიმუში ბრძანების ხაზის ხელსაწყოს გამოყენებით, რომელიც ასევე მოცემულია.
3. დაათვალიერეთ DataHub თქვენს ბრაუზერში.

აქტიურად ადევნებენ თვალყურს გიტერ ჩატი ასევე კონფიგურირებულია სწრაფი კითხვებისთვის. მომხმარებლებს ასევე შეუძლიათ პრობლემების შექმნა პირდაპირ GitHub საცავში. რაც მთავარია, ჩვენ მივესალმებით და ვაფასებთ ყველა გამოხმაურებას და წინადადებას!

სამომავლო გეგმები

ამჟამად, ყველა ინფრასტრუქტურა ან მიკროსერვისი ღია კოდის DataHub-ისთვის აგებულია როგორც Docker კონტეინერი და მთელი სისტემა ორკესტრირებულია გამოყენებით დოკერი-კომპოზიცია. პოპულარობისა და გავრცელების გათვალისწინებით კუბერნეტებიჩვენ ასევე გვსურს შემოგთავაზოთ Kubernetes-ზე დაფუძნებული გადაწყვეტა უახლოეს მომავალში.

ჩვენ ასევე ვგეგმავთ უზრუნველყოთ ანაზრაურების გადაწყვეტა DataHub-ის განსათავსებლად საჯარო ღრუბლოვან სერვისზე, როგორიცაა Azure, AWS ან Google Cloud. LinkedIn-ის Azure-ში მიგრაციის ბოლოდროინდელი განცხადების გათვალისწინებით, ეს შეესაბამება მეტამონაცემების გუნდის შიდა პრიორიტეტებს.

და ბოლოს, მადლობა ყველა ადრეულ მიმღებს DataHub-ის ღია კოდის საზოგადოებაში, რომლებმაც შეაფასეს DataHub ალფა და დაგვეხმარა პრობლემების იდენტიფიცირებაში და დოკუმენტაციის გაუმჯობესებაში.

წყარო: www.habr.com