Pull to refresh
29
0
Андрей Кузнецов @netcitizen

Инженер

Send message

На одну таску дефолтно аллоцируется 1 cpu, поэтому число ядер на экзекьюторе в вашем кейсе может влиять только на то сколько тасок параллельно он исполняет внутри одной джобы.

И вот этот простой сводится к минимуму при параллельном запуске методов - почти в любой момент времени найдётся куда утилизировать временно освобождающиеся ядра.

Согласен, все так

Приложение запросило и получило 100 ядер, Yarn скорее всего не отдаст эти ядра ни при последовательном, ни при параллельном выполнении.

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

Для тестов можно просто поставить нужное число initialExecutors и он не будет добирать

Стоит отметить, что проведение экспериментов в высококонкурентной среде, коим является Hadoop-кластер, - это то ещё удовольствие. Каждый тестовый запуск не похож на предыдущий, т.к. постоянно кто-то ещё что-то считает. И мой i-ый тестовый запуск может получить ресурсов меньше/больше, чем i-1. Также скорость получения ресурсов неодинаковая: можно со старта получить 100 ядер, а можно эти 100 ядер добирать на протяжении долгого времени.

Для таких целей можно зафиксировать ресурсы за вашим приложением c помощью spark.executor.instances 

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

По умолчанию обычно одна таска = 1 ядро. Параллелизм на уровне экзекьютора зависит от параметров, которые вы указали в sparkConf.

В итоге подход с параллельным выполнением методов всегда превосходил последовательный. В самом худшем раскладе параллельное выполнение на 40% быстрее. В самом лучшем - когда сошлись все звёзды - получалось 3х-кратное превосходство. Если взять средние показатели для целевого времени расчёта признаков (раннее утро), то параллельный подход выигрывает примерно в 2 раза.

В статье Cloudera немножко не про то говорят: там основная мысль в том, что бОльшее число партиций даст возможность разбросать таски по бОльшему числу экзекьюторов. В вашем случае прирост скорее всего в том, что в жирных подтасках утилизация экзекьюторов неравномерная и RM скорее всего успевал их забирать под нужды других задач. То есть тут прирост скорее всего только в том, что вы забрали ресурсы кластера под свои задачи и остальные стали работать чуть медленнее :)

А какие у вас примерные нагрузки на сервис сообщений? BERT совсем недешевая штука в плане ресурсов.
Вы уровнем OSI промахнулись. OFDM это физический уровень и в WiFi он, конечно, есть. А CSMA-CA просто обеспечивает проверку чистоты эфира, чтобы не словить помеху по всей полосе при передаче и это уровень канальный.
Займусь, как будет время непременно.
Не совсем по теме, но близко была хорошая статья feriat с аналитикой по Медузе.
А я всё мечтаю добраться и сделать какой-то семантический анализ заголовков и содержания новостей Ленты, чтобы подтвердить или опровергнуть своё личное ощущение по поводу сильно упавшего качества её контента за последние годы.
Возможно стоило чуть по-другому оформить разбивку по рубрикам, т.к. субъективно она выглядит плохо читаемой.

Спасибо за статью и датасет.
Прекрасную инфографику от РИА в статье отрейскелили так, что смотреть без слез нельзя.
Спасибо за системный и детализированный отчет о мероприятии. Особенно интересно читать о том, как комбинации известных методов анализа фомируют конечные бизнес-решения.
Смотрел цены для организаций и сравнивал их с лицензиями персональными Microsoft. Пардон.
Есть ли у персональные лицензии?
Цены на ваши продукты вряд ли можно считать конкурентоспособными на рынке. Оставив за скобками госучреждения, не вижу вашей ЦА.
Обе имеют клиенты как для ПК, так и для других платформ.
ICQ со своей огромной пользовательской базой и историей умудрилась проиграть гонку WhatsApp, Viber и остальным. И все потому, что в какой-то момент управленцы не смогли правильно выстроить вектор развития мессенджера: забили под завязкой рекламой официальный клиент, не вкладываясь в развитие.
Теперь только и остается писать про историю.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Works in
Date of birth
Registered
Activity