Общая информация
Релиз CedrusData 405-2 вышел 26 января 2023 года и основан на Trino 405.
Скачайте и запустите из архива:
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.