С Hadoop 2.0 и YARN Hadoop, по-видимому, больше не привязан только к решениям для сокращения карт. С этим продвижением, каковы варианты использования для Apache Spark против Hadoop, учитывая оба варианта HDFS? Я прочитал вводную документацию по Spark, но мне любопытно, сталкивался ли кто-нибудь с проблемой, которая была бы более эффективной и легче решалась с помощью Spark по сравнению с Hadoop.
Ответы:
Hadoop означает HDFS, YARN, MapReduce и многое другое. Вы имеете в виду Spark против MapReduce ? Потому что Spark работает на / с Hadoop, что довольно важно.
Основной причиной использования Spark является скорость, и это связано с тем, что его выполнение может хранить данные в памяти между этапами, а не всегда сохранять обратно в HDFS после Map или Reduce. Это преимущество очень заметно для итерационных вычислений, которые имеют десятки этапов, каждый из которых касается одних и тех же данных. Здесь все может быть в 100 раз быстрее. Для простых однопроходных ETL-подобных заданий, для которых была разработана MapReduce, в общем, это не быстрее.
Другой причиной использования Spark является более приятный язык высокого уровня по сравнению с MapReduce. Он предоставляет функциональное представление, похожее на программирование, которое имитирует Scala, что гораздо приятнее, чем написание кода MapReduce. (Хотя вы должны либо использовать Scala, либо принять немного менее развитые API Java или Python для Spark). Crunch и Cascading уже предоставляют аналогичную абстракцию поверх MapReduce, но это все еще область, где Spark хорош.
Наконец, у Spark есть еще молодые, но многообещающие подпроекты для ML, анализа графиков и потоковой передачи, которые предоставляют похожий, согласованный API. С MapReduce вам придется обратиться к нескольким другим проектам для этого (Mahout, Giraph, Storm). Приятно иметь его в одной упаковке, хотя еще не «запеченный».
Почему бы вам не использовать Spark? перефразируя себя:
Не уверен насчет YARN, но я думаю, что Spark имеет реальное значение по сравнению с Hadoop (рекламируется как в 100 раз быстрее), если данные могут уместиться в памяти вычислительных узлов. Просто потому, что он избегает доступа к жесткому диску. Если данные не умещаются в памяти, все равно есть какой-то выигрыш из-за буферизации.
Хорошая информация @ Шон Оуэн. Хотел бы добавить еще один. Spark может помочь в создании унифицированных конвейеров данных в архитектуре Lambda, адресованных как пакетному, так и потоковому уровням, с возможностью записи на общий обслуживающий уровень. Огромным преимуществом является повторное использование логики между пакетной передачей и потоковой передачей. Кроме того, потоковые алгоритмы K-Means в Spark1.3 являются дополнительным плюсом для ML, кроме отличного мониторинга работы и визуализации процессов в 1.4.
Было бы справедливо сравнить Spark с MapReduce - платформой обработки Hadoop. В большинстве случаев Spark может превзойти MapReduce. Первый обеспечивает обработку данных в памяти, что позволяет обрабатывать данные до 100 раз быстрее. По этой причине Spark является предпочтительным вариантом, если вам нужно быстро понять, например, если вам нужно
Тем не менее, MapReduce хорош в обработке действительно огромных наборов данных (если у вас достаточно времени, необходимого для обработки). Кроме того, это более экономичное решение, поскольку MapReduce читает / записывает на диск. А диски вообще дешевле чем память.
Машинное обучение является хорошим примером типа проблемы, в которой решения на основе Spark световые годы опережают решения на основе mapreduce, несмотря на молодой возраст искры на нити.