Переход к технологии Lakehouse активно обсуждается во многих компаниях, поскольку она снижает совокупную стоимость владения активами (TCO), позволяя экономить, например, на аппаратном обеспечении, поддержке ПО и закупках лицензий. Рассмотрим, как Lakehouse на практике оптимизирует работу с аналитическими сценариями, каковы возможности технологии, подводные камни и стратегии внедрения новой архитектуры.

Новая революция в аналитике

Архитектура Lakehouse подает большие надежды и вызывает повышенный интерес в мире ИТ — есть вероятность, что она изменит подход к реализации аналитических систем. Так было с Hadoop 10-12 лет назад — тогда многим казалось, что этот фреймворк заменит любые аналоги и удовлетворит все потребности аналитиков. В конечном счете он не стал универсальной платформой, но занял свою устойчивую нишу и позволил выполнять целый пласт задач, которые сложно или невозможно решить другими средствами.

Вероятно, архитектура Lakehouse будет развиваться по тому же сценарию. Эволюционно она очень похожа на Hadoop: каждая из этих платформ представляет собой не монолитное решение, а набор технологий, между которыми выстраиваются связи.

Ключевые преимущества Lakehouse

У архитектуры Lakehouse есть два основных преимущества, которые делают ее особенно интересной. Во-первых, она снижает совокупную стоимость владения (TCO) на горизонте 3-5 лет: например, позволяет экономить на аппаратном обеспечении, поддержке и закупках лицензий, что возможно благодаря разделению подсистем расчетов и хранения. Ими можно динамически управлять по отдельности.

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

Раздельная архитектура повышает гибкость применения разных движков, упрощая работу аналитиков. Это позволяет сотрудникам решать задачи наиболее удобными и привычными инструментами, а значит более эффективно применять профессиональные навыки в интересах бизнеса. Движки можно использовать на платформе параллельно, масштабируя нагрузки и выделенные им вычислительные ресурсы.

Второе преимущество Lakehouse — возможность полностью раскрыть потенциал классических реляционных баз данных RDBMS с их транзакционностью, отказоустойчивостью и консистентностью. Архитектура поддерживает набор требований ACID, то есть согласованные данные с функцией полного отката транзакций в распределенном кластере.

Стратегия внедрения и поддержки

Основные компоненты Lakehouse — бесплатные, с открытым исходным кодом. Для их установки и настройки нужно только рабочее время двух-трех специалистов. Это не слишком сложная задача: развернуть платформу и проверить ее в рамках пилотного сценария получится в течение месяца. Можно без серьезных издержек оценить целесообразность перехода на новую архитектуру, протестировать разные сборки и компоненты, выбрать вендоров и принять решения о дальнейших шагах.

Каждая компания выстраивает аналитику в Lakehouse на основе собственных требований и акцентов, но в любом случае платформа сможет поддержать классическую отчетность и процедуры загрузки по расписанию, отчетность в режиме, близком к реальному времени, и ML-сценарии.

Чтобы свести к минимуму капитальные затраты, Lakehouse следует внедрять по частям. Лучше начать с небольшого минимально жизнеспособного продукта (MVP) и точечного решения задач, которые вызывают сложности в текущем технологическом стеке. На следующем этапе можно шаг за шагом переносить в Lakehouse другие процессы, для которых эта архитектура функционально подходит лучше всего, и проектировать ее под эти функции. Запускать первые аналитические сценарии стоит одновременно с внедрением платформы, чтобы сразу оценить ее ценность и работоспособность, отталкиваясь от задач бизнеса. На такую апробацию можно заложить от квартала до полугода.

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

Lakehouse — аналитическая платформа, поэтому ее смогут поддерживать те же DevOps-инженеры и администраторы баз данных, которые поддерживали прежнюю инфраструктуру. Большинство таких специалистов хорошо знакомы с компонентами, на которых строится Lakehouse. Если у бизнеса нет собственной подготовленной команды для этого направления, всегда можно обратиться к вендорам или другим организациям, которые смогут обучить сотрудников или предоставить свой ресурсный пул.

Как минимизировать риски

Как и в случаях с другими новыми трендовыми технологиями, при знакомстве с Lakehouse может показаться, что эта архитектура станет универсальным решением любых задач. Однако такой подход вряд ли приведет к нужным результатам. Это молодая платформа с большим количеством компонентов, которые периодически меняются. Если распространить ее сразу на все процессы, повысится риск, что что-то пойдет не так. Гораздо лучше поэтапное внедрение.

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

Архитектуру Lakehouse важно проектировать под конкретные классы задач, которые важны для компании. Речь идет не только о функциональных и технологических потребностях, но и об управлении финансами, особенностях инфраструктуры и команды, которой предстоит поддерживать платформу. Только на основе комплексной оценки задач можно правильно заложить фундамент, на котором будет строиться Lakehouse.

Михаил Рощин, заместитель директора отделения управления проектами и архитектуры IBS