В каких случаях Lakehouse может стать лучшим решением для бизнеса, каким функциональным и техническим требованиям должно удовлетворять решение, чтобы считаться полноценной Lakehouse-платформой, как выглядит типовой путь внедрения и за счет чего достигается снижение совокупной стоимости владения данными — рассказывает Владислав Подречнев, директор yаправления инженерии данных компании «Синимекс».
— Какие вы могли бы отметить предпосылки для появления решения
класса Lakehouse на российском рынке? Как его появление повлияло на
рынок больших данных?
В. Подречнев: Появление Lakehouse — закономерный результат эволюции мира данных. Классические DWH отлично справлялись с регламентированной отчетностью и построением витрин в условиях, когда данные были хорошо структурированы и более предсказуемы. По мере роста числа источников (событийные логи, потоковые, полу- и неструктурированные данные), ускорения бизнес-процессов и ужесточения требований к self-service аналитике DWH оказался экономически тяжелым и операционно «жестким». Высокая стоимость лицензий в сочетании с необходимостью дублировать данные вынуждала дата-инженеров искать более дешевые и гибкие подходы к хранению информации.
Так возник параллельный мир Data Lake, который обеспечил гибкость
хранения любых типов данных, но без транзакционности, строгой управляемости и гарантированной повторяемости результатов. Неаккуратная эксплуатация и неидеальные архитектурные практики нередко превращали
озера данных в «болота».
На этом фоне стали появляться открытые табличные форматы (Iceberg,
Delta, Hudi, Paimon), которые привнесли в файловые хранилища «поведение»
управляемых таблиц: ACID-операции, версионирование, time travel, эволюцию схем. По сути, файлы в Data Lake получили свойства управляемых
DWH-таблиц — это и стало «техническим» триггером для появления
Lakehouse.
В числе драйверов со стороны бизнеса я бы выделил экспоненциальный рост
объемов и типов данных, выход аналитики за пределы ИТ — в
бизнес-подразделения, стремительный рост ИИ и LLM как потребителей
данных.
Таким образом, Lakehouse снимает болевые точки обоих лагерей: «дорого и
жестко» в DWH, «гибко, но без гарантий» в Data Lake. В результате мы получаем единый масштабируемый фундамент под расширяющуюся воронку аналитических и продуктовых сценариев.
— Как появление Lakehouse повлияло на практики команд?
В. Подречнев: С внедрением Lakehouse данные проходят значительно более короткий путь и быстрее становятся доступными конечным пользователям. Если раньше бизнесу приходилось ждать прохождения долгих и трудоемких этапов обработки, то теперь данные можно получать и использовать из единого «источника правды». В результате они становятся точнее и доступнее, а потребители получают их существенно быстрее.
— Каким функциональным и техническим требованиям должно удовлетворять решение, чтобы считаться полноценной Lakehouse-платформой?
В. Подречнев: Lakehouse базируется на трех ключевых
«китах». В основе зрелой Lakehouse‑платформы лежит единый слой хранения
данных в открытых колоночных форматах (чаще всего в Parquet), поверх
которого реализуется транзакционный табличный слой. Этот слой — будь то
Delta Lake, Apache Iceberg, Hudi или Paimon — обеспечивает ACID‑гарантии, версионирование, time travel и эволюцию схем, что позволяет поддерживать согласованность и воспроизводимость данных без их копирования между разными контурами. Физически эти данные находятся в объектных хранилищах, например в MinIO.
Второй обязательный элемент Lakehouse — вычислительный слой с поддержкой
классического SQL, способный работать напрямую по таблицам в объектном
хранилище. На практике применяются разные SQL‑движки под разные задачи:
Apache Spark, Trino, Dremio, StarRocks, Flink, Hive, Impala и др. У каждой технологии есть свои сильные стороны и ограничения: одни лучше подходят для массовых пакетных обработок, другие — для интерактивных запросов с низкой задержкой, третьи — для потоковой обработки или интеграции со сложными open source экосистемами. Конкретный выбор зависит от профиля задач, нагрузки и инфраструктуры.
Третий «кит», который совершенно напрасно не всегда включают в число
обязательных, — это слой Data Governance, который позволяет навести
порядок в обращении с данными...
Продолжение читайте на https://futurebanking.ru/post/4180