Как ускорить извлечение метаданных в Iceberg

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

Аналитические запросы всегда были ресурсоемкими, но проблемы с производительностью возникают, в основном, из-за медленного извлечения метаданных. В этой статье рассматриваются типичные проблемы и предлагается стратегия их решения, которая гарантирует оптимальную производительность запросов к Iceberg.

Низкая скорость извлечения метаданных в Apache Iceberg может серьезно повлиять на работу системы, вызывая следующие проблемы:

1. Низкая производительность при выполнении больших запросов. Запросы, охватывающие большие периоды или крупные наборы данных, часто зависают на этапе планирования заданий в Iceberg. В крайних случаях это приводит к полной сборке мусора, которая вызывает заметные перебои в работе сервиса.
2. Задержки при выполнении небольших запросов. Низкая скорость извлечения данных затрагивает даже небольшие запросы, которые не укладываются в жесткие лимиты (например, время выполнения на p90 должно быть менее 3 секунд).
3. Сложности при операциях с метаданными. Низкая скорость извлечения метаданных влияет не только на запросы, но и на другие операции, использующие метаданные Iceberg. Например, переписывание запросов для материализованных представлений, при котором часто сравниваются планы разных запросов.

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

Для решения проблем с производительностью важно понять причины медленного извлечения метаданных в Apache Iceberg.

1. Издержки при распаковке метаданных. Iceberg хранит метаданные в файлах манифестов в формате Avro с высокой степенью сжатия. Так они занимают меньше места, зато их распаковка и парсинг требуют больше времени. Например, на распаковку файла размером 8 МБ может уходить до одной секунды. Это неприемлемо, если требуется быстро отвечать на запросы.
2. Распаковка и чтение множества файлов Avro. Каждый файл манифеста может содержать ссылки на тысячи файлов данных. Даже если запросу нужны данные всего из нескольких файлов, приходится обрабатывать весь манифест, что еще больше замедляет работу.
3. Зависимость от ресурсов ведущего узла. Извлечение метаданных задействует ресурсы процессора и памяти на ведущем узле. Например, в Селене, которая использует механизм StarRocks, это фронтенд-узел, а в Trino — координатор. При увеличении объема метаданных и параллелизма запросов ведущий узел становится узким местом, что приводит к снижению производительности.

Как оптимизировать производительность, когда метаданных становится слишком много? Давайте рассмотрим варианты решения этой проблемы.

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

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

Хотя параллельная обработка и кэширование эффективно решают задачу быстродействия, для их реализации требуется механизм запросов, рассчитанный на большие и сложные нагрузки. В качестве механизма можно использовать StarRocks. Хранилище данных Селена класса Data Lakehouse построено на основе механизма StarRocks, и полностью использует его функционал и преимущества, связанные с выборкой данных, и предоставляя высокое быстродействие по работе с Apache Iceberg.

StarRocks — это движок запросов с открытым исходным кодом с массовой параллельной обработкой (Massively Parallel Processing, MPP), оптимизированный для рабочих нагрузок, как в хранилище DWH, только в Data Lake. Благодаря распределенной архитектуре он эффективно использует возможности параллельной обработки на современном оборудовании, преодолевая ограничения, с которыми сталкиваются традиционные движки запросов.

Уникальная архитектура StarRocks состоит из фронтенд-узлов и вычислительных узлов, что позволяет распределять рабочие нагрузки и оптимизировать производительность.

• Фронтенд-узлы

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

• Вычислительные узлы

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

StarRocks 3.3 реализует оба описанных выше подхода и выбирает тот, который лучше подходит для текущих запросов:

• Распределенная обработка на вычислительных узлах

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

• Кэширование десериализованных файлов манифестов

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

Рассмотрим, как эти решения работают в реальных условиях

У крупной соцсети были проблемы с обработкой больших нетиповых запросов к данным, содержащим более 300 столбцов и ежедневно пополняющимся более чем на 100 млрд строк. Этот массив данных сопровождается огромным объемом метаданных, из-за чего в старых версиях StarRocks запросы часто зависали на этапе планирования.

После перехода на StarRocks 3.3 распределенное извлечение метаданных позволило линейно масштабировать планирование задач. Ниже приводятся результаты при использовании четырех вычислительных узлов:

В крупной туристической компании возникли проблемы с составлением BI-отчетов из-за медленного извлечения метаданных. Общее время выполнения было допустимым, но более половины его тратилось на планирование задания.

После перехода на StarRocks 3.3 благодаря кэшированию десериализованных файлов Avro удалось сократить среднее время планирования запроса с 1 с до 100 мс, то есть производительность возросла в 10 раз.

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