Симулейтив

Друзья, спасибо всем, кто посетил наши вебинары!

Записи занятий уже лежат в боте ✅

Продолжаем держать низкие цены на продвинутый тренинг по SQL — напомним, что это такое:

😶 Углубляемся в SQL и повышаем грейд: разбираем оптимизацию SQL-запросов, анализ качества данных и трендов на основе исторических данных в SQL;

😶 6 домашних заданий и 1 кросс-проверка, где студенты проверяют код друг друга;

😶 Практический проект для отработки полученных навыков и разбор тестового задания на senior-позицию.

Автор курса — Владимир Лунев, Fullstack-аналитик в Магните с более чем 5-летним опытом в системном и бизнес-анализе, ведёт авторский Telegram-канал SQL: Реляционные базы данных.

Регистрируйтесь и прокачивайте свой скилл в SQL!

➡️ Записаться по ранней цене

📊 Simulative

Clickhouse: что это за СУБД и для чего нужна

NoSQL СУБД типа Clickhouse заточены под определённый тип задач. Clickhouse нужна прежде всего для решения OLAP-задач — например, рассчитать какую-либо метрику типа CTR поверх всех действий всех пользователей в приложении.

Разобрали в статье, чем отличается Clickhouse от Postgres, её архитектурные особенности и возможности, а также как начать работать с СУБД.

🟡 Читать статью в блоге

📊 Simulative

⚡️ Уже начали вебинар по SQL, подключайтесь!

📊 Simulative

Знакомая ситуация?

Запускаете запрос, ждёте… а Excel уже подвис, BI-система крутит loading, и коллеги начинают писать, что там с отчётом.

99% таких ситуаций — не вина сервера, а ошибки в самом SQL-запросе. И да, это можно исправить.

Уже сегодня на вебинаре спикер тренинга «Продвинутый SQL» Владимир Лунев расскажет:

🟠 Как понять, что запрос тормозит, и чем это грозит бизнесу;
🟠 Как читать план выполнения (EXPLAIN, EXPLAIN ANALYZE) и находить ошибки;
🟠 Типовые причины медленных запросов и как их исправлять;
🟠 7 реальных кейсов из практики: «было → стало» с разбором кода.

😶😶Регистрация

📊 Simulative

⚡️ Вебинар по анализу данных в Python уже идёт!

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

➡️ Регистрируйтесь и подключайтесь по ссылке: https://vk.cc/cPLa3m

📊 Simulative

Сегментация клиентов с помощью машинного обучения

Привет! С вами Кристина Желтова, ментор курса «ML-инженер».

В персонализации клиентского сервиса и маркетинге важно правильно сегментировать клиентов — разделять клиентскую базу на группы (сегменты) на основе их характеристик.

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

В качестве датасета возьмем небольшой набор данных Mall Customer Segmentation с Kaggle:

path = kagglehub.dataset_download("vjchoudhary7/customer-segmentation-tutorial-in-python")
df = pd.read_csv('/kaggle/input/customer-segmentation-tutorial-in-python/Mall_Customers.csv')

Один из самых простых и известных методов кластеризации — KMeans. Он разделяет данные на K кластеров, находя центроиды (центры) каждого кластера и группируя точки данных вокруг ближайших центроидов.

❗️ Важно: KMeans не предназначен для работы с категориальными признаками. Их нужно либо анализировать отдельно, либо применять другие алгоритмы кластеризации, поддерживающие смешанные датасеты.

clustering_features = ['Age', 'Annual Income (k$)', 'Spending Score (1-100)']
X = df[clustering_features].copy()

Перед применением алгоритма KMeans важно провести масштабирование признаков, иначе признаки с большими единицами измерения будут «перетягивать на себя» расстояния и смещать всё решение.

scaler = StandardScaler()

X_scaled = scaler.fit_transform(X)
X_scaled_df = pd.DataFrame(X_scaled, columns=clustering_features, index=X.index)

При использовании KMeans всегда есть некоторая неопределенность — этому алгоритму нужно заранее задать, на сколько кластеров/групп мы будем разделять данные. Иногда это предположение можно сделать экспертно, но можно попробовать и подобрать оптимальное количество групп, используя «метод локтя» — перебираем количество кластеров, визуализируя на графике сумму квадратов расстояний от каждой точки до центра её кластера. Точка перегиба, где график «сгибается» как локоть руки, и будет оптимальным количеством кластеров.

inertias = []

k_values = range(2, 11)

for k in k_values:
    # Обучаем K-means с конкретным k
    kmeans = KMeans(n_clusters=k, random_state=42, n_init=10)
    cluster_labels = kmeans.fit_predict(X)
    
    inertia = kmeans.inertia_
    inertias.append(inertia)

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

➡️ Более подробный пример можно посмотреть в colab notebook.

📊 Simulative

Экспресс-оптимизация SQL-запроса на реальном кейсе

Привет! На связи Владимир Лунев, ментор тренинга «Продвинутый SQL». Давайте разберём кейс, где простые приёмы оптимизации могут ускорить выполнение запроса в несколько раз.

Представим, что у нас есть база заказов крупного интернет-магазина с реальными объёмами данных. Индексов нет. Всё выполняется на сырых таблицах. СУБД PostgreSQL.

Задача: посчитать для каждой категории количество заказов, суммарную выручку и средний чек за август 2025 только для завершённых заказов (со статусом completed).

Состав БД:
Таблица orders (5 млн строк) с полями:
➖ id — уникальный идентификатор заказа;
➖ product_id — ID продукта;
➖ order_date — дата заказа;
➖ amount — сумма заказа;
➖ status — статус заказа, например, completed.

Таблица products (2 тыс. строк):
➖ id — ID продукта;
➖ category_id — ID категории;
➖ price — цена.

Таблица categories (100 строк):
➖ id — ID категории;
➖ name — название категории.

Исходный запрос (медленный), ожидаемое время выполнения 4-5 минут:

SELECT 
    c.id,  # идентификатор категории
    c.name AS category,  # название категории
    COUNT(o.id) AS orders_count,  # количество заказов
    SUM(o.amount) / COUNT(o.id) AS avg_check  # средний чек (ручное деление)
FROM orders o
JOIN products p ON o.product_id = p.id  # соединяем с таблицей продуктов
JOIN categories c ON p.category_id = c.id  # соединяем с категориями
WHERE 
    o.status = 'completed'  # фильтруем только завершённые заказы
    AND o.order_date >= '2025-08-01'  # начало периода (строковый литерал)
    AND o.order_date < '2025-09-01'  # конец периода
GROUP BY c.id, c.name   # группировка по категории (строка и id)
ORDER BY SUM(o.amount) DESC;  # сортировка по суммарной выручке

Почему медленно:
➖ JOIN происходит на 5 млн строк без фильтрации.
➖ GROUP BY по c. name — сравнение строк (TEXT) вместо чисел, это дополнительная нагрузка.
➖ AVG считается вручную (SUM / COUNT) — выполняется две агрегации.
➖ Фильтр по дате задан как строка — типы приводятся динамически, что замедляет план выполнения.

Оптимизированный запрос (быстрее в ~10 раз!), ожидаемое время выполнения 25-30 секунд:

WITH filtered_orders AS (
    # Сначала фильтруем все нужные заказы в отдельном CTE
    SELECT *
    FROM orders
    WHERE status = 'completed'  # только завершённые
      AND order_date >= DATE '2025-08-01'  # явное указание типа DATE
      AND order_date < DATE '2025-09-01'
)
SELECT 
    c.id,  # id категории
    c.name AS category,  # название категории
    COUNT(fo.id) AS orders_count,  # количество заказов
    SUM(fo.amount) AS total_sales,  # суммарная выручка
    AVG(fo.amount) AS avg_check  # средний чек (встроенная функция)
FROM filtered_orders fo
JOIN products p ON fo.product_id = p.id  # соединяем уже отфильтрованные заказы
JOIN categories c ON p.category_id = c.id  # соединяем с категориями
GROUP BY c.id  # PK, группировка по ID (name подтянется автоматически)
ORDER BY total_sales DESC;  # сортировка по суммарной выручке

Что изменилось и почему быстрее:
➖ CTE filtered_orders — с EXPLAIN ANALYZE видно, что количество строк на JOIN сократилось примерно до ~500 тыс. строк вместо 5 млн, т. е. 90%!
➖ GROUP BY c.id — сравнение по числу вместо текста, PostgreSQL подтягивает c.name автоматически.
➖ AVG() вместо SUM/COUNT — встроенная оптимизация движка.
➖ Явное указание типа даты (DATE '2025-08-01') — СУБД не тратит время на приведение типов.

На больших таблицах корректная структура запроса может кардинально влиять на скорость выполнения. В результате правильно построенный запрос может обрабатываться в 10-100 раз быстрее, чем прямой вариант с лишними вычислениями и сортировками.

❗️ Оптимизация SQL — это понимание того, как СУБД выполняет операции и как конкретный юзер может эффективно сэкономить свое время и бонусом ресурсы сервера. Ещё больше кейсов и рекомендаций будет на вебинаре 24 сентября — приходите, расскажу про свои способы оптимизации SQL-запросов.

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

📊 Simulative

Must-have инструменты для аналитика в Python

Привет, любители аналитики! С вами Павел Беляев, ментор курса «Дата-аналитик» и ведущий канала «Тимлидское об аналитике».

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

1️⃣ Pandas — король обработки данных

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

➖ Чтение и запись данных в разных форматах;
➖ Фильтрация, сортировка, группировка;
➖ Объединение датасетов;
➖ Базовые статистические операции.

import pandas as pd

# Пример использования
df = pd.read_csv('data.csv') # записывает в датафрейм данные из файла csv
df.head() # выводит первые строки датафрейма

2️⃣ NumPy — математика для больших данных

➖ Работа с массивами и матрицами;
➖ Математические операции;
➖ Генерация случайных чисел.

import numpy as np

# Пример
array = np.array([1, 2, 3, 4, 5]) # создаёт одномерный массив
mean = np.mean(array) # вычисляет среднее значение массива

3️⃣ Matplotlib и Seaborn — визуализация данных, обычно датафреймов

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

import matplotlib.pyplot as plt
import seaborn as sns

# Простой график по точкам
plt.plot([1, 2, 3], [4, 5, 6])
plt.show()

4️⃣ Scipy — это уже следующий уровень, основы статистического анализа

from scipy import stats

# Проведение t-теста для независимых выборок
# Сравнивает средние значения двух групп данных
# Помогает определить, есть ли статистически значимые различия между выборками
result = stats.ttest_ind(data1, data2)  # data1 и data2 — массивы сравниваемых данных

5️⃣ Statsmodels — ещё более продвинутая статистика

➖ Регрессионный анализ;
➖ Временные ряды;
➖ Эконометрика.

import statsmodels.api as sm

# Простая линейная регрессия
model = sm.OLS(y, x).fit()

Для разработки на Python можно использовать:
🟠 Jupyter Notebook и продвинутая среда JupiterLab, которые поставляются, в частности, с пакетом Anaconda;
🟠 Google Colab — простая, но мощная «модернизация» Jupiter для пользователей Google;
🟠 Visual Studio Code — универсальная среда для профессиональных разработчиков.

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

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

📊 Simulative

Привет, аналитики! Мы регулярно собираем обратную связь со студентов и выпускников наших курсов — пришло время подписчиков!

Пожалуйста, ответьте на четыре вопроса ниже, а мы в ответ сделаем наш контент лучше и интереснее 👇

Узнайте, почему ваши SQL-запросы тормозят 🤖

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

На вебинаре Владимир Лунев, бизнес- и системный аналитик с 5-летним опытом работы в ритейле и IT, разберёт 7 реальных кейсов оптимизации SQL-запросов, которые помогали бизнесу принимать быстрые и точные решения.

В ходе вебинара разберём:
🟠 Как понять, что запрос тормозит, и чем это грозит бизнесу;
🟠 Как читать план выполнения (EXPLAIN, EXPLAIN ANALYZE) и находить ошибки;
🟠 Типовые причины медленных запросов и как их исправлять;
🟠 7 реальных кейсов из практики: «было → стало» с разбором кода.

❗️ Встречаемся 24 сентября в 19:00 МСК.

🧡 Обязательно ждём вас в лайве — вы сможете напрямую задать свои вопросы Владимиру Луневу и получить ценный опыт оптимизации SQL-запросов!

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

📊 Simulative

⚡️ Вебинар: первичный анализ и очистка данных с помощью Python

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

На вебинаре Павел Беляев, тимлид аналитики в eLama, автор канала «Тимлидское об аналитике» и ментор курса «Аналитик данных», покажет, как быстро проверить и визуализировать данные в Python.

В ходе вебинара мы на примере данных сервиса по продаже подержанных авто разберём:
➖ Зачем и как проверять качество данных перед анализом;
➖ Как находить выбросы и «поломанные» значения в датасете;
➖ Какие приёмы Python помогают делать агрегацию по категориальным признакам;
➖ Как визуализировать данные и находить закономерности;
➖ Как даже новичок может собрать базовый пайплайн очистки и анализа.

❗️ Встречаемся 23 сентября в 19:00 МСК.

♾ Обязательно приходите на эфир — разберем must-have библиотеки для дата-аналитика: pandas для работы с табличными данными, matplotlib и seaborn для визуального анализа!

➡️ Регистрация на вебинар

📊 Simulative

С какими данными работает аналитик

Приветствую любителей аналитики! С вами Павел Беляев, ментор курса «Аналитик данных». Сегодня поговорим о том, с какими данными и из каких источников приходится работать дата-аналитику.

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

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

1️⃣ CRM-системы

Что это: инструменты сбора, обработки и отображения информации о клиентах и взаимодействии с ними.

Метод сбора данных: чаще всего веб-интерфейс и свой API, через который можно отправить запрос в систему и получить ответ. Большие CRM могут дорабатываться под особенности бизнеса, также может допиливаться и API.

Данные
➖ Контакты и прочие данные клиентов;
➖ Данные о сделках, взаимодействиях и прочих процессах работы с клиентами;
➖ Новые лиды;
➖ Данные о сотрудниках, работающих с клиентами;
➖ Источники лидов;
➖ Другие сведения, которые стекаются в CRM.

Примеры: Битрикс24, amoCRM, Мегаплан.

2️⃣ Cистемы веб-аналитики

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

Метод сбора данных: использование API, но не все системы отдают всё полностью.
Например, Google Analytics 4 не отдаёт полные сырые данные о хитах по API. Эта опция доступна только при прямой интеграции с Google BigQuery, остальным придётся довольствоваться лишь агрегированными данными.

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

Данные
➖ Хиты (события, просмотры страниц);
➖ Визиты/сессии (источники трафика, длительность, данные о приложении-клиенте пользователя и т. д.).

Примеры: Google Analytics, Яндекс Метрика, Amplitude.

3️⃣ Базы данных бизнес-приложений

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

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

Метод сбора
Данные из «своих» СУБД собираются через стандартные методы подключения, например, из Python-скриптов (например, библиотека psycopg2 для работы с PostgreSQL) или же с помощью специализированных инструментов (например, оператор PostgresOperator для Airflow).

Примеры: PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database.

4️⃣ Электронные таблицы

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

Данные: любые табличные данные.

Метод сбора: популярные облачные решения имеют свои API и Python-библиотеки. Для csv и xlsx-файлов в Python также есть функции загрузки в скрипт (например, в Pandas-датафрейм) и заливки в аналитическое хранилище.

Примеры: Google Sheets, Яндекс Таблицы, файлы Excel, файлы csv.

Все виды данных, а в особенности, как с ними работать, разбираем на курсе «Аналитик данных». Сегодня последний день по ранней цене!

⚡️ Успеть и записаться со скидкой 15%

📊 Simulative

Катастрофа в проде: модель идеально работает в ноутбуке, но ломается после выкатки в продакшн

Привет! На связи Кристина Желтова, ментор курса «ML-инженер».

На практике нередкая ситуация, когда ML-специалист или даже целая команда празднуют победу — их модель показывает на локальных экспериментах отличное качество, а значит, задача решена!

Модель проходит код-ревью, готовится к раскатке в прод и пилотированию или A/B-тестированию, и вот час настал — её выпускают в настоящую жизнь, в production. Но через какое-то время разгневанные заказчики приходят и сетуют на сошедшую с ума модель, которая одобрила кредиты всем подряд или рекомендовала потратить весь бюджет маркетинга на удержание клиентов, которые и так не собирались уходить.

❓ Какие могут быть причины такого поведения модели, и как узнать о существовании проблемы не от заказчиков, а во время экспериментов?

1️⃣ Temporal Leakage: неправильная разбивка данных, упорядоченных по времени

Проблема: команда использовала обычный train_test_split с shuffle=True на упорядоченных данных с временными метками.

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

Правильный подход: использовать специальную валидацию для временных данных — TrainTestSplit.

2️⃣ Feature Leakage: признаки из «будущего»

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

Правильный подход: проверять, что все признаки, агрегации и статистики считаются только на данных до целевой даты предсказания.

3️⃣ Target Leakage: утечка информации из целевой переменной

Проблема: для моделирования использовали признаки, напрямую связанные с целевой переменной или вычисляемые из неё.

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

Кстати, сегодня последний день, когда можно записаться на курс-симулятор «ML-инженер» по низкой цене. Регистрируйтесь и создавайте эффективные модели машинного обучения под руководством опытного ментора-меня 😉

➡️ Записаться на курс со скидкой 15%

📊 Simulative

Разберём решение задачи с поиском ошибок данных таблицы shipments в БД межзвёздной логистической компании «SQL Bootcamp»

Напомним потенциальные аномалии данных, которые нужно было обнаружить, в рамках бизнес-логики компании:
➖ Груз без указанной станции отправления или прибытия
➖ Рейс, где груз вылетает и прибывает на ту же станцию
➖ Отрицательные значения веса или расхода топлива

Верный ответ: B
```
SELECT * FROM shipments
WHERE (dep_station IS NULL OR arr_station IS NULL)
OR (dep_station = arr_station)
OR (weight < 0 OR fuel < 0);
```
➖ Проверяет пустые станции отправления/прибытия
➖ Проверяет одинаковые станции отправления и прибытия
➖ Проверяет отрицательный вес и расход топлива

Разберём остальные ответы:

A)
```
SELECT * FROM shipments
WHERE dep_station IS NULL
OR arr_station IS NULL
OR weight < 0
OR fuel < 0;
```
Не проверяет рейсы, где станция отправления = станция прибытия.

C)
```
SELECT * FROM shipments
WHERE (weight < 0 OR fuel < 0)
OR (COALESCE(dep_station,'') = '' OR COALESCE(arr_station,'') = '');
```
Проверяет только пустые станции и отрицательные значения, не проверяет рейсы с одинаковыми станциями.

D)
```
SELECT * FROM shipments
WHERE dep_station = arr_station
OR dep_station IS NULL
OR arr_station IS NULL;
```
Проверяет пустые станции и одинаковые станции, но не отрицательный вес и расход топлива.

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

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

Подробнее про проверки мы поговорим в рамках SQL-буткемпа — регистрируйтесь, до конца сентября держим ранние цены!

🔔 Зарегистрироваться на тренинг по SQL

📊 Simulative

Давайте попрактикуемся в поиске ошибок данных?

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

Потенциальные аномалии данных, которые нужно обнаружить в рамках бизнес-логики компании:
➖ Груз без указанной станции отправления или прибытия;
➖ Рейс, где груз вылетает и прибывает на ту же станцию;
➖ Отрицательные значения веса или расхода топлива;

Таблица shipments:

id     dep_station  arr_station  weight   fuel
7001   Alpha-7      NULL         5.0      300
7002   Beta-9       Beta-9       2.1      450
7003   Gamma-5      Delta-1      8.3      -20
7004   Epsilon-3    Zeta-2      -1.5      100

Описание атрибутов:
id — уникальный номер перевозки
dep_station — станция отправления
arr_station — станция прибытия
weight — вес груза
fuel — расход топлива

Какой запрос найдёт все потенциальные аномалии данных в таблице shipments?

A)

SELECT * FROM shipments
WHERE dep_station IS NULL
   OR arr_station IS NULL
   OR weight < 0
   OR fuel < 0;

B)

SELECT * FROM shipments
WHERE (dep_station IS NULL OR arr_station IS NULL)
   OR (dep_station = arr_station)
   OR (weight < 0 OR fuel < 0);

C)

SELECT * FROM shipments
WHERE (weight < 0 OR fuel < 0)
   OR (COALESCE(dep_station,'') = '' OR COALESCE(arr_station,'') = '');

D)

SELECT * FROM shipments
WHERE dep_station = arr_station
   OR dep_station IS NULL
   OR arr_station IS NULL;

Пишите в комментариях свою версию, завтра опубликуем правильный вариант ❤️

📊 Simulative