DataHub z otwartym kodem źródłowym: platforma do wyszukiwania i odkrywania metadanych od LinkedIn
Szybkie wyszukiwanie potrzebnych danych jest niezbędne dla każdej firmy, która polega na dużej ilości danych do podejmowania decyzji opartych na tych danych. Ma to nie tylko wpływ na wydajność użytkowników danych (w tym analityków, programistów uczenia maszynowego, specjalistów ds. przetwarzania danych i inżynierów danych), ale także ma bezpośredni wpływ na końcowe produkty, które zależą od jakościowego procesu uczenia maszynowego (ML). Co więcej, tendencja do wdrażania lub tworzenia platform uczenia maszynowego naturalnie stawia pytanie: jaka jest wasza metoda wewnętrznego odkrywania funkcji, modeli, wskaźników, zbiorów danych itd.
W tym artykule opowiemy, jak opublikowaliśmy źródło danych na otwartej licencji na naszej platformie wyszukiwania i odkrywania metadanych, począwszy od pierwszych dni projektu . LinkedIn wspiera swoją własną wersję DataHub oddzielnie od wersji open source. Zaczniemy od wyjaśnienia, dlaczego potrzebujemy dwóch oddzielnych środowisk deweloperskich, a następnie omówimy pierwsze podejścia do korzystania z WhereHows w wersji open source i porównamy naszą wewnętrzną (produkcyjną) wersję DataHub z wersją na . Podzielimy się również szczegółami naszego nowego zautomatyzowanego rozwiązania do wysyłania i odbierania aktualizacji z otwartym kodem źródłowym, aby zsynchronizować oba repozytoria. Na koniec przekażemy instrukcje, jak zacząć korzystać z DataHub w wersji open source, oraz krótko omówimy jego architekturę.
WhereHows to teraz DataHub!
Zespół ds. metadanych LinkedIn wcześniej przedstawił (następca WhereHows), platformę wyszukiwania i odkrywania metadanych LinkedIn, i podzielił się planami jej otwarcia. Wkrótce po tym ogłoszeniu wydaliśmy wersję alpha DataHub i podzieliliśmy się nią z społecznością. Od tego czasu nieprzerwanie przyczynialiśmy się do repozytorium i współpracowaliśmy z zainteresowanymi użytkownikami, aby dodać najbardziej pożądane funkcje i rozwiązać problemy. Teraz z radością ogłaszamy oficjalne wydanie .
Podejścia open source
WhereHows, oryginalny portal LinkedIn do wyszukiwania danych i ich pochodzenia, zaczynał jako projekt wewnętrzny; zespół ds. metadanych otworzył . Od tamtej pory zespół zawsze utrzymywał dwie różne bazy kodu — jedną dla kodu open source, a drugą dla wewnętrznego użytku LinkedIn, ponieważ nie wszystkie funkcje produktu opracowane dla potrzeb LinkedIn były ogólnie aplikowalne dla szerszej publiczności. Ponadto WhereHows ma niektóre wewnętrzne zależności (infrastruktura, biblioteki itp.), których kod źródłowy nie jest publiczny. W ciągu następnych lat WhereHows przeszedł przez wiele iteracji i cykli rozwoju, co uczyniło synchronizację obu baz kodu dużym wyzwaniem. Zespół metadanych przez wiele lat próbował stosować różne podejścia, aby spróbować zsynchronizować rozwój wewnętrzny z rozwojem open source.
Pierwsza próba: „Najpierw open source”
Początkowo stosowaliśmy model rozwoju „najpierw open source”, gdzie główny rozwój odbywał się w repozytorium open source, a zmiany były wprowadzane dla wewnętrznego wdrożenia. Problem z tym podejściem polegał na tym, że kod zawsze trafiał najpierw na GitHub, zanim był całkowicie sprawdzony wewnętrznie. Dopóki zmiany nie zostaną wprowadzone z repozytorium open source i nie przeprowadzimy nowego wewnętrznego wdrożenia, nie wykryjemy żadnych problemów produkcyjnych. W przypadku złego wdrożenia bardzo trudno było również ustalić winowajcę, ponieważ zmiany były wprowadzane partiami.
Ponadto ten model obniżył produktywność zespołu przy rozwijaniu nowych funkcji wymagających szybkich iteracji, ponieważ wymuszał umieszczanie wszystkich zmian najpierw w repozytorium open source, a następnie przenoszenie ich do repozytorium wewnętrznego. Aby skrócić czas przetwarzania, potrzebna poprawka lub zmiana mogła być najpierw dokonana w repozytorium wewnętrznym, ale stanowiło to ogromny problem, gdy nadeszło do scalania tych zmian z powrotem do repozytorium open source, ponieważ obie bazy kodu straciły synchronizację.
Ten model znacznie łatwiej wdrożyć w przypadku ogólnych platform, bibliotek lub projektów infrastrukturalnych niż w przypadku pełnoprawnych aplikacji webowych. Ponadto, model ten idealnie nadaje się do projektów, które zaczynają się z otwartym kodem źródłowym od pierwszego dnia, ale WhereHows było tworzony jako całkowicie wewnętrzna aplikacja webowa. Było naprawdę trudno w pełni abstrahować od wszystkich wewnętrznych zależności, więc musieliśmy zachować wewnętrzną gałąź, ale zachowanie wewnętrznej gałęzi i rozwój głównie z otwartym kodem źródłowym nie do końca się sprawdziły.
Druga próba: „Najpierw wewnętrzny”
** Jako drugą próbę przeszliśmy na model rozwoju „najpierw wewnętrzny”, w którym główny rozwój odbywa się wewnątrz firmy, a zmiany są regularnie wprowadzane do otwartego kodu źródłowego. Chociaż ten model najlepiej pasuje do naszego przypadku użycia, wiąże się z pewnymi problemami. Bezpośrednie przesyłanie wszystkich różnic do repozytorium z otwartym kodem źródłowym, a następnie próba rozwiązywania konfliktów scalania później — jest to opcja, ale wymaga dużo czasu. W większości przypadków programiści starają się tego nie robić przy każdej kontroli kodu. W rezultacie będzie to wykonywane znacznie rzadziej, partiami, co utrudni późniejsze rozwiązywanie konfliktów scalania.
Trzeci raz się udało!
Dwie wspomniane powyżej nieudane próby doprowadziły do tego, że repozytorium WhereHows na GitHubie pozostawało przez długi czas przestarzałe. Zespół nadal doskonalił funkcje i architekturę produktu, więc wewnętrzna wersja WhereHows dla LinkedIn stawała się coraz bardziej zaawansowana w porównaniu do wersji z otwartym kodem źródłowym. Miała nawet nową nazwę — DataHub. Na podstawie wcześniejszych nieudanych prób zespół postanowił opracować skalowalne, długoterminowe rozwiązanie.
W przypadku każdego nowego projektu z otwartym kodem źródłowym zespół deweloperów LinkedIn konsultuje i wspiera model rozwoju, w którym moduły projektu są w pełni opracowywane z otwartym kodem źródłowym. Artefakty z obsługą wersji są wdrażane w publicznie dostępnym repozytorium, a następnie zwracane do wewnętrznego artefaktu LinkedIn za pomocą Podążanie za tym modelem rozwoju jest korzystne nie tylko dla osób korzystających z otwartego oprogramowania, ale prowadzi także do stworzenia bardziej modularnej, rozbudowalnej i interaktywnej architektury.
Jednak osiągnięcie tego stanu w dojrzałej aplikacji wewnętrznej, takiej jak DataHub, wymaga znacznego nakładu czasu. Wyklucza to również możliwość otwartego źródła w pełni działającej implementacji, dopóki wszystkie wewnętrzne zależności nie będą całkowicie abstrahowane. Dlatego opracowaliśmy narzędzia, które pomagają nam wnosić wkład w otwarte oprogramowanie szybciej i znacznie mniej bolesnie. To rozwiązanie jest korzystne zarówno dla zespołu metadanych (deweloper DataHub), jak i społeczności otwartego oprogramowania. W kolejnych częściach omówimy to nowe podejście.
Automatyzacja publikacji z otwartym kodem źródłowym
Ostatnie podejście zespołu metadanych do DataHub z otwartym kodem źródłowym polega na opracowaniu narzędzia, które automatycznie synchronizuje wewnętrzną bazę kodu z repozytorium otwartego oprogramowania. Funkcje tego narzędzia obejmują:
- Synchronizację kodu LinkedIn z / z otwartego oprogramowania, podobnie jak .
- Generowanie nagłówka licencji, podobnie jak .
- Automatyczne tworzenie logów commitów z otwartym kodem źródłowym na podstawie wewnętrznych logów commitów.
- Zapobieganie wewnętrznym zmianom, które mogą zakłócać budowę z otwartym kodem źródłowym poprzez .
W następnych podsekcjach szczegółowo omówimy powyższe funkcje, które mają interesujące wyzwania.
Synchronizacja kodu źródłowego
W przeciwieństwie do wersji DataHub z otwartym kodem źródłowym, która jest jednolitym repozytorium GitHub, wersja DataHub dla LinkedIn jest kombinacją kilku repozytoriów (w firmie nazywanych ). Interfejs DataHub, biblioteka modeli metadanych, serwis zaplecza przechowywania metadanych i zadania strumieniowe znajdują się w różnych repozytoriach w LinkedIn. Niemniej jednak, aby ułatwić korzystanie z otwartego oprogramowania, posiadamy jednolite repozytorium dla wersji DataHub z otwartym kodem źródłowym.
Rysunek 1: Synchronizacja między repozytoriami LinkedIn DataHub i jednolitym repozytorium DataHub z otwartym kodem źródłowym
Aby wspierać automatyczne procesy budowy, wysyłania i ekstrakcji, nasze nowe narzędzie automatycznie tworzy dopasowanie na poziomie pliku dla każdego pliku źródłowego. Jednak narzędzie wymaga początkowej konfiguracji, a użytkownicy muszą dostarczyć wysokopoziomowe odwzorowanie modułów, jak pokazano poniżej.
{
"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"
]
}Dopasowanie na poziomie modułu to prosty JSON, w którym klucze to moduły docelowe w repozytorium open source, a wartości to lista modułów źródłowych w repozytoriach LinkedIn. Każdy moduł docelowy w repozytorium open source może korzystać z dowolnej liczby modułów źródłowych. Do oznaczania wewnętrznych nazw repozytoriów w modułach źródłowych używa się w stylu Bash. Korzystając z pliku dopasowania na poziomie modułu, narzędzia tworzą plik dopasowania na poziomie plików, skanując wszystkie pliki w powiązanych katalogach.
{
"${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,
}Dopasowanie na poziomie plików jest automatycznie tworzone przez narzędzia; jednak może również być aktualizowane ręcznie przez użytkownika. To dopasowanie 1:1 pliku źródłowego LinkedIn z plikiem w repozytorium open source. Istnieje kilka zasad związanych z automatycznym tworzeniem dopasowania plików:
- W przypadku kilku modułów źródłowych dla modułu docelowego w repozytorium open source mogą wystąpić konflikty, na przykład ten sam , istniejący w więcej niż jednym module źródłowym. Jako strategię rozwiązywania konfliktów nasze narzędzia domyślnie stosują opcję „ostatni wygrywa”.
- "null" oznacza, że plik źródłowy nie jest częścią repozytorium open source.
- Po każdej wysyłce do otwartego kodu źródłowego lub jego wydobycia, to odwzorowanie jest automatycznie aktualizowane i tworzony jest zrzut stanu. Jest to konieczne do określenia dodatków i usunięć w kodzie źródłowym po ostatniej akcji.
Tworzenie logów commitów
Logi commitów dla commitów z otwartym kodem źródłowym są również automatycznie tworzone poprzez scalanie logów commitów wewnętrznych repozytoriów. Poniżej przedstawiony jest przykładowy log commitów, aby pokazać strukturę logu commitów stworzonego przez nasze narzędzie. Commit jednoznacznie wskazuje, jakie wersje repozytoriów źródłowych są spakowane w tym commicie oraz dostarcza podsumowującej informacji o logu commitów. Sprawdź to na rzeczywistym przykładzie logu commitów stworzonego przez nasze narzędzie.
metadata-models 29.0.0 -> 30.0.0
Dodano model aspektu foo
Naprawiono problem bar
dataset-gms 2.3.0 -> 2.3.4
Dodano API rest.li do obsługi aspektu foo
MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0Testowanie zależności
LinkedIn ma , która pomaga zagwarantować, że zmiany wewnętrznego wieloproduktu nie zakłócą budowy zależnych wieloproduktów. Repozytorium DataHub z otwartym kodem źródłowym nie jest wieloproduktowe i nie może być bezpośrednią zależnością od jakiegokolwiek wieloproduktu, ale za pomocą wieloproduktowej powłoki, która wydobywa otwarty kod źródłowy DataHub, wciąż możemy korzystać z tego systemu testowania zależności. W związku z tym, każda zmiana (która być może później będzie otwarta) w którymkolwiek z wieloproduktów zasilających repozytorium DataHub z otwartym kodem źródłowym wyzwala zdarzenie budowy w powłoce wieloproduktu. Z tego powodu każda zmiana, która uniemożliwia zbudowanie powłoki wieloproduktu, nie przechodzi testów przed commitem oryginalnego wieloproduktu i jest odrzucana.
To przydatny mechanizm, który pomaga zapobiec jakimkolwiek wewnętrznym commitom, które zrywają budowę z otwartym kodem źródłowym i wykrywa je podczas tworzenia commitu. Bez tego byłoby dość trudno określić, który wewnętrzny commit doprowadził do niepowodzenia budowy repozytorium z otwartym kodem źródłowym, ponieważ umieszczamy pakietowe zmiany wewnętrzne w repozytorium DataHub z otwartym kodem źródłowym.
Różnice między DataHub z otwartym kodem źródłowym a naszą wersją produkcyjną
Do tej pory omawialiśmy nasze rozwiązanie do synchronizacji dwóch wersji repozytoriów DataHub, ale jeszcze nie wskazaliśmy powodów, dla których potrzebujemy dwóch różnych strumieni rozwoju. W tej sekcji wymienimy różnice między wersją publiczną DataHub a wersją produkcyjną na serwerach LinkedIn i wyjaśnimy te różnice.
Jednym z źródeł rozbieżności jest fakt, że nasza wersja produkcyjna ma zależności od kodu, który nie jest jeszcze otwarty, takiego jak Offspring LinkedIn (wewnętrzna struktura zarządzania zależnościami LinkedIn). Offspring jest szeroko stosowany w wewnętrznej bazie kodu, ponieważ jest preferowaną metodą zarządzania dynamiką konfiguracji. Ale nie jest to kod otwarty, dlatego musieliśmy znaleźć alternatywy z otwartym kodem dla DataHub z otwartym kodem źródłowym.
Są też inne powody. W miarę jak tworzymy rozszerzenia modelu metadanych dla potrzeb LinkedIn, te rozszerzenia są zazwyczaj bardzo specyficzne dla LinkedIn i mogą nie być bezpośrednio stosowane w innych środowiskach. Na przykład mamy bardzo specyficzne etykiety dla identyfikatorów uczestników i innych typów metadanych. Dlatego obecnie wykluczyliśmy te rozszerzenia z modelu metadanych DataHub z otwartym kodem źródłowym. W miarę interakcji z społecznością i rozumienia ich potrzeb będziemy pracować nad ogólnymi wersjami tych rozszerzeń z otwartym kodem, gdzie to będzie konieczne.
Łatwość użytkowania i łatwiejsza adaptacja dla społeczności otwartego kodu również zainspirowały pewne różnice między obiema wersjami DataHub. Różnice w infrastrukturze przetwarzania strumieniowego są tego dobrym przykładem. Chociaż nasza wersja wewnętrzna wykorzystuje infrastrukturę zarządzanego przetwarzania strumieniowego, zdecydowaliśmy się użyć wbudowanego (autonomicznego) przetwarzania strumieniowego dla wersji z otwartym kodem źródłowym, ponieważ pozwala to uniknąć tworzenia kolejnej zależności infrastruktury.
Inny przykład różnicy to posiadanie jednego GMS (Generalized Metadata Store) w implementacji z otwartym źródłem, a nie kilku GMS. GMA (Generalized Metadata Architecture) to nazwa wewnętrznej architektury dla DataHub, natomiast GMS to magazyn metadanych w kontekście GMA. GMA to bardzo elastyczna architektura, która pozwala na rozdzielenie każdej konstrukcji danych (np. zestawy danych, użytkownicy itp.) do własnego magazynu metadanych lub przechowywanie kilku konstrukcji danych w jednym magazynie metadanych, o ile rejestr zawierający mapowanie struktury danych w GMS jest aktualizowany. Dla uproszczenia wybraliśmy jedną instancję GMS, która przechowuje wszystkie różne konstrukcje danych w DataHub z otwartym źródłem.
Pełna lista różnic między dwiema implementacjami znajduje się w tabeli poniżej.
Cechy produktu
LinkedIn DataHub
Open Source DataHub
Obsługiwane konstrukty danych
1) Zestawy danych 2) Użytkownicy 3) Metryki 4) Cechy ML 5) Wykresy 6) Pulpity
1) Zestawy danych 2) Użytkownicy
Obsługiwane źródła metadanych dla zestawów danych
1) 2) Couchbase 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vector 14)
Hive Kafka RDBMS
Pub-sub
Confluent Kafka
Przetwarzanie strumieniowe
Zarządzane
Osadzone (standalone)
Wstrzykiwanie zależności & dynamiczna konfiguracja
LinkedIn Offspring
Narzędzia budowlane
Ligradle (wewnętrzny wrapper Gradle LinkedIn)
CI/CD
CRT (wewnętrzny CI/CD LinkedIn)
i
Magazyny metadanych
Rozproszone wiele GMS: 1) GMS zestawów danych 2) GMS użytkowników 3) GMS metryk 4) GMS funkcji 5) GMS wykresów/pulpitów
Jedno GMS dla: 1) Zestawów danych 2) Użytkowników
Mikroserwisy w kontenerach Docker
upraszczają wdrażanie i dystrybucję aplikacji dzięki . Każda część usługi w DataHub z otwartym źródłem, w tym komponenty infrastruktury, takie jak Kafka, , i , ma swój własny obraz Docker. Do orkiestracji kontenerów Docker wykorzystaliśmy .
Rysunek 2: Architektura DataHub *z otwartym źródłem**
Możesz zobaczyć wysokopoziomową architekturę DataHub na powyższym obrazku. Oprócz komponentów infrastruktury ma cztery różne kontenery Docker:
datahub-gms: usługa magazynu metadanych
datahub-frontend: aplikacja , obsługująca interfejs DataHub.
datahub-mce-consumer: aplikacja , która korzysta z strumienia zdarzeń zmian metadanych (MCE) i aktualizuje magazyn metadanych.
datahub-mae-consumer: aplikacja , która korzysta z strumienia zdarzeń audytu metadanych (MAE) i tworzy bazę danych indeksu wyszukiwania i grafu.
Dokumentacja repozytorium z otwartym źródłem i zawierają więcej szczegółowych informacji o funkcjach różnych usług.
CI / CD w DataHub z otwartym kodem źródłowym
Repozytorium DataHub z otwartym kodem źródłowym używa do ciągłej integracji i do ciągłego wdrażania. Oba mają dobrą integrację z GitHubem i są łatwe w konfiguracji. Większość infrastruktury z otwartym kodem stworzona przez społeczność lub prywatne firmy (np. ), utworzone zostały obrazy Docker, które są wdrażane w Docker Hub w celu ułatwienia używania przez społeczność. Każdy obraz Docker znaleziony w Docker Hub można łatwo wykorzystać za pomocą prostego polecenia .
Przy każdym commicie w repozytorium z otwartym kodem źródłowym DataHub wszystkie obrazy Docker są automatycznie tworzone i wdrażane w Docker Hub z tagiem „latest”. Jeśli w Docker Hub skonfigurowano pewne , wszystkie tagi w repozytorium z otwartym kodem źródłowym są również publikowane z odpowiednimi nazwami tagów w Docker Hub.
Używanie DataHub
jest bardzo prosta i składa się z trzech prostych kroków:
- Sklonuj repozytorium z otwartym kodem źródłowym i uruchom wszystkie kontenery Docker za pomocą docker-compose z dostarczonym skryptem docker-compose do szybkiego uruchomienia.
- Pobierz próbki danych dostępne w repozytorium za pomocą narzędzia wiersza poleceń, które również jest dostarczane.
- Odwiedź DataHub w swojej przeglądarce.
Aktywnie monitorowana jest również skonfigurowany do szybkich pytań. Użytkownicy mogą również zgłaszać problemy bezpośrednio w repozytorium GitHub. Co najważniejsze, witamy i doceniamy wszelkie uwagi i sugestie!
Plany na przyszłość
Obecnie każda infrastruktura lub mikroserwis dla DataHub z otwartym kodem źródłowym jest budowany jako kontener Docker, a cały system jest orkiestrony przez . Biorąc pod uwagę popularność i szerokie zastosowanie , chcielibyśmy również wkrótce dostarczyć rozwiązanie oparte na Kubernetes.
Planujemy również dostarczyć gotowe rozwiązanie do wdrażania DataHub w publicznej usłudze chmurowej, takiej jak , lub . Biorąc pod uwagę niedawne ogłoszenie o migracji LinkedIn na Azure, będzie to zgodne z wewnętrznymi priorytetami grupy metadanych.
I na koniec, ale nie mniej ważne: dziękuję wszystkim pierwszym użytkownikom DataHub w społeczności open source, którzy docenili wersje alfa DataHub i pomogli nam zidentyfikować problemy oraz poprawić dokumentację.
Źródło: habr.com
