Перейти к содержанию

Kafka Connect source/sink semantics и DLQ

Глубокие темы · Раздел03

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Версии в источниках: Kafka/Connect/Streams 4.1, Debezium 3.3, Flink 1.20.3, Spark 4.0.1 и Airflow 3.1 либо явно названная система. Непроверенные вопросы и ограничения runtime — в журнале (архив рабочего проекта).

Механизм

Worker/connector/task/converter/SMT составляют разные failure boundaries. Source offsets относятся к source protocol, sink offsets — к Kafka partitions. JSON syntax config не доказывает, что plugin установлен и способен выполнять выбранную guarantee.

flowchart TB
  Source[Source protocol] --> Worker[Worker publication and offsets]
  Worker --> Kafka
  Kafka --> Converter[Converter and SMT]
  Converter --> Target[Sink target commit]
  Converter --> DLQ[Supported record error path]
  Target --> Safe[Safe sink offsets]

Пошаговое объяснение

Source records+source progress → worker publication; sink poll → transform → target batch → flush/preCommit → committed offsets. В source EOS режиме transactions/fencing применимы только при connector support и worker settings. Sink semantics проверяют независимо.

Failure scenarios и recovery

Converter error, SMT error, target transient failure и source outage имеют разные error paths. errors.tolerance=all и DLQ settings не означают, что любой source/sink exception будет надёжно перенесён. Sink ErrantRecordReporter capability также plugin-dependent.

Trade-offs и эксплуатация

Retries/backoff и bounded buffering выбирают по target availability и source retention. DLQ owner должен сохранить original coordinates/schema/error, защитить PII, исправить причину и replay с исходной identity. Дубли DLQ допустимы при ambiguous publish.

Практический пример

Connect config + REST validate. Пример source Debezium не приписывает sink DLQ support PostgreSQL connector; generic error settings не включаются слепо ради зелёного dashboard.

Типичные ошибки проектирования

Смешивать source/state/sink boundaries, скрывать failed records и неопределённый исход timeout; применять retry без identity/version и retention contract. Конкретные ограничения разобраны выше.

Вопросы на собеседовании

Почему task FAILED без DLQ record? Ошибка может быть вне поддерживаемого record-error path.

Sink offset можно commit до flush? Только если connector доказал safe target outcome; иначе риск lost effect.

Практические упражнения

Составьте routing matrix malformed bytes/schema mismatch/target timeout/source log gap с retry/DLQ/fatal и reconciliation.

Дополнительные источники