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. Сеть

   Отслеживайте количество сетевых подключений и смотрите в логи кластера, скорее всего при росте нагрузок столкнетесь с тем, что Trino плодит много подключений между воркерами. В этом случае крутите вот эти параметры:

   sysctl net.core.somaxconn

   *.max-requests-queued-per-destination

   http-server.threads.max

2. Буферы и обмен данными

   Обратите внимание на следующие параметры. Несмотря на возможность работы со значениями по умолчанию, важно протестировать и адаптировать значения под специфику кластера:

   • 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

3. Обработка типов из колоночных СУБД

   Если необходимо подключить каталоги через коннекторы к Greenplum или Clickhouse, рекомендую сразу выставить следующие параметрыс которые отвечают за представление не поддерживаемых Trino типов данных.

   Greenplum, PostgreSQL	Clickhouse
   postgresql.array-mapping=AS_JSON unsupported-type-handling=CONVERT_TO_VARCHAR	clickhouse.map-string-as-varchar=True

4. Broken pipe в Сlickhouse

   Добавьте socket_timeout в строке подключения, в моем случае это 300000:

   connection-url=jdbc:clickhouse://<host>:8123/?socket_timeout=300000

5. Graceful shutdown

   Чтобы не ломать текущие запросы при выводе воркера на обслуживание или период деплоя каталога, рекомендую применять graceful shutdown. Для этого нужно немного настроить пользователя: https://trino.io/docs/current/admin/graceful-shutdown.html

   После этого можно вызывать команду:

   К сожалению, метод работает только на воркерах. Для координатора придется строить схему проверки – есть ли активные запросы?

6. Метрики и мониторинг

   Необязательно заниматься экспортом метрик через 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 внутри которого уже можно спокойно разбираться что происходит

7. Авторизация

   С использованием поисковых машин можно найти общедоступные кластеры, если нет желания записаться в их число, нужно включить авторизацию по паролю. Для этого нужен 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

8. Именование воркеров

   По документации к файлу node.properties можно сделать вывод, что node.id это md5-хэш. Но это не так – здесь возможны значения по регулярному выражению [a-z0-9\-]+. Советую указывать понятные значения, например имена серверов, вроде server-01.

9. тюнинг 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

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

   1. Четко указано максимальное количество memory heap size

   2. Резервирование памяти

   3. Отключено создание дампов памяти при Out Of Memory (они просто забивают диски и не нужны в production кластерах)

   4. Подкручен сборщик мусора (garbage collection)

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

1. Trino работает со скоростью слабой ноды, из-за этого факта нужно тщательно мониторить железо и хранилище

2. Тяжелые запросы влияют на легкие. Хорошее видео по этой теме:

3. Оперативная память не так важна, как CPU. В описанной выше конфигурации потребление не достигает 50%

4. Расчет выделенных ресурсов на воркеров упирается в бюджет и ожидания пользователей. Поэтому предлагаю начать с малого количества, с учетом постепенного наращивания мощностей

5. Если кластер тормозит и идеи закончились – проверяйте железо. Снимайте и анализируйте flamegraph. На наших нагрузках вылезали проблемы с сетевыми карты и дисками

6. Если решились на то, чтобы Trino и YARN разделяли ресурсы сервера – никак не обойтись без cgroups и четкой продуманной политики по ресурсам, иначе шедулер ОС принесет много проблем в стиле: “Коллеги, а что происходит?”, на которые нечего будет ответить

7. Spill to disk "просто так" включать не нужно – это сильно замедляет запросы и производительность кластера

8. В Trino Gateway заинтересовала следующая функциональность:

   • балансировщик

   • обеспечение High Availability при рестартах кластера

   • роутинг запросов

   • логирование запросов

   Думаю, что при необходимости дальнейшего масштабирования, текущий кластер будет разбит на 2 поменьше с роутингом через gateway

9. В случае, если запросы используют регулярные выражения (например, для Data Quality) и кластер начинает сильно тормозить – обратите внимание на это и попробуйте сменить библиотеку

10. Маленькие кластера лучше, чем один большой

11. Мелкие воркеры лучше, чем один большой

12. Кроме кода и официальной документации, информацию можно найти в Youtube-канале команды разработки Trino и Telegram-канале Trino и CedrusData Chat