🥇DataHub з адкрытым зыходным кодам: платформа пошуку і выяўлення метададзеных ад LinkedIn

DataHub з адчыненым зыходным кодам: платформа пошуку і выяўленні метададзеных ад LinkedIn

Хуткі пошук патрэбных дадзеных неабходны для любой кампаніі, якая належыць на вялікую колькасць дадзеных для прыняцця рашэнняў на аснове гэтых дадзеных. Гэта не толькі ўплывае на прадуктыўнасць карыстальнікаў дадзеных (уключаючы аналітыкаў, распрацоўшчыкаў машыннага навучання, спецыялістаў па апрацоўцы дадзеных і інжынераў дадзеных), але таксама аказвае прамы ўплыў на канчатковыя прадукты, якія залежаць ад якаснага канвеера машыннага навучання (ML). Акрамя таго, тэндэнцыя да ўкаранення або стварэнню платформаў машыннага навучання натуральным чынам выклікае пытанне: які ваш метад унутранага выяўлення функцый, мадэляў, паказчыкаў, набораў дадзеных і т. Д.

У гэтым артыкуле мы раскажам пра тое, як апублікавалі пад адкрытай ліцэнзіяй крыніцу дадзеных DataHub у нашай платформе пошуку і выяўлення метададзеных, пачынаючы з першых дзён праекта WhereHows. 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). Прытрымліванне гэтай мадэлі распрацоўкі не толькі добра для тых, хто выкарыстоўвае адкрыты зыходны код, але таксама прыводзіць да стварэння больш модульнай, якая пашыраецца і якая падключаецца архітэктуры.

Аднак для дасягнення гэтага стану для спелага ўнутранага прыкладання, такога як DataHub, запатрабуецца значная колькасць часу. Гэта таксама выключае магчымасць адкрытага зыходнага кода поўнасцю працуючай рэалізацыі да таго, як усе ўнутраныя залежнасці будуць поўнасцю абстрагаваны. Таму мы распрацавалі інструменты, якія дапамагаюць нам уносіць ўклады з адкрытым зыходным кодам хутчэй і значна менш балюча. Гэтае рашэнне выгадна як камандзе метададзеных (распрацоўнік DataHub), так і супольнасці адкрытага зыходнага кода. У наступных раздзелах будзе абмяркоўвацца гэты новы падыход.

Аўтаматызацыя публікацыі з адкрытым зыходным кодам

Апошні падыход групы метададзеных да DataHub з адчыненым зыходным кодам складаецца ў распрацоўцы прылады, які аўтаматычна сінхранізуе ўнутраную кодавую базу і рэпазітар з адчыненым зыходным кодам. Функцыі высокага ўзроўню гэтага інструментара ўключаюць:

Сінхранізацыя кода LinkedIn з / з адкрытага зыходнага кода, аналагічна Rsync.
Генерацыя загалоўка ліцэнзіі, аналагічная Apache Rat.
Аўтаматычнае стварэнне логаў комітаў з адкрытым зыходным кодам з унутраных логаў комітаў.
Прадухіленне ўнутраных змен, якія парушаюць зборку з адкрытым зыходным кодам, шляхам тэсціравання залежнасцяў.

У наступных падраздзелах будуць падрабязна разгледжаны вышэйзгаданыя функцыі, якія маюць цікавыя праблемы.

Сінхранізацыя зыходнага кода

У адрозненне ад версіі DataHub з адкрытым зыходным кодам, якая ўяўляе сабой адзіны рэпазітар GitHub, версія DataHub для LinkedIn уяўляе сабой камбінацыю некалькіх рэпазітараў (унутры кампаніі званых multiproducts). Інтэрфейс 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. Любы мэтавы модуль у рэпазітары з адкрытым зыходным кодам можа сілкавацца любой колькасцю зыходных модуляў. Для абазначэння ўнутраных імёнаў рэпазітараў у зыходных модулях выкарыстоўваецца радковая інтэрпаляцыя у стылі Bash. Выкарыстоўваючы файл супастаўлення на ўзроўні модуля, інструментальныя сродкі ствараюць файл супастаўлення на ўзроўні файлаў, скануючы ўсе файлы ў злучаных каталогах.

{
  "${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,
}

Супастаўленне файлавага ўзроўня аўтаматычна ствараецца прыладамі; аднак ён таксама можа быць абноўлены карыстальнікам уручную. Гэта супастаўленне 1: 1 зыходнага файла LinkedIn з файлам у рэпазітары з адкрытым зыходным кодам. Ёсць некалькі правіл, злучаных з гэтым аўтаматычным стварэннем супастаўлення файлаў:

У выпадку некалькіх зыходных модуляў для мэтавага модуля ў адкрытым зыходным кодзе могуць узнікнуць канфлікты, напрыклад, адзін і той жа FQCN, які існуе больш чым у адным зыходным модулі. У якасці стратэгіі вырашэння канфліктаў нашы інструменты па змаўчанні выкарыстоўваюць опцыю "апошні выйграе".
"null" азначае, што зыходны файл не з'яўляецца часткай рэпазітара з адкрытым зыходным кодам.
Пасля кожнай адпраўкі ў адкрыты зыходны код або вымання з яго гэта супастаўленне аўтаматычна абнаўляецца і ствараецца маментальны здымак. Гэта неабходна для вызначэння дадання і выдалення зыходнага кода пасля апошняга дзеяння.

Стварэнне логаў комітаў

Логі комітаў для комітаў з адкрытым зыходным кодам таксама аўтаматычна ствараюцца шляхам аб'яднання логаў комітаў унутраных рэпазітароў. Ніжэй прыведзены ўзор лога коміта, каб паказаць структуру лога коміта, створанага нашым інструментам. Коміт выразна паказвае, якія версіі зыходных рэпазітараў спакаваныя ў гэты коміт, і падае зводную інфармацыю лога комміта. Праверце гэты коміт на рэальным прыкладзе лога коміта, створанага нашым інструментарыем.

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 з адчыненым зыходным кодам, запускае падзею зборкі ў мультыпрадукты абалонкі. Такім чынам, любая змена, якая не дазваляе пабудаваць шматпрадукт-абалонку, не праходзіць тэсты перад комітам зыходнага шматпрадукта і вяртаецца.

Гэта карысны механізм, які дапамагае прадухіліць любы ўнутраны коміт, якая парушае зборку з адчыненым зыходным кодам, і выяўляе яе падчас стварэння комміта. Без гэтага было б даволі складана вызначыць, які ўнутраны коміт прывёў да збою зборкі рэпазітара з адчыненым зыходным кодам, таму што мы змяшчаем пакетныя ўнутраныя змены ў рэпазітар DataHub з адчыненым зыходным кодам.

Адрозненні паміж DataHub з адчыненым зыходным кодам і нашай вытворчай версіяй

Да гэтага моманту мы абмяркоўвалі наша рашэнне для сінхранізацыі двух версій рэпазітароў DataHub, але да гэтага часу не пазначылі прычыны, па якіх нам наогул патрэбныя два розных патоку распрацоўкі. У гэтай частцы мы пералічым адрозненні паміж агульнадаступнай версіяй DataHub і вытворчай версіяй на серверах LinkedIn, а таксама растлумачым чыннікі гэтых адрозненняў.

Адна з крыніц разыходжанняў вынікае з таго факту, што наша вытворчая версія мае залежнасці ад кода з яшчэ не адкрытым зыходным кодам, такога як LinkedIn's Offspring (унутраная структура ўкаранення залежнасцяў LinkedIn). Offspring шырока выкарыстоўваецца ва ўнутранай кодавай базе, таму што гэта пераважны метад кіравання дынамічнай канфігурацыяй. Але гэта не з адчыненым зыходным кодам; таму нам трэба было знайсці альтэрнатывы з адчыненым зыходным кодам для DataHub з адчыненым зыходным кодам.

Ёсць і іншыя прычыны. Па меры таго як мы ствараем пашырэнні мадэлі метададзеных для патрэб LinkedIn, гэтыя пашырэнні звычайна вельмі спецыфічныя для LinkedIn і могуць не ўжывацца наўпрост да іншых асяроддзяў. Напрыклад, у нас ёсць вельмі спецыфічныя пазнакі для ідэнтыфікатараў удзельнікаў і іншых тыпаў метададзеных адпаведнасці. Такім чынам, у наш час мы выключылі гэтыя пашырэнні з мадэлі метададзеных DataHub з адчыненым зыходным кодам. Па меры таго, як мы ўзаемадзейнічаем з супольнасцю і разумеем іх патрэбнасці, мы будзем працаваць над агульнымі версіямі гэтых пашырэнняў з адкрытым зыходным кодам, дзе гэта неабходна.

Прастата выкарыстання і лягчэйшая адаптацыя для супольнасці адчыненага зыходнага кода таксама натхнілі некаторыя адрозненні паміж двума версіямі DataHub. Адрозненні ў інфраструктуры струменевай апрацоўкі - добры таму прыклад. Хоць наша ўнутраная версія выкарыстоўвае інфраструктуру кіраванай струменевай апрацоўкі, мы вырашылі выкарыстаць убудаваную (аўтаномную) струменевую апрацоўку для версіі з адчыненым зыходным кодам, паколькі яна дазваляе пазбегнуць стварэнні яшчэ адной залежнасці інфраструктуры.

Іншы прыклад адрознення - наяўнасць аднаго GMS (Абагульненае сховішча метададзеных) у рэалізацыі з адчыненым зыходным кодам, а не некалькіх GMS. GMA (Абагульненая архітэктура метададзеных) - гэта назва ўнутранай архітэктуры для DataHub, а GMS - гэта сховішча метададзеных у кантэксце GMA. GMA - вельмі гнуткая архітэктура, якая дазваляе вам размяркоўваць кожную канструкцыю дадзеных (напрыклад, наборы дадзеных, карыстальнікаў і г. д.) Ва ўласнае сховішча метададзеных або захоўваць некалькі канструкцый дадзеных у адным сховішчы метададзеных да таго часу, пакуль рэестр, які змяшчае адлюстраванне структуры дадзеных у GMS абнаўляецца. Для прастаты выкарыстання мы абралі адзін асобнік GMS, які захоўвае ўсе розныя канструкцыі дадзеных у DataHub з адчыненым зыходным кодам.

Поўны спіс адрозненняў паміж дзвюма рэалізацыямі прыведзены ў табліцы ніжэй.

Асаблівасці прадукту
LinkedIn DataHub
Open Source DataHub

Supported Data Constructs
1) Datasets 2) Users 3) Metrics 4) ML Features 5) Charts 6) Dashboards
1) Datasets 2) Users

Supported Metadata Sources for Datasets
1) Ambry 2) Couchbase 3) Dalids 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
LinkedIn Kafka
Confluent Kafka

Stream Processing
кіраваны
Embedded (standalone)

Dependency Injection & Dynamic Configuration
LinkedIn Offspring
вясна

Build Tooling
Ligradle (LinkedIn's internal Gradle wrapper)
Gradlew

CI / CD
CRT (LinkedIn's internal CI/CD)
TravisCI і Дак-канцэнтратар

Metadata Stores
Distributed multiple GMS: 1) Dataset GMS 2) User GMS 3) Metric GMS 4) Feature GMS 5) Chart/Dashboard GMS
Single GMS for: 1) Datasets 2) Users

Мікрасэрвісы ў кантэйнерах Docker

Докер спрашчае разгортванне і распаўсюджванне прыкладанняў з дапамогай кантэйнерызацыі. Кожная частка сэрвісу ў DataHub з адчыненым зыходным кодам, уключаючы кампаненты інфраструктуры, такія як Kafka, Elasticsearch, neo4j и MySQL, мае свой уласны лад Docker. Для аркестрацыі кантэйнераў Docker мы выкарыстоўвалі Docker Compose.

Малюнак 2: Архітэктура DataHub *з адкрытым зыходным кодам**

Вы можаце ўбачыць высокаўзроўневую архітэктуру DataHub на малюнку вышэй. Апроч кампанентаў інфраструктуры, у яго ёсць чатыры розных кантэйнера Docker:

datahub-gms: служба сховішча метададзеных

datahub-frontend: дадатак гуляць, Абслуговаючае інтэрфейс DataHub.

datahub-mce-consumer: дадатак Kafka Streams, Якое выкарыстоўвае паток падзей змены метададзеных (MCE) і абнаўляе сховішча метададзеных.

datahub-mae-consumer: дадатак Kafka Streams, Якое выкарыстоўвае паток падзей аўдыту метададзеных (MAE) і стварае базу дадзеных пошукавага індэкса і графа.

Дакументацыя па рэпазітары з адкрытым зыходным кодам і зыходны запіс у блогу DataHub змяшчаюць больш падрабязную інфармацыю аб функцыях розных службаў.

CI / CD у DataHub з адкрытым зыходным кодам

Рэпазітар DataHub з адкрытым зыходным кодам выкарыстоўвае TravisCI для бесперапыннай інтэграцыі і Дак-канцэнтратар для бесперапыннага разгортвання. Абодва маюць добрую інтэграцыю з GitHub і простыя ў наладзе. Для большай часткі інфраструктуры з адкрытым зыходным кодам, распрацаванай супольнасцю ці прыватнымі кампаніямі (напрыклад, Пераход), створаны вобразы Docker, і яны разгортваюцца ў Docker Hub для спрашчэння выкарыстання супольнасцю. Любая выява Docker, знойдзены ў Docker Hub, можна лёгка выкарыстоўваць з дапамогай простай каманды докер цягнуць.

Пры кожным каментары ў рэпазітары з адчыненым зыходным кодам DataHub усе выявы Docker аўтаматычна ствараюцца і разгортваюцца ў Docker Hub з тэгам «latest». Калі ў Docker Hub наладжана некаторае найменне галінак рэгулярных выразаў, усе тэгі ў рэпазітары з адкрытым зыходным кодам таксама выпускаюцца з адпаведнымі імёнамі тэгаў у Docker Hub.

Выкарыстанне DataHub

Настройка DataHub вельмі простая і складаецца з трох простых крокаў:

Клануйце рэпазітар з адкрытым зыходным кодам і запусціце ўсе кантэйнеры Docker з дапамогай docker-compose з дапамогай прадстаўленага сцэнара docker-compose для хуткага запуску.
Загрузіце ўзоры дадзеных, прадстаўленыя ў рэпазітары, з дапамогай інструмента каманднага радка, які таксама прадастаўляецца.
Праглядзіце DataHub у сваім браўзэры.

Актыўна адсочваны -чат Gitter таксама настроены для хуткіх пытанняў. Карыстальнікі таксама могуць ствараць праблемы прама ў рэпазітары GitHub. Самае галоўнае, мы вітаем і цэнім усе водгукі і прапановы!

Планы на будучыню

У наш час кожная інфраструктура ці мікрасэрвіс для DataHub з адчыненым зыходным кодам пабудавана як кантэйнер Docker, а ўся сістэма аркеструецца з дапамогай докер-Compose. Улічваючы папулярнасць і шырокае распаўсюджванне Kubernetes, мы таксама хацелі б даць рашэнне на аснове Kubernetes у найбліжэйшай будучыні.

Мы таксама плануем даць гатовае рашэнне для разгортвання DataHub у агульнадаступнай хмарнай службе, такі як Блакітны, AWS або Google Cloud. Улічваючы нядаўнюю аб'яву аб міграцыі LinkedIn на Azure, гэта будзе адпавядаць унутраным прыярытэтам групы метададзеных.

І апошняе, але не меней важнае: дзякуй усім першым карыстачам DataHub у супольнасці з адчыненым зыходным кодам, якія ацанілі альфа-версіі DataHub і дапамаглі нам выявіць праблемы і палепшыць дакументацыю.

Крыніца: habr.com