spark, flink, storm, samza – фреймворки, которые можно использовать поверх этих (и не только) хранилищ
Мне кажется, что для 99% случаев Pulsar не нужен (часто Кафка тоже). Если вы не знаете что вам нужно, но хотите попробовать какую-то из этих двух технологий, то начинайте с Kafka (проще, больше обучающих материалов, более распространенная, лучше тулинг, больше комьюнити).
Для Кафки число топиков не очень важно, важно число партиций. 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-registry, я так понимаю, это Schema Registry? Если да, это плохой совет. Точнее, вам не обязательно использовать именно этот продукт, но Кафка без схем = помойка данных и нестабильные пайплайны на больших масштабах.
kafka-rest-proxy тоже имеет свое место – через него можно делать автоматизацию администрирования кластеров (создание топиков и тд для тех языков, где нет нормального Admin Client или его нет вообще). Использовать под нагрузкой не стоит, тут я соглашусь
Цифры относительные будут всегда, тк зависят от многих факторов (какое у вас железо, какой паттерн нагрузки, какого размера сообщения, на сколько хорошая сетка, как настроен кластер, клиенты и тд).
В наших инсталляциях на данный момент пиковые нагрузки в районе 25 гигабит в секунду или 600к событий в секунду на кластере из 9 машин с HDD дисками. Это точно далеко не предел, но пока нам больше и не нужно.
А какие у вас были проблемы, если не секрет (интересно)?
В целом, вы и правы и нет одновременно. Если сравнивать Kafka с другими подобными решениями, то у нее экосистема намного более развитая и богатая (коннекторы, репликаторы, прокси, schema registry и тд и тд). И часто компаниям достаточно того, что уже сделано другими и доступно в опенсорсе. Но бывают и случаи когда под именно вашу платформу/ваш кейс надо что-то дописывать самостоятельно.
Мы выбрали скрывать формат за абстракцией (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 дела получше).
nats streaming близкая к Кафке и Пульсару, да
spark, flink, storm, samza – фреймворки, которые можно использовать поверх этих (и не только) хранилищ
Мне кажется, что для 99% случаев Pulsar не нужен (часто Кафка тоже). Если вы не знаете что вам нужно, но хотите попробовать какую-то из этих двух технологий, то начинайте с Kafka (проще, больше обучающих материалов, более распространенная, лучше тулинг, больше комьюнити).
Не совсем так. В некоторых случаях Кафка лучше подходит, в некоторых Пульсар (и есть довольно большое пересечение, где можно использовать любую из технологий). В ряде компаний используют обе технологии, но под разные задачи (например, Tencent).
В контексте семантики топиков, «бесконечного» хранения данных на диске, чтения одних и тех же данных сотнями/тысячами консьюмеров и масштабирования до десятков/сотен ГБ событий в секунду использовать RabbitMQ может быть какой-то мощный админ и сможет в сложных топологиях, но смысла в этом большого нет.
Для всех консьюмеров (в т.ч. из разных групп) можно сделать то же самое, только запустить эту команду в цикле по списку всех групп
kafka-registry, я так понимаю, это Schema Registry? Если да, это плохой совет. Точнее, вам не обязательно использовать именно этот продукт, но Кафка без схем = помойка данных и нестабильные пайплайны на больших масштабах.
kafka-rest-proxy тоже имеет свое место – через него можно делать автоматизацию администрирования кластеров (создание топиков и тд для тех языков, где нет нормального Admin Client или его нет вообще). Использовать под нагрузкой не стоит, тут я соглашусь
Например, Kelsey Hightower считает, что монолиты скоро (или уже) опять будут в моде :)
В наших инсталляциях на данный момент пиковые нагрузки в районе 25 гигабит в секунду или 600к событий в секунду на кластере из 9 машин с HDD дисками. Это точно далеко не предел, но пока нам больше и не нужно.
В целом, вы и правы и нет одновременно. Если сравнивать Kafka с другими подобными решениями, то у нее экосистема намного более развитая и богатая (коннекторы, репликаторы, прокси, schema registry и тд и тд). И часто компаниям достаточно того, что уже сделано другими и доступно в опенсорсе. Но бывают и случаи когда под именно вашу платформу/ваш кейс надо что-то дописывать самостоятельно.
И еще не совсем понял последнюю часть про прод («до прода еще система не добралась») – у вас Pulsar ведь уже в проде?
И очень интересно было бы еще узнать про сложность администрирования Pulsar vs Kafka
В целом, формат может быть любой исходя из вашей задачи. Если вам нужны схемы, кодогенерация или если вы упираетесь в производительность – смотрите в сторону Avro, тем более вся экосистема вокруг Kafka его любит.
Если вы все-таки используете JSON, то стоит под него сразу написать свой простенький schema registry, т.к. «гибкий» JSON вообще без схем скоро превратит данные в вашем кластере в kakafku. Ну и готовьтесь гонять больше данных по сети, больше времени тратить на сериализацию/десериализацию и тд.
«нет схемы — нет проблем», это скорее «нет схемы – вы еще не знаете о проблемах». Один продюсер без схемы может сломать абсолютно всех консьюмеров. Кажется, что лучше такие изменения найти и поправить одном месте, чем сломаться сразу во многих.
Кафка уже давно разогналась и ее adoption в IT-компаниях явный тому пример.
Мне тоже кажется Pulsar более интересной технологией, но с точки зрения внедрения его в компаниях пока не вижу больших продвижений вперед (в контексте России, в основном. Кажется, в Азии у Pulsar дела получше).
Да, в теории Пульсар во многом лучше Кафки.