KLIP 27 — Расширенные параметры конфигурации UDF

Автор: Ханс-Петер Грахсл (@hpgrahsl) | Целевой релиз: ??? | Статус: Одобрено | Обсуждение: GitHub PR

Краткое содержание: Этот KLIP предлагает ввести новый параметр конфигурации для определения свойств функций, которые могут быть общими для группы / семейства (пользовательских) UDF, UDAF и/или UDTF, логически связанных друг с другом.

Мотивация и предпосылки

В настоящее время ksqlDB поддерживает два различных способа настройки (пользовательских) функций на основе записей, определённых в ksql-server.properties:

• либо свойства конфигурации напрямую связаны с одним конкретным классом UDF и применимы к потенциально существующим перегруженным методам — например, ksql.functions.<myudfname>.<mysetting>=foo;

• или мы можем иметь свойства, определённые в специальной области видимости, что делает их доступными глобально — например, ksql.functions._global_.<mysetting>=1234.

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

Что входит в область действия

Этот KLIP направлен на то, чтобы позволить нескольким, но определённо заданным функциям — включая UDF, UDAF и UDTF — совместно использовать свойства конфигурации, отличные от «неправильного использования» глобальной области видимости свойств.

Что не входит в область действия

Область действия этого KLIP — не полная переработка текущих механизмов конфигурации, а модифицированная реализация, поддерживающая совместное использование свойств конфигурации между конкретными (пользовательскими) функциями (UDF, UDAF, UDTF).

Ценность/результат

Основная ценность этого KLIP заключается в том, что пользователи могут легко определять определённые свойства конфигурации, общие для N >= 2 функций. Это можно сделать без указания таких свойств несколько раз, один раз для каждой функции, нуждающейся в них, или без «неправильного использования глобальной области», оба из которых можно считать обходными путями в лучшем случае.

Публичные API

Не должно быть ни изменений в публичных API, ни каких-либо модификаций языка запросов KSQL. В идеале выбранная реализация позволяет обновлять существующие конфигурации / переносить их в более новые версии ksqlDB без изменений для конфигураций, привязанных к конкретным функциям.

Дизайн

Простой подход заключается в расширении метаданных функции и добавлении опции groups к аннотациям @UdfDescription, @UdafDescription и @UdtfDescription, которая принимает список строк. Каждая строковая запись в groups явно определяет имя, используемое для логической группировки функций, для которых необходимо совместно использовать свойства конфигурации.

Учитывая следующий пример:

@UdfDescription(
    name = "someudf",
    description = "...",
    author = "...",
    version = "...",
    groups = {"shareit"/*,"..."*/})
public class SomeUdf implements Configurable {
    //...
}

позволяет настроить UDF с именем someudf с помощью ksql.functions.someudf.my.value.x=foo (базовая конфигурация для одной UDF) или ksql.groups.functions.shareit.my.value.x=foo (групповая конфигурация для нескольких функций, объявляющих одно и то же имя группы(и)). Это различие также делает очевидным, настроены ли свойства конфигурации для отдельных функций или нескольких групповых функций соответственно.

Недостатком подхода, основанного на метаданных, является то, что информация о группе должна быть объявлена в коде. Если это ограничение окажется проблемой, будущее улучшение может позволить явно определить информацию о группе в свойствах конфигурации следующим образом: ksql.groups.define.group_name=...,..., что для приведённого выше примера будет читаться как ksql.groups.define.shareit=someudf.

Преимущества этого дизайна:

• полная обратная совместимость, потому что метаданные groups являются новым параметром;
• наиболее распространённым случаем является настройка одной функции, что означает простоту для пользователей;
• легко добавлять новые конфигурации;
• группировка не является обязательной. План тестирования

Сценарии тестирования и сбоев довольно просты, они сосредоточены только на различных способах установки и чтения свойств конфигурации для функций (UDF, UDAF, UDTF). Нет необходимости в тестировании масштабируемости, нагрузки или производительности, поскольку этот KLIP не влияет на какие-либо критические области в этом отношении.

Этапы и вехи поставки

Определяются менеджером продукта и командой.

Обновления документации

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

Последствия совместимости

Предложение по дизайну предлагает решение, которое не должно привести к критическим изменениям для пользователей. Таким образом, реализация должна осуществляться с обратной совместимостью, чтобы она могла разумно поддерживать «старые» (то есть текущие) и «новые» (то есть предложенные здесь) параметры конфигурации параллельно.

Последствия для безопасности

Не должно быть негативных последствий для безопасности. Напротив, если область _global_ больше не нужно «злоупотреблять», чтобы (случайно) разделить чувствительные свойства конфигурации между всеми функциями, это может даже немного улучшить общую безопасность.

Отклоненные альтернативы

• Альтернатива 1: Один из способов сделать это — ввести подстановочный знак, который можно использовать для сопоставления префикса имён UDF, которые должны иметь возможность совместно использовать определённые свойства конфигурации. Например:

ksql.functions.my_udfgroup_*.some.value.x=foo
ksql.functions.otherudfs_*.other.value.y=1234

означает, что на основе подстановочного знака * параметр some.value.x будет доступен всем UDF, имена которых начинаются с my_udfgroup_. Параметр other.value.y доступен только для всех UDF, имеющих имя, начинающееся с otherudfs_*.

• Альтернатива 2: Свойства конфигурации изначально устанавливаются «без какой-либо области». На данный момент такие свойства вообще недоступны для каких-либо UDF. Только после определения явной области путём предоставления списка со всеми именами UDF такие свойства станут доступными для соответствующих функций. Например,

ksql.functions.some.value.x=foo
ksql.functions._scope_.some.value.x=my_udfgroup_a,otherudfs_b

означает, что исходя из явно определённой области _scope_ для some.value.x, это свойство будет доступно для двух указанных UDF: my_udfgroup_a и otherudfs_b. Параметр недоступен ни для одной UDF, если его область не была определена или пуста.

Конечно, можно также разрешить простое сопоставление с подстановочными знаками или сложные правила регулярных выражений для любой записи имени UDF, определённой в списке _scope_.