Комментарии 39
Сегодня, пожалуй, лишь Apache Hive можно считать классическим и надежным инструментом для работы с SQL-запросами по распределенным данным, как и HDFS является классикой среди кластерных файловых систем
Hive — это СУБД поверх HDFS, но никак не файловая система.
DAG (directed acyclic graph) vs Hadoop MapReduce vs Hadoop Streaming
Hadoop Streaming — это утилита, которая «стримит» поток данных на воркерах через STDIN и STDOUT, тем самым позволяя писать MapReduce приложения на любом языке (не особо удобно и совсем не эффективно, но раньше иначе было нельзя). Т.е. это всё тот же классический MR, только mapper и reducer — не джавовские потоки, а внешние процессы. PySpark и SparkR, кстати, делают, по сути, то же самое. Как и Storm, впрочем.
А вот в Spark Streaming слово «streaming» относится уже именно к потенциально бесконечному потоку данных, когда непрерывно поступают новые данные, например, из Kafka или Twitter.
Spark в EMR профессионально интегрирован с S3. Это правильно, ведь именно там вы скорее всего будете хранить файлы в Amazon. Мы сравнивали хранение больших файлов в S3 и HDFS, и оказалось, что скорость доступа примерно одинаковая. Тогда зачем связываться с HDFS, мучиться с кластерной файловой системой, если есть готовый сервис.
Боюсь, вы не поняли всей идеи map-reduce. Что отличает большие данные от маленьких? Правильно, размер и время передачи по сети. Map-reduce учит нас, что если данных действительно много, то гораздо проще не копировать их к приложению, а лучше скопировать само приложение к данным и обработать всё что можно локально. HDFS позволяет сделать именно это: вы не просто распределяете данные на много машин, вы ставите рядом с этими данными воркеров и назначаете этим воркерам задачи над своим локальным куском. Используя S3 вы возвращаетесь к началу и снова тратите время на перетягивание данных от одних серверов к другим.
Если хотите построить эффективную систему на Hadoop, то складывайте все пакетные данные в HDFS, а данные со случайным доступом — в какое-нибудь NoSQL хранилище (HBase, Cassandra, Redis — тут уже в зависимости от вариантов использования). Хранение в S3 имеет смысл только если вы каждый раз пересоздаёте кластер в EMR и уничтожаете его после использования, чтобы не платить Amazon-у лишних денег. Но тут уж сами считайте, что вам выгодней.
• Master-машины, которые контролируют вообще весь кластер. На них установлен Spark Master.
• Core-машины, на которых развернута файловая система — HDFS. Их может быть несколько штук. Правда, рекомендуется только увеличивать количество core-машин, а не уменьшать, иначе теряются данные.
• Для всего остального используются task-машины. Это обычные Spark-серверы, на которых работают воркеры.
По той же причине, что и выше, core и task машины должны быть одними и теми же. Ноды данных и воркеры должны быть рядом.
Больше всего мне не нравится в Yarn и Hadoop то, что там бардак с логированием.
yarn logs -applicationId <application ID>
После завершения приложения эта команда вытянет логи всех контейнеров YARN приложения. Нужно, правда, понимать, что именно у вас крутится в контейнерах, а что нет. Например, если вы запускаете приложение в режиме yarn-client, то драйвер будет на машине, с которой вы запускали, а значит драйвера (в отличие от логов воркеров) будут писаться локально на STDOUT.
Impala. Очень интересная вещь, про которую можно написать отдельный пост.Пока производит впечатление сырого софта. Так что используйте на свой страх и риск.
Многие вещи в Impala появились гораздо раньше, чем в Hive, да и стабильная версия у неё уже 2.1. Скорее всего у вас просто был неудачный опыт или вы привычки к Hive, у которого всё-таки немного другие цели.
При использовании Colleсt() весь результат собирается в память в драйвере и он может упасть.
Обычно данные просто записываются в HDFS. Это ещё один пример преимущества распределённой файловой системы: данные из каждой партиции запишутся локально и в паралелли. Если же надо получить на выходе ровно один файл, то можно вызвать .repartition(1) и тот же .saveAsHadoopFile() — все данные пойдут на одну машину, но не в виде одной коллекции, а в виде ленивого итератора, что полностью решает проблему с памятью.
Спасибо за развернутый комментарий! Приятно общаться с понимающими коллегами.
Согласен полностью! Парадигма Data Parallel Processing и ее детеныш в виде методики свертки функций — MapReduce учат нас, что данные можно разложить по кусочкам и одновременно на каждом кусочке выполнить функцию. А с точки зрения реализации уже, на уровне железа, будет лучше держать данные ближе к процессам, их обрабатывающим. В идеале. На практике вот что получалось:
1) Когда держали ноды с воркерами HDFS с запущенными там воркерами Spark — при интенсивной работе с данными воркеры Spark резко замедляли воркеры HDFS ;-)
2) Настройки ОС, конфигурация железа для нод с HDFS и нод со Spark — сильно отличается. В первом случае — диски большие, во втором — памяти побольше и ядер.
3) Коллеги из Hadoop одно время назад реализовали возможность «привязки» данных к серверным стойкам. Вот это способ видится мне более рациональным — когда в одной стойке под одним маршрутизатором живут машины с HDFS и машины Spark с разной железной конфигурацией.
4) Данных может быть на 2 сервера HDFS, а серверов для их обработки нужно 20. И наоборот. У нас так.
5) В Амазоне что машины с s3, что машины локальные — находятся примерно одинаково далеко :-) Вот у нас и не было выигрыша. Но если бы мы поднялись в изолированном кластере, а там есть такая услуга, то да, было бы быстрее хранить данные в HDFS.
Да смотрел я ее, но она вроде логи только получает не грохая? Логи просмотреть можно и через веб-админку. Нам нужно чтобы логи ротировались и удалялись из кластера. Пока приходится это делать кучей настроек в разных местах и скриптами на bash, лазающими и грохающими что найдут мусорного :-)
Hive — это СУБД поверх HDFS, но никак не файловая система.Конечно, никто не спорит: «лишь Apache Hive можно считать классическим и надежным инструментом для работы с SQL-запросами по распределенным данным».
Hadoop Streaming — это утилита, которая «стримит» поток данных на воркерах через STDIN и STDOUT, тем самым позволяя писать MapReduce приложения на любом языке (не особо удобно и совсем не эффективно, но раньше иначе было нельзя). Т.е. это всё тот же классический MR, только mapper и reducer — не джавовские потоки, а внешние процессы. PySpark и SparkR, кстати, делают, по сути, то же самое. Как и Storm, впрочем.Да, мы часть задач для MR пишем через эту прибамбасу на PHP. Но где нужна скорость — на java. Про Storm я бы поспорил — имхо он больше для Task Parallel задач, не для Data Parallel как MR или Spark.
Боюсь, вы не поняли всей идеи map-reduce. Что отличает большие данные от маленьких? Правильно, размер и время передачи по сети. Map-reduce учит нас, что если данных действительно много, то гораздо проще не копировать их к приложению, а лучше скопировать само приложение к данным и обработать всё что можно локально. HDFS позволяет сделать именно это: вы не просто распределяете данные на много машин, вы ставите рядом с этими данными воркеров и назначаете этим воркерам задачи над своим локальным куском. Используя S3 вы возвращаетесь к началу и снова тратите время на перетягивание данных от одних серверов к другим.
Согласен полностью! Парадигма Data Parallel Processing и ее детеныш в виде методики свертки функций — MapReduce учат нас, что данные можно разложить по кусочкам и одновременно на каждом кусочке выполнить функцию. А с точки зрения реализации уже, на уровне железа, будет лучше держать данные ближе к процессам, их обрабатывающим. В идеале. На практике вот что получалось:
1) Когда держали ноды с воркерами HDFS с запущенными там воркерами Spark — при интенсивной работе с данными воркеры Spark резко замедляли воркеры HDFS ;-)
2) Настройки ОС, конфигурация железа для нод с HDFS и нод со Spark — сильно отличается. В первом случае — диски большие, во втором — памяти побольше и ядер.
3) Коллеги из Hadoop одно время назад реализовали возможность «привязки» данных к серверным стойкам. Вот это способ видится мне более рациональным — когда в одной стойке под одним маршрутизатором живут машины с HDFS и машины Spark с разной железной конфигурацией.
4) Данных может быть на 2 сервера HDFS, а серверов для их обработки нужно 20. И наоборот. У нас так.
5) В Амазоне что машины с s3, что машины локальные — находятся примерно одинаково далеко :-) Вот у нас и не было выигрыша. Но если бы мы поднялись в изолированном кластере, а там есть такая услуга, то да, было бы быстрее хранить данные в HDFS.
Если хотите построить эффективную систему на Hadoop, то складывайте все пакетные данные в HDFS, а данные со случайным доступом — в какое-нибудь NoSQL хранилище (HBase, Cassandra, Redis — тут уже в зависимости от вариантов использования)Да, так и делаем. Для NoSQL у нас DynamoDB.
После завершения приложения эта команда вытянет логи всех контейнеров YARN приложения. Нужно, правда, понимать, что именно у вас крутится в контейнерах, а что нет. Например, если вы запускаете приложение в режиме yarn-client, то драйвер будет на машине, с которой вы запускали, а значит драйвера (в отличие от логов воркеров) будут писаться локально на STDOUT.
Да смотрел я ее, но она вроде логи только получает не грохая? Логи просмотреть можно и через веб-админку. Нам нужно чтобы логи ротировались и удалялись из кластера. Пока приходится это делать кучей настроек в разных местах и скриптами на bash, лазающими и грохающими что найдут мусорного :-)
Обычно данные просто записываются в HDFS. Это ещё один пример преимущества распределённой файловой системы: данные из каждой партиции запишутся локально и в паралелли. Если же надо получить на выходе ровно один файл, то можно вызвать .repartition(1) и тот же .saveAsHadoopFile() — все данные пойдут на одну машину, но не в виде одной коллекции, а в виде ленивого итератора, что полностью решает проблему с памятью.Нет проблемы с памятью — проблемы со скоростью выгрузки данных из RDD на диск. Если получать итератор по данным и качать из него — 3 дня ждать приходится :-) Repartition может выполняться неразумно долго, пробовали. Я код накидал выше, он позволяет выкачивать RDD гораздо быстрее в нашем случае.
Конечно, никто не спорит: «лишь Apache Hive можно считать классическим и надежным инструментом для работы с SQL-запросами по распределенным данным».
Я всё равно не понял, как Hive может быть ещё и классикой среди распределённых файловых систем, если файловой системой он не является. Ну да ладно, будем считать, что это моё личное восприятие.
Про Storm я бы поспорил — имхо он больше для Task Parallel задач, не для Data Parallel как MR или Spark.
Я не очень понимаю, как вы определяете data parallelism и task parallelism. Data parallelism обычно используется в контексте GPU или SIMD инструкций CPU — single instruction, multiple data. Task parallelism обычно ставится им в противоположность как возможнось исполнять в разных потоках разный код. Что Spark, что Storm позволяют одинаково легко делать и то, и другое.
Парадигма Data Parallel Processing и ее детеныш в виде методики свертки функций — MapReduce учат нас, что данные можно разложить по кусочкам и одновременно на каждом кусочке выполнить функцию.
Я ещё раз повторюсь, что смысл map-reduce именно в локальности данных, а не в параллельной обработке. Смотрите: возьмём 20 серверов MySQL, возьмём 20 серверов приложения и будем каждым инстансом приложения обрабатывать только часть данных из MySQL. Нужен здесь map-reduce? Нет, подобная схема существовала задолго до появления оной парадигмы.
Теперь рассмотрим другой пример: есть 20 серверов с индексами веб-страниц и 100 тысяч поисковых запросов в секунду. Если мы поставим отдельно 20 серверов приложений, то на каждый такой запрос сервер приложения должен будет выкачивать несколько гигабайт данных с серверов индексов, сканировать их и выдавать топ-10 результатов. Оверхед на передачу данных фантастический. С другой стороны, если собственно поисковый механизм перенесём на сервера индексов, то передавать придётся не все данные, а только топ-N записей: алгоритм локально подсчитает подходящие результаты (map), а потом передаст только наиболее подходящие на центральный сервер, который закончит работу (reduce). Вот это и было мотивацией создания map-reduce, а не просто распараллеливание работы.
1) Когда держали ноды с воркерами HDFS с запущенными там воркерами Spark — при интенсивной работе с данными воркеры Spark резко замедляли воркеры HDFS ;-)
А как вы это замеряли? DataNode-ы требуют минимум CPU и упираются в первую очередь в скорость диска. Spark требует CPU и памяти, но с диском работает через те же DataNode-ы. Возможно, вы получились где-то бонус от кеша HDFS, который тоже в памяти, но это довольно специфичный случай и из него можно получить профит и без, и со Spark-ом.
2) Настройки ОС, конфигурация железа для нод с HDFS и нод со Spark — сильно отличается. В первом случае — диски большие, во втором — памяти побольше и ядер.
Так а кто мешает поставить сбалансированные ноды? Благо, даже если вы изначальное не угадали с конфигурацией, то что Amazon, что выделенные стойки с серверами позволяют добавлять ресурсы (CPU, RAM, disk) по необходимости.
4) Данных может быть на 2 сервера HDFS, а серверов для их обработки нужно 20. И наоборот. У нас так.
В Amazon это называется compute-intensive nodes. Т.е. нет никакой проблемы взять машины с небольшим диском, но большим количеством ядер и памяти.
С другой стороны, если данных у вас действительно настолько мало, что вы можете свободно гонять их по сети, то и map-reduce как таковой вам не нужен. Spark здесь может дать дополнительное удобство, но принципиального отличия от тех же 20 серверов приложений, которые тянут данные с 20 серверов MySQL, нет.
В Амазоне что машины с s3, что машины локальные — находятся примерно одинаково далеко :-)
Так вот поэтому map-reduce и размещает ноды с данными на тех же машинах, что и ноды-обработчики — тогда они находятся максимально «близко» ;)
Я код накидал выше, он позволяет выкачивать RDD гораздо быстрее в нашем случае.
Выше — это в статье? Не могу найти.
Пример простой задачи. Нужно сжать, зашифровать и скопировать 100 млн. файлов из хранилища А в хранилище Б. Алгоритмически, время считывания файла из хранилища мизерно, по сравнению со временем сжатия и копирования файла. Задача легко решается на Hadoop/Spark — удобно, если грохается операция по причине временных внутренних ошибок, она перезапускается снова.
Это типичный кейс data parallel задачи. При чем же тут локализация хранения данных и процессов, работающих с ними?
Это типичный кейс data parallel задачи. При чем же тут локализация хранения данных и процессов, работающих с ними?
Еще пример. Spark по дефолту использует немалую часть ОЗУ для кэширования промежуточных результатов трансформации RDD. Считывание RDD во многих задачах (у нас так) происходит в самом начале. Затем данные трансформируются в памяти. Алгоритмически не очень важно, где данные лежат — в файле на диске, в HDFS, в s3 — это 5% времени выполнения алгоритма.
Я к тому, что не стоит привязываться к концепции хранить данные именно в HDFS рядом с воркерами, их обрабатывающими. Идея хорошая, но Spark пошел гораздо дальше и, кстати, заметьте, он хранит временные данные, которые не помещаются в ОЗУ не в HDFS, а на локальных дисках.
Я к тому, что не стоит привязываться к концепции хранить данные именно в HDFS рядом с воркерами, их обрабатывающими. Идея хорошая, но Spark пошел гораздо дальше и, кстати, заметьте, он хранит временные данные, которые не помещаются в ОЗУ не в HDFS, а на локальных дисках.
Это типичный кейс data parallel задачи. При чем же тут локализация хранения данных и процессов, работающих с ними?
Так именно что data parallel, а не map-reduce, о чём я и говорю. Вместо Spark можно взять Storm, чистый Akka Cluster, любую реализацию MPI или просто 20 инстансов приложения, и результат будет точно таким же.
Считывание RDD во многих задачах (у нас так) происходит в самом начале. Затем данные трансформируются в памяти. Алгоритмически не очень важно, где данные лежат — в файле на диске, в HDFS, в s3 — это 5% времени выполнения алгоритма.
Этот пример ещё лучше: если скачивание данных занимает всего 5% времени, то гораздо проще вычитать их напрямую на те же 20 серверов и крутить ими в памяти как угодно, а не только через абстракцию RDD. Т.е. всё это можно делать, и Spark даёт немало инструментов для этого, но к map-reduce не имеет к этому никакого отношения. А если у нас нет map-reduce, то и список возможных инструментов сильно расширяется. Но это уже совсем другой разговор.
он хранит временные данные, которые не помещаются в ОЗУ не в HDFS
С точки зрения внутреннего устройства, центральное понятие Spark-а — это партиция, т.е. данные, которые хранятся на одной машине и обрабатываются одним процессом (см. метод RDD.compute()). Т.е нам уже известно, где будут обрабатываться данные. Тогда логично, что партицию сохраняют на ту же машину.
К сожалению, гоняем одно и тоже из пустого в порожнее :-) Но, думаю, мы понимаем друг друга хорошо.
Но стало интересно, откуда так распространилось заблуждение, что MapReduce без Data Locality — мало полезен :-) Снова прочитал исходную статью создателей концепции, коллег из Google. Глянул в википедию английскую — может там написали что вредное, не нашел. Посмотрел в глаза Доугу, глаза серьезные :-)
Везде подчеркивается, что основной смысл парадигмы MapReduce — позволить разработчикам писать в функциональном стиле функи Map и Reduce. А об остальном позаботится платформа. Пожелание к платформе — отказоустойчивость, эффективный shuffle ключей к значениям. И немного лишь написано, что эффективнее будет, если данные будут читаться локально в п. 3.4 папера гугла.
Поэтому я не понимаю, поясните, откуда и где вы взяли идею главенствования локальности данных? :-)
Везде подчеркивается, что основной смысл парадигмы MapReduce — позволить разработчикам писать в функциональном стиле функи Map и Reduce. А об остальном позаботится платформа. Пожелание к платформе — отказоустойчивость, эффективный shuffle ключей к значениям. И немного лишь написано, что эффективнее будет, если данные будут читаться локально в п. 3.4 папера гугла.
Поэтому я не понимаю, поясните, откуда и где вы взяли идею главенствования локальности данных? :-)
Да пожалуйста, открываем Википедию и видим:
Про пункт 3.4 пейпера, который так и называется — Locality — вы уже сами написали. Обратите внимание, что алгоритм всегда пытается размещать воркеров на тех машинах, где есть реплика данных (т.е. вариант, когда они на разных машинах, даже не рассматривается), и только если это невозможно из-за загруженности машин, обработка запускается в другом месте. На практике 95-100% работы выполняется локально.
Если вам мало этого пунтка в пейпере, обратите внимание на схему, где явно указаны read и remote read. Да и если вчитаться, думаю, будет ещё много упоминаний про это.
Зачем читать биографию Дуга Каттинга — не знаю, он не только Хадупом отличился.
Вообще, необходимость локальности становится очевидной, когда начинаете работать с действительно большими данными. В одной из последних задач нам нужно было выкачивать 0.5Tb данных из S3 и обрабатывать их на Spark. Выкачивание и складывание на HDFS занимало час, обработка (вместе с чтением из HDFS) — 40 минут. Вот такая математика.
«Map» step: Each worker node applies the «map()» function to the local data, and writes the output to a temporary storage.
Про пункт 3.4 пейпера, который так и называется — Locality — вы уже сами написали. Обратите внимание, что алгоритм всегда пытается размещать воркеров на тех машинах, где есть реплика данных (т.е. вариант, когда они на разных машинах, даже не рассматривается), и только если это невозможно из-за загруженности машин, обработка запускается в другом месте. На практике 95-100% работы выполняется локально.
Если вам мало этого пунтка в пейпере, обратите внимание на схему, где явно указаны read и remote read. Да и если вчитаться, думаю, будет ещё много упоминаний про это.
Зачем читать биографию Дуга Каттинга — не знаю, он не только Хадупом отличился.
Вообще, необходимость локальности становится очевидной, когда начинаете работать с действительно большими данными. В одной из последних задач нам нужно было выкачивать 0.5Tb данных из S3 и обрабатывать их на Spark. Выкачивание и складывание на HDFS занимало час, обработка (вместе с чтением из HDFS) — 40 минут. Вот такая математика.
Я похоже понял, где затык у нас :-)
Я отстаиваю точку зрения, что часто не важно, где данные хранятся изначально. Spark будет вначале всасывать их в ОЗУ с s3, с HDFS, с Луны всеми нодами и формировать RDD, чтобы затем прогнать по цепочке, допустим мапперов. Разумеется, конечно, после первого маппера и shuffle — данные станут нафиг другими, могут вырасти в размере в 1000 раз от того, что хранилось первоначально в HDFS и разойдутся по воркерам и каждый, допустим, редьюсер будет работать со своим ключем локально. Если бы он не работал локально — для получения каждого значения пришлось бы ходить по TCP/IP, что смертоубийственно :-) Это мы хорошо с вами понимаем.
Во время выполнения DAG Spark, как сами понимаете, не будет скорее всего уже что-то читать из HDFS — если ОЗУ достаточно, он все уже туда втянет и будет тасовать. Иначе смысл использовать Spark без размещения данных в ОЗУ нод кластера.
Т.е. HDFS, s3, Луна — учитываются в момент всасывания данных, и, по закону Амдала, являются последовательной частью алгоритма, которую параллелить иногда бесполезно.
В нашем случае (сейчас над нашими 150ГБ и вашими 500ГБ смеется конечно Google и Facebook) мы вытягивали из s3 150ГБ минут 10, затем колбасили N часов в кластере Spark. Когда положили данные на ноды со Spark — первая часть стала быстрее, а вторая — медленнее на M часов. Когда положили данные рядом на HDFS ноды, стало по времени как ходить в s3 — минут 10.
Дискуссию считаю полезной, т.к. мы определили 2 понятия локальности данных: начальную и рабочую. Начальная по закону Амдала может на время выполнения задания не влиять, а вторая — влияет и очень сильно.
HDFS позволяет сделать именно это: вы не просто распределяете данные на много машин, вы ставите рядом с этими данными воркеров и назначаете этим воркерам задачи над своим локальным куском. Используя S3 вы возвращаетесь к началу и снова тратите время на перетягивание данных от одних серверов к другим.
Я отстаиваю точку зрения, что часто не важно, где данные хранятся изначально. Spark будет вначале всасывать их в ОЗУ с s3, с HDFS, с Луны всеми нодами и формировать RDD, чтобы затем прогнать по цепочке, допустим мапперов. Разумеется, конечно, после первого маппера и shuffle — данные станут нафиг другими, могут вырасти в размере в 1000 раз от того, что хранилось первоначально в HDFS и разойдутся по воркерам и каждый, допустим, редьюсер будет работать со своим ключем локально. Если бы он не работал локально — для получения каждого значения пришлось бы ходить по TCP/IP, что смертоубийственно :-) Это мы хорошо с вами понимаем.
Во время выполнения DAG Spark, как сами понимаете, не будет скорее всего уже что-то читать из HDFS — если ОЗУ достаточно, он все уже туда втянет и будет тасовать. Иначе смысл использовать Spark без размещения данных в ОЗУ нод кластера.
Т.е. HDFS, s3, Луна — учитываются в момент всасывания данных, и, по закону Амдала, являются последовательной частью алгоритма, которую параллелить иногда бесполезно.
В нашем случае (сейчас над нашими 150ГБ и вашими 500ГБ смеется конечно Google и Facebook) мы вытягивали из s3 150ГБ минут 10, затем колбасили N часов в кластере Spark. Когда положили данные на ноды со Spark — первая часть стала быстрее, а вторая — медленнее на M часов. Когда положили данные рядом на HDFS ноды, стало по времени как ходить в s3 — минут 10.
Дискуссию считаю полезной, т.к. мы определили 2 понятия локальности данных: начальную и рабочую. Начальная по закону Амдала может на время выполнения задания не влиять, а вторая — влияет и очень сильно.
Spark будет вначале всасывать их в ОЗУ с s3, с HDFS, с Луны всеми нодами
Только вот скорость считывания с HDFS будет ограничена исключительно скоростью работы с диском, а вот S3 будет ограничена и диском, и сетью, которая как бы одна на всех.
Впрочем, убеждать вас в чём-то я не собираюсь: у вас принципиально не те задачи и не те объёмы, для которых важна локальность данных. Появлятся те задачи, сами всё прочувствуете.
Во время выполнения DAG Spark, как сами понимаете, не будет скорее всего уже что-то читать из HDFS — если ОЗУ достаточно, он все уже туда втянет и будет тасовать. Иначе смысл использовать Spark без размещения данных в ОЗУ нод кластера.
Прелесть абстракции RDD как раз в том, что это ленивая коллекция данных, т.е. данные будут читаться с диска только по мере надобности. Это тоже чертовски важный аспект, потому что если у вас 20Тб данных на диске, но вам нужно найти только 10 записей, то в памяти в любой момент времени будет не больше этих самых 10 записей.
Когда положили данные на ноды со Spark — первая часть стала быстрее, а вторая — медленнее на M часов.
На ноды со Spark — это просто на локальный диск? Если да, то скорее всего вы не дали шедулеру самому распределить работу между нодами, вот и получилось, что некоторые справлялись быстрее нужного, а другие отставали и тормозили весь процесс.
сейчас над нашими 150ГБ и вашими 500ГБ смеется конечно Google и Facebook
500Гб — это ежедневный прирост свежих данных. А алгоритмы могут гоняться и за 1, и за 7 и за 30 дней. Добавьте к этому, что RAM-а у нас всего 2Tb, и становится совсем не смешно. Вот в такой ситуации и приходится думать про локальность, избирательное кеширование и прочие оптимизации.
Ну и да, попробуйте всё-таки придумать, чем Spark без локальности данных может быть лучше чем, скажем, голый Akka Cluster.
Да ничем не лучше, все ляжет к черту. С вашего позволения только поднимусь на уровень выше к модели акторов. Они же тупые, акторы, читают сообщения, выполняют и отвечают результатами. Но! Если хранить очередь сообщений на той же машине, где и актор-получатель (только не в HDFS, а локально на диске, что Spark и делает, сохраняя не помещающиеся в памяти данные на диск — тормозя конечно при этом все и вся) — все станет подобно Spark.
Что можно сделать на Mahout, что нельзя написать на Scala/Spark?
Ну это совершенно разные технологии, в принципе.
Mahout в последних вресиях как раз и построен на Spark. По крайней мере они были в процессе переезда, когда я смотрел на них последний раз.
Другое дело, что Mahout — это библиотека готовых алгоритмов, а не фреймворк. Т.е. ваш вопрос звучит примерно как «что можно сделать на Apache 2, что нельзя сделать на C».
Другое дело, что Mahout — это библиотека готовых алгоритмов, а не фреймворк. Т.е. ваш вопрос звучит примерно как «что можно сделать на Apache 2, что нельзя сделать на C».
Коллаборативная фильтрация на Scala/Spark пишется в 100 строчек кода без всякого УГ как Mahout (вы пробовали с его документацией разбираться?), даже без MLLib.
Да пробовали ее в MLlib ALS — тормозит и падает. Сырой еще MLlib имхо.
Не, так ради б-га, если у вас есть время, знания и силы писать свой алгоритм, то никто не запрещает. Только не всегда это возможно и не всегда имеет смысл. Мне вот сейчас нужна реализация ограниченной машины Больцмана на Spark, но, даже имея опыт её реализации для одной машины, я боюсь браться за эту задачу — долго и муторно. И я думаю, сделать свою коллаборативную фильтрацию для большинства пользователей Spark-а будет ещё дольше и ещё муторней.
Да откуда время то? Конечно сначала ищешь готовое. Благо MLlib довольно активно развивается. Кстати, пробовали на вкус уже www.tensorflow.org?
Для коллаборативки мы взяли из Mahout простую библиотечку Mahout taste, чуть дописали и задача была решена.
Для коллаборативки мы взяли из Mahout простую библиотечку Mahout taste, чуть дописали и задача была решена.
Да откуда время то? Конечно сначала ищешь готовое. Благо MLlib довольно активно развивается. Кстати, пробовали на вкус уже www.tensorflow.org?
Нет, не пробовал. Но у меня и область интереса немножко другая, так что в ближайшее время и не планирую.
Попалась реализация RMB на Spark, может будет полезной ссылочка: deeplearning4j.org/restrictedboltzmannmachine.html
Видел, не понравилось. Вернее даже не так, я в нём по итогу так и не разробрался, т.е. документация касающаяся Spark неполна, но то, что я увидел в коде, меня как-то не впечатлило. D4J имеет поддержку CPU, GPU и Spark за счёт другой библиотеки — ND4J, которая вроде как предоставляет универсальные многомерные массивы, способные работать на всех трёх платформах. Вы пишете один раз, а он автомагически начинает работать везде.
Проблема в том, что CPU, GPU и Spark — это ну очень разные платформы. Очень часто, в т.ч. в конкретном случае с RBM, алгоритмы должны специально адаптироваться для каждой платформы. Здесь же я не нашёл ничего такого ни в коде, ни в комментариях. Возможно, я дико ошибаюсь, но, опять же, мне быстрее написать свою реализации RBM на MLlib, чем разбираться в их коде.
Проблема в том, что CPU, GPU и Spark — это ну очень разные платформы. Очень часто, в т.ч. в конкретном случае с RBM, алгоритмы должны специально адаптироваться для каждой платформы. Здесь же я не нашёл ничего такого ни в коде, ни в комментариях. Возможно, я дико ошибаюсь, но, опять же, мне быстрее написать свою реализации RBM на MLlib, чем разбираться в их коде.
Ну в итоге-то много денег заработал компании? Или это всё так — популизм.
«А давайте возьмём эту хрень и перепишем её на spark»…
«А давайте возьмём эту хрень и перепишем её на spark»…
Местами статью больно читать:
дифференциальные вычисления, линейную алгебру, теорию вероятности, машинное обучение, графы и обучение на них, логистическую регрессию, линейный дискриминантный анализ и так далееСмесь из разделов математики и конкретных алгоритмов, непонятно как взаимосвязанных. К тому же дифференциальные вычисления никаким боком к большим объемам данных не относятся. Так же как и обозначенные алгоритмы — это то, что можно делать с данными (не обязательно большими), но чтобы работать с большими данными знать это сосвем не обязательно
Но вдруг, перед релизом, или когда данных окажется больше, чем вы ожидали, вы обнаружите, что этот алгоритм не работает в «параллельном режиме», не работает через MapReduce — им можно загрузить только одно ядро процессора. Поэтому вам нужно будет экстренно и заново изобрести еще один алгоритм, который умеет работать параллельно, и придумать, как он должен работать в парадигме MapReduce.Вы это серьезно, переделывать алгоритм для работы на кластере нужно обязательно непосредственно перед релизом? Может для начала при выборе алгоритма стоит проверить, как он работает на кластере из виртуалок? Или хотя бы в локальном режиме MapReduce?
Spark — берет, выполняет все задания, а затем выгружает результатПри этом на каждом shuffle бережно складывая данные на жесткий диск и затем вычитывая их
Можно кинуть в ответ Apache Tez или отыскать что-нибудь мелкое в зоопарке Apache — но, поверьте, для снижения рисков лучше использовать mainstream-технологии, которые развиваются в ногу с рынком.Apache Tez — это mainstream для Apache Hive. Никто в своем уме сейчас не использует Apache Hive поверх MapReduce: либо Hive+Tez, либо Impala или аналог
Полученные результаты мы выгружаем в Apache Mahout и на выходе получаем конкретные рекомендации для клиентаЗачем вам Apache Mahout и чем не понравился Spark MLlib? К слову сказать, Apache Mahout мертв чуть более чем 3 года
Deep learning — это, простыми словами, «качественное» машинное обучение, подразумевающее очень детальное изучение проблемы машиной и, часто, использование многослойной рекуррентной нейронной сетиDeep не имеет отношения к качеству и детальности проработки, а означает «глубину» (количество слоев) обучаемой сети
Также, все более активно используются HBase, Casandra, Mahout, Spark MLLibКак я уже написал выше, Mahout мертв и имеет скорее отрицательную динамику использования. Также странно видеть в одном ряду два Key-Value хранилища и подпроект Spark для машинного обучения
DAG (directed acyclic graph) vs Hadoop MapReduce vs Hadoop Streaming.DAG — абстракция уровня исполнения задачи в Spark, Hadoop MapReduce — фреймворк для обработки данных на кластере, Hadoop Streaming — дефолтный job MapReduce, который передает данные в виде текста стороннему приложению и получает от него результат. Как они могут быть в одном списке?
Streaming реализован в Spark гораздо лучше, чем в Hadoop, им гораздо удобнее пользоваться и работает часто эффективнее, за счет кэширования данных в памяти.Как уже писали выше, MapReduce Streaming и Spark Streaming — вещи абсолютно разные
Удобные коллекции: filter, map, flatMapПостойте, filter — это коллекция, вы уверены?
Master-машины, которые контролируют вообще весь кластер. На них установлен Spark MasterТакой вещи как Spark Master нет. Spark Master — это просто jar'ник Apache Spark, стартовавший с определенными параметрами. Это штука динамическая и зависит от того, в каком режиме вы запускаете Spark
Core-машины, на которых развернута файловая система — HDFS. Их может быть несколько штук. Правда, рекомендуется только увеличивать количество core-машин, а не уменьшать, иначе теряются данные.Вы это серьезно? Слышали ли вы о таких вещах, как HDFS Node Decommission, HDFS Balancer, replication factor?
Для всего остального используются task-машины. Это обычные Spark-серверы, на которых работают воркерыВот это — sparc-серверы, а то, о чем вы пишете, это просто ноды вашего кластера, предназначенные для запуска процессов Spark
В Yarn-кластерах, как и в Oracle, используется множество настроек, и, по хорошему, нужен админ, который в этом очень хорошо разбираетсяДа, для работы с кластером Hadoop нужны определенные знания. Но если вы пишете статью, то как бы подразумевается, что вы этими знаниями обладаете
Что такое Reduce? Когда в один worker собираются сгруппированные по одному ключу данныеВ один worker… Коллеги, вы видели когда-нибудь настройку mapreduce.job.reduces? Один — это значение по умолчанию, их может быть сколько угодно. В Apache Spark же это задается дефолтным уровнем паралелизма и количеством партиций в целевом RDD (практически все трансформации принимают как параметр количество партиций в целевом RDD). При этом значение по умолчанию — не 1, а количество партиций в исходном RDD
Допустим, вам нужно выгрузить из Spark данные в модель. Если объем велик, то это будет выполняться очень долгоА сохранить в ту же HDFS и вычитать оттуда? А записать через тот же JdbcRDD в любимый MySQL?
Не буду отвечать. Комментарий в стиле «привет от капитана Очевидность» :-)
Вопрос скорее в том, что некоторые вещи позволительно сказать при живом выступлении — ошибиться в ряде терминов, назвать что-то неправильно и т.д. Это допускается, так как выступление — это зачастую импровизация. Но когда вы пишете статью ожидается, что вы проверите приведенные факты и высказывания перед публикацией, ведь в отличии от живого выступления времени на это у вас достаточно
Да все я проверил и хорошо понимаю технологию и мы ее используем не один год, вы придираетесь просто :-)
Deep не имеет отношения к качеству и детальности проработки, а означает «глубину» (количество слоев) обучаемой сети
А вы правда думаете, что DeepLearning делается только на нейронных сетях? :-)
Зачем вам Apache Mahout и чем не понравился Spark MLlib? К слову сказать, Apache Mahout мертв чуть более чем 3 года
Да сырой еще сильно MLLib. А ML (бизнес-процессы для MLLib) там вообще детский сад еще, бардак с интерфейсами полнейший.
k-means с ходу упал, неаккуратно реализован и неадекватно использует память, переписывать пришлось полностью.
ALS-коллаборативка — глючная, падает через раз. Алгоритмов мало. Работа с матрицами — пока примитивнейшая. До python scikit-learn еще далеко.
DAG — абстракция уровня исполнения задачи в Spark, Hadoop MapReduce — фреймворк для обработки данных на кластере, Hadoop Streaming — дефолтный job MapReduce, который передает данные в виде текста стороннему приложению и получает от него результат. Как они могут быть в одном списке?Правда? Вот это да.
Как уже писали выше, MapReduce Streaming и Spark Streaming — вещи абсолютно разныеСерьезно? ;-)
Такой вещи как Spark Master нет. Spark Master — это просто jar'ник Apache Spark, стартовавший с определенными параметрами. Это штука динамическая и зависит от того, в каком режиме вы запускаете SparkВ амазоне такая вещь, извините, есть. В данном случае это машина с драйвером Spark. Это никакой не jar, а приложение с кучей открытых портов и жрущее немало памяти. Зачем называть приложение словом — jar ;-)
Вы это серьезно? Слышали ли вы о таких вещах, как HDFS Node Decommission, HDFS Balancer, replication factor?Читайте внимательно, я про EMR. Не читаете внимательно, а пишете комментарий.
А сохранить в ту же HDFS и вычитать оттуда? А записать через тот же JdbcRDD в любимый MySQL?Вы не поняли проблему. Что такое HDFS я прекрасно знаю. Зачем писать в MySQL тоже не пойму.
А вы правда думаете, что DeepLearning делается только на нейронных сетях? :-)
Думаю, да. То есть, некоторые виды сети можно, конечно, назвать марковским случайным полем, и это тоже будет правильно, но нейронными сетями они от этого быть не перестанут.
А как же варианты байесовских сетей доверия и Q-leaning? Все на нейронках сидят?
А как же варианты байесовских сетей доверия
Если байесовские сети доверия — это deep belief networks, то да, они одновременно являются и нейронными сетями. Если же вы имеете ввиду bayesian networks вообще, то тфу тфу тфу, нейронными сетями их ещё обозвать не успели, но и приставка deep к ним не применяется.
Q-leaning
Про Q-learning я знаю абсолютно ничего, но единственная работа, связанная с чем-то глубоким, на которую ссылается Педивикия, явно говорит про deep neural network. Если есть что-то ещё, кидайте ссылку, будем разбираться.
Хорошо, спасибо. Я где-то читал, что deep learning это хотя в целом нейронки, но не всегда — зачем ограничивать себя одной технологией. Как вспомню где и что, обещаю скинуть.
Deep learning — это именно нейронки по определению, т.к. «deep» относится именно к сетевым структурам, а всё, что сеть, можно назвать нейронкой (даже если вся суть взята из других видов сетей).
Другой вопрос, что есть representation learning — автокодировщики и RBM, основные составные блоки глубоких сетей. Вот их можно использовать и вне контекста нейронок, например, для рекоммендательных движков или уменьшения размерности.
Другой вопрос, что есть representation learning — автокодировщики и RBM, основные составные блоки глубоких сетей. Вот их можно использовать и вне контекста нейронок, например, для рекоммендательных движков или уменьшения размерности.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Apache Spark в «боевых» проектах — опыт выживания