Trino — высокопроизводительный распределённый SQL-движок, с возможностью объединения данных из разнородных источников, таких как: реляционные БД, файловые хранилища, шины данных, inmemory-хранилища, облачные сервисы и тд. Архитектура ориентирована на выполнение аналитических запросов с минимальной задержкой. Т.е. с его помощью можно отправлять SQL-запросы в MongoDB и Kafka, например. Благодаря скорости, развитию, и удобству захватывает популярность у инженеров и аналитиков, работающих с bigdata.

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

Детали о подопечном:

Как хранилище используется кластер ванильный HDFS, состоящий из 100 датанод, объем чистых данных ~ 4 ПБ. Формат — Apache Iceberg. Диски NVMe, cеть внутри кластера 25 ГБит\сек. Серверные платформы OCP: Goldы и EPYC.

Для доступа к данным на этих же серверах развернут кластер Trino 436-й версии, который состоит из 28 воркеров с 1496 ядрами. Объем выделенной оперативной памяти — 4 ТБ. На координаторе — 192 ядра, 1ТБ RAM.

Воркеры разнородны по конфигурации и среде:

8 — на серверах где работает только HDFS
20 — на серверах рядом с HDFS запущен еще и YARN, в который оркестрируются приложения на pyspark

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

Для хранилища метаданных используется Hive Metastore Server. СУБД под хранение метаданных — кластер PostgreSQL. Отдельно отмечу, что даже если сильно будет лень и хочется только ради теста попробовать поднять на Apache Derby — КРАЙНЕ НЕ РЕКОМЕНДУЮ. Потратьте время на PostgreSQL. Серьезно. Обвязка Patroni+PGBouncer не обязательны, если задача — провести эксперименты.

Если времени на это нет — выбейте у бизнеса. Аргумент железный: эта инвестиция позволит сэкономить участникам процесса кучу времени и нервов в будущем.

Также имеются подключения через коннекторы к разным кластерам Clickhouse, Greenplum и Mongo.

Описанная выше конфигурация обрабатывает следующую нагрузку:

Запросы (1 минута)	Запросы (6 часов)	75pth	99pth
10	3500	50 секунд	28 минут

Советы по настройке

Сеть
Отслеживайте количество сетевых подключений и смотрите в логи кластера, скорее всего при росте нагрузок столкнетесь с тем, что Trino плодит много подключений между воркерами. В этом случае крутите вот эти параметры:
sysctl net.core.somaxconn
*.max-requests-queued-per-destination
http-server.threads.max
Буферы и обмен данными
Обратите внимание на следующие параметры. Несмотря на возможность работы со значениями по умолчанию, важно протестировать и адаптировать значения под специфику кластера:
- exchange.max-buffer-sizeexchange.max-response-size
- join-max-broadcast-table-size
- task.max-local-exchange-buffer-size
- sink.max-buffer-size
- sink.max-broadcast-buffer-size
Эти параметры определяют, как данные передаются между узлами при выполнении запросов. Настройка позволит:
- Увеличить пропускную способность и производительность;
- Предотвратить сбои, вызванные нехваткой памяти или сетевого канала;
- Снизить накладные расходы на сжатие, буферизацию и ввод-вывод на диск;
- Облегчить масштабируемость кластера Trino для больших нагрузок.
Посмотрите видео:
Проанализируйте запросы и объемы данных и крутите вот эти параметры под ваши данные и запросы:
exchange.max-buffer-size
exchange.max-response-size
join-max-broadcast-table-size
task.max-local-exchange-buffer-size
sink.max-buffer-size
sink.max-broadcast-buffer-size

Обработка типов из колоночных СУБД
Если необходимо подключить каталоги через коннекторы к Greenplum или Clickhouse, рекомендую сразу выставить следующие параметрыс которые отвечают за представление не поддерживаемых Trino типов данных.
Greenplum, PostgreSQL
Clickhouse
postgresql.array-mapping=AS_JSON
unsupported-type-handling=CONVERT_TO_VARCHAR
clickhouse.map-string-as-varchar=True

Broken pipe в Сlickhouse
Добавьте socket_timeout в строке подключения, в моем случае это 300000:
connection-url=jdbc:clickhouse://<host>:8123/?socket_timeout=300000

Graceful shutdown
Чтобы не ломать текущие запросы при выводе воркера на обслуживание или период деплоя каталога, рекомендую применять graceful shutdown. Для этого нужно немного настроить пользователя: https://trino.io/docs/current/admin/graceful-shutdown.html
После этого можно вызывать команду:
К сожалению, метод работает только на воркерах. Для координатора придется строить схему проверки – есть ли активные запросы?
Метрики и мониторинг
Необязательно заниматься экспортом метрик через JMX-агент. Trino предоставляет HTTP ручку /metrics, которая отдает метрики в Prometheus формате. Доступ к ней требует специальных разрешений для пользователей, идентичных требованиям для graceful shutdown.
Пример дашборда для Grafana: https://github.com/ebogdanov/grafana-trino-dashboard/blob/main/dashboard.json
Этой информации хватает чтобы понять текущее состояние и здоровье кластера
Начиная с 450-ой версии, Trino поддерживает opentracing, но генерирует тяжелые трейсы. 20Гб тестового сервера забивалось за минуты. Если сильно нужно – лучше поднимайте отдельный мини-кластер trino + opentracing внутри которого уже можно спокойно разбираться что происходит
Авторизация
С использованием поисковых машин можно найти общедоступные кластеры, если нет желания записаться в их число, нужно включить авторизацию по паролю. Для этого нужен HTTPS сертификат и вот этот параметры (config.properties):
http-server.https.enabled=true
http-server.https.port=8443
http-server.https.keystore.path=путь к сертификату.pem
Другой путь который можно упомянуть – поставить перед координатором балансировщик, который будет говорить, что якобы обслуживает HTTPS трафик, посылая заголовок: X-Forwarded-Proto: https. За это отвечает параметр:
http-server.process-forwarded=true
Настройка аутентификации через password-authenticator.properties:
password-authenticator.name=file
file.password-file=путь_к_паролям.db
Добавление пользователей осуществляется с помощью команды:
```
htpasswd -b -B -C 10 путь_к_паролям.db $username $PASSWD
```
Именование воркеров
По документации к файлу node.properties можно сделать вывод, что node.id это md5-хэш. Но это не так – здесь возможны значения по регулярному выражению [a-z0-9\-]+. Советую указывать понятные значения, например имена серверов, вроде server-01.

тюнинг java virtual machine:

jvm.properties к которому я пришел

-server
-Xmx96G
-XX:InitialRAMPercentage=80
-XX:MaxRAMPercentage=80
-XX:G1HeapRegionSize=32M
-XX:+ExplicitGCInvokesConcurrent
-XX:+ExitOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-XX:ReservedCodeCacheSize=1024M
-XX:PerMethodRecompilationCutoff=10000
-XX:PerBytecodeRecompilationCutoff=10000
-Djdk.attach.allowAttachSelf=true
-Djdk.nio.maxCachedBufferSize=2000000
-XX:+UnlockDiagnosticVMOptions
-XX:+UseAESCTRIntrinsics
-Dfile.encoding=UTF-8
# Disable Preventive GC for performance reasons (JDK-8293861)
-XX:-G1UsePreventiveGC  
# Reduce starvation of threads by GClocker, recommend to set about the number of cpu cores (JDK-8192647)
-XX:GCLockerRetryAllocationCount=32

Отличия от указанного в документации:

Четко указано максимальное количество memory heap size
Резервирование памяти
Отключено создание дампов памяти при Out Of Memory (они просто забивают диски и не нужны в production кластерах)
Подкручен сборщик мусора (garbage collection)

Выводы и наблюдения

Trino работает со скоростью слабой ноды, из-за этого факта нужно тщательно мониторить железо и хранилище
Тяжелые запросы влияют на легкие. Хорошее видео по этой теме:
Оперативная память не так важна, как CPU. В описанной выше конфигурации потребление не достигает 50%
Расчет выделенных ресурсов на воркеров упирается в бюджет и ожидания пользователей. Поэтому предлагаю начать с малого количества, с учетом постепенного наращивания мощностей
Если кластер тормозит и идеи закончились – проверяйте железо. Снимайте и анализируйте flamegraph. На наших нагрузках вылезали проблемы с сетевыми карты и дисками
Если решились на то, чтобы Trino и YARN разделяли ресурсы сервера – никак не обойтись без cgroups и четкой продуманной политики по ресурсам, иначе шедулер ОС принесет много проблем в стиле: “Коллеги, а что происходит?”, на которые нечего будет ответить
Spill to disk "просто так" включать не нужно – это сильно замедляет запросы и производительность кластера
В Trino Gateway заинтересовала следующая функциональность:
- балансировщик
- обеспечение High Availability при рестартах кластера
- роутинг запросов
- логирование запросов
Думаю, что при необходимости дальнейшего масштабирования, текущий кластер будет разбит на 2 поменьше с роутингом через gateway
В случае, если запросы используют регулярные выражения (например, для Data Quality) и кластер начинает сильно тормозить – обратите внимание на это и попробуйте сменить библиотеку
Маленькие кластера лучше, чем один большой
Мелкие воркеры лучше, чем один большой
Кроме кода и официальной документации, информацию можно найти в Youtube-канале команды разработки Trino и Telegram-канале Trino и CedrusData Chat

Мой опыт эксплуатации кластера Trino