Коммерсантъ FM

Дом у озера данных

Руководитель продуктовой архитектуры платформы данных Yandex Cloud Леонид Савченков — о переходе от классических DWH, экономии и работе с ИИ

Архитектурная концепция Lakehouse (озеро-хранилище) сочетает свойства сразу двух конкурирующих подходов к хранению и работе с данными — Data Warehouse (DWH — структурированное хранилище для бизнес-аналитики, основанное на жесткой схеме) и Data Lake (хранилище для больших массивов сырых данных любого формата). Само название складывается из этих двух понятий: Lake + Warehouse.

Новая концепция возникла как ответ на отраслевые проблемы: озера данных оказались слишком неструктурированными для серьезной аналитики, а традиционные хранилища — дорогими и плохо масштабируемыми на больших объемах. Кроме того, бизнесу потребовалось одновременно и жесткое управление данными, и гибкость под новые типы данных, и возможность строить на одной платформе и обычные отчеты, и модели ИИ. О развитии подхода, миграции крупного бизнеса и перспективах аналитики рассказывает руководитель продуктовой архитектуры платформы данных Yandex Cloud (входит в Yandex B2B Tech) Леонид Савченков.

Фото: Предоставлено пресс-службой Яндекса

Фото: Предоставлено пресс-службой Яндекса

— Что такое Lakehouse и чем он отличается от традиционных DWH и data lake?

— Lakehouse объединяет две предыдущие концепции. Ключевое отличие — данные хранятся отдельно от вычислительных мощностей, которые их обрабатывают. Грубо говоря, «склад» и «завод» работают независимо друг от друга. Можно нарастить мощности для обработки данных, не докупая дополнительное место для их хранения, и наоборот. Это делает систему дешевле и более гибкой в эксплуатации. Эффективно расходуются ресурсы, а еще ее легче разворачивать в облаках. В отличие от Data Lake, где данные складываются без предварительной структуры («складываем и потом разберемся»), в Lakehouse появляются строгие табличные форматы хранения и более зрелый уровень управления данными — близкий к тому, что есть в СУБД (система управления базами данных). Также такой подход чуть проще разворачивать в облаках, чем в on-premises (на собственных серверах).

— Почему бизнес переходит на Lakehouse именно сейчас, если подход был представлен и проработан еще пять лет назад?

— Data Lake решал проблему объема — туда можно складывать любые данные в любом виде. Но когда бизнесу нужно было строить на этих данных отчеты и принимать решения, возникала проблема: данные есть, а работать с ними быстро и надежно — сложно. Не было ни единых стандартов хранения, ни инструментов контроля качества данных, привычных по классическим хранилищам.

При росте объемов данных, например, свыше 100 ТБ классические хранилища DWH начинают давать сбои: замедляются отчеты, растет нестабильность. Единственный способ это исправить — докупать серверные мощности. Но в традиционной архитектуре хранение данных и их обработка неразрывно связаны, поэтому расширять приходится сразу все — даже если «узкое место» только одно. Затраты растут быстро, а отдача от каждого нового сервера — все меньше. Дальше классические DWH либо становятся слишком дорогими (проблему «заливают» железом), либо требуют высокой экспертизы, чтобы поддерживать растущие требования бизнеса. Lakehouse позволяет выйти на сотни терабайт и петабайты данных, покрывая новые объемы и потребности аналитики.

— Как санкции и импортозамещение влияют на интерес к новому подходу?

— Архитектуру Lakehouse можно собрать на open-source решениях или вендорских продуктах на их основе. Тем самым отрасль делает полшага вперед. Конкретные кейсы сегодня — это, например, Т-банк, который мигрировал с классического DWH. Торговая сеть «Магнит» для своей системы планирования поставок F&R с жестким требованием по времени обсчета в 15 минут выстроила пока гибридную модель, которая позволяет решать основные задачи бизнеса. Строительная «Леман Про», «Ламода» — почти все декларируют снижение совокупной стоимости владения (TCO) и задел на будущее по масштабированию.

— Каковы узкие места нового подхода?

— Чудес не бывает. Остается потребность в хорошей технической экспертизе по настройке вычислительных движков (например, Trino и Spark). Также важным вопросом остается: как масштабировать — в ширину или в высоту, как оптимизировать запросы. Такая экспертиза в конкретных движках с рынка не уйдет никогда — всегда будут нужны специалисты, которые умеют их настраивать.

— Как происходит миграция с DWH на Lakehouse? Это полная замена?

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

— Существует ли риск, что топ-менеджмент условного крупного бизнеса решится на миграцию поэтапно и забуксует на первичном этапе: «и так все работает, зачем продолжать»?

— Такой риск есть. Но если бизнес растет, то нагрузка растет, и старый DWH все равно будет «постреливать»: будет падать стабильность или расти время генерации отчетов. Надолго расслабиться не получится. При этом миграция в Lakehouse дешевле, чем миграция из одного хранилища в другое, поэтому она дается проще. Также ее легче контролировать из-за гибкости настройки мощностей.

— Для каких сценариев в ритейле Lakehouse дает наибольший эффект?

— Прежде всего — пиковые нагрузки, например, ажиотаж вокруг «черной пятницы» или Нового года. Lakehouse позволяет эластично увеличивать емкость на период пика и не платить за избыточные мощности весь год. Это касается и маркетинга, и управления запасами, и HR-систем (сезонные сотрудники), и онлайн-каналов.

— Как решаются вопросы безопасности?

— В облаке доступ контролируется централизованно — через IAM, аудит и мониторинг. Ключевые механизмы те же: шифрование, ролевой доступ (RBAC), соответствие требованиям регуляторов. Отличие Lakehouse от классической СУБД в том, что данные теоретически может прочитать тот, кто получил доступ к объектному хранилищу. Но подходы к защите не меняются. Более того, как ни странно, облако в этом смысле выглядит безопаснее, чем on-premises: доступ контролируется в едином месте, легче аудировать.

В классической базе данных информаци физически лежит под СУБД, и ее можно зашифровать так, что без ключа ничего не прочитаешь. В Lakehouse чисто теоретически данные можно хранить так, что доступ к объектному хранилищу дает возможность их прочитать. Поэтому подходы безопасности абсолютно те же: шифрование, контроль доступа. Возможно, требуется чуть больше работы со стороны службы информационной безопасности (СИБ), потому что Lakehouse — это многокомпонентная система, а не одна СУБД, где все можно урегулировать на уровне пользователей.

— Для каких задач с ИИ подходит Lakehouse?

— Lakehouse удобен для экспериментов с ИИ. За счет разделения вычислений можно выделить под ИИ отдельные мощности, не влияя на основной поток нагрузки (поступление данных, формирование отчетов, чтение). Если хранилищу и так «плохо», дополнительная нагрузка его не улучшит. Lakehouse здесь радикально лучше, потому что нагрузкой от ИИ можно независимо управлять — «поселить» его на отдельные вычислительные мощности. За счет эластичного хранения и разделения compute и storage (вычислений и хранения) текущий бизнес-процесс не страдает. Когда эксперименты покажут результат, можно переходить к точечному внедрению.

Отдельная ветка — аналитика на естественном языке, когда бизнес формулирует запрос практически устно и получает график. Ретейлеры уже строят таких чат-ботов. Например, X5 Group, по имеющимся данным, создала бота, который отвечает на вопросы типа «как там с молоком, какие тренды по молочной продукции в Северо-Западном регионе». Разумеется, там выстраивается контур контроля ошибок, чтобы ответ был именно про молоко, а не про кисломолочку.

ИИ естественным образом подходит для преобразования пользовательского запроса с учетом контекста организации и разметки данных в нужный SQL-запрос. У Yandex Cloud есть «Нейроаналитик» в DataLens, его качество будет расти: он сможет отвечать на более сложные вопросы, получать больше агентских функций. В широком смысле для аналитики на базе Lakehouse это одно из ключевых направлений.

— Какую долю рынка занимает Lakehouse в России и когда подход станет массовым?

— Ключевой блокер — деньги. Если бюджеты на миграции будут, темпы вырастут. При нынешних трендах распространение Lakehouse будет расти вдвое быстрее рынка аналитических решений в целом. У всех он не появится никогда — через пять лет, вероятно, возникнет новая концепция. Бизнесу, которому решение нужно «прямо сейчас», ждать не стоит. А тем, кто только начинает строить аналитику с нуля, стоит сравнить TCO для своего объема: на маленьких объемах классический DWH может быть дешевле и проще.