KAFKA по сравнению с современной сеткой данных в памяти (IMDG)

Question

У меня есть некоторый опыт IMDG. Я довольно новичок в KAFKA. Я пытаюсь понять вариант использования для Кафки. Я понимаю, что это платформа потоковой передачи сообщений. Многие из его проблем имеют свои недостатки в современных сетках данных в памяти. Можете ли вы пролить немного света на случаи использования, когда кто-то предпочитает использовать Kafka и когда вы предпочитаете использовать IMDG. Мне нужно провести параллель.

Я приведу один пример. Я заметил использование Kafka для репликации данных. Хотя возможно, я считаю, что IMDG более способны и автоматизированы для этой цели.

Также меня интересует, как эти две технологии дополняют друг друга, поскольку я не думаю, что они находятся в прямой конкуренции.

Answer 1

Недавно я размышлял над тем же вопросом. Я пришел к следующим выводам:

Используйте IMDG, например, Ignite / Hazelcast, если:

• Ваши варианты использования обработки имеют смысл в вычислительной сетке И ваша сетка, в которой может быть несколько приложений / процессов, является единственным потребителем для надежных распределенных потоков данных

Используйте Кафку, если:

• У вас неоднородная среда уровней обработки, и вам нужен независимый уровень интеграции данных для обеспечения надежных распределенных потоков данных

Кроме того, они не обязательно являются взаимоисключающими. Вы можете обнаружить, что последнее имеет смысл в вашей организации. Однако у некоторых потребителей могут быть особые варианты использования IMDG / IMCG, и они предпочитают использовать плоскость Кафки в масштабе предприятия для начальных данных и повторно использовать свои внутренние структуры данных IMDG / IMCG для промежуточных потоков данных, которые используются исключительно в сетке, поэтому нет никакой реальной причины переадресовывать их на Кафку. Это может перенаправить результаты обратно в Кафку для дальнейшего распространения среди остальной части предприятия.

Кстати, IMDG / IMCG, такие как ignite и hazelcast, могут обеспечить паб / суб, быть такими же долговечными, как Kafka, с точки зрения устойчивости данных и обеспечить потоковую обработку по ним.

Answer 2

У двух типов систем есть некоторое перекрытие функций, но они по-прежнему представляют собой два разных типа систем с разными основными целями. В этом мы не можем сравнивать их по основным признакам.

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

На вторичном уровне, который, как мне кажется, линии становятся размытыми, оба типа систем предоставляют какие-то возможности распределенных вычислений (Kafka Streams, Ignite или Hazelcast Compute Grid / Service) с функцией приема данных. Это, однако, не может быть принято в качестве основного критерия выбора.

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

Небольшое приложение может обойтись без одного типа, чтобы использовать вторичные функции другого, но приложение с высоким спросом на оба может фактически нуждаться в использовании обоих типов систем.

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