На одну таску дефолтно аллоцируется 1 cpu, поэтому число ядер на экзекьюторе в вашем кейсе может влиять только на то сколько тасок параллельно он исполняет внутри одной джобы.
И вот этот простой сводится к минимуму при параллельном запуске методов - почти в любой момент времени найдётся куда утилизировать временно освобождающиеся ядра.
Согласен, все так
Приложение запросило и получило 100 ядер, Yarn скорее всего не отдаст эти ядра ни при последовательном, ни при параллельном выполнении.
Легко отдаст если они будут простаивать. Другое дело, что возвращать их для жирного стейджа внутри таски - дополнительные накладные расходы, избежав которых в схеме с параллельным исполнением можно и получить тот самый профит.
Стоит отметить, что проведение экспериментов в высококонкурентной среде, коим является Hadoop-кластер, - это то ещё удовольствие. Каждый тестовый запуск не похож на предыдущий, т.к. постоянно кто-то ещё что-то считает. И мой i-ый тестовый запуск может получить ресурсов меньше/больше, чем i-1. Также скорость получения ресурсов неодинаковая: можно со старта получить 100 ядер, а можно эти 100 ядер добирать на протяжении долгого времени.
Для таких целей можно зафиксировать ресурсы за вашим приложением c помощью spark.executor.instances
Во-вторых, кажется, что для одной задачи прирост производительности от увеличения количества ядер не является линейным, а постепенно замедляется. Таким образом, большей эффективности получается добиться от параллельного запуска нескольких методов.
По умолчанию обычно одна таска = 1 ядро. Параллелизм на уровне экзекьютора зависит от параметров, которые вы указали в sparkConf.
В итоге подход с параллельным выполнением методов всегда превосходил последовательный. В самом худшем раскладе параллельное выполнение на 40% быстрее. В самом лучшем - когда сошлись все звёзды - получалось 3х-кратное превосходство. Если взять средние показатели для целевого времени расчёта признаков (раннее утро), то параллельный подход выигрывает примерно в 2 раза.
В статье Cloudera немножко не про то говорят: там основная мысль в том, что бОльшее число партиций даст возможность разбросать таски по бОльшему числу экзекьюторов. В вашем случае прирост скорее всего в том, что в жирных подтасках утилизация экзекьюторов неравномерная и RM скорее всего успевал их забирать под нужды других задач. То есть тут прирост скорее всего только в том, что вы забрали ресурсы кластера под свои задачи и остальные стали работать чуть медленнее :)
Вы уровнем OSI промахнулись. OFDM это физический уровень и в WiFi он, конечно, есть. А CSMA-CA просто обеспечивает проверку чистоты эфира, чтобы не словить помеху по всей полосе при передаче и это уровень канальный.
А я всё мечтаю добраться и сделать какой-то семантический анализ заголовков и содержания новостей Ленты, чтобы подтвердить или опровергнуть своё личное ощущение по поводу сильно упавшего качества её контента за последние годы.
Возможно стоило чуть по-другому оформить разбивку по рубрикам, т.к. субъективно она выглядит плохо читаемой.
Спасибо за системный и детализированный отчет о мероприятии. Особенно интересно читать о том, как комбинации известных методов анализа фомируют конечные бизнес-решения.
ICQ со своей огромной пользовательской базой и историей умудрилась проиграть гонку WhatsApp, Viber и остальным. И все потому, что в какой-то момент управленцы не смогли правильно выстроить вектор развития мессенджера: забили под завязкой рекламой официальный клиент, не вкладываясь в развитие.
Теперь только и остается писать про историю.
На одну таску дефолтно аллоцируется 1 cpu, поэтому число ядер на экзекьюторе в вашем кейсе может влиять только на то сколько тасок параллельно он исполняет внутри одной джобы.
Согласен, все так
Легко отдаст если они будут простаивать. Другое дело, что возвращать их для жирного стейджа внутри таски - дополнительные накладные расходы, избежав которых в схеме с параллельным исполнением можно и получить тот самый профит.
Для тестов можно просто поставить нужное число initialExecutors и он не будет добирать
Для таких целей можно зафиксировать ресурсы за вашим приложением c помощью spark.executor.instances
По умолчанию обычно одна таска = 1 ядро. Параллелизм на уровне экзекьютора зависит от параметров, которые вы указали в sparkConf.
В статье Cloudera немножко не про то говорят: там основная мысль в том, что бОльшее число партиций даст возможность разбросать таски по бОльшему числу экзекьюторов. В вашем случае прирост скорее всего в том, что в жирных подтасках утилизация экзекьюторов неравномерная и RM скорее всего успевал их забирать под нужды других задач. То есть тут прирост скорее всего только в том, что вы забрали ресурсы кластера под свои задачи и остальные стали работать чуть медленнее :)
Отличная статья, спасибо!
Очень круто! Спасибо!
Не совсем по теме, но близко была хорошая статья feriat с аналитикой по Медузе.
Возможно стоило чуть по-другому оформить разбивку по рубрикам, т.к. субъективно она выглядит плохо читаемой.
Спасибо за статью и датасет.
Есть ли у персональные лицензии?
Теперь только и остается писать про историю.