Лекция 14. Apache Kafka

Что такое Kafka

Apache Kafka — distributed event streaming platform (распределённая платформа потоковой обработки событий).

Назначение

• High-performance data pipelines — высокопроизводительные пайплайны данных
• Streaming analytics — потоковая аналитика
• Data integration — интеграция данных
• Mission-critical applications — критически важные приложения

Ключевые свойства Kafka

• Распределённость
• Отказоустойчивость
• Высокая доступность
• Надёжность и согласованность данных
• Высокая производительность (пропускная способность)
• Горизонтальное масштабирование
• Интегрируемость

Немного истории

• Разработана в LinkedIn
• Программный код опубликован в 2011 году
• С 2012 под крылом Apache
• Реализована на Scala и Java
• Название придумал Jay Kreps в честь Franz Kafka («известный писатель»)
• Девиз: «Kafka — a system optimized for writing»

Задача, которую решает Kafka

Без Kafka (прямые соединения между сервисами):

Сложности при количестве сервисов:

• Надёжность и гарантия доставки
• Подключение новых получателей
• Отправители знают получателей
• Техническая поддержка
• Интеграция разных стеков

С Kafka (брокер посередине):

Удобства:

• Надёжность и гарантия доставки
• Подключение новых получателей
• Отправители не знают получателей
• Техническая поддержка
• Интеграция разных стеков

Основные сущности Kafka

1. Broker — сервер Kafka
2. Zookeeper — координатор кластера
3. Message (Record) — сообщение
4. Topic / Partition — топик и его партиции
5. Producer — отправитель
6. Consumer — получатель

Kafka Broker (Kafka Server / Kafka Node)

Функции брокера

• ✅ Приём сообщений
• ✅ Хранение сообщений
• ✅ Выдача сообщений

Kafka-кластер

• Масштабирование — несколько брокеров работают вместе
• Репликация — данные дублируются между брокерами

Zookeeper

Zookeeper — координатор кластера Kafka. Его функции:

• ✅ Состояние кластера
• ✅ Конфигурация
• ✅ Адресная книга (data)
• ✅ Выбор Controller
• ✅ Обеспечение консистентности

Controller

Один из брокеров кластера становится Controller — отвечает за управление и принятие решений в кластере. Выбирается через Zookeeper.

Kafka Message (Record / Event)

Сообщение представляет собой key-value пару с дополнительными полями:

Kafka Topic — поток данных (stream of data)

Topic — это поток данных, через который сообщения проходят от продюсеров к консумерам.

Свойства Topic

• ✅ FIFO — гарантирует порядок (ordering support)
• Сообщения сохраняются последовательно

Partitions — разделение топика

Топик разделяется на партиции для:

• ✅ Ускорения чтения/записи данных (параллелизация)

FIFO per partition — порядок гарантируется внутри партиции, но не во всём топике (если партиций больше одной).

Topic placement by Brokers (в кластере)

Партиции топика размещаются на разных брокерах:

Topic A: partition 0, 1, 2
  Broker 1: P0
  Broker 2: P1
  Broker 3: P2

⚠️ Возможна несбалансированность размещения партиций топика — учитывается количество всех партиций всех топиков на брокере.

При наличии нескольких топиков (B, C, D и т.д.) кафка пытается балансировать нагрузку между брокерами.

Storage for Kafka Topic — где хранятся данные

Данные топика хранятся в файловой системе брокера, в каталоге /logs:

• Для каждой партиции — отдельная директория
• Внутри директории несколько файлов:
  • .log — сами сообщения
  • .index — индекс по offset
  • .timeindex — индекс по timestamp

Segments — сегменты файлов

Файлы партиции разбиваются на сегменты:

• Имя файла соответствует start offset сегмента
• В timeindex хранится max message timestamp сегмента

Это нужно для:

• Эффективного управления хранением
• Быстрого поиска по offset и timestamp
• Удаления старых данных

Data removing from Kafka Topic — удаление данных

⚠️ Операция удаления данных не поддерживается!

✅ Поддерживается автоматическое удаление данных по TTL (time-to-live):

• Удаляются целиком сегменты партиций, не отдельные сообщения
• Условие: segment timestamp expired → to delete

Data Replication — надёжность данных и отказоустойчивость

Если один брокер падает — данные его партиций потеряны!

Решение: replication-factor

Set replication-factor (>1)

• Каждая партиция реплицируется на несколько брокеров
• При падении одного брокера — данные сохраняются на других

Но просто с репликацией не всё так просто. Есть нюансы.

Master-Slave — гарантия согласованности данных

При replication-factor: 3 — у каждой партиции есть 3 копии.

Leader и Followers

• Kafka Controller назначает Leader-реплики
• ⚠️ Операции чтения и записи производятся ТОЛЬКО с Leader-репликой

producer → Leader → consume

Остальные реплики (Followers) только синхронизируются с Leader.

Несбалансированность Leaders

⚠️ Возможна проблема несбалансированности Leaders и Followers — все запросы к одному брокеру, остальные «отдыхают».

Kafka должна перебалансировать Leader’ов между брокерами.

Data sync between Leader and Followers

Followers must fetch data from Leader

Followers периодически запрашивают данные у Leader (fetch periodically).

Проблема: что если Leader упал?

Кто теперь Leader? И все ли данные у него есть?

Если новым Leader станет Follower с отстающими данными — данные могут быть потеряны. Это ненадёжно!

Решение — In-Sync Replicas (ISR)

ISR — реплики, которые синхронизированы с Leader.

Настройка: min.insync.replicas = 3

• Запись считается успешной только когда она прошла на минимум N ISR
• ISR Follower — надёжный кандидат на Leader

Если запись прошла в Leader + ISR(1) + ISR(2) — данные надёжны.
Если новый Leader выбирается из ISR — данные не теряются.

Kafka Producer — отправка сообщений

Kafka Producer — высокопроизводительный отправитель сообщений.

acks — гарантии доставки

Параметр acks определяет, чего ждёт продюсер:

Delivery semantic support

Kafka поддерживает три семантики доставки:

• At most once — не более одного раза (сообщение может потеряться)
• At least once — хотя бы один раз (сообщение может дублироваться)
• Exactly once — ровно один раз (через idempotence)

Конвейер обработки сообщения Producer’ом

Что происходит при send message:

1. fetch metadata — Producer получает метаданные от Zookeeper:
   • cluster state
   • topic placement
   • ⚠️ Expensive operation — блокирует send() до получения метаданных (или таймаут 60 сек)
2. serialize message — сериализация ключа и значения через key.serializer и value.serializer (например, StringSerializer)
3. define partition — определение партиции:
   • explicit partition — явное указание
   • round-robin — по очереди
   • key-defined — key_hash % n
4. accumulate batch — накопление в батч (контролируется batch.size и linger.ms)
5. compress message — сжатие
6. send to Broker — отправка на брокер

Producer пытается группировать сообщения в батчи для эффективности, чтобы лучше использовать сеть и хранилище.

Kafka Consumer — получение сообщений

Kafka Consumer — высокопроизводительный получатель.

Принцип работы

Consumer сам запрашивает сообщения у брокера (poll messages). В отличие от ActiveMQ — Kafka не пушит сообщения консумерам.

Подключение Consumer

Consumer подключается к Leader-репликам всех партиций топика.

⚠️ В один поток это может быть медленно, если партиций много.

Consumer Group

Чтобы распараллелить чтение — Consumer’ы объединяются в Consumer Group через <group.id>:

• Каждая партиция читается одним Consumer’ом в группе
• Сообщения распределяются между Consumer’ами группы
• При добавлении/удалении Consumer’а — происходит rebalance

Пример:

• Topic с 4 партициями
• Consumer Group из 4 Consumer’ов
• Каждый Consumer читает свою партицию

Kafka Consumer Offset

Offset — last consumed message by Group (последнее прочитанное сообщение группой).

Что хранится

Для каждой Consumer Group хранится:

Эта информация хранится в специальном системном топике: __consumer_offsets.

Зачем offsets

• Если Consumer перезапускается — он продолжает с последнего обработанного offset
• Если приходит новая группа — она может начать с начала топика или с последнего offset

Kafka Consumer Offset commit

После обработки сообщения нужно закоммитить offset.

Типы коммитов

А как же exactly once?

Custom offset management — управление offset вручную, в той же транзакции, что и обработка. Тогда:

• Обработка и commit в одной транзакции
• При неуспехе — откат всего
• Exactly once — не пропустили, не дублировали

Kafka Consumer Offset missing

Что если Consumer Group неактивна долгое время?

Параметры

• max inactive period — offsets.retention.minutes (по умолчанию 7 дней)
• После истечения — offsets удаляются из __consumer_offsets

После активации группы

После повторной активации используется параметр auto.offset.reset:

Kafka performance — почему так быстро?

Итоги: Apache Kafka

• ✅ Kafka — очень популярна
• ✅ Kafka — надёжное проверенное решение
• ✅ Kafka — высокопроизводительный инструмент
• ✅ Kafka — широковещательная с упорядочиванием (FIFO per partition)
• ✅ Kafka — интегрируема со всеми тулами
• ✅ Kafka — гибкая в конфигурации
• ⚠️ Kafka — нужно понимать нюансы (acks, ISR, offset management, rebalance)