Як еволюціонували сховища даних: від дата-складів до lakehouse і TableFlow

Сучасні пайплайни обробки даних народили цілу екосистему термінів — 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:

1. Спочатку визначається структура таблиці (поля, типи, обмеження).
2. Потім у таблицю записуються тільки ті дані, які цій схемі відповідають.
3. Зміна схеми потребує міграції вже наявних даних.

Цей підхід добре працює, коли:

• дані чітко структуровані;
• бізнес-вимоги відносно стабільні;
• обсяги та типи даних передбачувані.

Але інтернет усе змінив.

Вибух даних і народження 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:

1. Дані записуються в об’єктне сховище як є (наприклад, JSON-файли).
2. Коли виникає потреба в аналізі, над ними визначається схема.
3. На основі цієї схеми будуються таблиці й виконуються запити.

Переваги такого підходу:

• можна зберігати будь-які формати (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.

Метадані зберігають:

1. Схеми даних
2. опис структури файлів;
3. історію змін схем;

4. можливість еволюції схеми без поломки запитів.

5. Статистику файлів

6. кількість рядків;
7. діапазони значень;

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

9. Транзакційні журнали

10. підтримка ACID-транзакцій;

11. можливість time travel — запитів до стану даних у минулому.

12. Управління дрібними файлами

13. відстеження великої кількості малих файлів;
14. автоматичне об’єднання (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).

Джерело

The Evolution of Data Storage (And What’s Next) | Modern Data Engineering Pipelines — Confluent Developer