Open Source DataHub: Platforma pro vyhledávání a zjišťování metadat LinkedIn
Rychlé nalezení potřebných dat je zásadní pro každou společnost, která se při rozhodování na základě dat spoléhá na velké množství dat. To má vliv nejen na produktivitu uživatelů dat (včetně analytiků, vývojářů strojového učení, datových vědců a datových inženýrů), ale má to také přímý dopad na konečné produkty, které závisí na kvalitním kanálu strojového učení (ML). Navíc trend k implementaci nebo budování platforem strojového učení přirozeně vyvolává otázku: jaká je vaše metoda pro interní objevování funkcí, modelů, metrik, datových sad atd.
V tomto článku budeme hovořit o tom, jak jsme publikovali zdroj dat pod otevřenou licencí v naší platformě pro vyhledávání a zjišťování metadat, počínaje počátky projektu . LinkedIn spravuje svou vlastní verzi DataHubu odděleně od verze s otevřeným zdrojovým kódem. Začneme vysvětlením, proč potřebujeme dvě samostatná vývojová prostředí, poté probereme rané přístupy k používání open source WhereHows a porovnáme naši interní (produkční) verzi DataHubu s verzí na . Budeme také sdílet podrobnosti o našem novém automatizovaném řešení pro odesílání a přijímání aktualizací s otevřeným zdrojovým kódem, aby byla obě úložiště synchronizována. Nakonec poskytneme návod, jak začít používat open source DataHub, a krátce probereme jeho architekturu.
WhereHows je nyní DataHub!
Tým metadat LinkedIn již dříve představil (nástupce WhereHows), platforma LinkedIn pro vyhledávání a zjišťování metadat a sdílené plány na její otevření. Krátce po tomto oznámení jsme vydali alfa verzi DataHubu a sdíleli ji s komunitou. Od té doby neustále přispíváme do úložiště a spolupracujeme se zainteresovanými uživateli na přidávání nejžádanějších funkcí a řešení problémů. Nyní s potěšením oznamujeme oficiální vydání .
Open Source přístupy
WhereHows, původní portál LinkedIn pro vyhledávání dat a odkud pocházejí, začal jako interní projekt; tým metadat jej otevřel . Od té doby tým vždy udržoval dvě různé kódové báze – jednu pro open source a jednu pro interní použití LinkedIn – protože ne všechny funkce produktu vyvinuté pro případy použití LinkedIn byly obecně použitelné pro širší publikum. Kromě toho má WhereHows některé vnitřní závislosti (infrastruktura, knihovny atd.), které nejsou open source. V následujících letech prošel WhereHows mnoha iteracemi a vývojovými cykly, takže udržení synchronizace těchto dvou kódových základen bylo velkou výzvou. Tým metadat zkoušel v průběhu let různé přístupy, aby se pokusil udržet interní a open source vývoj v synchronizaci.
První pokus: "Nejdříve otevřený zdroj"
Zpočátku jsme se řídili vývojovým modelem „open source first“, kde většina vývoje probíhá v open source úložišti a změny jsou prováděny pro interní nasazení. Problém s tímto přístupem je, že kód je vždy nejprve odeslán na GitHub, než bude plně zkontrolován interně. Dokud nebudou provedeny změny z úložiště s otevřeným zdrojovým kódem a nebude provedeno nové interní nasazení, nenajdeme žádné produkční problémy. V případě špatného nasazení bylo také velmi obtížné určit viníka, protože změny byly prováděny v dávkách.
Tento model navíc snížil produktivitu týmu při vývoji nových funkcí, které vyžadovaly rychlé iterace, protože všechny změny musely být nejprve vloženy do úložiště s otevřeným zdrojovým kódem a poté přeneseny do interního úložiště. Aby se zkrátila doba zpracování, požadovaná oprava nebo změna mohla být provedena nejprve v interním úložišti, ale to se stalo obrovským problémem, když došlo ke sloučení těchto změn zpět do úložiště s otevřeným zdrojovým kódem, protože tyto dva repozitáře nebyly synchronizovány.
Tento model je mnohem snazší implementovat pro sdílené platformy, knihovny nebo infrastrukturní projekty než pro plně vybavené vlastní webové aplikace. Tento model je navíc ideální pro projekty, které začínají s otevřeným zdrojovým kódem od prvního dne, ale WhereHows byl vytvořen jako zcela interní webová aplikace. Bylo opravdu těžké úplně abstrahovat všechny vnitřní závislosti, takže jsme potřebovali ponechat interní vidlici, ale zachování interní vidlice a vývoj převážně open source se tak úplně neosvědčilo.
Druhý pokus: „Nejprve vnitřní“
**Jako druhý pokus jsme přešli na model vývoje „nejprve interní“, kde většina vývoje probíhá interně a změny v otevřeném zdrojovém kódu jsou prováděny pravidelně. Přestože se tento model nejlépe hodí pro náš případ použití, má své vlastní problémy. Možnost přímého přenesení všech rozdílů do úložiště s otevřeným zdrojovým kódem a následného pokusu o vyřešení konfliktů sloučení později, ale je to časově náročné. Vývojáři se to ve většině případů snaží nedělat pokaždé, když kontrolují svůj kód. V důsledku toho se to bude provádět mnohem méně často, v dávkách, a proto je pozdější řešení konfliktů sloučení obtížnější.
Napotřetí to vyšlo!
Dva neúspěšné pokusy uvedené výše vedly k tomu, že úložiště GitHub WhereHows zůstalo po dlouhou dobu neaktuální. Tým pokračoval ve vylepšování funkcí a architektury produktu, takže interní verze WhereHows pro LinkedIn se stala pokročilejší než verze s otevřeným zdrojovým kódem. Měl dokonce nový název – DataHub. Na základě předchozích neúspěšných pokusů se tým rozhodl vyvinout škálovatelné, dlouhodobé řešení.
U každého nového open source projektu radí a podporuje open source tým LinkedIn vývojový model, ve kterém jsou moduly projektu vyvíjeny výhradně v open source. Verzované artefakty jsou nasazeny do veřejného úložiště a poté zkontrolovány zpět do interního artefaktu LinkedIn pomocí . Následování tohoto modelu vývoje je dobré nejen pro ty, kteří používají open source, ale také vede k modulárnější, rozšiřitelnější a připojitelnější architektuře.
Vyspělá back-endová aplikace, jako je DataHub, však bude vyžadovat značné množství času, než dosáhne tohoto stavu. To také vylučuje možnost otevřeného zdroje plně funkční implementace před úplným odstraněním všech vnitřních závislostí. Proto jsme vyvinuli nástroje, které nám pomáhají vytvářet open source příspěvky rychleji a s mnohem menší bolestí. Toto řešení je přínosné jak pro tým metadat (vývojář DataHub), tak pro komunitu open source. Následující oddíly se budou zabývat tímto novým přístupem.
Automatizace publikování s otevřeným zdrojem
Nejnovějším přístupem týmu Metadata k open source DataHub je vývoj nástroje, který automaticky synchronizuje interní kódovou základnu a open source repozitář. Mezi funkce této sady nástrojů na vysoké úrovni patří:
- Synchronizujte kód LinkedIn do/z open source, podobně .
- Generování hlavičky licence, podobně jako .
- Automaticky generovat open source protokoly odevzdání z interních protokolů odevzdání.
- Zabraňte interním změnám, které narušují sestavení open source .
Následující podkapitoly se ponoří do výše zmíněných funkcí, které mají zajímavé problémy.
Synchronizace zdrojového kódu
Na rozdíl od open source verze DataHubu, což je jediné úložiště GitHub, LinkedIn verze DataHubu je kombinací více úložišť (nazývaných interně ). Rozhraní DataHub, knihovna modelů metadat, backendová služba metadatového skladu a úlohy streamování jsou umístěny v samostatných úložištích na LinkedIn. Abychom to však uživatelům s otevřeným zdrojovým kódem usnadnili, máme pro open source verzi DataHubu jediné úložiště.
Obrázek 1: Synchronizace mezi repozitáři LinkedIn DataHub a jediné úložiště DataHub otevřený zdroj
Náš nový nástroj automaticky vytváří mapování na úrovni souborů odpovídající každému zdrojovému souboru, abychom podpořili automatizované pracovní postupy sestavení, push a pull. Sada nástrojů však vyžaduje počáteční konfiguraci a uživatelé musí poskytnout mapování modulů na vysoké úrovni, jak je uvedeno níže.
{
"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"
]
}Mapování na úrovni modulu je jednoduchý JSON, jehož klíče jsou cílové moduly v úložišti s otevřeným zdrojovým kódem a hodnoty jsou seznam zdrojových modulů v úložištích LinkedIn. Jakýkoli cílový modul v úložišti s otevřeným zdrojovým kódem může být napájen libovolným počtem zdrojových modulů. Chcete-li uvést interní názvy úložišť ve zdrojových modulech, použijte ve stylu Bash. Pomocí souboru mapování na úrovni modulu nástroje vytvoří soubor mapování na úrovni souboru prohledáním všech souborů v přidružených adresářích.
{
"${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,
}Mapování úrovně souboru je automaticky vytvořeno nástroji; může však být také ručně aktualizován uživatelem. Toto je mapování 1:1 zdrojového souboru LinkedIn na soubor v úložišti open source. S tímto automatickým vytvářením přidružení souborů je spojeno několik pravidel:
- V případě více zdrojových modulů pro cílový modul v open source mohou nastat konflikty, např. , existující ve více než jednom zdrojovém modulu. Jako strategii řešení konfliktů naše nástroje standardně používají možnost „poslední vyhrává“.
- "null" znamená, že zdrojový soubor není součástí úložiště s otevřeným zdrojovým kódem.
- Po každém odeslání nebo extrakci open source se toto mapování automaticky aktualizuje a vytvoří se snímek. To je nezbytné pro identifikaci přidání a odstranění ze zdrojového kódu od poslední akce.
Vytváření protokolů odevzdání
Protokoly potvrzení pro potvrzení s otevřeným zdrojovým kódem jsou také automaticky generovány sloučením protokolů potvrzení interních úložišť. Níže je ukázkový protokol odevzdání, který ukazuje strukturu protokolu odevzdání generovaného naším nástrojem. Potvrzení jasně uvádí, které verze zdrojových úložišť jsou v tomto potvrzení zabaleny, a poskytuje souhrn protokolu odevzdání. Podívejte se na tohle pomocí skutečného příkladu protokolu odevzdání generovaného naší sadou nástrojů.
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.0Testování závislosti
LinkedIn má , což pomáhá zajistit, že změny interního multiproduktu nenaruší sestavu závislých multiproduktů. Open source úložiště DataHub není multiproduktové a nemůže být přímou závislostí na žádném multiproduktu, ale s pomocí multiproduktového obalu, který načítá zdrojový kód DataHub s otevřeným zdrojovým kódem, můžeme stále používat toto testování závislosti. Jakákoli změna (která může být později odhalena) na kterémkoli z multiproduktů, které napájejí open source úložiště DataHub, spustí událost sestavení v multiproduktu shellu. Jakákoli změna, která selže při sestavení obalového produktu, proto neprojde testy před provedením původního produktu a bude vrácena zpět.
Jedná se o užitečný mechanismus, který pomáhá zabránit jakémukoli internímu odevzdání, které naruší sestavení open source a detekuje ho v době odevzdání. Bez toho by bylo docela obtížné určit, které interní potvrzení způsobilo selhání sestavení úložiště s otevřeným zdrojovým kódem, protože interní změny v open source úložišti DataHub dávkujeme.
Rozdíly mezi open source DataHub a naší produkční verzí
Až do tohoto bodu jsme diskutovali o našem řešení pro synchronizaci dvou verzí úložišť DataHub, ale stále jsme nenastínili důvody, proč potřebujeme dva různé vývojové proudy. V této části uvedeme rozdíly mezi veřejnou verzí DataHubu a produkční verzí na serverech LinkedIn a vysvětlíme důvody těchto rozdílů.
Jeden zdroj nesrovnalostí pramení ze skutečnosti, že naše produkční verze má závislosti na kódu, který ještě není open source, jako je LinkedIn's Offspring (interní rámec pro vkládání závislostí LinkedIn). Offspring je široce používán v interních kódových základnách, protože je to preferovaná metoda pro správu dynamické konfigurace. Ale není to open source; takže jsme potřebovali najít open source alternativy k open source DataHubu.
Existují i jiné důvody. Při vytváření rozšíření metadatového modelu pro potřeby LinkedIn jsou tato rozšíření obvykle velmi specifická pro LinkedIn a nemusí se přímo vztahovat na jiná prostředí. Máme například velmi specifické štítky pro ID účastníků a další typy odpovídajících metadat. Nyní jsme tedy tato rozšíření vyloučili z modelu metadat s otevřeným zdrojovým kódem DataHub. Když se zapojíme do komunity a pochopíme její potřeby, budeme v případě potřeby pracovat na společných verzích těchto rozšíření s otevřeným zdrojovým kódem.
Snadné použití a snadnější přizpůsobení pro komunitu open source také inspirovalo některé rozdíly mezi dvěma verzemi DataHubu. Rozdíly v infrastruktuře zpracování datových proudů jsou toho dobrým příkladem. Přestože naše interní verze používá řízený rámec pro zpracování datových proudů, rozhodli jsme se pro verzi s otevřeným zdrojovým kódem použít vestavěné (samostatné) zpracování datových proudů, protože se tak vyhne vytváření další závislosti na infrastruktuře.
Dalším příkladem rozdílu je použití jediného GMS (Generalized Metadata Store) v implementaci s otevřeným zdrojovým kódem namísto více GMS. GMA (Generalized Metadata Architecture) je název back-endové architektury pro DataHub a GMS je úložiště metadat v kontextu GMA. GMA je velmi flexibilní architektura, která vám umožňuje distribuovat každý datový konstrukt (např. datové sady, uživatele atd.) do jeho vlastního úložiště metadat nebo uložit více datových konstruktů do jednoho úložiště metadat, pokud registr obsahující mapování datové struktury v GMS je aktualizován. Pro snadné použití jsme vybrali jedinou instanci GMS, která ukládá všechny různé datové konstrukce v open source DataHubu.
Kompletní seznam rozdílů mezi těmito dvěma implementacemi je uveden v tabulce níže.
Vlastnosti produktu
LinkedIn DataHub
Open Source DataHub
Podporované datové konstrukce
1) Soubory dat 2) Uživatelé 3) Metriky 4) Funkce ML 5) Grafy 6) Řídicí panely
1) Soubory dat 2) Uživatelé
Podporované zdroje metadat pro datové sady
1) 2) Couchbase 3) 4) 5) HDFS 6) Úl 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vektor 14)
Úl Kafka RDBMS
Pub-sub
Splývající Kafka
Streamové zpracování
Managed
Vestavěný (samostatný)
Dependency Injection & Dynamic Configuration
LinkedIn Offspring
Build Tooling
Ligradle (interní obal Gradle na LinkedIn)
CI / CD
CRT (interní CI/CD LinkedIn)
a
Úložiště metadat
Distribuované více GMS: 1) Dataset GMS 2) Uživatelský GMS 3) Metrický GMS 4) Funkce GMS 5) Graf/Dashboard GMS
Jediný GMS pro: 1) Datové sady 2) Uživatele
Mikroslužby v kontejnerech Docker
zjednodušuje nasazení a distribuci aplikací s . Každá část služby v DataHubu je open source, včetně komponent infrastruktury, jako je Kafka, , и , má svůj vlastní obrázek Docker. K orchestraci kontejnerů Docker, které jsme použili .
Obrázek 2: Architektura DataHub *otevřený zdroj**
Vysokoúrovňovou architekturu DataHubu můžete vidět na obrázku výše. Kromě komponent infrastruktury má čtyři různé kontejnery Docker:
datahub-gms: služba ukládání metadat
datahub-frontend: aplikace , obsluhující rozhraní DataHub.
datahub-mce-consumer: aplikace , který používá stream události změny metadat (MCE) a aktualizuje úložiště metadat.
datahub-mae-consumer: aplikace , který používá tok událostí auditu metadat (MAE) a vytváří vyhledávací index a databázi grafů.
Dokumentace úložiště s otevřeným zdrojovým kódem a obsahují podrobnější informace o funkcích různých služeb.
CI/CD na DataHubu je open source
Používá se open source úložiště DataHub pro nepřetržitou integraci a pro nepřetržité nasazení. Oba mají dobrou integraci GitHub a snadno se nastavují. U většiny open source infrastruktury vyvinuté komunitou nebo soukromými společnostmi (např. ), Docker obrazy jsou vytvářeny a nasazovány do Docker Hub pro snadné použití komunitou. Jakýkoli obrázek Docker nalezený v Docker Hub lze snadno použít pomocí jednoduchého příkazu .
S každým odevzdáním do úložiště s otevřeným zdrojovým kódem DataHub jsou všechny obrázky Docker automaticky sestaveny a nasazeny do Docker Hub s označením „nejnovější“. Pokud je Docker Hub nakonfigurován s některými , všechny značky v úložišti s otevřeným zdrojovým kódem jsou také vydány s odpovídajícími názvy značek v Docker Hub.
Pomocí DataHubu
je velmi jednoduchý a skládá se ze tří jednoduchých kroků:
- Klonujte úložiště s otevřeným zdrojovým kódem a spusťte všechny kontejnery Docker pomocí docker-compose pomocí poskytnutého skriptu docker-compose pro rychlý začátek.
- Stáhněte si ukázková data poskytnutá v úložišti pomocí nástroje příkazového řádku, který je také k dispozici.
- Procházejte DataHub ve svém prohlížeči.
Aktivně sledováno také nakonfigurován pro rychlé dotazy. Uživatelé mohou také vytvářet problémy přímo v úložišti GitHub. A co je nejdůležitější, vítáme a oceňujeme každou zpětnou vazbu a návrhy!
Plány do budoucna
V současné době je každá infrastruktura nebo mikroslužba pro open source DataHub postavena jako kontejner Docker a celý systém je organizován pomocí . Vzhledem k popularitě a rozšířenosti , rádi bychom také v blízké budoucnosti poskytli řešení založené na Kubernetes.
Plánujeme také poskytnout řešení na klíč pro nasazení DataHubu na veřejné cloudové službě jako je např , nebo . Vzhledem k nedávnému oznámení o migraci LinkedIn do Azure to bude v souladu s interními prioritami týmu pro metadata.
V neposlední řadě patří poděkování všem prvním uživatelům DataHubu v komunitě s otevřeným zdrojovým kódem, kteří hodnotili DataHub alfa a pomohli nám identifikovat problémy a zlepšit dokumentaci.
Zdroj: www.habr.com