Kafka Connect: интеграция без кода

Урок про слой интеграции Kafka: как заливать данные из баз и систем в топики и обратно, не написав ни строки продюсера.

Kafka Connect — фреймворк готовых коннекторов: source-коннекторы тянут данные из внешних систем в топики, sink-коннекторы выгружают из топиков во внешние системы — конфигом, без кода.

Зачем это нужно

90% интеграций однотипны: «забери из Postgres — положи в Kafka», «возьми из Kafka — запиши в ClickHouse/S3/Elasticsearch». Писать и поддерживать такие конвейеры вручную скучно и ненадёжно. Connect даёт это как готовые компоненты, настраиваемые JSON-конфигом, с масштабированием и обработкой сбоев из коробки.

Source и sink

  [ Postgres ] --source connector--o ==Kafka== --sink connector--o [ ClickHouse ]
       (БД -> топик)                              (топик -> хранилище)

Тип	Направление	Примеры
source	система -> Kafka	Debezium (БД), JDBC source, file source
sink	Kafka -> система	JDBC sink, S3 sink, Elasticsearch sink

Пример конфига source-коннектора

{
  "name": "orders-pg-source",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "database.hostname": "pg",
    "database.dbname": "shop",
    "table.include.list": "public.orders",
    "topic.prefix": "shop"
  }
}

Такой конфиг отправляют в REST API Connect — и он начинает лить изменения таблицы orders в топик shop.public.orders.

CDC — захват изменений данных

CDC (Change Data Capture) — техника, при которой каждое изменение строки в БД (insert/update/delete) превращается в событие в Kafka. Debezium читает не саму таблицу опросом, а журнал транзакций БД (WAL в Postgres, binlog в MySQL) — поэтому ловит каждое изменение в порядке, без нагрузки на таблицу и без пропусков.

  Postgres WAL:  INSERT order#7 -> UPDATE order#7 -> DELETE order#7
        |  Debezium читает WAL
        v
  Kafka топик:  {op:c, ...} {op:u, before, after} {op:d, ...}

Как работает под капотом

Connect запускается как кластер worker'ов; коннектор делится на задачи (tasks), которые распределяются по worker'ам — так интеграция масштабируется и переживает падение узла. Connect сам управляет оффсетами source-коннекторов (где он остановился в WAL) и коммитами sink-коннекторов, обеспечивая at-least-once, а с поддерживающими коннекторами — и exactly-once. CDC через лог транзакций даёт надёжный поток изменений: БД становится источником событий для Kafka «бесплатно», без правок в приложении.

Частые ошибки

Городить свой продюсер вместо Connect. Для типовых интеграций Connect надёжнее и без кода.
CDC опросом (polling) вместо чтения лога. Polling грузит БД и пропускает промежуточные изменения; читайте WAL/binlog.
Sink без идемпотентности. При повторах нужен UPSERT по ключу, иначе дубли в приёмнике.

Итоги

Connect — готовые source/sink коннекторы; интеграция настраивается конфигом, а не кодом.
CDC через журнал транзакций БД превращает каждое изменение строки в событие Kafka.
Коннектор делится на задачи по worker'ам — масштабирование и устойчивость из коробки.