Обзор SPI

Trino использует архитектуру плагинов для расширения своих возможностей и интеграции с различными источниками данных и другими системами. Плагины должны реализовывать интерфейсы и переопределять методы, определённые в Service Provider Interface (SPI).

Общая информация о плагинах для пользователей доступна в документации по плагинам, а подробности описаны на отдельных страницах для каждого плагина.

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

Код

Исходный код SPI находится в каталоге core/trino-spi в дереве исходного кода Trino.

Метаданные плагина

Каждый плагин определяет точку входа: реализацию интерфейса Plugin. Имя этого класса передаётся в Trino через стандартный интерфейс Java ServiceLoader: classpath содержит ресурсный файл с именем io.trino.spi.Plugin в каталоге META-INF/services. Содержимое этого файла — одна строка с именем класса плагина:

com.example.plugin.ExamplePlugin

Для встроенного плагина, входящего в исходный код Trino, этот ресурсный файл создаётся автоматически, если файл pom.xml плагина содержит следующую строку:

<packaging>trino-plugin</packaging>

Plugin

Интерфейс Plugin — хорошая отправная точка для разработчиков, желающих понять SPI Trino. Он содержит методы доступа для получения различных классов, которые может предоставлять плагин. Например, метод getConnectorFactories() — это верхнеуровневая функция, которую вызывает Trino для получения ConnectorFactory, когда необходимо создать экземпляр коннектора для каталога. Существуют аналогичные методы для объектов Type, ParametricType, Function, SystemAccessControl и EventListenerFactory.

Сборка плагинов через Maven

Плагины зависят от SPI Trino:

<dependency>
    <groupId>io.trino</groupId>
    <artifactId>trino-spi</artifactId>
    <scope>provided</scope>
</dependency>

Плагин использует область видимости Maven provided, поскольку Trino предоставляет классы SPI во время выполнения, и поэтому плагин не должен включать их в сборку.

Существует несколько других зависимостей, предоставляемых Trino, включая Slice и аннотации Jackson. В частности, Jackson используется для сериализации дескрипторов коннекторов, поэтому плагины должны использовать версию аннотаций, предоставляемую Trino.

Все остальные зависимости определяются потребностями конкретного плагина. Плагины загружаются в отдельном classloader, чтобы обеспечить изоляцию и позволить использовать версии библиотек, отличающиеся от тех, что используются в Trino.

Пример файла pom.xml можно найти в примере HTTP-коннектора в каталоге plugin/trino-example-http в исходном коде Trino.

Развёртывание пользовательского плагина

Плагины Trino должны использовать тип упаковки Maven trino-plugin, предоставляемый trino-maven-plugin. При сборке плагина создаётся необходимый service descriptor и используется Provisio для создания ZIP-файла в каталоге target. Этот файл содержит JAR плагина и все его зависимости в виде JAR-файлов и подходит для установки плагина.

Совместимость

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

Например, плагин Trino, скомпилированный для Trino 470, может не работать с более старыми или более новыми версиями, такими как Trino 430 или Trino 490. Это особенно важно при установке плагинов из сторонних проектов, от поставщиков или при собственной разработке.

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

Если исходный код плагина доступен, вы можете определить версию Trino, изучив файл pom.xml. Плагин должен объявлять зависимость от SPI, и, следовательно, совместимость определяется версией Trino, указанной в теге version:

<dependency>
    <groupId>io.trino</groupId>
    <artifactId>trino-spi</artifactId>
    <version>470</version>
    <scope>provided</scope>
</dependency>

Хорошей практикой является использование свойства для значения версии, которое затем объявляется в другом месте файла pom.xml:

...
<dep.trino.version>470</dep.trino.version>
...
<dependency>
    <groupId>io.trino</groupId>
    <artifactId>trino-spi</artifactId>
    <version>${dep.trino.version}</version>
    <scope>provided</scope>
</dependency>