PERCENTILE_CONT в SQL: как считать p50, p95 и latency

Коротко

PERCENTILE_CONT интерполирует значение между наблюдениями для заданного процентиля. p50 показывает медиану, p95 — значение, ниже которого находится 95% наблюдений.

Материал относится к полке «SQL и аналитика» и построен вокруг рабочего решения: сначала определить объект и границы расчёта, затем проверить пример и только после этого выбирать инструмент или метрику.

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

Какой вопрос решает материал

Почему среднее время ответа хорошее, а часть пользователей всё равно ждёт слишком долго?

Latency и время доставки часто имеют длинный хвост. Среднее сглаживает проблему, а максимум зависит от одной аномальной строки. Квантили дают устойчивый способ говорить о типичном и тяжёлом сценарии.

Если p50 checkout равен 1,2 секунды, а p95 — 6,8, большинство пользователей видит быстрый ответ, но хвост нуждается в отдельной диагностике по устройству, региону и endpoint.

Определение и зерно расчёта

Для latency одна строка должна быть один завершённый запрос или один пользовательский опыт. Повторные retries нельзя смешивать с успешным результатом без отдельного флага.

Сначала выбери единицу наблюдения и исключи технические дубли. Затем посчитай несколько процентилей на одной базе, рядом укажи n и сравни распределение по сегментам.

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

Рабочий пример

Если p50 checkout равен 1,2 секунды, а p95 — 6,8, большинство пользователей видит быстрый ответ, но хвост нуждается в отдельной диагностике по устройству, региону и endpoint.

Не копируй пример в рабочий отчёт вслепую. Сначала замени названия таблиц и полей, проверь кардинальность связей и запиши, какие строки должны попасть в результат. Хорошая адаптация сохраняет логику, но делает допущения видимыми.

SELECT COUNT(*) AS requests, PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY latency_ms) AS p50, PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY latency_ms) AS p95, AVG(latency_ms) AS mean_latency\nFROM request_log\nWHERE endpoint = '/checkout';

Как читать результат

Для SLA показывай p95 или p99 вместе с размером выборки и долей нарушений. Для продуктового опыта не забывай про перцентили, но связывай их с конкретным сценарием пользователя.

Результат полезен только в контексте baseline, размера объекта и действия после сигнала. Одна цифра без периода и сравнения выглядит убедительно, но не отвечает на вопрос, стало ли решение лучше.

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

Где расчёт ломается

Нельзя считать p95 при маленьком n точной цифрой, склеивать разные endpoint и скрывать отсутствие запросов. Для тяжёлого хвоста проверь также p99 и долю выше SLA.

Отдельно протестируй пустой результат, NULL, дубль, граничную дату и объект без связанной записи. Эти случаи не являются редкими исключениями: именно они чаще всего превращают рабочий показатель в красивую, но неверную цифру.

• Не смешивай зрелые и незрелые периоды без отдельной подписи.
• Не заменяй проверку качества тем, что запрос просто выполнился.
• Не делай причинный вывод из одного разреза.

Визуальная проверка

График здесь нужен не для украшения статьи. Он помогает увидеть форму сигнала: тренд, разрыв между сегментами, хвост распределения или этап, на котором теряется объект. Сначала прочитай оси и единицы, затем сравни с таблицей и только после этого формулируй вывод.

На визуализации «Центр и хвост latency» сравнивай не только максимальное значение. Проверь, одинаковы ли базы, не скрыта ли неполная дата и не меняется ли знаменатель от категории к категории.

Мини-практика

Возьми сто значений latency с одним длинным хвостом. Сравни mean, p50, p90 и p95, а затем напиши, какое действие следует из каждого показателя.

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

• Собери контрольный пример из пяти-десяти строк.
• Сверь итог с независимым способом расчёта.
• Проверь хотя бы один крайний случай.
• Зафиксируй дату, версию схемы и ограничение.

Контрольные сценарии

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

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

После изменения схемы или определения запусти прежний контрольный пример снова. Сравни не только финальное число, но и промежуточный grain, количество уникальных ключей и долю исключённых строк. Если число изменилось, должно быть понятно, какая именно договорённость это объясняет.

Когда выбрать другой подход

Не каждый вопрос стоит решать тем же инструментом. Если нужен быстрый обзор, достаточно таблицы и одной декомпозиции. Если важна воспроизводимость, вынеси логику в SQL или Python. Если нужен причинный вывод, добавь эксперимент или квазиэксперимент, а не усложняй описательный график.

Команда может выбрать другой метод, когда меняются стоимость ошибки, скорость обновления, доступность данных или требование к аудиту. Это не отменяет текущий расчёт, а помогает не выдавать удобный инструмент за универсальный.

Как передать результат

Рабочее сообщение должно начинаться с ответа, а не с истории всех попыток. Напиши, что изменилось, на какой базе это видно, какой размер эффекта и какое ограничение нужно учитывать. Затем добавь ссылку на запрос, notebook или карточку метрики, чтобы коллега мог проверить расчёт без устного экскурса.

Если результат требует действия, назови owner и момент пересмотра. «Проверить mobile checkout до пятницы» полезнее, чем «обратить внимание на конверсию». Если данных пока недостаточно, сформулируй следующий сбор: какое событие, какой период или какой эксперимент закроет неопределённость.

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

Как довести расчёт до рабочего процесса

Начни с маленького контрольного запроса или notebook, где видны исходные фильтры, зерно и промежуточные строки. Сверь его с ручным примером и только затем переноси логику в дашборд, витрину или регулярную задачу. Так ошибка находится до того, как на её основе появится решение.

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

После запуска смотри не только на итоговое значение. Контролируй количество строк, долю NULL, долю исключений и размер ключевых сегментов. Если эти показатели резко меняются, сначала проверяй загрузку и схему, а не объясняй скачок поведением пользователей.

• Один контрольный пример с известным ответом.
• Владелец определения и владелец данных.
• Порог свежести и допустимый диапазон.
• Лог изменений, SQL или notebook в одном месте.

Чеклист перед публикацией

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

• Понятно ли, что является строкой результата?
• Названы ли период, timezone, фильтры и знаменатель?
• Есть ли проверка на дубли, NULL и пустые группы?
• Сравнивается ли результат с baseline или сегментом?
• Понятно ли, какое решение поддерживает показатель?
• Есть ли следующий шаг, если сигнал подтвердится?

Вывод

Для SLA показывай p95 или p99 вместе с размером выборки и долей нарушений. Для продуктового опыта не забывай про перцентили, но связывай их с конкретным сценарием пользователя.

Сильный аналитический материал не обещает абсолютной уверенности. Он показывает, как получить число, где оно может ошибиться и какое решение можно принять уже сейчас. Такой формат хорошо переносится в дашборд, SQL-тренажёр, собеседование и рабочее обсуждение с командой.