Это 17-й день моего участия в Gengwen Challenge.Подробности о мероприятии, пожалуйста, проверьте:Обновить вызов
Общая настройка производительности 2: оптимизация RDD
- Мультиплексирование RDD
При выполнении операторов на СДР необходимо избегать повторных вычислений на СДР по одному и тому же оператору и логике расчета Измените вычислительную архитектуру RDD на рисунке выше, чтобы получить результаты оптимизации, показанные на рисунке ниже:
- постоянство RDD
В Spark, когда операция оператора выполняется над одним и тем же RDD несколько раз, RDD будет каждый раз пересчитываться с предыдущим родительским RDD.Такой ситуации следует избегать.Повторное вычисление одного и того же RDD является правильным.Это огромная трата ресурсов. .Поэтому необходимо сохранять СДР, которые используются много раз, и кэшировать данные общедоступных СДР в памяти/диске посредством сохранения.После этого вычисление общедоступных СДР будет напрямую получать данные СДР из памяти/диска.
Для устойчивости RDD необходимо отметить два момента:
Постоянство RDD может быть сериализовано.Если память не может хранить данные RDD полностью, вы можете рассмотреть возможность использования метода сериализации, чтобы уменьшить объем данных и полностью сохранить данные в памяти.
Если надежность данных высока и памяти достаточно, для сохранения данных RDD можно использовать механизм копирования. Когда механизм репликации включен для сохраняемости, реплика сохраняется для каждого постоянного блока данных и размещается на других узлах, тем самым реализуя отказоустойчивость данных.После потери данных реплики нет необходимости пересчитывать другую копию.
- Фильтровать операции на RDD как можно раньше
После получения исходного RDD следует как можно скорее отфильтровать ненужные данные, чтобы уменьшить использование памяти и повысить эффективность выполнения заданий Spark.
Общая настройка производительности 3: Настройка времени ожидания локализации
Во время выполнения задания Spark Драйвер будет назначать задачи каждому этапу. Согласно алгоритму распределения задач Spark, Spark надеется, что задача может выполняться на узле, где подсчитываются данные, которые она хочет вычислить (идея локализации данных), чтобы можно было избежать передачи данных по сети. Вообще говоря, задача не может быть назначена узлу, на котором находятся обрабатываемые данные, потому что доступные ресурсы этих узлов могут быть исчерпаны.В это время Spark будет ждать в течение определенного периода времени, по умолчанию 3 с, если по-прежнему не удается дождаться указанного времени. Если указанный узел работает, он будет автоматически понижен. Попробуйте назначить задачу узлу, соответствующему более низкому уровню локализации. Например, назначьте задачу узлу, который ближе к данным для расчета, а затем выполните расчет.Если текущий уровень Если он все еще не работает, продолжайте и понизьте.
Когда данные, которые должны быть обработаны задачей, находятся не на узле, где находится задача, произойдет передача данных. Задача будет получать данные через BlockManager узла, на котором они расположены.Когда BlockManager обнаруживает, что данные не являются локальными, пользователь получает данные от BlockManager узла, где находятся данные, через сетевой компонент передачи.
Ситуация с передачей данных по сети - это то, чего мы не хотим видеть. Большое количество передач по сети серьезно повлияет на производительность. Поэтому мы надеемся скорректировать локализованное время ожидания. Если целевой узел выполнил некоторые задачи в течение времени ожидания, Тогда у текущей задачи будет возможность выполниться, что может повысить общую производительность задания Spark. Уровни локализации Spark показаны в таблице:
| название | Разобрать |
|---|---|
| PROCESS_LOCAL | Локализация процесса, задачи и данные находятся в одном Исполнителе, а производительность наилучшая. |
| NODE_LOCAL | Локализация узла, задача и данные находятся в одном узле, но задача и данные не в одном Исполнителе, и данные нужно передавать между процессами. |
| RACK_LOCAL | Локализация стойки, задача и данные находятся на двух узлах в одной стойке, и данные необходимо передавать между узлами по сети. |
| NO_PREF | Для задач одинаково, где бы вы их ни брали, нет ни хороших, ни плохих. |
| ANY | Задачи и данные могут быть где угодно в кластере, а не в стойке, с худшей производительностью. |
Уровни локализации Spark показаны в таблице:
На этапе разработки проекта Spark вы можете использовать режим клиента для тестирования программы.В это время вы можете увидеть более полную информацию журнала локально.Информация журнала имеет четкий уровень локализации данных задачи.Если большинство из них PROCESS_LOCAL, то В настройке нет необходимости, но если вы обнаружите, что много уровней NODE_LOCAL и ANY, то вам необходимо настроить время ожидания локализации.Увеличив время ожидания локализации, посмотрите, улучшился ли уровень локализации задачи, и наблюдайте за Spark job Сокращено ли время работы?
Обратите внимание, что уже слишком поздно, не продлевайте время ожидания локализации слишком долго, что увеличит время выполнения заданий Spark из-за большого времени ожидания.
Настройка времени ожидания локализации Spark показана в коде:
val conf = new SparkConf()
.set("spark.locality.wait", "6")