Когда 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;
-
косвенные признаки бизнес-логики и нагрузки.
Эти данные часто нельзя просто отправить во внешний сервис. Внутри компании они тоже не всегда должны свободно разъезжаться по чатам и тикетам без обработки.
Отсюда простое требование к диагностическому инструменту: сырые артефакты остаются локально, а наружу и в UI попадают только проверенные, отредактированные и короткие выводы.
Что не так с диагнозом «на глаз»
В 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-проблему.
Поэтому формулировки важны.«Есть кандидат для проверки» и «найдена причина» — разные утверждения. В production-диагностике эта разница не косметическая: от нее зависит, будет ли человек делать безопасную проверку или сразу менять SQL, статистику, пул или настройки.
Я сделал Query Doctor как попытку оставить полезную часть автоматизации, но не отдавать наружу сырой operational context.
Как устроен Query Doctor
Текущая версия Query Doctor сфокусирована только на Apache Impala. Другие движки возможны только как roadmap, но сейчас не поддерживаются.
Инструмент может работать с Cloudera Manager, если он есть, или с bounded direct impalad endpoints для Recent, Running и одного Known Query ID workflow. Сбор контекста остается локальным, read-only и ограниченным.
Общий workflow такой:
-
Collector собирает bounded read-only context.
-
Analyzer извлекает факты.
-
Scoring выбирает подозрительные запросы и кандидатов на оптимизацию или сбор статистики.
-
Отчет или optimizer review запускаются только явно для выбранного case.
-
Report проходит нормализацию, санитацию и валидацию.
-
В UI и trusted reports не попадают raw SQL, raw profiles, raw metadata, local paths, secrets, model names, runtime internals, subprocess output и raw artifact filenames.
LLM в этом подходе не является источником фактов. Его роль — помочь написать читаемый текст поверх уже извлеченных и проверенных сигналов. Если фактов не хватает, корректный результат — “нужно проверить”, “не наблюдается” или “unknown”, а не уверенная история про root cause.
Демо на synthetic cases
Публичное демо синтетическое. В нем нет реальных SQL, profiles, metadata, хостов, пользователей или credentials.
Локально демо можно поднять так:
python3 -m venv .venv. .venv/bin/activatepython -m pip install --upgrade pippython -m pip install query-doctorquery-doctor-demo-preflightquery-doctor-demo --out /tmp/query-doctor-demo-pack --overwritequery-doctor-web --batch-summary /tmp/query-doctor-demo-pack/batch_summary.json
В текущем synthetic pack есть три показательных кейса.
Кейс 1: query-shape review candidate (demo-optimizer-0001)
Первый synthetic case показывает high query optimization candidate.
Детерминированные факты:
-
synthetic duration: 315 секунд;
-
metadata status: not_requested;
-
table stats status: not_checked;
-
referenced tables: 2;
-
collected metadata tables: 0;
-
query optimization candidate: high;
-
impact: high;
-
confidence: high;
-
cardinality anomalies: 4;
-
memory anomalies: 3;
-
zero/unknown row estimate gaps: 2;
-
zero/unknown memory estimate gaps: 1;
-
host-tail candidates: 1;
-
reasons: join row expansion, large exchange/intermediate movement, memory pressure around join/aggregation operators;
-
metadata не собиралась, поэтому выводы о статистике остаются unknown.
Практический вывод: запрос стоит отправить на query-shape review. В первую очередь смотреть join keys, join cardinality, pre-aggregation и filter pushdown.
Некорректный вывод:
Причина точно в join'ах. Вот переписанный SQL, можно запускать.
Такой переход слишком резкий. Есть набор сигналов, но нет доказательства единственной причины и нет права автоматически выдавать SQL как безопасную замену.
Кейс 2: stats maintenance candidate (demo-stats-0002)
Второй synthetic case показывает high stats optimization candidate.
Детерминированные факты:
-
metadata status: collected;
-
table stats status: missing or incomplete;
-
referenced tables: 2;
-
collected metadata tables: 2;
-
stats optimization candidate: high;
-
impact: high;
-
confidence: medium;
-
synthetic duration: 96 секунд;
-
cardinality anomalies: 3;
-
memory anomalies: 1;
-
zero/unknown row estimate gaps: 3;
-
zero/unknown memory estimate gaps: 1;
-
need type: table and column stats;
-
required confirmation: сравнить EXPLAIN до/после stats maintenance и выполнить comparable rerun.
Здесь важно не перепрыгнуть через проверку. “Stats are missing” и “stats caused the slowdown” — разные утверждения.
Первое можно поддержать metadata-фактами. Второе требует проверки плана и сопоставимого rerun.
COMPUTE STATS иногда действительно помогает, но это не универсальная таблетка. Сначала нужно понять, почему мы решили, что statistics maintenance имеет отношение к проблеме.
Кейс 3: validator guardrail (demo-validator-0003)
Третий synthetic case показывает отказ от небезопасного результата.
Детерминированные факты:
-
query optimization candidate: medium;
-
impact: high;
-
confidence: medium;
-
synthetic duration: 188 секунд;
-
metadata status: not_requested;
-
table stats status: not_checked;
-
referenced tables: 3;
-
collected metadata tables: 0;
-
backend data skew: true;
-
cardinality anomalies: 2;
-
memory anomalies: 2;
-
zero/unknown row estimate gaps: 1;
-
zero/unknown memory estimate gaps: 1;
-
host-tail candidates: 1;
-
counter-signal: draft validation rejected unsafe shape change.
Это нормальное поведение инструмента. Query Doctor может сказать, что запрос стоит посмотреть внимательнее. Но это не значит, что существует безопасный SQL draft.
Если draft меняет shape запроса или не проходит детерминированную валидацию, он не должен становиться trusted output. В текущем synthetic case rejected draft остается скрытым как untrusted partial output. Это менее эффектно, чем показать красивый SQL, зато не подменяет review небезопасной подсказкой.
Что Query Doctor НЕ делает
Ограничения здесь не менее важны, чем возможности.
Query Doctor:
-
не выполняет user SQL;
-
не выполняет optimizer draft SQL;
-
не является root-cause оракулом;
-
не является Cloudera-заточеным продуктом;
-
не обещает поддержку всех query engines;
-
не превращает raw profile в безопасный публичный артефакт;
-
не делает LLM output доверенным без deterministic validation.
Текущий реализованный engine — Apache Impala. Будущие engine seams есть только как roadmap, не как поддержанная функциональность.
Зачем это нужно
В реальной эксплуатации диагностика запросов часто находится между двумя крайностями.
С одной стороны — ручной разбор профиля. Он точный, но медленный и зависит от опыта конкретного инженера.
С другой — быстрый ответ от LLM по сырому SQL/profile. Это удобно, но часто неэффективно и плохо контролирует безопасность данных, факты и confidence.
Query Doctor пытается занять середину:
-
собрать bounded context локально;
-
выделить deterministic facts;
-
показать candidates, evidence и limitations;
-
сгенерировать отчет только после validation;
-
оставить оператору понятные follow-up checks.
Это не отменяет ручную диагностику. Скорее сокращает путь до места, где человеку нужно посмотреть внимательнее.
Где нужен feedback
Если вы работаете с Impala профилями, мне особенно интересно:
-
какие profile facts вы чаще всего используете при инцидентах;
-
какие counters или секции профиля чаще всего неправильно интерпретируют;
-
какие synthetic cases стоит добавить;
-
какие поля профиля слишком зависят от версии/configuration, чтобы строить на них уверенный downstream tooling;
-
какие диагностические выводы должны оставаться «candidate», а не «root cause».
Если хотите показать реальный кейс, сначала санитизируйте SQL, profile, metadata, hosts, users и paths или опишите ситуацию словами без операционных артефактов.
ссылка на оригинал статьи https://habr.com/ru/articles/1041012/