Data Lakehouse: почему озера-хранилища данных ожидает значительный рост в 2025 году

Озеро-хранилище (lakehouse) данных робко появилось около восьми лет назад, когда организации искали золотую середину между беспорядочностью озер данных (data lakes) и замкнутой суетливостью хранилищ данных (warehouses). Новый архитектурный паттерн привлек несколько последователей, но рост не был впечатляющим. Однако в 2025 г., согласно новому исследованию Dremio, благодаря стечению обстоятельств озера-хранилища данных будут развиваться весьма активно, сообщает портал BigDATAwire.

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

Позволяя клиентам сбрасывать большие объемы полуструктурированных и неструктурированных данных в распределенную файловую систему, кластеры Hadoop получили прозвище «озера данных». Клиенты могли обрабатывать и преобразовывать данные для своих конкретных аналитических нужд по требованию, реализуя так называемый подход «structure on read» (стратегия сбора и анализа данных, при которой их структура определяется во время чтения).

Это существенно отличалось от подхода «structure on write» (структура определяется при записи), который использовался в типичных хранилищах данных того времени. До появления Hadoop предприятиям приходилось тратить время на преобразование и очистку транзакционных данных перед их загрузкой в хранилище данных. Это увеличивало затраты времени и денег, но было необходимо для максимального использования дорогостоящих ресурсов хранения и вычислений.

По мере продвижения эксперимента с Hadoop многие предприятия обнаружили, что их озера данных превратились в «болота данных». Хотя сброс необработанных данных в HDFS или S3 радикально увеличивал объем данных, которые они могли хранить, это происходило за счет более низкого качества данных. В частности, в Hadoop отсутствовали средства контроля, позволяющие предприятиям эффективно управлять своими данными, что привело к снижению доверия к аналитике Hadoop.

К середине 2010-х несколько независимых команд работали над решением проблемы. Первую команду возглавлял Винот Чандар, инженер из Uber, которому нужно было решить проблему быстрого перемещения файлов для приложения по совместному использованию автомобилей. Он руководил разработкой формата таблиц, который позволил бы Hadoop обрабатывать данные подобно традиционной базе данных. Чандар назвал его Hudi, что расшифровывается как «Hadoop upserts, deletes, and incrementals». Uber внедрила Hudi в 2016 г.

Год спустя еще две команды представили аналогичные решения для озер данных HDFS и S3. Инженер Netflix Райан Блю и инженер Apple Дэниел Викс совместно создали формат таблиц под названием Iceberg, который должен был привнести в таблицы Apache Hive возможности ACID-подобных транзакций и откатов. В том же году компания Databricks выпустила Delta Lake, объединив возможности хранилищ данных по работе со структурированными данными с облачным озером данных, чтобы привнести «хорошее, лучшее, оптимальное» в управление данными и обеспечение их качества.

Эти три формата таблиц в значительной степени стимулировали рост озер-хранилищ данных, поскольку они позволяли применять традиционные методы управления данными в базах данных в качестве слоя поверх озер данных в стиле Hadoop и S3. Таким образом, клиенты получали лучшее из двух миров: масштабируемость и доступность озер данных и качество и надежность данных в хранилищах данных.

Другие платформы данных, включая AWS, Google Cloud и Snowflake, начали принимать один из форматов таблиц. Iceberg, который в 2020 г. стал проектом Apache высшего уровня, получил значительную поддержку от открытой экосистемы Hadoop. Databricks, которая сначала придерживалась Delta Lake и лежащего в ее основе формата таблиц, а затем постепенно открылась, также становилась все более популярной. Третьим по популярности стал формат Hudi, который в 2019 г. получил статус проекта Apache верхнего уровня.

Битва между Apache Iceberg и Delta Lake за доминирование в области форматов таблиц казалось бы зашла в тупик. Однако в июне 2024 г. Snowflake усилила поддержку Iceberg, запустив каталог метаданных для Iceberg под названием Polaris (теперь Apache Polaris). Практически одновременно Databricks объявила о приобретении основанной Райаном Блу, Дэниелом Уиксом и бывшим инженером Netflix Джейсоном Ридом компании Tabular, платформа которой основана на Iceberg, за сумму от 1 до 2 млрд. долл.

Руководители Databricks во главе с генеральным директором Али Годси объявили, что форматы Iceberg и Delta Lake со временем будут объединены: «Мы собираемся стать лидерами в области совместимости данных, чтобы вы больше не были ограничены тем, в каком формате озер-хранилищ хранятся ваши данные».

Запуск Polaris и приобретение Tabular оказали огромное влияние, особенно на сообщество поставщиков, разрабатывающих независимые движки запросов, и сразу же вызвали рост популярности Apache Iceberg. «Если вы принадлежите к сообществу Iceberg, то для вас наступает время вступить в новую эру», — сказал в июне 2024 г. Рид Мэлони, директор по маркетингу компании Dremio.

Семь месяцев спустя этот импульс не иссяк. В январе 2025 г. Dremio опубликовала новый отчет под названием «State of the Data Lakehouse in the AI Era», который составлен на основе опроса 563 лиц, принимающих решения в области данных, проведенного McKnight Consulting Group в IV квартале 2024 г.

Отчет засвидетельствовал растущую поддержку озер-хранилищ данных (которые теперь по умолчанию считаются основанными на Iceberg). «Наш анализ показывает, что озера-хранилища данных достигли критического порога принятия: 55% организаций проводят большинство аналитических операций на этих платформах, — говорится в отчете. — По прогнозам респондентов, в ближайшие три года эта цифра достигнет 67%, что свидетельствует о явном изменении стратегии работы с данными на предприятиях».

Dremio утверждает, что основным фактором роста озер-хранилищ данных остается экономическая эффективность, на которую указали 19% респондентов, за которой следуют унифицированный доступ к данным и повышенная простота использования (по 17%) и аналитика самообслуживания (13%). По данным опроса, 41% пользователей озер-хранилищ данных перешли из облачных хранилищ данных, а 23% — из стандартных озер данных.

Более качественная и открытая аналитика данных занимает первое место в списке причин перехода на озеро-хранилище данных, однако Dremio обнаружила удивительное большое количество организаций, использующих свое озеро-хранилище данных для поддержки другого сценария использования — разработки ИИ. Так, 85% пользователей озер-хранилищ данных в настоящее время используют их для разработки моделей ИИ, а еще 11% планируют это делать. Ошеломляюще мало (4%) пользователей lakehouse заявили, что не планируют поддерживать разработку ИИ.

Несмотря на то, что стремление к ИИ является всеобщим, организациям еще предстоит преодолеть серьезные препятствия, прежде чем они смогут реализовать свою мечту об ИИ. В ходе своего исследования Dremio выяснила, что организации сталкиваются с серьезными проблемами на пути к достижению успеха в подготовке данных для ИИ. В частности, 36% респондентов заявили, что главной проблемой являются регулирование и безопасность при использовании ИИ, затем следуют высокие стоимость и сложность (33%) и отсутствие единой инфраструктуры, готовой к ИИ (20%).

По словам Джеймса Роуленд-Джонса, вице-президента Dremio по управлению продуктами, архитектура lakehouse является ключевым компонентом для создания продуктов данных, которые хорошо управляются и широко доступны, что очень важно для упрощения разработки ИИ-приложений.

«Важно то, как происходит обмен данными и что с этим связано, — говорит Роуленд-Джонс. — Как они обогащаются? Как вы понимаете их и рассуждаете о них как конечный пользователь? Получаете ли вы статистическую выборку данных? Можете ли вы понять, что это за данные? Документированы ли они? Регулируются ли они? Есть ли глоссарии? Можно ли использовать глоссарий в разных представлениях, чтобы люди не дублировали все эти усилия?».

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

«Ландшафт архитектуры данных находится на переломном этапе, когда требования ИИ и продвинутой аналитики меняют традиционные подходы к управлению данными, — считает Мэлони. — Этот отчет описывает, как и почему компании используют озера-хранилища данных для стимулирования инноваций, решая при этом такие важные задачи, как экономическая эффективность, регулирование и готовность к ИИ».

Для целей регулярной отчетности и бизнес‑аналитики отлично подойдет классическое хранилище данных (DWH). Оно помогает объединить и привести к единому формату данные из информационных систем, баз данных и других источников: CRM, ERP, систем бухгалтерского учета, кассовых систем. Благодаря своей структурированности и оптимизации данных, КХД позволяет получить быстрый доступ к большим объемам информации без значительного влияния на производительность информационных систем и оперативных баз данных.

Data Lake — метод хранения и обработки «больших данных». Сбор структурированных и неструктурированных данных расширяет возможности для продвинутой аналитики или для использования инструментов машинного обучения. Озеро данных становится особенно ценным инструментом в крупных концернах с распределенной структурой, так как позволяет извлекать пользу из неочевидных источников информации.

Концепции Data Lakehouse, Data Fabric и Data Mesh — следующие уровни работы с данными, которые охватывают не только технологический стек, но и организационную структуру компании. Реализация таких архитектур подразумевает полный пересмотр бизнес‑процессов в компании, но при грамотном внедрении повышает эффективность работы всех подразделений.

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

В любом случае, лучшим решением станет начать с предпроектного обследования — оценки бизнес‑процессов, источников данных, инфраструктуры компании. 

Для целей регулярной отчетности и бизнес‑аналитики отлично подойдет классическое хранилище данных (DWH). Оно помогает объединить и привести к единому формату данные из информационных систем, баз данных и других источников: CRM, ERP, систем бухгалтерского учета, кассовых систем. Благодаря своей структурированности и оптимизации данных, КХД позволяет получить быстрый доступ к большим объемам информации без значительного влияния на производительность информационных систем и оперативных баз данных.

Data Lake — метод хранения и обработки «больших данных». Сбор структурированных и неструктурированных данных расширяет возможности для продвинутой аналитики или для использования инструментов машинного обучения. Озеро данных становится особенно ценным инструментом в крупных концернах с распределенной структурой, так как позволяет извлекать пользу из неочевидных источников информации.

Концепции Data Lakehouse, Data Fabric и Data Mesh — следующие уровни работы с данными, которые охватывают не только технологический стек, но и организационную структуру компании. Реализация таких архитектур подразумевает полный пересмотр бизнес‑процессов в компании, но при грамотном внедрении повышает эффективность работы всех подразделений.

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

В любом случае, лучшим решением станет начать с предпроектного обследования — оценки бизнес‑процессов, источников данных, инфраструктуры компании. 

Александр Репин

Не понимаю эти шарады вокруг ETL и ELT. Что это чуть ли не единственная разница между озером и просто хранилищем. И озеро без трансформации надо было болотом назвать.

Концепции… Придумали же они там. Заменить у машины одну деталь и сказать что она теперь самолёт.

Реляционным хранилищам данных (ХД) более трех десятков лет. За последние 10 лет закат традиционной аналитики на их основе предрекали как минимум два раза. Сначала — при появлении облачных ХД, затем — озер данных.

Построение хранилища данных на территории заказчика (“on premises”) — инвестиционно-емкий проект, который может занимать до одного года и более. Облачные ХД были призваны удешевить стоимость развертывания хранилища, а также справиться с постоянно растущими объемами исходных данных. Но повсеместного перехода с традиционных ХД на облачные не произошло. По результатам последнего опроса IDC, 47% предприятий в мире используют централизованную архитектуру облачного хранилища. Но через два года этот показатель сократится до 22%. Основная причина в том, что возможности передачи данных растут медленнее, чем емкости хранилищ.

Что касается высокопроизводительных программно-аппаратных комплексов, используемых при построении ХД, таких как Oracle Exadata, то в России уже сегодня наблюдается опережающий спрос на «on-premises» решения.

После облачных ХД следующей «угрозой» для традиционных хранилищ стали озера данных. По оценке IDC, с 2010 по 2020 год объем мировой «цифровой вселенной» вырос в 32 раза и достиг 64 ЗБ. Аналитика больших данных превратилась в быстрорастущий ИТ-сегмент, а озера данных — в ключевой элемент Big Data инфраструктуры. Появились предположения, что озера могут отвоевать долю рынка у реляционных баз данных и даже «поглотить» традиционные ХД. Но сегодня каждое из них: хранилище и озеро — по-прежнему обслуживает собственную аналитическую нишу.

Одно из последних предсказаний о закате реляционных ХД связано с новой гибридной архитектурой — data lakehouse. Предполагается, что она придет на смену хранилищам и озерам данных, объединив эта два инструмента подготовки данных для аналитики. Термин data lakehouse условно можно перевести как «хранилище и озеро данных».

Ознаменует ли появление data lakehouse конец жизненного цикла ХД, или это просто новая организация работы с данными? Попробуем разобраться.

Почему появилась идея data lakehouse

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

В отличие от хранилищ, озера данных ориентированы на обработку неструктурированных и структурированных данных (Big Data), первые могут составлять до 80%. Данные могут извлекаться из потоков — социальных сетей, электронной коммерции, датчиков и Интернета вещей (IoT). Схема озера данных определяется «по чтению» (on read), а хранилища — «по записи» (on write). Наконец, озера не предусматривают высокую производительность обработки запросов и поддержку многопользовательского режима работы. Собранные в них данные — основа для применения методов машинного обучения (machine learning) и различных подходов «науки данных» (Data Science).

Как правило, хранилища и озера работают изолированно друг друга. Появление концепции гибридной архитектуры — это попытка объединить данные, собранные в хранилища и озера, и аналитические выводы, полученные на их основе.

Гибридная архитектура может не только расширить возможности хранилищ в части аналитики неструктурированных данных, но и устранить ограничения озер в обеспечении качества данных. Ряд экспертов также считает, что вычислительные возможности open-source платформ для озер данных начинают не справляться с нагрузкой, что подрывает идею об их экономичности.

Согласно исследованию TDWI, сегодня озера часто выполняют вспомогательную роль в подготовке аналитики. Только треть опрошенных компаний (37,3%) использует озера данных по прямому назначению — для продвинутой и ML-аналитики. Остальные — как область для временного хранения копии исходных данных перед их ETL-обработкой (37,3% опрошенных) или как расширение хранилища данных (36,7% опрошенных).

Data lakehouse: когда ждать пришествия варяга

Гибридная архитектура пока находится на уровне концепции, а соответствующая терминология только формируется. Например, большинство участников исследования TDWI предпочитают использовать термины, связанные с архитектурой. 43% называют ее корпоративной архитектурой данных (enterprise data architecture), 36% — гибридной архитектурой данных (hybrid data architecture), 35% — современной архитектурой хранилища данных (modern data warehouse architecture). Сами эксперты TDWI склоняются к термину мультиплатформенная архитектура данных (multiplatform data architecture), а аналитики Gartner используют data lakehouse.

По мнению последних, data lakehouse является развитием концепции логического хранилища данных, которое Gartner представил около 15 лет назад. Аналитики описывают ее как конвергентную инфраструктурную среду, в которой обеспечиваются все шаги по обработке и преобразованию данных: от сырых данных до информации, готовой для «употребления». Технология data lakehouse только прорабатывается, и пройдет пять-десять лет, пока она выйдет на так называемое плато продуктивности на кривой хайп-технологий в области управления данными.

Чем привлекательна гибридная архитектура

Основная выгода, которую принесет data lakehouse — извлечение еще большей ценности из данных. Об этом заявили 64% участников упомянутого опроса TDWI.

Переход к гибридной архитектуре позволяет унифицировать источники данных: и хранилища, и озера — в масштабе всей организации и обеспечить получение непротиворечивой отчетности и аналитики для разных бизнес-вертикалей. Так считают 53% участников опроса TDWI.

Сегодня корпоративные ХД могут ограниченно использовать ML-методы. По мнению 49% респондентов TDWI, применение data lakehouse дает возможность расшить «узкие места» традиционной аналитики. Если хранилища и озера будут унифицированы, а данные в озерах — структурированы, и их можно будет обрабатывать с помощью запросов, гибридная архитектура может стать основой для аналитической обработки традиционных и новых типов данных.

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