Почему не работает spark

Краткое описание:
Spark – это больше, чем просто почтовый клиент. В нем умело совмещены интуитивный дизайн и механизм, продуманный до мелочей.

«Spark помогает разобрать загруженный письмами ящик за несколько секунд.» – The Verge

Контроль над собственным ящиком
Умная сортировка писем и умные уведомления – лучшие инструменты для работы с персональной почтой. С таким помощником достичь Inbox Zero будет несложно!

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

Умные уведомления
Включите Умные уведомления, и почта будет отвлекать вас только по действительно важным вопросам от реальных людей.

Email Суперсила
Незаменимые инструменты в Spark подарят вам Email Суперсилу, с которой вы сможете разгрести завалы из писем за считанные секунды:

✓ Функция «Отложить на потом»
✓ Запланированная отправка писем
✓ Напоминания о письмах без ответа
✓ Персональные настройки
✓ Умный поиск

Свайп вправо, свайп влево
Все ваши подписи запоминаются программой автоматически. А для быстрого выбора нужной подписи вам достаточно свайпнуть влево или вправо.

Стильный дизайн
Мы много работали над тем, чтобы Spark одинаково классно выглядел на всех ваших устройствах. И чтобы фокус всегда был на тексте письма. И чтобы пользоваться приложением было не только удобно, но и приятно. Попробуйте!

КОМАНДНАЯ РАБОТА С ПОЧТОЙ

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

Пишите письма вместе
В режиме реального времени редактируйте и создавайте письма вместе с друзьями и коллегами.

Обменивайтесь ссылками на письма
Создавайте защищенные ссылки на отдельные письма и целые переписки. Обменивайтесь ими в Slack, Skype, CRM и других корпоративных сервисах для удобного сотрудничества с коллегами и партнерами.

Одним словом, Spark – это именно то, что вам нужно!
Что же касается делегирования писем, интеграции со сторонними сервисами, шаблонов писем, быстрых ответов и встроенного календаря – это то, что вас ждет впереди!

Требуется Android: 7.0+
Для ранних версий 6.0+
Русский интерфейс: Да

Версия: 2.0.4 build 20004113 (pokpok)
Версия: 2.0.4 build 20004112 (pokpok)
Версия: 2.0.4 build 20004103 (pokpok)
Версия: 2.0.4 Spark (Пост And_RU #85748209)
Версия: 2.0.3 build 20003092 (pokpok)
Версия: 2.0.2 Spark (Пост pokpok #84721185)
версия: 2.0.1 Сообщение №58, автор And_RU
версия: 2.0.0 Spark – Email App by Readdle_v2.0.0.apk ( 63,84 МБ )

Сообщение отредактировал iMiKED — 15.10.21, 10:52

Источник

Почему ваши приложения Spark работают медленно или выходят из строя

Часть II. Искажение данных и очистка памяти

Вторая часть нашей серии «Почему ваши приложения Spark медленно работают или выходят из строя» следует за первой частью об управлении памятью и посвящена вопросам, возникающим при искажении данных и очистки памяти в Spark. Как и многие другие проблемы, связанные с производительностью Spark, симптомы нарастают по мере увеличения объема данных, обрабатываемых приложением.

Что такое Искажение Данных (Data Skew)?

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

Искажение данных не является проблемой Spark как таковой, скорее это проблема работы с ними. Причиной проблемы искажения данных является их неравномерное распределение. Неравномерное распределение иногда неизбежно в общей компоновке данных или в характере запроса.

Для объединения и агрегирования Spark необходимо разместить записи одного кода в одном разделе. Записи кода всегда будут находиться в одном разделе. Аналогичным образом, другие записи кода будут распределены на другие разделы. Если один раздел станет очень большим, то это приведет к искажению данных, что будет затруднительно для любой системы запросов, если не будет выполнена соответствующая обработка.

Устранение искажения данных

Проблемы с искажением данных более очевидны в ситуациях, когда их необходимо перемешать в такой операции, как соединение или объединение. Перетасовка (Shuffle) — это операция, выполняемая Spark для хранения связанных данных (относящихся к одному коду) в одном разделе. Для этого Spark должен будет перемещать их по кластеру. По этой причине перетасовка (Shuffle) считается самой трудоемкой операцией.

Общими признаками искажения данных являются

Застопорившиеся этапы и задачи

Низкое использование процессора

Есть несколько приемов, которые мы можем использовать для решения проблемы искажения данных в Spark.

Выявление и устранение искажения данных

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

В таких случаях можно сделать несколько вещей, чтобы избежать искажения обработки данных. Если искажение находится на уровне источника данных (например, hive-таблица разбита на разделы с помощью команды on _month key (текущий месяц), а в таблице гораздо больше записей для particular _month (определенный месяц)), тогда это приведет к искажению обработки на этапе чтения из таблицы. В таком случае помогает преобразование таблицы с помощью других(ой) команд(ы) разбиения.

Однако, иногда это нецелесообразно, так как таблица может быть использована другими каналами передачи данных компании.

Передача данных

Если мы получаем искаженный набор данных, то одним из решений является увеличение значения « spark.sql.autoBroadcastJoinThreshold « для того, чтобы передавались уменьшенные таблицы. Это необходимо сделать для обеспечения достаточного количества памяти драйвера и исполнителя.

Предварительная обработка данных

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

Хэширование с солью (Salting)

В операции присоединения SQL-таблицы (Structured Query Language) код привязки используется для равномерного перераспределения данных таким образом, чтобы обработка раздела не занимала больше времени. Этот метод называется солью ( Salting ). Рассмотрим пример для проверки результата соления. В операции присоединения или группировки, Spark сопоставляет ключ ( key ) с идентификатором ( id ) определённого раздела, вычисляя значение хэш-кода и деля его на количество тасованных ( Shuffle ) разделов.

Предположим, что есть две таблицы со следующей схемой.

Рассмотрим случай, когда конкретный параметр сильно искажен, например, код 1 (key 1), и мы хотим объединить обе таблицы и сгруппировать их, чтобы добиться результата. Например,

После этапа перетасовки ( shuffle ), в связи с выполнением операции соединения, все строки, имеющие одинаковый ключ ( key ), должны находиться в одном и том же разделе. Посмотрите на диаграмму выше. Здесь все строки клавиши 1 находятся в разделе 1. Аналогично все строки с клавишей 2 находятся в разделе 2. Вполне естественно, что обработка раздела 1 займет больше времени, так как раздел содержит больше данных. Проверим пользовательский интерфейс Spark на время выполнения этапа перетасовки ( shuffle ) для вышеприведенного запроса.

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

Можем ли мы что-нибудь добавить к данным, чтобы наш информационный массив был более равномерно распределен? Большинство пользователей при проблемах с искажениями используют технику засолки (salting). Соление (Salting) — это техника, при которой мы добавляем случайные значения (в данном случае это ), чтобы связать их с кодом (key) одной из таблиц. В другой таблице нам нужно скопировать строки, чтобы они соответствовали случайным ключам (keys). Идея в том, что если условие соединения удовлетворяется условием ключ1 == ключ1 ( key1 == key1 ), то оно также должно удовлетворяться ключ1 = ключ1 ( key1 = key1 ). Значение соли поможет распределить набор данных более равномерно.

Вот пример того, как это сделать применительно к нашему случаю. Проверьте число 20, используемое при выполнении случайной функции и при извлечении из архива данных. Это определённое число разделов, которое мы используем для искаженного ключа (key). Это очень простой пример, который можно исправить, включив в него только искаженные элементы (keys).

Теперь давайте еще раз проверим работу приложения Spark. Как мы видим, время обработки стало более равномерным.

Обратите внимание, что для небольших объемов данных разница в производительности не будет сильно отличаться. Иногда способ компрессии (compress) в распределении данных (shuffle) также играет роль в общем времени обработки. Для искаженной информации, перетасованные данные (shuffled data) могут быть сильно сжаты в связи с повторяющейся структурой. Следовательно, общий объем ввода-вывода с диска/ сетевой передачи также уменьшается. Мы можем запустить наше приложение без соли (salt) и с солью, чтобы найти наиболее подходящий вариант.

Сборка мусора (Garbage Collection)

Spark работает на виртуальной машине Java (JVM). Поскольку Spark может хранить большие объемы данных в памяти, она в значительной степени полагается на управление памятью с помощью Java и сборщика мусора (GC). Поэтому решение проблемы по сборке мусора (GC) может стать основной задачей, которая может отразиться на многих приложениях Spark.

Распространенные признаки избытка мусора (GC) в приложении Spark:

Медленная работа приложения

Таймаут сердцебиения исполнителя (Executor heartbeat timeout)

Превышение предела допустимой перегрузки GC

Ориентированный на память подход приложений Spark, интенсивно использующих данные, делает эту проблему (GC) наиболее распространенной по сравнению с другими Java-приложениями. К счастью, легко диагностировать, если ваше приложение Spark испытывает проблемы с GC. Интерфейс (UI) Spark обозначает исполнителей (executors) красным цветом, если они затратили слишком много времени на GC.

Исполнители (Executors) Spark выполняют значительное количество процессорных циклов (CPU cycles), осуществляя уборку мусора. Это можно выяснить, взглянув на вкладку «Исполнители (Executors)» в пользовательском интерфейсе (UI) приложения Spark. Spark отметит исполнителя красным цветом, если он потратил на сбор мусора более 10% времени, чем на выполнение задачи, как показано на диаграмме ниже.

Spark интерфейс (UI) указывает на избыток GC красным цветом.

Решение проблем по сбору мусора

Вот некоторые из основных мер, которые мы можем предпринять, чтобы попытаться решить проблемы, связанные со сбором мусора (GC).

Структуры данных

При использовании приложений, основанных на RDD (Resilient Distributed Dataset), используйте структуры данных с меньшим количеством объектов. Например, используйте массив вместо списка.

Специализированные структуры данных

Если вы имеете дело с простейшими типами данных, рассмотрите возможность использования специализированных структур данных, таких как Koloboke или Fastutil. Эти структуры оптимизируют использование памяти для данных типов.

Хранение данных вне кучи* (off-heap)

Управляющая программа и память Spark могут хранить информацию вне кучи (off-heap). Вы можете включить off-heap накопитель, используя команды

Будьте осторожны при использовании хранилища вне кучи (off-heap), т.к. это не повлияет на размер памяти самой кучи (on-heap), т.е. не уменьшает ее объем. Поэтому, чтобы определить общий лимит памяти, задайте меньший размер кучи.

*Куча (heap) — название структуры данных, с помощью которой реализована динамически распределяемая память приложения.

Встроенные функции по сравнению с функциями, заданными пользователем (UDFS)

Если вы используете Spark SQL, постарайтесь максимально задействовать встроенные функции, насколько это возможно, а не писать новые UDF. Большинство UDF-файлов SPARK могут работать на UnsafeRow (unsafe row — небезопасная строка) и не нуждаются в дополнительной адаптации. Это позволяет избежать возникновения мусора, а также хорошо взаимодействует с процессом генерирования кода.

Экономия на создании объектов

Помните, что мы можем работать с миллиардами строк. Если мы создадим даже небольшой временный объект размером 100 байт для каждой строки, то это создаст 1 миллиард * 100 байт мусора.

Конец второй части

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

Если вы нашли этот блог полезным, вы, возможно, захотите посмотреть первую часть этого цикла статей Why Your Spark Apps is Slow or Failing: Часть I Управление памятью.

Также предлагаем будущим студентам курса и всем желающим посмотреть запись открытого вебинара на тему «Spark Streaming».

Источник

Почему ваши Spark приложения медленно работают или не работают вообще. Часть 1: Управление памятью

Будущих учащихся на курсе «Экосистема Hadoop, Spark, Hive» приглашаем на открытый вебинар по теме «Spark Streaming». На вебинаре участники вместе с экспертом познакомятся со Spark Streaming и Structured Streaming, изучат их особенности и напишут простое приложение обработки потоков.

А сейчас делимся с вами традиционным переводом полезного материала.

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

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

В этой серии статей я хочу рассказать о некоторых наиболее распространенных причинах, по которым приложение Spark выходит из строя или замедляется. Первая и наиболее распространенная — это управление памятью.

Если бы мы заставили всех разработчиков Spark проголосовать, то условия отсутствия памяти (OOM) наверняка стали бы проблемой номер один, с которой все столкнулись. Это неудивительно, так как архитектура Spark ориентирована на память. Некоторые из наиболее распространенных причин OOM:

неправильное использование Spark

высокая степень многопоточности (high concurrency)

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

Переполнение памяти может быть в узлах драйвера, исполнителя и управления. Рассмотрим каждый случай.

НЕДОСТАТОЧНО ПАМЯТИ ПРИ РАБОТЕ ДРАЙВЕРА

Драйвер в Spark — это JVM (Java Virtual Machine) процесс, в котором работает основной поток управления приложения. Чаще всего драйвер выходит из строя с ошибкой OutOfMemory — OOM (недостаточно памяти из-за неправильного использования Spark. Spark — это механизм распределения нагрузки между рабочим оборудованием. Драйвер должен рассматриваться только как дирижер. В типовых установках драйверу предоставляется меньше памяти, чем исполнителям. Поэтому мы должны быть осторожны с тем, что мы делаем с драйвером.

Обычными причинами, приводящими к OutOfMemory OOM (недостаточно памяти) драйвера, являются:

Низкий уровень памяти драйвера, настроенный в соответствии с требованиями приложения

Неправильная настройка Spark.sql.autoBroadcastJoinThreshold .

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

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

Если вы используете SQL (Structured Query Language) от Spark, а драйвер находится в состоянии OOM из-за распределения связей, то вы можете либо увеличить память драйвера, если это возможно; либо уменьшить значение » spark.sql.autoBroadcastJoinThreshold » (неправильная настройка порога подключения) так, чтобы ваши операции по объединению использовали более удобные для памяти операции слияния соединений.

Недостаточно памяти при работе управляющей программы

Это очень распространенная проблема с приложениями Spark, которая может быть вызвана различными причинами. Некоторые из наиболее распространенных причин — высокая степень многопоточности, неэффективные запросы и неправильная конфигурация. Рассмотрим каждую по очереди.

Высокая степень многопоточности

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

Spark задания или запросы разбиваются на несколько этапов, и каждый этап далее делится на задачи. Количество задач зависит от различных факторов, например, на какой стадии выполняется, какой источник данных читается и т.д. Если это этап map-stage (фаза сканирования в SQL), то, как правило, соблюдаются базовые разделы источника данных.

Например, если реестр таблицы ORC (Optimized Row Columnar) имеет 2000 разделов, то для этапа map-stage создается 2000 заданий для чтения таблицы, предполагая, что обработка разделов ещё не началась. Если это этап reduce-stage (стадия Shuffle), то для определения количества задач Spark будет использовать либо настройку » spark.default.parallelism » для RDD (Resilient Distributed Dataset), либо » spark.sql.shuffle.partitions » для DataSet (набор данных). Сколько задач будет выполняться параллельно каждой управляющей программе, будет зависеть от свойства » spark.executor.cores «. Если это значение установить больше без учета памяти, то программы могут отказать и привести к ситуации OOM (недостаточно памяти). Теперь посмотрим на то, что происходит, как говорится, за кадром, при выполнении задачи и на некоторые вероятные причины OOM.

Допустим, мы реализуем задачу создания схемы (map) или этап сканирования SQL из файла HDFS (распределенная файловая система Hadoop distributed file system) или таблицы Parquet/ORC. Для файлов HDFS каждая задача Spark будет считывать блок данных размером 128 МБ. Таким образом, если выполняется 10 параллельных задач, то потребность в памяти составляет не менее 128*10 только для хранения разбитых на разделы данных. При этом опять же игнорируется любое сжатие данных, которое может привести к резкому скачку данных в зависимости от алгоритмов сжатия.

Spark читает Parquet (формат файлов с открытым исходным кодом) в векторном формате. Проще говоря, каждая задача Spark считывает данные из файла Parquet пакет за пакетом. Так как Parquet является столбцом, то эти пакеты строятся для каждого из столбцов. Она накапливает определенный объем данных по столбцам в памяти перед выполнением любой операции над этим столбцом. Это означает, что для хранения такого количества данных Spark необходимы некоторые структуры данных и учет. Кроме того, такие методы кодирования, как словарное кодирование, имеют некоторое состояние, сохраненное в памяти. Все они требуют памяти.

Spark задачи и компоненты памяти во время сканирования таблицы

Так что, при большем количестве параллелей, потребление ресурсов увеличивается. Кроме того, если речь идет о широковещательное соединении (broadcast join), то широковещательные переменные (broadcast variables) также займут некоторое количество памяти. На приведенной выше диаграмме показан простой случай, когда каждый исполнитель выполняет две задачи параллельно.

Неэффективные запросы

Хотя программа Spark’s Catalyst пытается максимально оптимизировать запрос, она не может помочь, если сам запрос плохо написан. Например, выбор всех столбцов таблицы Parquet/ORC. Как видно из предыдущего раздела, каждый столбец нуждается в некотором пакетном состоянии в памяти. Если выбрано больше столбцов, то больше будет потребляться ресурсов.

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

Неправильная конфигурация

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

ПАМЯТЬ ИСПОЛНИТЕЛЯ И ДРАЙВЕРА

Требования к памяти каждого приложения разные. В зависимости от требований, каждое приложение должно быть настроено по-разному. Вы должны обеспечить правильные значения памяти spark.executor.memory или spark.driver.memory в зависимости от загруженности. Как бы очевидно это ни казалось, это одна из самых трудных задач. Нам нужна помощь средств для мониторинга фактического использования памяти приложения. Unravel (Unravel Data Operations Platform) делает это довольно хорошо.

Иногда это не память управляющей программы, а перегруженная память модуля YARN (Yet Another Resource Negotiator — еще один ресурсный посредник), которая вызывает OOM или узел перестает функционировать (killed) из-за YARN. Сообщения «YARN kill» обычно выглядят так:

YARN запускает каждый компонент Spark, как управляющие программы и драйвера внутри модулей. Переполненная память — это off-heap память, используемая для JVM в режиме перегрузки, интернированных строк и других метаданных JVM. В этом случае необходимо настроить spark.yarn.executor.memoryOverhead на нужное значение. Обычно 10% общей памяти управляющей программы должно быть выделено под неизбежное потребление ресурсов.

Если ваше приложение использует кэширование Spark для хранения некоторых наборов данных, то стоит обратить внимание на настройки менеджера памяти Spark. Менеджер памяти Spark разработан в очень общем стиле, чтобы удовлетворить основные рабочие нагрузки. Следовательно, есть несколько настроек, чтобы установить его правильно для определенной внеплановой нагрузки.

Spark определила требования к памяти как два типа: исполнение и хранение. Память хранения используется для кэширования, а память исполнения выделяется для временных структур, таких как хэш-таблицы для агрегирования, объединения и т. д.

Как память исполнения, так и память хранения можно получить из настраиваемой части (общий объем памяти — 300МБ). Эта настройка называется » spark.memory.fraction «. По умолчанию — 60%. Из них по умолчанию 50% (настраивается параметром » spark.memory.storageFraction «) выделяется на хранение и остаток выделяется на исполнение.

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

Если мы не хотим, чтобы все наши кэшированные данные оставались в памяти, то мы можем настроить » spark.memory.storageFraction » на меньшее значение, чтобы лишние данные были исключены и выполнение не столкнулось бы с нехваткой памяти.

Перегрузка памяти в менеджере узла

Spark приложения, которые осуществляют перетасовку данных в рамках групповых операций или присоединяются к подобным операциям, испытывают значительные перегрузки. Обычно процесс перетасовки выполняется управляющей программой. Если управляющая программа (исполнитель) занята или завалена большим количеством (мусора) GC (Garbage Collector), то она не может обслуживать перетасовки запросов. Эта проблема в некоторой степени решается за счет использования внешнего сервиса обмена.

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

Когда внешний сервис обмена данными Spark настроен с помощью YARN, NodeManager (управляющий узел) запускает вспомогательный сервис, который действует как внешний провайдер обмена данными. По умолчанию память NodeManager составляет около 1 ГБ. Однако приложения, выполняющие значительную перестановку данных, могут выйти из строя из-за того, что память NodeManager исчерпана. Крайне важно правильно настроить NodeManager, если ваши приложения попадают в вышеуказанную категорию.

Конец части №1, спасибо за внимание

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

Я поделился некоторыми соображениями о том, на что следует обратить внимание при рассмотрении вопроса об управлении памятью Spark. Это область, которую платформа Unravel понимает и оптимизирует очень хорошо, с небольшим количеством, если таковое вообще потребуется, человеческого вмешательства. Я рекомендую вам заказать демо-версию, чтобы увидеть Unravel в действии. Мы видим довольно значительное ускорение работы приложений Spark.

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

Источник