Помните процесс оптимизации HQL

Вспомните процесс решения проблемы несахарного диабета при относительно большом «объеме данных»~~

предыстория истории

Предыстория истории такова.Маленький друг написал говноподобный HQL.После того как объем данных стал большим,прямо завалило.Когда я увидел его SQL,я почувствовал,что смогу спасти этого бедного ребенка.С тех пор , Я встал на путь медленной адаптации!

Во-первых, общая логика SQL заключается в том, что таблица A дважды связывает таблицу информации о клиентах B. Простой оператор SQL выглядит следующим образом:

A left join B
on a.id_1 = b.id
left join B
on a.id_2 = b.id

Его первоначальный стиль письма не восстановить, а схема мозга слишком четкая, простите, я не могу вспомнить, как он это изначально написал.

Отправляться

Ну что начнем.Переписав SQL приступаем к настройке параметров.Сначала входим в план мозга.

Таблица B не разделена на ведра, она заслуживает того, чтобы быть медленной, измените ее!

create table B
partition by day
clustered by (id)
sorted by (id)
into 6 buckets
row …………;

Создавать бакеты с id, использовать ID для ассоциации, а так же менять формат хранения файлов ORC, надеюсь скорость получения некоторых колонок будет быстрее;

После импорта данных выясняется, что их всего более 300 М. Можно ли использовать MapJoin? ! ! Делай волну!

set hive.auto.convert.sortmerge.join=true;  
set hive.optimize.bucketmapjoin = true;  
set hive.optimize.bucketmapjoin.sortedmerge = true;  
set hive.auto.convert.sortmerge.join.noconditionaltask=true; 

Ведь в Application есть только этап Map, а задачи Reduce нет, однако! При выполнении второго этапа снова вылетает!

психически искаженный

В это время я сделал умственно отсталую ошибку, ** не прочитав Журнал! ! ! ** Считайте само собой разумеющимся изменение SQL, так как есть два этапа, поставьте первыйleft joinМожно ли кэшировать в промежуточную таблицу результатов?

Это обязательство!

with tmp_table as (……), и обнаружил, что он может представлять только простую структуру таблицы и не содержит вложенных операторов запроса.

Меня это не беспокоит, не так ли?create table asМы сделаем это! Одна операция свирепа как тигр, а открытие все равно рушится......

В это время я совершил еще одну умственно отсталую ошибку, не просмотрев Журнал! ! ! !

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

set hive.exec.compress.output=true;
set hive.exec.compress.intermediate=true;
set hive.default.fileformat=SequenceFile;
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

Этап сжатия промежуточного результата, формат файла SequenceFile, без проблем!

Кстати, добавь небольшие параметры слияния файлов, все в порядке!

-- Map阶段小文件合并
set hive.merge.mapfiles=true;   
-- Reduce阶段小文件合并
set hive.merge.maprefiles=true;
-- 超过这个文件大小，启动单独的MR程序进行合并
set hive.merge.size.per.task=1280000;

Казнить, несахарный диабет 2 стадии! Психика постепенно начала искажаться.

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

Измените количество параметров Map, Reduce и memory. различные эксперименты.

В это время обнаружено, что коэффициент использования ЦП и памяти Yarn низкий, устраивайте!

set mapreduce.map.memory.mb=1024;
set mapreduce.map.cpu.vcores=2;
set mapreduce.reduce.memory.mb=1024;
set mapreduce.map.reduce.cpu.vcores=2;

успокаивать

Беги! CPU и Mem поднимаются, но у гусыни Stage-2 понос продолжается...

После крушения я, наконец, начал успокаиваться и проверять журнал…………КонтейнерBeyond physics memory …………Память контейнера превышает лимит... Большое количество OOM для Задач.

Таким образом, должно быть два подхода:

1. Чтобы увеличить параметры Container, вам необходимо изменить конфигурацию кластера Yarn;
2. Ограничьте задачу фазы «Уменьшение» задачи MR;

Сначала меняйте Yarn, это бесполезно, он все равно вылетает, а лимит памяти не изменился, оставим его в покое и попробуем второй способ:

set mapred.map.child.java.opts=-Xmx1024m;
set mapred.reduce.child.java.opts=-Xmx2048m;

У меня все еще понос, но я в это время успокоилась, и моя интуиция подсказывала мне, что я вот-вот увижу Женьчжана!

Кстати, я обнаружил, что объем данных Стадии 2 намного больше, чем у Стадии 1. Не знаю почему, это вышло за границы моих знаний, давайте поговорим об этом! (Купите пасхальное яйцо, здесь ядерный взрыв!)

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

Оставьте лимит памяти для задачи Reduce без изменений и уменьшите размер данных, сегментированных с помощью Reduce. 256M разделяет Уменьшить, поехали!

Надежный!

После 5 долгих часов я, наконец, завершил весь процесс без сбоев в первый раз.

"Это" полностью выполнило задание~

Surprise

Движимые любопытством, посмотрите на окончательный результат пробега!

Святое дерьмо, предполагаемый объем данных составляет 100 миллионов, а вышло более 7 миллиардов! ! ! ! Взорваться! ! ! Расширение более чем в 70 раз! ! !

Проблема с разделом? все еще? ? ? успокаивать!

Это показывает, что есть проблема с логикой SQL-запроса, и есть проблема в самом источнике! ! ! Вовсе не до такой степени, что его нужно оптимизировать!

Это показывает, что более серьезной проблемой, чем не просмотр журнала, является:

Не трогайте данные, не проверяйте правильность SQL, сразу переходите к нему! ! !

Итак, самое главное для оптимизации:

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

Хорошо, приступим к устранению неполадок и воспользуемся 10 записями.left joinДалее было найдено более 100 записей.

Ознакомьтесь с документацией, чтобы узнать Hiveleft join == left outer join.

Не существует метода записи левого внутреннего соединения, поэтому, когда значение id таблицы B имеет большое количество повторений, оно будет сохранено в конечном результате.

例如：A表
a,10
b,5

B表
a,3
a,4
b,5
b,6

SQL：A left join B on a.id = b.id
结果就是
a,10,3
a,10,4
b,5,5
b,5,6

Честно говоря, это действительно слепое пятно моих знаний. Что-то я раньше не замечал.

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

Исследуя распределение данных, много дублирующихся данных, более 50 записей на пользователя! ! ! То, что делает этот ETL, является призраком...  

Расположение Расположение... Гарантия того, что таблица B уникальна.

Беги снова, 10 минут! Всего 10 минут! ! ! Проверить результат не проблема.

Успешно раскрыто дело, посыпать цветами~~~

Пришло время для подведения итогов класса

Допустил несколько ошибок (в порядке значимости):

1. Не трогайте исходные данные, не проверяйте правильность SQL, это основная причина, исходник не застрял, а доработка бесполезна;
2. Если вы не проверяете журнал, сообщение об ошибке очевидно, но большая часть работы на ранней стадии оптимизируется из воздуха;
3. После локализации проблемы анализа нет, а параметры оптимизации тоже угадываются. Слишком много повторяющихся действий, и нет глубокого копания возникших проблем. Программа MR по прежнему очень медленная и тратит много времени!

Тем не менее, после долгих метаний, многие точки оптимизации были глубоко выкопаны.

• Карта, Уменьшить число, ЦП, настройки памяти
• Настройки памяти задач
• MapJoin
• Сжатие, формат файла, таблица сегментов
• Слияние небольших файлов

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

Также экспериментировал с распределением в случайном порядке.

set mapreduce.reduce.shuffle.merge.percent=0.3;

Хотя я не знаю, для чего это.

Хотя на этот раз проблема была обнаружена по счастливой случайности, все же повезло, и позиционирование проблемы было слишком медленным, а лилейник был холодным. продолжать составлятьПринципы MapReduce и Yarn;Кроме тогоОператор улья и сценическое подразделениеЭта часть дефекта также нуждается в срочном исправлении.

На этот раз «докопаться до сути» подошло к концу, и Yarn приступает к следующему раунду!