Комментарии 28
Я как раз ищу что-то для отправки заданий, но у с большой особенностью: задание - это порядка гигабайта данных. Kafka такой размер сообщений не любит. А как с этим обстоит у Pulsar?
Pulsar тоже не очень любит. Как минимум размер пакета в протоколе по-умолчанию — 5 мегабайт.
Может быть в целом и не нужно слать такие большие задания? Положили пейлоад в сторадж, положили событие с его id в очередь и все
А вот это вопрос интересный. У нас highly volatile данные (граница актуальности - десятки минут), объёмом несколько сотен МБ. Из них нужно выжать (утрируя) небольшой вектор в сотни цифр, который имеет ценность в интервале недель и больше.
Данные прилетают с кучи локаций (сырые метрики) и у нас есть вариант писать их в базу и оттуда "отжимать", или сначала отжимать, а потом писать только важное.
Моя идея была сделать пул работников для "отжима" и раскидывать им задачи через message queue (т.к. локации разные, объём данных разный, время рассчёта разное).
База (и персистентность) тут выглядит избыточно, т.к. сырые данные теряют актуальность почти сразу. Писать в базу во имя удобства message queue, это как-то криво, потому что в схеме взаимодействия появляется довольно жирная связь, да и теряется чистый stateless (взял задачу, отдал результат).
Вот чешу затылок на тему, кому не трудно гигабайты перекачивать.
Интересно как появляется этот гигабайт данных изначально? Некий воркер собирает его из разных источников в памяти? Что будет если этот воркер упадет на полпути? Заново начнет пересобирать?
В классическом ETL не зазорно иметь какой-нибудь простой сторадж, в котором хранить временные данные, хоть в базе хоть в файле.
У нас довольно специальный случай - этот гигабайт состоит из ~200Мб метрик из удалённой локации (из которой очень трудно их доставать - в общем случае могут быть проблемы с сетью), плюс примерно 300Мб данных из других источников (относительно легко доступных). В общую кучу их хочется докладывать, чтобы воркеру не надо было никуда ходить, кроме MQ. Если собирающий потеряет данные, это будет галочка "данные потеряны" (и это ок, т.к. является частью ответа). Если воркер обсыпется в процессе рассчёта, это будет печально, но тоже терпимо, если не сильно часто.
За ETL аббревиатуру спасибо. (Я не data scientist, я админ в команде с программистами, для меня это внове).
Было что-то похожее недавно. Нужно было отжимать приходящие CSV размером от 5ГБ. Через имеющийся стриминг (NiFi, Kafka) ползало, но очень печально. Решением оказался Clickhouse. Отправка родному клиенту на stdin 5ГБ с последующей выдачей ключевых метрик (по датасету из 19М строк) на Kafka connector занимало буквально 6-7 секунд. И это на достаточно простом стенде, данные на который вливались с ноута по воздуху и внутри был фактически ещё один ETL stage, то есть импортированный датасет трансформировался в новый с обогащением, конвертацией и т.п.
У нас, к сожалению, алгоритмы сложнее, чем в clickhouse'ный sql можно записать. Притаскивать базу данных или внешнее хранилище можно, но оно усложнит администрирование и тестирование. Одно дело "чистая" функция "отжима", другое дело компонента, которая и в MQ лазит, и в базу.
Можно попробовать еще https://vectorized.io/redpanda/ как прозрачную замену Kafka
Думается вариант с хранилищем самый часто используемый. У нас пейлоады отправлялись в условный S3, в очередь отправлялась только ссылка на контент. Всё было в одном ДЦ и работало шустро.
В одном пет проекте использовал NSQ, у него в топики можно прям curl'ом POST-ить бинарники. Работало, но у меня там были максимум метров по 50 где-то данные. Да и с отказоустойчивостью непомню что там было, кажется репликации у него из коробки нет.
Очень хорошо обстоят, в клиенте реализован chunking - прозрачное разбиение большого сообщения на маленькие и склеивание на стороне консьюмера
наплодили... не ясно даже что выбирать...
pulsar , kafka , spart, flink, storm , spark, samza
ждем пока ктонибудь додумается написать статью как из этого выбирать
Конкретно pulsar — это кафка на стероидах. Тоже log внутри, но с добавлением некоторой логики сверху.
Не совсем так. В некоторых случаях Кафка лучше подходит, в некоторых Пульсар (и есть довольно большое пересечение, где можно использовать любую из технологий). В ряде компаний используют обе технологии, но под разные задачи (например, Tencent).
Согласен с вами. Своим комментарием я имел в виду, что пульсар, имея в основе систему хранения логов, похож в этом на Кафку, но в отличие от нее добавляет поверх ещё ряд функций: отложенные сообщения, отсутствие ограничения на число консьюмеров и другое. Все то, что в случае с кафкой пришлось бы реализовывать самостоятельно. Но все это правда не бесплатно с точки зрения надёжности
spark, flink, storm, samza – фреймворки, которые можно использовать поверх этих (и не только) хранилищ
Мне кажется, что для 99% случаев Pulsar не нужен (часто Кафка тоже). Если вы не знаете что вам нужно, но хотите попробовать какую-то из этих двух технологий, то начинайте с Kafka (проще, больше обучающих материалов, более распространенная, лучше тулинг, больше комьюнити).
Ещё nuts, pravega, etc
А сколько очередей (топиков) одновременно удалось поднять на pulsar и на каком железе?
У кафки проблемы начинаются где-то с 100K, а как на пульсаре по вашему опыту?
Пока их относительно не много. 1000+ партицированных топиков и соответственно 5000+ топиков-партиций
можно ли после прочтения сообщения , отложить его на некоторое время чтобы без каких либо внутренних буферов ?
Я правильно понимаю, что вы используете delayed сообщения в вашем сервисе очередей? Или вам достаточно классической очереди, когда сообщение из очереди можно потреблять сразу же после его публикации.
Pulsar интересен. Киньте ссылку на какое-нибудь NET Core приложение, работающее с Pulsar.
Пробовал сделать как описано у них здесь
https://pulsar.apache.org/docs/en/client-libraries-dotnet/
Не компилируется. То ли какого-то Нугета не хватает, то ли к.е.з.
Но хотелось бы пощупать.
Apache Pulsar как основа для системы очередей