Визуализация метрик запроса

YDB — распределённая СУБД для больших объёмов данных. Кластер может включать много узлов; структура запроса тогда состоит из сотен и тысяч задач, каждая со своими метриками. Показать все значения по отдельности и по ним же делать выводы нереалистично, поэтому метрики задач агрегируются по стадии, попадают в ответ сервиса и на диаграмму уже в агрегированном виде. На SVG-плане они показаны в колонках Tasks, Statistics и Timeline — см. Расположение информации в плане запроса. Ниже — как устроены агрегирование и визуализация и как по ним быстро оценить план и узкие места.

Общий вид визуализации

Графический план объединяет структуру запроса слева и агрегированные метрики справа:

Колонки диаграммы описаны в Расположении информации в плане запроса.

Параллельность

Число параллельно выполняющихся задач показано в колонке Tasks. Для стадий чтения из хранилища оно совпадает с числом шардов. Слева в той же колонке полосатый фон («зебра») отражает долю уже завершившихся задач. На финальном графике завершённого запроса полоса занимает всю высоту строки стадии; для снимка «в процессе» картина иная. Точные числа — во всплывающей подсказке при наведении на область.

Агрегаты

Для метрик в статистике вычисляются и передаются в ответ те же агрегаты, что и в SQL:

• MIN — минимум;
• MAX — максимум;
• COUNT — число значений;
• SUM — сумма;
• AVG — среднее (из COUNT и SUM).

Если COUNT меньше числа задач стадии (часть задач не отдала метрику), это помечается как аномалия: рядом с метрикой появляется красный круг с числом COUNT. Подробности — во всплывающей подсказке.

Если COUNT совпадает с числом задач (типичный случай), отдельный индикатор не рисуется. По умолчанию показывается SUM; при наведении — развёрнуто: SUM, MIN | AVG | MAX. Если метрику сообщила одна задача, MIN, AVG и MAX скрыты, остаётся SUM (она совпадает с единственным значением).

Дополнительные правила отображения:

• для целочисленных счётчиков (число строк) используются суффиксы K, M — множители 10³, 10⁶ и т.д.;
• для объёма (данные, память) — KB, MB и т.д. по степеням двойки: 2¹⁰, 2²⁰ …;
• длительности — в удобочитаемом виде часы / минуты / секунды.

Масштаб метрик

В колонке Statistics для каждой стадии сверху вниз выводятся метрики:

• Egress (тёмно-синий) — вывод данных через границу подсистемы (из хранилища в вычисление и обратно);
• Output (синий) — передача в следующую вычислительную стадию или в результат;
• Memory (тёмно-песочно-красный) — память;
• CPU (песочно-красный) — процессорное время;
• Input (зелёный) — ввод из другой вычислительной стадии;
• Ingress (тёмно-зелёный) — ввод через границу подсистемы.

Не у каждой стадии есть все шесть строк. У вычислительных стадий обязательны Memory и CPU. Из пары Egress / Ingress указывается одна соответствующая. Несколько входов Input перечисляются отдельно. Если выходов Output несколько, на основной строке стадии показывается один из них, остальные — у связанных «клонов», см. Множественные выходы.

Помимо числа, каждая метрика сопровождается цветной полосой. Для одного и того же типа метрики значения по стадиям нормируются между собой: у стадии с максимальным SUM полоса на всю ширину колонки Statistics, у остальных — пропорционально этому максимуму. Так проще сравнить, на какой стадии больше всего трафика, CPU, памяти и т.п.

Перекос данных

При параллельной обработке важно, чтобы задачи одной стадии стартовали и завершались почти синхронно. Длительность стадии задаётся самой медленной задачей: пока она не закончилась, стадия не считается завершённой.

Помимо SUM (она задаёт длину цветной полосы), по остальным агрегатам строится ломаная линия; участок полосы выше линии рисуется более светлым:

• MAX задаёт общий масштаб; ломаная начинается в левом верхнем углу полосы;
• MIN задаёт высоту ломаной на правом краю: отношение к MAX такое же, как MIN/MAX (например, при MIN вдвое меньше MAX конец ломаной — середина правой границы);
• AVG задаёт промежуточную точку между MIN и MAX по горизонтали и вертикали.

Hmax = H
Hmin = MIN * H / MAX
Havg = AVG * H / MAX
Wavg = (AVG – MIN) * W / (MAX – MIN)

Четыре типичных случая:

1. MIN == AVG == MAX: ломаная совпадает с верхним краем полосы, светлой зоны нет. Нагрузка по задачам равномерна (данные, время или память — в зависимости от метрики).

MAX = 100
AVG = 100
MIN = 100

2. MIN < MAX, но разброс небольшой: светлая область — узкий сегмент у правого верхнего угла. Роль AVG для визуальной оценки вторична.

MAX = 100
AVG = 90
MIN = 80

3. MIN существенно меньше MAX: важно положение AVG. Если оно близко к MAX, большинство задач загружены примерно одинаково, «лёгкие» задачи мало влияют на время стадии — перекос обычно некритичен.

MAX = 100
AVG = 90
MIN = 20

4. MIN сильно меньше MAX, а AVG близко к MIN: мало сильно перегруженных задач при большом числе простаивающих. Снижение перекоса (перераспределение работы) может заметно укоротить стадию.

MAX = 100
AVG = 30
MIN = 20

Практическое правило: чем больше площадь светлой части полосы, тем сильнее неравномерность и тем внимательнее стоит смотреть на эту метрику. Сильный перекос данных дополнительно помечается красным кругом с буквой S (data skew).

Перекос времени

Неравномерность бывает и по времени: одинаковый объём данных и схожее CPU/память, но разная длительность задач (узел перегружен, вытеснение планировщиком и т.д.). Такой сценарий на метриках из предыдущего раздела не всегда виден.

Оценка по времени — по правой колонке с временной шкалой: когда стадия стартовала и завершилась, как шли задачи. Чистый перекос по времени без перекоса по данным редок; чаще проявляются оба эффекта, поэтому логично начинать с данных.

Временная шкала читается проще, чем геометрия перекоса по данным. Для каждого канала задачи отдают FirstMessage (F) и LastMessage (L) — моменты обработки первого и последнего сообщения. Fmin — начало активности всех задач стадии, Lmax — конец. Дополнительно рисуются две жёлтые «зебры»: от Fmin до Fmax вдоль верхнего края прямоугольника и от Lmin до Lmax вдоль нижнего. В точках Favg и Lavg — вертикальные штрихи до середины по высоте.

Особый случай: обе «зебры» на всю ширину, вертикальные штрихи совпадают (не обязательно ровно по центру). Это соответствует ситуации, когда у каждой задачи FirstMessage == LastMessage — одно сообщение на передачу всего объёма между задачами (мало данных на канал).

Потребление CPU

Рассмотрим CPU на примере стадии 0 из раздела Структура фактического плана запроса. Здесь «потребление» — использование процессорного времени на полезную работу. Простой стадии не даёт вклада в CPU; при работе вклады задач суммируются обычным агрегированием.

«Загруженность» стадии и всей структуры выполнения запроса зависит от многих факторов, в том числе от других запросов на кластере. Для интерпретации CPU используется несколько представлений.

Помимо строк в Statistics, в правой колонке — график CPU по времени: интервалы с большей и меньшей утилизацией (песочно-красный) и ожидание данных (зелёный). При back pressure возможны и синие области; в этом разделе акцент на самом потреблении.

В примере суммарное процессорное время задач стадии 0 — 1,79 с, стадии 1 — 0,81 с, при более короткой календарной длительности. Чтобы сравнивать стадии, считается пропускная способность (throughput): число входных строк в секунду (сумма входов, если их несколько). От неё зависит насыщенность фона в Tasks. На диаграмме видно расхождение: у стадии 1 порядка 329 млн строк/с, у стадии 0 — около 90 млн (точные значения — во всплывающей подсказке по ячейке в Tasks).

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

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

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

Потребление памяти

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

Как использовать итоги диагностики:

• Сравните полосы Statistics и Timeline — найдите стадии с наибольшим CPU, памятью или трафиком.
• Проверьте Tasks и перекос данных: неравномерная нагрузка удлиняет стадию.
• Сопоставьте метрики со стадиями и каналами связи в структуре плана — узкое место часто совпадает с тяжёлой стадией или каналом.
• Сравните оценки EXPLAIN с фактическими метриками ANALYZE.