Когда Impala-запрос начинает выполняться заметно дольше обычного, первое место, куда обычно идут смотреть - query profile, то есть профиль запроса. Там есть план выполнения, счетчики, оценки кардинальности, память, scan-часть, exchange, admission, хвосты по backend-ам и другая полезная информация.

Проблема в том, что текстовый profile не слишком удобный для анализа. Он большой, в нем много повторяющихся секций, часть сигналов видна только в связке с другими счетчиками. При этом почти всегда внутри есть чувствительная информация: SQL-текст, имена таблиц и колонок, пользователи, resource pools, хосты, фрагменты топологии выполнения.

Поэтому на практике появляются два привычных варианта:

Разбирать profile руками.
Скопировать SQL и profile в LLM и попросить объяснить, что не так.

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

Что в profile чувствительного

Impala profile - это не просто лог. Это срез выполнения запроса и окружения.

Даже если там нет паролей и токенов, обычно там можно найти:

SQL и литералы;
имена баз, таблиц, колонок и партиций;
пользователей, pools, coordinator и backend-хосты;
объемы чтения, runtime counters, memory estimates, spills;
признаки admission wait, skew, exchange pressure;
косвенные признаки бизнес-логики и нагрузки.

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

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

Что не так с диагнозом «на глаз»

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

Например:

Admission wait может говорить об очереди, лимитах пула или давлении на кластер, но сам по себе не объясняет форму плана.
Memory pressure полезен рядом с join, aggregation или sort, но без estimates, spills и формы плана это только часть картины.
Cardinality mismatch показывает расхождение оценок и фактических строк, но не всегда означает, что достаточно собрать статистику.
Scan skew может объяснять дисбаланс backend-ов, но нужен контекст scan volume, партиций и layout данных.
Exchange wait / intermediate data movement часто ведет к review join shape, pre-aggregation или filter pushdown.
Writer/fetch tail объясняет длинный хвост после основной работы, но не всегда указывает на storage-проблему.

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

Из этого требования и вырос Query Doctor: инструмент для локального разбора Impala-профилей, где автоматизация помогает быстрее дойти до места проверки, но не получает права выдумывать диагноз.

Как устроен Query Doctor

Сейчас Query Doctor работает только с Apache Impala. Другие движки возможны как направление развития, но сейчас не поддерживаются в публичном продукте.

Он может работать с Cloudera Manager, если он есть, или с ограниченными direct impalad endpoints для Recent, Running и одного Known Query ID сценария. Cloudera Manager остается полным источником discovery/profile/metrics/events для Impala. Direct Impala поддерживает ограниченные Recent/Running/Known Query ID сценарии без Cloudera Manager events; optional Prometheus metrics, /profile_docs и /admission?json используются только как дополнительный контекст и должны спокойно превращаться в unknown/unavailable на старых кластерах.

Общий флоу такой:

Сборщик получает ограниченный контекст только для чтения.
Анализатор извлекает факты.
Скоринг выбирает подозрительные запросы и кандидатов на оптимизацию или сбор статистики.
Отчет или проверка оптимизатора запускаются только явно для выбранного запроса.
Отчет проходит нормализацию, очистку и валидацию.
В интерфейс и доверенные отчеты не попадают raw SQL, raw profiles, raw metadata, локальные пути, секреты, названия моделей, runtime internals, вывод подпроцессов и имена сырых артефактов.

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

Что Query Doctor НЕ делает

Эти границы лучше проговорить явно.

Query Doctor:

не выполняет пользовательский SQL;
не выполняет черновики SQL от оптимизатора;
не является оракулом первопричины;
не заменяет Cloudera Manager или Impala Web UI;
не обещает поддержку всех движков запросов;
не превращает raw profile в безопасный публичный артефакт;
не делает вывод LLM доверенным без детерминированной валидации.

Текущий реализованный движок - Apache Impala. Заделы под другие движки есть только как направление развития, но не как поддержанная функциональность. В репозитории есть закрытая подготовительная работа по Trino, но это fixture-only/private-preview: без live collection, без экрана выбора движка и без заявленной поддержки Trino.

Демо на синтетических кейсах

Команды и сценарии ниже актуальны для query-doctor 0.4.1.

Публичное демо синтетическое. В нем нет реальных SQL, профилей, метаданных, хостов, пользователей или учетных данных.

Локально демо можно поднять так:

python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install query-doctor
query-doctor-demo-preflight
DEMO_PACK="${TMPDIR:-/tmp}/query-doctor-demo-pack"
query-doctor-demo --out "$DEMO_PACK" --overwrite
QUERY_DOCTOR_ACTION_OUTCOMES_PATH="$DEMO_PACK/action_outcomes.jsonl" \
  query-doctor-web --host 127.0.0.1 --port 8766 --batch-summary "$DEMO_PACK/batch_summary.json"

В текущем синтетическом наборе одиннадцать кейсов, очищенных от чувствительных данных. Они показывают не только оптимизацию SQL и статистику, но и группы Workloads, регрессию admission/runtime, Storage/HDFS follow-up, частые короткие запросы, смешанные сигналы, unknown-but-useful сценарий и совместимость direct Impala.

Кейс 1: очередь действий по workload-группам

Первый экран демо теперь лучше строить не вокруг одного запроса, а вокруг Action Queue. Например, пара demo-admission-0004 / demo-admission-0005 показывает регрессию workload-группы, где основной сигнал - admission/runtime, а не форма SQL.

Детерминированная цепочка там такая:

похожие запросы попали в одну workload-группу без показа сырого SQL;
длительность выросла относительно локального baseline;
admission wait занимает большую часть общего времени выполнения;
рекомендуемое действие - смотреть pool/admission/runtime контекст вокруг окна выполнения;
проверка - сопоставимый rerun, где admission wait и p95 группы больше не доминируют.

Практический вывод: не каждый медленный запрос надо начинать с переписывания SQL. Иногда первый безопасный шаг - проверить очередь, лимиты пула и runtime-контекст.

Кейс 2: кандидат на разбор формы запроса (demo-optimizer-0001)

Этот кейс показывает сильного кандидата на оптимизацию формы запроса, но без обещания готового SQL.

Опорные сигналы:

duration: 315 секунд;
query optimization candidate: high, impact: high, confidence: medium;
cardinality anomalies: 4, memory anomalies: 3;
есть сигналы join row expansion, large exchange/intermediate movement и memory pressure around join/aggregation operators;
metadata не собиралась, поэтому выводы о статистике остаются unknown.

Практический вывод: запрос стоит отправить на разбор формы запроса. В первую очередь смотреть join keys, join cardinality, pre-aggregation и filter pushdown.

Некорректный вывод:

Причина точно в join'ах. Вот переписанный SQL, можно запускать.

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

Кейс 3: кандидат на обновление статистики (demo-stats-0002)

Этот кейс показывает сильного кандидата на обновление статистики.

Опорные сигналы:

metadata status: collected;
table stats status: missing or incomplete;
stats optimization candidate: high, impact: high, confidence: medium;
duration: 96 секунд;
cardinality anomalies: 3;
need type: table and column stats;
required confirmation: сравнить EXPLAIN до/после обновления статистики и выполнить сопоставимый rerun.

Здесь важно не перепрыгнуть через проверку. “Stats are missing” и “stats caused the slowdown” - разные утверждения.

Первое можно поддержать фактами из метаданных. Второе требует проверки плана и сопоставимого rerun.

COMPUTE STATS иногда действительно помогает, но это не универсальная таблетка. Сначала нужно понять, почему мы решили, что обновление статистики имеет отношение к проблеме.

Кейс 4: валидатор отклоняет небезопасный черновик (demo-validator-0003)

Этот кейс показывает отказ от небезопасного результата.

Опорные сигналы:

query optimization candidate: medium, impact: high, confidence: medium;
metadata status: not_requested;
table stats status: not_checked;
backend data skew: true;
cardinality anomalies: 2, memory anomalies: 2;
counter-signal: draft validation rejected unsafe shape change.

Это нормальное поведение инструмента. Query Doctor может сказать, что запрос стоит посмотреть внимательнее. Но это не значит, что существует безопасный черновик SQL.

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

Оставшиеся сценарии в демо нужны, чтобы показать границы: Storage/HDFS follow-up не сводится к переписыванию SQL, частые короткие запросы не всегда заслуживают высокого приоритета, смешанные сигналы не должны превращаться в искусственную уверенность, unknown может быть полезным результатом, а совместимость direct Impala показывает работу без Cloudera Manager events и без обязательных optional endpoints.

Зачем это нужно

В реальной эксплуатации диагностика запросов часто находится между двумя крайностями.

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

С другой - быстрый ответ от LLM по сырому SQL/profile. Это быстро, но плохо контролирует безопасность данных, факты и уровень уверенности.

Посередине между ними Query Doctor делает несколько простых вещей:

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

Это не отменяет ручную диагностику. Скорее сокращает путь до места, где человеку нужно посмотреть внимательнее.

Где нужна обратная связь

Если вы работаете с Impala профилями, мне особенно интересно:

какие profile facts вы чаще всего используете при инцидентах;
какие counters или секции профиля чаще всего неправильно интерпретируют;
какие синтетические кейсы стоит добавить;
какие поля профиля слишком зависят от версии/configuration, чтобы строить на них надежные инструменты;
какие диагностические выводы должны оставаться кандидатами, а не первопричиной.

Код на Гитхабе

Пакет

Если хотите показать реальный кейс, сначала удалите или замаскируйте чувствительные данные: SQL, профиль, метаданные, хосты, пользователей и пути. Другой безопасный вариант — описать ситуацию словами без операционных артефактов.

Медленные запросы в Impala: как анализировать profile и не выносить SQL наружу