Как в SQL настроить фокус окна?

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

Когда я осваивал оконные функции, для меня самым сложным было разобраться не с OVER, партициями или самими функциями, а именно с настройками окна.

Инструкция ROWS позволяет ограничить строки в окне, указывая фиксированное количество строк, предшествующих или следующих за текущей.

RANGE, в отличие от ROWS, работает не с физическими строками, а с диапазоном значений ORDER BY. Поэтому несколько строк с одинаковым значением могут попадать в одно окно.

Обе инструкции ROWS и RANGE всегда используются вместе с ORDER BY.

Возьмем наш пример и посчитаем сумму по текущей и следующей строке внутри каждого дня:

SELECT 
  date
, medium
, conversions
, SUM(conversions) OVER(PARTITION BY date ORDER BY medium ROWS BETWEEN CURRENT ROW AND 1 FOLLOWING) AS sum 
FROM orders

Результат выполнения и логику запроса смотрите на картинке.

В выражении для ограничения окна также можно использовать следующие ключевые слова:

▪️UNBOUNDED PRECEDING - указывает, что окно начинается с первой строки группы;
▪️UNBOUNDED FOLLOWING - с помощью данной инструкции можно указать, что окно заканчивается на последней строке группы;
▪️CURRENT ROW - инструкция указывает, что окно начинается или заканчивается на текущей строке;
▪️BETWEEN «граница окна» AND «граница окна» - указывает нижнюю и верхнюю границу;
▪️«Значение» PRECEDING - определяет число строк перед текущей строкой (не допускается в RANGE);
▪️«Значение» FOLLOWING - определяет число строк после текущей строки (не допускается в RANGE).

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

Далее разберем самые полезные оконные функции.

#харды #sql

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

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

Здесь хочется вспомнить незатейливый слоган:

Нормально делай – нормально будет.

Метрики качества – это фундамент доверия и долгосрочного успеха. Без них можно сколько угодно создавать ценность и работать над лояльностью, но один сбой, медленная загрузка или волна ошибок сведут все усилия на нет. Именно качество напрямую влияет на удержание, репутацию и в конечном счете на экономику продукта.

Как это измерить? Я выделяю четыре группы метрик, которые стоит мониторить любой продуктовой и инженерной команде.

1. Метрики надежности

Здесь все просто. Пользователь должен иметь доступ к продукту. Ключевые показатели:
▪️Uptime;
▪️SLA;
▪️Коэффициент ошибок.
Это базовый уровень доверия.

2. Метрики функциональности и стабильности

Продукт не только должен работать, но и работать правильно.
▪️Доля ошибок;
▪️Процент негативных обращений в поддержку;
▪️Доля пользователей, столкнувшихся с проблемами.
Эти цифры показывают, насколько стабилен ваш функционал в реальных условиях, а не в тестовой среде.

3. Метрики производительности

Даже если все работает без ошибок, но медленно – ценность падает.
▪️Время загрузки страниц или экранов;
▪️Время отклика на действия.
Просадки здесь сразу бьют по вовлечению и конверсиям.

4. Метрики контроля качества

Это уже про внутренние процессы:
▪️Бюджет ошибок (сколько проблем мы готовы принять);
▪️Процент успешных тестов;
▪️Количество непредвиденных инцидентов после релиза.
Эти метрики помогают оценить, насколько эффективно мы предупреждаем сбои и управляем рисками.

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

Последний слой пирамиды метрик – самый близкий к пользователю: интерфейс продукта и маркетинг. Но его мы разберем в следующий раз.

#харды #метрики #разбор_метрик

Решил попробовать написать серию постов про машинное обучение.

Но так как люблю копать глубоко, начать захотелось с истории - понять, откуда вообще все это выросло и почему мы оказались именно в текущей точке. Так сказать, пройтись по основным вехам.

В какой-то момент стало понятно, что это уже не пост для Telegram. Текст разросся, плюс захотелось добавить фоток и немного контекста.

➡️ Поэтому вынес его в блог.

Приятного чтения и поделитесь фидбеком!

#харды #ml

В АБ-тестах самая частая ошибка не расчет p-value, а неправильный выбор статистического теста.

▪️Одна выборка или две?
▪️Если две - зависимые или независимые?
▪️Сравниваем средние или пропорции?
▪️Есть ли выбросы?
▪️Насколько однородны группы?

От этого зависит правильность ваших выводов.

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

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

И только после этого принимать решение.

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

Если хотите системно разобраться в АБ-тестах, могу порекомендовать курс Паши. Я его знаю лично и доверяю его подходу.

У него как раз упор на практику и полный цикл эксперимента. Сам планирую пойти, потому что в менеджерской роли стал подзабывать АБ.

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

#харды #аб

Почему оконные функции могут тормозить запрос?

Я написал уже целую серию постов про оконки (раз, два, три) и там все выглядело красиво - добавил OVER() и получил профит. Но в комментах справедливо подметили, что оконные функции - это часто один из самых тяжелых видов запросов, который сильно жрет ресурсы.

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

1⃣ Убери ORDER BY из окна, если порядок не влияет на смысл

Частая ошибка - писать ORDER BY внутри OVER() «на всякий случай». Как только он появляется, базе нужно обеспечить порядок строк, а это почти всегда дорого.

Если тебе нужен просто итог по группе (например, общий доход за день для каждой строки), а не накопительная сумма или скользящее окно - ORDER BY внутри окна не нужен.

-- Накопительная сумма (дороже)
SUM(revenue) OVER (PARTITION BY date ORDER BY created_at)

-- Просто итог по дню (дешевле)
SUM(revenue) OVER (PARTITION BY date)

2⃣ Чем меньше строк, тем быстрее

Оконки «проходят» по всем строкам, часто упорядочивают их, а иногда еще и держат большие куски данных в памяти. Поэтому самый простой ускоритель - сократить объем данных ДО оконки:

✔ Отфильтруй период (например, последние 30/90 дней);
✔ Не тащи лишние колонки («SELECT *» - плохо);
✔ Если можно, то сначала агрегируй данные до нужной гранулярности, а окно считай уже на агрегате.

3⃣ Несколько разных окон = несколько сортировок

Если в одном запросе несколько окон с разным ORDER BY, база может быть вынуждена упорядочивать данные несколько раз. И как итог: больше времени и памяти.

SUM(x) OVER (PARTITION BY a ORDER BY b) AS s1,
AVG(x) OVER (PARTITION BY a ORDER BY c) AS s2

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

4⃣ Используй план выполнения запроса

EXPLAIN - это команда, которая показывает план выполнения запроса: какие шаги база собирается сделать и где она потратит ресурсы. А EXPLAIN ANALYZE еще и выполняет запрос добавляя фактические цифры: сколько строк прошло через каждый шаг и сколько времени заняло.

Далее я разберу, как именно читать EXPLAIN и использовать эту команду для оптимизации.

#харды #sql

Как учатся модели машинного обучения?

Ранее я написал небольшую статью про историю ML, а сегодня хочу развить тему дальше.

Речь пойдет о моделях, которые учатся, минимизируя функцию потерь градиентными методами. У других алгоритмов (например, деревья) свои механизмы, но они тоже оптимизируют критерий качества. Есть и алгоритмы, которые вообще не проходят этап обучения - например, kNN просто хранит обучающие данные и делает предсказания на основе ближайших соседей.

Когда модель обучается с «учителем», у нее есть простая джоба: на вход размеченные данные, на выход - предсказание. Но дальше возникает ключевой вопрос: как понять, насколько предсказание хорошее, и как сделать так, чтобы в следующий раз было лучше?

Для этого нужна функция потерь (loss). Формально функция потерь сравнивает две вещи:
▪️ правильный ответ (y);
▪️ предсказание модели ŷ.

И превращает разницу между ними в число ошибки. Именно это число становится целью обучения - модель старается его уменьшить.

Как выглядит обучение по шагам?

Обычно перед обучением проводят подготовку и делят данные на три части:
▪️тренировочная выборка - это те данные, на которых будет учиться модель;
▪️валидационная выборка - чтобы проверять, не начинает ли модель «зазубривать» тренировочные данные и как лучше настроить параметры;
▪️тестовая выборка - финальная честная проверка, когда обучение уже закончено.

1⃣ Модель делает предсказание
Мы подаем признаки (X) в модель, она считает ответ и выдает свой прогноз.

2⃣ Считаем ошибку (loss)
Теперь сравниваем получившееся предсказание модели с правильным ответом, то есть y и ŷ. Получаем ошибку модели и если модель сильно ошибается - loss будет большим. Если предсказывает хорошо, то маленьким.

3⃣ Считаем градиент
Дальше нужно понять, как изменить параметры модели, чтобы ошибка уменьшилась. Для этого считается градиент функции потерь - он показывает направление, в котором нужно менять параметры.

4⃣ Обновляем параметры модели
Сам градиент параметры не меняет. Его использует оптимизатор - специальный алгоритм обновления весов. Оптимизатор делает маленький шаг в сторону уменьшения ошибки.
И после обновления параметров цикл начинается заново.

В итоге получается такой алгоритм:
Сделали предсказание > Посчитали ошибку > Вычислили градиент > Обновили параметры > Повторили тысячи раз.

Какие бывают функции потерь?

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

Для интуитивного понимания достаточно двух примеров:
▪️MSE (mean squared error) - ошибка возводится в квадрат. Это значит, что большие ошибки «наказываются» особенно сильно, поэтому модель старается избегать крупных промахов.
▪️MAE (mean absolute error) - берется просто абсолютная разница. Такая функция потерь относится к ошибкам более спокойно и обычно лучше переносит редкие выбросы.

Понимание этого цикла - одна из базовых идей ML. Многие современные модели, от простой линейной регрессии до нейросетей, в той или иной форме обучаются именно так.

#харды #ml

Как аналитику оптимизировать свои запросы?

Ранее я рассказывал, почему оконные функции могут тормозить, и дал 4 совета по оптимизации. Но если ты действительно хочешь ускорить свои запросы, то начинать нужно с анализа плана выполнения.

Знакомьтесь - EXPLAIN

Команда простая и очевидная, но почему-то ею мало кто пользуется. Может, потому что хочется быстрее решить задачу, а не копаться в том, как база данных обрабатывает запросы. Но когда ты пишешь боевой запрос, от которого зависит работа важной системы, или когда на кластере жесткие лимиты по ресурсам - умение читать EXPLAIN твое все!

Как SQL работает под капотом?

Прежде чем говорить о плане, важно понимать этапы, которые проходит SQL-запрос внутри базы данных (на примере PostgreSQL):

1⃣ Parser - разбирает текст SQL, проверяет синтаксис и строит абстрактное синтаксическое дерево.

2⃣ Analyzer - проверяет существуют ли таблицы, колонки, функции, есть ли права доступа. Если ты опечатался в названии колонки, то ошибка упадет именно здесь.

3⃣ Rewriter - делает логическое преобразование запроса.

4⃣ Planner / Optimizer - самый важный этап для нас. Он перебирает возможные планы выполнения и выбирает тот, у которого наименьшая стоимость.

5⃣ Executor - выполняет план и возвращает результат.

EXPLAIN показывает результат работы planner и это тот самый план, который база данных посчитает оптимальным на основе статистики.

Как читать EXPLAIN?

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

Команда EXPLAIN показывает, как именно база данных собирается выполнять запрос: какие индексы использовать, как соединять таблицы, будет ли сортировка.

А EXPLAIN ANALYZE еще и выполняет запрос, добавляя фактические цифры: сколько строк прошло через каждый шаг, сколько времени заняло, сколько памяти использовано.

Основные операторы в плане:

◾ Seq Scan - последовательное чтение всей таблицы (для маленьких таблиц - это окей).
✔ Оптимизация: добавить индекс на поля, которые используются в WHERE, JOIN, ORDER BY.

◾ Index Scan - чтение по индексу.
✔ Оптимизация: следи, чтобы индекс реально использовался: без функций, кастов и с правильным порядком колонок.

◾ Sort - дорогая операция, особенно на больших объемах и без индексов.
✔ Оптимизация: если сортировка нужна, то убедись, что есть индекс на поля сортировки. Если не нужна - убери.

◾ Hash Join / Merge Join / Nested Loop - это способы соединить таблицы. Hash Join и Merge Join обычно быстрее на больших данных, Nested Loop - на маленьких.
✔ Оптимизация: главный прием - уменьшить данные до JOIN, а не после.

◾ Cost=1..123 - оценка оптимизатора, где первое число - стоимость получить первую строку, второе - все строки. Чем меньше - тем лучше.
✔ Оптимизация: это лишь оценка оптимизатора, ориентируйся на реальные метрики из EXPLAIN ANALYZE.

Я не буду переписывать сюда всю документацию. Вот ссылки на официальные руководства, где все подробно расписано:
- PostgreSQL
- MySQL
- SQL Server
- Greenplum
- ClickHouse

Твое задание на сегодня

Возьми любой запрос, который работал долго, и выполни перед ним EXPLAIN, найди самый дорогой узел по стоимости и попробуй его оптимизировать.

Интересными кейсами делись в комментариях!

#харды #sql

Эффективные встречи один на один - существуют ли они?

Я терпеть не могу встречи ради встреч. Обычно это просто сжигание времени. Но есть один формат, в который я по-настоящему верю 🙏

Встречи один на один - не просто регулярный разговор сотрудника с начальником, а один из главных инструментов управления. К сожалению, многие относятся к ним как к простой формальности и проводят их «для галочки».

Для меня 1-1 - это способ синхронизироваться, вовремя заметить проблемы, поддержать и задать направление движения. Именно поэтому к таким встречам нужно готовиться. Не обязательно писать большой план, но важно хотя бы заранее понимать, что хочешь обсудить.

Формат может быть таким:

1. Начинаем с короткого неформального разговора.

2. Даем слово сотруднику: какие есть вопросы, сложности, идеи, что беспокоит, где нужна помощь (и действительно стараемся помочь).

3. Переходим к своей части: рассказываем новости, делимся мыслями, советуем, если это уместно, обсуждаем планы и изменения.

4. Самый важный блок - фокус недели. Фиксируем 1-2 главных приоритета на ближайшие дни. На следующей встрече разбираем: что вышло, что нет и почему.

⚠️ Сами фокусы не должны браться из воздуха. Они должны рождаться из стратегии развития. Если у руководителя нет понимания, куда движется функция, то 1-1 быстро скатывается в обсуждение только текучки. А когда есть стратегия, такие встречи становятся способом регулярно переводить ее в конкретные шаги для команды.

Кстати, я уже готовлю статью про свой опыт создания и внедрения стратегии аналитики в компании.

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

Как часто проводить 1-1?

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

Такой подход делает встречи не формальностью, а рабочим инструментом. Помогает держать курс, поддерживать людей и не тонуть в текучке.

А вы верите в эффективный 1-1?

👍 - да
🔥 - нет, сжигание времени

#опыт

Друзья, это финальный пост про пирамиду метрик.

Я довольно много писал про метрики и разные фреймворки, и к пирамиде мы возвращались не раз. Но с последним слоем я немного подзатянул - исправляюсь 🙂

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

Этот слой отвечает на базовые вопросы:
- как пользователи приходят в продукт?
- что они в нем делают?
- доходят ли до целевого действия?

Как и в предыдущих слоях, здесь есть своя логика группировки. Я выделяю четыре блока:

1. Маркетинг
Это про вход в продукт: кого мы приводим и за какие деньги.

2. Интерфейс
Это уже про UX и то, насколько продукт понятен.

3. Вовлеченность
Здесь видно, «цепляет» продукт или нет.

4. Аудитория
Это наша текущая и потенциальная база.

Этот слой - точка, где формируется все поведение пользователя: как он зашел, что сделал, получил ли пользу. А дальше поднимается выше по пирамиде - в ценность, лояльность и деньги.

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

Главное не фреймворк, а используете ли вы его на практике. Будь то пирамида, дерево метрик или что-то свое - важно, чтобы метрики были системой, а не набором цифр.

#харды #метрики #разбор_метрик