Является ли кеширование единственным преимуществом искры по сравнению с уменьшением карты?

Ответ 1

Кэширование + в вычислении памяти определенно является большой проблемой для искры, но есть и другие вещи.

RDD (Resilient Distributed Data set): RDD является основной абстракцией искры. Это позволяет восстановить неудавшиеся узлы путем повторного вычисления DAG, а также поддерживает более похожий стиль восстановления Hadoop посредством контрольной точки, чтобы уменьшить зависимости RDD. Хранение искрового задания в DAG допускает ленивое вычисление RDD и может также позволить механизму оптимизации искры планировать поток способами, которые имеют большое значение в производительности.

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

Spark Streaming: искрообразование основано на бумаге Discretized Streams, в которой предлагается новая модель для выполнения оконных вычислений на потоках с использованием микропакетов. Hadoop не поддерживает ничего подобного.

Как результат вычисления памяти в искровом разряде действует как собственный планировщик потока. В то время как для стандартного MR вам нужен внешний планировщик заданий, например Azkaban или Oozie, для планирования сложных потоков.

Проект hadoop состоит из MapReduce, YARN, общего пользования и HDFS; искра, однако, пытается создать единую платформу больших данных с библиотеками (в том же репо) для машинного обучения, обработки графов, потоковой передачи, нескольких библиотек типов sql, и я считаю, что глубокая библиотека обучения находится на начальных этапах. Хотя ничто из этого не является строго особенностью искры, это продукт искровой вычислительной модели. Tachyon и BlinkDB - это две другие технологии, которые построены вокруг искры.

Ответ 2

Значит, это гораздо больше, чем просто кеширование. Ааронман много страдал, только добавляя то, что он пропустил.

Исходная производительность без кэширования в 2-10 раз быстрее благодаря обычно более эффективной и хорошо структурированной структуре. Например. 1 jvm per node с потоками akka лучше, чем разветвление целого процесса для каждой задачи.

Scala API. Scala означает Масштабируемый язык и, безусловно, лучший язык для параллельной обработки. Говорят, что Scala сокращает код на 2-5x, но по моему опыту с кодом рефакторинга на других языках, особенно с кодом java mapreduce, его больше похоже на код на 10-100x меньше. Серьезно я переработал 100 LOC из java в горстку Scala/Spark. Его также гораздо легче читать и рассуждать. Spark еще более лаконичен и прост в использовании, чем инструменты абстракции Hadoop, такие как свинька и улей, и даже лучше, чем Scalding.

Spark имеет repl/shell. Необходимость цикла компиляции-развертывания для выполнения простых заданий устраняется. Можно интерактивно играть с данными так же, как использовать Bash для вызова системы.

Последнее, что приходит на ум, - это простота интеграции с большими табличными БД, такими как cassandra и hbase. В cass прочитать таблицу, чтобы сделать некоторый анализ, просто

sc.cassandraTable[MyType](tableName).select(myCols).where(someCQL)

Подобные вещи ожидаются для HBase. Теперь попробуйте сделать это в любой другой структуре MPP!

ОБНОВЛЕНИЕ, указывающее на то, что это только преимущества Spark, на самом деле есть немало полезных вещей. Например. GraphX ​​для обработки графов, MLLib для легкого машинного обучения, Spark SQL для BI, BlinkDB для безумных быстрых apprx-запросов и, как упоминалось, Spark Streaming

Ответ 3

много было покрыто ааронманом и самбетом. У меня есть еще несколько баллов.

• Spark имеет намного меньшее значение для каждого задания и накладных расходов на одну задачу. Это дает возможность применения к случаям, когда Hadoop MR неприменим. Это случаи, когда ответ требуется через 1-30 секунд.
  Низкие затраты на одну задачу делают Spark более эффективным даже для больших рабочих мест с множеством коротких задач. Как очень приблизительная оценка - когда задача занимает 1 секунду, Spark будет в 2 раза эффективнее, чем Hadoop MR.

• Искра имеет более низкую абстракцию, тогда MR - это график вычислений. В результате можно реализовать более эффективную обработку, а затем MR - особенно в тех случаях, когда сортировка не нужна. Другими словами - в MR мы всегда платим за сортировку, но в Spark - нам не нужно.

Ответ 4

• Apache Spark обрабатывает данные в памяти, а Hadoop MapReduce сохраняется на диске после карты или уменьшает действие. Но Spark нуждается в большой памяти

• Spark загружает процесс в память и сохраняет его там до дальнейшего уведомления ради кэширования.

• Resilient Distributed Dataset (RDD), который позволяет вам прозрачно хранить данные в памяти и сохранять их на диске, если это необходимо.

• Так как Spark использует встроенную память, нет препятствия синхронизации, которые замедляют вас. Это основная причина производительности Spark.

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

• API DataFrames был вдохновлен кадрами данных в R и Python (Pandas), но разработан с нуля до расширения существующего RDD API.

• A DataFrame - это распределенная коллекция данных, организованная в именованные столбцы, но с более богатыми оптимизациями под капотом, поддерживающим скорость искры. p >

• Использование RDD s Spark упрощает сложные операции, такие как join и groupBy, а в бэкэнд вы работаете с фрагментированными данными. Эта фрагментация позволяет выполнять Spark параллельно.

• Spark позволяет создавать сложные многоступенчатые конвейеры данных с использованием направленного ациклического графика (DAG). Он поддерживает совместное использование данных в DAG, чтобы разные задания могли работать с одними и теми же данными. DAG - большая часть скорости Spark.

• База данных Spark намного меньше.

Надеюсь, что это поможет.

Ответ 5

Я думаю, что есть три основные причины.

Основные две причины связаны с тем, что обычно не выполняется одно задание MapReduce, а множество заданий в последовательности.

• Одним из основных ограничений MapReduce является то, что он сохраняет полный набор данных для HDFS после запуска каждого задания. Это очень дорого, потому что оно в три раза (для репликации) приводит к увеличению размера набора данных в дисковых вводах и аналогичном количестве сетевых операций ввода-вывода. Искра занимает более целостное представление о трубопроводе операций. Когда вывод операции должен быть передан в другую операцию, Spark передает данные напрямую, не записывая в постоянное хранилище. Это нововведение по сравнению с MapReduce, которое появилось из документации Microsoft Dryad и не является оригинальным для Spark.
• Основной инновацией Spark было введение абстракции кэширования в памяти. Это делает Spark идеальным для рабочих нагрузок, когда несколько операций получают доступ к тем же входным данным. Пользователи могут поручить Spark кэшировать наборы входных данных в памяти, поэтому их не нужно читать с диска для каждой операции.
• Как насчет работы Spark, которая сводится к одной задаче MapReduce? Во многих случаях они также работают быстрее на Spark, чем на MapReduce. Основное преимущество Spark заключается в том, что он может запускать задачи намного быстрее. MapReduce запускает новую JVM для каждой задачи, которая может занять несколько секунд с загрузкой JAR, JITing, анализом конфигурации XML и т.д. Spark поддерживает JVM-исполнитель, работающий на каждом node, поэтому запуск задачи - это просто вопрос создания RPC для он и передача Runnable в пул потоков, который принимает одиночные цифры в миллисекундах.

Наконец, распространенное заблуждение, вероятно, стоит упомянуть, что Spark как-то работает полностью в памяти, а MapReduce - нет. Это просто не тот случай. Реализация Spuff shuffle очень похожа на MapReduce: каждая запись сериализуется и записывается на диск на стороне карты, а затем извлекается и десериализуется со стороны уменьшения.