Привет, Хабр!
Собрать Lakehouse на слайде несложно. Берём S3-совместимое хранилище, добавляем Iceberg, Spark, Trino, Kafka, Airflow и каталог данных. Получается современно, масштабируемо и архитектурно красиво. Гораздо сложнее сделать так, чтобы эта конструкция работала в определенных корпоративных сценариях. В статье попробуем отделить архитектурную концепцию от маркетинга и разобраться, как на самом деле идут проекты внедрения Data Lakehouse в России: какие решения доступны на рынке, какие проблемы платформа не решает, когда её внедрение имеет смысл и как выбрать подход к миграции.
Кто придумал «Data Lakehouse»
Кто первым произнёс словосочетание «Data Lakehouse» — установить вряд ли возможно. Самое раннее найденное мной опубликованное употребление термина относится к магистерской работе Педро Хавьера Гонсалеса Алонсо 2016 года. В 2017 году Джереми Энгл независимо использовал его в презентации о Snowflake. Однако именно компания Databricks в 2020–2021 годах популяризировала Lakehouse как самостоятельную архитектурную концепцию и придала термину современное рыночное значение, сначала в блог‑посте «What is a Data Lakehouse?», а затем в формальной научной статье на CIDR 2021. Именно с этого момента вокруг архитектурной категории «Data Lakehouse» начал выстраиваться целый рынок — вендоры, форматы, конференции, книги.
Надо отметить, что технические системы, напоминавшие будущий Lakehouse, появились раньше этой формализации. Одним из первых и наиболее хорошо задокументированных примеров стал Apache Hudi, созданный в Uber в 2016 году и публично представленный в 2017-м.
У Uber была платформа Data Lake на базе Hadoop — сырые данные из разных источников без трансформации при загрузке. Основной проблемой была актуализация изменяемых операционных данных, например, состояний поездок. До Hudi крупные Spark‑задачи периодически переписывали целые наборы данных в HDFS, чтобы применить вставки, обновления и удаления из источников. Пересчитывать целые партиции ради нескольких изменившихся строк было очень дорого и медленно. Именно поэтому Uber спроектировал формат Hudi так, чтобы он умел делать инкрементальные upsert/delete прямо поверх Parquet‑файлов на HDFS, снизив время upsert‑операции до порядка нескольких минут.
Был ли это Lakehouse? По сути да: ACID‑транзакции, upsert/delete, инкрементальная обработка поверх дешёвого распределённого хранилища — то самое сочетание надёжности DWH и гибкости Data Lake, которое позже Databricks формализовали в термине. Ретроспективно Hudi часто называют одной из первых — а в материалах Onehouse и AWS первой — Lakehouse‑технологией, хотя в Uber тогда использовали термин transactional data lake.
Показательно, что паттерн родился из практической инженерной боли Uber. Нужны были инкрементальные обновления на петабайтных объёмах в реальном времени, а не из маркетингового позиционирования. Databricks (через Delta Lake, 2019) и Uber (через Hudi, 2016–2017) фактически шли параллельными путями к одной и той же архитектуре, просто из разных бизнес‑задач: у Databricks — унификация DWH и ML, у Uber — обновление и добавление записей в реальном времени на огромных объёмах.
Зачем вообще понадобился Lakehouse
Если убрать весь маркетинг, задача была предельно простая. У компаний исторически было два отдельных мира данных, и оба были по‑своему плохи:
Data Warehouse хорошо подходил для структурированных данных, регулярной отчётности и контролируемого доступа. Однако по мере роста объёмов его становилось всё дороже масштабировать, а для хранения сырых данных, событий, файлов и задач машинного обучения он был не слишком удобен.
Data Lake позволял недорого хранить большие объёмы данных почти в любом формате. Однако нет транзакций, нет гарантий целостности, данные быстро превращаются в «болото», где никто не понимает, что где лежит и можно ли этому доверять.
Поэтому компании годами держали обе системы параллельно: сырые данные — в озере, обработанные аналитические срезы — в хранилище. Это означало двойную инфраструктуру, задержку между появлением данных и их доступностью для отчётов, риск рассинхронизации двух копий одних и тех же данных и зависимость от поставщика на дорогих проприетарных DWH.
Lakehouse — это попытка убрать этот дуализм, а именно взять дешёвое объектное хранилище как Data Lake и добавить поверх него открытый табличный формат, формирующий транзакционный слой над файлами и обеспечивающий атомарные изменения таблицы, снимки, time travel и эволюцию схемы. Полноценная Lakehouse‑платформа дополнительно требует каталога, вычислительных движков, управления доступом, оптимизации, оркестрации и эксплуатационных сервисов.
Что происходит в западных компаниях сейчас
Важно понимать, на каком этапе зрелости находится рынок. Технология перешла из стадии «а что это такое» в стадию тонкой инженерной настройки. Западная литература и профессиональное сообщество сейчас в основном спорят о технических нюансах зрелой экосистемы.
Если посмотреть на карту рынка, сейчас под вывеской Data Lakehouse продаются несколько продуктов. Условно рынок можно поделить на несколько моделей:
1. Полнофункциональные интегрированные Data & AI Lakehouse‑платформы (Databricks, Microsoft Fabric). Эти продукты предоставляют весь жизненный цикл данных в одной среде. Databricks — наиболее прямой пример Lakehouse‑native‑платформы. Microsoft Fabric — интегрированная SaaS‑платформа, в которой OneLake выступает общим хранилищем для Spark, SQL, Power BI, streaming и AI‑нагрузок.
2. Классические Data Warehouses, расширенные до Lakehouse (Snowflake, Oracle). Это платформы, которые выросли из мира баз данных и облачных аналитических хранилищ, а затем добавили работу с открытыми табличными форматами в объектном хранилище.
3. Облачные Lakehouse‑платформы и составные сервисы гиперскейлеров (AWS, Google Cloud). Оба провайдера позволяют собирать Lakehouse из отдельных облачных компонентов, но одновременно предлагают интегрированные управляемые решения: Amazon SageMaker Lakehouse и Google Cloud Lakehouse for Apache Iceberg. Поэтому их модели правильнее описывать как сочетание готовых Lakehouse‑платформ и отдельных сервисов‑конструкторов. Microsoft также является гиперскейлером, однако Fabric мы отнесли к первой категории, поскольку этот продукт изначально упакован и продаётся как единая SaaS‑среда.
4. Коммерческие платформы для выполнения запросов и управления каталогом данных поверх открытых табличных форматов — Dremio, с 2026 года входящая в состав SAP, и Starburst. Эти платформы предоставляют коммерческий слой для обработки запросов, управления доступом и метаданными, при этом данные могут оставаться в объектном хранилище заказчика и храниться в открытых форматах.
5. Платформы загрузки и эксплуатации Lakehouse‑таблиц (Onehouse). Продукт автоматически принимает данные из источников, строит инкрементальные дата‑конвейеры и сам оптимизирует таблицы в открытых форматах на S3. Его отличие еще заключается в универсальности формата через Apache XTable: данные одновременно доступны как Hudi, Iceberg и Delta, а сам продукт дополняет Snowflake/Databricks, а не конкурирует с ними.
Таким образом, главная проблема западных компаний уже не в том, что Lakehouse “не работает” или продукт еще незрелый. Проблема в том, что переход к нему редко упрощает архитектуру сразу. На этапе внедрения компания часто получает не единую платформу вместо старых систем, а ещё один слой рядом с DWH, Data Lake, streaming‑платформой и несколькими каталогами. Lakehouse обещает одну платформу вместо нескольких систем, но без жёсткой архитектурной и организационной дисциплины сам становится ещё одной системой в этом списке.
А что в России
На этом фоне российский рынок находится несколько в другой точке траектории. У каких‑то компаний дискуссия всё ещё крутится вокруг куда более базового вопроса, как и чем вообще заменить уходящие Oracle/MS SQL/Teradata (подставьте нужное). Кто‑то уже запустил первые MVP и новая платформа не оправдала ожиданий.
Российский рынок начал массово обсуждать Lakehouse практически синхронно с уходом западных вендоров в 2022 году. Можно сказать, что догоняющая волна легла поверх уже устоявшейся на западе технологии, а не выросла органически из собственной инженерной потребности, как это было у Uber.
Это принципиально другая отправная точка, и именно поэтому дальше стоит разобраться, что в реальности происходит с внедрениями Lakehouse в России, почему здесь так часто пилотные проекты вязнут и едва доходят до продакшена.
Само понятие Lakehouse российские вендоры используют довольно свободно. Под ним могут продаваться:
полноценная платформа с объектным хранилищем, транзакционным табличным форматом и несколькими вычислительными движками;
обновлённый Hadoop‑дистрибутив;
аналитическая MPP‑СУБД;
набор управляемых облачных сервисов;
обычная ETL/DWH‑платформа с Lakehouse в названии.
Если использовать техническое определение Lakehouse, то наиболее полно эта архитектура публично подтверждена у следующих платформ:
Data Ocean Nova. Российская модульная Lakehouse‑платформа от Data Sapience, построенная на наборе доработанных open‑source‑компонентов и дополненная инструментами пакетной и потоковой загрузки, администрирования и управления ресурсами. У продукта есть публичные внедрения в Burger King Russia, Альфа‑Банке, Магните, Апельсине и Ингосстрахе, однако большая часть сведений публикуется самим вендором.
CedrusData Platform. Модульная платформа для построения Lakehouse, включающая SQL‑движок на базе Trino, каталог метаданных с поддержкой Iceberg и возможность использовать разные вычислительные движки для работы с общими данными. В марте 2026 года состоялась сделка с VK Tech, после которой CedrusData присоединилась к направлению дата‑сервисов компании, а её движок и каталог должны усилить VK Data Platform.
MWS Data Lakehouse. Отдельный акцент сделан на миграции с Greenplum. Вендор заявляет совместимость модели данных, SQL и существующих ETL‑процессов.
Arenadata Hyperwave. Гибридная enterprise‑платформа, эволюционировавшая из Hadoop‑дистрибутива. Arenadata Hyperwave — новое название Arenadata Hadoop. Начиная с версии 4.0 компоненты могут разворачиваться без обязательного запуска полного Hadoop‑стека. Платформу можно сконфигурировать как Data Lake, Lakehouse или инфраструктуру для Data Mesh. Самые убедительные публичные примеры внедрения платформы и её предшественника есть у ВТБ, «Газпром нефть», Россельхозбанка.
ANG Platform. Продуктовая сборка Lakehouse на основе компонентов с открытым исходным кодом. ANG не создаёт собственный табличный формат или новый SQL‑движок. Её коммерческая ценность состоит в интеграции компонентов, готовом развёртывании в кубере, едином администрировании, мониторинге, сопровождении и SLA.
Digital Q.DataFactory. Продукт от «Диасофт» охватывает всю цепочку — от загрузки и контроля качества до BI, обучения моделей и создания AI‑приложений.
Cloud.ru Evolution Data Platform. Наиболее явно документированный российский managed‑конструктор Lakehouse, строится из управляемых компонентов, поэтому клиенту не нужно самостоятельно устанавливать Trino, Metastore, Spark и др. компоненты.
Selena. Позиционируется как российская Data Lakehouse‑платформа для высокопроизводительной аналитики и работы с данными в реальном времени. Мастер‑дистрибьютором выступает DIS Group, а сама Selena входит в экосистему AIDP вместе с решениями для Data Governance, MDM, ETL/ELT и контроля качества данных. В основе лежит MPP‑архитектура, колоночное хранение, векторизованное выполнение запросов, стоимостной оптимизатор запросов и материализованные представления. С 2026 года в качестве ядра заявлены коммерческие технологии StarRocks Enterprise. Публичный кейс — проект «цифрового двойника» в ГК «Нацпроектстрой» для управления автопарком и строительной техникой.
VK Cloud. VK предлагает VDP Lakehouse из Object Storage, Trino и Iceberg, а после сделки с CedrusData развивает более широкую VK Data Platform.
Yandex Cloud. Компонентная облачная data‑платформа, из которой можно собрать Lakehouse. Yandex Cloud пока правильнее называть конструктором Lakehouse, а не готовой единой Lakehouse‑платформой. Ответственность за совместимость Spark, Trino, версий Iceberg, Metastore, управление данными и обслуживание таблиц в значительной степени остаётся у заказчика.
Все вышеперечисленные продукты продают технологический фундамент, иногда с «каркасом», а не готовую работающую платформу данных. Развернуть Spark, Trino, Iceberg, Kafka, Airflow и каталог — это сравнительно понятная инженерная задача, гораздо сложнее построить вокруг них устойчивые процессы разработки, эксплуатации и управления данными. На данном этапе своего развития Lakehouse‑платформы пытаются решать преимущественно физическую и техническую унификацию, но не процессную, уж тем более не семантическую.
Для успешного ведения проектов внедрения подобных платформ не хватает не столько технологий, сколько проектного менеджмента и модели управления данными. А могут ли в принципе предлагаемые технологии потенциально помочь сгладить противоречия в проектных командах и увязать потребности разных участников работы с данными? Без заранее определённых полномочий, правил взаимодействия и измеримых уровней сервиса эти различия существенно замедляют внедрение.
В своём развитии Lakehouse‑платформы должны стремиться не просто объединять хранилище и вычислительные движки, а предоставлять целостную среду, в которой стандартизированы не только технологии, но и способы разработки, публикации, сопровождения и использования данных.
Какие проблемы не решает внедрение платформы Lakehouse
Представим типичную ситуацию. В компании существующее хранилище перестаёт справляться с нагрузкой, постоянная проблема со свободным местом и масштабируемостью, заканчивается поддержка зарубежного продукта и запускается срочная программа импортозамещения. Перед командой быстро возникает целый набор вопросов: развивать текущую архитектуру или строить новую платформу, собирать её самостоятельно или покупать готовое решение, какой технологический стек выбрать и какому поставщику доверить критически важный контур данных.
В такой момент Lakehouse легко начинает восприниматься как «серебряная пуля» — универсальный ответ сразу на множество накопившихся проблем. На новую платформу сразу возлагается «букет» ожиданий, что уж в этот раз точно сделаем «нормальную» платформу, ускорим разработку, снизим стоимость хранения, повысим качество данных и даже наведем порядок во взаимодействии команд! Однако смена архитектуры и набора технологий сама по себе не устраняет организационные, процессные и смысловые проблемы, которые годами формировались вокруг данных. Поэтому до выбора продукта и начала миграции важно отделить задачи, которые Lakehouse действительно способен решить, от тех, для которых потребуются самостоятельные изменения в процессах, ответственности и модели управления.
Итак, какие проблемы не могут быть решены за счет внедрения платформы Lakehouse.
1. Lakehouse сам по себе не отвечает на вопрос, зачем компании вообще нужна новая платформа. Отсутствуют реальные измеримые цели. Проект может начинаться под влиянием внешнего повода, например необходимо срочно заменить зарубежное решение и заканчивается поддержка действующего продукта; новый руководитель хочет пересобрать технологический ландшафт; текущая система стала слишком дорогой; в компании принято решение «развивать искусственный интеллект»; конкурент уже объявил о создании собственной платформы; появился бюджет на цифровую трансформацию.
Наличие повода ещё не означает наличия целей и задач. Если не определены конкретные результаты — например, сокращение срока подключения источника, повышение свежести данных, снижение стоимости определённых расчётов или ускорение вывода аналитического продукта, — платформа легко превращается в многолетнюю стройку.
Иногда проект начинается не с проблемы, а с доступного финансирования. Логика становится обратной: появилась возможность получить крупный бюджет и под него подбирается модная архитектура.
CIO, CDO, консультанты или вендор предлагают заметное и хорошо продаваемое решение: Lakehouse, Data Mesh, Managed Kubernetes, MDM, новая ERP, AI‑платформа. Архитектуру и подрядчика выбирают до подробного обследования процессов и данных. Затем под выбранную платформу начинают собирать бизнес‑сценарии. В бюджет включают лицензии, инфраструктуру, миграцию и большой объём работ подрядчика. Все согласовано, работы начинаются, уже видны первые результаты проекта. Приглашают нового лида, архитектора, руководителя data‑направления или delivery manager с задачей вести такой проект. От специалиста ожидают, что он разберётся в ошибках архитектуры и некачественной реализации, восстановит отсутствующие требования, договорится со всеми конфликтующими подразделениями; устранит проблемы производительности, компенсирует нехватку компетенций подрядчика, при этом не изменит бюджет, сроки и выбранный стек. Человека используют как ручной компенсатор дефектной системы управления и совершенных ошибок. Реализуется опасный сценарий: специалиста нанимают, когда решения уже приняты, деньги потрачены, а провал становится заметным.
2. Новая технология Lakehouse не компенсирует отсутствие базовой дисциплины и незрелость управления данными. Если до проекта в компании неизвестны владельцы данных, нет единых правил именования, изменения источников происходят без уведомления, показатели в отчётности рассчитываются по‑разному в зависимости от отдела, качество исправляется вручную, отчётность зависит от отдельных сотрудников, то после внедрения Lakehouse те же проблемы просто переместятся в новое хранилище.
3. Новая платформа как технологический проект — это плохой способ перераспределения полномочий и корпоративной реорганизации под видом внедрения. Внедрение новой платформы иногда используется как способ борьбы за контроль над отчётностью. Например, центральное ИТ‑подразделение может попытаться забрать у бизнеса создание управленческой отчётности, определение показателей, управление доступами, бюджет на аналитическую разработку. Формально это объясняется необходимостью «единого источника истины» и стандартизации. Фактически может возникнуть новый централизованный посредник, без которого бизнес не способен получить данные или изменить отчёт. Для руководства платформой выбирается человек из бизнеса, хорошо знающий внутреннюю карту влияния и очень заинтересованный в карьерном переходе в IT. Его ценность состоит не столько в технической компетентности, сколько в готовности вступить в противостояние с существующими владельцами отчётности, делегитимизировать локальные практики и административно консолидировать бюджеты, команды, доступы и право определения показателей вокруг новой платформенной функции.
Внедрением новой платформы также не решишь организационные вопросы. Lakehouse не согласует разные цели участников проекта. Аналитикам нужны понятные и стабильные данные, инженерам данных — формализованные требования и управляемые изменения, службе безопасности — минимальные права и полный контроль, руководителю проекта — соблюдение сроков и бюджета, бизнесу — результат как можно раньше, вендору — продажа лицензий, расширение использования продукта, достаточный объём проектных работ. Новая платформа не устраняет эти различия. Более того, добавление нескольких вычислительных движков, каталогов, средств оркестрации и новых ролей может увеличить число границ ответственности.
4. Lakehouse не решает проблему отсутствия единой семантики в данных. В Lakehouse нет автоматических механизмов для определения, что в компании означает выручка, активный клиент, новый клиент, доставленный заказ и так далее. Платформа может хранить исходные поля и выполнять формулы, но не способна выбрать правильную формулу за бизнес. Разные определения часто отражают не техническую ошибку, а разные управленческие задачи. Финансы могут считать выручку по моменту признания, продажи по дате заказа, а логистика по отгрузке. Перенос всех данных в единое хранилище не устраняет это различие.
Даже поставщики Lakehouse рекомендуют отдельно обеспечивать семантическую согласованность, поддерживать бизнес‑метаданные и формировать доверенные информационные продукты.
Отсутствие смыслового слоя становится особенно опасным при использовании ИИ: схема таблиц не содержит достаточного контекста о бизнес‑отношениях, допустимых трактовках и правилах применения показателей.
У российских вендоров есть средства якобы частичной автоматизации семантики. Самый очевидный подтверждённый пример — это Arenadata Catalog с автоматическим сбором метаданных, lineage, AI‑генерацией описаний и гипотезами классификации. Однако надёжный полный автоматический механизм вряд ли удастся найти — ни у российских, ни, строго говоря, у зарубежных вендоров. ИИ может сформировать гипотезу, но он не знает управленческих договорённостей и не способен установить, какое определение компания должна признать официальным.
5. Lakehouse не решает проблему низкого качества исходных данных. Lakehouse может хранить плохие данные надёжнее, быстрее и дешевле. Хорошими они от этого не становятся. Платформа не исправляет автоматически ошибочные значения, введённые в операционной системе, дублирование клиентов и товаров, неверные справочники, потерянные изменения, ручные корректировки задним числом и т.д
6. Lakehouse не компенсирует сложность интеграции с унаследованными системами. Одна из самых частых иллюзий состоит в том, что после выбора платформы данные можно относительно быстро «подключить». На практике приходится интегрироваться с:
многолетними ERP;
старыми банковскими системами;
закрытыми промышленными решениями;
самописными приложениями;
устаревшими версиями баз данных;
файлами и ручными выгрузками;
процессами, логика которых известна одному сотруднику.
Компании часто недооценивают интеграцию с наследуемыми системами, поскольку Lakehouse меняет целевую точку загрузки, но не упрощает автоматически происхождение данных.
Например, интеграция с еще живущим SAP ERP в некоторых компаниях, действующих на территории РФ, особенно сложна. Доступ к специализированным коннекторам и поддержке сейчас очень ограничивается, а внутренние структуры данных SAP и прикладные интерфейсы требуют глубокой экспертизы. На российском рынке есть шины данных, например, Arenadata Streaming, где возможна настройка передачи отдельных событий SAP через API. Однако событийный обмен по API не может обеспечить полноценного наполнения платформы данных: исторической загрузки, получения всех изменений и удалений, восстановления состояния бизнес‑объектов и сверки с SAP ERP.
Таким образом, Lakehouse не способен сам по себе решить плохую организацию работы с источниками. Остаются прежние проблемы:
источник не передаёт удаления;
нет журнала изменений;
схема меняется без предупреждения;
выгрузка создаёт нагрузку на рабочую систему;
интерфейс имеет жёсткие ограничения;
исторические данные отсутствуют;
часть логики скрыта в приложении;
данные доступны только через ручную выгрузку файлов.
Платформа может использовать CDC, Kafka, или пакетный загрузчик, но не заставит владельца системы обеспечить устойчивый контракт поставки данных.
7. Lakehouse не является автоматически лучшим решением для производительности любых сценариев нагрузки. В одном контуре могут конкурировать и тяжёлые пакетные расчёты, и аналитические запросы, отчётность, ML, потоковая обработка, обслуживание таблиц, массовые повторные или исторические загрузки.
S3-совместимые объектные хранилища имеют иную модель производительности, чем локальные и блочные хранилища. Например, к вызовам в работе с S3 можно отнести заметную задержку отдельного запроса, зависимость пропускной способности от параллелизма и возможное ограничение частоты запросов. “Тяжелые” SQL‑запросы, проблема мелких файлов и необходимость обслуживания iceberg‑таблиц никуда не уходят. Здесь важно понимать: если мигрировать SQL‑запросы, фреймворки, платформенные инструменты AS‑IS co старой платформы на новую, вау‑эффекта по улучшению производительности ждать не стоит.
Когда внедрение Data Lakehouse действительно имеет смысл
Lakehouse не внедряют тогда, когда в компании просто «много данных». Большой объём сам по себе ещё не требует новой архитектуры: десятки терабайт структурированной информации с предсказуемой отчётностью вполне могут успешно обрабатываться классическим DWH или специализированной аналитической СУБД.
Чтобы понять, нужен ли компании Lakehouse, следует поставить вопрос так: «Какую уже существующую и дорогостоящую проблему он устранит?» Например, перестанет ли компания хранить пять копий одних и тех же заказов в Data Lake, DWH, ML‑песочнице и аналитических витринах; сократится ли путь данных от ERP до отчёта с суток до нескольких минут; исчезнут ли десятки ETL‑процессов, единственная задача которых — перекладывать данные между платформами; смогут ли BI и Data Science использовать один доверенный набор данных без дополнительных выгрузок? Если на эти вопросы нет конкретных ответов и измеримого эффекта, Lakehouse, скорее всего, станет ещё одной платформой рядом с уже существующими. Когда ответы подтверждаются конкретными цифрами по объему хранимых и обрабатываемых данных, профилями нагрузок, затратами и бизнес‑сценариями, Lakehouse действительно имеет смысл. Когда аргументация ограничивается словами «современная архитектура», «единый источник истины», «проект», скорее всего, начинается с технологии, а не с реальной потребности.
Итак, Lakehouse наиболее оправдан, когда у компании одновременно присутствуют несколько из следующих признаков:
Значительный и постоянно растущий объём данных — от десятков или сотен терабайт и выше.
Когда кроме реляционных таблиц у компании появилась потребность обрабатывать полуструктурированные и неструктурированные данные: события, JSON, журналы приложений, телеметрию, файлы, тексты, изображения, результаты работы моделей и другие данные, которые неудобно сразу приводить к строгой модели классического хранилища.
Существуют несколько физических копий одних таблиц. Одна таблица может одновременно храниться в озере данных, корпоративном хранилище, аналитических витринах и среде машинного обучения. Значительная часть процессов при этом занимается не расчётами, а переносом и синхронизацией одинаковых данных.
Необходимо обрабатывать изменения, обновления, удаления (CDC) и запоздавшие данные. И все это нужно в реальном времени. Заказы отменяются, документы исправляются задним числом, возвраты поступают через несколько недель, а отдельные записи требуется удалить. Для таких сценариев нужны захват изменений, точечное обновление таблиц и корректировка прошлых периодов без полного пересчёта всей истории.
Озеро данных уже превратилось в критически важную промышленную систему. От него зависят отчёты, модели и бизнес‑процессы, но оно всё ещё может управляться как набор файлов и каталогов.
Hadoop или устаревшее корпоративное хранилище требуют большого объёма ручного сопровождения. Инженеры регулярно перезапускают загрузки, восстанавливают разделы, контролируют свободное место и разбирают последствия сбоев. Когда поддержание системы начинает отнимать больше ресурсов, чем развитие аналитики, переход на Lakehouse становится экономически обоснованным.
Вычислительная нагрузка сильно меняется во времени. В обычные дни ресурсов требуется немного, но при закрытии периода, массовом перерасчёте или обучении моделей нагрузка возрастает многократно. Раздельное масштабирование хранения и вычислений позволяет не содержать пиковые мощности постоянно.
Необходим федеративный доступ к данным из нескольких источников или движков.
И наконец, организация созрела к управлению данными как общим активом. Без этой готовности Lakehouse станет не упрощением архитектуры, а ещё одним плохо управляемым слоем.
Если решили внедрять Lakehouse, какой подход к миграции выбрать?
Единой стандартной классификации миграций DWH → Lakehouse нет. Но в рекомендациях западных гиперскейлеров AWS, Google Cloud, Microsoft и Databricks повторяются несколько основных подходов. Пока обсудим общий концептуальный подход без технических деталей.
1. Поэтапная миграция.
Хранилище переносится отдельными волнами. Обычно единицей миграции становится определенная предметная область или бизнес‑сценарий, группа связанных витрин, законченный вертикальный срез. Например:
Волна 1. Группа отчетов по продажам: источник → Raw → ODS/DDS → витрины → отчёты
Волна 2. Клиенты: источник → Raw → ODS/DDS → витрины → отчёты
После каждой волны часть старого DWH отключают.
Плюсы такого подхода.
· Снижение риска миграции и постепенное получение бизнес‑результата. Отчёты и команды переводятся на новую платформу постепенно, поэтому организационная нагрузка ниже, чем при одномоментном переключении. Большое DWH обычно невозможно безопасно перенести одним проектом. Деление на вертикальные срезы делает миграцию управляемой.
· Упрощённое тестирование и возможность безопасного отката. Проверять одну группу связанных таблиц и отчётов проще, чем одновременно сравнивать всё старое и новое хранилище. Если новая реализация работает неправильно, пользователей можно временно вернуть на старый контур без отката всей миграции.
· Возможность корректировать и приоритизировать план исходя из бизнес‑ценности. После каждой волны можно пересмотреть приоритеты, архитектуру, ресурсы и сроки на основе фактических результатов. Сначала можно переносить наиболее важные, дорогие или проблемные сценарии, а менее значимые объекты оставить на поздние этапы.
К минусам можно отнести долгое сосуществование двух платформ, временные интеграции и двойные эксплуатационные расходы.
Для крупного корпоративного хранилища это обычно наиболее практичный базовый подход, который требует умеренного количества времени и усилий. Миграция выполняется поэтапно и итеративно, последовательно выбираются прикладные сценарии.
Архитектурно этот подход близок к шаблону Strangler Fig: новая платформа постепенно заменяет части старой системы. Таким образом, нивелируется риск, связанный с одномоментным переписыванием критически важной системы.
2. Разгрузка старого хранилища: сначала витрины и потребители.
Это разновидность поэтапной миграции, при которой сначала реплицируются сырые и операционные данные из старого хранилища на новую платформу, и на них строится отчётность:
Первичные источники → старое DWH → репликация отдельных слоев → Lakehouse → отчётность
Сначала Lakehouse используется как новая аналитическая и отчётная платформа, но старое DWH ещё продолжает выполнять загрузки и преобразования. На следующих этапах выполняется полная миграция:
Первичные источники → Lakehouse → отчётность
Плюсы данного подхода:
· Быстрый бизнес‑результат.
· Ниже риск переключения.
· Проще сверять результаты. Готовую таблицу старого DWH можно напрямую сравнивать с её копией в Lakehouse по строкам, суммам и бизнес‑показателям.
· Не нужно ждать готовности всех источников. Миграцию отчётности можно начать до завершения интеграций с SAP, ERP, CRM и другими системами.
· Подходит для критичной отчётности. Не требуется одномоментно переключать весь аналитический контур.
Минусы:
· Сохраняется зависимость от старого DWH. Пока данные поступают через него, legacy‑систему нельзя отключить.
· Новая платформа проверяется не полностью. Не тестируются прямое извлечение из источников, CDC, обработка удалений, запоздавших данных, восстановление и пересчёт истории. Невозможно оценить производительность, стоимость и эксплуатационные особенности при загрузке источников, особенно если планируется внедрение новых интеграционных сценариев.
· Двойные расходы. Команда разработчиков тратит ресурсы на создание «костылей» для платформенных инструментов, чтобы обеспечить отсутствие расхождений в данных. Могут появляться временные обратные потоки вида: старое DWH → Lakehouse → старое DWH. Впоследствии встает необходимость второй миграции и замены всех «костылей» на реальные потоки из источников. Аналитики же фокусируются больше на сверках и соответствии данных на старом хранилище, нежели на архитектуре данных.
· Переносится технический долг. В новую систему попадают старые модели, дублирование, спорные показатели и устаревшие правила.
· Опасность ложного завершения. После переноса отчётности второй этап может потерять приоритет, и временная схема станет постоянной.
Такой подход к миграции подходит прежде всего тем организациям, где настроены относительно стабильные процессы интеграций с источниками, само хранилище хорошо документировано, зависимости понятны. В противном случае см. раздел «Какие проблемы не решает внедрение платформы Lakehouse» пункт 6.
А что, если нет никакого старого хранилища? Или оно находится в другом обособленном, малодоступном контуре, и нужно строить платформу почти с нуля?
3. Построение Lakehouse от первичных источников с перепроектированием архитектуры данных.
Это подход, при котором новая платформа напрямую подключается к первичным системам, а конвейеры, модели данных, правила обработки истории и контроля качества создаются заново или существенно перерабатываются под целевую архитектуру.
Плюсы подхода:
· Чистая целевая архитектура и независимость от прежнего хранилища. Новая платформа не наследует обязательную зависимость от структуры старого хранилища. Можно сразу использовать соответствующие для Lakehouse технологии и подходы.
· Возможность исправить технический долг. Миграция становится возможностью пересмотреть существующую архитектуру: удалить неиспользуемые таблицы, объединить дублирующиеся пайплайны, отказаться от полных пересчётов, стандартизировать справочники, разделить техническую и бизнес‑логику.
· Полноценная проверка Lakehouse. Проверяется не только хранение данных и выполнение SQL‑запросов, но и вся целевая платформа. Это даёт более реалистичное представление о готовности новой платформы.
· Поддержка новых сценариев. Прямой доступ к исходным и детальным данным упрощает развитие сценариев, которых могло не быть в старом DWH.
Минусы подхода:
· Максимальный объём анализа. Необходимо восстановить полный путь данных от источников до отчётности. Особенно сложно, когда документация устарела, а первоначальные разработчики больше не работают в компании.
· Длительное время до первого результата относительно других подходов.
· Риск потерять скрытую бизнес‑логику. В старом DWH могут существовать правила, которые нигде не описаны, например, исключения, ручные корректировки, особая логика закрытия периода, исторические договорённости или фильтры, добавленные из‑за инцидентов. При перепроектировании часть такой логики можно не обнаружить или ошибочно принять за технический долг.
· Необходимость согласования новой модели. Если расчёты не переносятся один в один, возникает вопрос, какой результат считать правильным. Старое DWH может показывать одно значение, а новая логика — другое. Различие не всегда означает ошибку, иногда новая система исправляет старую проблему. Но без владельца показателя невозможно определить, какой вариант должен стать целевым.
· Высокая стоимость первого этапа.
· Сложная сверка со старым DWH. Простой контроль вида «новая таблица должна быть полностью равна старой» подходит не всегда. Нужно разделять технические расхождения, бизнес‑расхождения, осознанные изменения логики, ошибки новой реализации, ошибки старой реализации.
Как вывод, миграция от первичных источников хорошо подходит, когда основная цель — не только сменить платформу, но и исправить архитектуру и решить вопрос с большим техническим долгом.
Какие возникают технические вызовы на проектах по внедрению Lakehouse разберем в второй части.
