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

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