KLIP 7 — Интеграция с Kafka Connect

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

Краткое содержание: предоставить первоклассную интеграцию с Kafka connect для ввода и вывода данных KSQL.

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

Базы данных выполняют три функции:

• ввод данных в базу данных (т. е. вставка данных);
• преобразование данных (т. е. получение новых данных из старых);
• вывод данных (запросы и/или ETL).

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

Пример мотивации

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

Объём работ

Этот KLIP будет:

• определять язык, подобный SQL, для базового управления коннекторами;
• предоставлять руководящие принципы и высокоуровневую архитектуру для интеграции connect-ksql.

Этот KLIP не будет:

• предлагать улучшения для Kafka Connect, такие как облегчение бремени конфигурации, но обсудит, как использовать будущие улучшения Connect.

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

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

Дизайн

Архитектура

Существует три способа интегрировать KSQL с Connect:

1. Запускать их отдельно и предоставлять синтаксис для обмена данными между ними.
2. Встроить Connect в KSQL, управляя отдельными рабочими процессами Connect как частью экосистемы KSQL.
3. Упаковать Connect и KSQL в одну JVM, но просто запустить их на верхнем уровне.

Есть некоторый консенсус в том, что в масштабе KSQL и Connect должны работать как отдельные компоненты. Это означает, что API, который мы разрабатываем, не сможет использовать какую-либо «встроенность» Connect, сводя на нет большинство преимуществ второго подхода.

Тем не менее есть преимущества в упаковке Connect и KSQL в одной JVM для бесшовного взаимодействия с новыми пользователями. А именно, новым пользователям нужно будет загрузить только один пакет, запустить один процесс и поддерживать только одно приложение. Есть некоторые (решаемые) проблемы с этим подходом, но по указанной выше причине синтаксис будет разработан с предположением, что Connect работает как отдельный компонент.

Рекомендуется поддерживать 1 и 3, отложив 2 до тех пор, пока в нём не возникнет необходимость.

Синтаксис

Аналогично DDL и DML, синтаксис Connect разделяет действия, имеющие побочные эффекты, и действия, которые просто объявляют метаданные поверх существующих данных. Это решает две проблемы:

• У одного коннектора может быть много тем, что затрудняет моделирование их как одного оператора.
• Коннектор можно смоделировать разными способами (например, поток/таблица), и жизненный цикл коннектора должен быть независимым от того, как KSQL его интерпретирует.

Есть ещё несколько незначительных моментов, требующих внимания:

• Все команды «DML», вызывающие изменения в Connect, не будут отправляться в тему команд; вместо этого они будут выдаваться на сервере REST (это соответствует шаблону, согласно которому все модификации внешнего состояния не распространяются).
• Некоторые коннекторы будут иметь специфичные для KSQL оболочки, которые позволят упростить настройку и более тесную интеграцию. Эти коннекторы также автоматически будут выдавать операторы DDL для любых создаваемых ими тем. JDBC Primary Key (P1): Поскольку мы ориентируемся на коннектор JDBC как на первую «одобренную» интеграционную точку с KSQL, важно, чтобы опыт работы был как можно лучше. Было бы замечательно, если бы коннектор заполнял первичный ключ строки в записи Kafka без необходимости SMT.

Push updates (P2): Было бы неплохо иметь возможность «подписаться», чтобы получать обновления для любой новой темы/схемы, которая была создана (см. первый пункт), без опроса подключения.

Дополнительные темы

• Обработка ошибок: трудно понять, работает данный коннектор или нет, и ещё труднее отладить, почему он не работает. Это выходит за рамки данного KLIP и должно быть рассмотрено в Connect, а затем представлено внешне. Существует ограниченный набор синхронных ошибок, которые можно легко идентифицировать (например, отсутствующие конфигурации), которые могут быть переданы непосредственно пользователю в момент отправки запроса.

• Управление секретами: некоторые коннекторы (например, коннектор JDBC) могут потребовать передачи секретов для доступа к базе данных. Для MVP безопасность будет наивно полагаться на HTTPS и Connect — потребуется, чтобы пользователи указывали свои секреты в операторе SQL (например, CREATE ... WITH(foo.username='me', foo.password='secret')). Хотя это не идеально, эти команды не будут распространяться на тему команд KSQL. Рекомендуется, однако, заблокировать конфигурацию темы Connect, чтобы предотвратить утечку этих секретов туда. На более позднем этапе итерации KSQL может более тесно интегрироваться с функциями безопасности Connect, передавая токены некоторому менеджеру секретов (например, Vault) и разрешая их только на стороне сервера.

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

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

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

TODO

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

N/A

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

N/A

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

См. раздел «Управление секретами».