Kafka и streaming на собеседовании Data Engineer
Зачем DE спрашивают про Kafka
Apache Kafka — стандарт для distributed event streaming. Используется как message broker, как буфер между системами, как backbone для real-time pipelines. На собесе Data Engineer Kafka почти всегда — особенно в командах, работающих с real-time данными (fraud detection, recommendations, monitoring).
Уровень: junior — знает basics produce/consume; middle — понимает partitions, consumer groups, offsets; senior — exactly-once, schema evolution, multi-DC, capacity planning.
Архитектура Kafka
Broker — узел кластера. Хранит топики, обрабатывает produce/consume.
Topic — категория сообщений. Можно представить как лог.
Partition — единица параллелизма топика. Сообщения в одной partition строго упорядочены, между partitions — нет.
Producer — приложение, пишущее в Kafka.
Consumer — приложение, читающее из Kafka.
Consumer group — группа consumer-ов, делящих работу. Каждая partition назначается одному consumer в группе.
Replication — каждая partition реплицируется на N broker-ов. Один — leader (читает/пишет), остальные — followers (sync).
ZooKeeper / KRaft — координация кластера. В новых версиях ZooKeeper заменён на KRaft (Kafka Raft).
Partitions и параллелизм
Partition — это:
- Единица упорядоченности. Внутри partition order строгий.
- Единица параллелизма. Больше partitions = больше параллельных consumer-ов.
- Единица масштабирования. Партиции можно распределить по brokers.
Сколько partitions делать?
- Минимум = ожидаемый максимум consumer-ов в группе
- На каждый broker — десятки partitions (но не сотни — overhead в metadata)
- Помни: увеличить partitions можно, уменьшить — нельзя (без миграции)
Partition key — определяет, в какую partition попадает сообщение. Default — round-robin или hash(key).
Consumer groups
Каждая partition назначается одному consumer в группе. Это даёт:
- Parallelism: 10 partitions = до 10 параллельных consumer-ов
- Load balancing: при добавлении consumer-а — rebalance
- Fault tolerance: если consumer падает, его partitions переназначаются
Важно: если в группе больше consumer-ов чем partitions — лишние простаивают.
Offsets и delivery semantics
Offset — позиция consumer-а в partition. Kafka хранит offsets в специальном topic __consumer_offsets.
Delivery semantics:
- At-most-once. Commit offset до обработки. Если падаешь — сообщение теряется.
- At-least-once. Commit offset после обработки. Если падаешь — обрабатываешь повторно. Default.
- Exactly-once. Сложнее: транзакции producer-а + idempotent consumer.
Достичь exactly-once:
- Idempotent producer. Включить
enable.idempotence=true. Producer добавляет sequence number — broker дедуплицирует. - Transactional producer. Группа операций как одна транзакция.
- Idempotent consumer. Логика обработки должна быть идемпотентной (UPSERT по key, dedup в хранилище).
Schema Registry
При produce/consume важно, чтобы producer и consumer знали схему сообщения. Schema Registry хранит схемы (Avro / Protobuf / JSON Schema) централизованно.
Преимущества:
- Single source of truth для схем
- Validation: producer не может отправить невалидное
- Schema evolution: совместимые изменения проходят валидацию
Compatibility modes:
- Backward — новый consumer может читать старые сообщения
- Forward — старый consumer может читать новые
- Full — оба направления
Retention и compaction
Retention — сколько хранить сообщения. По времени (retention.ms) или размеру (retention.bytes). По умолчанию 7 дней.
Log compaction — для топиков-key-value стораджей. Kafka хранит только последнее сообщение для каждого ключа. Используется для CDC, configs, state.
Типичные вопросы
«Как обеспечить exactly-once в Kafka pipeline?»
(1) Idempotent producer (enable.idempotence=true) — sequence numbers + retry. (2) Transactional API для multi-partition transactions. (3) Idempotent consumer — UPSERT в storage по unique key. Альтернатива — at-least-once + dedup в downstream.
«Сколько partitions сделать для топика?»
Зависит от: (1) throughput — больше partitions = больше параллелизма, (2) consumer count — минимум = max ожидаемый consumer count, (3) ordering requirements — если нужен strict order, иногда меньше partitions.
«Consumer не успевает обработать. Что делать?»
(1) Больше consumer-ов в группе — до количества partitions. (2) Increase max.poll.records — больше за раз. (3) Async processing внутри consumer-а. (4) Партиционировать heavier — больше partitions с rebalance.
«Что такое rebalance и зачем оптимизировать?»
Rebalance — переназначение partitions consumer-ам. Происходит при добавлении/удалении consumer-а. Во время rebalance consumer-ы стоят. Оптимизация: cooperative rebalancing (incremental, не stop-the-world).
«Kafka vs RabbitMQ?»
Kafka — distributed log, для high-throughput pub/sub и event streaming. RabbitMQ — traditional message queue, для task queues с persistent state и complex routing. Kafka масштабируется лучше для миллионов событий/сек.
Структурированный streaming
Spark Structured Streaming — streaming на уровне DataFrame.
Kafka Streams — Java/Scala embedded library для stream processing.
Apache Flink — distributed stream processor, true streaming.
Подробнее — Spark Structured Streaming на собесе DE, Apache Flink на собесе DE.
Частые ошибки
- Игнорировать partition key. Без key — round-robin, ordering ломается
- Слишком много partitions. Overhead в metadata, медленный rebalance
- At-most-once без понимания. «Commit раньше обработки» = потери. На собесе спросят, понимаешь ли trade-off
- Не различать idempotent producer и exactly-once. Idempotent — это часть exactly-once, не весь exactly-once
- Использовать Kafka для всего. Kafka не БД, не cache. Это distributed log
FAQ
Какие книги читать?
«Kafka: The Definitive Guide» (Narkhede, Shapira, Palino) — главная книга. «Designing Data-Intensive Applications» (Kleppmann) — глобальный контекст.
Нужно ли уметь администрировать Kafka?
Junior/Middle DE — нет, это работа SRE. Senior — желательно понимать concepts (replication, ISR, broker config).
Альтернативы Kafka?
Pulsar — современная альтернатива с tiered storage. Redpanda — Kafka-API совместимый, быстрее. На собесах преимущественно Kafka.
Что такое ISR?
In-Sync Replicas — реплики, которые up-to-date с leader. min.insync.replicas — минимум, при котором broker принимает produce. Trade-off: высокий min — больше durability, меньше availability.
Сколько готовиться к Kafka-блоку?
С нуля — 1-2 месяца с практикой. Уже работал — 2-4 недели.