Nyílt forráskódú DataHub: LinkedIn Metadata Search and Discovery Platform
A szükséges adatok gyors megtalálása elengedhetetlen minden olyan vállalat számára, amely nagy mennyiségű adatra támaszkodik az adatközpontú döntések meghozatalához. Ez nemcsak az adatfelhasználók (beleértve az elemzőket, gépi tanulási fejlesztőket, adattudósokat és adatmérnököket) termelékenységét befolyásolja, hanem közvetlen hatással van a végtermékekre is, amelyek egy minőségi gépi tanulási (ML) folyamattól függenek. Ezenkívül a gépi tanulási platformok bevezetése vagy létrehozása felé irányuló tendencia természetesen felveti a kérdést: mi a módszere a funkciók, modellek, mutatók, adatkészletek stb. belső felfedezésére.
Ebben a cikkben arról lesz szó, hogyan tettünk közzé adatforrást nyílt licenc alatt a metaadat-kereső és -felfedező platformunkban, a projekt korai napjaitól kezdve . A LinkedIn a DataHub saját verzióját a nyílt forráskódú verziótól elkülönítve tartja karban. Kezdjük azzal, hogy elmagyarázzuk, miért van szükségünk két különálló fejlesztői környezetre, majd megvitatjuk a nyílt forráskódú WhereHows használatának korai megközelítéseit, és összehasonlítjuk a DataHub belső (éles) verzióját a webhelyen lévő verzióval. . Részleteket is megosztunk a nyílt forráskódú frissítések küldésére és fogadására szolgáló új automatizált megoldásunkról, hogy mindkét adattárat szinkronban tartsuk. Végül útmutatást adunk a nyílt forráskódú DataHub használatának megkezdéséhez, és röviden megvitatjuk az architektúráját.
A WhereHows ma már DataHub!
A LinkedIn metaadat-csapata korábban bemutatta (a WhereHows utódja), a LinkedIn keresési és metaadat-felderítő platformja, valamint megosztotta a megnyitására vonatkozó terveket. Röviddel a bejelentés után kiadtuk a DataHub alfa verzióját, és megosztottuk a közösséggel. Azóta folyamatosan hozzájárulunk az adattárhoz, és együttműködünk az érdeklődő felhasználókkal a legkeresettebb szolgáltatások hozzáadása és a problémák megoldása érdekében. Örömmel jelentjük be a hivatalos megjelenést .
Nyílt forráskódú megközelítések
A WhereHows, a LinkedIn eredeti portálja az adatok keresésére és honnan származnak, belső projektként indult; a metaadat-csapat nyitotta meg . Azóta a csapat mindig két különböző kódbázist tart fenn – egyet a nyílt forráskódú, egyet pedig a LinkedIn belső használatához –, mivel nem minden LinkedIn használati esetre kifejlesztett termékfunkció volt általánosan alkalmazható a szélesebb közönség számára. Ezenkívül a WhereHows rendelkezik néhány belső függőséggel (infrastruktúra, könyvtárak stb.), amelyek nem nyílt forráskódúak. A következő években a WhereHows számos iteráción és fejlesztési cikluson ment keresztül, ami nagy kihívást jelentett a két kódbázis szinkronban tartása. A metaadat-csapat az évek során különböző megközelítéseket próbált ki, hogy a belső és a nyílt forráskódú fejlesztéseket szinkronban tartsa.
Első próbálkozás: "Először nyílt forráskód"
Kezdetben a "nyílt forráskódú először" fejlesztési modellt követtük, ahol a legtöbb fejlesztés nyílt forráskódú tárolóban történik, és a változtatásokat a belső telepítés érdekében hajtják végre. Ezzel a megközelítéssel az a probléma, hogy a kód mindig először a GitHubba kerül, mielőtt teljes belső felülvizsgálatra kerülne. Amíg nem hajtanak végre változtatásokat a nyílt forráskódú tárhelyen, és nem hajtanak végre új belső telepítést, addig nem találunk éles problémákat. Rossz kiépítés esetén is nagyon nehéz volt meghatározni a tettest, mert kötegenként történtek változtatások.
Ezenkívül ez a modell csökkentette a csapat termelékenységét a gyors iterációt igénylő új funkciók fejlesztésekor, mivel minden változtatást először nyílt forráskódú tárolóba, majd belső tárolóba kellett áthelyezni. A feldolgozási idő csökkentése érdekében a szükséges javítást vagy módosítást először a belső tárolóban lehetett elvégezni, de ez óriási problémát jelentett, amikor a változtatásokat vissza kellett egyesíteni a nyílt forráskódú tárházba, mivel a két tároló nem volt szinkronban.
Ez a modell sokkal könnyebben megvalósítható megosztott platformok, könyvtárak vagy infrastrukturális projektek esetében, mint a teljes funkcionalitású egyéni webalkalmazások esetében. Ezenkívül ez a modell ideális olyan projektekhez, amelyek az első naptól kezdve nyílt forráskódúak, de a WhereHows teljesen belső webalkalmazásként készült. Nagyon nehéz volt teljesen absztrahálni az összes belső függőséget, ezért meg kellett tartanunk a belső forkot, de a belső elágazás megtartása és a többnyire nyílt forráskódú fejlesztés nem egészen ment.
Második próbálkozás: „első a belső”
**Második próbálkozásként áttértünk egy "első belső" fejlesztési modellre, ahol a legtöbb fejlesztés házon belül történik, és rendszeresen módosítják a nyílt forráskódot. Bár ez a modell felel meg a legjobban a mi használati esetünknek, vannak benne problémák. Lehetséges, hogy minden eltérést közvetlenül a nyílt forráskódú tárba küld, majd később megpróbálja megoldani az összevonási ütközéseket, de ez időigényes. A fejlesztők a legtöbb esetben megpróbálják nem ezt tenni minden alkalommal, amikor átnézik a kódjukat. Emiatt ez sokkal ritkábban, kötegekben történik majd, és így megnehezíti az összevonási konfliktusok későbbi feloldását.
Harmadszorra sikerült!
A fent említett két sikertelen próbálkozás azt eredményezte, hogy a WhereHows GitHub adattár hosszú ideig elavult volt. A csapat folytatta a termék funkcióinak és architektúrájának fejlesztését, így a WhereHows for LinkedIn belső verziója fejlettebb lett, mint a nyílt forráskódú verzió. Még új neve is volt - DataHub. A korábbi sikertelen próbálkozások alapján a csapat egy méretezhető, hosszú távú megoldás kidolgozása mellett döntött.
Minden új nyílt forráskódú projekt esetében a LinkedIn nyílt forráskódú csapata olyan fejlesztési modellt ad és támogat, amelyben a projekt moduljait teljes egészében nyílt forráskódú fejlesztik. A verziójú műtermékek egy nyilvános tárolóba kerülnek, majd visszakerülnek a belső LinkedIn melléktermékbe a . Ennek a fejlesztési modellnek a követése nem csak a nyílt forráskódot használók számára jó, hanem modulárisabb, bővíthetőbb és csatlakoztathatóbb architektúrát is eredményez.
Egy kiforrott háttéralkalmazásnak, például a DataHubnak azonban jelentős időre van szüksége ahhoz, hogy elérje ezt az állapotot. Ez azt is kizárja, hogy egy teljesen működő implementáció nyílt forrásból származzon, mielőtt az összes belső függőséget teljesen absztrahálták volna. Éppen ezért olyan eszközöket fejlesztettünk ki, amelyek segítségével gyorsabban és sokkal kevesebb fájdalommal tegyünk nyílt forráskódú hozzájárulásokat. Ez a megoldás mind a metaadat-csoport (DataHub-fejlesztő), mind a nyílt forráskódú közösség számára előnyös. A következő szakaszok ezt az új megközelítést tárgyalják.
Nyílt forráskódú közzétételi automatizálás
A Metadata csapat legújabb megközelítése a nyílt forráskódú DataHubhoz egy olyan eszköz kifejlesztése, amely automatikusan szinkronizálja a belső kódbázist és a nyílt forráskódú adattárat. Ennek az eszköztárnak a magas szintű szolgáltatásai a következők:
- Szinkronizálja a LinkedIn kódot nyílt forráskóddal/-ből, hasonló .
- Licencfejléc-generálás, hasonló a .
- Nyílt forráskódú véglegesítési naplók automatikus generálása belső véglegesítési naplókból.
- Akadályozza meg a nyílt forráskódú buildeket megszakító belső változtatásokat .
A következő alfejezetek a fent említett funkciókkal foglalkoznak, amelyek érdekes problémákkal küzdenek.
Forráskód szinkronizálás
Ellentétben a DataHub nyílt forráskódú verziójával, amely egyetlen GitHub adattár, a DataHub LinkedIn verziója több adattár kombinációja (ezt belsőleg hívják ). A DataHub felület, a metaadatmodell-könyvtár, a metaadatraktár háttérszolgáltatása és a streaming feladatok a LinkedIn külön lerakataiban találhatók. A nyílt forráskódú felhasználók dolgának megkönnyítése érdekében azonban egyetlen adattárral rendelkezünk a DataHub nyílt forráskódú verziójához.
1. ábra: Szinkronizálás a tárolók között LinkedIn DataHub és egyetlen adattár DataHub nyílt forráskód
Az automatizált build, push és pull munkafolyamatok támogatása érdekében új eszközünk automatikusan létrehoz egy fájlszintű leképezést az egyes forrásfájloknak megfelelően. Az eszközkészlet azonban kezdeti konfigurációt igényel, és a felhasználóknak magas szintű modulleképezést kell biztosítaniuk az alábbiak szerint.
{
"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"
]
}A modulszintű leképezés egy egyszerű JSON, amelynek kulcsai a nyílt forráskódú adattárban lévő célmodulok, az értékek pedig a LinkedIn-tárolókban lévő forrásmodulok listája. A nyílt forráskódú lerakat bármely célmodulját tetszőleges számú forrásmodul táplálhatja. A forrásmodulok lerakatainak belső nevének jelzéséhez használja a Bash stílusban. A modulszintű leképezési fájl használatával az eszközök fájlszintű leképezési fájlt hoznak létre a kapcsolódó könyvtárak összes fájljának vizsgálatával.
{
"${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,
}A fájlszintű leképezést az eszközök automatikusan létrehozzák; azonban a felhasználó manuálisan is frissítheti. Ez egy LinkedIn-forrásfájl 1:1-es leképezése a nyílt forráskódú tárolóban lévő fájlhoz. Számos szabály kapcsolódik a fájltársítások automatikus létrehozásához:
- Ha egy nyílt forráskódú célmodulhoz több forrásmodul is tartozik, konfliktusok léphetnek fel, pl. , amely egynél több forrásmodulban létezik. Konfliktusmegoldási stratégiaként eszközeink alapértelmezés szerint az „utolsó nyer” opciót választják.
- A "null" azt jelenti, hogy a forrásfájl nem része a nyílt forráskódú tárolónak.
- Minden nyílt forráskódú beküldés vagy kibontás után ez a leképezés automatikusan frissül, és létrejön egy pillanatkép. Ez a forráskódból az utolsó művelet óta történt kiegészítések és törlések azonosításához szükséges.
Végrehajtási naplók létrehozása
A nyílt forráskódú véglegesítések véglegesítési naplói szintén automatikusan jönnek létre a belső lerakatok végrehajtási naplóinak egyesítésével. Az alábbiakban egy végrehajtási napló minta látható, amely bemutatja az eszközünk által generált véglegesítési napló szerkezetét. A véglegesítés egyértelműen jelzi, hogy a forráslerakatok mely verziói vannak az adott véglegesítésben csomagolva, és összefoglalja a véglegesítési naplót. Ezt nézd meg az eszközkészletünk által generált véglegesítési napló valódi példáját használva.
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.0Függőségteszt
A LinkedInnek van , amely segít abban, hogy a belső többtermékek módosításai ne törjék meg a függő többtermékek összeállítását. A nyílt forráskódú DataHub repository nem többtermékes, és nem lehet közvetlen függősége egyetlen többterméknek sem, de a nyílt forráskódú DataHub forráskódot lekérő többtermékes burkoló segítségével továbbra is használhatjuk ezt a függőségi tesztelést. Így a nyílt forráskódú DataHub lerakatot tápláló többtermékek bármelyikének módosítása (amely később nyilvánosságra kerülhet), összeállítási eseményt indít el a shell többtermékben. Ezért minden olyan módosítás, amely nem képes létrehozni egy csomagolóterméket, nem felel meg az eredeti termék véglegesítése előtti teszteknek, és visszaáll.
Ez egy hasznos mechanizmus, amely segít megelőzni minden olyan belső véglegesítést, amely megszakítja a nyílt forráskódú buildet, és a véglegesítés időpontjában észleli azt. Enélkül meglehetősen nehéz lenne meghatározni, hogy melyik belső véglegesítés okozta a nyílt forráskódú lerakat felépítésének meghiúsítását, mivel a DataHub nyílt forráskódú tárház belső módosításait köteggel hajtjuk végre.
A nyílt forráskódú DataHub és a mi éles verziónk közötti különbségek
Eddig a pontig tárgyaltuk a DataHub adattárak két verziójának szinkronizálására vonatkozó megoldásunkat, de még mindig nem vázoltuk fel, hogy miért van szükségünk két különböző fejlesztési adatfolyamra. Ebben a részben felsoroljuk a DataHub nyilvános verziója és a LinkedIn szervereken lévő éles verzió közötti különbségeket, és elmagyarázzuk ezeknek a különbségeknek az okait.
Az eltérések egyik forrása abból a tényből fakad, hogy éles verziónk olyan kódoktól függ, amelyek még nem nyílt forráskódúak, mint például a LinkedIn Offspring (a LinkedIn belső függőségi befecskendezési keretrendszere). Az utódokat széles körben használják a belső kódbázisokban, mivel ez a dinamikus konfiguráció kezelésének előnyben részesített módszere. De ez nem nyílt forráskódú; ezért nyílt forráskódú alternatívákat kellett találnunk a nyílt forráskódú DataHub helyett.
Vannak más okok is. Mivel a LinkedIn igényeinek megfelelően bővítményeket hozunk létre a metaadat-modellhez, ezek a bővítmények jellemzően nagyon specifikusak a LinkedInre, és nem feltétlenül vonatkoznak közvetlenül más környezetekre. Például nagyon specifikus címkéink vannak a résztvevőazonosítókhoz és más típusú egyező metaadatokhoz. Tehát most kizártuk ezeket a bővítményeket a DataHub nyílt forráskódú metaadatmodelljéből. Miközben kapcsolatba lépünk a közösséggel, és megértjük igényeiket, szükség esetén a bővítmények közös nyílt forráskódú verzióin dolgozunk.
A könnyű használhatóság és a nyílt forráskódú közösséghez való könnyebb adaptáció inspirálta a DataHub két verziója közötti különbségek egy részét is. Jó példa erre az adatfolyam-feldolgozási infrastruktúra különbségei. Bár belső verziónk felügyelt adatfolyam-feldolgozási keretrendszert használ, a nyílt forráskódú verzióhoz a beépített (önálló) adatfolyam-feldolgozást választottuk, mert így elkerülhető az újabb infrastruktúra-függőség létrehozása.
Egy másik példa a különbségre, ha több GMS helyett egyetlen GMS (Generalized Metadata Store) van nyílt forráskódú megvalósításban. A GMA (Generalized Metadata Architecture) a DataHub háttérarchitektúrájának neve, a GMS pedig a metaadattároló a GMA kontextusában. A GMA egy nagyon rugalmas architektúra, amely lehetővé teszi az egyes adatkonstrukciók (pl. adatkészletek, felhasználók stb.) saját metaadattárába való szétosztását, vagy több adatkonstrukció egyetlen metaadattárban való tárolását mindaddig, amíg a rendszerleíró adatbázis tartalmazza az adatstruktúra-leképezést. A GMS frissült. A könnyebb használat érdekében egyetlen GMS-példányt választottunk, amely az összes különböző adatkonstrukciót a nyílt forráskódú DataHubban tárolja.
A két megvalósítás közötti különbségek teljes listája az alábbi táblázatban található.
Termék jellemzők
LinkedIn DataHub
Nyílt forráskódú DataHub
Támogatott adatkonstrukciók
1) Adatkészletek 2) Felhasználók 3) Mutatók 4) ML szolgáltatások 5) Diagramok 6) Irányítópultok
1) Adatkészletek 2) Felhasználók
Támogatott metaadatforrások az adatkészletekhez
1) 2) Kanapé 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vektor 14)
Hive Kafka RDBMS
Pub-sub
Összefolyó Kafka
Stream feldolgozás
irányított
Beágyazott (önálló)
Dependency Injection & Dynamic Configuration
LinkedIn utód
Szerszámozás
Ligradle (a LinkedIn belső Gradle-csomagolója)
CI / CD
CRT (a LinkedIn belső CI/CD-je)
és a
Metaadatboltok
Elosztott több GMS: 1) Adatkészlet GMS 2) Felhasználói GMS 3) Metrikus GMS 4) Szolgáltatás GMS 5) Grafikon/műszerfal GMS
Egyetlen GMS: 1) Adatkészletek 2) Felhasználók
Mikroszolgáltatások Docker konténerekben
leegyszerűsíti az alkalmazások telepítését és terjesztését . A DataHub szolgáltatásának minden része nyílt forráskódú, beleértve az olyan infrastrukturális összetevőket, mint a Kafka, , и , saját Docker-képe van. Az általunk használt Docker konténerek hangszereléséhez .
2. ábra: Építészet DataHub *nyílt forráskód**
A DataHub magas szintű architektúráját a fenti képen láthatja. Az infrastruktúra-összetevők mellett négy különböző Docker konténerrel rendelkezik:
datahub-gms: metaadattárolási szolgáltatás
datahub-frontend: alkalmazás , amely a DataHub felületet szolgálja ki.
datahub-mce-consumer: alkalmazás , amely a metaadat-módosítási esemény (MCE) adatfolyamot használja, és frissíti a metaadattárolót.
datahub-mae-consumer: alkalmazás , amely metaadat-ellenőrzési eseményfolyamot (MAE) használ, és keresési indexet és grafikon adatbázist hoz létre.
Nyílt forráskódú adattár dokumentációja és részletesebb információkat tartalmaznak a különböző szolgáltatások funkcióiról.
A DataHubon található CI/CD nyílt forráskódú
A nyílt forráskódú DataHub lerakat használja a folyamatos integrációért és folyamatos telepítéshez. Mindkettő jó GitHub-integrációval rendelkezik, és könnyen beállítható. A legtöbb nyílt forráskódú infrastruktúrához, amelyet a közösség vagy magáncégek fejlesztettek ki (pl. ), a Docker képek létrehozása és üzembe helyezése a Docker Hub-on történik a közösség általi egyszerű használat érdekében. A Docker Hubban található bármely Docker-kép könnyen használható egy egyszerű paranccsal .
A DataHub nyílt forráskódú tárhelyére tett minden véglegesítéskor az összes Docker-kép automatikusan létrejön, és a „legújabb” címkével kerül üzembe a Docker Hubon. Ha a Docker Hub konfigurálva van néhány , a nyílt forráskódú lerakatban lévő összes címke a megfelelő címkenevekkel is megjelent a Docker Hubban.
A DataHub használata
nagyon egyszerű, és három egyszerű lépésből áll:
- Klónozza a nyílt forráskódú tárat, és futtassa az összes Docker-tárolót a docker-compose szolgáltatással a mellékelt docker-compose szkript segítségével a gyors kezdéshez.
- Töltse le a tárolóban található mintaadatokat a szintén mellékelt parancssori eszköz segítségével.
- Böngésszen a DataHub között a böngészőjében.
Aktívan nyomon követve gyors kérdésekhez is konfigurálva. A felhasználók közvetlenül a GitHub-tárolóban is létrehozhatnak problémákat. A legfontosabb, hogy minden visszajelzést és javaslatot szívesen fogadunk és nagyra értékelünk!
Tervek a jövőre
Jelenleg a nyílt forráskódú DataHub minden infrastruktúrája vagy mikroszolgáltatása Docker konténerként épül fel, és a teljes rendszert a . Tekintettel a népszerűségre és elterjedtségére , szeretnénk a közeljövőben egy Kubernetes alapú megoldást is nyújtani.
Azt is tervezzük, hogy kulcsrakész megoldást biztosítunk a DataHub nyilvános felhőszolgáltatásokon való üzembe helyezéséhez, mint pl , vagy . Tekintettel a LinkedIn Azure-ba való migrációjáról szóló legutóbbi bejelentésre, ez összhangban lesz a metaadat-csapat belső prioritásaival.
Végül, de nem utolsósorban köszönet a nyílt forráskódú közösségben a DataHub minden korai alkalmazójának, akik értékelték a DataHub alfáit, és segítettek a problémák azonosításában és a dokumentáció javításában.
Forrás: will.com