DataHub з відкритим вихідним кодом: платформа пошуку та виявлення метаданих від LinkedIn
Швидкий пошук потрібних даних необхідний будь-якої компанії, яка покладається на велику кількість даних для прийняття рішень на основі цих даних. Це не тільки впливає на продуктивність користувачів даних (включаючи аналітиків, розробників машинного навчання, спеціалістів з обробки даних та інженерів даних), але також прямо впливає на кінцеві продукти, які залежать від якісного конвеєра машинного навчання (ML). Крім того, тенденція до впровадження або створення платформ машинного навчання природно викликає питання: який ваш метод внутрішнього виявлення функцій, моделей, показників, наборів даних і т.д.
У цій статті ми розповімо про те, як опублікували під відкритою ліцензією джерело даних у нашій платформі пошуку та виявлення метаданих, починаючи з перших днів проекту . LinkedIn підтримує власну версію DataHub окремо від версії з відкритим кодом. Ми почнемо з пояснення того, чому нам потрібні два окремі середовища розробки, після чого обговоримо перші підходи до використання WhereHows з відкритим вихідним кодом та проведемо порівняння нашої внутрішньої (виробничої) версії DataHub з версією на . Ми також поділимося подробицями про наше нове автоматизоване рішення для надсилання та отримання оновлень з відкритим вихідним кодом, щоб синхронізувати обидва репозиторії. Нарешті, ми дамо інструкції про те, як почати використовувати DataHub з відкритим кодом, і коротко обговоримо його архітектуру.
WhereHows тепер DataHub!
Команда метаданих LinkedIn раніше представила (Наступник WhereHows), платформу пошуку та виявлення метаданих LinkedIn, і поділилася планами з її відкриття. Незабаром після оголошення ми випустили альфа-версію DataHub і поділилися нею з спільнотою. З того часу ми постійно вносили свій внесок у репозиторій і працювали із зацікавленими користувачами, щоб додати найбільш потрібні функції та вирішити проблеми. Тепер ми раді оголосити про офіційний випуск .
Підходи з відкритим вихідним кодом
WhereHows, оригінальний портал LinkedIn для пошуку даних та їх походження, відкривався як внутрішній проект; команда метаданих відкрила його . З того часу команда завжди підтримувала дві різні кодові бази - одну для відкритого вихідного коду, а іншу для внутрішнього використання LinkedIn, оскільки не всі функції продукту, розроблені для варіантів використання LinkedIn, в цілому були застосовні для більш широкої аудиторії. Крім того, WhereHows має деякі внутрішні залежності (інфраструктура, бібліотеки тощо), вихідний код яких не відкритий. У наступні роки WhereHows пройшов через безліч ітерацій та циклів розробки, що зробило синхронізацію двох кодових баз великою проблемою. Команда метаданих протягом багатьох років намагалася використовувати різні підходи, щоб спробувати синхронізувати внутрішню розробку та розробку з відкритим вихідним кодом.
Перша спроба: "Спочатку відкритий код"
Спочатку ми дотримувалися моделі розробки «спочатку відкритий вихідний код», де основна розробка відбувається у репозиторії з відкритим вихідним кодом, а зміни вносяться для внутрішнього розгортання. Проблема з цим підходом полягає в тому, що код завжди спочатку відправляється на GitHub, перш ніж він буде повністю перевірений усередині. Поки не буде внесено змін з репозиторію з відкритим вихідним кодом і не буде виконано нове внутрішнє розгортання, ми не виявимо жодних виробничих проблем. У разі поганого розгортання було дуже складно визначити винуватця, бо зміни вносилися партіями.
Крім того, ця модель знизила продуктивність команди при розробці нових функцій, які вимагали швидких ітерацій, оскільки вона змушувала всі зміни спочатку поміщати до репозиторію з відкритим вихідним кодом, а потім переносити у внутрішній репозиторій. Щоб скоротити час обробки, необхідне виправлення або зміна можна було зробити спочатку у внутрішньому репозиторії, але це стало величезною проблемою, коли справа дійшла до об'єднання цих змін назад до репозиторію з відкритим вихідним кодом, тому що два репозиторії вийшли з синхронізації.
Цю модель набагато простіше реалізувати для спільних платформ, бібліотек або інфраструктурних проектів, ніж для повнофункціональних користувачів веб-додатків. Крім того, ця модель ідеально підходить для проектів, які починаються з відкритого вихідного коду з першого дня, але WhereHows створювалося як повністю внутрішній веб-додаток. Було справді складно повністю абстрагуватися від усіх внутрішніх залежностей, тому нам потрібно було зберегти внутрішню вилку, але збереження внутрішньої вилки та розробка переважно з відкритим вихідним кодом не зовсім спрацювали.
Друга спроба: «Спочатку внутрішній»
** Як другу спробу ми перейшли на модель розробки «спочатку внутрішній», в якій основна розробка відбувається всередині компанії, а зміни вносяться у відкритий вихідний код на регулярній основі. Хоча ця модель найкраще підходить для нашої нагоди використання, їй притаманні проблеми. Пряме відправлення всіх відмінностей у репозиторій з відкритим вихідним кодом, а потім спроба вирішити конфлікти злиття пізніше - варіант, але це забирає багато часу. Розробники здебільшого намагаються не робити цього під час кожної перевірки коду. В результаті це буде виконуватися набагато рідше, партіями, і, таким чином, ускладнює подальше вирішення конфліктів злиття.
Втретє все вийшло!
Дві вищезгадані невдалі спроби призвели до того, що репозиторій WhereHows GitHub залишався застарілим довгий час. Команда продовжувала вдосконалювати функції та архітектуру продукту, тому внутрішня версія WhereHows для LinkedIn ставала дедалі досконалішою, ніж версія з відкритим вихідним кодом. Він навіть мав нову назву — DataHub. На основі попередніх невдалих спроб команда вирішила розробити довгострокове рішення, що масштабується.
Для будь-якого нового проекту з відкритим кодом команда розробників відкритого коду LinkedIn консультує і підтримує модель розробки, в якій модулі проекту повністю розробляються з відкритим кодом. Артефакти з підтримкою версій розгортаються у загальнодоступному репозиторії, а потім повертаються у внутрішній артефакт LinkedIn за допомогою . Слідування цієї моделі розробки не тільки добре для тих, хто використовує відкритий вихідний код, але також призводить до створення більш модульної, архітектури, що розширюється і підключається.
Однак для досягнення цього стану для зрілої внутрішньої програми, такого як DataHub, знадобиться значна кількість часу. Це також виключає можливість відкритого вихідного коду, що повністю працює, до того, як всі внутрішні залежності будуть повністю абстраговані. Тому ми розробили інструменти, які допомагають нам вносити вклади з відкритим кодом швидше і набагато менш болісно. Це рішення вигідне як команді метаданих (розробник DataHub), і спільноті відкритого вихідного коду. У наступних розділах буде обговорено цей новий підхід.
Автоматизація публікації з відкритим вихідним кодом
Останній підхід групи метаданих до DataHub з відкритим вихідним кодом полягає у розробці інструменту, який автоматично синхронізує внутрішню кодову базу та репозиторій із відкритим вихідним кодом. Функції високого рівня цього інструментарію включають:
- Синхронізація коду LinkedIn з/з відкритого вихідного коду, аналогічно .
- Генерація заголовка ліцензії, аналогічна .
- Автоматичне створення логів коммітів із відкритим вихідним кодом із внутрішніх логів коммітів.
- Запобігання внутрішнім змінам, що порушують складання з відкритим вихідним кодом, шляхом .
У наступних підрозділах будуть детально розглянуті вищезгадані функції, що мають цікаві проблеми.
Синхронізація вихідного коду
На відміну від версії DataHub з відкритим вихідним кодом, яка являє собою єдиний репозиторій GitHub, версія DataHub для LinkedIn є комбінацією декількох репозиторіїв (всередині компанії званих ). Інтерфейс 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 з файлом у репозиторії з відкритим вихідним кодом. Є кілька правил, пов'язаних із цим автоматичним створенням зіставлення файлів:
- У разі декількох вихідних модулів для цільового модуля у відкритому вихідному коді можуть виникнути конфлікти, наприклад, один і той же , що існує більш ніж в одному вихідному модулі. Як стратегію вирішення конфліктів наші інструменти за умовчанням використовують опцію «останній виграє».
- "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) 2) Couchbase 3) 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
Конфлюент Кафка
Обробка потоків
Керований
Embedded (standalone)
Dependency Injection & Dynamic Configuration
LinkedIn Offspring
Build Tooling
Ligradle (LinkedIn's internal Gradle wrapper)
CI/CD
CRT (LinkedIn's internal CI/CD)
та
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, , и має свій власний образ Docker. Для оркестрації контейнерів Docker ми використовували .
Малюнок 2: Архітектура DataHub *з відкритим вихідним кодом**
Ви можете побачити високорівневу архітектуру DataHub на зображенні вище. Крім компонентів інфраструктури, у нього є чотири різні контейнери Docker:
datahub-gms: служба сховища метаданих
datahub-frontend: програма , що обслуговує інтерфейс DataHub
datahub-mce-consumer: додаток , яка використовує потік подій зміни метаданих (MCE) та оновлює сховище метаданих.
datahub-mae-consumer: додаток яка використовує потік подій аудиту метаданих (MAE) і створює базу даних пошукового індексу та графа.
Документація з репозиторію з відкритим вихідним кодом та містять більш детальну інформацію про функції різних служб.
CI / CD у DataHub з відкритим вихідним кодом
Репозиторій DataHub із відкритим вихідним кодом використовує для безперервної інтеграції та для безперервного розгортання. Обидва мають гарну інтеграцію з GitHub і прості у налаштуванні. Для більшої частини інфраструктури з відкритим вихідним кодом, розробленої спільнотою або приватними компаніями (наприклад, ), створені образи Docker, і вони розгортаються на Docker Hub для спрощення використання спільнотою. Будь-який образ Docker, знайдений у Docker Hub, можна легко використовувати за допомогою простої команди .
При кожному коміті в репозиторії з відкритим кодом DataHub всі образи Docker автоматично створюються і розгортаються в Docker Hub з тегом «latest». Якщо в Docker Hub налаштовано деяке , всі теги в репозиторії з відкритим кодом також випускаються з відповідними іменами тегів в Docker Hub.
Використання DataHub
дуже проста і складається з трьох простих кроків:
- Клонуйте репозиторій з відкритим вихідним кодом і запустіть усі контейнери Docker за допомогою docker-compose за допомогою сценарію docker-compose для швидкого запуску.
- Завантажте зразки даних, представлені в репозиторії, за допомогою інструмента командного рядка, який також надається.
- Перегляньте DataHub у своєму браузері.
Активно відстежується також налаштований для швидких питань. Користувачі також можуть створювати проблеми прямо у репозиторії GitHub. Найголовніше, ми вітаємо та цінуємо всі відгуки та пропозиції!
Плани на майбутнє
В даний час кожна інфраструктура або мікросервіс для DataHub з відкритим вихідним кодом побудована як контейнер Docker, а система оркеструється за допомогою . Враховуючи популярність та широке поширення Ми також хотіли б надати рішення на основі Kubernetes в найближчому майбутньому.
Ми також плануємо надати готове рішення для розгортання DataHub у загальнодоступній хмарній службі, такій як , або . Враховуючи нещодавнє оголошення про міграцію LinkedIn на Azure, це відповідатиме внутрішнім пріоритетам групи метаданих.
І останнє, але не менш важливе: дякую всім першим користувачам DataHub у спільноті з відкритим вихідним кодом, які оцінили альфа-версії DataHub і допомогли нам виявити проблеми та покращити документацію.
Джерело: habr.com