Вопросы по Kafka и стримингу на собеседовании

Kafka спрашивают на собесах дата-инженеров и бэкендеров, и почти всегда разговор упирается в гарантии: что значит at-least-once на практике, откуда берутся дубли и почему exactly-once не бесплатен.

Что спрашивают

• +Гарантии доставки: at-most-once, at-least-once, exactly-once, идемпотентный продюсер и дедупликация на стороне потребителя
• +Устройство: партиции и ключ сообщения, офсеты и их коммит, группы потребителей и ребалансировка
• +Порядок: где он гарантирован, а где нет, и что делать, когда порядок действительно важен
• +Окна и время: событийное против времени обработки, опоздавшие события, watermark
• +Эксплуатация: лаг потребителя, ретенция, что происходит при падении консьюмера посреди батча

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

• Гарантии доставки16
• Окна и время события14
• Основы стриминга14
• Потоковая обработка11
• Внутренности Kafka10

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• Гарантии доставки в Kafka: at-least-once и exactly-once16 вопросов
• Партиции, офсеты и группы потребителей в Kafka10 вопросов
• Потоковая обработка данных11 вопросов
• Основы потоковой обработки14 вопросов
• Окна и время события в стриминге14 вопросов

Примеры вопросов с разбором

1. #delivery_semantics1 / 9
   Что такое offset в Kafka?

   A)Общее суммарное количество всех консьюмеров, одновременно читающих один и тот же топик

   B)Задержка в миллисекундах между отправкой и получением сообщения брокером

   C)Позиция сообщения в партиции; консьюмер коммитит её, чтобы не читать заново

   D)Объём свободного места, оставшегося в партиции топика на диске брокера

   показать ответ и разбор

   +C)Позиция сообщения в партиции; консьюмер коммитит её, чтобы не читать заново

   // разбор: Offset — порядковый номер сообщения в партиции. Консьюмер отмечает (коммитит) свой offset, чтобы после перезапуска продолжить с нужного места, а не с начала. Момент коммита определяет гарантию доставки: закоммитить до обработки — at-most-once (потеря при сбое), после обработки — at-least-once (возможны повторы).

2. #kafka_internals2 / 9
   Что такое партиция топика Kafka и зачем их несколько?

   A)Партиция — это резервная копия топика на другом брокере ради отказоустойчивости системы

   B)Партиции нужны для сжатия данных и на параллелизм чтения не влияют

   C)Партиция — упорядоченный лог и единица параллелизма/распределения

   D)Kafka обеспечивает строгий порядок сообщений сразу по всему топику через все партиции

   показать ответ и разбор

   +C)Партиция — упорядоченный лог и единица параллелизма/распределения

   // разбор: Топик делится на партиции — независимые упорядоченные логи, распределённые по брокерам. Партиции дают горизонтальный масштаб (пишем/читаем параллельно) и параллелизм консьюмеров: в группе каждую партицию читает один консьюмер, поэтому потолок параллелизма чтения — число партиций. Порядок гарантируется только внутри партиции. Число партиций выбирают заранее под целевой параллелизм — увеличивать легко, уменьшать нельзя.

3. #stream_processing3 / 9
   Что такое stateful-обработка в стриминге и чем она сложна?

   A)Stateful-обработка не хранит состояния, обрабатывая каждое событие независимо

   B)Сложность stateful-обработки лишь в скорости, к сбоям и восстановлению она безразлична

   C)Состояние между событиями; сложность — его durability и восстановление

   D)Состояние стрим-обработчика помещается в пару переменных и не требует сохранения

   показать ответ и разбор

   +C)Состояние между событиями; сложность — его durability и восстановление

   // разбор: Stateless-операция (map, filter) обрабатывает каждое событие независимо. Stateful (агрегаты по окну, дедуп, join потоков, счётчики на ключ) держит накопленное состояние между событиями. Сложность в том, что это состояние надо переживать сбои: его периодически чекпоинтят в надёжное хранилище, чтобы после падения восстановить и продолжить без потери и двойного счёта. Объём состояния и его консистентность — главные заботы stateful-стрима.

4. #streaming_basics4 / 9
   Чем batch-обработка отличается от streaming?

   A)Batch обрабатывает накопленные данные порциями; streaming — события по мере поступления

   B)Batch и streaming — это полные синонимы одного и того же способа обработки данных

   C)Streaming-обработка по своей сути запускается один раз в год одним большим пакетом

   D)Batch работает с текстом, а streaming — с числами

   показать ответ и разбор

   +A)Batch обрабатывает накопленные данные порциями; streaming — события по мере поступления

   // разбор: Batch копит данные и обрабатывает их порциями по расписанию — высокая пропускная способность, но задержка в часы. Streaming обрабатывает события по мере поступления — низкая задержка (near-real-time) ценой сложности. Выбор от задачи: дневной отчёт — batch, антифрод и алерты в моменте — streaming.

5. #windowing_time5 / 9
   Зачем в потоковой обработке нужны окна (windows)?

   A)Чтобы наглядно отрисовать весь входящий поток событий на большом графике дашборда

   B)Поток бесконечен; окно ограничивает набор событий, по которому считают агрегат

   C)Чтобы удалять старые события из системы ради экономии места на диске

   D)Чтобы зашифровать содержимое каждого отдельного события в потоке данных

   показать ответ и разбор

   +B)Поток бесконечен; окно ограничивает набор событий, по которому считают агрегат

   // разбор: Поток событий бесконечен, поэтому агрегаты («сколько заказов за 5 минут», «средний чек за час») считают не по всему потоку, а по окну — ограниченному по времени или числу событий набору. Тип окна (tumbling, sliding, session) определяет, как именно эти наборы нарезаются во времени.

6. #delivery_semantics6 / 9
   Как из дешёвой at-least-once доставки получить эффект exactly-once в стриме?

   A)Достаточно отключить повторные попытки доставки сообщений

   B)Читать каждое сообщение по одному разу, игнорируя сбои сети

   C)Хранить все сообщения в оперативной памяти без записи на диск

   D)Сделать обработчик идемпотентным (dedup по ключу/offset) — повтор не меняет результат

   показать ответ и разбор

   +D)Сделать обработчик идемпотентным (dedup по ключу/offset) — повтор не меняет результат

   // разбор: At-least-once дёшев, но допускает повторы после сбоя. Если обработчик идемпотентен — дедуплицирует по event_id/ключу или делает upsert по offset — повторная доставка не меняет итог, и по эффекту получается exactly-once. Это дешевле и надёжнее, чем строить «настоящий» exactly-once на уровне транспорта, и работает даже при переигрывании лога.

7. #kafka_internals7 / 9
   Что такое ISR (in-sync replicas) в Kafka?

   A)ISR — это список консьюмеров, которые в данный момент активно читают из партиции

   B)ISR — реплики, которые намеренно отстают от лидера ради экономии дисковых операций

   C)ISR — резервные брокеры, простаивающие, пока не выйдет из строя основной кластер

   D)Реплики партиции, догнавшие лидера; запись с acks=all подтверждается, когда её приняли все из ISR

   показать ответ и разбор

   +D)Реплики партиции, догнавшие лидера; запись с acks=all подтверждается, когда её приняли все из ISR

   // разбор: У партиции есть лидер и реплики-фолловеры; ISR — подмножество реплик, не отстающих от лидера. При acks=all запись считается зафиксированной, когда её реплицировали все реплики из ISR, а min.insync.replicas задаёт минимальный размер ISR, при котором приём вообще разрешён. Если реплика отстаёт, её выкидывают из ISR; лидером при сбое становится реплика из ISR — поэтому нет потери подтверждённых данных.

8. #stream_processing8 / 9
   Зачем в стриминге делают чекпоинты (checkpoints)?

   A)Чекпоинт просто выводит текущие метрики джоба в лог для удобства ручного мониторинга

   B)Чекпоинты ускоряют обработку, кэшируя ответы downstream-сервисов между событиями потока

   C)Чекпоинт останавливает поток на длительное время для ручной проверки данных оператором

   D)Снимок состояния+offset для восстановления после сбоя

   показать ответ и разбор

   +D)Снимок состояния+offset для восстановления после сбоя

   // разбор: Чекпоинт — согласованный снимок состояния обработчика вместе с offset'ами входных потоков, сохранённый в надёжное хранилище. При падении джоб поднимается с последнего чекпоинта: восстанавливает состояние и перечитывает вход с сохранённых offset'ов — поэтому не теряет накопленное и не считает дважды. Частота чекпоинтов — размен между накладными расходами и объёмом переигровки после сбоя. Основа отказоустойчивости Flink/Spark Structured Streaming.

9. #streaming_basics9 / 9
   Что такое топик и партиция в Kafka?

   A)Топик в Kafka — это один физический сервер-брокер, а партиция — его подключённый жёсткий диск

   B)Топик — это единичное сообщение, а партиция — его резервная копия для надёжности

   C)Топик — именованный поток сообщений; партиция — его часть для параллелизма и порядка

   D)Топик — формат сериализации сообщения, а партиция — способ его сжатия

   показать ответ и разбор

   +C)Топик — именованный поток сообщений; партиция — его часть для параллелизма и порядка

   // разбор: Топик — именованный поток сообщений, разбитый на партиции. Партиции дают горизонтальный параллелизм (их читают разные консьюмеры) и хранят упорядоченный лог: порядок гарантирован внутри партиции, но не между ними. Поэтому число партиций ограничивает параллелизм чтения, а ключ сообщения определяет, в какую партицию оно попадёт.

Частые вопросы

• Что чаще всего спрашивают про Kafka?

  Гарантии доставки и как избежать дублей, устройство партиций и порядок сообщений, работу групп потребителей и коммит офсетов.

• Нужен ли exactly-once в реальных системах?

  Обычно достаточно at-least-once с идемпотентной обработкой на стороне потребителя. На собесе как раз проверяют, понимаете ли вы цену exactly-once и умеете ли обойтись без него.

• Спрашивают ли Kafka у аналитиков?

  Редко и по верхам: что это за очередь и зачем она в архитектуре данных. Глубокие вопросы про офсеты и ребалансировку остаются дата-инженерам и бэкендерам.