Чому дані так важко перетворити на користь бізнесу

Попри вибухове зростання обсягів інформації, більшість компаній досі не вміють ефективно працювати з даними. Gartner оцінює втрати від низької якості даних у середньому в 12,9 млн доларів на рік для однієї організації, а інженери витрачають до 80% робочого часу на «прибирання» чужих помилок. Канал Confluent Developer розбирає, де саме в сучасних дата-пайплайнах ховаються ці втрати й які архітектурні компроміси визначають, чи стануть дані конкурентною перевагою, чи дорогим тягарем.

Життєвий цикл даних: чотири етапи та їхні пастки

Сучасна інженерія даних пропонує дивитися на дані як на безперервний життєвий цикл із чотирьох етапів:

1. Генерація
2. Інжестія (завантаження в пайплайн)
3. Трансформація
4. Сервінг (надання доступу споживачам)

На кожному з цих кроків доводиться робити вибір між зручністю, вартістю, швидкістю та якістю.

Генерація: чистити на джерелі чи «латати» потім

На етапі генерації дані з’являються в системі:
– кліки користувачів в e-commerce,
– показники IoT?сенсорів,
– логи застосунків, що фіксують поведінку користувачів.

Головна проблема тут — якість:
– користувачі вводять некоректні значення,
– сенсори дають збої,
– логи виявляються неповними.

Ключове рішення:
покращувати дані максимально близько до джерела чи миритися з «брудом» і чистити далі в пайплайні?

Аргументи на користь очищення на джерелі:

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

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

Інжестія: як реальний час перетворюється на батчі

На етапі інжестії дані потрапляють у пайплайн, зазвичай із мінімальними перетвореннями — щоб зберегти можливість повернутися до «сирого» джерела.

Саме тут часто відбувається критична зміна:
дані, які генеруються в реальному часі, завантажуються в пайплайн батчами — за часом або за розміром.

Компроміс виглядає так:

• Батч-обробка
• простіше реалізувати;
• дозволяє ефективніше використовувати ресурси;

• але:

  • втрачається реальний час,
  • інсайти з’являються із затримкою,
  • збої змушують перезапускати обробку цілих батчів.

• Стрімінг у реальному часі

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

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

Трансформація: моноліт проти модульності

Третій етап — трансформація — це місце, де живе основна бізнес-логіка:

• агрегації,
• зміна структури даних,
• очищення та нормалізація значень.

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

Тут постає ще один архітектурний вибір:
монолітні чи модульні трансформації?

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

• швидший старт для молодого бізнесу:

  • менше складності в деплої та моніторингу,
  • команда ще не до кінця розуміє домен і не готова до грамотної модульності.

• Модульний підхід

• краща повторна використованість;
• окремі частини легше зрозуміти й розвивати;
• але вимагає зрілого розуміння домену й більш складної інфраструктури.

У міру зростання бізнесу моноліт стає дедалі дорожчим:

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

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

Сервінг: реальний час проти зручності запитів

Фінальний етап — сервінг, коли дані стають доступними для людей і систем:

• сховища даних, дата-лейки, lakehouse?платформи
• зручні для аналітичних запитів;

• але зазвичай жертвують реальним часом;

• API

• дають контрольований програмний доступ;

• стрімінгові платформи на кшталт Apache Kafka

• зберігають реальний час;
• проте складніші для класичної аналітики й ad-hoc?запитів.

Компроміс тут формулюється просто:
залишити дані «в русі» для миттєвої реакції чи покласти їх у статичне сховище для зручного аналізу?

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

Критична асиметрія:
– реальний час завжди можна «приземлити» в статичне сховище для аналітики;
– але зі статичних батчів неможливо відновити справжній real-time.

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

Медальна архітектура: Bronze, Silver, Gold

Ще один спосіб мислити про пайплайн — так звана Medallion Architecture, що ділить його на три шари за аналогією з олімпійськими медалями:

1. Bronze — сирі дані
2. Silver — очищені та змодельовані
3. Gold — бізнес-орієнтовані агрегати

Bronze: страховка й джерело істини

Bronze?шар відповідає етапу інжестії:

• дані просто завантажуються в систему з мінімальними перетвореннями;
• структура й формат максимально зберігаються;
• бізнес-користувачі зазвичай із цим шаром не працюють.

Його цінність — у тому, що це «страхова копія» та джерело істини:

• можна перезапустити трансформації;
• додати нові кроки;
• виправити помилки в логіці, не втрачаючи оригіналу.

Silver: структурований фундамент

Silver?шар відповідає трансформації з чітким фокусом:

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

Компроміс:

• інвестиції в якісну структуру збільшують складність і час розробки;
• зате різко підвищують повторну використованість і спрощують аналітику.

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

Gold: інсайти замість деталізації

Gold?шар — це бізнес-готові дані:

• агреговані під конкретні сценарії;
• оптимізовані під запитання бізнесу й дашборди.

Головний компроміс:
втрачається деталізація в обмін на швидкість і зручність отримання інсайтів.

Для аналітики зазвичай використовують обидва шари:

• Silver — для дослідницької роботи й комбінування різних датасетів;
• Gold — для стандартних звітів і ключових показників.

ELT, ETL і роль медальної моделі

Medallion Architecture найкраще лягає на ELT?підхід:

• дані спочатку завантажуються в lakehouse (Bronze),
• а вже там трансформуються в Silver і Gold.

У класичних ETL?сценаріях (трансформація до завантаження) Bronze?шар може взагалі не існувати як окрема сутність — сирі дані не зберігаються в lakehouse.

Стрімінг проти батчів у контексті всієї архітектури

У батч?реалізаціях Bronze, Silver і Gold зазвичай — це статичні датасети в lakehouse:

• легко запускати SQL?запити;
• просто пояснювати структуру аналітикам;
• але немає справжнього real-time.

У стрімінгових реалізаціях кожен етап трансформації — це новий потік:

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

Чому все ж так важко зробити дані корисними

Складність не в тому, що бракує технологій — у відео згадуються Kafka, data warehouses, lakes, lakehouses, ETL/ELT?пайплайни, стрімінгові платформи. Проблема в ланцюжку компромісів на кожному етапі життєвого циклу:

• де чистити дані — на джерелі чи в пайплайні;
• коли обирати батч, а коли стрімінг;
• будувати моноліт чи модульну систему трансформацій;
• зберігати дані в русі чи «приземляти» їх у статичні сховища;
• як балансувати між Bronze?страховкою, Silver?структурою та Gold?інсайтами.

Ключова умова успіху — починати не з інструментів, а з бізнес-кейсу. Лише розуміючи, які рішення й дії мають підтримати дані, можна свідомо обирати архітектуру й технології, а не підганяти бізнес під уже обрані стек і патерни.

Джерело

Why Is It So Hard to Make Data Useful? | Modern Data Engineering Pipelines — Confluent Developer