Spark: дата-майнинг до 30x быстрее Hadoop

[@DanielWolf]

интересно, а блоках биткойна 30х он сделает?

[@Kindman]

А, на php к нему можно подключиться?

[@whynot]

Круто, давайте на пыхе еще научные вычисления делать. Хотя, судя по вопросу, вы или полный и беспросветный даун (ПОДКЛЮЧИТЬСЯ НА ПХП К ФРЕЙМВОРКУ ДЛЯ КЛАСТЕРНЫХ ВЫЧИСЛЕНИЙ??777) или что-то еще. Хотя нет, первый вариант.

[@xhumanoid]

рассматривая hadoop мы имеем thrift интерфейс, а следовательно:
1. доступ на hdfs
2. доступ к состоянию джобов и их управление
3. доступ к hive и как следсвие sql-подобному языку для выполнения запросов на mr

А учитывая, что thrift может скомпилить схему и под php, то получаем доступ к кластеру хоть из пыха, хоть из си, хоть с питона.

Не путайте возможность подключения и отправку запросов на выполнение и сами вычисления.

[@xhumanoid]

основная фишка в том, что часто используемые данные кешируются в
памяти, у хадупа как таковое главный тормоз это hdfs, в качестве постоянного хранилища у этого sparky используется… упс hdfs или s3 от amazon, в итоге стоит данным не влезть в память и сразу же мы в какашке.

В данный момент hadoop уже достаточно имеет поддержки на уровне больших кампаний, а фреймворков которые превосходят по тестам hadoop более чем достаточно.

очередной пример — piccolo.news.cs.nyu.edu/ (извиняюсь ссылку на хабр найти не могу, точно знаю что уже проскакивала она где-то здесь)

правда там таже проблема — все данные в памяти и мы рады, а вот что делать если данные в память не влазят?

[@xhumanoid]

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

[@Ghostwriter]

>Увеличение производительности до 30х возможно на специфических задачах, в которых идёт постоянное обращение к одному и тому же набору данных.

Может следовало не писать отдельный фреймворк, а сделать контриб-патч в сам hadoop?..