Описание алгоритма расчёта необходимых вычислительных ресурсов для обработки данных в Kylin

Apache Kylin – это распределенное хранилище предварительно рассчитанных и агрегированных данных, предназначенных для сложного анализа, то есть кубов оперативной аналитической обработки (OLAP)

Процесс предварительной агрегации данных выполняется после инициирования запроса на сборку сегмента куба, который генерирует задание Spark. В конфигурации куба возможно определить количество исполнителей (процессов) и объём выделенной для каждого исполнителя оперативной памяти. При запуске задания Spark происходит автоматическая конфигурация необходимых для его выполнения ресурсов, эти значения могут быть ориентиром для разработчика, но не прямым руководством к действию. Например, Spark может запросить 20 исполнителей, но, если задание выполняется на одном сервере с 10 ядрами, это не приведёт к положительному результату. Таким образом, при построении куба разработчик должен учитывать как рекомендуемые параметры, получаемые от авто конфигурации задания Spark, так и доступные ресурсы кластера/сервера. Формула расчёта необходимого объема оперативной памяти кластера/сервера представлена ниже:

Где M – размер оперативной памяти кластера/сервера;

n – количество исполнителей Spark;

M_e – размер оперативной памяти, выделенный каждому исполнителю Spark;

M_eO – размер оперативной памяти, выделенный каждому исполнителю Spark на накладные расходы;

M_d – размер оперативной памяти, выделенный драйверу Spark;

M_dO – размер оперативной памяти, выделенный драйверу Spark на накладные расходы;

M_s – размер оперативной памяти, выделенный Sparder.

Для получения оптимальных параметров конфигурации и минимизации неиспользуемых зарезервированных вычислительных ресурсов для обработки данных в Kylin было проведено тестирование. Стартовая конфигурация Hadoop и Spark была установлена таким образом, чтоб было задействовано около 90% ресурсов. Для кластера с одной нодой (узлом), технические характеристики которой 150 Гб ОЗУ, 981.46 Гб ПЗУ, 10 ядерный процессор были установлены описанные ранее в статьях параметры:

1) Общий объём оперативной памяти кластера 125 Гб;
2) Для драйвера spark выделяется 4+2 Гб;
3) Для задания spark выделяется 8 исполнителей;
4) Каждому исполнителю выделяется 8+2 Гб;
5) Для Sparder выделяется 21 Гб.

Количество исполнителей задания spark – это один и ключевых параметров, влияющих на время сборки куба. Тестирование показало, что чем больше отдельных процессоров запущено при выполнении задания построения куба, тем меньше время выполнения. Важно учесть, что каждому процессу должно быть выделено не менее одно физического ядра процессора, то есть количество исполнителей не может превышать количества ядер процессора. Также следует взять во внимание, что, кроме исполнителей при старте задания запускается драйвер Spark, кроме того, в кластере уже запущен исполнитель для Sparder. Таким образом, для указанного сервера оптимальным количеством исполнителей Spark будет 8.

Мониторинг используемых ресурсов при выполнении построения секций кубов на сервере с linux-подобной ОС может быть выполнено посредством консольной команды top. На рисунке 1 представлен вывод для команды top во время выполнения задания spark, который показывает, что для каждого исполнителя выделено около 10 Гб ОЗУ (VIRT), при этом реально используется только 4-5 Гб оперативной памяти (RES). Важно отметить, что менеджер ресурсов Hadoop отображает показатели памяти rss+swap (рисунок 2), что соответствует столбцу VIRT на рисунке 1 и не показывает реально используемых ресурсов.

Кроме мониторинга ресурсов сервера во время выполнения задания следует посмотреть рекомендуемую авто конфигурацию Spark, которую можно отследить в файле логов (рисунок 3, 4).

Анализ результатов тестирования и авто конфигурации Spark показывает, что рационально установить 5 Гб каждому исполнителю и 2 Гб в качестве накладных расходов памяти. Использование ресурсов с такой конфигурацией spark представлено на рисунках 5, 6. Следует отметить, что снижение выделенной оперативной памяти для исполнителя сократило время процессирования сегмента куба.

Теперь после того, как вычислена оптимальная конфигурация Spark в отношении ресурсов сервера, минимально необходимый размер оперативной памяти сервера для Apache Kylin составляет:
8*5Гб+2Гб+4Гб+2Гб+21Гб=83Гб

На рисунке 5 видно, что несмотря на выделенные 83 Гб оперативной памяти, используется около 63 Гб, то есть своего рода запас ресурсов предусмотрен. Таким образом, для выполнения текущих задач сервер с ОЗУ 150Гб избыточен, достаточно было бы иметь сервер с ОЗУ 83 Гб и аналогичной текущей мощностью процессора.

Список источников:

https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/NodeManagerCGroupsMemory.html
https://www.tencentcloud.com/document/product/1026/35591