💻 SQL в действии: запросы, которые должен знать каждый аналитик

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

1️⃣ Анализ продаж с использованием агрегатных функций

Допустим, у нас есть таблица sales с колонками: sale_id, product_id, region, sale_date, amount. Мы хотим узнать общую сумму продаж и средний чек по регионам:

SELECT 
    region, 
    SUM(amount) AS total_sales, 
    AVG(amount) AS avg_check
FROM sales
GROUP BY region
ORDER BY total_sales DESC;

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

2️⃣ Использование подзапросов для поиска аномалий

Предположим, мы хотим найти товары, продажи которых ниже среднего уровня по всем товарам:

SELECT product_id, SUM(amount) AS total_sales
FROM sales
GROUP BY product_id
HAVING SUM(amount) < (
    SELECT AVG(total_sales)
    FROM (
        SELECT SUM(amount) AS total_sales
        FROM sales
        GROUP BY product_id
    ) AS subquery
);

Здесь мы используем подзапрос для вычисления среднего уровня продаж по всем товарам и фильтруем те товары, которые находятся ниже этого уровня.

3️⃣ Оконные функции для анализа трендов

Оконные функции позволяют анализировать данные без группировки. Например, найдем кумулятивную выручку (накопительный итог) по датам:

SELECT 
    sale_date,
    SUM(amount) OVER (ORDER BY sale_date) AS cumulative_sales
FROM sales;

Такой запрос поможет увидеть динамику роста выручки за определенный период.

4️⃣ Сравнение текущих и предыдущих периодов

Чтобы сравнить продажи текущего месяца с предыдущим, можно использовать оконные функции:

SELECT 
    region,
    DATE_TRUNC('month', sale_date) AS month,
    SUM(amount) AS monthly_sales,
    LAG(SUM(amount)) OVER (PARTITION BY region ORDER BY DATE_TRUNC('month', sale_date)) AS prev_month_sales,
    SUM(amount) - LAG(SUM(amount)) OVER (PARTITION BY region ORDER BY DATE_TRUNC('month', sale_date)) AS sales_diff
FROM sales
GROUP BY region, DATE_TRUNC('month', sale_date)
ORDER BY region, month;

Этот запрос покажет динамику продаж по регионам с учетом разницы между месяцами.

5️⃣ Объединение таблиц для анализа

Допустим, у нас есть две таблицы: products (с информацией о товарах) и sales (с информацией о продажах). Чтобы получить список товаров с их категориями и общей суммой продаж, используем JOIN:

SELECT 
    p.product_name,
    p.category,
    SUM(s.amount) AS total_sales
FROM products p
LEFT JOIN sales s ON p.product_id = s.product_id
GROUP BY p.product_name, p.category
ORDER BY total_sales DESC;

Такой запрос помогает объединять данные из нескольких таблиц для более глубокого анализа.

Попробуйте эти запросы на своих данных и убедитесь в их эффективности!

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

💻💻💻💻💻 PostgreSQL vs ClickHouse: что выбрать аналитику в 2026 году 🤔

На вебинаре вместе с Павлом Беляевым разберёмся, чем отличаются строчное и колоночное хранение данных, почему PostgreSQL отлично подходит для одних задач, а ClickHouse — для других, и как эти базы работают в реальных проектах.

На вебинаре вы:
➡️ Поймёте на практике, чем отличаются PostgreSQL и ClickHouse и как способ хранения данных влияет на скорость запросов;
➡️ Разберётесь, где PostgreSQL силён, а где начинает проигрывать на аналитических задачах;
➡️ Узнаете, зачем нужен ClickHouse, какие задачи он решает и какие у него есть ограничения;
➡️ Посмотрите живую демонстрацию: один и тот же запрос — и две базы данных;

📆 12 сентября, 12:00 МСК
📹 Спикер — Павел Беляев, тимлид аналитики в Яндекс eLama

➡️ Зарегистрироваться

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

📌 Вызовы в работе аналитика данных

Привет! На связи Павел Беляев — автор канала Тимлидское об аналитике и ментор Симулейтив 👋🏻

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

1️⃣ Формулировка требований

Зачастую заказчики аналитики знают о своём предмете не сильно больше, чем вы. Во всяком случае, о том, что надо измерять, чтобы понять, например, эффективность затраченных усилий.

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

2️⃣ Качество данных

Причин недостоверности данных много: технические, организационные, человеческие... Конвейер длинный — на каждом шагу может что-то пойти не так.

Например, пользователь накосячил с вводом, отвалилось API третьестепенных данных, на которых, внезапно, завязаны расчеты, кто-то что-то закостылил, а аналитикам не сказали — всё это требует постоянного неустанного слежения за качеством данных, желательно автоматического.

Поэтому полезно завести привычку ничему не доверять и постоянно всё проверять.

3️⃣ Техническая реализуемость

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

Бывает, что заказчики прямо фонтанируют идеями — громкими, но сомнительными. Я не сторонник того, чтобы «обламывать» такие порывы. Но долг аналитика — выслушать, оценить, внести коррективы, которые позволят исполнить более удобное или недорогое решение.

4️⃣ Внезапные изменения в источниках

Работа аналитиков сильно завязана на источниках данных: база данных, сторонние сервисы и др. Если база данных находится в ведении других команд (у разработчиков приложения, например), то нужно иметь в виду, что у них свои цели и процессы. Вы им не нужны, это они вам нужны 🙂
Из-за этого они могут просто забыть сообщить вам, что, например, у них изменилась структура таблицы, которую вы привычно тянете, или что база вовсе переезжает, причем, послезавтра.

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

5️⃣ Как себя проверить?

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

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

6️⃣ Как это работает?!

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

Это не только к вопросу об обязательном документировании, но и к тому, что я писал в начале поста — потребители данных иногда слабо понимают, что за цифры они смотрят.

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

В общем, будни дата-аналитика — штука весёлая. И всё же, в эту сферу войти проще, чем в хардкорное программирование. Начать свой путь до оффера в аналитике можно после обучения на курсе «BI-аналитик», где я буду вашим ментором.

📈 Узнать больше о курсе

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

💻 Ошибки при использовании джоинов

Давайте обсудим некоторые ключевые аспекты работы с джоинами в SQL, на которые стоит обратить внимание, чтобы избежать ошибок и недоразумений.

🔑 Сохранение данных в приоритете

При написании запросов с джоинами, особенно с транзитивными связями, всегда задавайте себе вопрос:

❓ Какие данные мне важно не потерять?

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

1️⃣ Вы выбираете джоин, который кажется логичным;
2️⃣ Вы не замечаете потенциальных проблем.

Давайте рассмотрим этот момент на примере:

SELECT *
FROM problem p
JOIN page p2 
  ON p.page_id = p2.id
JOIN company c 
  ON p.company_id = c.id

На первый взгляд, этот запрос кажется корректным, и результаты выглядят нормально. Однако если внимательно проанализировать, вы увидите, что множество записей из таблицы problem просто исчезли 😱

❓ Почему так произошло?

Что, если в таблице problem есть строки, в которых company_id = NULL? Тогда такие строки будут исключены из результата, ведь в таблице company поле id — первичный ключ и не содержит NULL.

❗️ Чтобы избежать потери данных, всегда помните о выборе правильного типа джоина:

SELECT *
FROM problem p
JOIN page p2 
  ON p.page_id = p2.id
LEFT JOIN company c 
  ON p.company_id = c.id

Используя LEFT JOIN, вы сохраните все записи из problem и соответствующие им записи из company, где problem.company_id=NULL, будут иметь пустые значения.

Помните об этом важном аспекте при работе с джоинами, чтобы получать точные и полные результаты! И ставьте 🔥, если было полезно!

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

💻💻💻💻💻Что меняется в работе дата-инженера, когда данных становится в тысячу раз больше?

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

На вебинаре разберём три версии одной задачи:
1️⃣ Объединяем данные сайта и CRM в базовом пайплайне.
2️⃣ Увеличиваем объём до терабайта и добавляем Airflow и PySpark.
3️⃣ Переходим к обновлению в реальном времени и подключаем стриминг, Kafka и распределённое хранилище.
4️⃣ На этих примерах покажем, как меняется мышление специалиста по мере роста: от выполнения отдельных задач до проектирования архитектуры под требования бизнеса.

🎙Спикер — Андрей Вильмов, Data Engineer в IBS. Ранее — CTO «ПерилаГлавСнаб», CEO и сооснователь FlowAI.

📆 20 сентября, 18:00 мск.
❗️Необходима регистрация!

➡️ Зарегистрироваться на вебинар

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

💻💻💻💻💻Как устроена работа аналитика в среднем бизнесе?

Хотите понять, чего ждать, если устраиваетесь аналитиком в среднюю компанию — из чего состоит рабочий день, какие инструменты нужно знать и как вопрос бизнеса превращается в решение?

23 сентября вместе с Павлом Беляевым покажем аналитический контур Яндекс eLama глазами дата-аналитика: от сбора данных до принятия решений.

На вебинаре вы:
➡️ Поймёте, чем аналитику в среднем бизнесе предстоит заниматься каждый день;
➡️ Пройдёте весь конвейер данных: сбор, обработку и создание витрин, визуализацию, анализ и принятие решений;
➡️ Узнаете, как живёт витрина данных: от вопроса бизнеса и ТЗ до поддержки, обновления и вывода из эксплуатации;
➡️ Увидите технический стек команды и инструменты собственной разработки, в том числе с вайб-кодингом.

🧑🏻‍💻 Спикер: Павел Беляев, руководитель группы дата-аналитиков в Яндекс eLama, ментор курсов «BI-аналитик» и «Fullstack-аналитик».

📆 Когда: 23 сентября, 19:00 МСК
➡️ Зарегистрироваться на вебинар

Записи не будет. Приходите на живой эфир!

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS