Сучасні пайплайни обробки даних народили цілу екосистему термінів — data warehouse, data lake, lakehouse, streaming, TableFlow. У новому освітньому ролику Confluent Developer пояснює, як саме ці технології з’явилися, які проблеми вони вирішують і чому їхні назви насправді логічні, а не просто маркетинг.
![]()
Витоки: дата-склади та ера schema-on-write
Першим кроком стали data warehouses — по суті, спеціалізовані бази даних для аналітики.
Традиційні бази будувалися для OLTP (online transaction processing): швидкі, дрібні операції — платежі, замовлення, оновлення записів. Для цього обиралися одні архітектурні рішення, але вони погано підходили для аналітичних запитів по великих масивах даних.
Data warehouse орієнтований на OLAP (online analytical processing):
- працює з великими наборами даних;
- зберігає їх у вигляді таблиць з рядками та стовпцями;
- використовує чітко визначені схеми, спроєктовані наперед;
- забезпечує передбачувані SQL-запити й оптимізовану продуктивність.
Ключова ідея — schema-on-write:
- Спочатку визначається структура таблиці (поля, типи, обмеження).
- Потім у таблицю записуються тільки ті дані, які цій схемі відповідають.
- Зміна схеми потребує міграції вже наявних даних.
Цей підхід добре працює, коли:
- дані чітко структуровані;
- бізнес-вимоги відносно стабільні;
- обсяги та типи даних передбачувані.
Але інтернет усе змінив.
Вибух даних і народження data lakes: schema-on-read
Зі зростанням інтернету та цифрових сервісів почали масово накопичуватися:
- лог-файли з кожною дією користувачів;
- потоки подій від веб- та мобільних застосунків;
- дані IoT-сенсорів (часові ряди);
- контент із соцмереж — текст, зображення, відео;
- різноманітні документи та напівструктуровані формати (JSON, XML).
Ці дані:
- погано вкладаються в класичні таблиці;
- часто змінюють структуру;
- мають гігантські обсяги, які дорого зберігати в традиційних сховищах.
HDFS та об’єктне сховище
Відповіддю став Hadoop Distributed File System (HDFS) — спосіб зберігати файли без необхідності вписувати їх у реляційну структуру. SQL-можливості додавалися окремими інструментами (наприклад, Hive).
На цій основі виросло об’єктне сховище:
- Amazon S3, Google Cloud Storage та подібні сервіси;
- зберігання будь-яких типів файлів (CSV, JSON, відео, зображення, документи);
- дуже низька вартість за гігабайт (у рази дешевше за традиційне сховище);
- практично необмежена масштабованість;
- паралельний доступ багатьох команд без деградації продуктивності.
Але просто зберігати — недостатньо. Дані потрібно аналізувати. Так з’явилися data lakes.
Data lake: вода з усіх джерел в одному озері
Метафора озера тут показова:
- у справжнє озеро вода надходить із річок, струмків, дощу;
- озеро «не цікавить», звідки саме вода — усе змішується;
- щоб пити чи використовувати воду, її потрібно очистити й підготувати.
Так само data lake:
- приймає дані з різних джерел у «сирому» вигляді;
- не нав’язує структуру при записі;
- дозволяє накладати структуру вже на етапі читання.
Це і є перехід до schema-on-read:
- Дані записуються в об’єктне сховище як є (наприклад, JSON-файли).
- Коли виникає потреба в аналізі, над ними визначається схема.
- На основі цієї схеми будуються таблиці й виконуються запити.
Переваги такого підходу:
- можна зберігати будь-які формати (JSON, CSV, Parquet, відео, зображення);
- різні команди можуть по-різному інтерпретувати одні й ті самі файли;
- складне моделювання можна відкласти до моменту, коли вимоги стануть зрозумілішими;
- data scientists та аналітики отримують доступ до сирих даних без зміни джерел.
Важливий нюанс: «неструктуровані» дані не означають повну відсутність структури. Відео має кадри й пікселі, зображення — свій формат (JPEG, PNG тощо). Проблема в тому, що:
- структура не є уніфікованою для всіх файлів;
- її не завжди відомо наперед;
- її важко втиснути в класичну реляційну модель.
Для data lake це не проблема — структура не нав’язується при записі.
Коли озеро перетворюється на болото
Успіх data lakes породив нові труднощі:
- хаос у сховищі: будь-хто може покласти будь-що будь-куди;
- різні інтерпретації: команди застосовують різні схеми й отримують суперечливі результати;
- «шторм» дрібних файлів: потоки подій і реального часу створюють тисячі маленьких файлів, які важко ефективно обробляти;
- проблеми з продуктивністю: рушії запитів витрачають більше часу на відкриття файлів і з’ясування їхньої структури, ніж на сам аналіз;
- відсутність «рятівних» інструментів: без фіксованої структури важко застосовувати класичні оптимізації на кшталт індексів.
У результаті data lake часто перетворюється на data swamp — «болото», де знайти надійні, узгоджені дані стає майже неможливо.
Data lakehouse: метадані як міст між гнучкістю та порядком
Наступний крок — спроба поєднати:
- дешеве, гнучке об’єктне сховище data lake;
- продуктивність, керованість і транзакційність data warehouse.
Так з’явилася концепція data lakehouse.
Метадані як «розумний каталог»
Ключовий елемент lakehouse — метадані, які працюють як «розумний каталог» поверх об’єктного сховища. Це реалізується через open table formats, зокрема:
- Apache Iceberg;
- Delta Lake.
Метадані зберігають:
- Схеми даних
- опис структури файлів;
- історію змін схем;
-
можливість еволюції схеми без поломки запитів.
-
Статистику файлів
- кількість рядків;
- діапазони значень;
-
іншу інформацію, яка дозволяє пропускати файли, що точно не містять потрібних даних.
-
Транзакційні журнали
- підтримка ACID-транзакцій;
-
можливість time travel — запитів до стану даних у минулому.
-
Управління дрібними файлами
- відстеження великої кількості малих файлів;
- автоматичне об’єднання (compaction) у більші, ефективніші блоки.
Усе це перетворює об’єктне сховище на платформу, яка поєднує:
- продуктивність і надійність data warehouse;
- гнучкість і форматну різноманітність data lake.
Що робити з «незручними» неструктурованими даними
Відео, документи, файли зі змінними форматами — усе це залишається в об’єктному сховищі в оригінальному вигляді. Lakehouse:
- автоматично відстежує метадані файлів (розмір, формат, час створення, пов’язані схеми);
- дозволяє запускати спеціальну обробку для вилучення змістовних метаданих (тривалість відео, роздільна здатність зображення, властивості документа).
Ці метадані стають доступними через структуровані таблиці, що дає змогу:
- шукати й фільтрувати файли за їхніми властивостями;
- зберігати «сирі» файли без змін, але працювати з ними як з частиною аналітичної моделі.
Наступний крок: TableFlow і реальний час у єдиній аналітичній площині
Попри всі переваги lakehouse, залишалася одна суттєва прогалина: реальний час.
Потоки подій у Apache Kafka та подібних платформах:
- не зберігаються безпосередньо в об’єктному сховищі;
- не доступні для аналітичних запитів так само просто, як історичні дані в lakehouse.
Це створювало розрив між:
- streaming-даними (Kafka);
- аналітичними даними (lakehouse).
TableFlow: автоматичні таблиці з Kafka-топіків
Новий підхід — TableFlow — намагається закрити цю прогалину:
- автоматично перетворює Kafka-топіки на таблиці в lakehouse;
- записує події з Kafka у файли в об’єктному сховищі;
- витягує необхідні метадані для подальшого аналізу.
Результат:
- бізнес-аналітики можуть використовувати звичні інструменти запитів для реальних потоків даних;
- немає потреби будувати складні пайплайни для синхронізації streaming і batch;
- створюється єдина платформа для запитів до всіх даних — як пакетних, так і потокових.
По суті, реальний час стає доступним як таблиця в базі даних, але поверх lakehouse-архітектури.
Логіка еволюції: кожне покоління закриває слабкі місця попереднього
Якщо подивитися на розвиток технологій з висоти:
- Data warehouse зробили аналітику по операційних даних доступною та продуктивною.
- Data lakes додали гнучкість і підтримку різноманітних форматів, але втратили структуру й керованість.
- Lakehouse повернули продуктивність, транзакційність і керованість, зберігши гнучкість lakes.
- TableFlow знімає напругу між потоковими даними та аналітикою, інтегруючи реальний час у lakehouse.
У майбутньому подібний підхід — автоматичне створення lakehouse-таблиць для різних типів даних — може поширитися й на інші технології. Це рух у бік:
- уніфікації зберігання та доступу до даних;
- спрощення пайплайнів;
- зменшення розриву між операційними й аналітичними системами.
Назви теж виявляються не випадковими:
- warehouse — «склад», де в масовому порядку зберігаються операційні дані для аналітики;
- lake — «озеро», яке збирає «воду» (дані) з різних «річок» (джерел) у єдину масу;
- lakehouse — гібрид, що поєднує гнучкість озера з комфортом і структурою «будинку» (warehouse).







