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

Высокая производительность 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

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

Почему обработка данных из 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.

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

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

Мы рады анонсировать релиз CedrusData 406-1! Ключевым функционалом данного релиза является новый оптимизированный коннектор к Greenplum, который добавляет возможность параллельного сканирования таблиц Greenplum. Так же мы разработали новый удобный способ визуализации планов запросов на основе утилиты PEV2, который позволяет быстрее идентифицировать проблемы производительности.
Более подробно про новый функционал можно прочитать в нашем блоге: https://www.cedrusdata.ru/blog/release-cedrusdata-406-1

Мы рады анонсировать релиз CedrusData 410-1! Ключевым функционалом данного релиза является ускорение запросов к partitioned таблицам Hive. Так же мы добавили новый способ авторизации пользователей в ряде коннекторов. Более подробно про новый функционал можно прочитать в нашем блоге: https://www.cedrusdata.ru/blog/release-cedrusdata-410-1

Всем привет. Последние два месяца наша команда напряженно работала над реализацией ряда критических оптимизаций производительности, которые мы рады представить в вышедшем вчера релизе CedrusData 417-1.
1. Мы добавили локальный дисковый кэш данных, который позволяет сохранять части файлов из вашего озера непосредственно на worker-узлах. Во многих случаях данная оптимизация приводит к кратному ускорению запросов.
2. Мы добавили базовую инфраструктуру нового cost-based оптимизатора на основе алгоритма Cascades. Новый оптимизатор позволяет движке находить более оптимальное разбиение плана на фрагменты по сравнению с оригинальной версией Trino. Мы уже видим хорошее ускорение ряда сложных запросов с большим количеством операторов Join и Aggregation. В последующих версиях мы интегрируем большее количество оптимизаций в новый алгоритм, что позволит в полной мере раскрыть его потенциал.
3. Наконец, мы добавили новый коннектор к Teradata, что позволяет вам использовать CedrusData в еще большем количестве аналитических сценариев.

Более подробно про новый функционал можно прочитать в нашем блоге: https://www.cedrusdata.ru/blog/release-cedrusdata-417-1

Одно из главных требований пользователей к аналитическим движкам - оперативная обработка больших объемов информации. Рассказываем в нашей новой статье, как Trino реализует принципы массивно-параллельной обработки для быстрого выполнения SQL-запросов: https://www.cedrusdata.ru/blog/trino-massively-parallel-processing

Динамические фильтры - это важная оптимизация произодительности Trino, которая значительно ускоряет сканирование данных. Рассказываем в нашем новом блоге, как она работает: https://www.cedrusdata.ru/blog/trino-dynamic-filtering

Мы рады представить релиз CedrusData 422-1.
1. Мы добавили поддержку локального дискового кэша и оптимизировали чтение partitioned таблиц в коннекторе Iceberg. Iceberg коннектор в Trino традиционно отстает по возможностям от коннектора Hive. Данные изменения призваны в значительной степени ускорить работу с Iceberg.
2. Мы добавили возможность сопоставления пользователя с группами безопасности с помощью LDAP. Данное изменение позволяет в значительной степени упростить управление доступом к данным, потому что теперь вы можете определять права доступа для групп, заданных в LDAP, вместо сопоставления пользователей с группами вручную.

Более подробно про новый функционал можно прочитать в документации и нашем блоге: https://www.cedrusdata.ru/blog/release-cedrusdata-422-1

Trino содержит обширный набор функций, которых обычно достаточно для большинства сценариев использования. При решении сложных задач может возникнуть необходимость написания собственных кастомных функций. Для этого пользователи Trino традиционно использовали плагины, которые позволяют добавить собственную функцию, написанную на языке Java. Недостаток данного подхода - необходимость компиляции функции и перезапуска узла.

Начиная с релиза 431, в Trino появилась возможность создания кастомных функций с помощью SQL! Функции могут быть определены как непосредственно в запросе, так и сохранены в каталоге (например, в Hive Metastore) для дальнейшего переиспользования. Документация: https://trino.io/docs/current/routines/introduction.html

Всем привет! В следующую пятницу, 24 ноября, в 18:00 пройдет (кажется) первый в российском сегменте онлайн-вебинар по Trino! Поговорим про реальную практику использования Trino в Avito и особенности работы оптимизатора запросов. Зарегистрироваться можно по ссылке: https://jugrugroup.timepad.ru/event/2675022/?utm_refcode=775f3a3d5cbd6daaf95e43fbc64e971d25ed5a05
Записи докладов позднее будут выложены на YouTube. До встречи на митапе!

Всем привет. Мы выложили видео с прошедшего митапа по Trino: https://www.youtube.com/@cedrusdata/videos
У нас остался ряд вопросов слушателей, на которые мы не успели ответить на митапе. В ближайшие дни мы предоставим ответы.

Всем привет.

Мы рады представить релиз CedrusData 431-3!
1. Добавили новый Vertica коннектор с поддержкой SELECT, DML и DDL выражений.
2. Значительно ускорили работу локального дискового кэша для коннектора Hive. Аналогичные улучшения появятся в коннекторе Iceberg в следующих версиях.
3. Начали системную работу над дополнительными возможностями мониторинга системы. В данной версии появилась возможность просмотра агрегированных статистик доступа к таблицам в источниках: сколько байт и строк было прочитано.
4. Коннектор Teradata: добавили поддержку новых типов данных и расширили возможности pushdown.
Полную информацию и соответствующую документацию можно найти в release notes: https://docs.cedrusdata.ru/latest/release/release-431-3.html

Ожидаем в ближайших версиях:
1. Поддержка Arrow Flight SQL, которая в том числе позволит работать с CedrusData через сторонние ODBC драйвера
2. Финализация поддержки data cache для формата ORC (формально он уже есть в экспериментальном режиме, но надо поработать над производительностью)
3. Production-ready поддержка динамических каталогов
4. Автоматическая дедупликация повторяющихся фрагментов

Всем привет! 27 февраля в 18:00 мы проведем очередной онлайн-митап по Trino! Обсудим использование Trino в Тинькофф и вопросы локального кэширования данных на worker-узлах. Регистрация по ссылке: https://cedrusdata.timepad.ru/event/2754553/?utm_refcode=451a37ec7d9c7e17392334bbf146373c0b3f036f

Всем привет. Мы рады представить релиз CedrusData 431-4!

1. Добавили экспериментальную поддержку протокола Arrow Flight SQL. Теперь вы можете подключаться к CedrusData из любых клиентских приложений, которые реализуют данный протокол, включая сторонние ODBC и JDBC драйвера. Функционал будет окончательно стабилизирован в ближайших версиях. Документация: https://docs.cedrusdata.ru/latest/client/arrow-flight-sql.html
2. Ускорили работу локального дискового кэша в коннекторе Hive для файлов Parquet. Ранее продукт не умел кэшировать ряд структур Parquet (zone maps, bloom filters, dictionary pages), что приводило к лишним запросам в data lake даже при включенном кэше. Начиная с версии 431-4, семантическое кэширование распространяется на все составные части Parquet.

Release notes: https://docs.cedrusdata.ru/latest/release/release-431-4.html

Коллеги, дискуссия интересная, и комментарии увлекательные 🙂
Большая просьба не скатываться в холивары 👍🏼