Оптимизация производительности Hive на уровне предприятия (рекомендуемая коллекция хороших статей)

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

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

Эта статья впервые опубликована в паблике: пять минут на изучение больших данных

Как устранить проблемы с производительностью Hive

Когда мы обнаруживаем, что время выполнения оператора SQL слишком велико или неразумно, мы должны рассмотреть возможность оптимизации SQL.Сначала оптимизация должна быть выполнена для устранения неполадок, поэтому какие методы мы можем использовать для устранения неполадок?

Учащиеся, часто использующие реляционные базы данных, могут знать приемы оптимизации реляционных баз данных.посмотреть план выполнения. Например, база данных Oracle имеет различные типы планов выполнения.Благодаря сочетанию различных планов выполнения вы можете увидеть план выполнения, выведенный из статистической информации, то есть план выполнения, выведенный Oracle, который фактически не выполняется; вы также можете увидеть фактический план выполнения План выполнения для выполнения задач, возможность наблюдать за основным процессом от чтения данных до окончательного представления и количественных данных между ними. Можно сказать, что в сфере разработки Oracle настройка SQL не является сложной задачей путем освоения соответствующих ссылок и выбора различных планов выполнения.

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

Чтобы узнать текущую информацию обо всех этапах HiveSQL, вы можете просмотретьЛоги предоставлены YARN. Ссылку на просмотр журнала можно найти в информации, которая выводится на консоль после выполнения каждого задания. Как показано ниже:

План выполнения, предоставленный Hive, в настоящее время может отображать следующую информацию::

просмотреть основную информацию плана выполнения, то есть пояснить;
Просмотр расширенной информации плана выполнения, то есть объяснение расширенного;
Просмотр информации о зависимостях ввода данных SQL, то есть объяснение зависимости;
Просмотр информации о разрешениях, связанных с операциями SQL, то есть объяснение авторизации;
Просмотрите информацию описания векторизации SQL, то есть объясните векторизацию.

Добавление ключевого слова объяснения перед SQL оператора запроса является основным способом просмотра плана выполнения. План выполнения, открытый с помощью объяснения, состоит из следующих двух частей:

Граф зависимостей задания, то есть STAGE DEPENDENCIES;
Детали каждой работы, т.е. ЭТАПНЫЕ ПЛАНЫ.

Подробное объяснение плана выполнения объяснения в Hive см. в этой статье, которую я написал ранее.:

Основной принцип Hive: подробно объясните план выполнения

Примечание. Использование объяснения для просмотра плана выполнения — очень важный способ настройки производительности Hive, обязательно освойте его!

Сводка: Как Hive устраняет проблемы с производительностью операторов SQL:

Используйте объяснение для просмотра плана выполнения;
Просмотрите журналы, предоставленные YARN.

Как настроить производительность Hive

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

Далее мы познакомим вас с разнообразием оптимизации Hive с нескольких совершенно разных точек зрения. Давайте попробуем это вместе.

1. Оптимизация операторов SQL

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

1. union all


insert into table stu partition(tp) 
select s_age,max(s_birth) stat,'max' tp 
from stu_ori
group by s_age

union all

insert into table stu partition(tp) 
select s_age,min(s_birth) stat,'min' tp 
from stu_ori
group by s_age;

Мы просто анализируем приведенный выше оператор SQl, то есть получаем максимальное и минимальное дни рождения каждого возраста и помещаем их в одну таблицу.Два оператора до и после объединения группируют одну и ту же таблицу в соответствии с s_age, а затем берут максимальное и минимальное значение. Дважды группировать одно и то же поле в одной и той же таблице — огромная трата времени. Можем ли мы его преобразовать? Конечно, можно ввести для вас синтаксис:from ... insert into ..., этот синтаксис начинается с, функция заключается в использовании таблицы, которая может выполнять несколько операций вставки:

--开启动态分区 
set hive.exec.dynamic.partition=true; 
set hive.exec.dynamic.partition.mode=nonstrict; 

from stu_ori 

insert into table stu partition(tp) 
select s_age,max(s_birth) stat,'max' tp 
group by s_age

insert into table stu partition(tp) 
select s_age,min(s_birth) stat,'min' tp 
group by s_age;

Приведенный выше SQL может сгруппировать поле s_age таблицы stu_ori один раз и выполнить две разные операции вставки.

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

2. distinct

Давайте сначала посмотрим на SQL, чтобы удалить двойной счет:

select count(1) 
from( 
  select s_age 
  from stu 
  group by s_age 
) b;

Это простой подсчет значений перечисления возраста, почему бы не использовать отдельные?

select count(distinct s_age) 
from stu;

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

Давайте проигнорируем проблему большого количества данных,Использование Different в текущем бизнесе и среде определенно будет более эффективным, чем описанный выше метод подзапроса.. Причины следующие:

Вышеприведенное дедуплицированное поле — это поле age. Вы должны знать, что значение перечисления age очень ограничено. Даже если вы вычислите возраст от 1 до 100 лет, максимальное значение перечисления s_age равно 100. Если его преобразовать в MapReduce объяснить. Если это так, на этапе карты каждая карта будет дедуплицировать s_age. Поскольку значение перечисления s_age ограничено, s_age, полученный каждой картой, также ограничен, и количество сокращенных данных, наконец, равно количеству карт * количеству значений перечисления s_age.
Отдельная команда построит в памяти хеш-таблицу, а временная сложность поиска и дедупликации будет O (1), а при сортировке оптимальная временная сложность сортировки не может достигать O (1). Кроме того, дедупликация первого метода (группировка по) будет преобразована в две задачи, которые будут потреблять больше дисковых сетевых ресурсов ввода-вывода.
В последней версии Hive 3.0 добавлена оптимизация подсчета (отличных), которую можно настроить, настроивhive.optimize.countdistinct, даже если данные искажены, они могут быть автоматически оптимизированы, а логика выполнения SQL может быть автоматически изменена.
Второй способ (различный) лаконичнее первого (группировать по), а смысл выражения прост и понятен, если особых проблем нет, то лаконичный код отличный!

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

2. Оптимизация формата данных

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

Hive предоставляет следующие форматы: TEXT, SequenceFile, RCFile, ORC и Parquet.

SequenceFile — это плоский файл со структурой двоичной пары ключ/значение, который широко использовался в качестве формата вывода/вывода MapReduce на ранних платформах Hadoop, а также в качестве формата хранения данных.

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

Оптимизация ORC — это оптимизация RCFile, которая обеспечивает эффективный способ хранения данных Hive, а также может повысить производительность Hive при чтении, записи и обработке данных и совместима с несколькими вычислительными системами. Фактически, в реальной производственной среде ORC стал одним из основных вариантов хранения данных Hive.

Мы используем те же данные и операторы SQL, но формат хранения данных другой, и мы получаем следующее время выполнения:

Формат данных	процессорное время	Время ожидания пользователя
TextFile	33 балла	171 секунда
SequenceFile	38 баллов	162 секунды
Parquet	2 минуты 22 секунды	50 секунд
ORC	1 минута 52 секунды	56 секунд

Примечание:процессорное время: указывает время, в течение которого работающая программа занимает ресурсы ЦП сервера.

*用户等待耗时*：记录的是用户从提交作业到返回结果期间用户等待的所有时间。

Запрос таблицы данных типа TextFile занимает 33 минуты, а запрос таблицы типа ORC — 1 минута 52 секунды, что сильно укорочено.Видно, что разные форматы хранения данных также могут сильно влиять на производительность HiveSQL. .

3. Слишком много оптимизации для маленьких файлов

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

Поэтому нам необходимо оптимизировать слишком много маленьких файлов.Что касается решения слишком большого количества маленьких файлов, я написал статью, чтобы объяснить решение.Подробности см.:

Решить проблему слишком большого количества мелких файлов в улье

4. Параллельное выполнение оптимизаций

Hive превращает запрос в один или несколько этапов. Такими этапами могут быть этап MapReduce, этап выборки, этап слияния, этап ограничения. Или другие этапы, которые могут потребоваться во время выполнения Hive. По умолчанию Hive будет выполнять только один этап за раз. Однако конкретное задание может содержать множество этапов, и эти этапы могут не быть полностью зависимыми друг от друга, а значит, некоторые этапы могут выполняться параллельно, что может сократить время выполнения всего задания. Чем больше этапов может выполняться параллельно, тем быстрее может завершиться задание.

Установив для параметра hive.exec.parallel значение true, можно включить параллельное выполнение. В общем кластере следует отметить, что чем больше параллельных стадий в задании, тем выше будет загрузка кластера.

set hive.exec.parallel=true; //打开任务并行执行
set hive.exec.parallel.thread.number=16; //同一个sql允许最大并行度，默认为8。

Конечно, есть преимущество, когда системные ресурсы относительно простаивают, иначе ресурсов нет, и параллелизм будет невозможен.

5. JVM-оптимизация

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

Конфигурация Hadoop по умолчанию обычно заключается в использовании производной JVM для выполнения карт и сокращения задач. В это время процесс запуска JVM может вызвать значительные накладные расходы, особенно если выполняемое задание содержит сотни или тысячи задач. Повторное использование JVM позволяет повторно использовать экземпляр JVM N раз в одном и том же задании. Значение N можно найти в Hadoopmapred-site.xmlконфигурационный файл. Обычно от 10 до 20, конкретная сумма должна быть проверена в соответствии с конкретными бизнес-сценариями.

<property>
  <name>mapreduce.job.jvm.numtasks</name>
  <value>10</value>
  <description>How many tasks to run per jvm. If set to -1, there is
  no limit. 
  </description>
</property>

Мы также можем установить в улей

set  mapred.job.reuse.jvm.num.tasks=10; //这个设置来设置我们的jvm重用

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

6. Оптимизация спекулятивного исполнения

В среде распределенного кластера из-за программных ошибок (включая ошибки самого Hadoop), несбалансированной нагрузки или неравномерного распределения ресурсов скорость выполнения нескольких задач одного и того же задания может быть непостоянной, а скорость выполнения некоторых задач может быть очевидной. , Медленнее, чем другие задачи (например, задача задания выполняется только на 50%, в то время как все остальные задачи завершили выполнение), то эти задачи будут замедлять общий ход выполнения задания. Чтобы избежать этой ситуации, Hadoop использует механизм спекулятивного выполнения (Speculative Execution), который выводит «обратную» задачу в соответствии с определенными правилами и запускает задачу резервного копирования для такой задачи, чтобы задача и исходная задача могли обрабатываться. та же задача в то же время данные, и, наконец, выберите результат расчета первой успешной операции для завершения задачи в качестве конечного результата.

Установите параметр для включения спекулятивного выполнения: hadoopmapred-site.xmlНастройте в файле:

<property>
  <name>mapreduce.map.speculative</name>
  <value>true</value>
  <description>If true, then multiple instances of some map tasks 
               may be executed in parallel.</description>
</property>

<property>
  <name>mapreduce.reduce.speculative</name>
  <value>true</value>
  <description>If true, then multiple instances of some reduce tasks 
               may be executed in parallel.</description>
</property>

Сам hive также предоставляет элементы конфигурации для управления спекулятивным выполнением на стороне сокращения:

set hive.mapred.reduce.tasks.speculative.execution=true

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

Публичный аккаунт [Пять минут на изучение больших данных], оригинальный технологический аккаунт в области больших данных

Наконец

Принципы оптимизации кода:

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