Следующая архитектурная модель: DLH
Следующей архитектурной моделью, как вы могли догадаться, стал Data Lakehouse. Базовое устройство DLH мы уже показывали, теперь посмотрим глубже — что именно изменилось для платформы.
Раньше данные были привязаны к конкретным MPP-кластерам. Платформе приходилось размещать объекты по консьюмерам, переносить их между контурами и следить за актуальностью копий. В DLH основным объектом управления стала логическая таблица в общем слое хранения.
Физически данные лежат в S3 в формате Parquet. Iceberg хранит схему таблицы, список актуальных файлов, снапшоты, историю изменений и правила партиционирования. Метастор связывает логическое имя таблицы с ее Iceberg-метаданными. Благодаря этому Spark и Trino обращаются к одному состоянию данных: один движок может записать результат ETL, другой — прочитать его для интерактивного анализа.
Теперь ключевые задачи сосредоточены вокруг того, как устроены сами таблицы. На производительность влияют размер и распределение файлов, выбранное партиционирование, сортировка, процессы compaction и полнота статистики. Если структура данных не соответствует характеру запросов, движок не сможет эффективно отсечь лишние файлы и будет читать значительно больше данных, чем требуется.
Так DLH изменил модель платформы: вместо управления копиями данных на кластерах — управление общим табличным слоем и вычислениями вокруг него.