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 е създаден като изцяло вътрешно уеб приложение. Беше наистина трудно да се абстрахират напълно всички вътрешни зависимости, така че трябваше да запазим вътрешния форк, но запазването на вътрешния форк и разработването предимно с отворен код не се получиха съвсем.

Втори опит: „Вътрешен първи“

**Като втори опит, ние преминахме към модел на разработка „първо вътрешно“, където по-голямата част от разработката се извършва вътрешно и редовно се правят промени в кода с отворен код. Въпреки че този модел е най-подходящ за нашия случай на употреба, той има присъщи проблеми. Директното изпращане на всички разлики в хранилището с отворен код и след това опит за разрешаване на конфликти при сливане по-късно е опция, но отнема много време. Разработчиците в повечето случаи се опитват да не правят това всеки път, когато преглеждат своя код. В резултат на това това ще се прави много по-рядко, на партиди, и по този начин ще бъде по-трудно разрешаването на конфликти при сливане по-късно.

На третия път се получи!

Двата неуспешни опита, споменати по-горе, доведоха до това, че хранилището на WhereHow GitHub остава неактуално за дълго време. Екипът продължи да подобрява характеристиките и архитектурата на продукта, така че вътрешната версия на WhereHows за LinkedIn стана по-напреднала от версията с отворен код. Дори имаше ново име - DataHub. Въз основа на предишни неуспешни опити, екипът реши да разработи мащабируемо, дългосрочно решение.

За всеки нов проект с отворен код екипът с отворен код на LinkedIn съветва и поддържа модел на разработка, при който модулите на проекта са разработени изцяло с отворен код. Артефактите с версии се внедряват в публично хранилище и след това се проверяват обратно във вътрешния артефакт на LinkedIn с помощта на заявка за външна библиотека (ELR). Следването на този модел на разработка е не само добро за тези, които използват отворен код, но също така води до по-модулна, разширяема и включваща се архитектура.

Въпреки това, зряло back-end приложение като DataHub ще изисква значително време, за да достигне това състояние. Това също така изключва възможността за отворен код за напълно работеща реализация, преди всички вътрешни зависимости да бъдат напълно абстрахирани. Ето защо разработихме инструменти, които ни помагат да правим приноси с отворен код по-бързо и с много по-малко болка. Това решение е от полза както за екипа за метаданни (разработчик на DataHub), така и за общността с отворен код. Следващите раздели ще обсъдят този нов подход.

Автоматизация на публикуване с отворен код

Най-новият подход на екипа на Metadata към DataHub с отворен код е да разработи инструмент, който автоматично синхронизира вътрешната кодова база и хранилището с отворен код. Характеристиките на високо ниво на този инструментариум включват:

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

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

Синхронизиране на изходния код

За разлика от версията с отворен код на DataHub, която е едно хранилище на GitHub, версията на LinkedIn на DataHub е комбинация от множество хранилища (наричани вътрешно мултипродукти). Интерфейсът 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. Всеки целеви модул в хранилище с отворен код може да бъде захранван от произволен брой модули с изходен код. За да посочите вътрешните имена на хранилищата в изходните модули, използвайте интерполация на низове в Баш стил. Използвайки файл за картографиране на ниво модул, инструментите създават файл за картографиране на ниво файл, като сканират всички файлове в свързаните директории.

{
  "${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 и ще обясним причините за тези разлики.

Един източник на несъответствие произтича от факта, че нашата производствена версия има зависимости от код, който все още не е с отворен код, като например Offspring на LinkedIn (вътрешната рамка за инжектиране на зависимости на LinkedIn). Offspring се използва широко във вътрешни кодови бази, защото е предпочитаният метод за управление на динамична конфигурация. Но не е с отворен код; така че трябваше да намерим алтернативи с отворен код на DataHub с отворен код.

Има и други причини. Тъй като създаваме разширения към модела на метаданни за нуждите на LinkedIn, тези разширения обикновено са много специфични за LinkedIn и може да не се прилагат директно към други среди. Например имаме много специфични етикети за идентификатори на участници и други типове съвпадащи метаданни. И така, сега изключихме тези разширения от модела на метаданни с отворен код на 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) Основа на дивана 3) Далиди 4) Еспресо 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) Пино 12) Престо 12) Seas 13) Teradata 13) Вектор 14) Венеция
Hive Kafka RDBMS

Пъб-под
LinkedIn Кафка
Влива се Кафка

Поточна обработка
Сайтът се поддържа
Вграден (самостоятелен)

Инжектиране на зависимости и динамична конфигурация
LinkedIn потомство
Пролет

Инструменти за изграждане
Ligradle (вътрешната обвивка на Gradle на LinkedIn)
Градлю

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

Хранилища за метаданни
Разпределени множество GMS: 1) GMS с набор от данни 2) GMS с потребители 3) GMS с показатели 4) GMS с функции 5) GMS с диаграма/табло
Един GMS за: 1) Набори от данни 2) Потребители

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

докер опростява внедряването и разпространението на приложения с контейнеризация. Всяка част от услугата в DataHub е с отворен код, включително инфраструктурни компоненти като Kafka, Elasticsearch, neo4j и 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 контейнер и цялата система е оркестрирана с докер-ново съобщение. Като се има предвид популярността и широкото разпространение Kubernetes, ние също бихме искали да предоставим базирано на Kubernetes решение в близко бъдеще.

Също така планираме да предоставим готово решение за внедряване на DataHub в публична облачна услуга като напр Лазурен, AWS или Google Cloud. Като се има предвид скорошното съобщение за миграцията на LinkedIn към Azure, това ще бъде в съответствие с вътрешните приоритети на екипа за метаданни.

И накрая, но не на последно място, благодарение на всички първи възприели DataHub в общността с отворен код, които оцениха алфа версиите на DataHub и ни помогнаха да идентифицираме проблеми и да подобрим документацията.

Източник: www.habr.com