Архитектура современных озёр данных: Data Lakehouse

На протяжении последних десятилетий архитектура корпоративного хранения данных прошла через три фундаментальных этапа:

1. Классические хранилища данных (Data Warehouses, 1990–2000-е): Реляционные системы высокой надежности с транзакциями ACID и строгой схемой. Прекрасно подходили для структурированной отчетности, но плохо масштабировались на петабайты сырых данных и не поддерживали неструктурированные форматы.
2. Озера данных (Data Lakes, 2010-е): Построенные на базе Hadoop HDFS, а затем облачных объектных хранилищ (Amazon S3, MinIO, Ceph). Позволили дешево сохранять любые объемы сырых файлов (CSV, JSON, Parquet). Однако «озера» быстро превратились в неуправляемые «болота данных» (Data Swamps): отсутствие транзакций приводило к чтению полузаписанных файлов при сбоях, отсутствовала версионность, а изменение одной строки требовало перезаписи терабайтных разделов ¹.
3. Data Lakehouse (современный этап): Новая открытая парадигма, предложенная создателями Apache Spark и Databricks ². Она объединяет низкую стоимость и масштабируемость объектных хранилищ с надежностью, схемами и транзакциями ACID классических СУБД.

В этой заключительной теме мы разберем устройство открытых форматов таблиц (Open Table Formats: Apache Iceberg, Delta Lake), концепцию разделения хранения и вычислений, управление метаданными и возможность путешествия во времени (Time Travel).

Архитектура Data Lakehouse

Главный принцип архитектуры Lakehouse — полное разделение подсистемы хранения и вычислительных движков (Separation of Storage and Compute):

Вместо привязки к единственной монолитной СУБД, данные сохраняются в открытом объектном хранилище в стандартном формате Apache Parquet. Поверх них накладывается транзакционный уровень управления метаданными (Apache Iceberg или Delta Lake), к которому могут одновременно обращаться десятки разнородных вычислительных ядер: DuckDB для быстрой локальной аналитики, Trino для распределенных интерактивных SQL-запросов и Spark для пакетного машинного обучения.

Устройство открытого формата таблиц на примере Apache Iceberg

Созданный в Netflix и переданный в Apache Software Foundation, формат Apache Iceberg решил главную проблему озер данных: как выполнять атомарные транзакции над неизменяемыми файлами в объектном хранилище ³.

Таблица Iceberg представляет собой не просто каталог с файлами, а трехуровневое дерево метаданных:

Компоненты дерева Iceberg

1. Каталог (Catalog): Центральный реестр (REST-каталог, Hive Metastore или PostgreSQL), хранящий атомарную ссылку на текущий актуальный файл метаданных таблицы.
2. Файл метаданных таблицы (Table Metadata): Содержит эволюцию схемы таблицы, историю партиционирования и список всех моментальных снимков (Snapshots).
3. Список манифестов (Manifest List): Фиксирует снимок состояния таблицы на определенный момент времени и перечисляет файлы манифестов с их диапазонами разделов.
4. Файлы манифестов (Manifest Files): Содержат списки реальных файлов данных Parquet, а также подробные зонные карты (минимумы, максимумы и число null) для каждого столбца каждого файла.
5. Файлы данных (Data Files): Непосредственно файлы Parquet или ORC, расположенные в бакетах S3/MinIO.

Ключевые возможности Lakehouse

1. Гарантии ACID и изоляция снимков (Snapshot Isolation)

Операции записи в Iceberg никогда не перезаписывают существующие файлы данных. Вместо этого они записывают новые файлы Parquet, создают новые файлы манифестов и формируют новый моментальный снимок (Snapshot). Фиксация транзакции заключается в атомарной замене указателя на снимок в каталоге с помощью механизма оптимистического контроля параллелизма (OCC: Compare-And-Swap) ⁴. Читатели видят согласованное состояние данных и никогда не блокируют писателей.

2. Путешествие во времени (Time Travel) и откат изменений

Поскольку исторические снимки и связанные с ними манифесты сохраняются, аналитик может запросить состояние хранилища на любую дату и время в прошлом или к конкретному идентификатору снимка:

-- Запрос к состоянию телеметрии на 10 утра вчерашнего дня в DuckDB:
SELECT district, avg(val)
FROM iceberg_scan('s3://lake/telemetry', as_of = '2024-03-01 10:00:00')
GROUP BY district;

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

3. Эволюция схемы и скрытое партиционирование (Hidden Partitioning)

В традиционных СУБД удаление или переименование столбца требует переписывания терабайтов данных. В Iceberg схема отвязана от файлов: столбцам присваиваются уникальные неизменяемые целочисленные ID, что позволяет добавлять, переименовывать и удалять столбцы за миллисекунды простой правкой метаданных.

Скрытое партиционирование (Hidden Partitioning): Пользователю больше не нужно вручную формировать искусственные столбцы вроде year и month для фильтрации подкаталогов. Iceberg сам вычисляет функции партиционирования (days(timestamp)) и автоматически отсекает ненужные файлы при обычном запросе с фильтром по дате.

4. Обслуживание данных: компактизация мелких файлов

Потоковая запись телеметрии в реальном времени приводит к появлению множества мелких файлов Parquet (small files problem). В Lakehouse фоновые служебные процессы периодически выполняют операцию компактизации (Compaction): переписывают десятки мелких файлов в крупные блоки по 512 МБ с обновлением манифестов в новой атомарной транзакции без остановки читающих аналитиков.

Итоги темы и курса

Парадигма Data Lakehouse стерла грань между транзакционными базами данных и масштабируемыми файловыми озерами. Объединив открытые колоночные форматы хранения (Parquet), векторные стандарты памяти (Arrow), высокоскоростные встраиваемые движки (DuckDB) и транзакционные форматы открытых таблиц (Apache Iceberg), современная инженерия данных сформировала гибкий, экономичный и невероятно мощный технологический стек для обработки любых объемов структурированных и телеметрических данных.

Литература

1. Armbrust M. et al. Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. — Proceedings of CIDR 2021 ¹.
2. Zaharia M. et al. Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores. — Proceedings of the VLDB Endowment, 2020, Vol. 13, No. 12, С. 3411–3424 ².
3. Apache Iceberg Project. Apache Iceberg Table Spec: Format Version 2. — Apache Software Foundation, 2024. https://iceberg.apache.org/spec/ ³.
4. Kleppmann M. Designing Data-Intensive Applications. — O'Reilly Media, 2017 ⁴.

Дополнительные материалы

Вопросы для самопроверки

1. Какие ключевые ограничения классических хранилищ (DWH) и озер данных (Data Lakes) привели к возникновению архитектуры Data Lakehouse?
2. В чём заключается принцип разделения хранения и вычислений (Separation of Storage and Compute)?
3. Назовите три ведущих открытых формата таблиц (Open Table Formats) в современной индустрии данных.
4. Опишите иерархию метаданных Apache Iceberg: какую роль играют файл метаданных таблицы, список манифестов и файлы манифестов?
5. Как в Iceberg реализуются транзакции ACID и изоляция снимков над объектным хранилищем без блокировки читателей?
6. Что такое путешествие во времени (Time Travel) и как оно используется для отладки конвейеров данных и аудита?
7. Чем механизм скрытого партиционирования (Hidden Partitioning) в Iceberg отличается от традиционного Hive-партиционирования по каталогам?
8. Как Iceberg решает проблему эволюции схемы при переименовании или удалении столбцов?
9. Что такое «проблема мелких файлов» (Small Files Problem) при потоковой записи в озеро данных и как работает процедура компактизации?
10. Каким образом встраиваемая СУБД DuckDB способна напрямую запрашивать таблицы Iceberg в бакетах S3?

Глоссарий темы

Шпаргалка по работе с Iceberg в DuckDB

-- Установка и подключение расширения Iceberg:
INSTALL iceberg;
LOAD iceberg;

-- Настройка доступа к объектному хранилищу MinIO / S3:
SET s3_endpoint = 'localhost:9000';
SET s3_access_key_id = 'minioadmin';
SET s3_secret_access_key = 'minioadmin';
SET s3_use_ssl = false;

-- Прямое чтение таблицы Iceberg из бакета:
SELECT district, count(*), avg(consumption)
FROM iceberg_scan('s3://lakehouse/smart_city/readings')
GROUP BY district;

-- Запрос к историческому состоянию (Time Travel):
SELECT count(*)
FROM iceberg_scan('s3://lakehouse/smart_city/readings', as_of = '2024-03-01 12:00:00');

Типичные ошибки и подводные камни

1. Забытая регулярная компактизация файлов метаданных и данных: Тысячи частых коммитов потоковых данных приводят к разрастанию дерева манифестов. Если не настроить периодический вызов процедур оптимизации метаданных и объединения мелких файлов, планирование каждого запроса начнет занимать десятки секунд.
2. Неконтролируемое накопление исторических снимков: Без регулярной очистки старых снимков (Expire Snapshots) и удаления отвязанных файлов данных объем объектного хранилища будет непрерывно расти, аннулируя финансовую экономию Lakehouse.
3. Конфликты конкурентных коммитов (Commit Conflicts): Если два независимых процесса одновременно пытаются модифицировать одни и те же разделы таблицы Iceberg, один из них завершится с ошибкой оптимистической блокировки и потребует программного повтора (Retry).

Литература

1. Armbrust M. et al. Lakehouse: A New Generation of Open Platforms. — CIDR, 2021 ¹.
2. Zaharia M. et al. Delta Lake: High-Performance ACID Table Storage. — VLDB, 2020 ².
3. Apache Iceberg Specification. — Apache Software Foundation, 2024 ³.