Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Data Mesh: не софтверний розв’язок софтверних проблем даних

Привіт, мене звати Олександр, я — розробник і один з учасників команди подкасту «Опівночні Балачки», нас там троє, ще є Денис та Ігор. Ми працюємо в різних компаніях, але маємо спільні інтереси і створюємо профільний контент про машинне навчання, розробку та всякі інші речі на перехресті.

Цей текст — переказ з невеликими змінами випуску № 12 нашого подкасту. Матеріал буде цікавим для всіх, хто слідкує за сучасними тенденціями у Data Engineering чи найліпшими практиками створення продуктів, які побудовані на великій кількості даних (а, судячи з вакансій, дата інженером нині бути — це перспективно).

Tl;dr: Data Mesh можна зрозуміти за аналогією системи на базі мікросервісів. Маємо чітку дата платформу, на яких запускаються наші дата продукти. Так само як на k8s кластері запускаються окремі мікросервіси. Дата продукти використовують різні можливості дата платформи для свого функціонування. Завдання дата продуктів — поглинати і видавати «на вихід» трансформовані дані, які повʼязані з певним доменом (чи кількома). В термінології Data Mesh це input та output порти. У них обовʼязково мусить бути чітка специфікація формату і способу видачі даних (на кшталт звʼязки GRPC + Protobuf у ваших сервісах). І було б непогано мати можливість зрозуміти, з яких початкових даних було отримано результуючі, тут це називається data lineage (щось схоже на distributed tracing).

Випуск ще з часів, коли лише один з нас говорив українською. Ми стали більш впевнені у своїх навичках і новіші епізоди вже на 100% українською. Якщо вам лінь читати, то можна, власне, послухати подкаст.

Вступ

З назви концепції Data Mesh, «дата мешів» не зрозуміло, чи відноситься це до даних, чи до обробки даних, чи їх використання. Чи це хайп лиш одного дня? Втім, уже два роки (майже три), як зʼявився цей підхід, люди досі обговорюють та приміряють його до своєї роботи з даними.

Найбільший в історії софтверний IPO, що відбувся позаминулого року, — у компанії Snowflake. І це є релевантно тому, що їх продукт обіцяє позбавити вас болю від управління сховищами даних у великих організаціях і взяти на себе всі операційні навантаження. Є й інші компанії, що працюють в цьому напрямі, і вони також успішно підіймають інвестиції під великі оцінки (наприклад, SingleStore).

Дисклеймер: ми будемо говорити про практику обробки даних, про речі, з якими ми так чи інакше стикалися, але також і про концепти, які ми знаємо лише теоретично з відкритих джерел, доповідей, статей і таке інше.

Але почнемо ми, відступивши на крок назад, з того, як оброблялися аналітичні дані.

Звідки зʼявилися ті дані, і нащо їх ховати

Передбачаємо, що читач знає, як працюють софтверні продукти і архітектури взаємодії клієнт-сервер. Тоді ви розумієте, що, зазвичай, за усіма продуктами стоїть персистентне сховище даних, так звані бази даних.

На початку люди користувалися базами даних за допомогою API, записували якісь дані і користувались цим, щоби мати змогу опрацьовувати якісь транзакції, проводити продажі, робити грошові перекази і т.п.

В якийсь момент, невідомо де, невідомо коли, хтось сказав «Ей, Пітер Паркер, мені потрібні інсайти!», заохочуючи його підлеглих генерувати т.з. «бізнес-інсайти». Спочатку і для аналітики, і для звичайної роботи ПЗ використовувалась одна і та ж СУБД, Але з часом стало зрозуміло, що запити аналітиків занадто навантажують ту ж саму базу, що обслуговує ваш продакшн. Почався поділ сховищ даних ще й з точки зору зручності доступу до даних для тих чи інших цілей. Умовний поділ на операційний та аналітичний формат.

З часом, все прийшло до того, що у вас є окрема БД, якою ми користуємося щодня і такі собі «сховища даних», data warehouse, де у нас зберігаються дані за N-у кількість днів-тижнів-місяців-років. І саме вони дозволяють нам робити певні звіти та отримувати «бізнес-інсайти». Наприклад, якщо брати роздрібну торгівлю, то за допомогою подібних даних ми матимемо відповідь на питання: «яка кількість підгузок продавалася в перший і останній квартали певного року».

Стосовно структури даних для аналітичних сховищ, з часом прийшли до роботи довкола однієї таблиці, яку назвали «fact table», де кожен рядок відповідає певній транзакції у вашій системі. На прикладі торгівлі, це може бути транзакція про покупку. Вона буде мати унікальний ідентифікатор продукту, його кількість, ідентифікатор покупця та інші дані. Кожен з цих ідентифікатор буде звʼязувати наші дані з іншими таблицями через референси. Саме з них можна буде дізнатися конкретні деталі та значення певних полів-властивостей. Через те, що це виглядає як одна «широка» таблиця, що посилається на велику кількість інших, ви отримуєте таку собі ⭐ зірочку зв’язків, де одна таблиця всередині зв’язана з купою навколо. Якщо почнете розбивати ці властивості ще далі, і вже в дочірніх таблицях посилатися на інші, ви отримаєте другу популярну архітектуру — ❄️ сніжинку.

В якийсь момент цей підхід змінився, бо люди весь час хочуть робити краще, крутіше, і впроваджують поступові зміни. Але у загальному вжитку на заміну централізованим data warehouse прийшли озера даних, ака data lake. Якщо передати ідею двома реченням, то «не будемо прямо зараз зводити все до купи в єдину таблицю, часу немає, ви бачили, скільки в нас мікросервісів? Але дані — то важливо, потім будемо продавати, а поки що просто давайте кожен сервіс на s3 логи скидати буде».

Проблемно менеджерити дата вєерхауз? Дата лейки поспішають на допомогу. З вас знімають необхідність тримати інженерів, що будуть управляти і підтримувати ваше сховище даних, працювати зі схемами даних. Також не потрібно вирішувати проблему, кому і який доступ треба давати в організації. Вам також не треба строго слідкувати за тим, щоб потрібні дані структуровано попадали в таблиці, де вони мають бути. Ну, і звільнивши людей від необхідності проводити свої дані по всьому цьому ланцюжку, ми отримали вільні руки, щоб клепати жсон ейпіаї створювати продукт.

В підході data lake не обовʼязково буде дуже чіткий і зрозумілий інтерфейс доступу до даних, але принаймні знатимете, що ці дані є і якщо вони будуть потрібні, їх візьмуть. Можливо, ці дані не грають великої ролі для операційної діяльності чи генерації якихось регулярних інсайтів, але ці дані непогано б мати для глибшого аналізу.

Натяком на те, що ваш проєкт сповідує філософію/ підхід data lake може бути факт, що вашу гугл аналітику ви складаєте у біг квері «на майбутнє» чи всі файли, які ваші юзери заливають, навіть якщо вони вам ніколи потім не знадобляться (і вони не мають персональних даних) кидаєте на s3, хай полежать. Чимось це схоже на розлад поведінки, коли люди накопичують різних мотлох вдома (силогоманія).

Різниця між людьми, які просто страждають розладом накопичення і тими, хто зберігає речі про запас полягає в тому, наскільки вони систематичні, чи мають вони можливість у будь-який момент часу знати, принаймні, в якій кімнаті та в якому кутку лежать їхні дані і, коли знадобиться, вони зможуть отримати до них доступ. Або покликати на допомогу дата інженера, який зможе цю купу розгребти і перетворити на корисні дані.

Дата інженери

Тепер про дата інженерів. Назва ролі доволі нова, але за змістом така професія існує доволі давно. Інженери даних мало відрізняються від інженерів програмного забезпечення. Єдина відмінність, мабуть, полягає у тому, що дата інженери мусять справді розуміти, як обробляти надвеликі (або просто великі) масиви даних. І знову ж таки, за останні десятиріччя було створено багато інструментів для цього, включаючи різного роду сховища даних, ETL процесори та всяке таке інше. Їхня робота якраз і полягає в тому, щоби опанувати ці інструменти і вміти їх використовувати для вирішення кількох класів задач.

Ми б розділили ці задачі умовно на такі:

  1. Data Ingestion, себто «всмоктування даних», завантаження даних у систему.
  2. ETL. Extract — transform — load операції. Систематизуємо отримані сирі дані і розкладаємо по «полицях» нашого дата сховища.

Для збереження місця у публікації, за більшою кількістю деталей будемо посилатись або на «Вікіпедію» або на наш гонзо переказ.

Джерелом даних, які необхідно завантажити, можуть бути REST API, черги повідомлень, результати crawling’у вебсторінок, дані в файлах екзотичного формату чи зліпки операційної БД.

Дуже часто ingestion закінчується тим, що дані опиняються в data lake, адже це не вимагає надзусиль по формуванню як самої структури даних, так і дизайну бази, і в ролі data lake може виступати будь-який HDFS сторейдж або s3 / blob storage у AWS / GCP.

Так, що там в нас далі... Дата інженери отримали якісь формалізовані вимоги про те, до якого виду мусять бути приведені дані, які і як саме. Вони імплементують пайплайни, що можна віднести до окремих етапів у ETL підході. Отримані дані можуть передавати, кому треба: аналітикам, дата саєнтистам, бізнесу, і після цього з гордістю стверджувати «ми все зробили».

На цьому етапі важливо, щоб в певний момент кінцеві користувачі даних дізналися, що а) дані є, дані зібрані, б) як і де до них можна отримати доступ, яка природа даних з точки зору структури колонок і можливих даних. В цьому плані сховища даних трішки ліпші у розумінні «із коробки», тому що маючи SQL інтерфейс, можна дізнатися схему таблиць, в яких дані зберігаються. Але деяка кількість формалізованих каналів комунікації та документації так чи інакше мусить бути присутня.

Що саме в цій системі може піти не так

Все! Починаючи з першого кроку, ingestion. Дата інженерам дають якусь документацію потенційного джерела даних і говорять «чуваки, ось є дані, нам їх треба заінжестити». Ось вам заплутано написана документація (а чи бувають інші?), подивіться, що нам треба, і візьміть з потрібних місць ті дані, що потрібні нам.

Ну, і дата інженери такі «о круто, все ясно», і беруться до роботи: тут треба скрейпити сайт, погнали. Можливо, дата інженерам ще надали якісь більш високорівневі вимоги до кінцевої фічі і передбачається, що вони розберуться, що з тими вимогами треба робити. Вони сідають і просто роблять свою роботу.

Доволі часто буває так, що дата інженери роблять технічно правильну задачу, яка технічно правильно виконується, але яка втрачає будь-який сенс. Утрируваним прикладом подібного може бути таке: поставлена задача — зібрати теги інстаграму; ми сетапимо скрейпінг чи кверяємо апі, вважаючи на рейт ліміти, пропихаємо це через всі наші пайплани і зберігаємо у data lake посортовані теги з інформацією про кількість спільних згадок. Тут дата саєнтисти дістають зі своєї кобури BigGAN, але є невелика проблемка — окрім тегів, нам треба і самі картинки, щоб вміти теги передбачати по картинках.

Якось так, але в інших масштабах, це відбувається і в реальному житті. Бо люди, які складають технічну специфікацію щодо процесу завантаження даних, можуть не розуміти всіх деталей реалізації, задуму та кінцевих вимог. Відповідно ці деталі реалізації втрачаються у термінології, губимося в тих трьох соснах. І дата інженери реалізують це по-своєму.

Звісно, інформація про те, що дані не повністю або неправильно зібрані, ми отримаємо лише коли пройдемося по всьому ланцюжку. Через ланку ingestion, через ETL (чим можуть займатися, в теорії, різні люди, і навіть команди). Навіть коли дані вже складені в сховище даних, ніхто не запідозрить підступ, допоки дата саєнтисти або аналітики не почнуть аналізувати ці дані і не зрозуміють, що там все не так.

Тож, спроба № 2. Створюємо нові вимоги, які враховують попередні помилки, вимоги передаються дата інженерам, робота пішла за тими ж етапами і БУМ — в кінці циклу знову ж таки дата-аналітики виявляють, що щось не так: поле зіскраплено неправильно, або цей API віддає не зовсім ту інформацію, або якесь строкове значення видає не настільки специфічну інформацію при певних умовах, як би нам хотілось. І знову ж таки, чия це відповідальність?

Здавалося б, звинуватити можна дата інженерів, бо вони погано організували скрейпинг даних або неправильно інтерпретували вимоги, але чи можна це робити в такому випадку? Замість того, щоб когось звинувачувати, можна означити, що це — один з недоліків такої побудови процесу роботи з даними.

Якщо говорити не про недоліки процесуальні, розглянемо приклад. Уявімо, що у нас є дані, які дата інженери успішно завели в систему. Можливо, дата інженери інтегрують дані з кількох десятків джерел, і ці всі дані потрапляють у наше сховище даних. Умовно кажучи, наявність даних у сховищі даних є критерієм успішності задачі, щоб аналітики могли організовувати репортінг на цьому.

За підсумками роботи в умовах стартапу з подібною організацією, де все дуже часто змінюється, матимемо десятки таблиць початкових даних від дата інженерів і сотні таблиць чи materialized view від аналітиків. Знову ж таки, часто подібні таблиці не підписані, у Slack ніхто не зізнається, що це його таблиця, імена таблиць з якимись temp_ префіксами чи з v1-v2-v10 суфіксами. А ще й логування у вейрхаузі здогадались включити через 3 місяці після того, як почали працювати, коли всі ці мільйони* (* — утрируємо) таблиць вже створено... Ми ж стартап, нам треба якнайшвидше все зробити, не маємо часу змоделювати, які логи нам потрібні або не потрібні.

І якщо підсумовувати, то за декілька місяців ми маємо сховище даних, в якому купа всього, але дуже слабко визначено, хто за які дані відповідає, розмежування доступів дуже складно правильно надати. Особливо якщо на рівні самого інструменту для сховища даних це не має якісної підтримки. Але навіть якщо і підтримує, біль від організації команди на групи і розуміння, які групи до яких даних мусять мати який тип доступу, прописування якихось політик і таке інше. Забезпечити data governance, одним словом (ладно, двома).

І це ми ще не розповідаємо про великі компанії, всередині яких відбуваються якісь дивні (на погляд людей, що працюють у здоровій атмосфері) політичні ігри замість спроб кооперативно дійти спільної мети. Оскільки у різних команд-відділів різні боси, кожен з яких має свої інтереси. Деякі боси хочуть ділитися з іншими босами цією інформацією, деякі — ні. Окремим питанням може бути спроба перекладати відповідальність за провали у ланцюжку виконання інтеграції джерела даних.

І подібні проблеми — не виняток, а скоріше закономірність, коли ви будуєте Найліпший Продукт™️, повʼязаний з даними, але не знаєте напевне, як його побудувати. Добудовуєте цей літак, коли він вже здійнявся в повітря, якщо вам взагалі вдасться відірватися від землі.

І так відбувається тому, що ви щоразу відкриваєте нову і нову інформацію не тільки про свої дані, як структуру, але й кількість даних, а ще дізнаєтесь про якісь втрати даних, чи проблеми якості даних. Але частина цих проблем і швидкість реакції на них зумовлена саме організацією всього процесу у цій парадигмі. У парадигмі, де існує чіткий розподіл на окремі ролі, що відповідають за окремі фази життя даних у вашому продукті: дата інженери — ingestion і ETL; аналітики/саєнтисти — звіти і моделі; розробники — продукт на основі моделей/даних.

Новий варіант, як це виправити

Чому, маючи таку ідеальну структуру, ідеальний поділ зон відповідальності (separation of concerns) між дата інженерами і аналітиками, ми будуємо дата системи і вони постійно мають зламані дані? Дані постійно неправильні, бізнес — не задоволений, а звіти вічно знаходяться у стані хотфіксів. І, в принципі, люди багато різних проблем намагаються вирішити (або успішно вирішили) паралельно: і про способи утримання даних актуальними, і про способи знати про існування різних даних всередині єдиної системи, і про редуплікацію повторюваних обчислень, що необхідні для різних споживачів (з точки зору організаційної структури, читай «департаментів»), і про способи надання єдиних інтерфейсів доступу до так необхідних усім даних.

Створено міріади інструментів, як опен-сорс, так і пропрієтарних. Багато писалося про різні концепції, і в деяких з них можна побачити окремі ідеї, які перекочували до концепту, про який йдеться далі.

Одним із варіантів підходів, що намагається вирішити всі проблеми є Data Mesh, які ми далі називатимемо «дата мешами» (можна було б перекласти як «мережа даних» чи «сітка даних», але це може хибно сприйматися як data network). Ну, добре, не всі проблеми, але принаймні ту частину, що повʼязана з роботою з аналітичними даними у компанії.

Цей концепт було сформовано і презентовано інженеркою Джамак Дельгані, яка працює у ThoughtWorks. Перший великий допис про дата меші був на сайті martinfowler, що є популярним ресурсом з багатьма описами архітектурних підходів та поширених практик написання коду. Дата меш архітектура передбачає не лише зміни кодової бази чи використання якогось певного інструменту, а й загалом зміну структури і розподілу відповідальності, які лежать на плечах інженерів з різних команд, чи то дата інженери, дата саєнтисти, чи аналітики.

Чому дата меш — це не про технологію, а підхід? Ну, як мінімум через проблеми, що виникають при розподілі роботи з одним і тим самим джерелом даних у різних відділах (див. розділ «Що в цій системі може піти не так?»). Дата меш пропонує формувати команди не на основі конкретно навичок (ще відомий як «функціональний» поділ, де для нашого прикладу у нас буде окрема команда дата інженерів, де всі займаються ingestion), а скоріше на основі так званих дата продуктів, або под-команд (pod team).

Така команда — кросдисциплінарна, і вона має компетенцію робити усі кроки пайплайну, від ingestion до моделювання. Ще, у такій організації важливим елементом є наявність спільної платформи даних (data platform), на якій запускаються дата продукти. Сама дата платформа зменшує кількість болю, який мусить вирішувати дата продуктова команда, відносно підтримки інфраструктури та вибору інструментів для створення ingestion пайплайнів та ETL, як і сховища для збереження чистих даних. Тому платформа організовує цей фреймворк для команд, і дає змогу більше зусиль продуктовим командам безпосередньо витрачати на розробку продуктових рішень.

Тому у нас є поділ на інженерів платформи даних та продуктових інженерів, до навичок останніх можуть входити навички дата інжинірингу, дата саєнсу і аналітики даних. Оригінальна концепція зазначає, що бажано, щоб у кожній продуктовій команді була суміш цих компетенцій. І для допомоги їм є інженери платформи, що надають інструменти і гайдлайни як робити всі складові обробки і аналізу даних.

Тут можна провести паралель з рухом DevOps, коли у нас був початковий поділ на розробку і операційну підтримку, і в кінці циклу розробки програмісти «через паркан» перекидають дискету-флешку-диск з кодом, і далі вже оперейшнз займаються задачею запуску і стабільної роботи продукту.

В цьому контексті девопс був і є рухом до того, щоб ми налаштували платформу і надали інструментарій, щоб самі розробники могли відповідати і за операційну підтримку свого коду. Можливо, це робилося вже на вищому рівні в залежності від можливостей платформи, але розробники мали можливість напряму впливати на те, що буде відбуватися, таке собі самообслуговування.

В дата мешах також вирішуємо подібні задачі, але в контекстах обробки даних. Тому команди платформи даних — це щоб ідентифікувати, яких інструментів для яких задач не вистачає, і або додавати їх у платформу, або придумати обхідні шляхи, гарантуючи можливість командам співіснувати і кожній з них бути відповідальним за власні дані і результати їх обробки, і мати більш передбачувану розробку і свідомо до неї підходити.

Тому, якщо намагатися формалізувати, то дата опси будують дата платформу, що покриватиме наступну функціональність: ingestion механізми, великомасштабний ETL і інструменти взаємодії між дата продуктами.

Дата продукти — це мікросервіси, які інкапсулюють у собі один бізнес домен. Тобто певна команда буде відповідальна за певний дата продукт, якому відповідатимуть конкретні сутності. Наприклад, для рітейл системи може бути дата продукт що відповідає за замовлення покупців.

У дата продукта обовʼязково мусять бути вхідні та вихідні порти (input ports / output ports) — це інтерфейси для даних які прямують «в» або «з» мікросервісу. Якими можуть бути ці порти? Як різного роду бази/сховища даних, так і черги повідомлень. Єдине, що вимагається від цих сорців — щоб вони були задокументовані і дата опси могли швидко надати якийсь відносно легкий доступ до цих даних.

Це знімає необхідність інженерам продукту думати про скейлинг, а замість цього фокусуватися на відкриванні по дещицях особливостей інформації, з якими починається робота. І скоріш за все, стандартизовані (і задокументовані) інпут-аутпут порти — це найважливіший технічний аспект, що дозволяє спрацювати цьому підходу.

Варто також памʼятати, що аутпут порти дата продуктів можуть бути як «кінцевим продуктом» так і слугувати інпут портом інших продуктів даних. Тому можемо уявляти таку собі структурну сітку (звідки і береться назва підходу), де є команди/продукти, які читають звідкись дані і надають до оброблених даних доступ за заданою специфікацією, відомою всім у компанії з подальшою можливістю робити перехресне зʼєднання даних з різних продуктів.

І якщо в прикладі вище, окрім команди, яка працює з доменом Замовлення, є команда, що працює з Інвентарними даними і третя команда, що мусить перетнути дані з цих двох дата продуктів, вона зможе це зробити, через стандартизований SQL-подібний або data lake інтерфейс (який можна надалі кверити умовним Spark’ом або Athena’ою або Presto).

Авжеж, інтерфейс може і бути http інтерфейсом, можливо graphql, який чітко прописаний загалом командою дата платформи. Дата меш не встановлює якісь обмеження щодо імплементацій. Іншим варіантом рішення могло б бути користування кожним дата продуктом власним RDS на амазоні. І далі матимемо один центральний Redshift, у якого є функціонал обʼєднувати різні RDS і надавати до них спільний доступ і робити JOIN запити на них. І ще один варіант з ряду «на вскидку»: кожен output порт — це s3, куди ми кладемо наші дані у форматі parquet, а далі використовуємо Presto, щоб їх надалі поєднувати і аналізувати. Або альтернативою престо ще може бути Amazon Athena.

Що ще важливо в концепті Data Mesh? Це discoverability, можливість знаходити потрібні дані. Ми мусимо мати змогу дізнаватися про існування сервісів та даних, з якими вже працюють інші команди. Для цього вже потрібні якісь інструменти у вигляді дата-каталогів, за інструментарій яких відповідає команда платформи.

Вони можуть зчитувати схему атупут портів тим чи іншим чином. Для SQL — це відносно тривіально, для інших варіантів можна щось придумати, як-от: віддавати метадані у певному форматі як частину аутпут порта. І якщо все це зібрати до купи і додати трішки аналізу у код трансформацій, то можна побудувати lineage схему, схему походження даних, з можливістю прослідкувати, звідки прийшли дані і на основі яких колонок попередніх аутпут портів їх було отримано. Така собі умовна «карта ETLів». Навіть якщо саме походження даних трекати ми не будемо, дуже корисно мати каталог даних з можливістю пошуку, де люди можуть зайти і, як на базарі, обрати дані, які їм потрібні. З певністю в тому, що там будуть всі дані з їх системи у чітко заданому форматі.

Коли ми маємо правильно розмежовані бізнес сутності, у нас є чітке розуміння, яка команда за них відповідальна. І саме вони будуть вирішувати проблему некоректності або невалідності даних. І вони не матимуть можливості перекласти провину на когось іншого, бо «блін, якась десята команда, яка відповідає за якийсь ingestion наших сутностей, наробила ділов і ми нічого не знаємо».

Це суттєво спрощує роботу і швидкість реагування на проблеми. Окрім чіткого поділу відповідальності, маємо також можливості і чітко розмежовувати доступи до даних, маючи деякий Data Governance. Це якщо дата платформ інженери будуть мати систему, яка роздає доступ до окремих дата продуктових сервісів. Якщо у кожного дата продукта своє сховище даних, то при необхідності — надаємо доступ саме до потрібних сховищ даних.

З тих питань, над якими ми працювали, було і питання змін схеми output port’а якогось сервісу, на який спирається декілька інших продуктів, — що робити в такому випадку? В принципі, якщо ми пишемо forward-compatible код, то не мусить бути проблемою додавання колонок. Зміна назв-видалення колонок вже серйозніша зміна, що може зачепити стабільність роботи інших сервісів, а тому все буде залежати від самого формату порта: можливі варіанти створення паралельного дата продакту, або ж нової версії дата порта (що відносно зрозуміло для http кейсу, а для інших це означає мати нові таблиці/вьюхи для ваших SQL таблиць чи нові шляхи для s3 артефактів). Якщо маємо lineage схему для даних, то можемо відслідковувати за її допомогою, що «споживачі» перейшли на нову версію даних.

Інструментарій Data Mesh

Які інструменти можуть допомогти про побудові власне дата платформи? В принципі, дуже розповсюдженим варіантом є побудова дата платформи на databricks, оскільки він має багато ознак lingua franca для того, щоб будувати дата платформу. За його допомогою можна «підсісти» на spark, використовуючи його з hdfs, або використовуючи ваш data lake на s3.

Databricks відповідно надає універсальний інтерфейс запитів до цих даних. Через наявність spark можна використовувати spark sql або dataframe операції і робити необхідні вам аналізи і трансформації. Зазвичай саме з кроком ingestion дата брікс може не впоратися, оскільки він більше орієнтований на виконання аналітичної функції у вашій дата платформі.

А як зробити ETL? Багато компаній намагаються структурувати цей процес через якісь шини даних (message bus), через черги повідомлень. Дуже розповсюдженим варіатом тут є kafka завдяки гнучкості її налаштувань і можливості гарантувати, що дані на правильно налаштованому кластері потраплять у чергу, і всі підписники зможуть їх вичитати з відповідного топіка. І ті ж самі підписники зможуть далі їх трансформувати і скласти в сховище даних чи інше місце.

Але інколи можна навіть не ускладнювати це все кафкою, якщо ви маєте справу з відносно поширеними типами даних. Якщо ви працюєте з даними гугл аналітики, фейсбук реклами чи отримаєте дані з гугл драйву, куди їх складають люди, то є окремі інструменти, які допоможуть вам зробити цей ingestion.

Наприклад, fivetran.io — платний продукт, у стадії стартапу, що виступає конектором подібних джерел і ваших баз даних або хмарного сховища. Після налаштування він почне в автоматичному режимі це робити. Але для бажаючих пригод, і вміючих правити інструменти для себе, єй аналоги з відкритим сирцевим кодом. Наприклад, airbyte, що побудований на singer. Сам singer також має перелік готових рішень, щоб на додаток до гнучкості самому написати необхідні частини як для отримання, так і зберігання даних.

Такі інструменти дозволяють автоматизувати цей марудний процес отримання даних, які вже були написані для вас. І результатом роботи цього ПЗ будуть дані з чіткою структурою і інтерфейсом доступу. Тому можливо використати щось на кшталт fivetran/singer/airbyte у зв’язці з databricks для покриття всіх функцій дата платформи. Але і є варіант взяти умовний airflow + k8s + spark on k8s і робити свою дата платформу на цих інструментах.

Це всього два варіанти з безлічі комбінацій інструментів, які трішки відрізняються один від іншого з точки зору кількості вендорлоків і винагороди третім сторонам за використання не власноруч написаних інструментів.

Також у провайдерів хмарних обчислень зазвичай є продукти, що мають на меті закривати потребу дата продуктів. У Amazon це — Glue, який, на час запису подкасту, був скоріше інструментом для ETL, більш низькорівневим аналогом fivetran, і давав можливість в UI або дуже простим кодом налаштувати, звідки брати і куди складати дані. У Google Cloud Platform є Dataflow, та й Azure має якісь Data Factory.

Можна підсумувати, що в просторі рішень проблем побудови дата платформа багато чого відбувається, є рішення як від великих вендорів, так і стартапів поменше; як платні, так і опенсорс рішення. Люди завжди будуть продовжувати будувати щось з низькорівневих блоків самі, але доволі «підігріта» ніша і, можливо, з плином часу, матимемо все більше блоків і далі продовжимо дертися цими сходинками абстракції на вищі шаблі.

Виглядає прикольно? Йдемо далі

Чи підійде метод і, по суті, культура, дата меш всім?

Поділ на інженерів платформи і продукту вже несе за собою якісь витрати, які можуть бути обтяжливими для стартапів на початкових стадіях, та навіть невеликих компаній. Тому повний дата меш варто реалізовувати лише при наявності коштів і потреби на це.

Як визначити, чи є потреба? Якщо у вас все працює і не було проблем, які ми означали на самому початку — нічого не треба змінювати.

У вас точно не буде потреби, якщо у вас всі дані — це один дата сорс на три колекції, з якою працює команда з чотирьох-п’яти осіб. При такому розмірі команді буде 2-1-2 чи 2-2-1 дата інженер/ аналітик/ саєнтист, і тут буде простіше дата саєнтисту подивитись на дані, які завантажив в систему інженер і, якщо вони не працюють, сісти разом з ним у сесію парного коду і виправити ситуацію.

Але як починати нові проєкти, маючи уявлення про подальший потенційний розвиток вертикалі роботи з даними при рості, з урахуванням підходу дата меш?

Виходить, що якщо є всього один інженер і він думає в концептах «ця частина — це відповідальність платформи», а «ось ця — частина дата продукту», то все зійдеться до якихось загальних принципів, схожих на звичайні принципи архітектури ПЗ та SOLID, з правильно розділеними сховищами за окремими доменами, з чітко визначеною специфікацією.

Їх ETL обробка буде виконуватися з використанням одного і й того ж набору інструментів і більш-менш централізовано, з однаковими дата портами для отримання даних. І надалі при збільшенні кількості доменів чи складності дата платформи можна буде органічно збільшити і відокремити команду на необхідну структуру.

Як переводити проєкти, які вже працюють, на дата меші? Окрім зрозумілого опору організаційного, який треба подолати, і закладання структурних і культурних змін, які мусять відбутися, все інше буде сильно залежати від вашого поточного стану речей і того, що ви хочете зробити. Непоганим першим кроком буде уточнення всіх наявних потоків даних у всіх різних командах, які у вас є, інвентаризація і побудова їх специфікації. Потім — пройтись по переліку джобів для ETL і ingestion, а також сховищ наших даних. І далі намагатися знайти найближчий спільний знаменник та рухатись в тому напрямку з уніфікацією інтерфейсів, конекторів і портів. І потихеньку виокремлювати частину, пов’язану з платформою обробки даних від роботи з даними.

Чомусь здається, що більше проблем буде з людьми. Ніякий дейта меш не врятує вас від конфліктів в команді (чи між командами).

Ідеї дейта меш активно просувають:

  • thoughtworks, які все це придумали і заробляють гроші;
  • Zalando, які активно пропагують цей підхід і у публічній площині досить активно його форсують;
  • IBM популяризують цю парадигму і викладали в опен-сорс релевантні шматочки своєї cloud native платформи (fybrik який раніше був the-mesh-for-data).

У Netflix також говорили про дата меші, але тут це, скоріше, конфлікт неймінгу, бо їх дата меші це більше схоже на сервіс меш підхід, застосований на даних.

***

За час між початком підготовки до подкасту і написанням чорнетки цього допису також у спільноті почали обговорювати Data Fabric, ще один новий і «не такий як всі» підхід до опрацювання даних і побудови роботи навколо нього, де велика роль віддається автоматичній обробці метаданих за допомогою машинного навчання та ШІ.

Чи був Data Mesh ще одним підходом, який назавжди буде жити в тіні класичних компаній, що десятиріччями будуть складати свої дані у невибагливі Data Warehouse, чи залишиться він з нами до появи чогось адекватнішого — покаже лише час.

Будемо раді фідбеку на цей допис чи випуск подкасту, залишайте свої коментарі тут або долучайтесь до нашого телеграм-каналу, підписуйтесь на аудіо платформах чи слідкуйте за нами в твітері та тік-ток.

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

дуже цікава і корисна стаття. автору подяка!

підхід цікавий якщо мислити категоріями і мати як мінімум декілька дата інженерів на проекті між якими можна розділити підпроцеси. на практиці ж і на проектах де працював не маю уяви як би то можна імплементувати, оскільки дійсно це породжує конфлікти інтересів між інженерами, командами. і тоді ніякий дата меш не допоможе вирішувати проблеми, а навпаки породить нові

Data mesh це просто ще один баззворд, бленд ідей з data factory, data virtualization та governance , який вирішує певні проблеми, натомість створює кучу нових, створений щоб продовжити щось продавати

А у вас користуються цим підходом?
Теоретично, частково поділяю вашу думку, з іншого боку чую від принаймні однієї людини, в чиїй компанії запровадили, позитивні відгуки.
Головна мета статті тут — розказати про існування подібної штуки. Якщо в гугл вбити `data mesh site:jobs.dou.ua` одиничні вакансії проскакують, що значить, що десь зовсім поруч можуть бути компанії, які цим підходом користуються (чи принаймні питають на співбесіді). Може навіть хтось ДОУ прочитає, побачить статтю і поділиться своїм досвідом, щоб підтвердити чи спростувати корисність цього всього.

Поняття, як на мене, зовсім не нове. В банках, наприклад, під кожний напрямок бізнесу є команда, в яку входить аналітик, який виконує функції і дата інженера, безпосередньо аналітика і загортувача цукерок в презентації бізнесу. В нашій сфері це перекликається з hub-spoke підходом.

Від статті очікував менше води та плюсів-мінусів при впровадженні реальних кейсів. Можливо так і планувалось?!

Не сумніваюсь, що схожі підходи використовуються в різних галузях, однак все одно більшість компаній дуже погано справляється (з різних причини) з швидкою інтеграцією нових даних, перевіркою їх якості, трансформацією цих даних. Дата меш є частково референсом до того, як зробити так, щоб працювало краще — умовний дата чекліст.

А могли б трошки детальніше розписати, яку саме дата інженірінг роботу виконує аналітик в банку?

Звичайно — на свому прикладі можу сказати, що збирали інфу з різних джерел (блок фінансів, з центрального IT — куди ж без них, різних OLTP систем, якими користується відділ і звичайно різного роду ексельки від бізнесу). Далі ETL(ELT) в якусь одну систему, щоби на базі цього давати регулярні звіти для бізнесу.

Коментар порушує правила спільноти і видалений модераторами.

Підписатись на коментарі