Как стать автором
Обновить
28
0
Анатолий Солдатов @EasyGrow

Исследователь

Отправить сообщение
nats все-таки уже другая по своей идее технология (in-memory queue).

nats streaming близкая к Кафке и Пульсару, да
pulsar, kafka – хранилища/стриминговые платформы

spark, flink, storm, samza – фреймворки, которые можно использовать поверх этих (и не только) хранилищ

Мне кажется, что для 99% случаев Pulsar не нужен (часто Кафка тоже). Если вы не знаете что вам нужно, но хотите попробовать какую-то из этих двух технологий, то начинайте с Kafka (проще, больше обучающих материалов, более распространенная, лучше тулинг, больше комьюнити).
При этом в Kafka 3 (без зукипера) этот предел будет значительно увеличен (до миллионов)
Для Кафки число топиков не очень важно, важно число партиций. 100к это не предел для Кафки. Конфлюент дает такие цифры (статья): «As a rule of thumb, we recommend each broker to have up to 4,000 partitions and each cluster to have up to 200,000 partitions.»
> Конкретно pulsar — это кафка на стероидах.
Не совсем так. В некоторых случаях Кафка лучше подходит, в некоторых Пульсар (и есть довольно большое пересечение, где можно использовать любую из технологий). В ряде компаний используют обе технологии, но под разные задачи (например, Tencent).
У RabbitMQ и Apache Kafka есть пересечение, где обе технологии могут применяться для похожих задач. Но в целом это разные технологии с разной семантикой. Для каждой из них можно найти область, где она будет лучше другой (и хуже тоже).

В контексте семантики топиков, «бесконечного» хранения данных на диске, чтения одних и тех же данных сотнями/тысячами консьюмеров и масштабирования до десятков/сотен ГБ событий в секунду использовать RabbitMQ может быть какой-то мощный админ и сможет в сложных топологиях, но смысла в этом большого нет.
Для консьюмеров из одной группы это можно сделать командой kafka-consumer-gropus с флагом --members.

Для всех консьюмеров (в т.ч. из разных групп) можно сделать то же самое, только запустить эту команду в цикле по списку всех групп
Слишком вы критичны :)

kafka-registry, я так понимаю, это Schema Registry? Если да, это плохой совет. Точнее, вам не обязательно использовать именно этот продукт, но Кафка без схем = помойка данных и нестабильные пайплайны на больших масштабах.

kafka-rest-proxy тоже имеет свое место – через него можно делать автоматизацию администрирования кластеров (создание топиков и тд для тех языков, где нет нормального Admin Client или его нет вообще). Использовать под нагрузкой не стоит, тут я соглашусь
В целом, многие с этим мнением не согласятся, конечнo.
Например, Kelsey Hightower считает, что монолиты скоро (или уже) опять будут в моде :)
2020 prediction: Monolithic applications will be back in style after people discover the drawbacks of distributed monolithic applications.
Цифры относительные будут всегда, тк зависят от многих факторов (какое у вас железо, какой паттерн нагрузки, какого размера сообщения, на сколько хорошая сетка, как настроен кластер, клиенты и тд).

В наших инсталляциях на данный момент пиковые нагрузки в районе 25 гигабит в секунду или 600к событий в секунду на кластере из 9 машин с HDD дисками. Это точно далеко не предел, но пока нам больше и не нужно.
Это перевод статьи, автор данного мнения – Emil Koutanov
Пользовательской аналитикой очень просто таких объемов добиться (кликстрим, например).
А какие у вас были проблемы, если не секрет (интересно)?

В целом, вы и правы и нет одновременно. Если сравнивать Kafka с другими подобными решениями, то у нее экосистема намного более развитая и богатая (коннекторы, репликаторы, прокси, schema registry и тд и тд). И часто компаниям достаточно того, что уже сделано другими и доступно в опенсорсе. Но бывают и случаи когда под именно вашу платформу/ваш кейс надо что-то дописывать самостоятельно.
Apache Kafka = технология (она)
А на каких цифрах вы уперлись в лимит Kafka по топикам/производительности?

И еще не совсем понял последнюю часть про прод («до прода еще система не добралась») – у вас Pulsar ведь уже в проде?

И очень интересно было бы еще узнать про сложность администрирования Pulsar vs Kafka
А можете описать профиты переезда конкретно для вас (не абстрактные Pulsar более заряжен фичами и тд и тп)? Это было бы очень интересно узнать
Мы выбрали скрывать формат за абстракцией (Brief – www.youtube.com/watch?v=VjMloZzEq2A). Сервисы работают с нашим форматом, а внутри может быть Avro, Proto, JSON и тд). У Brief есть свой аналог schema registry и схемы.

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

Если вы все-таки используете JSON, то стоит под него сразу написать свой простенький schema registry, т.к. «гибкий» JSON вообще без схем скоро превратит данные в вашем кластере в kakafku. Ну и готовьтесь гонять больше данных по сети, больше времени тратить на сериализацию/десериализацию и тд.

«нет схемы — нет проблем», это скорее «нет схемы – вы еще не знаете о проблемах». Один продюсер без схемы может сломать абсолютно всех консьюмеров. Кажется, что лучше такие изменения найти и поправить одном месте, чем сломаться сразу во многих.
Вы хотели сказать пока Pulsar разгоняется, наверное :)
Кафка уже давно разогналась и ее adoption в IT-компаниях явный тому пример.

Мне тоже кажется Pulsar более интересной технологией, но с точки зрения внедрения его в компаниях пока не вижу больших продвижений вперед (в контексте России, в основном. Кажется, в Азии у Pulsar дела получше).
Я поэтому и задал вопрос про практический опыт:)
Да, в теории Пульсар во многом лучше Кафки.
Подход к сопровождению кластеров Кафки

Информация

В рейтинге
Не участвует
Работает в
Зарегистрирован
Активность