Data Lakehouse 
на открытом коде:

Корпоративная аналитика долго жила вокруг понятной идеи: собрать данные в центральное хранилище, построить витрины, подключить BI и постепенно наращивать слой отчетности. Эта модель не исчезла. Более того, для многих компаний она до сих пор отлично работает. Но требования к данным стали шире, чем классический DWH-контур, каким бы зрелым он ни был.
Сегодня бизнес хочет не только регламентные отчеты. Ему нужны быстрые витрины, ad-hoc аналитика, воспроизводимая история, подготовка данных для ML/AI-сценариев, контроль качества, прослеживаемость данных, безопасный доступ, работа в своем контуре и понятная экономика владения. Когда всё это пытаются сложить в один большой аналитический кластер, платформа начинает напоминать не хранилище, а перегруженный вокзал: все поезда важные, все хотят отправиться вовремя, но пути одни и те же.
Data Lakehouse предлагает другую оптику. Данные хранятся в открытых форматах, вычислители выбираются под конкретную нагрузку, а быстрые витрины живут отдельно от исторического слоя. В cloud-мире эту идею упаковали в крупные платформы вроде Databricks. Но сам принцип не требует обязательно уходить в зарубежное облако. Большую часть Lakehouse-архитектуры можно развернуть на собственной инфраструктуре из компонентов с открытым кодом: Iceberg, Spark, Trino, ClickHouse, Airflow, объектное хранилище, каталог метаданных и слой безопасности.
Эта статья не про то, что Greenplum или MPP-DWH внезапно стали плохими. Скорее наоборот: чтобы выбрать архитектуру трезво, нужно понимать, где MPP остается сильным решением, а где современная lakehouse-архитектура дает больше свободы. Главный вопрос звучит не «какая технология моднее?», а «какая платформа позволит бизнесу расти без лишней зависимости от одного продукта, одного поставщика и одного способа масштабирования?»
Особенно острой тема стала для рынков России и СНГ, где к общим требованиям добавляется отдельный слой ограничений: санкционные риски, требования информационной безопасности, регуляторика, недоступность части зарубежных облачных сервисов и желание крупных организаций держать критичные данные в собственном контуре. По обзорам российского BI-рынка, импортозамещение перешло от пилотов к промышленной эксплуатации, а заказчики больше смотрят на архитектурную зрелость, безопасность, масштабирование, интеграцию и прозрачный TCO. На этом фоне идея Lakehouse становится особенно интересной: она родилась и активно развивалась в облачной среде, но ее базовые принципы не привязаны к облаку. Открытые форматы, разделение хранения и вычислений, разные движки поверх одного слоя данных и каталогизация метаданных применимы и в on-prem архитектуре.

В этой статье:

Ограничения классического MPP-DWH

Главное ограничение классического MPP-DWH не в том, что сама технология плохая. Проблемы появляются, когда один кластер становится универсальным местом для всего: сырой истории, регулярных загрузок, тяжелых пересчетов, ad-hoc запросов, BI и иногда даже экспериментальных ML-нагрузок. В такой архитектуре разные типы задач начинают конкурировать за общий ресурс.

Конкретные симптомы: ночная загрузка может влиять на утреннюю отчетность; большой исследовательский запрос аналитика мешает регулярным витринам; рост исторического слоя увеличивает требования к основному кластеру, хотя далеко не вся история нужна в горячем SQL-контуре.
Есть и экономическая сторона. В MPP-системах хранение и вычисления часто масштабируются как единый организм: если данных стало больше, приходится расширять кластер; если стало больше тяжелых расчетов — снова расширять кластер; если BI требует быстрых ответов, то нужна отдельная оптимизация или витрины. В итоге совокупная стоимость владения складывается не только из лицензий или подписок, но и из серверов, дисков, резервирования, эксплуатации, тюнинга, обновлений, миграций и компетенций команды.
MPP-DWH остается сильным инструментом, но его не стоит автоматически выбирать как единственный центр всей аналитической платформы. Во многих сценариях выгоднее разделить хранение, обработку и слой быстрых витрин.

Идея Data Lakehouse

Data Lakehouse можно описать как попытку объединить сильные стороны data lake и DWH. От data lake берется дешевое и масштабируемое хранение файлов в открытых форматах. От DWH берется управляемость табличных данных: схемы, транзакционность, историчность, контроль изменений, SQL-доступ и понятные витрины.
В основе современной lakehouse-архитектуры лежит открытый табличный формат. В этой статье в качестве базового примера используется Apache Iceberg. Официальный сайт Iceberg описывает его как открытый табличный формат для аналитических наборов данных и подчёркивает, что он позволяет Spark, Trino, Flink, Presto, Hive и другим движкам безопасно работать с одними и теми же таблицами.

Благодаря табличному слою появляются эволюция схемы (schema evolution), скрытое партиционирование, перемотка во времени (time travel), откат изменений и уплотнение данных. Для бизнеса это не просто технические возможности. Это способ хранить данные в открытом виде, не запирать их внутри одного движка и постепенно менять вычислительный слой без миграции всего хранилища.

Как собрать Lakehouse на открытом коде в собственном контуре

За рубежом Lakehouse часто ассоциируется с облачными платформами вроде Databricks и стеками крупных облачных провайдеров. Для российских компаний такая модель не всегда подходит. Причины разные: требования ИБ, персональные и коммерческие данные, регуляторные ограничения, санкционные риски, внутренняя политика по размещению критичных систем, стоимость облака и требования к контролю инфраструктуры.
Но сама архитектурная идея Lakehouse не требует обязательно покупать облачную платформу. Её можно собрать в своём контуре на open-source компонентах. Да, это потребует инженерной зрелости, инфраструктурной команды и дисциплины эксплуатации. Зато компания получает контроль над данными, открытые форматы, возможность выбирать компоненты и снижать зависимость от одного поставщика.
Базовый Lakehouse на открытом коде во внутреннем контуре можно собрать из нескольких слоёв. Важно, что это не список модных инструментов, а разделение ответственности между компонентами.

• Слой хранения: S3-совместимое объектное хранилище, например MinIO, Ceph или другой совместимый контур. MinIO описывает своё хранилище как программно-определяемое и S3-совместимое, предназначенное для задач AI и аналитики. Для Lakehouse это фундамент: данные лежат не внутри одного SQL-движка, а в объектном хранилище.
• Табличный слой: Apache Iceberg поверх Parquet (основной формат) или ORC. Он отвечает за метаданные таблиц, снимки состояния, эволюцию схемы, перемотку во времени, партиционирование и совместную работу разных движков.
• Вычислительный слой: Apache Spark для пакетной обработки, ELT и ML-пайплайнов. Spark официально описывается как многоязыковой движок для разработки данных, анализа данных и машинного обучения, работающий на одной машине или в кластерах; он поддерживает пакетную обработку, потоковую обработку, SQL и другие типы нагрузок.
• SQL/ad-hoc слой: Trino или Spark SQL. Trino прямо позиционирует себя как движок запросов для data lakes и lakehouse; его документация отдельно описывает компоненты lakehouse: объектное хранилище, табличные форматы, хранилища метаданных и каталоги, форматы файлов и инструменты вокруг них.
• Слой быстрых витрин: ClickHouse. Официальная документация ClickHouse описывает его как высокопроизводительную колоночную SQL СУБД для аналитической обработки данных. В такой архитектуре ClickHouse не обязан быть главным хранилищем всей истории: он может обслуживать быстрые витрины, дашборды и интерактивную аналитику.
• Оркестрация: Apache Airflow или Dagster. Оба инструмента используются для разработки, расписания и мониторинга пайплайнов данных. Airflow — более распространённый выбор с широкой экосистемой готовых интеграций; Dagster предлагает более современную модель с фокусом на типизацию ресурсов и тестируемость пайплайнов. В Lakehouse оркестратор координирует загрузки, пересчёты, проверки качества, обновление витрин и сервисные процедуры.
• Governance и безопасность: каталог метаданных, контроль качества данных, прослеживаемость данных, политики доступа, аудит. Здесь возможны OpenMetadata или DataHub — это разные инструменты с разной специализацией. OpenMetadata сильнее в каталогизации и контроле качества данных; DataHub (развивается в экосистеме LinkedIn) акцентирует прослеживаемость данных и поиск по активам. Apache Ranger выступает как платформа для управления и мониторинга безопасности данных. Дополнительно: интеграция с AD/LDAP/SSO, шифрование, сетевые политики и аудит.

Как собрать Lakehouse на открытом коде в собственном контуре

В классическом DWH компания часто масштабирует платформу целиком. В Lakehouse масштабируется тот слой, которому действительно не хватает ресурса. Если растет история, то расширяется storage. Если тяжелее стали ночные расчеты — добавляются Spark executors или отдельный compute-контур. Если пользователям не хватает скорости в BI, то масштабируются ClickHouse-витрины. Если аналитикам нужны ad-hoc запросы — можно отдельно масштабировать Trino.
Это не магия и не бесплатная производительность, но более точное распределение ресурсов. Экономический эффект проявляется не только в цене железа. Компания получает возможность держать холодные и теплые данные в объектном хранилище, не перегружать основной SQL-контур архивами, отделять исследовательские нагрузки от регулярной отчетности и избегать ситуации, где каждый новый сценарий требует расширять один и тот же центральный кластер.
Open-source не значит бесплатно. Инженеры, мониторинг, обновления, резервирование, безопасность — всё это реальные статьи затрат. Но TCO в Lakehouse прозрачно раскладывается по слоям: хранение, compute, serving. Каждый слой можно оптимизировать независимо от соседей, и это не обещание снижения бюджета, а возможность управлять стоимостью точнее.

TCO: честный разговор о деньгах

Как только разговор доходит до денег, начинается спекуляция. «Наш MPP обходится дешевле» или «Lakehouse снизит затраты» прежде всего это красивые тезисы, но без контекста они ничего не значат. Стоимость любой аналитической платформы определяется объёмом данных, характером нагрузок, зрелостью команды и тем, что уже есть в инфраструктуре.
В MPP-DWH в стоимость входят поддержка дистрибутива, железо для кластера, диски, резервирование, лицензии смежных компонентов и DBA-часы на тюнинг, обновления и сопровождение витрин. В Lakehouse картина другая: object storage обходится дёшево, но появляются compute-кластеры, SQL-движки, serving-слой, каталог метаданных, оркестрация и, главное, инженерная полоса на поддержку всего этого многокомпонентного стека.
Lakehouse не гарантирует автоматического снижения бюджета, но даёт больше рычагов управления стоимостью. Компания может отдельно оптимизировать хранение, обработку, интерактивную аналитику и governance, а не масштабировать один монолитный аналитический контур под все типы нагрузки.

Где MPP и Greenplum-подобные решения всё ещё уместны

MPP-DWH не исчезает. Он уместен, когда у компании уже есть зрелая SQL-команда, структурированные данные, понятная модель корпоративного DWH, регулярная отчетность, прогнозируемые запросы и опыт эксплуатации конкретной СУБД. MPP также может быть правильным выбором для сложных SQL-запросов по большим структурированным наборам, для организаций, где DWH уже внедрен и окупается, а риски миграции выше потенциальной выгоды.
Если бизнес-задача закрывается существующим кластером, то не нужно строить Lakehouse ради модного названия. Но если компания упирается в хранение истории, смешение нагрузок, высокую стоимость горячего слоя, необходимость ML/AI-сценариев, разные движки, on-prem ограничения и снижение зависимости от поставщика, то стоит рассмотреть Lakehouse или гибридную архитектуру.

MPP-DWH, Lakehouse или гибрид: когда что выбирать

Когда Lakehouse может быть лишним

Lakehouse не панацея и может быть лишним, если данных мало, источников немного, аналитика закрывается одной СУБД и простым BI, команда не готова поддерживать распределённую платформу, а бизнесу не нужны историчность, разные compute-движки и сложное управление данными.
Есть и операционные риски. Компоненты с открытым кодом нужно обновлять, мониторить, интегрировать между собой, настраивать безопасность, разбираться с совместимостью версий и выстраивать процессы управления данными. Если этого не сделать, вместо зависимости от поставщика получится архитектурная зависимость: платформа формально открытая, но фактически завязана на неявные знания нескольких инженеров.
Поэтому первым шагом является не закупка серверов и не выбор табличного формата,
а инвентаризация задач: какие данные есть, кто их потребляет, какие SLA нужны, что тормозит сейчас, какие регуляторные ограничения есть и какие сценарии появятся в ближайшие 1-2 года.

Зависимость от поставщика и архитектурная зависимость

Зависимость от поставщика  — это не только строчка в лицензионном договоре. Он живёт в форматах хранения, в проприетарных ETL-скриптах, в семантическом слое BI, особенно в компетенциях команды. Когда все знают только один инструмент, уйти от него невозможно даже если очень хочется.
Стек с открытым кодом и открытыми форматами снижает эту зависимость: Parquet и Iceberg позволяют поменять вычислительный движок без переноса данных, S3-совместимое хранилище переносится, Spark, Trino и ClickHouse развиваются независимо. Но зависимость не исчезает автоматически. Если вся бизнес-логика размазана по скриптам, нет владельцев данных, нет тестов качества и нет описания витрин — открытый стек не спасёт.
Поэтому платформа должна сопровождаться инженерной дисциплиной: контроль версий для пайплайнов, непрерывная интеграция и доставка, инфраструктура как код, документированные контракты, мониторинг и понятные правила владения данными. Без этого вместо зависимости от поставщика получается архитектурная зависимость: платформа формально открытая, а вся логика живёт в головах нескольких инженеров.

Безопасность и управление данными

Безопасность не дописывается в конце проекта: это условие применимости архитектуры. Разграничение доступа по зонам данных, интеграция с AD/LDAP/SSO, минимально необходимые права, аудит, шифрование и сетевая сегментация закладываются с самого начала.
Особенно важный момент: большинство бизнес-пользователей не должны видеть Bronze и Silver слои. Им место в Gold-витринах, где применены проверки качества и маскирование чувствительных полей.
Есть и операционная сторона, о которой обычно думают в последнюю очередь. Мониторинг пайплайнов, контроль заполнения хранилища, оповещения по качеству данных, резервное копирование и восстановление, тестовый контур для обновлений, матрица совместимости компонентов — всё это реальные задачи, а не теоретические риски. Отдельно стоит продумать жизненный цикл данных: какие таблицы хранятся бессрочно, где включается compaction, как чистятся старые снимки Iceberg, кто отвечает за оптимизацию витрин и что происходит при изменении схемы источника.
По сути Lakehouse — это не только стек технологий, но и операционная модель. И чем раньше это осознают, тем меньше шансов получить новый хаос на новой инфраструктуре.

Как внедрять: последовательность шагов

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

1. Инвентаризация: какие источники, кто потребители, где боль, что тормозит.
2. Выбрать один домен с понятной проблемой: долгие отчеты, дорогое хранение истории или ручные выгрузки. Не брать всё и сразу, но один реальный кейс.
3. Под этот домен поднять минимальный контур: storage, Iceberg, Spark, оркестрация и базовый каталог.
4. Когда первые витрины золотого слоя заработали в ClickHouse и BI подключён — добавить полноценную операционную модель: контроль качества данных, прослеживаемость данных, мониторинг и аудит.
5. Масштабировать архитектуру на новые домены. Такой путь снижает риск: компания не переписывает всю аналитику сразу, а проверяет подход на реальном сценарии.

Бизнес-ценность: что это даёт на практике

Для бизнеса Lakehouse ценен не тем, что в архитектурной схеме появляются новые названия. Его смысл в том, что компания перестает воспринимать аналитическую платформу как один большой продукт, который должен одинаково хорошо хранить историю, считать тяжелые пайплайны, отвечать на BI-запросы, обслуживать ad-hoc и готовить данные для ML.
Конкретика: когда данных становится больше, то расширяется только storage, не весь кластер. Когда появляются тяжелые расчеты — добавляем compute под Spark. Когда пользователям нужна быстрая аналитика, то масштабируем ClickHouse-витрины. Открытые форматы (Parquet и Iceberg) при этом снижают зависимость от конкретного движка: если через несколько лет понадобится поменять compute-слой, историю не придется перегонять заново.
И наконец: Lakehouse не требует сносить то, что уже работает. MPP-DWH может продолжать обслуживать зрелую SQL-отчетность и core-витрины. Lakehouse берет на себя исторический слой, новые домены, ML/AI-сценарии, исследовательские нагрузки. Компания не ломает работающую аналитику, а расширяет её возможности.

Типовой сценарий: крупная компания с несколькими источниками

Представим крупную компанию с несколькими источниками данных: ERP, CRM, биллинг, операционные системы и файловые выгрузки. Исторические данные растут, отчеты считаются часами, часть витрин дублируется, аналитики делают ручные выгрузки, а BI-нагрузка конкурирует с ночными пересчетами.

Заключение

Lakehouse на открытом коде не отменяет DWH и не делает MPP-СУБД устаревшими. Но он меняет архитектурную оптику. Вместо одного тяжёлого центра для всех задач компания получает открытую платформу, где данные лежат в переносимых форматах, вычислители выбираются под тип нагрузки, быстрые витрины обслуживаются отдельным слоем, а безопасность и управление данными встраиваются в архитектуру с самого начала.
Для российского и СНГ-рынка это особенно ценно: подход можно развернуть on-prem, адаптировать под внутренние требования, развивать постепенно и не привязывать критичный слой данных к одному зарубежному облаку или одному коммерческому продукту.
Выбор между MPP и Lakehouse зависит от конкретики: какие типы нагрузок, ограничения и горизонты роста у платформы. Если нужна зрелая SQL-отчётность по структурированным данным — MPP отлично справляется. Если нужна открытая, масштабируемая платформа для хранения истории, витрин, произвольных запросов, ML и разных вычислителей — Lakehouse на открытом коде становится интересным вариантом.