Hadoop, Storm, Samza, Spark и Flink: Сравнение платформ больших данных

Функциональность обработки Hadoop происходит от движка MapReduce. Техника обработки MapReduce следует алгоритму преобразования, перемешивания и сокращения с использованием пар ключ-значение. Основная процедура включает в себя:

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

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

Hadoop имеет обширную экосистему, причем сам кластер Hadoop часто используется в качестве строительного блока для другого программного обеспечения. Многие другие среды обработки и механизмы имеют интеграцию Hadoop для использования HDFS и менеджера ресурсов YARN.

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

Обработка штормового потока выполняется путем организации DAG (направленных ациклических графов) в рамках, называемых * топологиями *. Эти топологии описывают различные преобразования или шаги, которые будут предприняты для каждого входящего фрагмента данных при его поступлении в систему.

Топологии состоят из:

Идея, лежащая в основе Storm, состоит в том, чтобы определить небольшие дискретные операции с использованием вышеуказанных компонентов, а затем объединить их в топологию. По умолчанию Storm предлагает как минимум однократные гарантии обработки, что означает, что он может гарантировать, что каждое сообщение обрабатывается хотя бы один раз, но в некоторых сценариях сбоя могут быть дубликаты. Storm не гарантирует, что сообщения будут обработаны по порядку.

Для достижения точной однократной обработки с сохранением состояния также доступна абстракция под названием * Trident *. Чтобы быть явным, Storm без Trident часто упоминается как * Core Storm *. Trident значительно изменяет динамику обработки Storm, увеличивая задержку, добавляя состояние к обработке и внедряя модель микропакетирования вместо поэлементной системы потоковой передачи.

Пользователи Storm обычно рекомендуют по возможности использовать Core Storm, чтобы избежать таких штрафов. Учитывая это, гарантия Trident на обработку элементов ровно один раз полезна в случаях, когда система не может интеллектуально обрабатывать дубликаты сообщений. Trident также является единственным выбором в Storm, когда вам необходимо поддерживать состояние между элементами, например, при подсчете количества пользователей, нажимающих на ссылку в течение часа. Trident дает Storm гибкость, даже если он не играет на естественных преимуществах платформы.

Топологии Trident состоят из:

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

Storm with Trident дает вам возможность использовать микропартии вместо чистой потоковой обработки. Хотя это дает пользователям большую гибкость в приспособлении инструмента к предполагаемому использованию, оно также сводит на нет некоторые из самых больших преимуществ программного обеспечения по сравнению с другими решениями. При этом выбор стиля обработки потока все еще полезен.

Core Storm не предоставляет гарантии заказа сообщений. Core Storm предлагает как минимум однократные гарантии обработки, что означает, что обработка каждого сообщения может быть гарантирована, но возможны дубликаты. Trident предлагает единовременные гарантии и может предлагать заказы между партиями, но не внутри.

С точки зрения функциональной совместимости, Storm может интегрироваться с посредником ресурсов YARN Hadoop, что упрощает подключение к существующему развертыванию Hadoop. Storm имеет более широкую языковую поддержку, чем большинство платформ обработки, и предоставляет пользователям множество возможностей для определения топологий.

Для рабочих нагрузок с чистым потоком и очень строгими требованиями к задержке Storm, вероятно, является наилучшим вариантом для зрелых систем. Он может гарантировать обработку сообщений и может использоваться с большим количеством языков программирования. Поскольку Storm не выполняет пакетную обработку, вам придется использовать дополнительное программное обеспечение, если вам требуются эти возможности. Если у вас есть острая необходимость в одноразовых гарантиях обработки, Trident может предоставить это. Тем не менее, другие структуры потоковой обработки также могут быть более подходящими в этой точке.

Самза полагается на семантику Кафки, чтобы определить способ обработки потоков. Кафка использует следующие понятия при работе с данными:

Поскольку Кафка представляет собой неизменный журнал, Самза имеет дело с неизменными потоками. Это означает, что любые преобразования создают новые потоки, которые используются другими компонентами, не влияя на начальный поток.

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

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

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

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

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

Samza может сохранять состояние, используя отказоустойчивую систему контрольных точек, реализованную как локальное хранилище значений ключей. Это позволяет Samza предлагать гарантированную доставку хотя бы один раз, но не обеспечивает точного восстановления агрегированного состояния (например, количества) в случае сбоя, поскольку данные могут быть доставлены более одного раза.

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

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

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

Хотя обработка в оперативной памяти вносит существенный вклад в скорость, Spark также быстрее справляется с задачами, связанными с диском, благодаря комплексной оптимизации, которая может быть достигнута путем предварительного анализа всего набора задач. Это достигается путем создания ориентированных ациклических графов или * DAG *, которые представляют все операции, которые должны быть выполнены, данные, с которыми нужно работать, а также отношения между ними, что дает процессору большую возможность разумно координировать работу.

Для реализации пакетных вычислений в памяти Spark использует модель, называемую Resilient Distributed Datasets, или * RDDs *, для работы с данными. Это неизменные структуры, которые существуют в памяти и представляют собой коллекции данных. Операции над СДР производят новые СДР. Каждый RDD может проследить свою родословную через свои родительские RDD и, в конечном счете, до данных на диске. По сути, RDD позволяют Spark поддерживать отказоустойчивость без необходимости обратной записи на диск после каждой операции.

Возможности потоковой обработки предоставляются Spark Streaming. Сам Spark разработан с учетом ориентированных на пакет рабочих нагрузок. Чтобы справиться с несоответствием между дизайном двигателя и характеристиками потоковых рабочих нагрузок, Spark реализует концепцию, называемую micro-batches *. Эта стратегия предназначена для обработки потоков данных как серии очень маленьких пакетов, которые могут обрабатываться с использованием собственной семантики пакетного механизма.

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

Очевидная причина использования Spark поверх Hadoop MapReduce - скорость. Spark может обрабатывать одни и те же наборы данных значительно быстрее благодаря своей стратегии вычислений в памяти и расширенному планированию DAG.

Еще одно из главных преимуществ Spark - это универсальность. Он может быть развернут как автономный кластер или интегрирован с существующим кластером Hadoop. Он может выполнять как пакетную, так и потоковую обработку, позволяя управлять одним кластером для обработки нескольких стилей обработки.

Помимо возможностей самого движка, Spark также имеет экосистему библиотек, которые можно использовать для машинного обучения, интерактивных запросов и т. Д. Почти всегда признается, что задачи Spark легче писать, чем MapReduce, что может иметь значительные последствия для производительности.

Адаптация методологии пакетной обработки для потоковой обработки включает буферизацию данных при их поступлении в систему. Буфер позволяет обрабатывать большой объем входящих данных, увеличивая общую пропускную способность, но ожидание очистки буфера также приводит к значительному увеличению задержки. Это означает, что Spark Streaming может не подходить для обработки, где низкая задержка обязательна.

Поскольку ОЗУ обычно дороже дискового пространства, Spark может стоить дороже, чем дисковые системы. Однако повышенная скорость обработки означает, что задачи могут выполняться гораздо быстрее, что может полностью компенсировать затраты при работе в среде, где вы платите за ресурсы ежечасно.

Еще одно последствие разработки Spark в оперативной памяти заключается в том, что нехватка ресурсов может быть проблемой при развертывании в общих кластерах. По сравнению с MapReduce Hadoop, Spark использует значительно больше ресурсов, что может помешать другим задачам, которые могут пытаться использовать кластер в данный момент. По сути, Spark может быть менее внимательным соседом, чем другие компоненты, которые могут работать в стеке Hadoop.

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

Модель потоковой обработки Flink обрабатывает поступающие данные по каждому элементу как истинный поток. Flink предоставляет свой DataStream API для работы с неограниченными потоками данных. Основные компоненты, с которыми работает Flink:

Задачи потоковой обработки во время вычислений делают моментальные снимки с заданными значениями, чтобы использовать их для восстановления в случае возникновения проблем. Для сохранения состояния Flink может работать с несколькими внутренними состояниями в зависимости от уровня сложности и постоянства.

Кроме того, потоковая обработка Flink способна понять концепцию «времени события», то есть времени, когда событие действительно произошло, и также может обрабатывать сеансы. Это означает, что он может гарантировать упорядочение и группировку несколькими интересными способами.

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

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

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

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

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

Flink анализирует свою работу и оптимизирует задачи несколькими способами. Часть этого анализа аналогична тому, что планировщики SQL-запросов выполняют в базах данных отношений, и определяет наиболее эффективный способ реализации данной задачи. Он способен распараллеливать этапы, которые можно выполнять параллельно, одновременно объединяя данные для блокировки задач. Для итеративных задач Flink пытается выполнить вычисления на узлах, где хранятся данные, из соображений производительности. Он также может выполнять «дельта-итерацию» или итерацию только для тех частей данных, которые имеют изменения.

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

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

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

Flink предлагает как потоковую обработку с низкой задержкой, так и поддержку традиционных пакетных задач. Flink, вероятно, лучше всего подходит для организаций, которые предъявляют высокие требования к обработке потоков и некоторым пакетным задачам. Его совместимость с собственными программами Storm и Hadoop, а также способность работать в кластере, управляемом YARN, позволяют легко оценить. Его быстрое развитие делает его достойным внимания.