Почему компании переходят на Lakehouse: архитектура, стек и план миграции для российского рынка

3 сентября 2026 г.

Евгений Левашов

Автор статьи

Во многих компаниях аналитические данные распределены между несколькими системами. Тяжёлые расчёты выполняются в Greenplum, готовые агрегаты выгружаются в ClickHouse, отдельные версии таблиц появляются в финансовых отчётах и локальных выгрузках. Логи и полуструктурированные данные лежат в объектном хранилище отдельно: подключать их к привычному SQL-контуру сложно, поэтому они часто остаются вне аналитики. Новая витрина добавляет ещё один ETL-процесс и ещё одну копию данных.

Lakehouse предлагает собрать эти сценарии вокруг одного набора таблиц в объектном хранилище. Данные хранятся в открытом формате, например Parquet. Табличный слой, такой как Apache Iceberg, отвечает за схемы, снапшоты и атомарные изменения. Trino, Spark и Flink работают с одними и теми же таблицами каждый в своём режиме: интерактивный SQL, тяжёлые batch-трансформации или потоковая обработка. Хранение и вычисления масштабируются независимо, поэтому не приходится покупать диски вместе с процессорами только из-за нехватки одного ресурса.

Это не универсальная замена корпоративному хранилищу. Вместо одной СУБД появляется несколько компонентов: объектное хранилище, табличный формат, каталог, вычислительные движки и процедуры обслуживания таблиц. Если данных немного, запросы известны заранее, а ClickHouse справляется с дашбордами без очереди на новые витрины, новая архитектура только увеличит объём работы. Она становится оправданной, когда данные растут, копии начинают расходиться между системами, а подготовка новых сценариев занимает месяцы.

В статье сравним Data Warehouse, Data Lake и Lakehouse, разберём стек для российского контура, подход к расчёту TCO, публичные кейсы и план миграции. Отдельно рассмотрим ситуации, в которых от перехода лучше отказаться: не потому, что Lakehouse не работает, а потому, что он пока не решает достаточно дорогую проблему.

Статья подготовлена совместно с экспертом

Павел Савченко, архитектор предпродажных решений

Data Warehouse, Data Lake и Lakehouse

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

Корпоративное хранилище

Классическое хранилище решает задачу управляемой аналитики: строгая схема при записи, ACID-транзакции, предсказуемая производительность SQL по известным витринам и единая модель данных. На умеренных объёмах это по-прежнему рабочая конструкция.

Ограничения тоже хорошо известны. Данные лежат в проприетарном формате, и сторонний движок не прочитает их без выгрузки. Вычисления и хранение масштабируются вместе: в архитектуре shared-nothing узел неотделим от локальных дисков. Нехватку процессоров приходится закрывать покупкой лишних терабайтов, нехватку места — покупкой лишних ядер. Неструктурированные данные в эту модель вписываются плохо.

В России к этому классу относятся Greenplum и Vertica. Обе системы честно закрывают свои задачи, но на растущих объёмах упираются в ограничения архитектуры.

Озеро данных

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

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

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

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

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

Открытый колоночный формат файлов, обычно Parquet.
Табличный формат с транзакционностью, например Apache Iceberg, Delta Lake, Hudi или Paimon.
Отдельно масштабируемый вычислительный движок.
Технический каталог, который хранит метаданные и управляет доступом.

Главный эффект даёт не дешёвый байт в объектном хранилище, а отказ от лишних копий. Один набор Iceberg-таблиц могут читать Trino, Spark, Flink и ClickHouse без перекладывания данных между системами.

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

Критерий	Data Warehouse	Data Lake	Lakehouse
Формат хранения	Проприетарный	Открытый: Parquet, ORC	Открытый: обычно Parquet
Стоимость хранения	Высокая: диски продаются вместе с compute	Низкая: объектное хранилище	Низкая: объектное хранилище
ACID-транзакции	Да	Нет без табличного формата	Да, через Iceberg или Delta
Схема данных	Строгая, при записи	Часто определяется при чтении	Гибкая, с эволюцией схемы
Типы данных	В основном структурированные	Любые	Любые
Независимость compute и storage	Нет	Да	Да
Производительность SQL	Высокая на известных витринах	Низкая без табличного формата и специализированного движка	Высокая на Trino и Spark
Vendor lock-in	Высокий	Низкий	Низкий на уровне файлов, сохраняется на уровне каталога
Governance и RBAC	Обычно встроены	Сложно организовать	Реализуются через каталог
Типичные представители в России	Greenplum, Vertica, ClickHouse	HDFS и Spark	CedrusData (Trino), Iceberg, S3

Строку про стоимость хранения не стоит понимать слишком буквально. Гигабайт в объектном хранилище и гигабайт на дисках под управлением СУБД могут стоить сопоставимо. Разница в том, что в MPP-системе место покупается вместе с вычислителями, которые большую часть суток могут простаивать.

Почему Greenplum и ClickHouse достигают потолка

Связка Greenplum и ClickHouse упирается в три системные проблемы: дублирование данных, долгий цикл появления новых сценариев и пакетное масштабирование вычислений вместе с дисками. После покупки VMware компанией Broadcom добавился и вопрос дальнейшего развития ядра Greenplum.

Стандартная российская архитектура 2020-х

Переход на Lakehouse начинается не с выбора движка, а с понимания, где именно перестал справляться текущий стек. Типовая схема выглядит знакомо: источники, ETL-слой, Greenplum для тяжёлых расчётов витрин, ClickHouse для сервинга дашбордов и BI поверх них.

Связка возникла не случайно. Greenplum хорошо справляется со сложными SQL-расчётами и многотабличными соединениями. ClickHouse быстро отдаёт агрегаты по заранее подготовленным витринам. На объёмах в единицы и первые десятки терабайт конструкция работает и часто обходится дешевле альтернатив.

Проблема заложена в фундаменте shared-nothing MPP. Этот подход появился ещё в 1980-х: каждый узел приносит и процессоры, и диски. Само допущение с тех пор не изменилось.

Три системные проблемы связки

Дублирование данных. Одна и та же информация лежит в Greenplum, затем копируется в ClickHouse и расходится по выгрузкам. Каждая копия меняется в своём темпе. Расследование, почему два дашборда показывают разные цифры, становится регулярной задачей.

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

Масштабирование пакетом. В shared-nothing MPP каждый новый узел приносит и compute, и storage. На 10 ТБ это может быть незаметно. На 100 ТБ и выше переплата превращается в отдельную строку бюджета. Расширение кластера требует ребалансировки данных между узлами, а на больших объёмах она надолго занимает кластер.

Фактор Broadcom: ядро ушло в закрытый продукт

В мае 2024 года репозитории Greenplum на GitHub архивировали и перевели в режим только для чтения. После покупки VMware компанией Broadcom дальнейшие релизы ядра поставляются в составе коммерческого Tanzu Data Suite.

Из этого не следует, что российские вендоры не могут развивать Greenplum. Код, опубликованный до архивации, остался под лицензией Apache 2.0. Есть открытый форк — open-gpdb, и отдельно развивается Apache Cloudberry, форк Greenplum на более свежем ядре PostgreSQL, который остаётся в инкубаторе Apache Software Foundation.

Проблема не в запрете на доработку. Экосистема раскололась на форки, поэтому совместимость между ними приходится проверять самостоятельно. Ответственность за развитие ядра переехала к разработчикам конкретного форка. При выборе приходится оценивать не только СУБД, но и компанию, которой вы готовы доверить сопровождение ядра на горизонте пяти лет.

Для организаций, которые уже смотрели в сторону Lakehouse, это скорее ускоритель, чем самостоятельная причина миграции.

Технологический стек Lakehouse в России

Lakehouse собирается из четырёх слоёв. Ошибка в хранилище, табличном формате, движке или каталоге обычно обходится дороже, чем неверный выбор конкретной версии Trino.

Слой 1: распределённое хранилище

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

Базовый вариант — S3-совместимое объектное хранилище. В российском контуре это, например, Object Storage в VK Cloud и решения на инфраструктуре отечественных вендоров. Выбирать стоит по практическим критериям: надёжности, поведению при параллельном чтении несколькими движками, стоимости хранения и стоимости операций.

HDFS остаётся нормальным вариантом для компаний с живым Hadoop-кластером. Hadoop поддерживает протокол S3A, поэтому гибридную конфигурацию можно собрать без переписывания заданий. Для нового проекта HDFS уже не выглядит оправданным стартом.

Переезд с HDFS на объектное хранилище тоже не всегда выгоден. Если в кластере много файлов меньше 10 МБ, объектное хранилище может дать деградацию производительности и рост стоимости операций. Поэтому крупные компании нередко сохраняют HDFS как часть гибридной архитектуры.

Слой 2: табличный формат

Apache Iceberg стал стандартом по умолчанию для Lakehouse. Спецификация v3 добавляет timestamp с точностью до наносекунд, типы_ variant_, geometry и geography, значения по умолчанию для колонок, row lineage, бинарные deletion vectors и ключи шифрования таблиц. Формат поддерживают Trino, Spark, Flink и крупные коммерческие платформы.

Альтернативы выбирают по профилю нагрузки:

Delta Lake подходит, когда весь стек построен вокруг Spark и Databricks.
Hudi рассчитан на потоковый ingestion и частые обновления записей.
Paimon использует LSM-дерево и изначально ориентирован на streaming-first сценарии с интеграцией Flink CDC.

Сравнительные тесты форматов полезны только как ориентир. Их результаты обычно получены на синтетической телеметрии, которая редко повторяет реальную нагрузку компании. Выбранный формат определяет, какие движки получится подключить через два года, поэтому проверять его нужно на своих данных.

Слой 3: вычислительный движок

Trino закрывает интерактивную SQL-аналитику и федеративные запросы к нескольким источникам без предварительного ETL. На август 2026 года актуальна версия 483. Trino умеет работать с Iceberg v3: создавать, записывать и удалять v3-таблицы, использовать row lineage, выполнять optimize и expire_snapshots, а также экспериментально работать с типом variant.

У Trino есть известные эксплуатационные ограничения. Движок написан на Java, поэтому векторизация и SIMD не появляются автоматически. Активный координатор всегда один. Балансировщик перед ним может сократить простой, но не распределит нагрузку между несколькими координаторами. Fault-tolerant execution существует, однако по умолчанию выключен и использует объектное хранилище для промежуточных состояний, что замедляет запросы.

CedrusData Engine — коммерческая сборка на базе Trino. После перехода команды в VK Tech развитие продукта идёт в составе VK Data Platform. Вендор развивает cost-based оптимизатор и переносит часть вычислительного ядра на Rust поверх Apache DataFusion. При этом полноценный обход пространства планов и ряд правил, включая планирование порядка соединений, ещё заявлены как дальнейшая работа.

Spark и Flink не конкурируют с Trino напрямую:

Spark нужен для тяжёлых batch-трансформаций и ML-пайплайнов.
Flink отвечает за потоковую обработку и CDC.
Trino обслуживает интерактивный SQL.

В зрелом Lakehouse все три движка могут работать с одним набором таблиц.

Слой 4: технический каталог

Каталог хранит метаданные таблиц, управляет правами и участвует в обслуживании данных. Hive Metastore остаётся legacy-вариантом: он сложнее в сопровождении, не проектировался как cloud-native компонент и требует отдельной настройки высокой доступности. При этом миграция с legacy-каталога на REST не требует переписывать или переносить файлы данных.

Для нового проекта обычно выбирают Iceberg REST Catalog. Спецификация описывает и credential vending: клиент сообщает, что умеет работать с делегированным доступом, а каталог выдаёт короткоживущие учётные данные для префикса конкретной таблицы вместо постоянного ключа от всего бакета.

Из реализаций стоит смотреть на Apache Polaris, Unity Catalog и CedrusData Catalog. Polaris стал проектом верхнего уровня ASF в феврале 2026 года. Unity Catalog глубоко связан с экосистемой Databricks. CedrusData Catalog ориентирован на российский контур, включает RBAC и заявляет интеграцию с LDAP-группами. У Engine и Catalog разные записи в реестре отечественного ПО: № 15789 относится к Engine, № 27155 — к Catalog.

Каталог остаётся точкой, где реальный lock-in сохраняется даже при полностью открытых файлах данных.

Все четыре слоя Lakehouse — от одного вендора

VK Object Storage, CedrusData Engine и CedrusData Catalog — совместимый стек без интеграции компонентов вручную

MinIO, StarRocks и Impala

Для выбора важны несколько конкретных ограничений.

MinIO

Репозиторий minio/minio больше не поддерживается, а разработка ушла в коммерческий AIStor. Community-версия с июня 2025 года распространяется только в исходном коде.

При выборе MinIO слой хранения нужно закладывать вместе с планом возможного ухода. Лицензия AGPLv3 также ограничивает использование продукта в закрытых коммерческих решениях.

StarRocks

Ядро StarRocks открыто под Apache License. Движок известен сильным стоимостным оптимизатором, но его важное ограничение лежит в другой плоскости: со своим форматом он работает в 3–10 раз быстрее, чем с Parquet и ORC. Полная поддержка Iceberg v3 указана в roadmap на 2026 год.

StarRocks оправдан как слой сервинга, когда нужна высокая скорость на собственном формате. Делать его ядром Lakehouse на открытых форматах пока преждевременно.

Apache Impala

Impala не строит исчерпывающую стоимостную оптимизацию: команда Cloudera считает, что свежую статистику для такого подхода слишком дорого собирать и поддерживать. Взамен есть LLVM-компиляция с SIMD, execution groups и несколько активных координаторов — возможностей, которых нет у Trino.

Impala оправдана в действующем Hadoop-кластере. Для нового проекта на открытых форматах её преимущества не настолько велики, чтобы сделать её очевидным выбором.

TCO: как посчитать переход в рублях

Статья затрат	Greenplum и ClickHouse	Lakehouse на Iceberg, Trino и S3
Хранение	Локальные диски узлов, покупаются вместе с вычислителями	Объектное хранилище, оплата за фактический объём
Масштабирование вычислений	Узел добавляет и процессоры, и диски	Вычислители добавляются отдельно от хранения
Лицензии	Greenplum 7 — коммерческий продукт Broadcom. Бесплатны форки Greengage и Apache Cloudberry	Iceberg и Trino распространяются по Apache 2.0. CedrusData Engine — коммерческий
Сопровождение	Две системы и две зоны экспертизы	Один набор данных, но четыре слоя платформы
Разработка сценариев	Новый сценарий проходит через создание витрины	Возможен прямой SQL-доступ к таблицам
Риск смены вендора ядра	Высокий: решение принимается за пределами компании и страны	Низкий на уровне данных, сохраняется на уровне каталога

Главная ошибка в TCO — считать Greenplum бесплатным только потому, что он когда-то был open source. Бесплатны форки вроде Greengage и Apache Cloudberry, но не продукт Broadcom.

Методика расчёта

Для расчёта нужны четыре входные величины.

Хранение. Объём данных в терабайтах умножается на ставку за гигабайт-месяц.
Вычисления. Сравнивать нужно не число серверов, а профиль нагрузки. В классическом MPP вычислители оплачиваются круглосуточно, потому что неотделимы от хранения. В Lakehouse ночной batch на Spark и дневная интерактивная нагрузка на Trino могут использовать один пул ресурсов в разное время.
Период двойной эксплуатации. Во время миграции работают оба стека. Эту статью часто не учитывают, хотя именно она заметно влияет на итоговую экономику. Месячную стоимость текущего стека нужно умножить на срок параллельной работы по этапам миграции.

Разница между стоимостью текущего и целевого стека покажет экономический эффект. Универсального ROI нет: всё зависит от простаивающих вычислителей, числа копий данных и длительности двойной эксплуатации.

Бенчмарк Trino и Greenplum

Внутренний бенчмарк VK Tech на TPC-DS объёмом 1 ТБ и конфигурации 64 CPU, 512 ГБ RAM показал 46 минут 47 секунд для Managed Trino против 4 часов 56 минут для лицензионного Greenplum.

Эту цифру нельзя переносить в бизнес-кейс как готовое обещание. Она получена на конкретном стенде, конкретной конфигурации и синтетическом наборе TPC-DS. На собственных данных результат может оказаться другим.

Когда Lakehouse не подходит

Lakehouse решает определённый класс задач. За его пределами более простая система может быть дешевле, понятнее и надёжнее.

Порог объёма: чек-лист 5V

Один из независимых ориентиров для российского рынка предлагает не переходить на Lakehouse, если на горизонте трёх лет объём не превысит 10–30 ТБ. Данные в смысле «больших» начинаются примерно от 100 ТБ, а доля полу- и неструктурированных данных для задач Data Science должна превышать 10%.

Считать нужно прогноз, а не текущий объём. Платформу строят не под сегодняшний снимок.

Три сценария, где лучше остаться на текущем стеке

Данных мало, запросы простые. Если есть 5–10 ТБ структурированных таблиц, стандартные отчёты и команда из двух-трёх аналитиков, ClickHouse или PostgreSQL закроют задачу дешевле и с меньшим числом компонентов.

Почти вся нагрузка — дашборды с простыми агрегациями. На готовых витринах ClickHouse выигрывает по времени отклика. Lakehouse особенно полезен для сложных аналитических и федеративных запросов к сырым данным. Если таких задач нет в бэклоге, мигрировать незачем.

Нет команды и ресурса на её формирование. Компонентная архитектура требует экспертизы по движку, табличному формату, каталогу и объектному хранилищу. В такой ситуации разумнее начать с управляемого сервиса или коммерческой поддержки, чем собирать платформу из open-source компонентов без владельца.

Операционный overhead

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

Потоковая запись создаёт мелкие файлы и раздувает метаданные. Для частых обновлений нужно либо выбирать формат, спроектированный под streaming-сценарии, например Hudi или Paimon, либо заранее закладывать вычислительный бюджет на компакцию.

Исторический Hadoop-кластер может принести проблему мелких файлов в наследство. Если множество объектов меньше 10 МБ, сначала придётся укрупнить файлы, а уже затем считать выгоду от переноса в объектное хранилище. Иначе TCO будет построен на неверных предпосылках.

У Trino есть единственный активный координатор. Поэтому заранее нужен план его отказа и осознанное решение об использовании fault-tolerant execution. Устойчивость длинных запросов покупается снижением скорости коротких.

Миграция измеряется годами.

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

Российская специфика

Реестр отечественного ПО. Для госзаказчиков это минимальное требование. Для ГИС, ИСПДн, АСУ ТП и значимых объектов КИИ добавляются требования приказа ФСТЭК № 64 от 14 апреля 2023 года к системам управления базами данных.

Переход значимых объектов КИИ на российское ПО закреплён Федеральным законом № 58-ФЗ от 7 апреля 2025 года. Конкретные сроки определяет правительство. В графике, предложенном Минцифры в мае 2026 года, базовой датой названо 1 января 2028 года, а для отдельных случаев предусмотрены отсрочки до 2031 и 2036 годов.

HDFS-legacy. Стек Lakehouse должен работать одновременно с HDFS и S3, иначе миграция превратится в одномоментный переезд всего Hadoop-кластера. Для большинства крупных контуров это слишком рискованный и дорогой сценарий.

LDAP и Active Directory. Интеграция с корпоративным каталогом пользователей — обычное требование enterprise-контура. Формального исследования, которое доказывает LDAP как обязательный критерий выбора, нет. На практике отсутствие этой интеграции быстро становится проблемой для информационной безопасности, аудита и управления доступами.

План миграции

В российской практике уже встречается паттерн Strangler Fig: старая и новая платформы работают параллельно, витрины переносятся по доменам данных, результаты запросов сравниваются между стеками, а производительность и стоимость измеряются на каждом этапе. Это медленнее, чем переехать за выходные, но зато аналитика не превращается в памятник неудачному большому проекту.

Этап 1. Оценка и выбор стека: 1–2 месяца

Сначала инвентаризируют нагрузки: сценарии, объёмы, SLA, текущие копии данных и команды, которые отвечают за каждую систему. Затем считают TCO и проверяют порог 5V.

Точка принятия решения простая: если прогноз объёма на три года не превышает 10–30 ТБ, а в бэклоге нет сложных аналитических сценариев, проект стоит закрыть на этом этапе. Это не провал. Гораздо хуже построить четырёхслойную платформу для пяти таблиц и пары еженедельных отчётов.

Для пилота выбирают не самый критичный сценарий, но такой, где есть измеримый эффект и живой внутренний заказчик. «Давайте перенесём что-нибудь» — плохой кандидат: потом будет нечего сравнивать.

Этап 2. Пилот: 2–3 месяца

Разворачивают минимальный стек: объектное хранилище, Iceberg, вычислительный движок и каталог. Пилотный сценарий переносят целиком, включая обслуживание таблиц, а не только красивую демонстрацию SQL-запроса.

Измеряют три показателя:

Время отклика по сравнению с текущим стеком.
Фактическую месячную стоимость.
Срок разработки нового сценария.

Если пилот не улучшил ни одну из трёх метрик, нужно остановиться и разобрать причины. Пытаться «докрутить по ходу» платформу, которая не доказала пользу на ограниченном сценарии, обычно дорого и бесполезно.

Этап 3. Постепенная миграция: от 3 до 12 месяцев и дольше

Оба стека работают параллельно, а нагрузка переезжает по мере готовности команды. Лучше начинать не с переноса старых витрин, а с новых сценариев: свежая аналитика сразу разрабатывается на Lakehouse, а legacy переносится фоном.

Публичный опыт Avito показывает реальный горизонт: работа длится больше трёх лет, а часть платформенных решений команде пришлось строить самостоятельно. Миграция не становится простой от того, что в презентации её назвали roadmap.

Этап 4. Регулярная оптимизация

После переноса начинается обычная эксплуатация: lifecycle-политики в объектном хранилище, регламент обслуживания Iceberg-таблиц, компакция мелких файлов, анализ дорогих запросов и расширение на ML-нагрузки.

У этого этапа нет даты завершения. Он превращается в постоянную работу команды платформы.

Три повторяющиеся ошибки

«Большой взрыв». Переносить всё разом кажется быстрым только в плане проекта. Параллельная работа двух стеков дороже в моменте, но почти всегда дешевле отката после остановки аналитики.

Недооценка операционной части. Бюджет на обслуживание таблиц, мониторинг и устранение мелких файлов нужен с первого дня. Если вспомнить о нём через полгода, к этому моменту запросы уже начнут деградировать.

Выбор стека без оценки команды. Экспертиза по движку, табличному формату, каталогу и объектному хранилищу не появляется за квартал. Если её нет, разумнее начинать с управляемого сервиса или коммерческой поддержки, а не собирать платформу из компонентов, которые никто не готов сопровождать.

Заключение

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

Порог входа можно оценить заранее. При прогнозе ниже 10–30 ТБ на горизонте трёх лет Lakehouse обычно избыточен. Его сильные стороны проявляются на сложных запросах к сырым данным, а не на дашбордах по готовым витринам. Экономия появляется не от абстрактно дешёвого гигабайта: стоимость хранения может быть сопоставимой. Считать нужно независимое масштабирование compute и storage, а также объём данных, который перестанет жить в нескольких копиях.

Базовый стек известен: S3-совместимое объектное хранилище, например VK Object Storage, Apache Iceberg, CedrusData Engine и технический каталог с RBAC. Для тяжёлого ETL и ML добавляется Spark, для потоковых сценариев — Flink. Стратегия тоже известна: пилот на некритичной нагрузке, параллельная работа двух стеков и перенос по доменам данных. Реалистичный горизонт измеряется годами, а не кварталами.

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

Частые вопросы про Lakehouse

Что такое Lakehouse простыми словами

Lakehouse — платформа данных, где файлы лежат в открытом формате на объектном хранилище. Поверх файлов работает табличный формат, например Apache Iceberg или Delta Lake. Он добавляет ACID-транзакции, эволюцию схемы и историю версий. Вычислительный движок подключается к этим таблицам отдельно и масштабируется независимо от объёма хранения.

Чем Lakehouse отличается от Data Warehouse

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

Взамен появляется четыре слоя в эксплуатации вместо одной СУБД: объектное хранилище, табличный формат, каталог и вычислительный движок. Таблицы нужно обслуживать самостоятельно.

Стоит ли переходить на Lakehouse с Greenplum

Решение зависит от прогноза объёма и профиля нагрузки. Один из ориентиров: при объёме меньше 10–30 ТБ на горизонте трёх лет Lakehouse обычно избыточен.

Дополнительный аргумент для оценки рисков даёт статус самого Greenplum. Репозитории архивированы с мая 2024 года, дальнейшие релизы ядра поставляются в коммерческом продукте, а развитие открытой линии переехало в форки вроде Greengage и Apache Cloudberry.

Какой стек выбрать для Lakehouse в России

Базовая сборка состоит из S3-совместимого объектного хранилища, Apache Iceberg, Trino или CedrusData Engine для SQL-аналитики и технического каталога по спецификации Iceberg REST с RBAC.

Для тяжёлого ETL и ML добавляют Spark, для потоковых сценариев — Flink. Если в компании работает Hadoop-кластер, отдельно нужно проверить поддержку HDFS и сценарий поэтапного перехода на S3.

Сколько стоит переход на Lakehouse

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

Последнюю статью часто недооценивают. Для крупных хранилищ миграция занимает годы, а не несколько месяцев.