5 главных мифов о превосходстве Apache Pulsar над Kafka и их опровержения

Оставив за рамками этой статьи бенчмаркинговые войны по оценке производительности Apache Pulsar в сравнении с Kafka и RabbitMQ, сегодня разберем 5 популярных мифов о превосходстве молодого Пульсар над зрелой Кафка – платформой потоковой обработки событий с точки зрения администрирования и эксплуатации. Читайте далее, правда ли управлять кластером Pulsar проще, чем Apache Kafka, и что из них надежнее для построения распределенных масштабируемых систем аналитики больших данных.

Миф №1: Pulsar проще в управлении, чем Kafka

Недавно мы упоминали, что BookKeeper позволяет Pulsar разделять вычисления и хранение данных, в отличие от Kafka. В Apache Pulsar брокер выполняет вычисления, а букмекер управляет stateful-хранилищем, обеспечивая более гибкую масштабируемость, меньшую операционную нагрузку, скорость и стабильность высокопроизводительной обработки Big Data.

Однако, не все так просто. Архитектура Pulsar включает три распределенных системы и дополнительную технологию хранения: собственно Apache Pulsar, ZooKeeper и BookKeeper, а также RocksDB для хранения внутренних индексов. В свою очередь, кластер Kafka состоит из самой Кафка и Zookeeper для синхронизации метаданных распределенных систем. Таким образом, количество конфигурационных параметров в Apache Kafka значительно меньше, чем у Pulsar. Кроме того, Kafka планирует отказаться от Zookeeper, заменив его внутренним механизмом под названием Self-Managed Metadata Quorum [1], о чем мы рассказывали здесь.

Впрочем, пока Zookeeper как потенциальная точка отказа присущ как 2-х уровневой архитектуре Kafka, так и 3-х уровневой модели Pulsar. При том, что трехуровневая архитектура считается более гибкой для масштабирования, дополнительный уровень увеличивает передачу данных по сети минимум на 33%. В случае Pulsar данные в брокерах должны дополнительно кэшироваться на обоих уровнях для обеспечения эквивалентной производительности и дважды записываться на диск, поскольку формат хранения Bookkeeper отличается от обычного лога.

На практике в облачных развертываниях Kafka резервным хранилищем является не нишевое решение как BookKeeper, а широко используемое и проверенное хранилище объектов в виде AWS S3 или GCP GCS. В частности, многоуровневое хранилище в Confluent Platform, которое поддерживается AWS S3 и GCP GCS, обеспечивает те же преимущества без дополнительного уровня BookKeeper и связанных с этим дополнительных затрат на передачу данных по сети и задержек, которые несет эта архитектура Pulsar.

Кроме того, стоит помнить, что администрирование и эксплуатация – это не только вопрос архитектуры. По сравнению с Pulsar, документация Kafka значительно подробнее, имеет широкое сообщество экспертов и огромный набор вспомогательных инструментов, упрощающих операции управления этой Big Data платформой. Наконец, количество обучающих материалов, конференций, митапов и курсов по Kafka намного больше, чем в случае Apache Pulsar [2].

Миф №2: Пульсар лучше справляется с опозданиями потребителей

Есть мнение, что Pulsar отлично решает проблему отстающих потребителей из-за 3-хуровневой архитектуры, разграничивающей кэширование и хранение данных. Чтобы подтвердить или опровергнуть этот миф, следует уточнить особенности работы с запаздывающими потребителями сообщений. Основная сложность с запаздывающими потребителями в том, что они исчерпывают кеш страницы. Это означает, что последние сообщения уже кэшированы, а их заменяют чтения из старых сегментов, снижая производительность чтения из заголовка журнала. Pulsar не устраняет эту проблему с очисткой кэша, добавляя к чтению с локального носителя данных дополнительный сетевой переход и операцию ввод-вывод.

Администрирование кластера Kafka

Код курса

KAFKA

Ближайшая дата курса

29 мая, 2024

Продолжительность

24 ак.часов

Стоимость обучения

72 000 руб.

Миф №3: Pulsar лучше масштабируется

Считается, что Kafka позволяет хранить не более 500K разделов на кластер из-за ограничений Zookeeper. Однако, Pulsar тоже не допускает бесконечных масштабов: BookKeeper имеет аналогичное ограничение «1 файл на регистр», что и Kafka, позволяя иметь несколько регистров в одном разделе. Уровень брокера Pulsar группирует разделы в пакеты, но BookKeeper хранит данные во множестве сегментов для каждого раздела. Впрочем, как и в Kafka, метаданные для этих сегментов хранятся в Zookeeper, что накладывает ограничение на общее количество, которое может быть сохранено.

Примечательно, что при создании топика Kafka необходимо задать масштаб, чтобы избежать чрезмерного разбиения топиков на разделы. Это ограничение является следствием особенностей распределенной потоковой передачи событий, позволяя Kafka масштабироваться намного лучше, чем традиционные системы обмена сообщениями, в частности, RabbitMQ, о чем мы писали здесь. Однако, аналогичный недостаток присутствует и у Pulsar, где пропускная способность записи основана на количестве разделов топика. Поэтому в Pulsar топики тоже должны быть избыточно разделены, как и в Kafka: в один момент времени каждому разделу доступен только один реестр для записи. А увеличение количества разделов приводит к нарушению порядка сообщений, аналогично Kafka.

Кроме того, при межкластерной репликации Pulsar требуется дополнительный «глобальный» кластер Zookeeper, что делает этот Big Data фреймворк непригодным для географического распределения на больших расстояниях [2]. В Apache Kafka с подобной задержкой при развертывании распределенных систем в разных регионах по всему миру позволяют справиться специальные инструменты репликации в реальном времени, например, MirrorMaker 2, Confluent Replicator, Multi-Region-Clusters или Global Kafka [3].

Миф №4: Мгновенное восстановление после сбоя

В отличие от брокера Kafka, брокер Pulsar не хранит данные, а является только прокси-сервером для BookKeeper. Таким образом, сбой брокера Pulsar действительно не является проблемой, что нельзя сказать о ситуации, когда узел BookKeeper (букмекер) выходит из строя. В случае перезапуска букмекера BookKeeper требуется такое же перераспределение (ребалансировка) данных, как и в Kafka. Впрочем, облако Confluent Cloud предлагает круглосуточную безотказную работу кластера со SLA более 99.xx% за счет самоорганизуемой ребалансировки, позволяя пользователю не беспокоиться об управлении брокером, определении размеров узлов, имезнения размеров кластера и пр. Пока Apache Pulsar нечего ответить на этот аргумент [2].

 

Миф №5: Pulsar отлично совместим с интерфейсом и API Kafka

Это утверждение частично соответствует истине, однако, с рядом уточнений [2]:

• Pulsar предоставляет очень простую реализацию, совместимую только с небольшими частями протокола Kafka v2.0;
• Pulsar имеет адаптер (конвертер) для основных частей Kafka. Но он поддерживает далеко не все методы API производителей и потребителей Kafka. Тоже самое можно сказать о поддержке настроечных параметров (свойств) этих API [4].

Из наиболее значимых в практическом смысле ограничений следует отметить отсутствие поддержки транзакции, семантики строго однократной доставки сообщений (exactly once), сжатия и уплотнения логов [2].

Таким образом, с точки зрения разработки по-настоящему крупных и надежных систем потоковой аналитики больших данных зрелая Кафка ничуть не уступает молодому Pulsar, а опережает этот по-своему интересный фреймворк, предлагая более взвешенные и устоявшиеся решения. А о том, кто и почему все-таки выбрал Pulsar вместо Kafka, читайте в нашей следующей статье. 

Apache Kafka для инженеров данных

Код курса

DEVKI

Ближайшая дата курса

27 мая, 2024

Продолжительность

24 ак.часов

Стоимость обучения

72 000 руб.

Больше подробностей по администрированию кластеров и разработке Kafka-приложений для аналитики больших данных вы сможете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

• Администрирование кластера Kafka
• Apache Kafka для разработчиков

 

 

Источники

1. https://cwiki.apache.org/confluence/display/KAFKA/KIP-500:+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum
2. https://dzone.com/articles/pulsar-vs-kafka-comparison-and-myths-explored
3. https://www.kai-waehner.de/blog/2020/01/29/deployment-patterns-distributed-hybrid-edge-global-multi-data-center-kafka-architecture/
4. http://pulsar.apache.org/docs/en/adaptors-kafka/