1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/mirrors-KSQL

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
klip-56-schema-id-in-create-statements.md 17 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
gitlife-traslator Отправлено 28.11.2024 07:33 e6dfb69

KLIP 56 — Schema ID in Create Statements

Автор: Хао Ли (@lihaosky) | Целевая версия: 0.24.0; 7.2.0 | Статус: объединён | Обсуждение: проблема, GitHub PR1

Краткое содержание: Этот KLIP вводит key_schema_id и value_schema_id в операторах C*AS и описывает ожидаемое поведение различных команд.

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

Как обсуждалось в этой проблеме, основная мотивация заключается в том, чтобы позволить пользователям указывать key_schema_id или value_schema_id в CAS и CS/CT операторах, чтобы существующие схемы в реестре схем можно было повторно использовать для создания логических схем и сериализации данных для вновь определённого источника данных.

Основные преимущества:

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

Что входит в рамки

  • Исправить ksqlDB, чтобы он не всегда использовал заглавные буквы при преобразовании схем между схемами реестра схем и схемами ksqlDB.
  • Поддерживать свойства KEY_SCHEMA_FULL_NAME и VALUE_SCHEMA_FULL_NAME, чтобы контролировать полное имя схемы для форматов AVRO и PROTOBUF.
  • Поддерживать key_schema_id и value_schema_id в операторах CAS и CS/CT с соответствующей проверкой.
  • Добавить поддержку в ksqlDB для сериализации данных с использованием существующей схемы, определённой в реестре схем, путём указания идентификатора схемы.

Что не входит в рамки

  • Поддержка схемы вывода в ksqlDB при отсутствии элементов таблицы и идентификатора схемы в операторе CS/CT. Поведение этого вывода схемы не изменится.
  • Предупреждение пользователя о возможной логической несовместимости схем и физической несовместимости во время создания потока/таблицы. Поскольку логические поля схемы ksqlDB являются обнуляемыми, а предоставленная схема с использованием идентификатора схемы может не иметь все поля обнуляемыми. Мы не будем выполнять эту проверку совместимости во время создания. Ошибка возникнет, если схемы несовместимы во время вставки значений.

Публичные API

Идентификаторы схем в операторе CAS

CREATE STREAM stream_name WITH (key_schema_id=1, value_schema_id=2, key_format='avro', value_format='avro') AS 
SELECT key, field1, field_2 FROM source_stream
EMIT CHANGES;
CREATE TABLE table_name WITH (key_schema_id=1, value_scheme_id=2, key_format='avro', value_format='avro') AS 
SELECT key, COUNT(field1) AS count_field FROM source_stream
GROUP BY key;

Идентификаторы схем в CS/CT

CREATE STREAM stream_name WITH (kafka_topic='topic_name', key_schema_id=1, value_schema_id=2, 
partitions=1, key_format='avro', value_format='avro');
CREATE TABLE table_name WITH (kafka_topic='table_name', key_schema_id=1, value_schema_id=2, 
partions=1, key_format='avro', value_format='avro');

Дизайн

Проверки, необходимые при наличии _schema_id

  • Команда CS/CT:

    • Соответствующий формат key_format/value_format или свойство format должны существовать, и формат должен поддерживать SCHEMA_INFERENCE (в настоящее время поддерживаются форматы protobuf, avro, json_sr).
    • Схема формата, полученная из реестра схем, должна соответствовать указанному формату в предложении WITH. Например, если формат схемы для идентификатора схемы в реестре схем — avro, но указанный формат в предложении WITH — protobuf, будет выдано исключение.
    • В реестре схем должна существовать схема с указанным идентификатором, иначе будет выдано исключение.
    • Если указаны key_schema_id или value_schema_id, соответствующие ключевые/знаковые элементы таблицы должны быть пустыми.
  • Команда CAS:

    • Для свойств key_format и value_format, если указан _schema_id:
      • Если указано свойство формата, оно должно соответствовать формату, полученному с помощью схемы. ID
  • Если свойство format не указано, оно будет выведено из формата источника запроса и должно соответствовать формату, полученному с использованием идентификатора схемы.

  • Схема с указанным идентификатором должна существовать в реестре схем, иначе будет выдано исключение.

Совместимость Пользователи могут использовать _schema_id с проекцией выбора в команде CAS. Например: CREATE STREAM stream_name WITH (kafka_topic='topic_name', key_schema_id=1, value_schema_id=2, partitions=1, key_format='avro', value_format='avro') AS SELECT * FROM source_stream; В этой ситуации схема из реестра схем должна быть надмножеством проекции выбора, а порядок полей должен совпадать. Обратите внимание, что при проверке совместимости не имеет значения, является ли поле обязательным или необязательным в физической схеме. Это может дать пользователю больше гибкости для использования большего количества схем. В противном случае поля схемы могут быть только необязательными, поскольку все поля в ksqlDB являются необязательными. Также разрешено, чтобы схема из реестра схем имела больше полей. В настоящее время мы не требуем, чтобы эти поля были необязательными. В случае, если требуются дополнительные поля, во время вставки значений может возникнуть ошибка сериализации, поскольку схема значений будет основана на схеме проекции запроса. Мы ожидаем, что пользователи, использующие идентификатор схемы, будут опытными пользователями и будут нести ответственность за обеспечение работоспособности сериализации.

Создание логической схемы ksqlDB и регистрация физической схемы

Схема, указанная с помощью идентификатора схемы, будет найдена и извлечена из реестра схем. Затем она будет переведена в столбцы ksqlDB:

  • Если в операторе создания указано SerdeFeatures UNWRAP, будет создан один столбец ключа или значения с именем ROWKEY или ROWVALUE, и полученная схема будет преобразована в тип ключа или значения.
  • В противном случае ожидается, что полученная схема будет иметь тип STRUCT, а имена полей будут именами столбцов ksqlDB. Схема для каждого поля будет соответствовать типу соответствующего столбца.
  • Если есть неподдерживаемые типы или другие ошибки перевода, оператор завершится ошибкой. Если перевод столбцов успешен:
  • Для оператора CS/CT переведённые столбцы будут добавлены к исходным элементам таблицы оператора и зарегистрированы при выполнении команды DDL.
  • Для оператора CAS будет выполнена проверка совместимости со схемой проекции запроса. Логическая схема созданного потока/таблицы по-прежнему будет схемой проекции запроса, которая отличается от поведения в операторе CS/CT. Затем физическая схема будет зарегистрирована в реестре схем под правильным именем субъекта ksqlDB. Например, в операторе CS/CT полученная физическая схема будет зарегистрирована под субъектом [topic]-key или [topic]-value. Полученная физическая схема регистрируется снова, потому что мы можем выполнить проверку совместимости схем, если создадим другие источники, используя ту же тему.

Путь записи данных

Идентификатор схемы, определённый в операторе создания источника, будет сохранён в ksqlDB. Во время сериализации данных данные сначала будут созданы с исходной логической схемой, а затем перезаписаны в соответствии с физической схемой, полученной с использованием идентификатора схемы. Перезапись данных может завершиться неудачей, если логическая и физическая схемы несовместимы. Например, если поле, определённое в физической схеме, обязательно, но может быть необязательным в ksqlDB, то перезапись с использованием null в качестве значения поля завершится неудачно. После перезаписи данных с использованием физической схемы данные можно сериализовать с помощью сериализатора соответствующего формата. Обратите внимание, что базовый сериализатор будет настроен на использование предоставленного нами идентификатора схемы для поиска схемы и использования физической схемы для сериализации.

Путь чтения данных

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

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

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

  • Схемы корректно проверяются при наличии _schema_id.
  • В утверждениях CAS и CS/CT можно зарегистрировать схемы в разном формате.
  • Данные можно сериализовать/десериализовать для утверждений CAS и CS/CT, если физическая схема совместима с логической схемой.
  • Если физическая схема содержит обязательное поле, значение которого указано как null, данные не могут быть сериализованы.

Обновления документации. Добавьте недавно поддерживаемые свойства в:

  • docs/developer-guide/ksqldb-reference/create-stream.md;
  • docs/developer-guide/ksqldb-reference/create-table.md;
  • docs/developer-guide/ksqldb-reference/create-stream-as-select.md;
  • docs/developer-guide/ksqldb-reference/create-table-as-select.md.

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

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

Ссылки. [1]: Avro Kafka Serializer.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/mirrors-KSQL.git
git@api.gitlife.ru:oschina-mirror/mirrors-KSQL.git
oschina-mirror
mirrors-KSQL
mirrors-KSQL
master