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

OSCHINA-MIRROR/mirrors-KSQL

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

KLIP 28 — Введение CREATE OR REPLACE

Автор: agavra | Целевая версия выпуска: 0.12.0; 6.1.0 | Статус: объединён | Обсуждение: https://github.com/confluentinc/ksql/pull/5611

Краткое содержание: CREATE OR REPLACE — это механизм, предназначенный для обеспечения эволюции запросов ksqlDB на месте.

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

Производственные развёртывания баз данных никогда не бывают статичными; они развиваются по мере изменения требований приложений и бизнеса. С этой целью все популярные хранилища данных имеют способы управления и манипулирования существующими данными. Для приложений потоковой обработки пользователь может захотеть изменить своё приложение в результате:

  • Бизнес-требований: требования просто меняются со временем.
  • Эволюции схемы: входящие данные или требуемый вывод были изменены.
  • Оптимизаций: одно и то же приложение может быть выполнено более эффективно (либо пользователем, либо движком).

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

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

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

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

Чтобы лучше понять область применения этого KLIP и любых будущих улучшений, мы определяем таксономию обновлений запросов как любую комбинацию трёх типов характеристик: исходного запроса, обновления и (необязательно) среды.

Категория Характеристика Описание
Запрос Состоятельный Состоятельные запросы поддерживают локальное хранилище
Оконный Оконные запросы поддерживают ограниченное количество состояний, определяемое окном во времени
Объединённый Объединённые запросы считывают данные из нескольких источников
Многоэтапный Многоэтапные запросы содержат промежуточные, невидимые для пользователя темы в Kafka
Недетерминированный Недетерминированные запросы могут давать разные результаты при выполнении идентичного ввода
Простой Запросы без вышеперечисленных характеристик
Обновление Прозрачное Прозрачные обновления изменяют способ вычисления чего-либо (например, улучшение производительности UDF)
Выбор данных Обновления, выбирающие данные, изменяют, какие/сколько событий генерируется
Эволюция схемы Обновления, эволюционирующие схему, изменяют тип выходных данных
Модификация источника Эти обновления изменяют исходные данные, будь то путём модификации JOIN или замены источника
Топология Эти обновления невидимы для пользователя, но изменяют топологию, например, количество подтопологий или порядок операций (например, фильтрация вниз)
Масштабирование Обновления масштабирования изменяют физические свойства запроса, чтобы обеспечить лучшие характеристики производительности
Неподдерживаемое Неподдерживаемые обновления семантически изменяют запрос недопустимым образом. Миграции такого рода не планируются к реализации
Среда Заполнение Заполнение требует, чтобы выходные данные были точными не только с точки во времени, но и с самого начала сохранённой истории
Каскадное Каскадные среды содержат запросы, которые не являются терминальными, а скорее поступают в последующие задачи потоковой обработки
Ровно один раз Среды ровно один раз не допускают дублирования данных или пропущенных событий
Упорядоченное Упорядоченные среды требуют, чтобы одно смещение разграничивало до и после миграции (события не чередуются)
Живое Живые среды описывают запросы, которые не могут позволить себе простои, будь то посредством...

Опубликовать ( 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