докер есть, отдельно есть уже более гранулированные (брокер, ноды)
в свое время вообще делал просто «скачал, распаковал, запустил дефолт», а уже дальше думаешь что тебе нужно
для начала хватит и одной машинки-инстанса, на котором все 3 типа запустить, примеры у них тоже неплохие
для визуализации (пока еще достаточно сырое, но уже от реста избавляет в простейших случаях) Imply. да и quickstart там описывает как запустить в одну команду, к тому же у него есть и свежий docker
а в druid просто нету sql, от слова СОВСЕМ
хотя сейчас imply что-то и пытается делать транслятор, но работы еще вагон
я бы понял, если бы сравнили druid c Pinot, но с редшифтом это уж слишком.
>> Ну column-ориентированные же?
по хорошему, сегмент в друиде это bitmap индекс, что и объясняет, почему select у них появился совсем не сразу, да и сейчас используется только для отладки, так как тормозной до ужаса.
column-ориентированные зачастую преподносят почему вам не нужны индексы, тут же только индексы и есть.
>> Нет уникальных ключей и т.п
в друид вообще нету понятий ключей, есть dimention и событие в append-only виде, ни обновлений ни изменений нету
Druid к Redshift это как теплое к мягкому
второй это честный sql
первый заточенность на агрегациях поверх псевдо-olap, да еще и без join'ов (хотя свое дело и делает хорошо в этой части если данные денормализованы)
>> Сейчас HSA Foundation насчитывает семь компаний, которые являются основателями данной организации: AMD, ARM, Imagination Technologies, MediaTek, Texas Instruments, Samsung Electronics and Qualcomm®.
Если пару лет назад это было горячей темой и Qualcomm и Samsung обещали свои следующие мобильные чипы выпускать с поддержкой данной технологии, то сейчас с этим как-то немного глухо. Из реализаций присутствует только у AMD. Учитывая большой скрип с которым вводится даже opencl, то выход на потребительский рынок hsa смотрится немного грустно.
Есть ли какая-либо дополнительная информация стоит ли вообще ждать каких либо продуктов от других вендоров или нет?
возможно не по адресу, но возвращаясь к вашим словам про то, что сами девелоперы не имеют нужного вам железа.
Пример очень простой: IntelliJ IDEA (ну и все продукты построенные на ней), сохранение файла-проекта, запросы на индексацию, разворачивание шаблонов в CLion и еще много достаточно тяжелых операций отправляются на выполнение через event dispatch который выполняется на 1 потоке AWT-EventQueue-0 и сам jetbrains не собирается ничего менять, так как есть более приоритетные таски.
По итогу получаем, что с одной стороны вы говорите про то, что не можете использовать CUDA/GPU/векторизацию, но в тоже время сами не сделаете активную загрузку всех имеющихся обычных x86 ядер, а продолжаете все процессить в 1 потоке, как это было 10 лет назад. хотя стоит признать, что подвижки небольшие в этом направлении все-таки есть и все активней начинают и другие ядра загружаться на типовых операциях.
p.s. я понимаю, что действительно фичи раньше были в большем приоритете, так как нужно было заинтересовать обновляться, но после слов о том, что это оказывается пользователи вас сдерживают в развитии остался небольшой осадок.
ну давайте быть честными, в момент становления sbt тот же gradle был не намного лучше
так как до версии 1.0 в нем очень часто после очередного milestone отваливался билд, пока не снесешь кеш в домашней директории на сборке ошибка писалась совсем не интуитивно понятная, а после сноса кеша резко все продолжало работать.
поэтому и развивались они параллельно, а менять сейчас смысла нету, так как свою задачу в данный момент делают оба
p.s. я уже не раз имел спор с билд инженерами чем вам (maven/gradle/sbt) не угодил, а выбрали (maven/gradle/sbt), ведь я могу с помощью него сделать все тоже, что вы делаете на своем. в общем это холивар =) причем очень жестокий. в любой системе можно сделать как вменяемый билд скрипт, так и такой что никто его не осилит
>> Spark можно собрать под 2.11 начиная с версии 1.2 или вроде того.
вот именно, поэтому найти в природе 2.11 немного проблематично, даже на офф сайте
«Note: Scala 2.11 users should download the Spark source package and build with Scala 2.11 support.»
а просто взять и использовать нельзя…
>> так что все не должно сломаться.
ага, сломается только половина
я не противник скалы, сам регулярно её использую для прототипов и небольших проектов, но начинать серьезный проект который нужно будет поддерживать годами я морально не готов, так как все эти изменения немножко напрягают. сам подход bytecode мы ломаем постоянно, а source level «всего» через раз отпугивают от scala очень много компаний. тут компании задумываются над тем, что обновлять java каждые 18 месяцев это слишком часто, давайте нам релиз цикл хотя бы 2 года, а вы со scala предлагаете каждые 2 года заставлять их переписывать код.
как минимум он решает проблему, что для зависимостей с разными версиями скалы нужны разные версии билдов
зависимость собранная для скалы 2.10 не взлетит если у вас проект на 2.11 и тд
то есть главные смысл в автоматическом мэтчинге нужной версии скалы
но по мне это пример костыля, который пытается маскировать основную проблему «между версиями плывет байткод»
ну а второй момент политический: зачем нам мэйвен если мы можем и сборщик тоже использовать со скалой, в итоге scala everywhere
>> Не без проблем, конечно, но полет нормальный
>> на нем есть большие проекты, например, Apache Spark
тогда может нам еще расскажите про совместимость между версиями?
Spark до сих пор используют scala 2.10.4, так как переехать на 2.11 свежее требует достаточно много ресурсов.
а дальше будет 2.12 которая вроде как обещают совместимость с 2.11, но хз-хз, так как работу с лямбдами полностью переделали
а после 2.13 в которой collections полностью обещают переделать, в итоге нету вообще никакой гарантии что даже на уровне source code будет работать.
или может расскажите про play?
если у вас проект на play со смесью java и scala и вам нужно смигрировать с play 2.1 на последние версии java, то резко оказывается что scala 2.9 не переваривает байткод от восьмерки, нужно обновить скалу до свежей версии,
обновляем скалу и нарываемся на второй пункт — 2.1 собран только под scala 2.9, под свежую скалу нету его, следовательно просто java обновить вы не можете, нужно обновлять и скала и сам плей
плей между версиями меняет api следовательно опять секс =)
итого: смена language level с 7 на 8 для scala части выливается в обновили scala core / all frameworks / fix all changed api
вообще если подойти более обще, то оказывается, что тот же typesafe пытается как-то объяснить Одерскому, что меняя api и ломая байткод каждую версию в серьезные проекты залезть сложно, на что получает закономерный ответ «нужно больше фич, а поддержка и совместимость это вторично»
>> Почему я уверен в том, что этот запрос Марка будет удовлетворен сообществом:
2 пункта в подтверждение, но вот 3й как раз в тему почему некоторые в сообществе считают, что может лучше уже и на 10ку скинуть модули, так как их первоначально вообще в 7ку обещали и где гарантия, что из-за них в мае не придется опять переносить еще на 6 месяцев релиз
можно поискать отдельно как работает map-reduce в хадупе и спарке:
1) фаза map и пишет в память
2) память периодически сбрасывает результаты на локальный диск
3) reduce фаза запрашивает ноды на которых проходили map фазы на получение данных
то есть редьюсеры сами выступают в роли инициатора получения данных, pull модель более устойчивая к отказам, если у нас reduce какой и отвалился, то все входные данные остаются и пересчитать не проблема
flink & mr 2.0 push
1) map отрабатывает и пишет в память
2) подымаются reduce элементы
3) по p2p топологии память стразу транслируется на удаленные машины
4) при необходимости reduce сбрасывает данные на диск после частичного merge, если данные в память не влазят
в push есть проблема, что если у нас reduce упал, то нам нужно еще и map фазу повторить для получения кусочка данных для данного блока, поэтому даже в push остается возможность настройки сброса копии на диск, чтобы можно было потом просто её забрать без пересчета.
Но вообще у нас снижается latency за счет того, что reducer сразу получает входные данные для свертки, без необходимости делать запрос. В классической реализации для снижения latency reducer'ы обычно стартуют чуть раньше чем завершатся все map task'и. этим параметром управляет mapreduce.job.reduce.slowstart.completedmap. 0.1 означает, что как только закончат работу 10% всех мап тасков начнут запускаться редьюсеры и вытягивать себе копии данных, то есть к моменту отрабатывания последнего map есть вероятность, что только его и будут ждать редьюсеры, чтобы скопировать последний кусочек и начать свертку.
1. пачка map фаз в spark'е, точно так же схлопываются в один map в MR задаче вручную, или с использование tez автоматически он пайплайнит задачи. хотя согласен что по красоте спарк выигрывает. про репликацию спорно, когда у вас все машинки по pull модели ломятся на один сервер хорошего мало. map.groupBy.map.groupBy — 2 фазы shuffle и изнасилованный диск, так что не стоит думать что диск так уж редко используется.
2. вы tez проверяли или судите по классическому mr? если классический, то это архитектурная особенность работы jobtracker'а, если уж тогда и сравнивать, то spark-submit на yarn
3. я говорю о глобальных изменениях, rdd по сути только в offheap вынесли, все вещи в dataframe интересные попадают. текущую схему работы без переделки всей архитектуры не поменять, а вот с dataframe еще что-то можно сделать. к тому же я говорю про оптимизацию платформы, не отдельных ваших задач, зачастую улучшение платформы сразу влияние на все задачи оказывает.
та картинка является правдой, НО для итеративной задачи, когда все данные в памяти, в итоге сделали бы они в 2 раза больше итераций еще больший бы разрыв получили. насколько помню там был pagerank, берем графовый giraph или flink delta iteration и получаем точно такие же графики, но на вершине уже спарк. и это тоже будет правдой. бенчмарки они такие…
> Но объективно я вижу, что те же самые задачи стали работать быстрее.
переписанные задачи, перевели бы вы их на impala стало бы еще быстрее местами. переписали на hive+tez другие результаты.
а использовали бы тот же flink и даже переписывать бы не пришлось, 2-3 строки изменить в коде только.
я не против спарка, как инструмент он неплох, как уже говорилось, мы сами его используем. я против того когда начинают хвалить инструмент ссылаясь на мифы, я их перечислил:
1) спарк все в памяти, поэтому такой быстрый, а вот хадуп все на диске
2) спарк реиспользует jvm, а вот хадуп подымает каждый раз новые инстансы
3) rdd универсальней map-reduce (на самом деле rdd это способ представления данных, а map-reduce парадигма вычисления, в спарке map-reduce и использует с небольшими модификациями)
если уже и приводить плюсы спарка, то это:
1) более удобный и высокоуровневый api, следовательно ниже порог вхождения разработчиков и более быстрое написание кода
2) местами более высокая скорость работы, но далеко не все объемы он может переварить, на которых справляется хадуп
3) более удобная обертка для оркестрации задачами, так как все можно делать в основной программе
p.s. по поводу как реиспользование в спарке работает: в спарке подымается воркер и он все задачи обслуживает, в хадупе от этого по умолчанию отказались, так как потенциально может вызвать утечку ресурсов в пределах долгой и нагруженной MR таски, в спарке забили, типо будем считать что утечек нету между отдельными тасками. поэтому в хадупе не проблема в пределах все mr job'ы сказать переиспользовать jvm, а вот в спарке запретить данное поведение уже нельзя.
python api был уже давно, правда он даже в питоне представлялся в виде rdd, проблем с сериализацией и тд был вагон, но это работало и многие математики это использовали.
сами датафреймы добавили как абстракцию уже почти год назад, а для bigdata год это достаточно большой срок, за это время многие продукты рождаются и успевают умереть в забвении =)
ругают не hdfs, а map-reduce как подход, хотя спарк это тот же map-reduce по сути, а вот тут и начинаются мифы… но всегда стоит отделять тех часть от маркетинга
во первых более высокоуровневый api, который хорошо ложится на скалу и неплохо на java 8. совсем первые версии spark в своих rdd по api были совместимы с коллекциями =) такой вот подход «пишем для кластера в манере написания для одной машинки»
тот кто пробовал вручную писать join + aggregation какой-нибудь на map-reduce со мной согласятся, что это немного ад. именно поэтому и появились такие проекты как hive (sql язык манипуляции) и pig (парадигма data stream и работа над стримами данных), которые и снимали с разработчика весь этот низкоуровневый ад.
второй плюс это смесь как классического подхода по обработке данных (императивны и функциональный за счет лямбд) с декларативным (sparksql) и гибкие переходы между ними
ну и третий наверное один из наиболее главных для математиков: он почти нативно поддерживает пандусовские датафреймы, а значит легко интегрируется с уже существующим кодом.
ну а другие «плюсы»: его активно форсят любители скалы, первый коммент это подтверждает ;) точно также как любители clojure форсят storm в качестве примеров больших систем.
в общем как очередная реализацию парадигмы map-reduce с переменных количеством map и reduce фаз в pipeline он очень неплох, да еще и скрывает многие сложности от пользователей.
но даже они признают, что у спарка до сих пор по сравнению с хадупом есть проблемы производительности на очень больших кластерах.
immutable state это не панаценя ( Even though Spark is fast, there’s room for improvement in stream processing. Performance will continue to be a focus area across the platform, but in Spark Streaming in particular, there are some obvious changes we can make, in persistent mutable state management and elsewhere, that will deliver some big benefits. ) и тд.
но я сомневаюсь, что тут найдется много людей с кластерами в тысячи машин, а значит и выходит на первое место удобство использования и порог вхождения. а вот тут спарк выигрывает. хотя последнее время очень активно и flink движется в этом направлении, чего стоят только примеры внедрения flink-forward.org/?post_type=session
немного переслащена статья, как и большинство статей про спарк =)
уж не обессудьте, но:
Т.е все промежуточные данные между Map и Reduce фазами, сбрасывались в HDFS
Стоит сказать что дисковый ввод/вывод всё таки используется (на этапе shuffle)
что такое shuffle если не промежуточный этап между Map и Reduce фазами? хотя в некоторых случаях действительно можно его избежать, если в процессе операции map не менялось партицирование
МapReduce запускает для каждой задачи новую JVM, со всеми вытекающими последствиями
mapred.job.reuse.jvm.num.tasks существует почти с первых версий hadoop, для исключения лишних созданий jvm
Ну и наконец Spark оперирует RDD абстракциями (Resilient Distributed Dataset), которые более универсальны чем MapReduce. которые очень сложно оптимизировать когда вы работаете с ними так как спарк (агрегирующая операция ждет выполнения) и в результате почти все текущие оптимизации вливаются в sparksql, по нему строим дерево и генерируем код
почему-то все в разговорах про спарк опускают запуск hadoop на tez. хотя тут примерно понятно, та же клоудера его демонстративно игнорирует, так как это продукт основного конкурента
причем на более высоком уровне, в отличии от спакра, у которого стриминг это микробатчи. поэтому честная поддержка dataflow сейчас в обсуждении как же сделать это на спарке
я не имею ничего против спарка =) сами используем, но читать в каждой статье хвалебные отзывы про техносовершенство спарка и убогости хадупа тоже напрягает.
Вы же утверждаете, что этот труд не помог есть стать миллардером, а причина в молитве макаронному монстру
делать выводы на основе байткода совершенно неверно, то что в некоторых случаях это сработало, закрепляет неправильные предложения и в итоге уводят в совершенно непонятных направлениях с постепенным превращением всего этого в cargo культ. посмотрите на статью автора с его манипуляциями байткодом с пачкой необоснованных утверждение и статьи Шипилева или Томпсона, разница гигантская, так как у них идет разбор на уровне asm и иногда железа, что же у нас происходит на самом деле.
Пока из их раговора я не понял, кто же прав.
прав некорректный бенчмарк:
1) автор сравнивает не просто add(), но и тут же remove(), что вносит дополнительную погрешность
2) автор утверждает, что методы add() имеют минимальные отличия, на практике в случае if в его тесте метод add() не инлайнится, а идет явный вызов
3) автор утверждает, что методы remove() полностью идентичны, на практике в случае if в его тесте метод remove() не инлайнится (предположительно предыдущий add() сломал оптимизации последующие), а идет явный вызов
по итогу:
1) метод с exception идет линейно, без дополнительных вызовов, к тому же нету случая когда этот exception выбрасывается
2) метод с if сразу производит 15 вызовов функции add() и следом 15 вызовов remove().
что мы вообще меряем? стоимость 30 вызовов функций? логично что вызывать их будет дороже, так как переходы не бесплатны и заметно дороже линейного выполнения кода
причем это не объясняет почему так произошло, только предположения о том, что exception работают быстрее.
на практике в случае с if в его тестах сразу отваливается inlining на add(), а уже потом еще и на remove(). как итог тест полностью бесполезен.
на свежих версиях jdk при срабатывании инлайнинга на обоих методах поведение идентичное, но автора это не останавливает =( начинаются споры по поводу использования в проде старых 6 и 7 версий
Мы изучали скомпилированный байткод для каждого метода и даже изменяли методы так, чтобы они попадали под лимит инлайнинга
Иногда, видя что метод превышает лимит инлайнинга, мы думали о том как изменить его таким образом, чтобы избавится от нескольких байт-инструкций. Например:
Наверное ни для кого уже не секрет, что лимит инлайнинга в Hostpot JVM — 35 байткод инструкций. Поэтому мы уделили некоторое внимание этому методу, чтобы сократить его и изменили его следующим образом:
Получилось довольно близко к лимиту, но все еще 36 инструкций. Поэтому мы сделали так:
Выглядит проще. Неправда ли? На самом деле, этот код хуже предыдущего — 45 инструкций.
Как раз ниже лимита в 35 байткод инструкций. Это маленький метод и на самом деле даже не высоконагруженный, но идею Вы поняли.
извиняюсь за то, что пришлось перепостить половину статьи, но первый раздел как раз по поводу инлайнинга и гадания на байткоде.
Общения в github, где автор на основе идентичности методов утверждает, что в его тесте они тоже работают одинаково радует. так же как и желания тестировать только на старых версиях jvm, которые работают не всегда корректно.
данная опция на версиях jvm, что использует автор крешит jvm на его бенчмарках. А так да, основная масса выводов автором сделана на основе анализа байткода, без самого анализа что же у нас происходит в реале
в свое время вообще делал просто «скачал, распаковал, запустил дефолт», а уже дальше думаешь что тебе нужно
для начала хватит и одной машинки-инстанса, на котором все 3 типа запустить, примеры у них тоже неплохие
для визуализации (пока еще достаточно сырое, но уже от реста избавляет в простейших случаях) Imply. да и quickstart там описывает как запустить в одну команду, к тому же у него есть и свежий docker
плохо искали ;)
хотя сейчас imply что-то и пытается делать транслятор, но работы еще вагон
я бы понял, если бы сравнили druid c Pinot, но с редшифтом это уж слишком.
>> Ну column-ориентированные же?
по хорошему, сегмент в друиде это bitmap индекс, что и объясняет, почему select у них появился совсем не сразу, да и сейчас используется только для отладки, так как тормозной до ужаса.
column-ориентированные зачастую преподносят почему вам не нужны индексы, тут же только индексы и есть.
>> Нет уникальных ключей и т.п
в друид вообще нету понятий ключей, есть dimention и событие в append-only виде, ни обновлений ни изменений нету
второй это честный sql
первый заточенность на агрегациях поверх псевдо-olap, да еще и без join'ов (хотя свое дело и делает хорошо в этой части если данные денормализованы)
Если пару лет назад это было горячей темой и Qualcomm и Samsung обещали свои следующие мобильные чипы выпускать с поддержкой данной технологии, то сейчас с этим как-то немного глухо. Из реализаций присутствует только у AMD. Учитывая большой скрип с которым вводится даже opencl, то выход на потребительский рынок hsa смотрится немного грустно.
Есть ли какая-либо дополнительная информация стоит ли вообще ждать каких либо продуктов от других вендоров или нет?
Пример очень простой: IntelliJ IDEA (ну и все продукты построенные на ней), сохранение файла-проекта, запросы на индексацию, разворачивание шаблонов в CLion и еще много достаточно тяжелых операций отправляются на выполнение через event dispatch который выполняется на 1 потоке AWT-EventQueue-0 и сам jetbrains не собирается ничего менять, так как есть более приоритетные таски.
По итогу получаем, что с одной стороны вы говорите про то, что не можете использовать CUDA/GPU/векторизацию, но в тоже время сами не сделаете активную загрузку всех имеющихся обычных x86 ядер, а продолжаете все процессить в 1 потоке, как это было 10 лет назад. хотя стоит признать, что подвижки небольшие в этом направлении все-таки есть и все активней начинают и другие ядра загружаться на типовых операциях.
p.s. я понимаю, что действительно фичи раньше были в большем приоритете, так как нужно было заинтересовать обновляться, но после слов о том, что это оказывается пользователи вас сдерживают в развитии остался небольшой осадок.
так как до версии 1.0 в нем очень часто после очередного milestone отваливался билд, пока не снесешь кеш в домашней директории на сборке ошибка писалась совсем не интуитивно понятная, а после сноса кеша резко все продолжало работать.
поэтому и развивались они параллельно, а менять сейчас смысла нету, так как свою задачу в данный момент делают оба
p.s. я уже не раз имел спор с билд инженерами чем вам (maven/gradle/sbt) не угодил, а выбрали (maven/gradle/sbt), ведь я могу с помощью него сделать все тоже, что вы делаете на своем. в общем это холивар =) причем очень жестокий. в любой системе можно сделать как вменяемый билд скрипт, так и такой что никто его не осилит
вот именно, поэтому найти в природе 2.11 немного проблематично, даже на офф сайте
«Note: Scala 2.11 users should download the Spark source package and build with Scala 2.11 support.»
а просто взять и использовать нельзя…
>> так что все не должно сломаться.
ага, сломается только половина
я не противник скалы, сам регулярно её использую для прототипов и небольших проектов, но начинать серьезный проект который нужно будет поддерживать годами я морально не готов, так как все эти изменения немножко напрягают. сам подход bytecode мы ломаем постоянно, а source level «всего» через раз отпугивают от scala очень много компаний. тут компании задумываются над тем, что обновлять java каждые 18 месяцев это слишком часто, давайте нам релиз цикл хотя бы 2 года, а вы со scala предлагаете каждые 2 года заставлять их переписывать код.
p.s. минутка юмора: очередной раз перечитывая www.scala-lang.org/api/2.11.4/index.html#scala.collection.concurrent.Map и все его варианты с + ++: --= /: :\ ++= складывается впечатление, что Одерски пытался написать обфускатор, но люди обозвали это языком и пытаются кодить =)
зависимость собранная для скалы 2.10 не взлетит если у вас проект на 2.11 и тд
то есть главные смысл в автоматическом мэтчинге нужной версии скалы
но по мне это пример костыля, который пытается маскировать основную проблему «между версиями плывет байткод»
ну а второй момент политический: зачем нам мэйвен если мы можем и сборщик тоже использовать со скалой, в итоге scala everywhere
>> на нем есть большие проекты, например, Apache Spark
тогда может нам еще расскажите про совместимость между версиями?
Spark до сих пор используют scala 2.10.4, так как переехать на 2.11 свежее требует достаточно много ресурсов.
а дальше будет 2.12 которая вроде как обещают совместимость с 2.11, но хз-хз, так как работу с лямбдами полностью переделали
а после 2.13 в которой collections полностью обещают переделать, в итоге нету вообще никакой гарантии что даже на уровне source code будет работать.
или может расскажите про play?
если у вас проект на play со смесью java и scala и вам нужно смигрировать с play 2.1 на последние версии java, то резко оказывается что scala 2.9 не переваривает байткод от восьмерки, нужно обновить скалу до свежей версии,
обновляем скалу и нарываемся на второй пункт — 2.1 собран только под scala 2.9, под свежую скалу нету его, следовательно просто java обновить вы не можете, нужно обновлять и скала и сам плей
плей между версиями меняет api следовательно опять секс =)
итого: смена language level с 7 на 8 для scala части выливается в обновили scala core / all frameworks / fix all changed api
вообще если подойти более обще, то оказывается, что тот же typesafe пытается как-то объяснить Одерскому, что меняя api и ломая байткод каждую версию в серьезные проекты залезть сложно, на что получает закономерный ответ «нужно больше фич, а поддержка и совместимость это вторично»
2 пункта в подтверждение, но вот 3й как раз в тему почему некоторые в сообществе считают, что может лучше уже и на 10ку скинуть модули, так как их первоначально вообще в 7ку обещали и где гарантия, что из-за них в мае не придется опять переносить еще на 6 месяцев релиз
1) фаза map и пишет в память
2) память периодически сбрасывает результаты на локальный диск
3) reduce фаза запрашивает ноды на которых проходили map фазы на получение данных
то есть редьюсеры сами выступают в роли инициатора получения данных, pull модель более устойчивая к отказам, если у нас reduce какой и отвалился, то все входные данные остаются и пересчитать не проблема
flink & mr 2.0 push
1) map отрабатывает и пишет в память
2) подымаются reduce элементы
3) по p2p топологии память стразу транслируется на удаленные машины
4) при необходимости reduce сбрасывает данные на диск после частичного merge, если данные в память не влазят
в push есть проблема, что если у нас reduce упал, то нам нужно еще и map фазу повторить для получения кусочка данных для данного блока, поэтому даже в push остается возможность настройки сброса копии на диск, чтобы можно было потом просто её забрать без пересчета.
Но вообще у нас снижается latency за счет того, что reducer сразу получает входные данные для свертки, без необходимости делать запрос. В классической реализации для снижения latency reducer'ы обычно стартуют чуть раньше чем завершатся все map task'и. этим параметром управляет mapreduce.job.reduce.slowstart.completedmap. 0.1 означает, что как только закончат работу 10% всех мап тасков начнут запускаться редьюсеры и вытягивать себе копии данных, то есть к моменту отрабатывания последнего map есть вероятность, что только его и будут ждать редьюсеры, чтобы скопировать последний кусочек и начать свертку.
из ссылок
flink-forward.org/?session=a-comparative-performance-evaluation-of-flink
одна из наиболее интересных статей с разбором на какой стадии больше диск насилуется видно в
eastcirclek.blogspot.com.by/2015/06/terasort-for-spark-and-flink-with-range.html
можно еще глянуть на это все в контексте стрим процессинга, смысл там остается таким же
gdfm.me/2013/01/02/distributed-stream-processing-showdown-s4-vs-storm
2. вы tez проверяли или судите по классическому mr? если классический, то это архитектурная особенность работы jobtracker'а, если уж тогда и сравнивать, то spark-submit на yarn
3. я говорю о глобальных изменениях, rdd по сути только в offheap вынесли, все вещи в dataframe интересные попадают. текущую схему работы без переделки всей архитектуры не поменять, а вот с dataframe еще что-то можно сделать. к тому же я говорю про оптимизацию платформы, не отдельных ваших задач, зачастую улучшение платформы сразу влияние на все задачи оказывает.
та картинка является правдой, НО для итеративной задачи, когда все данные в памяти, в итоге сделали бы они в 2 раза больше итераций еще больший бы разрыв получили. насколько помню там был pagerank, берем графовый giraph или flink delta iteration и получаем точно такие же графики, но на вершине уже спарк. и это тоже будет правдой. бенчмарки они такие…
> Но объективно я вижу, что те же самые задачи стали работать быстрее.
переписанные задачи, перевели бы вы их на impala стало бы еще быстрее местами. переписали на hive+tez другие результаты.
а использовали бы тот же flink и даже переписывать бы не пришлось, 2-3 строки изменить в коде только.
я не против спарка, как инструмент он неплох, как уже говорилось, мы сами его используем. я против того когда начинают хвалить инструмент ссылаясь на мифы, я их перечислил:
1) спарк все в памяти, поэтому такой быстрый, а вот хадуп все на диске
2) спарк реиспользует jvm, а вот хадуп подымает каждый раз новые инстансы
3) rdd универсальней map-reduce (на самом деле rdd это способ представления данных, а map-reduce парадигма вычисления, в спарке map-reduce и использует с небольшими модификациями)
если уже и приводить плюсы спарка, то это:
1) более удобный и высокоуровневый api, следовательно ниже порог вхождения разработчиков и более быстрое написание кода
2) местами более высокая скорость работы, но далеко не все объемы он может переварить, на которых справляется хадуп
3) более удобная обертка для оркестрации задачами, так как все можно делать в основной программе
p.s. по поводу как реиспользование в спарке работает: в спарке подымается воркер и он все задачи обслуживает, в хадупе от этого по умолчанию отказались, так как потенциально может вызвать утечку ресурсов в пределах долгой и нагруженной MR таски, в спарке забили, типо будем считать что утечек нету между отдельными тасками. поэтому в хадупе не проблема в пределах все mr job'ы сказать переиспользовать jvm, а вот в спарке запретить данное поведение уже нельзя.
сами датафреймы добавили как абстракцию уже почти год назад, а для bigdata год это достаточно большой срок, за это время многие продукты рождаются и успевают умереть в забвении =)
ругают не hdfs, а map-reduce как подход, хотя спарк это тот же map-reduce по сути, а вот тут и начинаются мифы… но всегда стоит отделять тех часть от маркетинга
тот кто пробовал вручную писать join + aggregation какой-нибудь на map-reduce со мной согласятся, что это немного ад. именно поэтому и появились такие проекты как hive (sql язык манипуляции) и pig (парадигма data stream и работа над стримами данных), которые и снимали с разработчика весь этот низкоуровневый ад.
второй плюс это смесь как классического подхода по обработке данных (императивны и функциональный за счет лямбд) с декларативным (sparksql) и гибкие переходы между ними
ну и третий наверное один из наиболее главных для математиков: он почти нативно поддерживает пандусовские датафреймы, а значит легко интегрируется с уже существующим кодом.
ну а другие «плюсы»: его активно форсят любители скалы, первый коммент это подтверждает ;) точно также как любители clojure форсят storm в качестве примеров больших систем.
в общем как очередная реализацию парадигмы map-reduce с переменных количеством map и reduce фаз в pipeline он очень неплох, да еще и скрывает многие сложности от пользователей.
с другой стороны возьмем клоудеру с её идеей спарка везде vision.cloudera.com/one-platform
но даже они признают, что у спарка до сих пор по сравнению с хадупом есть проблемы производительности на очень больших кластерах.
immutable state это не панаценя ( Even though Spark is fast, there’s room for improvement in stream processing. Performance will continue to be a focus area across the platform, but in Spark Streaming in particular, there are some obvious changes we can make, in persistent mutable state management and elsewhere, that will deliver some big benefits. ) и тд.
но я сомневаюсь, что тут найдется много людей с кластерами в тысячи машин, а значит и выходит на первое место удобство использования и порог вхождения. а вот тут спарк выигрывает. хотя последнее время очень активно и flink движется в этом направлении, чего стоят только примеры внедрения flink-forward.org/?post_type=session
уж не обессудьте, но:
Стоит сказать что дисковый ввод/вывод всё таки используется (на этапе shuffle)
что такое shuffle если не промежуточный этап между Map и Reduce фазами? хотя в некоторых случаях действительно можно его избежать, если в процессе операции map не менялось партицирование
mapred.job.reuse.jvm.num.tasks существует почти с первых версий hadoop, для исключения лишних созданий jvm
отдельно по поводу первого пункта: spark полностью совпадает с pull моделью используемой в классической реализации хадупа, в тоже время flink уже перешел на push, да и хадуп уже умеет это делать
просто Just for FUN
pl.postech.ac.kr/~eastcirclek
www.slideshare.net/FlinkForward/dongwon-kim-a-comparative-performance-evaluation-of-flink
тот же проект tungsten из спарка по выносы в offheap и кодогенерация почти целиком взят с идеи flink ( flink.apache.org ). Причем у флинка стриминг сделан более качественно, плюс совместим с гугловым Dataflow
www.slideshare.net/FlinkForward/william-vambenepe-google-cloud-dataflow-and-flink-stream-processing-by-default
причем на более высоком уровне, в отличии от спакра, у которого стриминг это микробатчи. поэтому честная поддержка dataflow сейчас в обсуждении как же сделать это на спарке
отдельно заслуживает упоминание совместимости, переезд ваших существующих задач с минимальными модификациями:
1) old hadoop map reduce — ci.apache.org/projects/flink/flink-docs-release-0.10/apis/hadoop_compatibility.html
2) storm (с учетом что твитер отказалась от дальнейшего развития) — ci.apache.org/projects/flink/flink-docs-release-0.10/apis/storm_compatibility.html
я не имею ничего против спарка =) сами используем, но читать в каждой статье хвалебные отзывы про техносовершенство спарка и убогости хадупа тоже напрягает.
делать выводы на основе байткода совершенно неверно, то что в некоторых случаях это сработало, закрепляет неправильные предложения и в итоге уводят в совершенно непонятных направлениях с постепенным превращением всего этого в cargo культ. посмотрите на статью автора с его манипуляциями байткодом с пачкой необоснованных утверждение и статьи Шипилева или Томпсона, разница гигантская, так как у них идет разбор на уровне asm и иногда железа, что же у нас происходит на самом деле.
прав некорректный бенчмарк:
1) автор сравнивает не просто add(), но и тут же remove(), что вносит дополнительную погрешность
2) автор утверждает, что методы add() имеют минимальные отличия, на практике в случае if в его тесте метод add() не инлайнится, а идет явный вызов
3) автор утверждает, что методы remove() полностью идентичны, на практике в случае if в его тесте метод remove() не инлайнится (предположительно предыдущий add() сломал оптимизации последующие), а идет явный вызов
по итогу:
1) метод с exception идет линейно, без дополнительных вызовов, к тому же нету случая когда этот exception выбрасывается
2) метод с if сразу производит 15 вызовов функции add() и следом 15 вызовов remove().
что мы вообще меряем? стоимость 30 вызовов функций? логично что вызывать их будет дороже, так как переходы не бесплатны и заметно дороже линейного выполнения кода
на практике в случае с if в его тестах сразу отваливается inlining на add(), а уже потом еще и на remove(). как итог тест полностью бесполезен.
на свежих версиях jdk при срабатывании инлайнинга на обоих методах поведение идентичное, но автора это не останавливает =( начинаются споры по поводу использования в проде старых 6 и 7 версий
извиняюсь за то, что пришлось перепостить половину статьи, но первый раздел как раз по поводу инлайнинга и гадания на байткоде.
Общения в github, где автор на основе идентичности методов утверждает, что в его тесте они тоже работают одинаково радует. так же как и желания тестировать только на старых версиях jvm, которые работают не всегда корректно.
данная опция на версиях jvm, что использует автор крешит jvm на его бенчмарках. А так да, основная масса выводов автором сделана на основе анализа байткода, без самого анализа что же у нас происходит в реале