Общая информация

Релиз CedrusData 405-2 вышел 26 января 2023 года и основан на Trino 405.

Запуск из архива:


wget https://downloads.cedrusdata.ru/releases/cedrus-405-2.tar.gz \
  && tar -xf cedrus-405-2.tar.gz \
  && cedrus-405-2/bin/launcher run

Запуск из Docker:


docker run -d --rm --name cedrus-server -p 8080:8080 \
  cr.yandex/crpjtvqf29mpabhmrf1s/cedrus:405-2

Ключевые изменения

Кэш метаданных файлов Parquet

Документация: https://docs.cedrusdata.ru/405-2/connector/hive.html#hive-parquet-metadata-cache-configuration.

Parquet это открытый колоночный формат хранения данных. Файлы Parquet содержат метаданные, которые описывают расположение отдельных частей данных в файле. CedrusData и Trino активно используют метаданные Parquet, что бы ограничить количество зачитываемых данных (project pushdown, filter pushdown, aggregate pushdown). Исторически чтение метаданных было реализовано в Trino как отдельный синхронный шаг перед непосредственным чтением данных. Таким образом, вне зависимости от природы запроса, для каждого Parquet файла необходимо сделать как минимум один сетевой запрос к озеру данных, что увеличивает latency и количество потенциально платных вызовов API облачного хранилища.

Так как файлы в озере данных изменяются достаточно редко, можно закэшировать относительно компактные метаданные, сократив количество удаленных вызовов. Данный функционал уже достаточно давно реализован в Presto для файлов Parquet и ORC, но не реализован в Trino.

В релизе CedrusData 405-2 мы добавили кэш метаданных (футеров). При первом доступе к файлу Parquet на данном узле мы читаем метаданные и сохраняем их в кэш фиксированного размера (512 Mb по умолчанию). При последующих обращениях к файлу мы проверяем актуальность метаданных, сравнивая закэшированный и текущий modification time файла. Если зэкэшированный футер актуален, мы возвращаем его без осуществления удаленного вызова. Пользователи могут регулировать размер кэша, задавать TTL, смотреть статистики кэша через JMX, а так же отключать кэш для конкретных запросов с помощью параметра сессии.

Данный функционал обеспечивает наиболее значительный прирост производительности для запросов, которые используют оптимизацию aggregate pushdown (например, функции `COUNT(*)`, `MIN` и `MAX` при отсутствии группировки или группировке по partitioning колонке). При использовании кэша метаданных Parquet совместно с кэшем файловых дескрипторов (`hive.file-status-cache-tables`), в ряде случаев вы можете выполнять агрегационные запросы без удаленных вызовов к озеру данных.

Попробуйте следующую конфигурацию для вашего каталога Hive:


hive.file-status-cache-tables=*
hive.file-status-cache-expire-time=1h
cedrusdata.parquet.metadata-cache.enabled=true

На данный момент кэш метаданных Parquet поддержан только для Hive коннектора. В дальнейшем мы расширим поддержку на коннекторы Iceberg, Hudi и Delta Lake.

Поддержка OpenTelementry

Документация: https://docs.cedrusdata.ru/405-2/admin/tracing.html.

OpenTelemetry - это популярный открытый стандарт для распределенного трейсинга и мониторинга. Мы добавили поддержку OpenTelemetry в CedrusData, которая позволяет трассировать SQL запросы. В текущей реализации CedrusData собирает спаны запросов (query), стадий (stage), и отдельных задач (task). Данные спаны позволяют удобно визуализировать процесс выполнения запроса и определять проблемные этапы.

Интеграция основана на OpenTelemetry SDK Autoconfigure, конфигурация осуществляется через системные переменные JVM. Поддержаны три типа экспортеров: `logging`, `otel` и `jaeger`.

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

Внешняя история запросов

Документация: https://docs.cedrusdata.ru/405-2/admin/properties-query-management.html#cedrusdata-query-external-history-path.

Trino сохраняет историю выполнения запросов в памяти координатора, что позволяет анализировать производительность уже выполненных запросов через UI. Однако, при перезапуске координатора история оказывается утеряна, что существенно сужает возможности ретроспективного анализа проблем производительности. В CedrusData 405-2 мы добавили возможность отображения истории запросов, которые были запущены в другом координаторе или кластере.

Сначала необходимо сохранить JSON-представление интересующего вас запроса в файл. Это можно сделать через UI (выбрать запрос и нажать кнопку "JSON", или воспользоваться нашим новым системным представлением `system.runtime.cedrusdata_query_json`). Далее вы можете перенести JSON-файлы запросов в локальную файловую систему нового координатора, и указать в `config.properties` путь к директории с JSON-файлами:


cedrusdata.query-external-history.path=/путь/к/директории/

После запуска координатора исторические запросы будут отображены в UI на вкладке "Finished".

Теперь вы можете обмениваться JSON файлами запросов со своими коллегами или нами для независимого анализа проблем производительности. В Querify Labs мы активно используем данный функционал для выявления перспективных улучшений продукта.

Дальнейшие планы

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

Свяжитесь с нами, что бы узнать больше о CedrusData и Trino.