Open Source DataHub: platforma wyszukiwania i odkrywania metadanych LinkedIn
Szybkie znalezienie potrzebnych danych jest niezbędne dla każdej firmy, która opiera się na dużych ilościach danych przy podejmowaniu decyzji w oparciu o dane. Ma to nie tylko wpływ na produktywność użytkowników danych (w tym analityków, programistów zajmujących się uczeniem maszynowym, analityków danych i inżynierów danych), ale ma także bezpośredni wpływ na produkty końcowe, które zależą od wysokiej jakości potoku uczenia maszynowego (ML). Dodatkowo trend w kierunku wdrażania lub budowania platform uczenia maszynowego w naturalny sposób rodzi pytanie: jaka jest Twoja metoda wewnętrznego odkrywania funkcji, modeli, metryk, zbiorów danych itp.
W tym artykule porozmawiamy o tym, jak opublikowaliśmy źródło danych na otwartej licencji na naszej platformie wyszukiwania i odkrywania metadanych, począwszy od początków projektu . LinkedIn utrzymuje własną wersję DataHub niezależnie od wersji open source. Zaczniemy od wyjaśnienia, dlaczego potrzebujemy dwóch oddzielnych środowisk programistycznych, następnie omówimy wczesne podejścia do korzystania z open source WhereHows i porównamy naszą wewnętrzną (produkcyjną) wersję DataHub z wersją na . Udostępnimy także szczegółowe informacje na temat naszego nowego, zautomatyzowanego rozwiązania do przesyłania i odbierania aktualizacji typu open source, aby zapewnić synchronizację obu repozytoriów. Na koniec podamy instrukcje, jak rozpocząć korzystanie z DataHub o otwartym kodzie źródłowym i krótko omówimy jego architekturę.
WhereHows jest teraz DataHubem!
Zespół metadanych LinkedIn przedstawił wcześniej (następca WhereHows), platformy wyszukiwania i odkrywania metadanych LinkedIn oraz wspólnych planów jej otwarcia. Krótko po tym ogłoszeniu wydaliśmy wersję alfa DataHub i udostępniliśmy ją społeczności. Od tego czasu stale współtworzymy repozytorium i współpracowaliśmy z zainteresowanymi użytkownikami, aby dodać najbardziej pożądane funkcje i rozwiązać problemy. Mamy teraz przyjemność ogłosić oficjalną premierę .
Podejścia typu open source
WhereHows, autorski portal LinkedIn służący do wyszukiwania danych i ich pochodzenia, powstał jako projekt wewnętrzny; otworzył go zespół metadanych . Od tego czasu zespół zawsze utrzymywał dwie różne bazy kodów — jedną dla oprogramowania typu open source i jedną do użytku wewnętrznego LinkedIn — ponieważ nie wszystkie funkcje produktów opracowane na potrzeby zastosowań LinkedIn miały ogólne zastosowanie dla szerszej publiczności. Dodatkowo WhereHows ma pewne wewnętrzne zależności (infrastruktura, biblioteki itp.), które nie są open source. W następnych latach WhereHows przeszło wiele iteracji i cykli rozwoju, co sprawiło, że synchronizacja obu baz kodów była dużym wyzwaniem. Zespół ds. metadanych przez lata próbował różnych podejść, aby zapewnić synchronizację rozwoju wewnętrznego i oprogramowania open source.
Pierwsza próba: „Najpierw open source”
Początkowo podążaliśmy za modelem rozwoju „najpierw open source”, w którym większość prac programistycznych odbywa się w repozytorium open source, a zmiany wprowadza się do wdrożenia wewnętrznego. Problem z tym podejściem polega na tym, że kod jest zawsze najpierw przesyłany do GitHuba, zanim zostanie w pełni sprawdzony wewnętrznie. Dopóki nie zostaną wprowadzone zmiany w repozytorium open source i nie zostanie wykonane nowe wewnętrzne wdrożenie, nie znajdziemy żadnych problemów produkcyjnych. W przypadku nieprawidłowego wdrożenia bardzo trudno było ustalić winowajcę, ponieważ zmiany wprowadzano partiami.
Dodatkowo model ten zmniejszał produktywność zespołu podczas opracowywania nowych funkcji wymagających szybkich iteracji, ponieważ wymuszał wypychanie wszystkich zmian najpierw do repozytorium open source, a następnie do repozytorium wewnętrznego. Aby skrócić czas przetwarzania, można najpierw wprowadzić wymaganą poprawkę lub zmianę w repozytorium wewnętrznym, ale stało się to ogromnym problemem, gdy przyszło do scalania tych zmian z powrotem z repozytorium open source, ponieważ oba repozytoria nie były zsynchronizowane.
Model ten jest znacznie łatwiejszy do wdrożenia w przypadku współdzielonych platform, bibliotek lub projektów infrastrukturalnych niż w przypadku w pełni funkcjonalnych, niestandardowych aplikacji internetowych. Dodatkowo model ten jest idealny do projektów, które od pierwszego dnia rozpoczynają pracę w trybie open source, ale WhereHows zostało zbudowane jako całkowicie wewnętrzna aplikacja internetowa. Naprawdę trudno było całkowicie wyabstrahować wszystkie wewnętrzne zależności, więc musieliśmy zachować wewnętrzny fork, ale utrzymanie wewnętrznego forka i rozwijanie głównie open source nie do końca wyszło.
Druga próba: „Najpierw wnętrze”
** Jako drugą próbę przeszliśmy do modelu rozwoju „najpierw wewnętrznego”, w którym większość prac nad oprogramowaniem odbywa się wewnętrznie, a w otwartym kodzie źródłowym regularnie wprowadzane są zmiany. Chociaż ten model najlepiej pasuje do naszego przypadku użycia, wiąże się z nieodłącznymi problemami. Bezpośrednie wypychanie wszystkich różnic do repozytorium open source, a następnie próba rozwiązania konfliktów podczas scalania później jest opcją, ale jest czasochłonna. Programiści w większości przypadków starają się tego nie robić za każdym razem, gdy przeglądają swój kod. W rezultacie będzie to wykonywane znacznie rzadziej, partiami, co utrudni późniejsze rozwiązywanie konfliktów scalania.
Za trzecim razem się udało!
Dwie nieudane próby wymienione powyżej spowodowały, że repozytorium WhereHows GitHub pozostało przez długi czas nieaktualne. Zespół w dalszym ciągu udoskonalał funkcje i architekturę produktu, dzięki czemu wewnętrzna wersja WhereHows dla LinkedIn stała się bardziej zaawansowana niż wersja open source. Otrzymał nawet nową nazwę – DataHub. Bazując na wcześniejszych nieudanych próbach, zespół zdecydował się opracować skalowalne, długoterminowe rozwiązanie.
W przypadku każdego nowego projektu open source zespół LinkedIn ds. open source doradza i wspiera model rozwoju, w którym moduły projektu są opracowywane w całości w formacie open source. Wersjonowane artefakty są wdrażane w publicznym repozytorium, a następnie ponownie sprawdzane w wewnętrznym artefakcie LinkedIn przy użyciu . Podążanie za tym modelem rozwoju jest dobre nie tylko dla tych, którzy korzystają z oprogramowania typu open source, ale także skutkuje bardziej modułową, rozszerzalną i podłączalną architekturą.
Jednak dojrzała aplikacja zaplecza, taka jak DataHub, będzie wymagała znacznej ilości czasu, aby osiągnąć ten stan. Wyklucza to również możliwość udostępnienia w pełni działającej implementacji na zasadach open source, zanim wszystkie wewnętrzne zależności zostaną w pełni wyodrębnione. Dlatego opracowaliśmy narzędzia, które pomagają nam szybciej i przy znacznie mniejszym wysiłku tworzyć materiały open source. Rozwiązanie to przynosi korzyści zarówno zespołowi metadanych (programiście DataHub), jak i społeczności open source. W poniższych sekcjach omówione zostanie to nowe podejście.
Automatyzacja publikacji typu open source
Najnowszym podejściem zespołu Metadata do open source DataHub jest opracowanie narzędzia, które automatycznie synchronizuje wewnętrzną bazę kodu i repozytorium open source. Zaawansowane funkcje tego zestawu narzędzi obejmują:
- Synchronizuj kod LinkedIn z/z open source, podobnie .
- Generowanie nagłówka licencji, podobnie jak .
- Automatycznie generuj dzienniki zatwierdzeń typu open source na podstawie wewnętrznych dzienników zatwierdzeń.
- Zapobiegaj zmianom wewnętrznym, które psują kompilacje open source .
W poniższych podrozdziałach omówimy wyżej wymienione funkcje, które wiążą się z interesującymi problemami.
Synchronizacja kodu źródłowego
W przeciwieństwie do wersji DataHub o otwartym kodzie źródłowym, która jest pojedynczym repozytorium GitHub, wersja DataHub na LinkedIn stanowi kombinację wielu repozytoriów (zwanych wewnętrznie ). Interfejs DataHub, biblioteka modeli metadanych, usługa zaplecza hurtowni metadanych i zadania przesyłania strumieniowego znajdują się w oddzielnych repozytoriach na LinkedIn. Aby jednak ułatwić użytkownikom open source, mamy jedno repozytorium dla wersji DataHub o otwartym kodzie źródłowym.
Rysunek 1: Synchronizacja pomiędzy repozytoriami LinkedIn Centrum danych i jedno repozytorium Centrum danych otwarte źródło
Aby obsługiwać zautomatyzowane przepływy pracy związane z budowaniem, wypychaniem i ściąganiem, nasze nowe narzędzie automatycznie tworzy mapowanie na poziomie pliku odpowiadające każdemu plikowi źródłowemu. Jednakże zestaw narzędzi wymaga wstępnej konfiguracji, a użytkownicy muszą zapewnić mapowanie modułów wysokiego poziomu, 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"
]
}Mapowanie na poziomie modułu to prosty JSON, którego kluczami są moduły docelowe w repozytorium open source, a wartościami jest lista modułów źródłowych w repozytoriach LinkedIn. Dowolny moduł docelowy w repozytorium open source może być zasilany przez dowolną liczbę modułów źródłowych. Aby wskazać wewnętrzne nazwy repozytoriów w modułach źródłowych, użyj w stylu Basha. Korzystając z pliku mapowania na poziomie modułu, narzędzia tworzą plik mapowania na poziomie pliku, 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,
}Mapowanie na poziomie pliku jest tworzone automatycznie przez narzędzia; jednakże może być również aktualizowany ręcznie przez użytkownika. Jest to mapowanie 1:1 pliku źródłowego LinkedIn na plik w repozytorium open source. Z automatycznym tworzeniem skojarzeń plików wiąże się kilka reguł:
- W przypadku wielu modułów źródłowych dla modułu docelowego w open source mogą wystąpić konflikty np. takie same , istniejący w więcej niż jednym module źródłowym. Jako strategia rozwiązywania konfliktów, nasze narzędzia domyślnie korzystają z opcji „ostatni wygrywa”.
- „null” oznacza, że plik źródłowy nie jest częścią repozytorium open source.
- Po każdym przesłaniu lub wyodrębnieniu kodu open source to mapowanie jest automatycznie aktualizowane i tworzona jest migawka. Jest to konieczne do zidentyfikowania dodatków i usunięć w kodzie źródłowym od czasu ostatniej akcji.
Tworzenie dzienników zatwierdzeń
Dzienniki zatwierdzeń dla zatwierdzeń typu open source są również generowane automatycznie poprzez połączenie dzienników zatwierdzeń z wewnętrznych repozytoriów. Poniżej znajduje się przykładowy dziennik zatwierdzeń pokazujący strukturę dziennika zatwierdzeń wygenerowanego przez nasze narzędzie. Zatwierdzenie wyraźnie wskazuje, które wersje repozytoriów źródłowych są spakowane w tym zatwierdzeniu i dostarcza podsumowanie dziennika zatwierdzeń. Sprawdź ten używając prawdziwego przykładu dziennika zatwierdzeń wygenerowanego przez nasz zestaw narzędzi.
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.0Testowanie zależności
LinkedIn ma , co pomaga zapewnić, że zmiany w wewnętrznym multiproduktie nie zakłócają zestawu zależnych multiproduktów. Repozytorium DataHub typu open source nie obejmuje wielu produktów i nie może być bezpośrednio zależne od żadnego wielu produktów, ale przy pomocy opakowania obejmującego wiele produktów, które pobiera kod źródłowy DataHub typu open source, nadal możemy korzystać z tego testowania zależności Zatem każda zmiana (która może później zostać ujawniona) w dowolnym multiproduktie zasilającym repozytorium DataHub typu open source wyzwala zdarzenie kompilacji w multiproduktie powłoki. Dlatego każda zmiana, która nie doprowadzi do powstania produktu w opakowaniu, nie przejdzie testów przed zatwierdzeniem oryginalnego produktu i zostanie cofnięta.
Jest to przydatny mechanizm, który pomaga zapobiegać wszelkim wewnętrznym zatwierdzeniom, które psują kompilację open source i wykrywają je w czasie zatwierdzania. Bez tego dość trudno byłoby określić, które zatwierdzenie wewnętrzne spowodowało niepowodzenie kompilacji repozytorium open source, ponieważ wewnętrzne zmiany są wsadowe do repozytorium open source DataHub.
Różnice pomiędzy open source DataHub a naszą wersją produkcyjną
Do tego momentu omawialiśmy nasze rozwiązanie umożliwiające synchronizację dwóch wersji repozytoriów DataHub, ale nadal nie wyjaśniliśmy powodów, dla których potrzebujemy w pierwszej kolejności dwóch różnych strumieni programistycznych. W tej sekcji wymienimy różnice pomiędzy publiczną wersją DataHub a wersją produkcyjną na serwerach LinkedIn i wyjaśnimy przyczyny tych różnic.
Jedno ze źródeł rozbieżności wynika z faktu, że nasza wersja produkcyjna jest zależna od kodu, który nie jest jeszcze oprogramowaniem typu open source, takim jak Offspring firmy LinkedIn (wewnętrzna platforma wstrzykiwania zależności LinkedIn). Narzędzie potomne jest szeroko stosowane w wewnętrznych bazach kodu, ponieważ jest preferowaną metodą zarządzania konfiguracją dynamiczną. Ale nie jest to oprogramowanie typu open source; dlatego musieliśmy znaleźć alternatywę typu open source dla DataHub o otwartym kodzie źródłowym.
Są też inne powody. Ponieważ tworzymy rozszerzenia modelu metadanych na potrzeby LinkedIn, rozszerzenia te są zazwyczaj bardzo specyficzne dla LinkedIn i mogą nie mieć bezpośredniego zastosowania w innych środowiskach. Na przykład mamy bardzo szczegółowe etykiety dla identyfikatorów uczestników i innych typów pasujących metadanych. Dlatego wykluczyliśmy te rozszerzenia z modelu metadanych open source DataHub. W miarę nawiązywania kontaktu ze społecznością i rozumienia jej potrzeb, w razie potrzeby będziemy pracować nad powszechnymi wersjami tych rozszerzeń typu open source.
Łatwość użycia i łatwiejsza adaptacja dla społeczności open source również zainspirowała niektóre różnice między dwiema wersjami DataHub. Dobrym tego przykładem są różnice w infrastrukturze przetwarzania strumieni. Chociaż nasza wersja wewnętrzna korzysta ze struktury zarządzanego przetwarzania strumieniowego, zdecydowaliśmy się użyć wbudowanego (samodzielnego) przetwarzania strumieniowego w wersji open source, ponieważ pozwala to uniknąć tworzenia kolejnej zależności od infrastruktury.
Innym przykładem różnicy jest posiadanie jednego GMS (Generalized Metadata Store) w implementacji open source zamiast wielu GMS. GMA (Generalized Metadata Architecture) to nazwa architektury zaplecza DataHub, a GMS to magazyn metadanych w kontekście GMA. GMA to bardzo elastyczna architektura, która pozwala na dystrybucję każdej konstrukcji danych (np. zbiorów danych, użytkowników itp.) do własnego magazynu metadanych lub przechowywanie wielu konstrukcji danych w jednym magazynie metadanych, o ile rejestr zawierający mapowanie struktury danych w GMS jest zaktualizowany. Aby ułatwić obsługę, wybraliśmy pojedynczą instancję GMS, która przechowuje wszystkie różne konstrukcje danych w DataHub o otwartym kodzie źródłowym.
Pełną listę różnic pomiędzy obiema implementacjami podano w poniższej tabeli.
cechy produktu
Centrum danych LinkedIn
Centrum danych typu open source
Obsługiwane konstrukcje danych
1) Zbiory danych 2) Użytkownicy 3) Metryki 4) Funkcje ML 5) Wykresy 6) Pulpity nawigacyjne
1) Zbiory danych 2) Użytkownicy
Obsługiwane źródła metadanych dla zestawów danych
1) 2) Podstawa kanapy 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Wektor 14)
Hive Kafka RDBMS
Pub-sub
Zlewający się Kafka
Przetwarzanie strumieniowe
zarządzane
Wbudowany (samodzielny)
Wstrzykiwanie zależności i konfiguracja dynamiczna
Potomstwo LinkedIn
Budowanie oprzyrządowania
Ligradle (wewnętrzne opakowanie Gradle LinkedIn)
CI / CD
CRT (wewnętrzny CI/CD LinkedIn)
i
Magazyny metadanych
Rozproszone wiele GMS: 1) GMS zbioru danych 2) GMS użytkownika 3) GMS metryczne 4) GMS funkcji 5) Wykres/pulpit GMS
Pojedynczy GMS dla: 1) Zbiorów Danych 2) Użytkowników
Mikrousługi w kontenerach Docker
upraszcza wdrażanie i dystrybucję aplikacji za pomocą . Każda część usługi w DataHub jest open source, łącznie z komponentami infrastruktury, takimi jak Kafka, , и , ma swój własny obraz Dockera. Do orkiestracji kontenerów Dockera używaliśmy .
Rysunek 2: Architektura Centrum danych *otwarte źródło**
Na powyższym obrazku możesz zobaczyć architekturę wysokiego poziomu DataHub. Oprócz komponentów infrastruktury zawiera cztery różne kontenery Docker:
datahub-gms: usługa przechowywania metadanych
datahub-frontend: aplikacja , obsługujący interfejs DataHub.
datahub-mce-consumer: aplikacja , który korzysta ze strumienia zdarzenia zmiany metadanych (MCE) i aktualizuje magazyn metadanych.
datahub-mae-consumer: aplikacja , który wykorzystuje strumień zdarzeń kontroli metadanych (MAE) i tworzy indeks wyszukiwania oraz bazę danych grafów.
Dokumentacja repozytorium open source i zawierają bardziej szczegółowe informacje na temat funkcji poszczególnych usług.
CI/CD w DataHub jest oprogramowaniem typu open source
Wykorzystuje repozytorium DataHub typu open source do ciągłej integracji i do ciągłego wdrażania. Obydwa mają dobrą integrację z GitHubem i są łatwe w konfiguracji. W przypadku większości infrastruktury open source opracowanej przez społeczność lub firmy prywatne (np. ), obrazy Dockera są tworzone i wdrażane w Docker Hub, aby ułatwić korzystanie z nich przez społeczność. Dowolnego obrazu Dockera znalezionego w Docker Hub można łatwo użyć za pomocą prostego polecenia .
Przy każdym zatwierdzeniu w repozytorium open source DataHub wszystkie obrazy Dockera są automatycznie tworzone i wdrażane w Docker Hub z tagiem „najnowsze”. Jeśli Docker Hub jest skonfigurowany z niektórymi , wszystkie tagi w repozytorium open source są również wydawane z odpowiadającymi im nazwami w Docker Hub.
Korzystanie z DataHuba
jest bardzo proste i składa się z trzech prostych kroków:
- Sklonuj repozytorium open source i uruchom wszystkie kontenery Docker za pomocą narzędzia docker-compose, korzystając z dostarczonego skryptu docker-compose, aby szybko rozpocząć.
- Pobierz przykładowe dane znajdujące się w repozytorium za pomocą dołączonego narzędzia wiersza poleceń.
- Przeglądaj DataHub w przeglądarce.
Aktywnie śledzone skonfigurowany również do szybkich pytań. Użytkownicy mogą także tworzyć problemy bezpośrednio w repozytorium GitHub. Co najważniejsze, jesteśmy otwarci i wdzięczni za wszelkie opinie i sugestie!
Plany na przyszłość
Obecnie każda infrastruktura lub mikrousługa dla DataHub typu open source jest zbudowana jako kontener Docker, a cały system jest koordynowany przy użyciu . Biorąc pod uwagę popularność i powszechne , chcielibyśmy również w najbliższej przyszłości udostępnić rozwiązanie oparte na Kubernetesie.
Planujemy również dostarczenie rozwiązania „pod klucz” do wdrożenia DataHub w publicznej usłudze chmury, takiej jak , lub . Biorąc pod uwagę niedawne ogłoszenie migracji LinkedIn na platformę Azure, będzie to zgodne z wewnętrznymi priorytetami zespołu ds. metadanych.
Na koniec dziękujemy wszystkim pierwszym użytkownikom DataHub w społeczności open source, którzy ocenili wersje alfa DataHub i pomogli nam zidentyfikować problemy i ulepszyć dokumentację.
Źródło: www.habr.com