Где Apache Samza и Apache Storm отличаются в своих случаях использования?

Ответ 1

Самое большое различие между Apache Storm и Apache Samza сводится к тому, как они передают данные для обработки.

Apache Storm проводит вычисления в реальном времени с использованием топологии и получает корм в кластер, где мастер node распределяет код между рабочими узлами, которые его выполняют. В топологии данные передаются между носиками, которые выплевывают потоки данных как непреложные наборы пар ключ-значение.

Здесь архитектура Apache Storm:

Apache Samza потоки, обрабатывая сообщения, когда они поступают по одному за раз. Потоки делятся на разделы, которые являются упорядоченной последовательностью, каждая из которых имеет уникальный идентификатор. Он поддерживает дозирование и обычно используется с Hadoop YARN и Apache Kafka.

Здесь архитектура Apache Samza:

Подробнее о конкретных способах выполнения каждой из перечисленных ниже систем.

ИСПОЛЬЗОВАНИЕ CASE

Apache Samza был создан LinkedIn.

Инженер-программист написал место размещения:

Он работал в LinkedIn уже несколько лет и в настоящее время работает на сотнях машин в нескольких центрах обработки данных. Наша самая большая работа Samza обрабатывает более 1 000 000 сообщений в секунду во время пиковых часов.

Используемые ресурсы:

Сравнение Storm vs. Samza

Полезные архитектурные ссылки на Storm and Samza

Ответ 2

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

• Возраст: Шторм - это более старый проект, а оригинальный - в этом пространстве, поэтому он обычно более зрелый и проверенный временем. Самза - это новое, второе поколение проекта, который, как сообщается, узнал из уроков, полученных из Storm.
• Кафка: Самза вырос из экосистемы Кафки и очень похож на Кафку. Например, в документации говорится, что они позволяют подключать разные системы обмена сообщениями... пока они предоставляют аналогичную секционирующую, упорядочивающую и воспроизводящую семантику, как это делает Kafka. Шторм, будучи более старой системой, не настолько специализирован для работы с Кафкой.
• Сложность: Самза, отчасти потому, что она делает более сильные предположения об окружающей среде ( "вы можете иметь любую инфраструктуру, которая вам нравится, пока она работает, как Kafka" ), а отчасти потому, что она только новее, поражает меня как правило, проще, чем Storm, в хорошем смысле. Но, возможно, менее хороший способ, которым Самза проще, заключается в том, что он (намеренно?) Не имеет концепции топологии Storm (сложные графики выполнения). Если вам нужен сложный многоступенчатый процессор, он должен быть реализован как самостоятельные задачи, которые общаются через Kafka. У этого есть преимущества, а также недостатки, но Самза делает для вас выбор, тогда как Storm дает вам больше возможностей.
• Управление государством:. Многие приложения Storm должны использовать внешний магазин, например Redis, когда им нужно поддерживать большой объем состояния для обработки входящих кортежей. Эта ситуация, по-видимому, является одной из главных вещей, которые мотивировали дизайн Самзы; одна из наиболее отличительных особенностей Samza заключается в том, что она обеспечивает свои задачи своим локальным дисковым хранилищем ключей/значений для использования в этих целях, если им это нужно.

Ответ 3

Здесь статья Тони Сицилиани, которая содержит сравнение использования (и архитектуры) для Storm, Spark и Samza. Ссылки Apache.org на фактические варианты использования также приведены ниже.

https://tsicilian.wordpress.com/2015/02/16/streaming-big-data-storm-spark-and-samza/

В отношении вариантов использования для Samza и Storm он пишет:

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

Apache Samza

Если у вас есть большое количество состояний для работы (например, много гигабайт на раздел), Samza совместно использует хранилище и обработку на тех же машинах, что позволяет эффективно работать с состоянием, которое не будет вписываться в память. Рамка также предлагает гибкость с ее подключаемым API: по умолчанию исполнение, обмен сообщениями и механизмы хранения могут быть заменены на ваш выбор альтернатив. Более того, если у вас есть несколько этапов обработки данных из разных команд с разными кодовыми базами, то мелкозернистые задания Samza будут особенно хорошо подходят, поскольку их можно добавлять/удалять с минимальными эффектами пульсации.

Несколько компаний, использующих Samza: LinkedIn, Intuit, Metamarkets, Quantiply, Fortscale...

Список вариантов использования Samza: https://cwiki.apache.org/confluence/display/SAMZA/Powered+By

Apache Storm

Если вам нужна высокоскоростная система обработки событий, которая допускает инкрементные вычисления, Storm для этого будет хорошо. Если вам еще нужно выполнить распределенные вычисления по требованию, в то время как клиент ждет синхронно для результатов, у вас будет распределенный RPC (DRPC) из коробки. И последнее, но не менее важное: поскольку Storm использует Apache Thrift, вы можете писать топологии на любом языке программирования. Если вам нужна постоянная настойчивость и/или доставка только один раз, вы должны посмотреть на Trident API более высокого уровня, который также предлагает микро-пакет.

Несколько компаний используют Storm: Twitter, Yahoo!, Spotify, The Weather Channel...

Список вариантов использования бури: http://storm.apache.org/documentation/Powered-By.html