Лейкхаус как у Google

В июле 2026 года Google показал Borderless Lakehouse — архитектуру целиком на Apache Iceberg, которая федерализует каталоги поверх AWS, Snowflake и Databricks, гоняет BigQuery и Spark по одним и тем же таблицам и прячет под всем этим автономную оптимизацию хранения. Через неделю Кaйл Уэллер — Head of Product агентного лейкхауса в Google — опубликовал фреймворк, который раскладывает производительность Iceberg на шесть слоёв: от базовой гигиены файлов до планирования запросов, осознающих формат.

Фреймворк стоит изучить. Не потому что продукты Google — единственный верный путь, а потому что мышление в терминах слоёв показывает, где на самом деле рождается производительность — и где большинство лейкхаус-архитектур останавливаются слишком рано.

Разберём каждый слой, посмотрим, как это строили в Google, и как выстроить то же самое в собственном открытом лейкхаусе — на любых движках и в любом облаке.

Ментальная модель: движки, таблицы и control plane

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

1. Движки запросов — как вы гоняете SQL. BigQuery, Spark, Trino, DuckDB, Athena, Snowflake, StarRocks. Каждый заточен под свой профиль нагрузки, модель цены и задержки.
2. Формат таблицы + каталог — как данные хранятся, версионируются и находятся. Apache Iceberg даёт открытый стандарт. Каталоги — AWS Glue, Polaris, Lakekeeper, Nessie, REST-каталог — закрывают слой метаданных.
3. Control plane — как таблицы остаются здоровыми и как запросы попадают на нужный движок. Компакция, последовательность обслуживания, наблюдаемость, управление, маршрутизация, доступ ИИ-агентов. Именно этот слой команды либо лепят руками, либо вообще пропускают.

flowchart LR
  A[Движки: BigQuery, Spark, Trino, DuckDB] --> C{Control plane}
  B[Формат + каталог: Iceberg, REST] --> C
  C --> D[Хранилище]
  C --> E[Компакция / обслуживание]
  C --> F[Маршрутизация запросов]
  C --> G[Наблюдаемость / управление]

Google вложился во все три направления. BigQuery и Lightning Engine для Spark закрывают слой движков. Каталог Lakehouse Runtime и федерация каталогов — слой метаданных. Автоматическая оптимизация хранения — компакция, сборка мусора, кластеризация — закрывает слой control plane.

Архитектуру Google особенной делает именно координация этих слоёв. Федерация каталогов подключает удалённые Iceberg-каталоги — AWS Glue, Databricks Unity Catalog, Snowflake Horizon — и BigQuery со Spark могут читать данные в разных облаках без копирования файлов. Credential vending заменяет долгоживущие ключи хранилища короткоживущими токенами с урезанными правами, выдаваемыми на путь таблицы, — минимально достаточные привилегии на уровне каталога.

Я перепробовал ряд отечественных облаков с Object Storage и ни у кого не нашёл поддержки credential vending, подходящей для работы с существующими iceberg каталогами.

Всеволод Миронович Директор по данным @ Далее

Интеллектуальное кросс-облачное кэширование хранит фрагменты удалённых данных локально после первого чтения, чтобы последующие запросы не платили за исходящий трафик. Каждая из этих функций — задача control plane: он сидит между движками и хранилищем и прозрачно управляет доступом, производительностью и ценой.

С учётом этого — вот шесть слоёв.

Слой 1: гигиена файлов и раскладки

Что покрывает: целевые размеры файлов, давление мелких файлов, базовая компакция и вменяемое партиционирование.

Здесь Google начинает — и это обязательный минимум. Каждая стриминговая задача, каждый append Flink или Spark, каждая микропакетная запись плодит файлы. Без активного управления таблицы копят тысячи недоразмеренных файлов. Каждый файл — это ещё одна запись в метаданных, ещё один S3 GET при планировании запроса и ещё одна единица работы для каждого движка, обращающегося к таблице.

Автоматическая оптимизация хранения в Google управляет компакцией и сборкой мусора для администрируемых Iceberg-таблиц. BigQuery сам склеивает мелкие файлы и возвращает хранилище из истёкших снимков — никаких ручных триггеров, никаких Spark-джобов по расписанию. Реализация конкретная: файлы отбираются под компакцию, когда их средний несжатый размер падает ниже 50% целевого размера в 256 МБ. Компакция срабатывает автоматически после любого изменения данных, а принудительное слияние прогоняется каждые 24 часа, если есть подходящие данные — так долг мелких файлов не накапливается даже в простое. Кластеризация переупорядочивает данные по указанным колонкам, чтобы запросы с фильтрами по ним целиком пропускали файлы.

Если вы не на управляемых таблицах BigQuery, гигиена файлов целиком на вас. Классический путь — Spark-компакция: планируй джобы, поднимай кластеры, крути JVM-настройки, чини падения. Работает, но это дорого, медленно и муторно поддерживать на сотнях таблиц.

Логику отбора файлов под компакцию легко представить как простой запрос по метаданным:

-- Псевдология отбора файлов под компакцию: цель 256 МБ, порог 50%SELECT f.file_path, f.record_count, f.file_size_in_bytesFROM iceberg.table_files AS fWHERE f.file_size_in_bytes < 0.5 * 256 * 1024 * 1024  -- меньше 50% целевого размераORDER BY f.partition, f.file_size_in_bytes;

Подход Google прост: файловая гигиена — не разовая чистка, а непрерывный процесс, который крутится в фоне и запускается по активности таблицы, а не по календарю. Таблице с 10 000 коммитов в день нужен другой ритм компакции, чем таблице с десятью.

Слой 2: эффективность метаданных

Что покрывает: стоимость обхода manifest list и манифестов, кэширование, прунинг и качество статистик.

Этот слой большинство команд упускает. Формулировка Уэллера точная: многие нагрузки деградируют задолго до того, как узким местом становится сам объём данных. Таблица на 50 ТБ хорошо организованных данных может отвечать быстрее, чем таблица на 5 ТБ с 2000 раздробленных манифестов, отсутствующими статистиками колонок и тысячами истёкших снимков, всё ещё висящих в дереве метаданных.

Стриминг обостряет проблему. Пайплайн Flink или Kafka Connect, пишущий микропакеты каждую минуту, даёт 1440 коммитов в день — каждый добавляет манифест, снимок и новые файлы метаданных. Посчитать накопление снимков можно прямо из метаданных таблицы:

-- Сколько снимков накопилось за месяц стримингаSELECT COUNT(*) AS snapshot_count,       MIN(committed_at) AS oldest,       MAX(committed_at) AS newestFROM iceberg.table_snapshotsWHERE committed_at > now() - interval '30 days';

Через месяц в таблице 43 000 снимков и такое глубокое дерево манифестов, что одно только планирование запроса занимает дольше, чем скан. Данные в порядке; узкое место — метаданные.

BigQuery решает это через Column Metadata Index (CMETA) — горизонтально масштабируемый индекс над метаданными блоков и колонок, позволяющий планировщику делать тонкий прунинг до сканирования любых данных. CMETA превращает метаданные, которые сами по себе — большие данные (терабайты статистик для таблиц петабайтного масштаба), в структуру, которую планировщик обходит эффективно. Он генерируется и обновляется автоматически и бесплатно.

Google вносит вклад и прямо в спецификацию Iceberg V4. Инженеры Google вместе с Snowflake, Databricks, Apple, Netflix и LinkedIn формируют адаптивные деревья метаданных — новую структуру, которая уплощает иерархию манифестов, поддерживает однобитные коммиты для стриминга и позволяет инлайн-изменения, которые фоновая поддержка позже перебалансирует в листовые манифесты. Предложение Content Stats, ратифицированное в V4 в мае 2026, заменяет старые карты статистик колонок типизированным, структурированным колоночным представлением, которое движки обрабатывают куда эффективнее.

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

Последовательность важна. Сначала истечение снимков → затем чистка осиротевших файлов → потом компакция файлов данных → далее переписывание манифестов → наконец вычисление статистик Puffin. Порядок осмысленный: раннее истечение снимков не даёт компакции трогать файлы, которые скоро отправятся в сборку мусора. Переписывание манифестов после компакции гарантирует, что дерево манифестов отражает свежую раскладку файлов. Вычисление статистик Puffin (NDV, min/max, количество null) после обоих шагов — чтобы каждый движок получил точные статистики колонок уже на этапе планирования.

Таблица с сотнями раздробленных манифестов заставляет делать сотни S3 GET просто ради планирования запроса. Консолидация сводит это к горстке запросов за один атомарный rewrite. Вместе с точными статистиками Puffin результат — более быстрое планирование на любом движке, работающем с таблицей: Spark, Trino, DuckDB, Athena, Snowflake — без подстройки под конкретный движок.

Слой 3: эффективность изменений данных

Что покрывает: update, delete и merge — position deletes, equality deletes, deletion vectors, остаточная фильтрация и взаимодействие мутаций с раскладкой файлов.

Здесь, как отмечает Уэллер, у Iceberg самые слабые места в дизайне. Любой DELETE или UPDATE на Iceberg-таблице не меняет файлы на месте. Вместо этого он пишет delete-файлы (position deletes или deletion vectors в V3), которые движки должны согласовывать при чтении. Таблица, накопившая тысячи delete-файлов, заставляет каждый запрос выполнять merge-операции на чтении — производительность деградирует пропорционально накоплению.

-- Каждое обновление строки пишет delete-файл, а не трогает данные на местеMERGE INTO orders AS o USING new_orders AS n ON o.id = n.idWHEN MATCHED THEN UPDATE SET o.status = n.status;-- Если строки разбросаны по сотням файлов — каждый требует position delete

Взаимодействие мутаций с раскладкой усугубляет проблему. MERGE INTO по таблице, отсортированной по customer_id, может задеть строки, разбросанные по сотням файлов — каждая требует записи position delete. Если движок не может избежать перезаписи этих файлов целиком, merge превращается в почти полную перезапись. Deletion vectors в Iceberg V3 снижают накладные расходы на строку (битмап вместо построчного delete-файла), но фундаментальный вызов остаётся: накапливающиеся мутации создают долг на чтение, который растёт с каждой неприменённой операцией.

BigQuery закрывает это внутренним слоем оптимизации хранения, который автоматически резолвит delete-файлы при фоновом обслуживании — тот же процесс компакции, что занимается размерами файлов, применяет и отложенные удаления, выдавая чистые выходные файлы без накладных расходов на согласование при чтении. Lightning Engine для Spark — построенный на open-source рантаймах Gluten и Velox — ускоряет согласование delete-файлов векторным C++-исполнением, обходя накладные расходы JVM, которые делают эти операции особенно дорогими в обычном Spark.

Для команд не на управляемых таблицах BigQuery долг delete-файлов — один из самых частых молчаливых убийц производительности. Таблицы выглядят здоровыми по количеству строк и размеру файлов — но скорость запросов стабильно падает по мере накопления delete-файлов. Большинство инструментов мониторинга не показывают ни долю delete-файлов, ни цену их согласования.

Практический вывод: эффективность мутаций — не только забота движка. Control plane, который следит за долей delete-файлов, запускает компакцию при пересечении порога и проверяет результат, превращает персональную ношу «таблица-за-инженером» в автономный фоновый процесс.

Слой 4: осознанность физической раскладки

Что покрывает: порядки сортировки, кластеризация, статистики колонок и пропуск row-group/страниц.

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

BigQuery решает это автоматической кластеризацией — переупорядочиванием данных по колонкам, чаще всего встречающимся в предикатах запросов. History-Based Optimizer (HBO) запоминает реальную статистику исполнения прошлых запусков и повторно применяет доказанные физические преобразования при повторении похожих форм запросов. Это замкнутый контур: оптимизатор учится на реальном поведении нагрузки, а не на статических эвристиках.

Физическая раскладка, подстроенная под реальные запросы, — та самая оптимизация с максимальным эффектом, которую большинство команд пропускает. Обычная компакция склеивает файлы по размеру и полностью игнорирует паттерны запросов. Результат: файлы правильного размера, но с данными в порядке, который не помогает ни одному запросу.

Разрыв закрывает sort-компакция. Она отслеживает колонки из WHERE, JOIN и GROUP BY по всем движкам для каждой таблицы, а затем сортирует данные при компакции, чтобы статистики min/max в Parquet давали агрессивный пропуск файлов и row-group. Порядок сортировки — на таблицу и самоулучшающийся: паттерны запросов меняются — колонки сортировки эволюционируют автоматически.

Симуляции раскладки позволяют проверить предлагаемый порядок сортировки против исторических паттернов запросов до коммита. Симуляция гоняется на ветке Iceberg, замеряет прогнозируемое влияние на просканированные данные и показывает результат — не трогая прод.

Связь с HBO Google прямая: обе системы учатся на реальном поведении запросов, а не на статической конфигурации. Разница в том, что HBO живёт внутри одного движка (BigQuery), а control plane работает сразу со всеми движками в стеке. Когда Trino, Spark, DuckDB и Athena читают одну таблицу, порядок сортировки должен отражать суммарную телеметрию запросов от всех них — а не от одного.

Совокупный эффект слоёв 1 и 4 стоит проговорить отдельно. Sort-компакция — не две разные операции, это подбор размера файла и оптимизация раскладки в одном проходе. Выходные файлы одновременно правильного размера (гигиена слоя 1) и отсортированы по релевантным колонкам (осознанность слоя 4). Предикатный pushdown работает на двух уровнях сразу: движок пропускает целые файлы, чьи диапазоны min/max не совпадают с фильтром, а затем пропускает row-group внутри оставшихся файлов. Ни одна оптимизация не работает хорошо сама по себе. Файлы правильного размера, но неотсортированные, всё равно требуют полного скана. Отсортированные, но раздробленные файлы всё равно требуют избыточного обхода метаданных. Движок компакции, обрабатывающий и то и другое за один проход, извлекает полную совокупную выгоду.

Слой 5: модель исполнения

Что покрывает: сдвиг от построчных итераторов к векторной колоночной обработке — SIMD, локальность кэша и нативные рантаймы, обходящие накладные расходы JVM.

Этот слой даёт больше всего заголовков. Lightning Engine для Managed Service for Apache Spark компилирует физические планы Spark в нативные C++-инструкции через Gluten и Velox, добиваясь ускорения до 4.9× без единой правки кода. Усиленная векторизация BigQuery сама выбирает SIMD-операторы, убирает избыточные вычисления и работает нативно над словарно и RLE-закодированными колонками. У Databricks — Photon. Onehouse построил Quanton на форке Velox.

Работа Google идёт глубже самой модели исполнения. Детальный разбор Lightning Engine у Уэллера вскрывает переработанные пути ввода-вывода: движок нативно потребляет формат Apache Arrow в C++ (в обход налога на конвертацию UnsafeRow), устанавливает прямые gRPC-стримы к Google Cloud Storage (минуя Cloud Frontend) и использует лексикографические листинговые API, чтобы забрать все метаданные файлов за несколько высокопроизводительных вызовов на уровне драйвера — вместо миллионов рекурсивных вызовов API, типичных для open-source Spark. Это не улучшения оптимизатора; это оптимизации на границе хранилища, убирающие накладные расходы ещё до начала обработки данных.

Индустрия сходится на нативном векторном исполнении. Но есть тонкость, которую подчёркивает Уэллер: векторизации самой по себе мало. Производительность движка важна, но движок работает только с тем, что даёт слой хранения. Идеально векторизованный скан таблицы с 50 000 несортированных раздробленных файлов всё равно медленный. Движок, оптимизированный под SIMD-обработку пакетами, всё равно проводит большую часть времени на вводе-выводе, если файлы не организованы под обслуживаемые им паттерны запросов.

Модель исполнения — где слой движков и слой control plane пересекаются яснее всего. Движки вы выбираете сами — и в большинстве продовых лейкхаусов их больше одного. Google гоняет BigQuery рядом со Spark. В большинстве компаний Trino — интерактивные запросы, Spark — батчевый ETL, DuckDB — ноутбуки и CI/CD, Snowflake или Athena — BI.

Вопрос в том, какой движок что обслуживает. Ответ по умолчанию — захардкодить строки подключения по командам или пайплайнам — ведёт к неоптимальной маршрутизации. Точечный lookup, который Trino делает за миллисекунды, уходит на Spark с 30 секундами старта кластера. Полносканный запрос, который Spark обрабатывает эффективно, улетает на DuckDB и умирает от нехватки памяти.

Единый SQL-эндпоинт с маршрутизацией запросов диспетчеризует каждый запрос на нужный движок по форме нагрузки, модели цены и здоровью движка. Группы маршрутизации — analytics, etl, reports, bi — каждая мапится на стабильный эндпоинт со стратегиями оптимизации под движок. Слой маршрутизации осознаёт здоровье таблиц: скомпактированная, хорошо отсортированная таблица открывает больше движков на форму запроса, а раздробленная может быть ограничена движками, способными выдержать накладные расходы.

Слой 6: операторы, знающие формат

Что покрывает: операторы и планировщики, которые понимают внутреннее устройство Iceberg — манифесты, delete-файлы, кластеризацию и статистики колонок — и работают с учётом формата, а не относятся к таблице как к непрозрачному набору Parquet-файлов.

Это самый глубокий слой и, по Уэллеру, то место, где некоторых в сообществе ослепляет. Быстрый движок, относящийся к Iceberg-таблицам как к мешку Parquet-файлов, упускает самые мощные фишки формата: прунинг на уровне манифестов, планирование сканов, осознающее partition spec, упорядочивание джойнов с учётом delete-файлов и предикатный pushdown на статистиках.

Продвинутый рантайм BigQuery расширяет путь усиленной векторизации на открытые форматы, включая специализированное поведение метаданных и сканов на Iceberg. Snowflake вложил серьёзные инженерные усилия, чтобы приблизить производительность Iceberg к нативным таблицам. Движок, знающий формат, понимает, что смена partition spec не обесценивает существующие данные, что position delete-файл соответствует конкретным позициям строк в конкретных файлах данных и что статистики колонок в манифестах могут вычеркнуть целые группы манифестов до начала сканирования.

Специализация планов, знающая формат, — прежде всего забота уровня движков: вы получаете её, выбирая движки, которые глубоко вложились в интеграцию с Iceberg. Но control plane играет критическую вспомогательную роль: он гарантирует, что слой хранения находится в состоянии, из которого движки, знающие формат, выжимают максимум.

Движок, умеющий прунить на уровне манифестов, огромно выигрывает от консолидированных манифестов с точными статистиками. Движок с планированием по partition spec выигрывает от партиций без перекоса и фрагментации. Движок, продавливающий предикаты по статистикам колонок, выигрывает от вычисленных и актуальных статистик Puffin.

Control plane закрывает разрыв между тем, что формат поддерживает, и тем, что движок может использовать. Без него даже самый изощрённый движок, знающий формат, работает с деградировавшими метаданными, раздутыми манифестами и устаревшими статистиками — вытаскивая лишь часть той производительности, на которую формат рассчитан.

Здесь же выбор движка важен сильнее всего. Не каждый движок вкладывается в операторы, знающие формат, одинаково. Оценивайте, могут ли ваши движки прунить на уровне манифестов (пропуская целые группы манифестов по partition spec), прозрачно обрабатывать эволюцию партиций (читая данные по старой и новой схемам партиционирования) и использовать статистики колонок из манифестов и файлов Puffin для предикатного pushdown. Чем глубже движок интегрирован со структурами метаданных Iceberg, тем больше производительности он вынимает из хорошо поддерживаемых таблиц — и тем больше ценности даёт control plane, держащий эти структуры в оптимальном состоянии.

За пределами шести слоёв: наблюдаемость и управление

Фреймворк Google фокусируется на оптимизации производительности. Но строить как Google означает и строить операционную инфраструктуру, которая держит производительность во времени. Таблицы деградируют. Партиции перекашиваются. Стриминговая запись создаёт давление мелких файлов быстрее, чем их разруливает компакция по расписанию. Новые инженеры заводят таблицы без порядков сортировки. Доли delete-файлов молча ползут вверх.

Открытому лейкхаусу нужна непрерывная наблюдаемость — не просто мониторинг, а действующая интеллектуальная система о здоровье таблиц по всем каталогам и движкам.

Единый дашборд классифицирует каждую таблицу как Critical, Warning или Healthy по нескольким сигналам здоровья: распределение количества и размера файлов, глубина манифестов, накопление снимков, доли delete-файлов, перекос партиций, выравнивание порядка сортировки и кросс-движковая телеметрия запросов.

Кросс-движковая телеметрия особенно ценна. Когда Trino, Spark, DuckDB и Athena читают одну таблицу, мониторинг ни одного движка не рассказывает всей истории. Таблица, выглядящая простаивающей в метриках Trino, может быть горячим путём для Spark ETL. Таблица, кажущаяся здоровой для Athena, может иметь доли delete-файлов, деградирующие чтения DuckDB. Control plane агрегирует паттерны запросов, задержки и стоимость по всем движкам — вскрывая совокупный паттерн доступа, который должен вести порядок сортировки, приоритет компакции и решения о маршрутизации.

Управление превращает наблюдаемость в политику. Правила обслуживания можно задавать на уровне организации, каталога, пространства имён или таблицы — с наследованием, историей версий и откатом. Политика, удерживающая снимки в течение 7 дней для всех продовых таблиц, задаётся один раз и применяется везде. Исключение на уровне пространства имён для таблиц комплаенса продлевает срок хранения до 90 дней. Control plane принуждает и то и другое непрерывно.

Агентный слой: ИИ-агенты как потребители лейкхауса

Видение Agentic Data Cloud от Google ставит ИИ-агентов полноценными потребителями аналитической инфраструктуры. Data Agent Kit включает агентные воркфлоу, которые автономно запрашивают, обрабатывают и отлаживают данные. BigQuery предоставляет встроенные MCP-инструменты, дающие агентам прямой доступ к таблицам, представлениям и ИИ-движкам.

Это не картина будущего — это работает уже сегодня, и оно добавляет лейкхаусу новый набор требований. ИИ-агенты генерируют непредсказуемые паттерны запросов. Они не диагностируют медленные запросы, вызванные деградацией таблицы. Они не ждут завершения Spark-компакции. Когда агент упирается в таблицу с тысячами мелких файлов, он расплачивается за каждую задержку и либо ретраит (сжигая токены), либо возвращает деградировавшие результаты.

Control plane, заточенный под агентные нагрузки, должен давать четыре возможности: агент-нативный интерфейс (MCP со schema-aware инструментами), защитные ограждения (read-only, оценка стоимости, маскирование PII, одобрение человеком — стековые на агента, команду или организацию), интеллектуальную маршрутизацию, адаптирующуюся к паттернам запросов агентов, и самооптимизирующийся слой хранения, где телеметрия запросов агентов подпитывает приоритеты компакции.

Замкнутый контур обратной связи — агенты запрашивают → телеметрия собирается → горячие таблицы получают приоритет в компакции → веса маршрутизации подстраиваются → следующий запрос агента быстрее — это тот же паттерн, что Google реализует внутри BigQuery, но доступный во всём вашем мультидвижковом стеке.

Конкретный пример. Аналитический агент начинает опрашивать таблицу order_events каждые несколько минут — параметризованные lookup по customer_id и event_date. Control plane детектит повторяющийся паттерн по десяткам агентных сессий, помечает таблицу как горячий путь, приоритезирует её под sort-компакцию по этим двум колонкам и корректирует вес маршрутизации, чтобы последующие запросы агента шли на DuckDB (субсекундные lookup) вместо Trino (старт на несколько секунд). Агент ничего этого не запрашивал. Он просто выдал SQL. Лейкхаус под ним улучшился — автономно, в ответ на наблюдаемый спрос.

Iceberg V4: спецификация догоняет архитектуру

Стоит отметить, что сама спецификация Iceberg эволюционирует под эту слоёвую архитектуру. Спецификация V4, активно формируемая инженерами Google, Snowflake, Databricks, Apple, Netflix и LinkedIn, вводит несколько изменений, напрямую ложащихся на слои выше:

• Относительные пути (ратифицировано май 2026) — таблицы можно переносить между регионами или бакетами, обновляя одну точку входа в каталоге, без перезаписи метаданных. Это эффективность слоя 2, применённая к операциям.
• Адаптивные деревья метаданных (в проектировании) — новая структура метаданных, поддерживающая однобитные коммиты для стриминговых нагрузок, снижающая амплификацию записи. Напрямую адресует слой 2 на уровне формата.
• Content Stats (ратифицировано май 2026) — типизированные, структурированные статистики колонок, заменяющие старые карты, позволяющие движкам эффективнее выполнять оптимизации слоёв 4 и 6.
• Column families (предложено) — независимое хранение и эволюция групп колонок, критично для широких ML-фичевых таблиц, где мелкие обновления не должны тянуть полную перезапись файлов (слой 3).

Control plane, держащий ваши таблицы здоровыми сегодня, автоматически выиграет от каждого из этих улучшений V4 по мере их внедрения движками. Метаданные, которые он поддерживает — консолидированные манифесты, точные статистики, разрешённые delete-файлы, оптимизированные порядки сортировки — это ровно то, что V4-aware движки используют для более глубоких оптимизаций.

Собираем свой открытый лейкхаус

Архитектура Google работает, потому что она интегрированная, автономная и многослойная. BigQuery закрывает слои 5 и 6. Автоматическая оптимизация хранения закрывает слои 1–4. Каталог Lakehouse Runtime закрывает метаданные. Borderless Lakehouse закрывает мультиоблачный доступ. Каждый компонент заточен под свою задачу, но все они работают как согласованная система.

Для команд, строящих на открытой инфраструктуре — с Trino, Spark, DuckDB, Flink, Athena или Snowflake как движками и Glue, Polaris, Nessie или REST-каталогами как хранилищами метаданных — эквивалентная архитектура требует control plane, дающего ту же координацию на гетерогенном стеке.

Вот из чего это складывается:

Подключи — подключи каталоги (Glue, REST, S3 Tables, Polaris, Nessie, Gravitino) и движки. Control plane обнаружит каждое пространство имён и таблицу, начнёт собирать телеметрию метаданных и даст мгновенную видимость здоровья таблиц по всему лейкхаусу.

Смотри — дашборд классифицирует каждую таблицу по сигналам здоровья. Видно, у каких таблиц давление мелких файлов, устаревшие снимки, отсутствующие статистики, высокие доли delete-файлов или перекос партиций — до того, как какой-то запрос замедлится.

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

Маршрутизируй — подключи движки и определи группы маршрутизации. Control plane диспетчеризует каждый запрос на оптимальный движок по цене, задержке и здоровью таблицы. По мере улучшения таблиц через компакцию больше движков становятся доступны для большего числа форм запросов.

Включи агентов — открой лейкхаус ИИ-агентам через MCP с многослойными ограждениями. Телеметрия запросов агентов подпитывает приоритеты компакции и веса маршрутизации. Лейкхаус умнеет по мере использования агентами.

Формат открыт — ценность в слоях

Кайл Уэллер сказал это чётко: Формат открыт. Настоящее различие — в том, сколько этих слоёв система готова оптимизировать — особенно глубокие, вокруг мутаций, модели исполнения и операторов, знающих формат.

Компании, вкладывающиеся сразу в несколько слоёв — Google с BigQuery и Lightning Engine, Snowflake с нативной производительностью Iceberg, Onehouse с движком Quanton — доказывают, что совместимости со спецификацией недостаточно. Реальная ценность — в слоях над и под форматом: в движках, способных эксплуатировать структуры метаданных Iceberg, и в control plane, держащем эти структуры в том состоянии, которое нужно движкам.

Для команд, строящих открытый лейкхаус, вывод ясен. Выбирай движки, вложившиеся в глубокую интеграцию с форматом (слои 5–6). Строй — или бери — control plane, который автономно закрывает слои 1–4. Добавь наблюдаемость и управление, чтобы производительность не деградировала со временем. Включи мультидвижковую маршрутизацию, чтобы каждый запрос попадал на нужный движок. И готовься к агентным нагрузкам, которые нагружают все слои одновременно.

Инструменты существуют. Паттерны проверены. Google построил это в масштабе Google. Netflix — в масштабе Netflix. Вы можете построить то же самое — не строя инфраструктуру — уже сегодня.

Данная статья является адаптацией блога LakeOps