Query Feedback

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

Поддерживается с v3.4.0.

Обзор

Query Feedback — это фреймворк и ключевой компонент Cost‑Based Optimizer (CBO). Он фиксирует статистики выполнения (например, InputRows/OutputRows) и переиспользует их в последующих запросах с похожими планами, помогая CBO формировать более подходящие физические планы. При устаревшей или неточной статистике CBO может выбирать неэффективные планы (например, широковещательный Broadcast для большой таблицы или неверный порядок соединения), что приводит к таймаутам, перерасходу ресурсов и сбоям.

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

Оптимизация на основе Query Feedback состоит из трёх стадий:

  1. Наблюдение. BE или CN записывают ключевые метрики PlanNode каждого плана запроса, включая InputRows и OutputRows.

  2. Анализ. Для «медленных» запросов (выше порога) и для явно помеченных к анализу запросов система анализирует детали выполнения в критических узлах сразу после окончания запроса и до возврата результата. FE сравнивает план с фактическими статистиками, определяя, не вызвана ли «медленность» аномальным планом. Выявляя неточности статистики, FE генерирует «гайд по тюнингу» (SQL tuning guide), инструктирует CBO о динамической оптимизации запроса и рекомендует стратегии улучшения.

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

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

По умолчанию Query Plan Advisor включён для «медленных» запросов и управляется системной переменной enable_plan_advisor (Default: true). Порог «медленных» запросов задаётся параметром FE slow_query_analyze_threshold (Default: 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;

Автоматический анализ для всех запросов

Чтобы включить анализ для всех запросов, установите:

SET enable_plan_analyzer = true;

Просмотр «гайдов» на текущем FE

Каждый FE хранит собственные записи «гайдов». Посмотреть их можно так:

SHOW PLAN ADVISOR

Проверка применения «гайда»

Выполните EXPLAIN для запроса. В выводе Explain String наличие строки Plan had been tuned by Plan Advisor означает, что «гайд» применён.

Удаление «гайда» по конкретному запросу

Удалите «гайд» по Query ID, полученному из SHOW PLAN ADVISOR:

ALTER PLAN ADVISOR DROP "<query_id>";

Очистка всех «гайдов» на текущем FE

TRUNCATE PLAN ADVISOR

Сценарии применения

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

  • Выбор корректного порядка левой/правой стороны в локальных Join‑узлах.

  • Выбор корректного метода выполнения локальных Join‑узлов (например, BROADCAST → SHUFFLE).

  • Включение режима pre_aggregation в первой фазе при высоком потенциале агрегации.

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

Ограничения

  • «Гайд» применим только к идентичному запросу, для которого он был сгенерирован (не распространяется на такой же шаблон с иными параметрами).

  • Каждый FE управляет «гайдами» независимо; синхронизация между FE не поддерживается. При выполнении одного и того же запроса на разных FE результаты могут отличаться.

  • Query Plan Advisor использует in‑memory кэш: при превышении лимита устаревшие «гайды» выталкиваются. Лимит по умолчанию ~300; долговременная персистентность истории не поддерживается.