Apache Kafka или Pulsar: что и когда выбирать

В заключение цикла статей о сравнении Apache Kafka с Pulsar, сегодня мы перечислим, когда следует предпочесть второй вариант для построения распределенных масштабируемых систем потоковой аналитики больших данных. Также читайте далее, с какими ограничениями придется мириться в случае выбора этого Big Data фреймворка.

5 случаев, когда Apache Pulsar лучше Kafka

При том, что различные бенчмаркинговые тесты выдают разные результаты при сравнении Apache Kafka с Pulsar, о чем мы писали здесь, на практике обе Big Data платформы активно используются для построения распределенных масштабируемых систем потоковой аналитики больших данных. В частности, опыт компаний Nutanix, Yahoo!JAPAN и StreamSQL показывает возможность применения Apache Pulsar вместо Kafka, несмотря на вполне обоснованную критику этого молодого и пока не слишком популярного фреймворка. Проанализировав эти и другие примеры использования Pulsar в production, отметим 5 наиболее распространенных сценариев, когда следует предпочесть его, а не самую популярную Big Data платформу потоковой обработки событий, т.е. Kafka.

Итак, выбирайте Apache Pulsar вместо Kafka, если:

• вы не хотите заботиться о геораспределенной репликации данных между несколькими дата-центрами в разных регионах и/или континентах. Функция распределенной графической репликации данных между кластерами встроена в Apache Pulsar, тогда как Kafka для этой цели предполагает использование дополнительных решений, такие как MirrorMaker 2, Confluent Replicator, Multi-Region-Clusters или Global Kafka [1]. Их использование увеличивает сложность управления всей Big Data инфраструктурой, поэтому, например, Yahoo!JAPAN предпочли Pulsar [2]. В Pulsar включить георепликацию между кластерами, можно при наличии клиента, который разрешает доступ к обоим кластерам. При этом фактически георепликация между двумя кластерами управляется на уровне пространства имен, в котором сообщение, опубликованное в любом топике, реплицируется на все кластеры в указанном наборе. Сперва сообщения сохраняются в локальном кластере, а затем асинхронно пересылаются в удаленные кластеры [3].
• нужно совместить модели очереди сообщений с потоковой передачей в одном решении. При том, что Pulsar не до конца объединяет эти 2 концепции, о чем мы писали здесь, и не включает такие возможности как транзакции, маршрутизация и фильтрация сообщений, а также не обеспечивает не обеспечивает семантику строго однократной доставки сообщений (exactly-once), эти недостатки не являются ограничениями для его практического использования в некоторых проектах. Например, американская ИТ-компания Nutanix выбрала именно Apache Pulsar вместо Kafka для своего SaaS-продукта Beam, в котором используется пакетная обработка очередей и потоковая передача по модели «Издатель/Подписчик» [4].
• есть потребность в автоматической перебалансировке данных на брокерах, которую в Apache Pulsar обеспечивает BookKeeper, равномерно распределяя сегменты по узлам хранения. Таким образом, в отличие от Kafka, данные топика не привязаны к какому-либо конкретному узлу хранения, что позволяет легко заменить узлы, а также увеличить или уменьшить масштаб кластера [5].
• требуется гибкое масштабирование с неограниченным числом топиков за счет разделения уровней обслуживания и хранения данных благодаря наличию Apache BookKeeper. В частности, эта возможность стала аргументом в пользу Pulsar для Yahoo!JAPAN [2], хотя утверждение о действительно ничем неограниченном масштабировании на самом деле является достаточно спорным [1].
• необходимо снизить расходы на обслуживание всей Big Data системы с помощью мультиарендности (Multi-tenancy), когда несколько сервисов используют одну платформу в качестве «арендатора» без организации собственной изолированной систему обмена сообщениями. Изначально Apache Pulsar создавался как мультитенантная система, где клиенты могут быть распределены по кластерам, и к каждому из них может быть применена собственная схема аутентификации и авторизации. Они также являются административной единицей, в которой можно управлять квотами хранилища, TTL сообщений и политиками изоляции. Таким образом, Pulsar предоставляет встроенные механизмы аутентификации и авторизации для защиты сообщений от перехвата в рамках пространства имен или топика [6].

Решив использовать Apache Pulsar в одном или нескольких вышеотмеченных случаев, будьте готовы мириться с некоторыми недостатками или ограничениями этого Big Data фреймворка, о которых мы поговорим далее.

3 главных недостатка Пульсар

Итак, при всех достоинствах Apache Pulsar, выбрав его вместо Kafka, следует быть готовым к его некоторым особенностям, которые существенно ограничивают практическое применение этого Big Data фреймворка:

• зависимость от Apache Zookeeper – в то время как Kafka в ближайшем будущем планирует отказаться от этой службы синхронизации распределенных систем, заменив его внутренним механизмом под названием Self-Managed Metadata Quorum [7], о чем мы рассказывали здесь, Pulsar даже не анонсирует такой возможности.
• меньшая степень зрелости – Apache Kafka появилась раньше Pulsar и уже прошла «проверку боем» во всех возможных вариантах использования, которые помогли выявить лучшие практики ее администрирования и эксплуатации.
• наконец, меньшая популярность Pulsar по сравнению с Kafka обусловливает меньшее количество обучающих материалов и курсов, а, значит, и специалистов по работе с этим Big Data фреймворком. При этом знание Kafka сегодня можно отнести к hard skills, которыми должен обладать каждый разработчик распределенных приложений и дата-инженер.

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

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

Источники

1. https://dzone.com/articles/pulsar-vs-kafka-comparison-and-myths-explored
2. https://streamnative.io/en/success-stories/yahoo_japan
3. https://pulsar.apache.org/docs/en/administration-geo/
4. https://medium.com/@yuvarajl/why-nutanix-beam-went-ahead-with-apache-pulsar-instead-of-apache-kafka-1415f592dbbb
5. https://streamnative.io/en/blog/tech/2020-07-08-pulsar-vs-kafka-part-1
6. https://pulsar.apache.org/docs/en/concepts-multi-tenancy/
7. https://cwiki.apache.org/confluence/display/KAFKA/KIP-500:+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum