KLIP 49 — Добавление семантики исходного потока/таблицы

Автор: Boyang Chen (@boyang) | Целевая версия выпуска: 0.22.0; 7.1.0 | Статус: объединено | Обсуждение: https://github.com/confluentinc/ksql/pull/7474

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

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

У пользователей KsqlDB нет чёткого определения владения таблицами или потоками, которые они создали. В «обычной» базе данных, когда пользователь создаёт таблицу, БД создаёт соответствующие файлы на диске и владеет таблицей. Пользователь может записывать данные в эти таблицы с помощью инструкций INSERT INTO и/или изменять/удалять существующие данные с помощью команд UPDATE и DELETE. Однако таблица не будет изменена никакими другими способами.

Для ksqlDB настройка выглядит совсем по-другому. В частности, пользователь может создать таблицу на основе тем, хранящихся в Kafka, как источника истины. Однако, поскольку нет чёткого владения, определённая таблица может быть изменена с помощью команды INSERT для заполнения её данными. Вставка загрязнит исходный источник данных, который должен принадлежать вышестоящему, например, конвейеру CDC, который заполняет тему.

Во-вторых, при вызове CREATE TABLE фактические данные не материализуются и не готовы к запросам на извлечение. Чтобы устранить эти пробелы, мы хотели бы добавить:

• Синтаксис для добавления потока/таблицы только для чтения с помощью CREATE SOURCE STREAM/TABLE, чтобы сделать источник данных доступным только для чтения. Любая команда вставки будет отклонена, пример ответа об ошибке:

Error: insertion into source stream/table is not allowed

• Кроме того, CREATE SOURCE TABLE станет постоянным запросом, а не просто операцией метаданных, такой как CREATE TABLE, CREATE STREAM или CREATE SOURCE STREAM. Исходная таблица материализует данные входной темы в виде экземпляра RocksDB для интерактивных запросов на серверах KsqlDB.

Что входит в объём работ

• Добавить синтаксис CREATE SOURCE STREAM/TABLE в KSQL
• DESCRIBE ... должен показывать исходные потоки и таблицы как доступные только для чтения
• Добавить материализацию исходной таблицы, чтобы она была доступна для запросов на извлечение
• Сделать исходный поток/таблицу неизменяемым из KSQL, отклоняя запросы на вставку
• Предотвратить удаление исходного потока/таблицы командой DROP ... DELETE TOPIC

Что не входит в объём работ

• Мы не будем пытаться иметь материализацию данных для общей команды CREATE TABLE по умолчанию, так как это потенциально может стать критическим изменением для существующих пользователей CREATE TABLE, которые предполагают, что это лёгкая операция метаданных. Поскольку у нас нет отзывов пользователей о масштабных изменениях, предпочтительнее начать предоставлять пользователю возможность опробовать материализованную таблицу и посмотреть, является ли это хорошей альтернативой или нет, и сделать первую версию предложения обратно совместимой.
• В версии 1 мы не добавим ролевое разрешение на запись для исходного потока/таблицы, хотя это кажется полезным.

Высокоуровневый дизайн

Семантическое изменение

Сначала мы добавим необязательное ключевое слово SOURCE в кодовую базу KSQL, добавив новый синтаксис в sqlBase.g4 для:

• createStream
• createTable

Пример синтаксиса:

CREATE (OR REPLACE)? (SOURCE)? TABLE (IF NOT EXISTS)?...

Сделать исходный поток/таблицу доступным только для чтения

При выполнении вставок KSQL проверит, доступен ли данный поток/таблица только для чтения. Если да, то вставка будет отклонена.

Кроме того, при вызове команды DROP для исходного потока/таблицы в настоящее время пользователь может выполнить DROP STREAM/TABLE [table_name] DELETE TOPIC, чтобы очистить базовую тему, поддерживаемую потоком/таблицей. Это не должно быть разрешено для исходного потока/таблицы, поскольку объект не владеет входными данными. См. эту проблему для получения дополнительной информации.

Материализация исходной таблицы

Основное различие между исходной таблицей и материализованным состоянием в запросе CTAS заключается в том, что мы не заполняем тему приёмника для исходной таблицы, поскольку не ожидается подключения к нисходящему каналу. Это будет учтено при... Время будет потрачено следующим образом (на реализацию и проверку):

1. Добавление синтаксиса SOURCE для потока/таблицы займёт неделю.
2. Внесение изменений в Metastore и CreateSource для источников только для чтения займёт неделю на проверку.
3. Отказ от вставки в таблицу/поток SOURCE займёт неделю.
4. Избегание команды DROP... DELETE TOPIC для удаления базовых топиков займёт 2 дня.
5. Отображение атрибутов только для чтения при DESCRIBE... займёт 3 дня.
6. Материализация исходной таблицы займёт неделю.
7. Добавление доступа к запросам на извлечение для исходной таблицы займёт около 3 дней.
8. Тестирование интеграции займёт 2 недели.

Будет 3 контрольных точки: первая — завершение добавления синтаксиса (#1), что отмечает начало разделения работы между инженерами. Вторая контрольная точка будет означать полную реализацию функционала (#2–6), а третья — завершение документации и тестов.

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

• Добавить новую страницу документа как docs/developer-guide/ksqldb-reference/source-table.md.
• Добавить новую страницу документа как docs/developer-guide/ksqldb-reference/source-stream.md.

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

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

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

Это не функция безопасности, и разрешено CREATE SOURCE TABLE поверх существующей темы, которую используют другие таблицы, без какого-либо влияния на право собственности. В долгосрочной перспективе у нас будет полная модель RBAC для KSQL, логистическая для создания нескольких таблиц по одной теме с разными ролями пользователей. Администратор может создать таблицу с доступом на запись, в то время как роль потребителя должна быть разрешена только создавать таблицы только для чтения.