При том, что Apache Kafka является фреймворком №1 в потоковой обработке Big Data, эта распределенная платформа передачи событий имеет специфические недостатки и ограничения, которые затрудняют ее использование в некоторых сценариях. Сегодня рассмотрим, что именно в Apache Kafka усложняет жизнь администраторам, разработчикам и дата-инженерам, а также как Redpanda решает эти проблемы.
Множество достоинств и 5 главных проблем Apache Kafka
На текущий момент Apache Kafka — это ключевой элемент современной инфраструктуры данных, ведущая платформа потоковой передачи событий с открытым исходным кодом. Мощности Kafka хватает для множества бизнес-сценариев в сотнях тысяч компаний, включая LinkedIn, Netflix, Airbnb, Twitter, Авито, Северсталь и пр.
Платформа также используется для интеграции информационных систем как шина событий, куда одни приложения отправляют сообщения, а другие считывают их по порядку, получая уведомления о новых данных в реальном времени. В отличие от традиционной базы данных, которая подходит для запросов и обновлений в соответствии с текущим состоянием, Kafka позволяет микросервисам быстро реагировать на различные изменения, приводящие к текущему состоянию. Благодаря отказоустойчивой кластерной архитектуре Kafka легко масштабировать по горизонтали, просто добавляя дополнительные узлы и разделы к отдельным топикам. А надежность обеспечивается за счет длительного хранения сообщений в течении настраиваемого периода, а не только, как они дошли до потребителя.
Однако, при всех своих достоинствах Apache Kafka не лишена недостатков. Выполняя роль ведущей инфраструктуры данных, Kafka сама по себе является большой и сложной платформой, повышая барьер входа в технологию и трудности при постоянном техническом обслуживании. На практике администраторы и дата-инженеры, работающие с Apache Kafka, выделяют следующие основные проблемы [1]:
- Администрирование кластера включает работу не только по развертыванию и подержке, но и требует глубокого погружения в дизайн системы. Например, определение того, как сообщения хранятся по разделам топиков, в течение какого времени и каковы квоты для группы или приложения. Инженер данных должен знать о том, что представляет собой каждое сообщение, как обеспечить его использование в правильном порядке, где и как выполнять преобразования с отслеживанием состояния и многое другое — и все это с максимальной точностью.
- Зависимость от инфраструктуры. Подобно СУБД, Kafka является техническим инструментом, который сам по себе не решает реальных бизнес-проблем. В частности, чтобы получить от этой event-streaming платформы настоящую пользу, нужны клиентские приложения, которые читают и записывают данные, используя предоставляемые Kafka гибкие API.
- Трудности инженерии данных, в частности преобразования в потоковых приложениях во время выполнения, с масштабированием и увеличением параллелизма, о чем мы говорили в прошлой статье;
- ограничение на исторические данные – при том, что одним из преимуществ Kafka является возможность длительного хранения событий, она зависит от доступного дискового пространства, серверов и перемещения данных. Будучи изначально созданным для локального хранилища, облачное развертывание этой платформы требует дополнительных усилий. Например, необходимо решит, следует ли использовать более медленные, но лучше масштабируемые постоянные диски, подключенные к сети, или более быстрые, но временные твердотельные накопители, которые могут потребовать дополнительного перемещения данных?
- Kafka не предназначен для пакетных данных. При том, что Кафка группирует сообщения в микро-пакеты, о чем мы писали здесь и здесь, фреймворк ориентирован именно на потоковую парадигму. Однако, пакетная обработка все еще актуальна для некоторых сценариев, которые не следует реализовывать в Kafka. В частности, большой размер пакетов может вызвать перегрузку брокеров, которые отвечают за запись новых данных в реальном времени.
Решить эти проблемы можно с помощью альтернативных систем. Причем к ним относятся не только широко известные RabbitMQ и Apache Pulsar, которые мы сравнивали с Кафка в этой статье, но и Redpanda, что мы рассмотрим далее.
Что такое Redpanda: альтернативная платформа потоковой обработки Big Data
Redpanda – это полностью совместимая с Kafka потоковая платформа для критически важных рабочих нагрузок. Поскольку все API полностью совместимы с Кафка, то любой ее клиент на разных языках программирования, от Java до PHP, будет работать с Redpanda без дополнительных изменений. Будучи написана на C++, Redpanda менее требовательна к оперативной памяти, чем основанная на JVM платформа Kafka. Наконец, еще одним существенным плюсом Redpanda является отсутствие Zookeeper или другого внешнего сервиса синхронизации метаданных благодаря обеспечению консенсуса с помощью RAFT-протокола. Хотя, последняя версия Apache Kafka также поддерживает подобное решение для отказа от Zookeeper, эта опция пока находится в экспериментальном режиме и не рекомендуется в production, о чем мы рассказывали здесь.
Еще стоит отметить несколько важных преимуществ Redpanda по сравнению с Kafka [2, 3]:
- встроенные преобразования WebAssembly (WASM), что позволяет разработчикам реализовать трансформации данных и фильтры на любом языке программирования и развернуть двоичный файл WASM с помощью одной CLI-команды. Преобразования WASM выполняются внутри кластера Redpanda, снижая потребность в дополнительных вычислительных кластерах, таких как Apache Flink или Spark. Также это обеспечивает возможность быстрой манипуляции с данными в соответствии с требованиями GDPR;
- геореплицируемое иерархическое хранилище;
- встроенная поддержка популярной DevOps-системы мониторинга приложений Prometheus;
- огромное количество разделов (более 2-х миллионов, т.е. в 10 раз больше, чем у Kafka);
- устойчивость к сканированию без кэширования страниц;
- чтение реплик.
Разумеется, данная система имеет и свои недостатки. Например, по сравнению с Kafka транзакции Redpanda более чувствительны к нарушениям внутри кластера, таким как разделение данных или повторные выборы координатора транзакций. Когда это случается, Redpanda прерывает затронутые транзакции и возвращает ошибку. Напомним, в Kafka при обнаружении ошибки во время обработки транзакции, клиент закрывает текущего продюсера создает нового, чтобы повторить транзакцию. Таким образом, прерванные транзакции возможны в Kafka, а Redpanda просто увеличивает их частоту.
В заключение подчеркнем, благодаря 100%-ной совместимости с API Kafka, можно заменить ее текущее развертывание на Redpanda, продолжая использовать все полезные инструменты и продукты экосистемы этой event streaming платформы. К примеру, просто указав кластер Redpanda для среды Apache Kafka Connect, применяемой в рамках интеграции с внешними системами данных [2, 3]. Пример практического использования Redpanda с Apache Flink смотрите в нашей новой статье.
Apache Kafka для инженеров данных
Код курса
DEVKI
Ближайшая дата курса
20 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
В заключение отметим, что еще одной перспективной альтернативой Apache Kafka считается платформа Pulsar, которой мы посвятили целую серию публикаций. Тем не менее, пока именно Apache Kafka считается самой популярной распределенной платформой потоковой передачи событий. А потому умение администрировать и использовать это фреймворк становится абсолютным must-have для современного специалиста Big Data. Освоить все тонкости практического администрирования и эксплуатации Apache Kafka для разработки распределенных приложений потоковой аналитики больших данных вам помогут специализированные курсы в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
