Введение в LakeHouse

В современном бизнесе компании всё чаще сталкиваются с необходимостью объединять большие объемы данных из разных источников — от систем продаж и логистики до маркетинговых отчетов и пользовательской активности. Для того, чтобы эти данные приносили реальную пользу, важно не просто хранить их, но и быстро получать из них аналитические инсайты.

Традиционные хранилища данных (Data Warehouse) хорошо справляются с аналитикой, но ограничены в работе с неструктурированными данными и могут быть дороги при хранении и обработке огромных объемов сырых данных. С другой стороны, хранилища в формате Data Lake позволяют хранить любые данные в сыром виде, но сложны в поддержке и не обеспечивают транзакционной целостности. На стыке этих двух подходов появилась архитектура Lakehouse.

Если коротко, Data Lake — это гибкое файловое хранилище для сырых данных любого формата, а Data Warehouse — структурированное хранилище, ориентированное на аналитику. Lakehouse сочетает их преимущества: масштабируемость и гибкость озера данных с надёжностью, транзакционностью и удобством запросов, характерными для хранилищ данных. В этой статье мы рассмотрим, как работает LakeHouse, чтобы на практике понять, какие преимущества он может дать для бизнес-аналитики.

В основе Lakehouse лежит идея единого пространства, где рядом сосуществуют сырые данные и аналитически подготовленные таблицы. Хранилище представляет комбинацию файлового и объектного хранилища, и слоя метаданных и управления, который накладывает табличную структуру на эти файлы.

На первом шаге создадим логический контейнер для данных — бакет (lakehouse). Это основная папка хранилища, в которой располагаются все объекты: как исходные, так и обработанные.

В хранилище можно увидеть, что внутри бакета (lakehouse) находится папка cheques. Это таблица, созданная в формате Iceberg — не просто набор каталогов и файлов, а логическая таблица, построенная поверх файлового хранилища. Iceberg организует данные так, что рядом с основными файлами (data) появляются служебные данные (metadata), содержащие информацию о структуре таблицы, её версиях, снимках и партициях.

Именно через такую организацию, Lakehouse объединяет мир файлового хранения и табличной аналитики. Ключевым инструментом оптимизации здесь выступают метаданные, которые управляют партиционированием и индексами. Эти механизмы могут применяться как к заранее организованным наборам данных, так и к частям сырых данных на этапе их подготовки, что ускоряет выполнение запросов. Рассмотрим подробнее папку metadata. Именно здесь хранится служебная информация, которая делает Iceberg-таблицу умной — она знает, из каких файлов состоит, какие у неё партиции, версии и актуальное состояние данных. Можно увидеть несколько типов файлов:

manifest files (*-m0.avro) — содержат списки Parquet-файлов, принадлежащих определённому snapshot (то есть конкретной версии таблицы);
snapshot files (snap-*.avro) — описывают состояние таблицы в момент создания snapshot: какие файлы были добавлены, изменены или удалены;
metadata.json (v1.metadata.json) — основные файлы конфигурации таблицы, в которых хранится схема данных, информация о партициях, списки snapshot’ов и общие параметры таблицы;
version-hint.text — небольшой технический файл, указывающий на актуальную версию таблицы.

Принцип работы Iceberg построен на версионности: любое изменение — добавление, обновление или удаление данных — не перезаписывает существующие файлы, а создает новую версию таблицы. Одна из главных особенностей - то, что версионность и изменение данных работают на уровне партиций. Это означает, что при изменении данных создаются новые файлы только в затронутой партиции, остальные данные в таблице остаются неизменными. Таким образом, Iceberg сохраняет полную историю изменений и позволяет при необходимости откатиться к любому предыдущему состоянию. Однако для эффективной работы критически важно правильное партиционирование данных. Если объемные файлы не разделены на партиции или партиционирование выполнено неверно (например, не под задачи ETL-процессов), система столкнется с необходимостью создания копий огромных объемов данных при каждом мелком изменении. Это приведет к резкому падению производительности и нерациональному использованию ресурсов при работе с миллиардами записей.

Помимо папки metadata, в структуре присутствует каталог data, где хранятся основные файлы с данными в формате Parquet. Parquet — это столбцовый формат хранения, оптимизированный для аналитических задач. Он позволяет быстро считывать только нужные столбцы, а не весь файл целиком, что значительно ускоряет выполнение запросов. Благодаря этому Iceberg сочетает преимущества файлового подхода (гибкость и масштабируемость) с эффективностью, характерной для аналитических хранилищ.

Таким образом, таблица в формате Iceberg сочетает два ключевых слоя: данные, хранящиеся в Parquet-файлах, и метаданные, описывающие их структуру, версии и партиции. Благодаря этому аналитический инструмент может работать не с каждым файлом напрямую, а через интеллектуальный слой Iceberg, который точно знает, какие файлы нужно прочитать для выполнения конкретного запроса. На практике это особенно заметно при работе с большими объемами данных.

Для выполнения аналитических запросов в данном примере использовался Apache Spark — распределенный вычислительный движок, который позволяет обрабатывать большие объемы данных параллельно. Spark интегрируется с Iceberg и может работать с ним через SQL-запросы, как с обычными таблицами. Чтобы на практике увидеть, как именно Iceberg оптимизирует чтение данных, выполним два запроса с одинаковыми условиями, но разным синтаксисом. На первый взгляд они делают одно и то же — считают количество чеков по магазинам за июнь 2023 года, но результат выполнения различается по времени.

В этом случае фильтр выполняется после чтения всех данных, так как поля Year и Month были приведены к строковому типу, и Iceberg не может использовать партиции для оптимизации. Spark фактически читает все файлы таблицы, что занимает больше времени.

Здесь фильтр написан корректно — Spark передаёт его Iceberg и тот использует информацию о партициях, считывая только нужные файлы. В результате запрос выполняется значительно быстрее, потому что Spark обрабатывает лишь небольшой поднабор данных.

Такой пример наглядно показывает одно из ключевых преимуществ Lakehouse-подхода: в нём аналитические инструменты вроде Spark работают с данными не напрямую, а через умный слой Iceberg, который сам определяет, какие части таблицы нужно читать. Благодаря Iceberg и системе партиционирования запросы обрабатываются быстрее, снижается нагрузка на вычислительные ресурсы, а аналитика становится более гибкой и отзывчивой. Это особенно важно, когда речь идёт о миллиардах строк данных — именно здесь Lakehouse показывает свою настоящую силу.

Архитектура Lakehouse является современным и гибким способом организации данных. Она объединяет преимущества хранения больших объемов информации и возможности аналитической обработки, упрощая работу с данными и делая их доступными для принятия решений. Lakehouse демонстрирует, что даже сложные наборы данных можно обрабатывать быстро, надежно и масштабируемо.