Решение Spark для устранения перекоса данных (1)

задняя часть Spark

Это 13-й день моего участия в Gengwen Challenge.Подробности о мероприятии, пожалуйста, проверьте:Обновить вызов

вводить

  • Проблема перекоса данных в Spark в основном относится к проблеме перекоса данных в процессе перемешивания, которая вызвана разными объемами данных, соответствующими разным ключам, и разными объемами данных, обрабатываемыми разными задачами.

  • Например, точка сокращения должна обработать в общей сложности 1 миллион единиц данных.Первая и вторая задачи распределяются по 10 000 единиц данных соответственно, а расчет выполняется в течение 5 минут.Третья задача распределяется по 980 000 единиц данных. В это время третья задача Задача может занять 10 часов, что делает все задание Spark выполненным за 10 часов, что является следствием перекоса данных.

  • Обратите внимание, что необходимо различать перекос данных и чрезмерный объем данных.Перекос данных означает, что небольшому количеству задач выделяется подавляющее большинство данных, поэтому несколько задач выполняются медленно; избыток данных означает, что всем задачам выделяется большой объем данных. данных.Большие, похожие, все задачи выполняются медленно.

  • Производительность перекоса данных:

    • Большинство задач задания Spark выполняются быстро, и только ограниченное количество задач выполняется очень медленно.В это время может быть перекос данных, и задание может выполняться, но очень медленно;

    • Большинство задач задания Spark выполняются быстро, но некоторые задачи внезапно сообщают об OOM во время выполнения процесса.После повторного выполнения несколько раз в определенной задаче сообщается об ошибке OOM.В это время данные могут быть искажены, а задание нормально не заводится..

  • Проблема перекоса данных позиционирования:

    • Проверьте операторы перемешивания в коде, такие как reduceByKey, countByKey, groupByKey, join и другие, и оцените, будет ли здесь перекос данных в соответствии с логикой кода;

    • Проверьте файл журнала задания Spark. Файл журнала будет записывать ошибку с точностью до определенной строки кода. Вы можете определить, на каком этапе произошла ошибка, основываясь на месте кода, где находится исключение, и какой оператор перетасовки соответствующий оператор тасования;

Решение 1. Объедините исходные данные

  • Избегайте процесса перемешивания

    • В большинстве случаев источником данных для заданий Spark являются таблицы Hive, и эти таблицы Hive в основном представляют собой вчерашние данные после ETL. Чтобы избежать перекоса данных, мы можем рассмотреть возможность отказа от процесса перетасовки.Если процесс перетасовки избегается, возможность проблем с перекосом данных принципиально устраняется.

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

    • Для работы данных в таблице Hive не обязательно склеивать их в строку, либо их можно напрямую накапливать и вычислять для каждых данных ключа.

    • Чтобы отличить, разницу между большим объемом обрабатываемых данных и перекосом данных.

  • Уменьшите детализацию ключей (увеличьте вероятность перекоса данных, уменьшите объем данных для каждой задачи)

    • Увеличение количества ключей может сделать искажение данных более серьезным.

  • Увеличьте детализацию ключей (уменьшите вероятность перекоса данных и увеличьте объем данных для каждой задачи)

    • Если нет возможности агрегировать фрагмент данных для каждого ключа, в определенных сценариях можно рассмотреть возможность расширения детализации агрегирования ключа.

  • Например, в настоящее время имеется 100 000 пользовательских данных, а степень детализации текущего ключа — (провинция, город, район, дата).Теперь мы рассматриваем возможность расширения детализации и расширения детализации ключа до (провинция, город, дата). Число будет уменьшено, а разница в объеме данных между ключами также может быть уменьшена, что может смягчить явление и проблему перекоса данных. (Этот метод действителен только для определенных типов данных. Если сценарий применения не подходит, перекос данных будет усугубляться)

Решение 2. Улучшите сокращение параллелизма в операции перемешивания

Когда схема 1 и схема 2 плохо влияют на обработку перекоса данных, рассмотрите возможность увеличения параллелизма редукционной стороны в процессе перемешивания.Увеличение параллелизма редукционной стороны увеличивает количество задач на редукционной стороне , то распределяется каждая задача. Объем полученных данных будет соответственно уменьшен, тем самым облегчая проблему перекоса данных.

  • Уменьшить настройку бокового параллелизма

    • В большинстве операторов тасования можно передать параметр настройки параллелизма, например, reduceByKey(500).Этот параметр будет определять параллелизм редукционной стороны в процессе тасования.При выполнении операции тасования он будет создан соответствующим образом. Указанное количество задач сокращения. Для операторов Spark SQL, подобных перетасовке, таких как group by, join и т. д., необходимо установить параметр, а именно spark.sql.shuffle.partitions, который представляет параллелизм задачи чтения в случайном порядке. Значение по умолчанию — 200. , Для многих сценариев это слишком мало.

    • Увеличение количества задач случайного чтения позволяет назначить несколько клавиш, изначально назначенных одной задаче, нескольким задачам, что позволяет каждой задаче обрабатывать меньше данных, чем раньше. Например, если изначально имеется 5 ключей, каждый ключ соответствует 10 элементам данных, и эти 5 ключей выделены задаче, то эта задача будет обрабатывать 50 элементов данных. После добавления задачи случайного чтения каждой задаче назначается ключ, то есть каждая задача обрабатывает 10 фрагментов данных, поэтому время выполнения каждой задачи естественно сократится.

  • Дефекты в настройке уменьшения параллелизма сторон

    • Улучшение параллелизма на стороне редукции принципиально не меняет характер и проблему перекоса данных (первое и второе решения принципиально предотвращают возникновение перекоса данных), но максимально облегчают и уменьшают нагрузку на данные задачи перетасовки редукции. , и Проблема перекоса данных применима к случаю, когда имеется много ключей, соответствующих относительно большому количеству данных.

    • Это решение обычно не может полностью устранить перекос данных, потому что если есть какие-то экстремальные ситуации, например, количество данных, соответствующее ключу, равно 1 миллиону, то независимо от того, насколько увеличивается номер вашей задачи, ключ, соответствующий 1 миллиону данных, будет определенно все еще будет выделено.Он обрабатывается в задаче, поэтому неизбежен перекос данных. Поэтому можно сказать, что эта схема является первым методом, который следует использовать при обнаружении перекоса данных, чтобы попытаться устранить перекос данных простым способом или использовать его в сочетании с другими схемами.

    • В идеале, после улучшения параллелизма на стороне редукции проблема перекоса данных будет в определенной степени облегчена или даже полностью устранена; однако в некоторых случаях это только сделает задачи, которые изначально выполнялись медленно из-за перекоса данных. работать быстрее.Немного улучшено, или устранена проблема OOM некоторых задач, но работа по-прежнему медленная.В это время необходимо вовремя отказаться от третьего решения и начать пробовать последнее решение.

Категории