KLIP-5: Внутренние схемы для KSQL Engine

Автор: hjafarpour | Целевая версия: 5.4 | Статус: обсуждается | Обсуждение:

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

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

В настоящее время, когда пользователи объявляют схему для потока или таблицы, KSQL engine использует предоставленную схему для выполнения обработки запросов к данным потока или таблицы. Это означает, что движок использует те же имена в полях схемы для обращения к полям схемы в вычислениях, таких как оценка выражений или фильтрация. Мы генерируем Java-код для оценки таких выражений, который накладывает определённые ограничения на именование переменных. Однако требование, чтобы схемы пользователей соответствовали требованиям именования переменных в Java, ограничивает способность KSQL обрабатывать данные любого пользователя. Хотя в форматах Avro и Delimited у KSQL не будет проблем, поскольку имена полей схемы уже соответствуют текущим требованиям KSQL, при обработке контента в формате JSON KSQL столкнётся с ограничениями. В формате JSON имена полей не обязательно соответствуют требованиям KSQL, и допустимое сообщение JSON может иметь имена полей, которые не могут быть приняты KSQL.

Кроме вышеуказанного требования, имена полей в KSQL также должны соответствовать требованиям именования идентификаторов в SQL, чтобы операторы анализировались правильно.

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

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

Рассмотрим пример, где мы хотим объявить поток на топике со значениями в формате JSON. Вот пример значения записи в этом топике:

{"@ID": 0, "@NAME": "foo", "MESSAGE.AMOUNT": 0.0, "SELECT": "bar"}

Как видите, два имени полей начинаются с «@», а третье включает «.» в имени поля. Четвёртое имя поля — «SELECT», которое является зарезервированным словом в KSQL. В настоящее время мы не можем объявить поток или таблицу на этом топике, так как его содержимое не соответствует требованиям к именованию полей KQSL. Однако мы сможем использовать заключённые в кавычки идентификаторы, которые поддерживаются нашим парсером, чтобы объявить поток или таблицу на этой теме и написать запросы над объявленным потоком или таблицей. Предположим, мы объявили поток на этой теме под названием foo. Ниже будет оператор DDL:

CREATE STREAM foo
  (“@ID” BIGINT, “@NAME” STRING, “MESSAGE.AMOUNT” DOUBLE, "SELECT" STRING)
WITH
  (KAFKA_TOPIC=’foo’, VALUE_FORMAT = ‘JSON’);

KSQL добавит указанный выше поток с объявленной схемой в свой метастор. Теперь предположим, что мы хотим создать новый поток из foo, используя следующий оператор CSAS:

CREATE STREAM bar AS
SELECT “@ID”, lowercase(“@NAME”) AS “@NAME”, “MESSAGE.AMOUNT” * 100 AS “AMOUNT.BY.100”, "SELECT"
FROM foo
WHERE “MESSAGE.AMOUNT” < 1;

KSQL сгенерирует внутреннюю схему для foo перед обработкой указанного запроса и перепишет запрос на основе внутренней схемы. Затем он будет использовать переписанный запрос для обработки записей из топика.

Область применения

• Поддержка заключённых в кавычки идентификаторов в операторах DDL и DML. Только идентификаторы полей схем находятся в области действия этого предложения, а идентификаторы имён потоков/таблиц — вне области действия.
• Создание внутренних схем для внешних схем.
• Переписывание запросов для использования внутренних схем. Обработка с использованием внутренних схем

Значение/возврат

Это устранит текущее требование о том, чтобы имена полей записей в темах Kafka соответствовали внутренним требованиям KSQL. С этим KLIP KSQL сможет обрабатывать темы с любым соглашением об именовании.

Публичный API

Единственная видимая пользователю часть этого KLIP — это поддержка цитируемых идентификаторов, которые будут такими же, как стандартные цитируемые идентификаторы в SQL. Объявление и использование внутренних схем не видны пользователям и являются частью внутренней работы механизма KSQL.

Дизайн

Внутренняя схема будет использоваться только при выполнении DML-операторов. Когда механизм получает DML-оператор (CSAS, CTAS, INSERT INTO, SELECT), он строит внутреннюю схему с допустимыми именами полей для данной исходной схемы(ы). Это делается путём расширения текущего класса LogicalSchema путём добавления к нему внутренней схемы. Имена полей внутренней схемы могут следовать предопределённому протоколу, так что механизм KSQL будет строить одну и ту же внутреннюю схему для заданной внешней схемы каждый раз. В качестве примера рассмотрим случай, когда мы используем индекс поля в схеме в качестве префикса к константному строковому значению для построения имён полей внутренней схемы. Рассмотрим предыдущий пример, где наша внешняя схема имеет четыре поля:

(“@ID” BIGINT, “@NAME” STRING, “MESSAGE.AMOUNT” DOUBLE, "SELECT" STRING)

Предполагая, что константная строковая приставка для построения полей внутренней схемы — «COL_», внутренняя схема для вышеуказанной схемы будет следующей:

(COL_0 BIGINT, COL_1 STRING, COL_2 DOUBLE, COL_3 STRING)

Обратите внимание, что между полями из внешней схемы и полями из внутренней схемы существует следующее взаимно однозначное соответствие:

• «@ID» <==> COL_0;
• «@NAME» <==> COL_1;
• «MESSAGE.AMOUNT» <==> COL_2;
• "SELECT" <==> COL_3.

В случае вложенных полей мы можем применить тот же подход к вложенным полям внутри типов ARRAY, MAP и STRUCT.

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

Например, рассмотрим следующий запрос ещё раз:

CREATE STREAM bar AS
SELECT “@ID”, lowercase(foo.“@NAME”) AS “@NAME”, “MESSAGE.AMOUNT” * 100 AS “AMOUNT.BY.100”, "SELECT"
FROM foo
WHERE “MESSAGE.AMOUNT” < 1;

С учётом вышеуказанного сопоставления механизм запишет этот запрос следующим образом:

CREATE STREAM bar AS
SELECT FOO_COL_1 AS “@ID”, lowercase(FOO_COL_1) AS “@NAME”, FOO_COL_2 * 100 AS “AMOUNT.BY.100”, FOO_COL3
FROM foo
WHERE FOO_COL_2 < 1;

Механизм KSQL сможет выполнить вышеуказанный запрос, поскольку все идентификаторы соответствуют требованиям к именованию идентификаторов в KSQL. Обратите внимание, что KSQL уже добавляет имя источника к имени поля автоматически, что устраняет двусмысленность в случае наличия нескольких источников (таких как запросы Join) с одинаковыми именами полей.

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

(“@ID” BIGINT, “@NAME” STRING, “AMOUNT.BY.100” DOUBLE, "SELECT" STRING)

Механизм будет использовать сгенерированную внутреннюю схему для создания приложения потоков. Десериализаторы из исходного потока или таблицы будут использовать внешнюю схему для извлечения полей и создания объекта GenericRow, но после этого внутренняя схема будет использоваться для обработки записей для запросов.

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

Механизм должен проверять, соответствуют ли имена полей результирующей схемы требованиям формата приёмника. Эта проверка должна выполняться во время компиляции запроса. Например, если формат приёмника... Речь идёт об Avro, и если имена полей в результирующей схеме не соответствуют требованиям к именованию Avro, то движок KSQL не должен выполнять запрос.

Обратите внимание, что во всех сообщениях об ошибках или логах KSQL всё ещё должны использоваться внешние имена схем, поскольку пользователь не знает о внутренних схемах.

План тестирования

Будут добавлены тесты для поддержки цитируемых идентификаторов. Это включает тесты для идентификаторов с точками, зарезервированных слов, таких как «SELECT» или «ROWKEY», чувствительности к регистру.

Все существующие тесты для разных этапов обработки запросов действительно проверяют правильность использования внутренних схем, так как внутренние схемы будут использоваться для такой обработки.

Тесты, которые проверяют промежуточные схемы, такие как в QTT, должны быть обновлены, поскольку промежуточные схемы будут основаны на внутренних.

Документация

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

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

Внутренние схемы нарушат совместимость для запросов с отслеживанием состояния, поскольку хранилище состояний в настоящее время хранит значения на основе внешних имён схем.

Влияние на производительность

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

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

Никаких последствий для безопасности.