⚡️ТОП навыков ML-инженера на примере реальной бизнес-задачи

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

😶Чтобы увидеть полный цикл решения реальной задачи и понять, какие навыки нужны ML-инженеру в работе, приходите 16 сентября на практико-ориентированный вебинар от Кристины Желтовой — директора по разработке моделей в Газпромбанке.

В ходе вебинара мы на примере задачи предсказания оттока клиентов разберём:

🟠Актуальность предсказания оттока клиентов для бизнеса
🟠Как работать с «сырыми» данными и подготовить их для обучения модели
🟠Как выбрать, построить и обучить базовую модель в Google Colab
🟠Как проверить, качество работы модели: разбор метрик и ошибок
🟠Какие ключевые навыки складываются в профессию ML-инженера.

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

*️⃣Обязательно ждем вас в лайве — сможете напрямую задать свои вопросы Кристине Желтовой и забрать с собой пример файла в Google Colab, к которому сможете вернуться в любое время для практики!

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

4 ключевых навыка ML-инженера в 2025 году

Уже много лет машинное обучение развивается и приносит пользу компаниям, и наметились очевидные тренды — нейросети становятся больше и умнее, а инструментов для работы становится столько, что и за всю жизнь не изучишь. При этом работодатели всё чаще ждут от кандидатов не только знания ML-алгоритмов, но и умения внедрять модели в реальный бизнес.

Ментор курса «ML-инженер» Кристина Желтова рассказала, какие навыки сегодня делают ML-инженера по-настоящему востребованным:

🟠 Техническая база

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

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

🟠 Работа с данными

Не зря говорят, что 80% работы приходится именно на данные — это залог успеха всего проекта. Поэтому умение строить data-пайплайны и грамотно трансформировать сырые данные в чистые выборки для обучения просто необходимо, иначе есть риск получить очень слабую и глупую модель.

🟠 Продакшн и MLOps

Жизнь модели не заканчивается после обучения. Дальше её ждёт внедрение, мониторинг и, возможно, регулярные запуски переобучения. Далеко не все ML-специалисты собственноручно занимаются внедрением — часто это отводится специалистам в роли MLOps, однако стоит понимать, какие у модели есть «особенности поведения» в проде. Например, насколько она «тяжелая» — как много времени ей требуется на подготовку прогноза, и как это соотносится с техническими требованиями — есть ли в процессе столько времени, чтобы ждать, пока модель «подумает»?

🟠 Soft skills

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

Навык объяснять сложное простыми словами даже неспециалисту недооценен и может очень сильно ускорить продвижение по карьерной лестнице, особенно по вертикальному треку.

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

♾ Уже завтра на вебинаре в 19:00 МСК разберём, как ML-инженер применяет свои навыки в реальной работе с данными. Регистрируйтесь и знакомьтесь с профессией под руководством опытного ментора!

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

Зачем прогнозировать отток клиентов и как это сделать

Привет! Снова на связи Кристина Желтова, ментор курса «ML-инженер» и спикер сегодняшнего вебинара про топ навыков в профессии.

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

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

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

Упрощённый пайплайн выглядит примерно так:

🟠 Готовим данные — превращаем сырую информацию в понятные моделям признаки. Например, как давно был последний визит, сколько товаров в корзине, характер активности на сайте.

🟠 Экспериментируем с моделями — выбираем ту «звёздочку», которая лучше всех отработает на наших данных.

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

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

Как работает этот пайплайн на реальном проекте, узнаем уже сегодня в 19:00 МСК на вебинаре. Приходите, чтобы погрузиться в профессию и понять, какие навыки будут полезны для обучения базовой модели.

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

📊 Simulative

Привет, аналитики! Меня зовут Владимир Лунев. Более 5 лет я работаю в IT как бизнес- и системный аналитик.

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

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

Несколько кейсов из моей работы:

👑 Оптимизировал отчёт и сократил время его выполнения с 3 часов, до 30 минут, не переписывая бизнес-логику, а разобрав EXPLAIN и исправив ошибки SQL-запросов.
👑 Построил систему контроля качества данных на основании проверочных скриптов, которая автоматически ловила дубли, NULL-ловушки и логические противоречия до попадания информации в отчёты.
👑 Разработал автоматизированный процесс агрегации и расчёта KPI для сети магазинов, позволивший ежедневно получать корректные метрики без ошибок.

Я буду ведущим SQL-буткемпа — практикума, где вы получите реальные навыки, которые работают в боевых проектах бизнеса. В рамках буткемпа мы разберём:

➖Оптимизацию запросов в SQL — разбор EXPLAIN, выявление «тормозящих» мест, исправление лишних подзапросов и «фантомных» строк для ускорения критичных бизнес-отчётов и выгрузок.
➖Контроль качества данных — научимся писать кастомные скрипты проверок данных для точных и надёжных данных.
➖Прогнозы и тренды — построение когорт, скользящих метрик, lag/lead-анализ и простые линейные прогнозы для точного планирования.
➖Сценарный анализ «что если» — моделирование альтернатив через параметризацию, temp-таблицы и CTE, автоматизация расчётов для оценки влияния изменений на ключевые показатели.
➖ Агрегацию данных и полезные бизнес-метрики — расчёт growth, hitrate, долей, YoY, контроль перекосов и проведение A/B-анализов для оценки эффективности решений.
➖ Рекурсию и последовательности — поработаем с деревьями parent-child, обходом графов, кластеризацией и сегментацией пользовательских действий для глубокого анализа процессов.

Формат: много практики на кейсах и задачах из IT-проектов и немного сопутствующей теории.

Буткемп будет полезен аналитикам, data-engineers, backend-разработчикам, а также всем, кто работает с массивами данных, строит отчёты и хочет улучшить навыки владения SQL.

Если вы хотите писать SQL-запросы так, чтобы данные реально работали на вас, а не наоборот — этот буткемп для вас!

➡️ Зарегистрироваться на буткемп по ранней цене

📊 Simulative

Как онбордятся дата-аналитики в Яндекс eLama

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

Новичку предстоит освоить немало всего:
➖Рабочие процессы и регламенты;
➖Наш инструментарий;
➖Наши данные;
➖Персонажи (заказчики, исполнители, смежники).

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

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

В списке ссылок новичок найдёт сведения об инструментах и процессах:
🟠 Корпоративные сервисы — структура компании, данные о сотрудниках, календарь, диск, почта и т. д.;
🟠 Раздел Data Office в корпоративном wiki-справочнике;
🟠 Регламент работы дежурного, или SLA — Service Level Agreement, о котором еще расскажу;
🟠 Наш стандарт оформления кода SQL;
🟠 Бизнес-глоссарий — используемые термины и метрики;
🟠 Описание рабочих процессов: планирование, движение задач, жизненный цикл витрин данных.

А также техническую информацию о данных:
🟠 Архитектура аналитического хранилища и ETL-механизмов;
🟠 Основные таблицы (витрины) и их представления;
🟠 Модель данных;
🟠 Механизм обновления данных и метаданных;
🟠 Используемые технические справочники и т. д.

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

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

Начиная со второй недели неофит участвует в планировании спринта, получает боевые задачи. Сначала простенькие, позже посложнее. А с третьей недели он уже дежурит, принимая текущие заявки от заказчиков. (Во многих компаниях у аналитиков имеется институт дежурства, когда один человек в течение некоторого периода отвечает за прием и обработку входящих обращений, чтобы остальные не отвлекались от проектных дел.)

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

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

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

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

♾ Кстати, до 19 сентября действует скидка -15%, так что успевайте зарегистрироваться и прокачать себя в профессии аналитика.

🧡 Получить предложение по низкой цене

📊 Simulative

Вебинар вчера был 🔥

Спасибо всем, кто пришёл, и особенно — кто задавал вопросы! Ментор Кристина передаёт спасибо за положительные отзывы и ждёт вас на курсе 🧡

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

А для тех, кто ещё не успел забронировать себе место на курсе «ML-инженер», есть время забежать в уходящий поезд и получить предложение по низкой цене — скидка 25% до конца дня 🔥

🖱 Успеть и забронировать место

📊 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

Разберём решение задачи с поиском ошибок данных таблицы 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

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

Привет! На связи Кристина Желтова, ментор курса «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

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

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

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

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

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

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

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

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

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

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

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

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

📊 Simulative

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

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

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

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

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

🧡 Обязательно ждём вас в лайве — вы сможете напрямую задать свои вопросы Владимиру Луневу и получить ценный опыт оптимизации 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». Давайте разберём кейс, где простые приёмы оптимизации могут ускорить выполнение запроса в несколько раз.

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

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

Привет! С вами Кристина Желтова, ментор курса «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