Comments 11
Честно говоря, непонятен посыл статьи. 1 час кластера в 100 серверов дороже или дешевле дня работы программиста-оптимизатора?
А что делать если вы студент-дипломник и у вас нет кластера? Да и на большом кластере когда работают 20 программистов-неоптимизаторов тоже становиться некомфортно...
Ну а посыл в том что даже на одном ноуте можно получить бенефит используя технологии и методы работы с большими данными.
Ну а посыл в том что даже на одном ноуте можно получить бенефит используя технологии и методы работы с большими данными.
2 Гб, пусть и в сжатом виде, это уже большие данные? Странно. Я то считал большими данными то, что не помещается на одном сервере.
И не понятно, чем занимался кластер из 100 машин, если на каждую приходилось по 20 Мб сжатых данных. Подозреваю, что это был hadoop кластер и обработка графа выполнялась с помощью MapReduce?
И не понятно, чем занимался кластер из 100 машин, если на каждую приходилось по 20 Мб сжатых данных. Подозреваю, что это был hadoop кластер и обработка графа выполнялась с помощью MapReduce?
Да, на каждый мэппер всего по 20мб. Но каждые 20мб очень быстро превращаются в 2Гб так как "количество узлов, между которыми существуют пути длины 2, на несколько порядков больше, чем количество прямых связей в графе".
Обрабатывать "в лоб" пробовали и на Spark, и на Pig, и на Pig + Tez. Спарк с пигом отработали норм, а тез залажал — начал делать хэш-джойн вместо мерж джойна и получил 3 часа в итоге
Попробуйте ;)
Обрабатывать "в лоб" пробовали и на Spark, и на Pig, и на Pig + Tez. Спарк с пигом отработали норм, а тез залажал — начал делать хэш-джойн вместо мерж джойна и получил 3 часа в итоге
Попробуйте ;)
Пробовал считать граф, в котором было примерно 20 млрд вершин и 1,5 трлн ребер на кластере меньше 100 машин. Подход MapReduce для графов совершенно не подходит. Spark интересный и перспективный инструмент, но и он не подходит для работы с графами. Есть GraphX, который будет оптимальней. Правда до тех пор, пока данные помещаются в оперативной памяти.
С очень большими графами на момент, когда я его смотрел, он работать не мог :-(
С очень большими графами на момент, когда я его смотрел, он работать не мог :-(
Ну про "совсем не" я бы не говорил — все сильно зависит от задачи. Получалось делать в рамках мапреда весьма интересные вещи с графами малой кровью, а спарк с итеративностью и кешом вообще норм. Выбор и специализированных графовых тулов сечас вполне ничего, но с большими графами проблемы бывают не только у graphx.
И есть еще ньюанс — в данном случае нам на самом деле надо не только посчитать общих друзей, но и потом собрать тренировочное множество, натренировать регрессию и записать результат в нужном виде. И тут "шейцарский нож" спарка подходит в самый раз, позволяя решить все нужный задачи в одном инструменте, да еще и сохранить возможность проделать все на минимальных ресурсах.
И есть еще ньюанс — в данном случае нам на самом деле надо не только посчитать общих друзей, но и потом собрать тренировочное множество, натренировать регрессию и записать результат в нужном виде. И тут "шейцарский нож" спарка подходит в самый раз, позволяя решить все нужный задачи в одном инструменте, да еще и сохранить возможность проделать все на минимальных ресурсах.
Теперь давайте представим, что пользователей 20 млдр, у каждого 200 друзей. Это уже достаточно большие данные.
Как будет работать ваше решение? Ведь граф придется делать распределенным, на одной машине он не поместится даже на жесткий диск.
Как будет работать ваше решение? Ведь граф придется делать распределенным, на одной машине он не поместится даже на жесткий диск.
Ну нам то надо всего 1М пользователей ;). На самом деле поскольку процесс итеративный и с фильтрацией, то потенциально даже на одной ноде можно подсчитать общих друзей и на гораздо более крупном графе.
Ну и при наличии кластера подход с одним шаффлом все равно быстрее. А при использовании спарка можно организовать итеративный процесс так, что из памяти на диск будут писаться только итоговые отфильтрованные результаты, а сам граф и данные шаффлов будут идти память-сеть-память, без диска. Работать будет в разы быстрее чем "в лоб", ± сравнимо с графлабом (хотя там, конечно, можно затюнить еще круче, если запариться).
Ну и при наличии кластера подход с одним шаффлом все равно быстрее. А при использовании спарка можно организовать итеративный процесс так, что из памяти на диск будут писаться только итоговые отфильтрованные результаты, а сам граф и данные шаффлов будут идти память-сеть-память, без диска. Работать будет в разы быстрее чем "в лоб", ± сравнимо с графлабом (хотя там, конечно, можно затюнить еще круче, если запариться).
Так ведь статья о применении подхода работы с большими данными :-)
В реальной жизни для обработки действительно большого графа (например web-графа) вам потребовалось бы реализовывать например pregel (http://web.stanford.edu/class/cs347/reading/pregel.pdf). На spark такое считать совсем не рентабельно. Однако для небольших графов, которые не являются big-data и помещаются на одной машине он не эффективен.
В реальной жизни для обработки действительно большого графа (например web-графа) вам потребовалось бы реализовывать например pregel (http://web.stanford.edu/class/cs347/reading/pregel.pdf). На spark такое считать совсем не рентабельно. Однако для небольших графов, которые не являются big-data и помещаются на одной машине он не эффективен.
Статья о пользе от технологий "больших" данных для тех кто привык пользоваться технологиями "маленьких" (R, Python). Как типичный студент/аспирант может показать хороший результат на SNA Hackathon 2016 не покидая свой уютный ноутик.
Как Вы думаете: убьёт ли Scala питон в нише прототипирования?
Sign up to leave a comment.
О пользе технологий больших данных в повседневной жизни