Привет, Хабр. С вами Влад Подречнев, директор направления Data Engineering в «Синимекс», и этой статьей я хотел бы открыть небольшой цикл статей на тему Lakehouse. По традиции подобных статей начну с обзора-введения, дальше будем углубляться.
Для тех, кто только знакомится с этим архитектурным подходом к хранению данных, я, забегая вперед, скажу, что этот подход объединил в себе лучшие черты старого доброго Data Warehouse и гибко-хаотичного Data Lake. В этой статье я широкими мазками нарисую картину того, как работает этот подход и как к нему приходили.
Эволюция данных: от DWH и Data Lake к Lakehouse
История управления данными напоминает эволюционный путь от простых структур к сложным системам. В 1966 году появились первые технологии класса баз данных, которые быстро развивались, и к 1970-м сформировались реляционные базы данных — фундамент будущих архитектур хранения. Однако настоящий прорыв произошел уже в нашем тысячелетии, когда в 2000-х годах стал появляться класс технологий Data Warehouse (DWH), который планомерно развивался, становясь стандартом индустрии.
Data Warehouse представлял собой концепцию, ориентированную исключительно на структурированные данные. Это были реляционные хранилища, организованные по различным моделям и методологиям — всем известные «звезда»/«снежинка» и «кимбалл»/«инмон».
Данные проходили через классические ETL/ELT-процессы (Extraction, Transformation, Loading): сначала выгружались структурированные данные, затем трансформировались и загружались в финальные базы данных. Оттуда они попадали в регуляторную отчетность и первые BI-отчеты. Это был понятный, структурированный путь — местами неповоротливый, но супернадежный, работавший как швейцарские часы.
В 2006 году начался новый этап эволюции с появлением Hadoop с его HDFS и параллельным развитием S3. К 2010 году эти технологии дополнились Hive как движком вычислений, что привело к формированию нового класса технологий — Data Lake. Парадигма Data Lake строилась на файловом хранилище, которое позволяло хранить не только структурированные данные, но и складывать туда звук, видео, аудио — абсолютно любые данные, включая полностью неструктурированные документы.
Data Lake поддерживал хранение данных в их исходной форме, не требуя немедленной нормализации, и позволял работать с данными в любых форматах (JSON, XML, видео, аудио). Однако обратной стороной этой гибкости стал хаос, возникавший из-за разрозненных источников. Обработка данных не гарантировала финальную воспроизводимость результата, а главное — нарушалась парадигма ACID, которая была фундаментальной в Data Warehouse.
Эволюция данных не стояла на месте, и конфликт между структурированными и неструктурированными данными, порядком и хаосом должен был породить новую парадигму хранения и обработки данных. В 2017 году появились первые технологии, трактаты и наметки класса Lakehouse.
Суть архитектурного прорыва Lakehouse
Что же такого прорывного добавили в архитектуру, чтобы она стала считаться чем-то новым с точки зрения инженеров, а не маркетологов? Ответ: фундаментально изменилась парадигма хранения и обработки данных. В отличие от традиционных подходов, где Data Warehouse оперировал исключительно структурированными данными в табличной форме, а Data Lake работал с файлами в их исходном виде, разработчики Lakehouse сумели соединить лучшие качества обеих архитектур. Ключевым отличием стал формат OTF — Open Table Format, через который удалось реализовать единый стандарт доступа к данным и 4 технологически-культурных сдвига. Перечислю их:
OTF принес возможность использовать ACID-операции, версионность, эволюцию схем и time-travel прямо в файловое хранилище. Сегодня существует четыре ключевых технологии класса OTF: Delta Lake, Apache Hudi, Iceberg и совсем свежий Apache Paimon. Эти форматы позволяют работать с файлами как с управляемыми таблицами, сохраняя при этом все преимущества файлового хранения.
Удалось разделить слои вычисления и хранения. В Data Warehouse вычислительные движки зависели от вендора, в Data Lake они стали внешними, что давало гибкость, но снижало производительность. В Lakehouse произошла оптимизация вычислительных движков под Open Table Format, что существенно повысило производительность обработки данных. Это позволяет использовать такие движки как Apache Spark, Trino, Apache Flink и другие, оптимизированные для работы с OTF.
Data Governance стала для Lakehouse буквально частью ДНК. Отмечу, что для DWH и Data Lake использование каталогов данных и метаданных было необязательным. Теперь же каталоги данных позволяют узнать происхождение и бизнес-смысл данных, а каталоги метаданных — все технические особенности. Благодаря им удается реализовать прозрачную поддержку структурированных и неструктурированных данных в рамках единой платформы.
Самый вкусный пункт для бизнеса — проекты Lakehouse оказались на фоне предшественников более экономичными и масштабируемыми. Это связано с тем, что Lakehouse использует опенсорсные технологии или недорогие системы хранения данных, которые можно также комбинировать с проприетарным ПО — отсюда экономичность (по сравнению с DWH). При этом архитектура, как я сказал в п. 3, дает возможность отделить слой хранения от слоя вычислений по разным кластерам, тем самым облегчая масштабирование и обработку многообразных типов данных.
Хронология появления и зрелость технологии
Вернемся к истории. Как я уже сказал, путь Lakehouse как архитектуры данных начался в 2017 году, когда появились первые концептуальные наметки и статьи на эту тему. Однако это были довольно сырые идеи, которые требовали серьезной доработки. Вплоть до 2020 года архитектура активно обрастала деталями, и многие крупные компании параллельно разрабатывали свои решения. Одним из пионеров в этой области стала компания Databricks, которая на тот момент была еще относительно небольшим ИТ-консалтинговым стартапом, а не гигантом под крылом Microsoft Azure. Именно Databricks представила Delta Lake — один из ключевых OTF-форматов, ставший фундаментом для Lakehouse-архитектуры.
Параллельно с Databricks, технологические гиганты Netflix и Uber разрабатывали свои подходы к решению задачи объединения преимуществ порядка и хаоса в управлении данными. Эти компании столкнулись с необходимостью обработки огромных объемов разнородных данных и искали способы совместить гибкость Data Lake с надежностью Data Warehouse. Их усилия привели к созданию альтернативных OTF-форматов, которые впоследствии стали основой для развития экосистемы Lakehouse-решений.
Согласно отчету Gartner за 2024 год, на Западе архитектура Lakehouse была признана и прошла пик хайпа в 2021-2022 годах, а сейчас спускается в "яму разочарований", с прогнозом выхода на плато эффективности через 0-2 года. Эти наблюдения позволяют предположить, что технология уже относительно зрелая и готова к промышленному использованию.
В России ситуация развивается с традиционным отставанием от западных трендов. Соответственно, сегодня в России эта технология только приближается к своему пику хайпа, что открывает окно возможностей для отечественных вендоров. Дополню, что российский рынок больших данных характеризуется традиционно более низким уровнем доверия к размещению данных в публичных облаках по сравнению с США — и это влияет на модели внедрения Lakehouse.
На данный момент, состояние этой архитектуры характеризуется интенсивным развитием интеграционных услуг по построению Lakehouse и появлением первых осмысленных продуктов отечественных вендоров. Вендоры уже активно включились в битву за этот рынок. В частности, традиционные вендоры КХД развивают свои продуктовые предложения до полноценных Data Lakehouse, идет рост зрелости открытых ��орматов данных, таких как Apache Iceberg и Delta Lake. Lakehouse рассматривается как будущий фактический стандарт для архитектуры аналитических данных, что подтверждается трендом перехода организаций с облачных хранилищ данных и озер данных на эту архитектуру.
Open Table Format (OTF) и другие киты
Давайте теперь чуть глубже заглянем в то, что же такое Open Table Format и почему он стал тем самым "китом", на котором держится вся архитектура Lakehouse. OTF — это открытый табличный формат, который приносит отсутствовавшие изначально транзакционные возможности в Data Lake, превращая его в полноценный Lakehouse.
Основные OTF-форматы, которые сегодня доминируют на рынке, это Apache Iceberg, Apache Hudi и Delta Lake от Linux Foundation. Каждый из них имеет свою специфику и сильные стороны.
Iceberg, созданный в Netflix, поддерживает такие функции как time travel, эволюцию схем и может работать с файловыми форматами Parquet, ORC и Avro.
Hudi предлагает формат данных, оптимизированный для потоковой и инкрементальной обработки. Он поддерживает массовую загрузку, upsert/delete-операции и позволяет эффективно обновлять данные в режиме near real-time.
Delta Lake предоставляет возможности совместного использования данных, конвертации существующих Parquet-файлов в Delta и встроенные проверки качества данных.
Технический прорыв OTF заключается в том, что все три основных формата обеспечивают ACID-гарантии для операций с данными на уровне файлов и метаданных.
Благодаря этому Data Lake впервые получил возможность выполнять операции обновления и уд��ления на уровне записей, чего не поддерживал классический формат хранения Hive.
Time travel — одна из ключевых функций Lakehouse, и все три табличных формата поддерживают ее. Ее суть в том, что каждый из этих форматов может сохранять старые версии данных и восстанавливать их по номеру версии или временной метке.
Для разработчиков этот формат дает возможность работать с данными как с полноценными таблицами, сохраняя при этом все преимущества файлового хранения. Например, благодаря поддержке эволюции схем, можно легко добавлять, удалять или переименовывать столбцы без перезаписи данных. Это существенно упрощает разработку и сопровождение ETL-пайплайнов.
С точки зрения бизнеса, OTF приносит конкретные выгоды. Российские компании, внедряющие Lakehouse, отмечают снижение стоимости лицензий на DWH на 10-15%, увеличение скорости обработки данных в 8-10 раз, а в некоторых случаях ускорение достигает 2400%. Для крупного банка экономический эффект может составлять десятки миллионов, сотни миллионов и даже миллиарды рублей в год (есть кейсы).
Отмечу, что экосистема OTF продолжает развиваться. Например, появляются новые форматы (Apache Paimon), плюс вендоры дают дополнительную поддержку существующим. В частности, Databricks, которая создала Delta Lake, предлагает его как основной компонент в своей Lakehouse-платформе. Создатели Hudi основали Onehouse — коммерческое предложение для платформы Hudi. Dremio и Tabular предлагают управляемый Iceberg для построения Lakehouse.
Data Governance в Lakehouse
Выше я упомянул про ДНК Lakehouse в виде Data Governance, поясню подробнее. В отличие от традиционных Data Warehouse, где управление данными ограничивалось только таблицами и отчетами, Lakehouse предлагает унифицированную стратегию управления как данными, так и AI-активами. Это означает, что можно получать централизованное управление метаданными для таблиц, представлений, отчетов и ML-моделей из единого интерфейса.
Ключевое отличие Lakehouse в том, что без каталога метаданных невозможно представить полноценную реализацию этой архитектуры. Без него озеро данных превращается в "болото данных" — в котором объемы данных просто лежат, не имея ни организации, ни структуры. В
Lakehouse же разработчики и аналитики получают мощные инструменты типа "Google для данных". Например, Open Metadata и Data Hub реализуют все ключевые фичи Data Governance: lineage (отслеживание происхождения данных), контроль качества данных, определение владельцев и классификацию. Благодаря этим фичам датасеты находятся проще, и пороги входа для аналитиков и дата-сайентистов становятся ниже.
По сути бизнес получил возможность узнавать про данные абсолютно всё.
Кроме того, для бизнеса оказалось весьма удобным унифицированное управление данными — можно повторно использовать правила качества данных, разрешения доступа и другие политики управления, созданные для разных активов. Такие возможности снижают операционные издержки и упрощают соблюдение комплаенса.
Технически, каталоги метаданных в Lakehouse, такие как Hive Metastore и Nessie, выступают "точкой истины" для всех SQL-движков, гарантируя согласованность и единый доступ к данным. Nessie даже позволяет работать с файлами в парадигме Git — с branching, tagging и time travel — можно безопасно экспериментировать с данными и откатывать изменения.
Compute-движки
Теперь давайте пробежимся по вычислительным движкам — тому самому третьему киту архитектуры Lakehouse. В отличие от традиционных Data Warehouse, где вычислительные движки были жестко привязаны к вендору, Lakehouse в этом плане супергибкий - все движки внешние и независимые. Но прорыв случился позже — когда движки стали оптимизировать под Open Table Format. С ним они стали работать быстрее.
Поскольку у Lakehouse открытая архитектура, то в нем реализуется доступ к данным через любые совместимые обработчики. Тут можно использовать как open-source движки (Spark, Presto, Trino, Flink, Hive), так и коммерческие оптимизированные решения. При этом привычным языком в экосистеме по прежнему остается SQL.
Каждый вычислительный движок заточен под свою конкретную задачу. Например, инженеры данных могут использовать Spark для выполнения PySpark-кода и ETL-подобных рабочих нагрузок, в то время как аналитики данных могут использовать SQL-движки вроде Presto или Trino для запросов к тем же данным из Lakehouse.
Отмечу, что Trino действительно является одной из самы�� многообещающих технологий благодаря своему федеративному преимуществу — возможности обращаться через SELECT к абсолютно разным источникам данных и строить запросы одновременно в Oracle, Postgres, CSV, Parquet и JSON.
Для потоковой обработки данных оптимален Apache Flink — фреймворк, обеспечивающий обработку потоков данных в реальном времени и интеграцию с системами хранения и обмена данными, такими как Kafka, Hudi и Iceberg. Impala же дает меньшую задержку для near real-time сценариев. Отмечу, что все основные форматы OTF (Iceberg, Hudi, Delta Lake) поддерживают широко распространенные open-source вычислительные движки, включая Spark, Trino, Presto, Flink и Hive. Однако при выборе движка необходимо учитывать его поддержку конкретного формата таблиц и возможные ограничения при работе с коммерческими движками облачных провайдеров.
Таким образом, вычислительное ядро можно собрать из нескольких движков в одном Lakehouse, позволяя разным командам выполнять свои вычислительные задачи наиболее оптимальным инструментом.
Польза и KPI
Ключевое преимущество — это снижение TCO (Total Cost of Ownership) в среднем на 30%+ за счет отказа от лицензий на DWH. Для крупных банков это означает, на минуточку, экономию десятков и сотен миллионов рублей в год.
Помимо экономии, Lakehouse объединяет низкую стоимость хранения (от Data Lake) и высокую производительность для аналитических нагрузок (от DWH). Поскольку форматы данных открытые, а решения могут быть облачными/ гибридными, резко падает зависимость от дорогих проприетарных СУБД.
Что касается производительности, то в разных источниках приводится ускорение обработки данных от 20% до 2400%. Конкретика? Пожалуйста: Burger King заявил об ускорении обработки данных с трех дней до трех часов, Банк Санкт-Петербург — в 8-10 раз, а РСХБ заявляет экономический эффект в 7 миллиардов рублей (упоминал выше).
Для ML-проектов Lakehouse является гарантией ML Ready — компания готова к внедрению ML вдоль и поперек. KPI тут могут быть как повышение точности риск-моделей, сокращение времени на вывод на рынок таких моделей, наконец, рост эффективности сценарного планирования.
Предпосылки для внедрения
Теперь вернемся к реалиям — Lakehouse нужен не всем. Далеко не все компании ставят себе цель построить систему управления данными на многие годы вперед. Также не у всех есть цель соответствовать времени и идти в ногу с технологиями.
Приходится также считаться с тем, что Lakehouse хоть и наиболее многообещающая архитектура хранения данных, но все же надо здраво подходить к своим возможностям. В частности, нужно тщательно оценива��ь такие критерии, как возможности горизонтального масштабирования, совместимость с привычными инструментами и реалистичность совокупных затрат (с учетом обучения персонала и интеграции). Здесь архитектурные ошибки при стоимости современных инфраструктурных компонентов стоят очень дорого — и по «железу», и по времени специалистов.
С другой стороны, эта архитектура помогает решить вопрос с импортозамещением. Для многих бизнесов критична возможность развивать систему без риска vendor-lock. Поскольку мы как интеграторы не завязываемся на одного конкретного вендора и не оперируем одним коробочным решением, мы имеем возможность строить архитектуру гибко, объединяя проприетарные технологии, которыми довольны, с open-source решениями.
Далее, Lakehouse подходит компаниям, которые хотят использовать единую платформу данных для всех задач Big Data. Особенно актуально это для организаций, где объем данных уже достиг терабайтов, и их нужно обрабатывать быстро.
Важным триггером для внедрения является необходимость наведения порядка в данных. Если компания уже столкнулась с бардаком в источниках данных и ценит порядок, Lakehouse становится естественным выбором. Причины я объяснил выше.
Еще один ценный фактор - гибкость архитектуры. Lakehouse умеет адаптироваться к новым сценариям (например, перемещаться между потоковой, пакетной и интерактивной аналитикой), а также без существенных затрат времени и ресурсов обеспечивает долгосрочную актуальность и эффективность решений.
Заключение
Ну а на сегодня у меня с докладом все. Надеюсь, было полезно. Приглашаю подписываться на блог нашей компании «Синимекс» на Хабре, чтобы не пропустить продолжение цикла статей по эффективной и современной архитектуре Lakehouse.
Да пребудет с вами сила качественных данных.
