Демократизация аналитических платформ и при чем здесь Lakehouse

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

От Data Warehouse и Data Lake к Lakehouse: как проходит эволюция архитектуры данных?

Идею Lakehouse можно описать просто: взять все лучшее от Data Warehouse и Data Lake и избавиться от главных недостатков.

Data Warehouse

Обычно реализуются на основе СУБД (система управления базами данных) с поддержкой ACID-транзакций (набор из четырех фундаментальных требований к базам данных: атомарность, согласованность, изоляция, устойчивость). Они заточены под работу со структурированными (табличными) данными с помощью SQL — специального языка запросов для поиска, изменения и управления данными.

Главные минусы: высокая стоимость владения, storage и compute вертикально интегрированы, линейное масштабирование может поддерживаться СУБД, но обычно только симметричными узлами. На практике есть достижимый предел по количеству одновременных пользователей (запросов) и масштабированию кластера, после которого эффективней создавать новый кластер рядом.

Data Lake

Data Lake появились в ответ на проблему дороговизны хранения и обработки в Data Warehouse и позволили значительно дешевле хранить большие массивы данных в любых форматах.

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

Lakehouse

Открытые табличные форматы (Open Table Format, OTF) позволили решить проблему с обновлением таблиц: появилась поддержка ACID-гарантий на уровне отдельной таблицы. Открытость этих форматов дала возможность реализовать совместимость в различных инструментах. Сегодня табличный формат Apache Iceberg поддерживается большинством compute-движков как минимум на уровне чтения данных, а многие также поддерживают запись и обновления.

Разделение storage и compute уже стало архитектурной основой, а не опциональной функцией. Это дает целый ряд преимуществ, благодаря которым можно:

• масштабировать storage и compute независимо;
• применять одновременно несколько вариантов compute;
• запускать, масштабировать и останавливать каждый compute, когда это необходимо.

Все это открывает широкий простор для оптимизации стоимости владения. Особенно если речь идет об аренде мощностей в облаке, но и в on-premise можно получить ощутимую экономию.

Как Lakehouse помогает демократизировать данные?

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

Увеличение количества пользователей не проблема для Lakehouse. Отделив compute от storage, появилась возможность разворачивать несколько compute-движков для определенных групп пользователей или задач, используя при этом единый storage. Это могут быть как различные движки, один движок в нескольких независимых средах (тенантах, например, два кластера Trino). В практике Databorn уже есть несколько кейсов внедрения Lakehouse с более чем 500 параллельными пользователями и domain-based-подходом к совместному использованию ресурсов кластера.

Рост объемов данных тоже уже не так критичен. Storage можно наращивать независимо от compute, организовать несколько уровней хранения (hot/cold) на дисках разных типов, использовать различные алгоритмы сжатия, а также задействовать несколько хранилищ с разными гарантиями отказоустойчивости, требующими соответствующего уровня избыточности данных. Все это открывает новые возможности для оптимизации стоимости владения.

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

Spark как ETL-инструмент позволяет реализовать даже сложные схемы интеграции с источниками (JDBC, REST API, обработка файлов);

Impala, StarRocks или другой высокопроизводительный SQL-движок для работы с табличными данными внутри платформы позволяет быстро получить ответ, используя минимум вычислительных мощностей;

Trino поможет с федеративными SQL-запросами, когда для adhoc требуются дополнительные данные из других систем;

Flink позволит реализовать поточную аналитику с минимальными задержками.

Возможность выбора инструмента под конкретную задачу – базовое требование к современной Lakehouse платформе. Практически в каждом проекте Databorn использовался Spark (интеграционные задачи, задачи обслуживания Iceberg-таблиц), а для adhoc и/или расчетов в Lakehouse – SQL-движок. Примерно в половине проектов применяли сразу несколько SQL-движков. К этому стоит добавить запросы на пилотирование дополнительного SQL-решения – часто клиенты проявляют интерес к относительно молодому StarRocks. Еще в половине кейсов Databorn внедряли механизмы обновления данных в Lakehouse в режиме near-real-time.

Нужно ли отказываться от Data Warehouse?

Часто возникает вопрос, что делать с традиционными Data Warehouse, в которые уже инвестировано немало денег. Для ответа на этот вопрос лучше всего провести аудит текущего решения, который поможет понять сильные стороны и узкие места, а также оценить ожидаемый рост по объему данных, спектру решаемых задач и т. д.

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

• организовать аналитическую песочницу для большого количества пользователей – данные из текущего Data Warehouse реплицируются в Lakehouse, где будут работать аналитики и пользователи с различным набором инструментов, включая возможности для Machine Learning;
• высвободить «дорогое» место в Data Warehouse – данные можно скопировать в Lakehouse, настроить регулярное обновление и оставить в Data Warehouse только последние 1–2 года, а полная история будет доступна аналитикам в Lakehouse;
• разгрузить Data Warehouse – проблемы могут быть не только с дисковым пространством, но и с объемом ежедневных вычислений, поэтому можно вынести расчет наиболее тяжелых витрин и отчетов из Data Warehouse в Lakehouse;
• решать новые задачи – если речь идет об обработке неструктурированных данных или поточной аналитике, Lakehouse для этого подойдет лучше, а новые витрины и отчеты можно сразу реализовывать в нем.

Если же Data Warehouse не справляется, есть критичные проблемы и понимание, что текущее решение не способно выдерживать нагрузку, то замена на Lakehouse может быть лучшим выбором.

Заключение

Lakehouse объединяет преимущества классических проверенных Data Warehouse и относительно более новых Data Lake. На сегодняшний день Lakehouse уже прошел путь от первых пилотов и MVP до запуска в промышленную эксплуатацию в некоторых компаниях – как самостоятельное решение, так и в паре с существующим Data Warehouse. Это позволило на практике убедиться в ряде преимуществ, которые Lakehouse может дать организациям, активно работающим с данными.

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

Именно здесь высокопроизводительный аналитический движок играет ключевую роль в современном стеке Lakehouse. Тот же StarRocks разработан как быстрый слой SQL-запросов как для внутренних данных, так и для открытых форматов озер данных. Это помогает организациям добиваться производительности аналитики уровня классических хранилищ (Data Warehouse), сохраняя при этом открытость и гибкость архитектуры Lakehouse

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