Trino и CedrusData

Мы рады анонсировать релиз CedrusData 405-2, в котором появился кэш метаданных для Parquet файлов, поддержка OpenTelemetry, а так же возможность анализа производительности запросов, которые были запущены в другом кластере.
Рассказали более подробно про новый функционал в нашем блоге: https://www.cedrusdata.ru/blog/release-cedrusdata-405-2

Почему обработка данных из data lake может быть недостаточно быстрой?

Trino позволяет читать данные в открытых форматах (ORC, Parquet, и т.д.) из HDFS и S3-совместимых хранилищ. Одна из потенциальных проблем — высокие сетевые задержки. Частично проблема решается уменьшением количества читаемых данных за счет оптимизаций filter pushdown и aggregate pushdown. Частично — за счет кэширования данных на worker-узлах (например, Alluxio Cache https://docs.alluxio.io/ee/user/stable/en/core-services/Caching.html). Достаточно ли этого? Не всегда. Современные облачные провайдеры позволяют читать данные по сети со скоростями в сотни мегабайт в секунду. Высокая скорость чтения совместно с filter/aggregate pushdown зачастую приводит к ситуации, когда узким местом становится ... CPU.

Форматы ORC и Parquet позволяют разным системам работать с одной и той же копией данных, упрощая и удешевляя инфраструктуру. В то же время, различные движки, будь то Spark или Trino, используют собственное внутреннее представление данных, оптимизированное под архитектуру конкретного продукта. Конвертация данных из открытых форматов в формат целевой системы является дорогостоящей операцией.

Ниже прикреплен flame graph собранный с помощью Async Profiler (https://github.com/jvm-profiling-tools/async-profiler) при выполнении TPC-DS запроса №7 (https://github.com/apache/impala/blob/master/testdata/workloads/tpcds-unmodified/queries/tpcds-q7.test) на scale factor 1000 в облаке Yandex.Cloud к данным в формате ORC. Видно, что значительная часть времени потрачена на перекодирование данных из формата ORC во внутреннее представление Trino (центральная часть flame graph). В том же время, непосредственно чтение данных из S3-совместимого хранилища занимает считанные проценты. Профили других SQL-запросов могут существенно отличаться. Тем не менее проблема траты ресурсов CPU на многократное перекодирование одних и тех же преимущественно immutable данных повторяется от запроса к запросу.

Мы считаем, что локального кэширования данных в оригинальном формате (как это сделано в Alluxio) недостаточно для оптимальной утилизации ресурсов кластера Trino.

Более продвинутым подходом может быть хранение дополнительной копии данных в формате, оптимизированном для Trino. Учитывая низкую стоимость SSD-дисков и облачных хранилищ, подготовленные для Trino данные можно хранить как на локальных SSD, так и в облаке. Внедрение подобной оптимизации позволит пользователям CedrusData эффективно выполнять запросы, используя меньшее количество дорогостоящих CPU.

Мы будем делиться с вами результатами эксперимента по мере разработки прототипа.

Озеро данных — это набор файлов, как можно выполнить к ним SQL-запрос? Рассказываем в нашем новом блоге, что происходит "под капотом" Trino при выполнении запросов к файлам в формате Parquet: https://cedrusdata.webflow.io/blog/kak-trino-chitaet-dannye-iz-failov-parquet

Высокая производительность Trino обусловлена не только архитектурными решениями, но и постоянной кропотливой работой над точечными улучшениями. Примером такого улучшения в последнем релизе Trino 403 [1] является минорная оптимизация оператора Aggregate [2], которая позволяет избегать проверок на NULL, если колонка заведомо не является nullable. Это изменение уменьшило суммарное время выполнения всех TPC-DS запросов на 1.5%, а для отдельных запросов - на 4-5%. Эффект не очень большой, но и само изменение это буквально несколько строк кода в одном исходном файле. Постоянный поток подобных точечных улучшений оказывает значительное влияние на производительность продукта в целом.

[1] https://trino.io/docs/current/release/release-403.html
[2] https://github.com/trinodb/trino/pull/14567

Trino и CedrusData оптимизированы под работу с файлами в S3-совместимых объектных хранилищах. MinIO - это популярное S3-совместимое объектное хранилище, которое может быть развернуть on-premise. Мы написали пошаговый гайд по интеграции CedrusData с MinIO, который позволит вам быстро развернуть простое, но полностью функциональное озеро данных на вашем локальном компьютере: https://www.cedrusdata.ru/blog/cedrusdata-s3-integration-with-minio

Для работы с озерами данных Trino необходимы метаданные, получаемые из Hive Metastore. Для изучения возможностей Trino и экспериментов вам может потребоваться развернуть Hive Metastore на локальном компьютере. Мы подготовили подробную инструкцию как быстро развернуть локальный экземпляр Hive Metastore и настроить Trino для работы с ним: https://www.cedrusdata.ru/blog/hive-metastore-with-cedrusdata

Channel created