Чем Apache Samza и Apache Storm отличаются в вариантах использования?

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

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

Вот архитектура Apache Storm:

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

Вот архитектура Apache Samza:

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

ПРИМЕР ИСПОЛЬЗОВАНИЯ

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

Инженер-программист написал публикацию:

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

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

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

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

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

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

Что касается вариантов использования Samza и Storm, он пишет:

Все три платформы особенно хорошо подходят для эффективной обработки непрерывных больших объемов данных в реальном времени. Итак, какой из них использовать? Жестких правил нет, максимум несколько общих рекомендаций.

Апач Самза

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

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

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

Апач Шторм

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

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

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