Перейти к основному содержимому
Версия: 2.0.x

Query Feedback

Experimental feature

Рекомендации по использованию экспериментальных функций

В этой теме представлена функция Query Feedback, её сценарии применения и способы оптимизации планов запросов на основе обратной связи от статистики выполнения с использованием Query Plan Advisor.

Selena поддерживает функцию Query Feedback начиная с версии v1.5.2.

Обзор​

Query Feedback — это фреймворк и критически важный компонент Cost-based Optimizer (CBO). Он записывает статистику выполнения во время выполнения запроса и повторно использует её в последующих запросах с похожими планами запросов, чтобы помочь CBO генерировать оптимизированные планы запросов. CBO оптимизирует планы запросов на основе оценочной статистики, поэтому когда статистическая информация устарела или неточна, он может выбирать неэффективные планы запросов (плохие планы), такие как broadcast-передача большой таблицы или неправильный порядок левой и правой таблиц. Эти плохие планы могут вызывать таймауты выполнения запросов, чрезмерное потребление ресурсов или даже сбои системы.

Рабочий процесс​

Рабочий процесс оптимизации планов на основе Query Feedback состоит из трёх этапов:

  1. Наблюдение: BE или CN записывает основные метрики (включая InputRows и OutputRows) PlanNode в каждом плане запроса.
  2. Анализ: Для медленных запросов, превышающих настроенный порог, и запросов, помеченных для анализа вручную, система анализирует детали выполнения в критических узлах для выявления возможностей оптимизации в текущем плане запроса после завершения запроса и до возврата результата. FE сравнивает план запроса со статистикой выполнения и проверяет, является ли запрос медленным из-за аномального плана запроса. При анализе неточной статистики FE генерирует руководство по настройке SQL для каждого запроса, инструктирует CBO динамически оптимизировать запрос и рекомендует стратегии для улучшения производительности.
  3. Оптимизация: После того как CBO генерирует физический план, он ищет любое существующее руководство по настройке, применимое к плану. Если такое есть, CBO динамически оптимизирует план в соответствии с руководством и стратегиями, исправляя проблемные участки, тем самым устраняя влияние на производительность запроса из-за повторного использования плохих планов запросов. Время выполнения оптимизированного плана сравнивается с исходным планом для оценки эффективности настройки.

Использование​

Управляемый системной переменной enable_plan_advisor (по умолчанию: true), Query Plan Advisor включён по умолчанию для медленных запросов, то есть запросов со временем выполнения, превышающим порог, определённый в параметре конфигурации FE slow_query_analyze_threshold (по умолчанию: 5 секунд).

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

Ручной анализ конкретного запроса​

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

ALTER PLAN ADVISOR ADD <query_statement>

Пример:

ALTER PLAN ADVISOR ADD SELECT COUNT(*) FROM (
    SLECT * FROM c1_skew_left_over t1
    JOIN (SELECT * FROM c1_skew_left_over WHERE c1 = 'c') t2
    ON t1.c2 = t2.c2 WHERE t1.c1 > 'c' ) t;

Включение автоматического анализа для всех запросов​

Чтобы включить автоматический анализ для всех запросов, необходимо установить системную переменную enable_plan_analyzer (по умолчанию: false) в значение true.

SET enable_plan_analyzer = true;

Просмотр руководств по настройке на текущем FE​

Каждый FE ведёт собственную запись руководств по настройке. Вы можете использовать следующий оператор для просмотра руководств по настройке, сгенерированных для соответствующих запросов на текущем FE:

SHOW PLAN ADVISOR

Проверка применения руководства по настройке​

Выполните EXPLAIN для оператора запроса. В строке EXPLAIN сообщение Plan had been tuned by Plan Advisor указывает на то, что руководство по настройке было применено к соответствующему запросу.

Пример:

EXPLAIN SELECT COUNT(*) FROM (
    SLECT * FROM c1_skew_left_over t1
    JOIN (SELECT * FROM c1_skew_left_over WHERE c1 = 'c') t2
    ON t1.c2 = t2.c2 WHERE t1.c1 > 'c' ) t;
+-----------------------------------------------------------------------------------------------+
| Explain String                                                                                |
+-----------------------------------------------------------------------------------------------+
| Plan had been tuned by Plan Advisor.                                                          |
| Original query id:8e010cf4-b178-11ef-8aa4-8a5075cec65e                                        |
| Original time cost: 148 ms                                                                    |
| 1: LeftChildEstimationErrorTuningGuide                                                        |
| Reason: left child statistics of JoinNode 5 had been overestimated.                           |
| Advice: Adjust the distribution join execution type and join plan to improve the performance. |
|                                                                                               |
| PLAN FRAGMENT 0                                                                               |
|  OUTPUT EXPRS:9: count                                                                        |
|   PARTITION: UNPARTITIONED

Удаление руководства по настройке для конкретного запроса​

Вы можете удалить руководство по настройке для конкретного запроса на основе идентификатора запроса, возвращённого из SHOW PLAN ADVISOR.

ALTER PLAN ADVISOR DROP <query_id>

Пример:

ALTER PLAN ADVISOR DROP "8e010cf4-b178-11ef-8aa4-8a5075cec65e";

Очистка всех руководств по настройке на текущем FE​

Чтобы очистить все руководства по настройке на текущем FE, выполните следующий оператор:

TRUNCATE PLAN ADVISOR

Сценарии использования​

В настоящее время Query Feedback в основном используется для оптимизации следующих сценариев:

  • Оптимизация порядка левой и правой сторон в локальных узлах Join
  • Оптимизация метода выполнения локальных узлов Join (например, переключение с Broadcast на Shuffle)
  • Для случаев со значительным потенциалом агрегации принудительное использование режима pre_aggregation для максимизации агрегации данных на первой фазе

Руководства по настройке в основном основаны на метриках Runtime Exec Node Input/Output Rows и statistics estimated rows FE. Поскольку текущие пороговые значения настройки относительно консервативны, рекомендуется использовать Query Feedback для проверки потенциальных улучшений производительности при обнаружении проблем в Query Profile или строке EXPLAIN.

Ниже представлены три распространённых сценария использования.

Случай 1: Неправильный порядок Join​

Исходный плохой план:

small left table inner join large table (broadcast)

Оптимизированный план:

large left table inner join small right table (broadcast)

Причина Проблема может быть вызвана устаревшей или отсутствующей статистикой, что приводит к тому, что Cost-Based Optimizer (CBO) генерирует неправильный план на основе неточных данных.

Решение Во время выполнения запроса система сравнивает input/output rows и statistics estimated rows Left Child и Right Child, генерируя руководства по настройке. При повторном выполнении система автоматически корректирует порядок Join.

Случай 2: Неправильный метод выполнения Join​

Исходный плохой план:

large left table1 inner join large right table2 (broadcast)

Оптимизированный план:

large left table1 (shuffle) inner join large right table2 (shuffle)

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

Решение Во время выполнения запроса система сравнивает input/output rows и statistics estimated rows Left Child и Right Child, генерируя руководства по настройке. После оптимизации метод Join изменяется с Broadcast Join на Shuffle Join.

Случай 3: Неэффективный режим предварительной агрегации первой фазы​

Симптом Для данных с хорошим потенциалом агрегации режим auto агрегации первой фазы может агрегировать только небольшой объём локальных данных, упуская возможность повышения производительности.

Решение Во время выполнения запроса система собирает Input/Output Rows для локальных и глобальных агрегаций. На основе исторических данных она оценивает потенциал столбцов агрегации. Если потенциал значительный, система принудительно использует режим pre_aggregation в локальных агрегациях, максимизируя агрегацию данных на первой фазе и улучшая общую производительность запроса.

Ограничения​

  • Руководство по настройке может использоваться только для точно такого же запроса, для которого оно было сгенерировано. Оно не применимо к запросам с тем же шаблоном, но с другими параметрами.
  • Каждый FE управляет своим Query Plan Advisor независимо, и синхронизация между узлами FE не поддерживается. Если один и тот же запрос отправляется на разные узлы FE, результаты настройки могут отличаться.
  • Query Plan Advisor использует структуру кэша в памяти:
    • Когда количество руководств по настройке превышает лимит, просроченные руководства автоматически удаляются.
    • Лимит руководств по настройке по умолчанию составляет 300, и сохранение исторических руководств по настройке не поддерживается.