Почему Trino такой гибкий: плагинная архитектура SQL-движка, зависимости SPI-интерфейса и последовательность создания пользовательского плагина.
Плагинная архитектура Trino и как она работает
Благодаря настраиваемым коннекторам Trino может подключаться к любым источникам, от реляционных баз данных до NoSQL-хранилищ. При этом коннекторы – это частный случай плагина. С точки зрения проектирования ПО, Trino имеет плагинную архитектуру, когда к единому ядру подключаются модули, каждый из которых реализует одну или несколько функциональных возможностей. Помимо коннекторов, плагины обеспечивают различные виды аутентификации, системы контроля доступа, дополнительные типы и глобальные функции, слушатели событий, кодировки, настройку конфигураций групп ресурсов, сеансовых свойств, обмена данными между узлами кластера и спулинга.
Все это множество плагинов Trino включает как часть бинарных пакетов, которые находятся в папке plugin и загружаются автоматически во время запуска движка. Нужный плагин можно свободно скачать с открытого репозитория как ZIP-архив, который надо разархивировать в отдельную папку каталога plugin на каждом узле кластера. Можно изменить каталог плагина по умолчанию, настроив директорию с помощью переменной конфигурации plugin.dir. Каталог плагина должен содержать только его JAR-файлы. Чтобы использовать плагин, надо перезапустить Trino.
При запуске фреймворк сканирует каталог с плагинами и запускает каждый из них в независимой песочнице, обеспечивая их изоляцию. Благодаря этому каждый плагин может использовать свои версии библиотек, без конфликтов между зависимостями. Если существующих коннекторов недостаточно, можно написать собственный. Однако, для этого надо сперва разобраться с принципами плагинной архитектуры фреймворка.
Будучи написанным на Java, Trino требует, чтобы плагины тоже были написаны на этом языке. Плагины должны реализовывать интерфейсы и переопределять методы, определенные интерфейсом поставщика услуг (SPI, Service Provider Interface).
Каждый плагин определяет точку входа: реализацию интерфейса Plugin. Это имя класса предоставляется Trino через стандартный Java-интерфейс ServiceLoader: classpath содержит файл ресурсов io.trino.spi.Plugin, указанный в каталоге META-INF/services. Содержимое этого файла представляет собой одну строку, в которой указано имя класса плагина, например,
com.example.plugin.ExamplePlugin
Для встроенного плагина, включенного в исходный код Trino, этот файл ресурсов создается всякий раз, когда pom.xmlфайл плагина содержит следующую строку:
<packaging>trino-plugin</packaging>
Интерфейс Plugin содержит методы доступа для извлечения различных классов, которые может предоставить плагин. Все необходимые зависимости и параметры плагина указываются в файле pom.xml, который является ядром Maven-проекта — инструмента автоматизации сборки и управления зависимостями в системах на языке Java. Для создания плагинов Trino используется специальный тип упаковки trino-plugin. Это означает, что проект плагина структурируется и собирается по определённым правилам, которые понимает Maven. Плагин trino-maven-plugin для Maven специально разработан для сборки плагинов Trino. Он обеспечивает необходимые настройки и задачи генерации дескриптора службы – файла, который описывает сервисы и компоненты плагина, позволяя Trino их распознавать и использовать. После выполнения всех сборочных шагов создаётся ZIP-архив, который помещается в каталог target — типичное место выходных результатов сборки в Maven. Этот ZIP-файл включает в себя JAR-файл плагина и другие JAR-файлы с необходимыми зависимостями.
Плагины Trino зависят от SPI, который предоставляет необходимые интерфейсы для разработки плагинов. Поэтому в файле pom.xml следует добавить зависимость trino-spi с областью видимости provided, чтобы обеспечить доступ к необходимым интерфейсам во время компиляции плагина, избегая включения самой библиотеки SPI в финальную сборку. Это гарантирует, что плагин будет совместим с версией SPI, которая уже используется в среде выполнения Trino:
<dependency>
<groupId>io.trino</groupId>
<artifactId>trino-spi</artifactId>
<scope>provided</scope>
</dependency>
Есть и другие зависимости, предоставляемых Trino, включая аннотации Slice для эффективного управления памятью и Jackson для сериализации дескрипторов коннекторов. Плагины должны использовать версию аннотаций, предоставляемую самим фреймворком. Плагины загружаются в отдельный загрузчик классов, чтобы обеспечить изоляцию и позволить плагинам использовать другую версию библиотеки, которую использует движок.
Успешная загрузка, установка и использование плагина зависят от совместимости плагина с целевым кластером Trino. Полная совместимость гарантируется только при использовании той же версии фреймворка, которая использовалась для сборки плагина и развертывания. Поэтому рекомендуется использовать ту же версию, указанную в теге <version> файла pom.xml. Например, плагин, скомпилированный для версии 470, может не работать со старыми или новыми версиями фреймворка, такими как 430 или 490. Это особенно важно при установке плагинов из других проектов. А, поскольку плагины реализуют SPI, который может меняться с каждым выпуском Trino, это также необходимо проверять. По умолчанию нет автоматических проверок на совместимость с SPI во время выполнения, это надо проверять вручную или автоматизировать парсинг файла pom.xml.
Таким образом, процесс разработки своего плагина состоит из следующих действий:
- определение целей и задач плагина, например, подключение к определенному источнику данных;
- настройка среды разработки (JDK 11 или выше) и системы сборки Java-проектов (Maven, Gradle или другие аналоги);
- создание структуры проекта и добавление зависимостей в файл конфигурации сборки (pom.xml для Maven или build.gradle для Gradle);
- реализация функциональности плагина – создание классов и интерфейсов. Например, для коннектора это могут быть классы для управления соединением, выполнения запросов и обработки результатов. Здесь же надо определить параметры конфигурации плагина и обеспечить их обработку. Наконец, следует класс плагина, который регистрирует ранее определенные классы и интерфейсы в Trino.
- тестирование плагина – разработка модульные тестов для проверки отдельных компонентов плагина и интеграционное тестирование тесты с запущенным экземпляром Trino в реальной среде.
- сборка и пакетирование, когда проект компилируется и создается JAR-файл со всеми зависимостями;
- развертывание – размещение плагина в каталоге плагинов, обновление конфигурационных файлов и перезапуск сервера, чтобы изменения вступили в силу.
Как это реализуется на практике, рассмотрим в следующей статье на примере разработки своего плагина, реализующего пользовательский тип данных.
Освоить работу с Trino вы сможете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
