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

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

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

Разбирать profile руками.

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

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