DataHub со отворен код: платформа за пребарување и откривање метаподатоци на LinkedIn

DataHub со отворен код: платформа за пребарување и откривање метаподатоци на LinkedIn

Брзото наоѓање на податоците што ви се потребни е од суштинско значење за секоја компанија која се потпира на големи количини на податоци за да донесува одлуки засновани на податоци. Не само што ова влијае на продуктивноста на корисниците на податоци (вклучувајќи аналитичари, развивачи на машинско учење, научници за податоци и инженери за податоци), туку исто така има директно влијание врз крајните производи кои зависат од квалитетно машинско учење (ML). Дополнително, трендот кон имплементирање или градење платформи за машинско учење природно го поставува прашањето: кој е вашиот метод за внатрешно откривање карактеристики, модели, метрика, збирки на податоци итн.

Во оваа статија ќе зборуваме за тоа како објавивме извор на податоци под отворена лиценца DataHub во нашата платформа за пребарување и откривање метаподатоци, почнувајќи од раните денови на проектот КадеКако. LinkedIn одржува сопствена верзија на DataHub одделно од верзијата со отворен код. Ќе започнеме со објаснување зошто ни се потребни две посебни развојни околини, потоа ќе разговараме за раните пристапи за користење на open source 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 со отворен код е да развие алатка која автоматски ги синхронизира внатрешната база на кодови и складиштето со отворен код. Карактеристиките на високо ниво на овој комплет алатки вклучуваат:

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

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

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

За разлика од верзијата со отворен код на DataHub, која е единствено складиште на GitHub, верзијата на LinkedIn на DataHub е комбинација од повеќе складишта (наречена внатрешно мултипроизводи). Интерфејсот DataHub, библиотеката со модели на метаподатоци, услугата за складирање на метаподатоци и задачите за стриминг се наоѓаат во посебни складишта на LinkedIn. Меѓутоа, за да им олесниме на корисниците со отворен код, имаме единствено складиште за верзијата со отворен код на DataHub.

Слика 1: Синхронизација помеѓу складиштата Скопје 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. Секој целен модул во складиштето со отворен код може да се храни со кој било број на изворни модули. За да ги наведете внатрешните имиња на складиштата во изворните модули, користете интерполација на низа во баш стил. Користејќи датотека за мапирање на ниво на модул, алатките создаваат датотека за мапирање на ниво на датотека со скенирање на сите датотеки во поврзаните директориуми.

{
  "${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). Подмладокот е широко користен во внатрешните бази на кодови бидејќи е префериран метод за управување со динамичка конфигурација. Но, тоа не е со отворен код; па ни требаше да најдеме алтернативи со отворен код за DataHub со отворен код.

Има и други причини. Како што создаваме екстензии на моделот на метаподатоци за потребите на LinkedIn, овие екстензии обично се многу специфични за LinkedIn и може да не се однесуваат директно на други средини. На пример, имаме многу специфични етикети за ID на учесници и други видови соодветни метаподатоци. Значи, сега ги исклучивме овие екстензии од моделот на метаподатоци со отворен код на DataHub. Додека се занимаваме со заедницата и ги разбираме нивните потреби, ќе работиме на заеднички верзии со отворен код на овие екстензии каде што е потребно.

Леснотијата на користење и полесното прилагодување за заедницата со отворен код, исто така, инспирираа некои од разликите помеѓу двете верзии на DataHub. Разликите во инфраструктурата за обработка на текови се добар пример за ова. Иако нашата внатрешна верзија користи рамка за обработка на управуван пренос, избравме да користиме вградена (самостојна) обработка на пренос за верзијата со отворен код бидејќи избегнува создавање друга зависност од инфраструктурата.

Друг пример за разликата е да се има единствена GMS (Генерализирана продавница за метаподатоци) во имплементација со отворен код, наместо повеќе GMS. GMA (Генерализирана архитектура на метаподатоци) е името на заднинската архитектура за DataHub, а GMS е продавница за метаподатоци во контекст на GMA. GMA е многу флексибилна архитектура која ви овозможува да ја дистрибуирате секоја конструкција на податоци (на пример, збирки на податоци, корисници итн.) во сопствена продавница за метаподатоци или да складирате повеќе конструкции на податоци во една продавница за метаподатоци се додека регистарот што содржи мапирање на структурата на податоци во GMS е ажуриран. За лесно користење, избравме единствен пример на GMS што ги складира сите различни конструкции на податоци во DataHub со отворен код.

Целосна листа на разлики помеѓу двете имплементации е дадена во табелата подолу.

Карактеристики на производот
LinkedIn DataHub
DataHub со отворен код

Поддржани конструкции на податоци
1) збирки на податоци 2) корисници 3) метрика 4) ML карактеристики 5) графикони 6) контролни табли
1) Збирки на податоци 2) Корисници

Поддржани извори на метаподатоци за збирки на податоци
1) Амбри 2) Couchbase 3) Далиди 4) Еспресо 5) HDFS 6) Hive 7) Кафка 8) MongoDB 9) MySQL 10) Oracle 11) Пино 12) Престо 12) Биди 13) Терадата 13) Вектор 14) Венеција
Кошница Кафка RDBMS

Паб-под
LinkedIn Кафка
Слеан Кафка

Обработка на тек
Успеа
Вградено (самостојно)

Вбризгување на зависност и динамичка конфигурација
LinkedIn потомство
пролет

Build Tooling
Ligradle (внатрешна обвивка Gradle на LinkedIn)
Градју

CI / CD
CRT (внатрешен CI/CD на LinkedIn)
TravisCI Докер центар

Продавници за метаподатоци
Дистрибуиран повеќекратен GMS: 1) Збирка на податоци GMS 2) кориснички GMS 3) метрички GMS 4) GMS карактеристики 5) Графикон/ГМС-табла
Единствен GMS за: 1) збирки на податоци 2) корисници

Микроуслуги во контејнери на Docker

пристанишен работник го поедноставува распоредувањето и дистрибуцијата на апликациите со контејнеризација. Секој дел од услугата во DataHub е со отворен код, вклучувајќи ги и инфраструктурните компоненти како што е Кафка, Еластична пребарување, Нео4ј и MySQL,, има своја Docker слика. За да ги оркестрираме контејнерите на Docker што ги користевме Докер Компонирај.

Слика 2: Архитектура DataHub *отворен извор**

Можете да ја видите архитектурата на високо ниво на DataHub на сликата погоре. Покрај инфраструктурните компоненти, има четири различни Docker контејнери:

datahub-gms: услуга за складирање на метаподатоци

datahub-frontend: апликација Игра, опслужувајќи го интерфејсот DataHub.

datahub-mce-consumer: апликација Кафка потоци, кој го користи преносот на настанот за промена на метаподатоци (MCE) и ја ажурира продавницата за метаподатоци.

datahub-mae-consumer: апликација Кафка потоци, кој користи поток на настани за ревизија на метаподатоци (MAE) и создава индекс за пребарување и база на податоци за графикони.

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

CI/CD на DataHub е со отворен код

Користи складиштето DataHub со отворен код TravisCI за континуирана интеграција и Докер центар за континуирано распоредување. И двете имаат добра интеграција на GitHub и лесно се поставуваат. За повеќето инфраструктура со отворен код развиена од заедницата или приватни компании (на пр. Метеж), Сликите на Docker се креирани и распоредени на Docker Hub за полесно користење од заедницата. Секоја слика на Docker пронајдена во Docker Hub може лесно да се користи со едноставна команда докер повлекување.

Со секое обврзување на складиштето со отворен код DataHub, сите Docker слики автоматски се градат и се распоредуваат во Docker Hub со „најновата“ ознака. Ако Docker Hub е конфигуриран со некои именување гранки на регуларни изрази, сите ознаки во складиштето со отворен код се исто така објавени со соодветни имиња на ознаки во Docker Hub.

Користење на DataHub

Поставување на DataHub е многу едноставен и се состои од три едноставни чекори:

1. Клонирајте го складиштето со отворен код и стартувајте ги сите контејнери на Docker со docker-compose користејќи ја дадената скрипта docker-compose за брз почеток.
2. Преземете ги примероците од податоците обезбедени во складиштето користејќи ја алатката за командна линија која исто така е обезбедена.
3. Прелистајте го DataHub во вашиот прелистувач.

Активно следен Gitter разговор исто така конфигуриран за брзи прашања. Корисниците исто така можат да создаваат проблеми директно во складиштето на GitHub. Што е најважно, ги поздравуваме и цениме сите повратни информации и предлози!

Планови за иднината

Во моментов, секоја инфраструктура или микросервис за DataHub со отворен код е изградена како Docker контејнер, а целиот систем е оркестриран со користење докер-компонира. Со оглед на популарноста и широко распространета Кубернети, исто така би сакале да обезбедиме решение базирано на Кубернетс во блиска иднина.

Исто така, планираме да обезбедиме решение со клуч на рака за распоредување на DataHub на јавна облак услуга како што е Сино, AWS или Google Cloud. Со оглед на неодамнешната најава за миграција на LinkedIn во Azure, ова ќе се усогласи со внатрешните приоритети на тимот за метаподатоци.

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

Извор: www.habr.com