Опен Соурце ДатаХуб: ЛинкедИн-ова платформа за претрагу и откривање метаподатака

Опен Соурце ДатаХуб: ЛинкедИн-ова платформа за претрагу и откривање метаподатака

Брзо проналажење података који су вам потребни је од суштинског значаја за сваку компанију која се ослања на велике количине података да би доносила одлуке засноване на подацима. Не само да ово утиче на продуктивност корисника података (укључујући аналитичаре, програмере машинског учења, научнике и инжењере података), већ такође има директан утицај на крајње производе који зависе од квалитетног процеса машинског учења (МЛ). Поред тога, тренд ка имплементацији или изградњи платформи за машинско учење природно поставља питање: који је ваш метод за интерно откривање функција, модела, метрика, скупова података итд.

У овом чланку ћемо говорити о томе како смо објавили извор података под отвореном лиценцом ДатаХуб у нашој платформи за претрагу и откривање метаподатака, почевши од првих дана пројекта ВхереХовс. ЛинкедИн одржава сопствену верзију ДатаХуб-а одвојено од верзије отвореног кода. Почећемо тако што ћемо објаснити зашто су нам потребна два одвојена развојна окружења, а затим разговарамо о раним приступима коришћењу ВхереХовс отвореног кода и упоредимо нашу интерну (производну) верзију ДатаХуб-а са верзијом на ГитХуб. Такође ћемо поделити детаље о нашем новом аутоматизованом решењу за слање и примање ажурирања отвореног кода како би оба спремишта била синхронизована. На крају, даћемо упутства о томе како да почнете да користите ДатаХуб отвореног кода и укратко разговарамо о његовој архитектури.

ВхереХовс је сада ДатаХуб!

ЛинкедИн-ов тим за метаподатке је претходно представљен ДатаХуб (наследник ВхереХовс), ЛинкедИн-ова платформа за претрагу и откривање метаподатака, и заједнички планови за њено отварање. Убрзо након ове објаве, објавили смо алфа верзију ДатаХуб-а и поделили је са заједницом. Од тада смо континуирано давали допринос спремишту и радили са заинтересованим корисницима на додавању најтраженијих функција и решавању проблема. Сада са задовољством најављујемо званично издање ДатаХуб на ГитХуб-у.

Приступи отвореног кода

ВхереХовс, ЛинкедИн-ов оригинални портал за проналажење података и одакле потичу, започео је као интерни пројекат; тим за метаподатке га је отворио изворни код у 2016. Од тада, тим је увек одржавао две различите базе кода — једну за отворени код и једну за интерну употребу ЛинкедИн-а — пошто нису све функције производа развијене за случајеве коришћења ЛинкедИн-а генерално применљиве на ширу публику. Поред тога, ВхереХовс има неке интерне зависности (инфраструктура, библиотеке, итд.) које нису отвореног кода. У годинама које су уследиле, ВхереХовс је прошао кроз многе итерације и развојне циклусе, чинећи синхронизацију две базе кода великим изазовом. Тим за метаподатке је током година покушао са различитим приступима како би покушао да синхронизује интерни развој и развој отвореног кода.

Први покушај: „Прво отворени извор“

Првобитно смо следили развојни модел „прво отвореног кода“, где се већина развоја одвија у спремишту отвореног кода и промене се праве за интерну примену. Проблем са овим приступом је у томе што се код увек прво гура на ГитХуб пре него што се у потпуности интерно прегледа. Све док се не изврше измене из складишта отвореног кода и не изврши нова интерна примена, нећемо наћи никакве проблеме у производњи. У случају лошег распореда, такође је било веома тешко утврдити кривца јер су измене вршене у серијама.

Поред тога, овај модел је смањио продуктивност тима при развоју нових функција које су захтевале брзе итерације, пошто је приморао да се све промене прво гурну у складиште отвореног кода, а затим пребаце у интерно спремиште. Да би се смањило време обраде, потребна поправка или промена би се прво могла извршити у интерном спремишту, али је ово постао велики проблем када је дошло до спајања тих промена назад у спремиште отвореног кода јер два спремишта нису била синхронизована.

Овај модел је много лакши за имплементацију за дељене платформе, библиотеке или инфраструктурне пројекте него за потпуно функционалне прилагођене веб апликације. Поред тога, овај модел је идеалан за пројекте који почињу са отвореним кодом од првог дана, али ВхереХовс је направљен као потпуно интерна веб апликација. Било је заиста тешко потпуно апстраховати све унутрашње зависности, тако да смо морали да задржимо интерну виљушку, али задржавање унутрашње виљушке и развој углавном отвореног кода није баш успело.

Други покушај: "Прво унутра"

**Као други покушај, прешли смо на развојни модел „прво интерно“, где се већина развоја одвија у компанији, а промене се редовно врше у отвореном изворном коду. Иако је овај модел најпогоднији за наш случај употребе, он има инхерентне проблеме. Директно пребацивање свих разлика у складиште отвореног кода, а затим покушај каснијег решавања сукоба спајања је опција, али то одузима много времена. Програмери у већини случајева покушавају да то не раде сваки пут када прегледају свој код. Као резултат тога, ово ће се радити много ређе, у групама, и самим тим отежава касније решавање конфликата спајања.

Трећи пут је успело!

Два горе поменута неуспела покушаја довела су до тога да је ВхереХовс ГитХуб спремиште дуго застарело. Тим је наставио да побољшава карактеристике и архитектуру производа, тако да је интерна верзија ВхереХовс за ЛинкедИн постала напреднија од верзије отвореног кода. Чак је имао и ново име - ДатаХуб. На основу претходних неуспешних покушаја, тим је одлучио да развије скалабилно, дугорочно решење.

За сваки нови пројекат отвореног кода, ЛинкедИн-ов тим отвореног кода саветује и подржава развојни модел у којем су модули пројекта у потпуности развијени у отвореном коду. Верзиони артефакти се постављају у јавно складиште, а затим се поново проверавају у интерни ЛинкедИн артефакт користећи захтев за екстерну библиотеку (ЕЛР). Праћење овог модела развоја није добро само за оне који користе отворени код, већ такође резултира модуларнијом, проширивом архитектуром која се може прикључити.

Међутим, зрелој позадинској апликацији као што је ДатаХуб биће потребно доста времена да достигне ово стање. Ово такође искључује могућност отвореног извора за потпуно функционалну имплементацију пре него што се у потпуности апстрахују све унутрашње зависности. Зато смо развили алате који нам помажу да дајемо доприносе отвореног кода брже и са много мање муке. Ово решење користи и тиму за метаподатке (програмер ДатаХуб-а) и заједници отвореног кода. У наредним одељцима ће се расправљати о овом новом приступу.

Аутоматизација објављивања отвореног кода

Најновији приступ Метадата тима ДатаХуб-у са отвореним кодом је развој алата који аутоматски синхронизује интерну кодну базу и складиште отвореног кода. Карактеристике високог нивоа овог комплета алата укључују:

1. Синхронизујте ЛинкедИн код са/са отвореног кода, слично рсинц.
2. Генерисање заглавља лиценце, слично Апацхе Рат.
3. Аутоматски генеришите дневнике урезивања отвореног кода из интерних дневника урезивања.
4. Спречите унутрашње промене које прекидају градње отвореног кода тестирање зависности.

Следећи пододељци ће се бавити горе поменутим функцијама које имају интересантне проблеме.

Синхронизација изворног кода

За разлику од верзије ДатаХуб-а отвореног кода, која је једно ГитХуб спремиште, ЛинкедИн верзија ДатаХуб-а је комбинација више складишта (названих интерно више производа). ДатаХуб интерфејс, библиотека модела метаподатака, позадинска услуга складишта метаподатака и послови стримовања налазе се у засебним репозиторијумима на ЛинкедИн-у. Међутим, да бисмо олакшали корисницима отвореног кода, имамо једно спремиште за верзију ДатаХуб-а отвореног кода.

Слика 1: Синхронизација између спремишта ЛинкедИн ДатаХуб и једно спремиште ДатаХуб отвореног кода

Да би подржао аутоматизоване токове израде, гурања и повлачења, наш нови алат аутоматски креира мапирање на нивоу датотеке које одговара свакој изворној датотеци. Међутим, комплет алата захтева почетну конфигурацију и корисници морају да обезбеде мапирање модула високог нивоа као што је приказано у наставку.

{
  "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"
  ]
}

Мапирање на нивоу модула је једноставан ЈСОН чији су кључеви циљни модули у спремишту отвореног кода, а вредности су листа изворних модула у ЛинкедИн репозиторијумима. Било који циљни модул у спремишту отвореног кода може се хранити било којим бројем изворних модула. Да бисте назначили интерна имена спремишта у изворним модулима, користите стринг интерполација у Басх стилу. Користећи датотеку за мапирање на нивоу модула, алати креирају датотеку за мапирање на нивоу датотеке скенирањем свих датотека у повезаним директоријумима.

{
  "${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 мапирање ЛинкедИн изворне датотеке у датотеку у спремишту отвореног кода. Постоји неколико правила повезаних са овим аутоматским креирањем асоцијација датотека:

• У случају више изворних модула за циљни модул у отвореном коду, може доћи до сукоба, нпр. ФКЦН, који постоји у више од једног изворног модула. Као стратегија за решавање сукоба, наши алати подразумевано користе опцију „последњи побеђује“.
• „нулл“ значи да изворна датотека није део отвореног спремишта.
• Након сваког подношења или екстракције отвореног кода, ово мапирање се аутоматски ажурира и креира се снимак. Ово је неопходно да се идентификују додаци и брисања из изворног кода од последње акције.

Креирање дневника урезивања

Евиденције урезивања за урезивање отвореног кода се такође аутоматски генеришу спајањем дневника урезивања интерних спремишта. Испод је пример дневника урезивања који приказује структуру дневника урезивања који генерише наш алат. Урезивање јасно указује које су верзије изворних спремишта упаковане у то урезивање и пружа резиме дневника урезивања. Погледај ово урадити користећи прави пример дневника урезивања који генерише наш комплет алата.

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

Тестирање зависности

ЛинкедИн има инфраструктура за тестирање зависности, што помаже да се осигура да измене интерног вишепроизвода не разбију склоп зависних вишепроизвода. ДатаХуб складиште отвореног кода није вишепроизводно и не може бити директна зависност од било ког више производа, али уз помоћ омотача са више производа који преузима изворни код отвореног кода ДатаХуб, и даље можемо да користимо ово тестирање зависности Према томе, свака промена (која касније може бити изложена) било којег од више производа који храни складиште отвореног кода ДатаХуб покреће догађај изградње у вишепроизводу љуске. Према томе, свака промена која не успе да направи омотач не прође тестове пре него што унесе оригинални производ и поништи се.

Ово је користан механизам који помаже у спречавању било каквог унутрашњег урезивања које квари изградњу отвореног кода и открива га у време урезивања. Без овога, било би прилично тешко одредити које унутрашње урезивање је изазвало неуспех изградње спремишта отвореног кода, јер ми скупљамо интерне промене у спремиште отвореног кода ДатаХуб.

Разлике између отвореног кода ДатаХуб и наше продукцијске верзије

До ове тачке смо разговарали о нашем решењу за синхронизацију две верзије ДатаХуб спремишта, али још увек нисмо навели разлоге зашто су нам уопште потребна два различита развојна тока. У овом одељку ћемо навести разлике између јавне верзије ДатаХуб-а и производне верзије на ЛинкедИн серверима и објаснити разлоге за ове разлике.

Један извор неслагања произилази из чињенице да наша производна верзија има зависности од кода који још увек није отвореног кода, као што је ЛинкедИн-ов Оффспринг (ЛинкедИн-ов интерни оквир за убризгавање зависности). Оффспринг се широко користи у интерним кодним базама јер је то преферирани метод за управљање динамичком конфигурацијом. Али то није опен соурце; па смо морали да пронађемо алтернативе отвореног кода за ДатаХуб отвореног кода.

Постоје и други разлози. Како креирамо проширења за модел метаподатака за потребе ЛинкедИн-а, ова проширења су обично веома специфична за ЛинкедИн и можда се не примењују директно на друга окружења. На пример, имамо веома специфичне ознаке за ИД-ове учесника и друге типове одговарајућих метаподатака. Дакле, сада смо искључили ове екстензије из ДатаХуб-овог модела метаподатака отвореног кода. Док се сарађујемо са заједницом и разумемо њихове потребе, радићемо на заједничким верзијама ових екстензија отвореног кода тамо где је то потребно.

Лакоћа коришћења и лакше прилагођавање заједници отвореног кода такође су инспирисали неке од разлика између две верзије ДатаХуб-а. Разлике у инфраструктури за обраду тока су добар пример за то. Иако наша интерна верзија користи оквир за обраду управљаног тока, одлучили смо да користимо уграђену (самосталну) обраду тока за верзију отвореног кода јер избегава стварање друге зависности од инфраструктуре.

Још један пример разлике је постојање једног ГМС-а (генерализованог складишта метаподатака) у имплементацији отвореног кода, а не више ГМС-ова. ГМА (Генерализед Метадата Арцхитецтуре) је назив позадинске архитектуре за ДатаХуб, а ГМС је складиште метаподатака у контексту ГМА. ГМА је веома флексибилна архитектура која вам омогућава да дистрибуирате сваки конструкт података (нпр. скупове података, кориснике, итд.) у сопствено складиште метаподатака или складиштите више конструкција података у једном складишту метаподатака све док регистар садржи мапирање структуре података у ГМС је ажуриран. Ради лакшег коришћења, изабрали смо једну ГМС инстанцу која складишти све различите конструкције података у ДатаХуб отвореног кода.

Комплетна листа разлика између ове две имплементације дата је у табели испод.

Карактеристике производа
ЛинкедИн ДатаХуб
Опен Соурце ДатаХуб

Подржане конструкције података
1) Скупови података 2) Корисници 3) метрика 4) МЛ функције 5) графикони 6) контролне табле
1) Скупови података 2) Корисници

Подржани извори метаподатака за скупове података
1) Амбри 2) Подлога за кауч 3) Далидс 4) Еспрессо 5) ХДФС 6) Хиве 7) Кафка 8) МонгоДБ 9) МиСКЛ 10) Орацле 11) Пинот 12) Престо 12) Сеас 13) Терадата 13) Вектор 14) Венеција
Хиве Кафка РДБМС

Пуб-суб
ЛинкедИн Кафка
Конфлуентни Кафка

Стреам Процессинг
Манагед
Уграђено (самостално)

Ињекција зависности и динамичка конфигурација
ЛинкедИн Оффспринг
Пролеће

Буилд Тоолинг
Лиградле (ЛинкедИн-ов интерни Градле омот)
Градлев

ЦИ / ЦД
ЦРТ (Интерни ЦИ/ЦД ЛинкедИн-а)
ТрависЦИ Доцкер Хуб

Продавнице метаподатака
Дистрибуирани вишеструки ГМС: 1) Скуп података ГМС 2) Кориснички ГМС 3) Метрички ГМС 4) ГМС карактеристика 5) ГМС графикона/контролне табле
Јединствени ГМС за: 1) Скупове података 2) Корисници

Микросервис у Доцкер контејнерима

лучки радник поједностављује примену и дистрибуцију апликација са контејнеризација. Сваки део услуге у ДатаХуб-у је отвореног кода, укључујући компоненте инфраструктуре као што су Кафка, Еластицсеарцх, Нео4ј и МиСКЛ, има свој Доцкер имиџ. За оркестрирање Доцкер контејнера смо користили Доцкер Цомпосе.

Слика 2: Архитектура ДатаХуб *отвореног кода**

Можете видети архитектуру високог нивоа ДатаХуб-а на слици изнад. Поред инфраструктурних компоненти, има четири различита Доцкер контејнера:

датахуб-гмс: услуга складиштења метаподатака

датахуб-фронтенд: апликација игра, који служи интерфејсу ДатаХуб.

датахуб-мце-цонсумер: апликација Кафка Стреамс, који користи ток догађаја промене метаподатака (МЦЕ) и ажурира складиште метаподатака.

датахуб-мае-цонсумер: апликација Кафка Стреамс, који користи ток догађаја ревизије метаподатака (МАЕ) и креира базу података индекса претраге и графикона.

Документација репозиторијума отвореног кода и оригинални ДатаХуб блог пост садрже детаљније информације о функцијама различитих услуга.

ЦИ/ЦД на ДатаХуб-у је отвореног кода

ДатаХуб спремиште отвореног кода користи ТрависЦИ за континуирану интеграцију и Доцкер Хуб за континуирано распоређивање. Оба имају добру ГитХуб интеграцију и лако се постављају. За већину инфраструктуре отвореног кода коју је развила заједница или приватне компаније (нпр. Чвор), Доцкер слике се креирају и постављају на Доцкер Хуб ради лакшег коришћења од стране заједнице. Било која Доцкер слика пронађена у Доцкер Хуб-у може се лако користити једноставном командом доцкер пулл.

Са сваким урезивањем у складиште отвореног кода ДатаХуб, све Доцкер слике се аутоматски праве и постављају у Доцкер Хуб са ознаком „најновија“. Ако је Доцкер Хуб конфигурисан са неким именовање грана регуларног израза, све ознаке у спремишту отвореног кода се такође објављују са одговарајућим називима ознака у Доцкер Хуб-у.

Коришћење ДатаХуб-а

Подешавање ДатаХуб-а је веома једноставан и састоји се од три једноставна корака:

1. Клонирајте складиште отвореног кода и покрените све Доцкер контејнере са доцкер-цомпосе користећи приложену скрипту доцкер-цомпосе за брзи почетак.
2. Преузмите узорке података датих у спремишту користећи алатку командне линије која је такође обезбеђена.
3. Прегледајте ДатаХуб у свом претраживачу.

Активно праћено Гиттер цхат такође конфигурисан за брза питања. Корисници такође могу креирати проблеме директно у ГитХуб спремишту. Што је најважније, поздрављамо и ценимо све повратне информације и сугестије!

Планови за будућност

Тренутно је свака инфраструктура или микросервис за ДатаХуб отвореног кода изграђен као Доцкер контејнер, а цео систем је оркестриран коришћењем доцкер-цомпосе. С обзиром на популарност и распрострањеност Кубернетес, такође бисмо желели да обезбедимо решење засновано на Кубернетесу у блиској будућности.

Такође планирамо да обезбедимо решење по принципу „кључ у руке“ за примену ДатаХуб-а на јавном облаку као што је нпр Плаветнило, АВС или Гоогле Цлоуд. С обзиром на недавну најаву ЛинкедИн-ове миграције на Азуре, ово ће бити у складу са интерним приоритетима тима за метаподатке.

На крају, али не и најмање важно, хвала свим раним усвојиоцима ДатаХуб-а у заједници отвореног кода који су оценили ДатаХуб алфа и помогли нам да идентификујемо проблеме и побољшамо документацију.

Извор: ввв.хабр.цом