Версия сайта для слабовидящих
Как использовать мощь Apache Kafka в ИТ-архитектуре корпоративных приложений и интеграции информационных систем: краткий ликбез по ключевым принципам работы этой платформы потоковой передачи событий и важность дата-контрактов для инженера данных, разработчика и архитектора.
9 лучших практик использования Apache Kafka в архитектуре приложений
Чтобы успешно применять Apache Kafka в качестве основной технологии проектирования и реализации конвейеров обработки данных в реальном времени и масштабных потоковых приложений, вспомним ключевые принципы работы этой платформы:
- разделение топика на разделы обеспечивает параллельную обработку сообщений, позволяя нескольким приложениям-потребителям обрабатывать сообщения параллельно. Каждый раздел может использоваться только одним потребителем в группе потребителей. Если в группе несколько потребителей, они могут получать сообщения из разных разделов. Поэтому, если нужно распараллелить потребление сообщений, следует создать несколько разделов в топике. Каждое сообщение отправляется группе потребителей, подписавшейся на топик или раздел, но внутри группы оно отправляется только одному потребителю. Хотя все группы потребителей, подписавшиеся на топик, получают сообщения, лишь один потребитель в группе получает сообщение из конкретного раздела. Таким образом, чтобы сообщение получали несколько потребителям, назначьте им разные группы потребителей.
- Kafka отлично работает с огромным потоком сообщений, но они должны быть небольшого размера, о чем мы писали здесь. По умолчанию размер сообщения в Kafka составляет 1 МБ. Сообщения можно сжать до их отправки в топик Kafka. Чтобы хранить больше данных в одном топике, можно создать несколько разделов на нескольких серверах.
- Сообщения, которые приложение-продюсер публикует в Kafka, должны быть сериализуемы. Не рекомендуется использовать слишком глубокий уровень вложенности, что часто бывает в сложных структурах данных.
- Если важен временной порядок сообщений, следует использовать один и тот же идентификатор раздела, чтобы они попадали в один раздел топика, гарантируя упорядоченность Для обеспечения глобального порядка событий рекомендуется создать один топик с одним единственным разделом. Но это лишит возможности использовать параллельную обработку сообщений.
- Переопределить смещения выборки, которые потребитель будет использовать при следующем опросе (тайм-аут) поможет функция seek(TopicPartition partition, long offset). Если этот метод вызывается для одного и того же раздела более одного раза, при следующем вызове функции опроса poll() будет использовано самое последнее смещение. Произвольное применение этого API в середине потребления для сброса смещений выборки может привести к потере данных.
- Защитить данные в Kafka помогут клиентские сертификаты TLS и шифрование сообщений, а также настроенные пользовательские разрешения на выполнение определенных операций.
- Поскольку Apache Kafka записывает данные на жесткий диск, следует регулярно контролировать дисковое пространство и удалить старые сообщения, используя механизм сжатия топика, когда старые события для ключа удаляются по мере публикации новых событий.
- Обеспечить высокую надежность системы потоковой передачи событий на основе Kafka поможет высокий коэффициент репликации для разделов каждого топика на нескольких серверах. Если какой-то брокер выйдет из строя, это позволит автоматически переключаться на реплики, оставляя сообщения доступными. Можно установить коэффициент репликации для каждого топика отдельно. Однако, стоит помнить, что репликация повышает надежность за счет снижения производительности, т.к. распространение копий по нескольким узлам кластера занимает время. Обычно для надежной отработки отказов задается фактор репликации, равный 3.
- Чтобы приложения-продюсеры и приложения-потребители могли успешно взаимодействовать друг с другом через Apache Kafka, необходимо определиться со схемой и форматом отправляемых и считываемых сообщений. Сделать это помогут контракты данных, о которых мы поговорим далее.
Контракты данных и реестр схем
Контракты данных помогают документировать и обеспечивать форму и метаданные сообщений, чтобы уменьшить количество неожиданных сбоев и избавиться от недокументированных изменений. Если продюсеры и потребители данных согласны с тем, что данные, которыми они обмениваются, имеют определенную схему, это следует проверять для каждого сообщения. Когда схема данных изменилась на стороне приложения-продюсера, а приложение-потребитель не знает об этом, прекращается фактическая интеграция информационных систем через Kafka. Поэтому важно, чтобы хранить контракты данных и поддерживать их с помощью автоматических проверок.
Чтобы определить такой контракт между приложениями-продюсерами и приложениями-потребителями данных, в Kafka есть специальный компонент под названием реестр схем (Schema Registry). Реестр схемы — это отдельный процесс, который находится за пределами кластера и одновременно используется как продюсером, так и потребителем для передачи и потребления сообщений. Он хранит и обслуживает метаданные сообщений. Схемы имеют версии и реестр предоставляет различные параметры совместимости, которые позволяют изменять схему данных.
Рекомендуется реализовать контракт между продюсером и потребителем, который будет улавливать любые изменения схемы данных на ранней стадии, обеспечивая валидацию сообщения еще до того, как данные будут опубликованы в Kafka. Раннее обнаружение изменения гарантирует, что нижестоящие потребители будут знать об эволюции схемы, поскольку у продюсера нет возможности продолжить работу с новой схемой без фактического обновления реестра схем, где хранятся контракты данных. А обновление контракта возможно только с согласия обеих сторон: приложения-продюсера и приложения-потребителя.
Автоматизировать такую валидацию поможет небольшой скрипт в виде теста. Например, из реестра берется последняя версия схемы и сравнивается со схемой данных, которые продюсер собирается отправить в Kafka. Тест будет пройден, когда схема отправляемого сообщения точно соответствует той, что зарегистрирована в реестре. На стороне приложения-потребителя можно сделать то же самое, проверяя схему считываемого сообщения.
Процесс обновления контракта данных сводится к регистрации новой версии схемы в реестре схем, что является общедоступным обновлением, которое должно быть согласовано между продюсерами и потребителями. Отдельное хранение контрактов данных позволяет повторно использовать их в разных местах, что повышает гибкость ИТ-архитектуры и экспоненциально снижает количество возможных сбоев по мере увеличения числа интегрируемых приложений.
Больше подробностей про администрирование и эксплуатацию Apache Kafka в системах аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Apache Kafka для инженеров данных
- Администрирование кластера Kafka
- Администрирование Arenadata Streaming Kafka
Источники
