Итоги модуля: ksqlDB

Модуль 08 завершён. Вы прошли путь от SQL-абстракций ksqlDB через CSAS/CTAS и push/pull queries к production-деплойменту. Теперь — систематизация: что когда применять, и как ksqlDB соотносится с Kafka Streams из Модуля 07.

Что мы изучили

Урок 01: Streams и Tables в ksqlDB

ksqlDB — SQL-интерфейс поверх Kafka Streams. Каждое SQL-выражение компилируется в Kafka Streams топологию и выполняется как стандартное Streams-приложение. STREAM = KStream (append-only события), TABLE = KTable (актуальное состояние по ключу). value_format определяет сериализацию: JSON без схемы, AVRO/PROTOBUF через Schema Registry.

Урок 02: CSAS/CTAS и Push/Pull queries

CSAS (CREATE STREAM AS SELECT) — непрерывная трансформация потока. CTAS (CREATE TABLE AS SELECT) — непрерывная агрегация с материализацией. Push query (EMIT CHANGES) — непрерывная подписка на новые данные, соединение открыто. Pull query — точечный lookup по ключу, только для материализованных TABLE, соединение закрывается сразу.

Урок 03: Windowed Aggregations и UDFs

WINDOW TUMBLING — фиксированные непересекающиеся окна. WINDOW HOPPING — перекрывающиеся окна. WINDOW SESSION — динамические окна по пробелам активности. GRACE PERIOD — продление приёма запоздавших записей. UDF (скаляр), UDAF (агрегат), UDTF (один-ко-многим) — деплоятся как Java JAR в ext/.

Урок 04: ksqlDB в Production

Headless mode (ksql.queries.file) — обязателен для production. Capacity planning: CPU + диск (RocksDB) + RAM на каждый persistent query. HA через Kafka Streams rebalancing + standby replicas. Мониторинг через JMX и Prometheus. CREATE SOURCE/SINK CONNECTOR — управление Connect коннекторами из SQL.

Kafka Streams vs ksqlDB: матрица решений

Критерий	Kafka Streams	ksqlDB
Язык	Java / Kotlin / Scala	SQL
Деплоймент	JAR встроен в ваше приложение	Standalone-сервер кластер
Flexibility	Полный DSL + Processor API	SQL-подмножество
Sliding windows	Да (`SlidingWindows`)	Нет
Foreign key join	Да (KTable-KTable FK join)	Ограниченно
Внешние вызовы	Да (через Processor API)	Нет (только SQL)
Пользовательская логика	Processor API (любая Java)	UDF (только Java)
CI/CD интеграция	JAR + стандартный деплоймент	SQL-файл + headless mode
Embedding в микросервис	Да (библиотека)	Нет (отдельный сервер)
Идеально для	Сложная обработка событий, микросервисы	SQL-разработчики, быстрый прототип, стандартные трансформации

Когда использовать ksqlDB

Используйте ksqlDB, если:

Команда предпочитает SQL и не хочет писать Java-код.
Задачи — стандартные: фильтрация, маппинг, GROUP BY агрегации, TUMBLING/HOPPING/SESSION windowing.
Нужна быстрая итерация: написал SQL → мгновенно видишь результат.
Пайплайн прозрачен: источник → трансформация → сток, без сложной бизнес-логики.
Команда уже использует Confluent Platform и хочет единый SQL-интерфейс для всего (Connect + processing + sink).

Используйте Kafka Streams, если:

Нужны sliding windows (SlidingWindows) — в ksqlDB их нет.
Требуются сложные joins, недоступные в ksqlDB SQL.
Нужно встроить processing в микросервис (JAR без внешнего процесса).
Логика обработки требует Processor API: внешние вызовы, сложные состояния, punctuators.
Производительность критична: Kafka Streams позволяет тонкую настройку, которую SQL не даёт.
Команда опытна в Java/Kotlin и предпочитает типобезопасный DSL.

Взаимосвязь модулей

Модуль 05 (Kafka Connect)
    |
    | CREATE SOURCE/SINK CONNECTOR
    v
Модуль 06 (Schema Registry)
    |
    | value_format = 'AVRO'/'PROTOBUF'
    v
Модуль 07 (Kafka Streams)  ------> Модуль 08 (ksqlDB)
    |                                   |
    | KStream, KTable                   | STREAM, TABLE
    | WindowedBy, state stores          | WINDOW TUMBLING/HOPPING
    | Processor API                     | CSAS, CTAS
    |                                   | Push / Pull queries
    |                                   |
    v                                   v
              Kafka Cluster (топики, партиции, репликация)
                          |
                        Модуль 09 (Security)

Оба модуля (07 и 08) описывают разные подходы к одному и тому же: stream processing поверх Kafka. ksqlDB компилирует SQL в Kafka Streams топологии — это не конкуренты, а уровни абстракции.

Ключевые SQL-паттерны модуля

Паттерн 1: Event enrichment (обогащение событий)

-- Регистрация источников
CREATE STREAM orders (order_id VARCHAR KEY, customer_id VARCHAR, amount DOUBLE)
  WITH (kafka_topic='orders', value_format='JSON');

CREATE TABLE customers (customer_id VARCHAR PRIMARY KEY, name VARCHAR, tier VARCHAR)
  WITH (kafka_topic='customers', value_format='AVRO');

-- Непрерывное обогащение через KStream-KTable join
CREATE STREAM enriched_orders AS
  SELECT o.order_id, o.amount, c.name, c.tier
  FROM orders o
  LEFT JOIN customers c ON o.customer_id = c.customer_id
  EMIT CHANGES;

Паттерн 2: Real-time aggregation с materialized view

CREATE TABLE hourly_revenue AS
  SELECT
    product_category,
    SUM(amount) AS total_revenue,
    COUNT(*) AS order_count,
    WINDOWSTART AS win_start
  FROM orders
  WINDOW TUMBLING (SIZE 1 HOUR, GRACE PERIOD 10 MINUTES)
  GROUP BY product_category
  EMIT CHANGES;

-- Точечный запрос текущего состояния
SELECT * FROM hourly_revenue WHERE product_category = 'electronics';

Паттерн 3: Headless production deployment

# queries.sql в Git-репозитории
# CI/CD: при изменении queries.sql — рестарт ksqlDB с новым файлом
docker run -d \
  -e KSQL_BOOTSTRAP_SERVERS=kafka:9092 \
  -e KSQL_KSQL_QUERIES_FILE=/etc/ksqldb/queries.sql \
  -v ./queries.sql:/etc/ksqldb/queries.sql \
  confluentinc/cp-ksqldb-server:7.9.0

Будущее ksqlDB: индустриальный сдвиг к Apache Flink

Любой, кто строит новый streaming-проект в 2026 году, обязан учитывать один факт: Confluent в 2024–2025 годах фактически свернул активную разработку ksqlDB и сделал ставку на Apache Flink. Это не формальный EOL — ksqlDB всё ещё поставляется в Confluent Platform 8.x, патчи безопасности выпускаются — но это стратегический сдвиг, который меняет рекомендованный путь для новых пайплайнов.

Хронология сдвига. В январе 2023 Confluent купил Immerok — стартап, основанный изначальной командой коммитеров Apache Flink. Через несколько месяцев был запущен Confluent Cloud for Apache Flink как first-class managed-сервис: глубокая интеграция Kafka topic = Flink table, Schema Registry как catalog, единый governance-слой. На Kafka Summit и Current 2024–2025 продуктовый roadmap сосредоточен вокруг Flink SQL Workspaces, Tableflow (Iceberg-output), AI-агентов поверх Flink. ksqlDB на тех же мероприятиях упоминается всё реже.

Что это значит технически. Apache Flink (с релизом Flink 2.0 в 2025 году) утвердился как индустриальный стандарт streaming SQL. У него более полный SQL-диалект (SQL:2016 features, true sliding windows, MATCH_RECOGNIZE для CEP), значительно более широкий connector-ecosystem (поверх Kafka — также Kinesis, Pulsar, Iceberg, Delta Lake, Hudi, JDBC CDC), горизонтальное масштабирование лучше чем у ksqlDB, и активное community Apache Software Foundation. Open-source репозиторий ksqlDB наблюдает резкое падение коммитов с 2024 года.

WARNING

Это не значит, что ksqlDB сегодня сломан или его нельзя использовать. Существующие production-пайплайны на ksqlDB продолжают работать. Но для новых проектов рекомендация индустрии однозначна: смотрите в сторону Flink SQL. Если ваша команда выбирает между Flink и ksqlDB для проекта 2026 года — Flink почти всегда правильный выбор.

Migration considerations для существующих ksqlDB-пайплайнов. Если у вас уже работает ksqlDB и встаёт вопрос миграции:

CSAS/CTAS-запросы в ksqlDB концептуально транслируются в CREATE TABLE AS SELECT Flink SQL, но синтаксис отличается: EMIT CHANGES в ksqlDB → continuous query семантика в Flink (по умолчанию). WINDOW TUMBLING (SIZE 1 HOUR) → TUMBLE(TABLE, DESCRIPTOR(rowtime), INTERVAL '1' HOUR).
State stores. ksqlDB использует RocksDB через Kafka Streams. Flink использует свой RocksDB-state-backend. При миграции state не переносится автоматически — нужно либо backfill из source-топиков, либо параллельный запуск с переключением.
UDF / UDAF / UDTF. Java UDF из ksqlDB не запускаются в Flink без переписывания: разные API (@Udf аннотация в ksqlDB → ScalarFunction/TableFunction/AggregateFunction в Flink Table API).
Pull queries (точечные lookup’ы по materialized table) в Flink заменяются на Lookup joins или внешний key-value store, в который Flink пишет результат агрегации.
Incremental migration. Реалистичный путь: запускайте Flink параллельно с ksqlDB на тех же source-топиках, переводите downstream-консьюмеров на Flink-output, постепенно выводите ksqlDB-запросы из эксплуатации. Полная одномоментная миграция почти всегда перебор.

Когда ksqlDB всё ещё имеет смысл. Маленькая команда, уже сидящая на Confluent Platform, с простыми SQL-трансформациями и нежеланием поднимать Flink-кластер. Прототипы и spike-проекты — kafka-streams-app + ksqlDB действительно дают скорость от идеи к рабочему пайплайну. Существующие production-пайплайны, которые работают и не требуют новых фич — мигрировать просто ради миграции не нужно.

Где смотреть дальше. Confluent Cloud for Apache Flink documentation (docs.confluent.io/cloud/current/flink), Apache Flink SQL reference, Flink Forward 2025 talks по миграции с ksqlDB, и опубликованные case-studies компаний Riskified и Booking — они описывали свои миграции в публичных блогах.

Что дальше

Модуль 09: Security — TLS, SASL, ACL, RBAC. Защита Kafka-кластера, Schema Registry, Kafka Connect и ksqlDB. Аутентификация продюсеров и консьюмеров. Authorization через ACL и Confluent RBAC.

После Module 09 у вас будет полная картина Kafka-экосистемы: архитектура (01), продюсеры (02), консьюмеры (03), внутренности Kafka (04), Connect (05), Schema Registry (06), Kafka Streams (07), ksqlDB (08), Security (09).

Проверка знанийKnowledge check

Команда разрабатывает систему real-time обнаружения мошенничества. Требования: (1) сложные правила с вычислением скользящего среднего за последние 5 минут, (2) обращение к внешнему ML-сервису для scoring, (3) высокая производительность. Kafka Streams или ksqlDB?

ОтветAnswer

Kafka Streams — правильный выбор по нескольким причинам. Во-первых, sliding windows (скользящее среднее за 5 минут) реализуется через SlidingWindows.ofTimeDifferenceWithNoGrace(Duration.ofMinutes(5)) в Kafka Streams DSL — в ksqlDB нет SQL-аналога WINDOW SLIDING. Во-вторых, обращение к внешнему ML-сервису (HTTP-запрос в процессинге) невозможно в ksqlDB SQL — это задача для Processor API или Kafka Streams с внешним вызовом в процессоре. В-третьих, performance-critical путь требует тонкой настройки, которую даёт Kafka Streams (custom SerDes, batch processing, RocksDB tuning). ksqlDB подойдёт для вспомогательных задач: alerting на явные пороги, агрегация метрик по tumbling/hopping windows, enrichment из reference tables.