Архитектура ADS

Каждый из именованных топиков (topic) в Kafka состоит из одной и более партиций (partition), распределённых между брокерами (broker) внутри одного кластера ADS.

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

Для гарантии сохранности данных каждая партиция в Kafka может быть реплицирована несколько раз. Таким образом гарантируется наличие нескольких копий сообщения, хранящихся на разных брокерах.

У каждой партиции есть «лидер» (Leader) — брокер, который работает с клиентами. Именно лидер работает с производителями (producer) и в общем случае отдаёт сообщения потребителям (consumer). Сообщения всегда отправляются лидеру и, в общем случае, читаются с лидера.

Для масштабируемой и надежной потоковой передачи данных между Kafka и другими системами данных используется Kafka Connect. Kafka Connect может принимать целые базы данных или собирать метрики с серверов приложений в топики Kafka, а также может доставлять данные из разделов Kafka, например, в системы для анализа и поиска данных (ADLS) или в системы управления базами данных (ADB).

При помощи Confluent Schema Registry обеспечивается совместимость схем данных между производителем и потребителем Kafka.

Решение о том, какой из брокеров является контроллером (то есть брокером, отвечающим за выбор лидеров партиций) принимает ZooKeeper. Также ZooKeeper определяет, в каком состоянии находятся лидеры партиций и их реплики.

Дополнительно ZooKeeper выполняет роль консистентного хранилища метаданных и распределённого сервиса логов. В случае сбоя брокера именно в ZooKeeper контроллером будет записана информация о новых лидерах партиций.

Для работы с потоковыми файлами NiFi использует множество обработчиков (процессоров) – отдельных фрагментов кода для выполнения конкретной операции с потоковыми файлами.

Каждый потребитель Kafka является частью Сonsumer Group, которая настроена при помощи процессора ConsumeKafka в NiFi на конкретный брокер и имя группы Kafka.

Каждая Consumer Group имеет уникальное название и регистрируется брокерами в кластере Kafka. Данные из одного и того же топика могут считываться множеством Consumer Group одновременно.

Когда несколько потребителей читают данные из Kafka и являются членами одной и той же группы, то каждый из них получает сообщения из разных партиций топика, таким образом распределяя нагрузку. NiFi в данном случае выступает в роли потребителя Kafka и реализует всю логику обработки данных.

Также существует возможность при помощи NiFi передать данные из Kafka в другую систему.

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

Producer API позволяет приложению публиковать поток сообщений в один или несколько топиков платформы Kafka.

Consumer API позволяет приложению подписываться на один или несколько топиков и обрабатывать принадлежащие им потоки записей.

Streams API позволяет приложению выступать в качестве stream processor (потокового процессора). Streams API потребляет входной поток данных из одного или нескольких топиков и создает выходной поток данных так же для одного или нескольких топиков. Таким образом Streams API эффективно преобразует входные потоки в выходные.