Плагины Presto: один JAR против нескольких JAR - PullRequest
Новая
       8

Плагины Presto: один JAR против нескольких JAR

0 голосов
/ 18 сентября 2018

  • Мой Presto плагин имеет 2 компонента: некоторые UDF s (для базовых MD5 / SHA1 хэширование ) и EventListener (для ведения журнала запросов с использованием FluentD регистратора)

  • Во время разработки( одноузловой Presto кластер), я добавил их в один Плагин класса , связал один JAR и не столкнулся с проблемой

  • Во время развертывания я обнаружил ловушку: UDF s должны быть зарегистрированы на всех узлах , тогда как (в частности) EventListenerдолжен быть зарегистрирован только с главным узлом

Теперь у меня есть две опции

1.Объедините их в один JAR

Мы можем контролировать регистрацию из UDF s / EventListener s через внешний файл конфигурации (различные конфигурации для мастера& подчиненные узлы).По мере добавления UDF с, EventListener с и других SPI с, один JAR в сочетании с измененным конфигурационным файлом достигает желаемого результата.

2.Объедините их в отдельные JAR-файлы

Мы можем создать различные подключаемые классы для UDF s / EventListener и предоставить соответствующие пути к классам в файле META-INF.services/com.facebook.spi.Pluginдо Jenkins.Тогда у нас будут разные JAR с для разных компонентов : один JAR для всех UDF с, один JAR для всех EventListener с и т. Д. Однако по мере увеличения функциональности в будущем,у нас может быть много разных JAR с.

Мои вопросы

  • Каковы плюсы и минусы обоих методов?
  • Есть ли альтернативный подход?

Я в данный момент на Presto 0.194, но скоро обновлюсь до Presto 0.206

1 Ответ

0 голосов
/ 18 сентября 2018

В любом случае работает.Вы можете делать то, что легче для вас.На самом деле есть третий вариант в середине, который состоит в том, чтобы иметь несколько Plugin реализаций в одном JAR (вы бы перечислили все реализации в файле META-INF/services).

EventListener фактически используется в обоихкоординатор и рабочие.События запроса происходят у координатора, а разделенные события - у рабочих.Однако, если вы заботитесь только о событиях запроса, он нужен вам только на координаторе.

Вы можете развернуть плагин событий как на координаторе, так и на рабочих, но настроить его только на координаторе.Код будет использоваться только в том случае, если вы настроите его, добавив файл event-listener.properties со свойством event-listener.name, которое совпадает с именем, которое вы возвращаете в методе EventListenerFactory.getName().

...