Видео: основы Apache Kafka

Основная задача, которую выполняет Apache Kafka, — это передача данных из системы источника в целевую систему. При такой схеме всё просто. Но что если у вас 4 source-системы и 6 target-систем?

В таком случае вам придётся реализовать 24 интеграции. Каждая интеграция требует протокола взаимодействия, формата данных и валидации по схеме. Также нам необходимо выполнить нефункциональные требования, такие как:

• надёжность и гарантия доставки;
• подключение новых получателей (target систем);
• интеграция разных стеков.

Такая задача уже не кажется простой.

Почему стоит использовать Apache Kafka

Apache Kafka — это распределённое, отказоустойчивое решение с гибкой архитектурой. Скейлится до 100 брокеров и миллиона запросов в секунду, по опыту удавалось выжать 550-600 тысяч сообщений в секунду, до миллиона не доходил. Есть возможность обрабатывать данные с задержкой менее чем 10 ms, то есть в реальном времени.

Apache Kafka создали в компании LinkedIn. С 2012 года это Open Source проект в составе Apache Foundation. Kafka написан на Scala и Java, а своё название получил в честь писателя Франца Кафки.

Для чего можно использовать Kafka:

• Система обмена сообщений в микросервисной архитектуре.
• Сбор журналов событий, логов и метрик с различного ПО и оборудования.
• Stream processing — возможность потоковой обработки данных хранящихся в Кафке.
• Интеграция с Apache Spark, Storm, Hadoop и другими технологиями, использующимися для Big Data и Machine Learning-решений.

Kafka используют в 2000+ компаниях — то есть это очень распространённое программное обеспечение.

• Netflix применяет для онлайн-рекомендаций, пока вы смотрите кино.
• Uber собирает всю информацию о такси и поездках в реальном времени, также высчитывает маршрут, прогнозирует загруженность и считает цену поездки.
• LinkedIn использует для спама и сбора данных о действиях пользователей в режиме реального времени.

Во всех этих кейсах Kafka выступает в роли транспорта.

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

Основными сущностями для Apache Kafka являются:

• Broker — часть, отвечающая за приём, передачу и хранение сообщений.
• ZooKeeper — отдельный вспомогательный продукт для хранения состояния кластера, конфигурации и метаданных.
• Message или Record — сами данные.
• Producer — информационная система, которая отправляет данные в Kafka.
• Topic — то, куда попадают данные. Отправляются они в том же порядке что и прилетели (FIFO).
• Consumer — тот, кто получает данные из Kafka.

Record состоит из полей Key — опциональное поле для распределения сообщений по кластеру, Value — массив байт, Timestamp — время сообщения в формате Unix time, Headers —  key-value пары с пользовательскими атрибутами.

Topic может быть разделён на партиции для организации высокопроизводительной работы. Партиции могут быть распределены между узлами кластера, но Kafka может это сделать неравномерно.

Например, у вас три топика с тремя партициями. Один топик очень нагруженный, а два — не очень. Kafka может все партиции нагруженного топика распределить на один узел, и он будет очень нагружен. Это решается ручным конфигурированием.

Данные топика или партиции хранятся в log-файлах. Обычно там три файла: .log, .index и .timeindex. Они хранят в себе всю информацию по сообщениям.

В .log хранятся данные, offset, position и timestamp. В index хранится маппинг offset на position, а в timeindex — маппинг timestamp на offset. Максимальный размер .log-файла — 1GB. Когда этот размер превышен, создаются новые три файла log, index и timeindex. Эти три файла называются сегментами.

Особенности Kafka

Kafka не поддерживает ручное удаление данных из топика. Только автоматическая чистка по времени, которая настраивается через параметр Time-To-Live.

Kafka поддерживает репликацию, чтобы при потере узла кластера не потерялись данные. За это отвечает параметр replication-factor, который говорит, сколько копий партиций будет на разных узлах кластера.

Kafka обеспечивает согласованность данных при помощи master-slave кластеризации партиций топика. Например, топик делится на три партиции и одну из них Kafka назначает лидером. Остальные являются фолловерами.

Все операции чтения и записи происходят через лидер-реплику партиции. Поэтому если все лидер-реплики партиций окажутся на одном узле кластера, то этот узел станет самым нагруженным, а остальные будут просто отдыхать. В этом случае надо вручную перебалансировать кластер.

Если лидер-реплика умерла, нужно выбрать нового лидера. В дефолтной конфигурации фолловеры могут не обладать всеми данными. Это плохие кандидаты для лидеров.

Для исключения такой ситуации в Kafka есть механизм insync-реплик. Их количество задаётся в конфигурации. В таком случае при записи данных в лидер-реплику происходит синхронная запись в ISR-реплики-фолловеры. Такие ISR-реплики являются кандидатами на нового лидера. Внимание, это драматично влияет на производительность.

Producer отправляет сообщения только в лидер-реплик партиции. У отправителя есть опции отправки — acks. Она принимает параметры 0, 1 и −1 или all.

• Если acks = 0, значит отправителя не интересует подтверждение доставки и сообщения могут теряться. Этот режим нужен при огромных объемах данных и в специальных случаях.
• Если acks=1, значит отправитель ожидает подтверждения доставки сообщения от лидер-реплики.
• Если acks=all или −1, то отправитель ждёт синхронизации сообщения между всеми ISR-репликами лидер-реплики.

Также producer поддерживает все известные семантики доставки: at most once, at least once, exactly once (idempotence).

Consumer читает пачки сообщений только из лидер-реплики партиции. Их можно объединять в группы, чтобы в несколько потоков читать данные. Это делается при помощи параметра group.id. Consumer должен закоммитить получение данных из Kafka. Есть 2 вида коммитов: автоматические и ручные. Если после получения данных при автокоммите consumer упал, то он не получит эти данные повторно.

Kafka — очень популярна, это проверенное, высокопроизводительное и очень гибкое решение. Но при его использовании нужно понимать нюансы.