sottoБазовые клиентские API
Прикладное взаимодействие строится на трёх API. Producer API публикует записи в топики (см. урок Producer). Consumer API подписывается на топики и читает в группе (см. урок Consumer). AdminClient управляет кластером программно — создаёт/удаляет топики, меняет конфиги, читает метаданные, управляет ACL.
Вокруг этих трёх API построены и инструменты (kafka-console-producer/consumer, kcat), и более высокоуровневые компоненты экосистемы.
Kafka Connect и Debezium
Kafka Connect — фреймворк интеграции Kafka с внешними системами через готовые коннекторы. Source connector тянет данные ВНУТРЬ Kafka (БД, файлы, очереди), sink connector — НАРУЖУ (S3, Elasticsearch, БД). Connect берёт на себя оффсеты, ретраи, масштабирование и работает в distributed-режиме.
Самый известный source — Debezium: реализует change data capture, читая WAL/binlog баз данных (PostgreSQL, MySQL, MongoDB) и публикуя изменения как события в Kafka. Это родной способ сделать CDC и transactional outbox без отдельного relay-сервиса (см. урок saga/CDC).
Kafka Streams
Kafka Streams — БИБЛИОТЕКА (не отдельный кластер) для stream-processing поверх Kafka. Приложение описывает топологию: source-топики → процессоры (map/filter/groupBy/join/aggregate) → sink-топики. Запускается как обычное Java-приложение и легко масштабируется через добавление инстансов в одну consumer group.
Состояние держат state stores (RocksDB локально на диске инстанса + changelog как compacted-топик в Kafka для отказоустойчивости). Поддерживаются windowing (tumbling/hopping/sliding/session) и exactly-once семантика в рамках Kafka (через транзакции producer + read_committed consumer).
ksqlDB
ksqlDB даёт SQL поверх Kafka Streams: CREATE STREAM, CREATE TABLE, SELECT с window-функциями и join'ами. Полезен для быстрого прототипирования потоковой аналитики и обогащения событий без написания Java-кода.
Под капотом — тот же движок Streams. Не «настоящая» БД: запросы выполняются на потоках событий, а не на снимке таблицы; это инструмент потоковой обработки, а не замена OLTP/OLAP.
Schema Registry
Хранит схемы сообщений (Avro, Protobuf, JSON Schema) и обеспечивает их эволюцию с проверкой совместимости (BACKWARD/FORWARD/FULL). Продюсер регистрирует схему под subject (обычно по имени топика), а ID схемы кладётся в каждое сообщение — consumer достаёт ровно ту версию, по которой оно сериализовано.
Так договор producer/consumer превращается в проверяемый контракт: попытка опубликовать несовместимую схему отклоняется на лету. Без Registry эволюция держится только на дисциплине команд и быстро ломается, особенно с независимыми сервисами.
MirrorMaker и multi-DC
MirrorMaker 2 (построен поверх Kafka Connect) реплицирует топики между КЛАСТЕРАМИ Kafka — для геораспределения, миграции и disaster recovery. Маппит топики source → target, переносит конфиги и (опционально) синхронизирует offsets consumer-групп.
Это асинхронная репликация с лагом: данные доедут в DR-кластер с задержкой. Для синхронной кросс-DC репликации Kafka не предназначена — там в ход идут multi-region stretched-кластеры с rack awareness по AZ (см. урок Replication) или специальные конструкции.
Как отвечать на собеседовании
Назовите три уровня экосистемы: клиентские API (Producer/Consumer/Admin), интеграция (Kafka Connect + Debezium для CDC), потоковая обработка (Kafka Streams как библиотека + ksqlDB как SQL поверх неё). Объясните Schema Registry как проверяемый контракт совместимости и MirrorMaker 2 как асинхронную межкластерную репликацию для DR/миграций. Подчеркните: Streams — это обычное приложение, не кластер; ksqlDB — не OLTP-БД.