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, преди да бъде напълно проверен intern. Докато не бъдат направени промени в хранилището с отворен код и не се извърши ново вътрешно разгръщане, няма да открием никакви производствени проблеми. В случай на лошо разгръщане също беше много трудно да се определи виновника, тъй като промените се въвеждаха партидно.

Освен това, този модел намали продуктивността на екипа при разработка на нови функции, които изискваха бързи итерации, тъй като принуждаваше всички промени да бъдат първо поставени в хранилището с отворен код, а след това да бъдат преместени в вътрешното хранилище. За да се намали времето за обработка, необходима корекция или промяна можеше да бъде направена първо във вътрешното хранилище, но това стана огромен проблем, когато дойде време да се обединят тези промени обратно в хранилището с отворен код, защото двете хранилища излезе от синхронизация.

Този модел е значително по-лесен за реализиране за общи платформи, библиотеки или инфраструктурни проекти, отколкото за напълно функционални потребителски уеб приложения. Освен това, този модел е идеален за проекти, които започват с отворен код от самото начало, но WhereHows беше създадено като напълно вътрешно уеб приложение. Наистина беше трудно да се абстрахираме напълно от всички вътрешни зависимости, затова трябваше да запазим вътрешния клон, но запазването на вътрешен клон и разработката основно с отворен код не сработиха съвсем.

Втора опит: "Първо вътрешно"

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

Третият път проработи!

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

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

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

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

Последният подход на екипа по метаданни към DataHub с отворен код е разработването на инструмент, който автоматично синхронизира вътрешната кодова база и репозитория с отворен код. Основните функции на този инструментариум включват:

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

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

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

В отличие от версията на 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“ означава, че изходният файл не е част от репозитория с отворен код.
• След всяко изпращане в отворен код или извличане от него, това съвпадение автоматично се актуализира и се създава моментален snapshot. Това е необходимо за определяне на добавки и изтривания в изходния код след последното действие.

Създаване на логове на комити

Логовете на комитите за комити с отворен код също автоматично се генерират чрез обединяване на логовете на комитите от вътрешните репозитории. По-долу е даден пример за лог на комит, който показва структурата на лог на комит, създаден от нашия инструмент. Комитът ясно указва какви версии на изходните репозитории са опаковани в този комит и предоставя обобщена информация за лог на комита. Проверете това комит на реален пример за лог на комит, създаден от нашия инструментариум.

metadata-models 29.0.0 -> 30.0.0
    Добавен аспект модел foo
    Отстранен проблем bar

dataset-gms 2.3.0 -> 2.3.4
    Добавен rest.li API за обслужване на аспект foo

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

Поддържани данни конструкции
1) Набори от данни 2) Потребители 3) Метрики 4) ML функции 5) Диаграми 6) Табла с инструментите
1) Набори от данни 2) Потребители

Поддържани източници на метаданни за набори от данни
1) Ambry 2) Couchbase 3) Dalids 4) Espresso 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) Pinot 12) Presto 12) Seas 13) Teradata 13) Vector 14) Venice
Hive Kafka RDBMS

Pub-sub
LinkedIn Kafka
Confluent Kafka

Обработка на потоци
Управлявано
Вградено (самостоятелно)

Инжектиране на зависимости & Динамична конфигурация
LinkedIn Offspring
Spring

Инструменти за изграждане
Ligradle (вътрешен Gradle wrapper на LinkedIn)
Gradlew

CI/CD
CRT (вътрешен CI/CD на LinkedIn)
TravisCI and Docker Hub

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

Микросервизи в контейнери Docker

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

При всяко комитиране в репозитория с отворен код DataHub, всички Docker изображения автоматично се създават и разгръщат в Docker Hub с етикет "latest". Ако в Docker Hub е настроен определен именуване на клонове с регулярни изрази, всички етикети в репозитория с отворен код също се издават с съответните имена на етикети в Docker Hub.

Използване на DataHub

Настройката на DataHub е много проста и се състои от три лесни стъпки:

1. Клонирайте репозитория с отворен код и стартирайте всички Docker контейнери с помощта на docker-compose, като използвате предоставения сценарий за бързо стартиране.
2. Изтеглете демонстрационни данни, представени в репозитория, с помощта на командния инструмент, който също е предоставен.
3. Прегледайте DataHub в браузъра си.

Активно наблюдаван чат Gitter също е настроен за бързи въпроси. Потребителите могат също да създават проблеми директно в репозитория GitHub. Най-важното е, че приветстваме и ценим всякакви отзиви и предложения!

Планове за бъдещето

В момента всяка инфраструктура или микросервис за DataHub с отворен код е изградена като Docker контейнер, а цялата система се оркестрира с помощта на docker-compose. Като се има предвид популярността и широко разпространението на Kubernetes, ние също искаме да предоставим решение на базата на Kubernetes в близко бъдеще.

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

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

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