экспертный материал
Демократизация аналитических платформ и при чем здесь Lakehouse
В условиях стремительного роста объемов корпоративной информации компании сталкиваются с необходимостью оптимизации IT-бюджетов при сохранении гибкости аналитических процессов. В этой статье мы, компания Databorn, как IT-интегратор с многолетним опытом на рынке и экспертизой в реализации проектов любого масштаба, разберем особенности разных подходов к организации аналитики данных внутри корпоративной платформы и расскажем, как архитектура Lakehouse помогает справиться с ключевыми вызовами демократизации данных.
Сегодня успех компаний все больше зависит от того, насколько эффективно рядовые сотрудники — маркетологи, финансовые и продуктовые аналитики, продакт-менеджеры и HR-специалисты — могут использовать данные внутри корпоративной аналитической платформы для ежедневных решений. Работа с данными перестала быть прерогативой исключительно IT-департаментов.
Демократизация меняет привычные подходы работы с данными, но порождает и новые вызовы. Одним требуются данные в реальном времени — суточные выгрузки уже не устраивают. Другим нужны логи с коммутационного оборудования разных производителей. Приходится подключать все больше систем-источников, накапливать глубокую историю изменений и наращивать объемы хранения. Увеличивается количество пользователей, расширяется спектр задач, которые должна решать платформа. А вместе с этим растет совокупная стоимость владения — и этот рост нужно контролировать, чтобы бюджет не превысил запланированные лимиты.
Эволюционный путь: от Data Warehouse и Data Lake к Lakehouse
Идею Lakehouse можно описать достаточно просто: взять все лучшее от Data Warehouse и Data Lake и избавиться от главных недостатков.
Data Warehouse
Обычно реализуются на основе СУБД с поддержкой ACID-транзакций, заточены под работу со структурированными (табличными) данными посредством SQL-запросов.
Главные минусы: высокая стоимость владения, storage и compute вертикально интегрированы, линейное масштабирование может поддерживаться СУБД, но обычно только симметричными узлами. На практике есть достижимый предел по количеству одновременных пользователей (запросов) и масштабированию кластера, после которого эффективней создавать новый кластер рядом.
Также в Data Warehouse есть сложности с эффективной работой над неструктурированными данными (логи, изображения, видео, аудио и т. д.) и реализацией потоковой аналитики.
Data Lake
Data Lake появились в ответ на проблему дороговизны хранения и обработки в Data Warehouse и позволили значительно дешевле хранить большие массивы данных в любых форматах.
В первых версиях compute-инженерам приходилось писать программы, которые запускались распределенно в кластере с помощью фреймворков. Но такой подход был слишком сложным для аналитиков и других бизнес-пользователей. Потребность в снижении порога входа и ускорении обработки привела к появлению и развитию целого ряда альтернативных вычислительных движков, включая SQL-движки. Именно благодаря зрелости Data Lake мы сегодня имеем выбор между Spark, Trino и Impala — как полноценными compute-движками для Lakehouse.
Кроме традиционной batch-обработки, активно формировался и спрос на инструменты для работы с непрерывными потоками данных, способные обеспечить минимальные задержки и гарантии доставки. Так, в этой же экосистеме появились и Spark Streaming, и Flink, и некоторые другие инструменты для поточной аналитики.
Однако были и минусы. Одной из ключевых проблем были сложности с обновлением таблиц: потребители могли получить неконсистентные данные, пока процесс обновления не завершился, — не говоря уже о том, что сам процесс мог прерваться из-за сбоя.
Lakehouse
Открытые табличные форматы (Open Table Format, OTF) позволили решить проблему с обновлением таблиц: появилась поддержка ACID-гарантий на уровне отдельной таблицы. Открытость этих форматов дала возможность реализовать совместимость в различных инструментах. Сегодня табличный формат Apache Iceberg поддерживается большинством compute-движков как минимум на уровне чтения данных, а многие также поддерживают запись и обновления.
Разделение storage и compute уже стало архитектурной основой, а не опциональной функцией. Это дает целый ряд преимуществ, благодаря которым мы можем:
Data Warehouse
Обычно реализуются на основе СУБД с поддержкой ACID-транзакций, заточены под работу со структурированными (табличными) данными посредством SQL-запросов.
Главные минусы: высокая стоимость владения, storage и compute вертикально интегрированы, линейное масштабирование может поддерживаться СУБД, но обычно только симметричными узлами. На практике есть достижимый предел по количеству одновременных пользователей (запросов) и масштабированию кластера, после которого эффективней создавать новый кластер рядом.
Также в Data Warehouse есть сложности с эффективной работой над неструктурированными данными (логи, изображения, видео, аудио и т. д.) и реализацией потоковой аналитики.
Data Lake
Data Lake появились в ответ на проблему дороговизны хранения и обработки в Data Warehouse и позволили значительно дешевле хранить большие массивы данных в любых форматах.
В первых версиях compute-инженерам приходилось писать программы, которые запускались распределенно в кластере с помощью фреймворков. Но такой подход был слишком сложным для аналитиков и других бизнес-пользователей. Потребность в снижении порога входа и ускорении обработки привела к появлению и развитию целого ряда альтернативных вычислительных движков, включая SQL-движки. Именно благодаря зрелости Data Lake мы сегодня имеем выбор между Spark, Trino и Impala — как полноценными compute-движками для Lakehouse.
Кроме традиционной batch-обработки, активно формировался и спрос на инструменты для работы с непрерывными потоками данных, способные обеспечить минимальные задержки и гарантии доставки. Так, в этой же экосистеме появились и Spark Streaming, и Flink, и некоторые другие инструменты для поточной аналитики.
Однако были и минусы. Одной из ключевых проблем были сложности с обновлением таблиц: потребители могли получить неконсистентные данные, пока процесс обновления не завершился, — не говоря уже о том, что сам процесс мог прерваться из-за сбоя.
Lakehouse
Открытые табличные форматы (Open Table Format, OTF) позволили решить проблему с обновлением таблиц: появилась поддержка ACID-гарантий на уровне отдельной таблицы. Открытость этих форматов дала возможность реализовать совместимость в различных инструментах. Сегодня табличный формат Apache Iceberg поддерживается большинством compute-движков как минимум на уровне чтения данных, а многие также поддерживают запись и обновления.
Разделение storage и compute уже стало архитектурной основой, а не опциональной функцией. Это дает целый ряд преимуществ, благодаря которым мы можем:
- масштабировать storage и compute независимо, расширяя только то, в чем есть необходимость, либо, наоборот, сокращать;
- использовать storage той реализации, которая лучше всего отвечает требованиям, включая варианты от облачных провайдеров при реализации Lakehouse в облаке или гибридном исполнении;
- использовать compute, наиболее подходящий для конкретной задачи: batch/ streaming, adhoc/ELT;
- применять одновременно несколько вариантов compute;
- запускать, масштабировать и останавливать каждый compute, когда это необходимо.
Все это открывает широкий простор для оптимизации стоимости владения. Особенно если речь идет об аренде мощностей в облаке, но и в on-premise можно получить ощутимую экономию.
Многие compute-движки, изначально созданные с оглядкой на Data Lake, сегодня развиваются с учетом тенденций Lakehouse платформ: добавлена поддержка работы с объектными хранилищами (S3-совместимыми) и открытыми табличными форматами, а также поддержка развертывания в Kubernetes.
Демократизации данных и Lakehouse
Lakehouse отлично вписывается в тенденцию демократизации данных, предлагая эффективные решения для растущих нагрузок и сложности запросов.
Увеличение количества пользователей не проблема для Lakehouse. Отделив compute от storage, мы получили возможность разворачивать несколько compute-движков для определенных групп пользователей или задач, используя при этом единый storage. Это могут быть как различные движки, один движок в нескольких независимых тенантах (например, два кластера Trino).
Увеличение количества пользователей не проблема для Lakehouse. Отделив compute от storage, мы получили возможность разворачивать несколько compute-движков для определенных групп пользователей или задач, используя при этом единый storage. Это могут быть как различные движки, один движок в нескольких независимых тенантах (например, два кластера Trino).
Некоторые движки позволяют поднять несколько координаторов для обработки большого количества одновременных сессий. В практике Databorn уже есть несколько кейсов внедрения Lakehouse с более чем 500 параллельными пользователями и domain-based-подходом к совместному использованию ресурсов кластера.
Рост объемов данных тоже уже не так критичен. Storage можно наращивать независимо от compute, организовать несколько уровней хранения (hot/cold) на дисках разных типов, использовать различные алгоритмы сжатия, а также задействовать несколько хранилищ с разными гарантиями отказоустойчивости, требующими соответствующего уровня избыточности данных. Все это открывает новые возможности для оптимизации стоимости владения.
Ни разнообразие типов данных, ни широта решаемых задач не становятся ограничениями.
В единое хранилище можно загружать файлы любых форматов, а под каждую задачу — выбирать оптимальный вычислительный движок:
Возможность выбора инструмента под конкретную задачу — базовое требование к современной Lakehouse платформе. Каждый инструмент имеет свою нишу: спектр задач, в которых он наиболее эффективен.
Практически в каждом проекте Databorn использовался Spark (интеграционные задачи, задачи обслуживания Iceberg-таблиц), а для adhoc и/или расчетов в Lakehouse — SQL-движок. Примерно в половине проектов применяли сразу несколько SQL-движков. К этому стоит добавить запросы на пилотирование дополнительного SQL-решения — часто клиенты проявляют интерес к относительно молодому StarRocks. Еще в половине кейсов мы внедряли механизмы обновления данных в Lakehouse в режиме near-real-time.
Безопасность — еще один важный аспект. Помимо шифрования каналов и данных на дисках, аутентификации и базовой авторизации пользователей, сегодня в Lakehouse-платформах можно реализовывать ролевой доступ с возможностью фильтраций и маскирования данных.
При выборе решения важно убедиться, что:
Рост объемов данных тоже уже не так критичен. 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. Еще в половине кейсов мы внедряли механизмы обновления данных в Lakehouse в режиме near-real-time.
Безопасность — еще один важный аспект. Помимо шифрования каналов и данных на дисках, аутентификации и базовой авторизации пользователей, сегодня в Lakehouse-платформах можно реализовывать ролевой доступ с возможностью фильтраций и маскирования данных.
При выборе решения важно убедиться, что:
- соответствующие правила можно применить к тем compute-движкам, которые будут доступны пользователям;
- при наложении ограничений доступности данных (например, при добавлении маскирования) пользователи не могут обойти их, обратившись напрямую к файлам в хранилище. То есть определенные ограничения должны применяться не только на уровне compute, но и иметь соответствующее отображение в используемом хранилище.
Замена или дополнение
Часто возникает вопрос, что делать с традиционными Data Warehouse, в которые уже инвестировано немало средств. Для ответа на этот вопрос лучше всего провести аудит текущего решения, который поможет понять сильные стороны и узкие места, а также оценить ожидаемый рост по объему данных, спектру решаемых задач и т. д. В таких случаях может быть полезна внешняя экспертиза — взгляд специалистов, знакомых со множеством аналитических платформ.
Если Data Warehouse закрывает основные потребности бизнеса, а отдельные задачи эффективнее решаются с помощью Lakehouse, эти архитектуры могут работать параллельно. Например, когда необходимо:
Если 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.
По мере того, как все больше предприятий модернизируют свои платформы данных, мы уверены, что будущее будет определяться не каким-то одним движком или монолитной системой хранения. Его определят открытые, совместимые архитектуры, позволяющие подбирать правильный инструмент под каждую конкретную нагрузку.
По мнению сообщества StarRocks, ценность концепции Lakehouse заключается не только в том, где именно хранятся данные, но и в том, насколько легко и эффективно их можно использовать. Открытые форматы таблиц, раздельное масштабирование хранения и вычислений, а также совместимость различных движков создают необходимый фундамент. Однако демократизация данных становится реальностью только тогда, когда аналитики, инженеры и бизнес-команды могут запрашивать проверенные данные с помощью привычного SQL, получая интерактивную скорость работы и предсказуемую стоимость.
Именно здесь высокопроизводительный аналитический движок играет ключевую роль в современном стеке Lakehouse. Тот же StarRocks разработан как быстрый слой SQL-запросов как для внутренних данных, так и для открытых форматов озер данных. Это помогает организациям добиваться производительности аналитики уровня классических хранилищ (Data Warehouse), сохраняя при этом открытость и гибкость архитектуры Lakehouse.
По мере того, как все больше предприятий модернизируют свои платформы данных, мы уверены, что будущее будет определяться не каким-то одним движком или монолитной системой хранения. Его определят открытые, совместимые архитектуры, позволяющие подбирать правильный инструмент под каждую конкретную нагрузку.