💻💻💻💻💻 Data science на практике: решаем задачу и оформляем проект в портфолио

Вы решили попробовать себя в data science — что делать дальше?

На вебинаре с Марией Жаровой вы пройдёте путь, который проходит дата-сайентист над реальной задачей — от постановки до готового проекта в портфолио:

➖ Возьмём финальное задание из бесплатного курса по ML и разберём, как подойти к нему самостоятельно;
➖ Обучим несколько моделей из sklearn, попробуем нестандартные подходы и выберем лучший вариант;
➖ Оформим ноутбук в полноценный проект на GitHub и разберём, что обязательно должно быть в README.md, чтобы проект выглядел сильным в портфолио.

👩🏻‍💻 Спикер: Мария Жарова, ML-инженер в команде рекомендаций Wildberries и ментор курса Симулейтив «Дата-сайентист»

📆 Когда: 18 августа, 19:00 МСК
➡️ Поставить напоминание в календарь

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

💻 Сценарии использования NULLIF

Вас когда-нибудь спрашивали на собеседовании о функции NULLIF?

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

✅ Что такое NULLIF и как это использовать?

NULLIF — это функция, которая принимает два аргумента и возвращает NULL, если аргументы равны, в противном случае она возвращает первый аргумент. Синтаксис выглядит следующим образом:

NULLIF(выражение 1, выражение 2)

💻 Деление на ноль

Пожалуй, самое полезное, что можно сделать, используя NULLIF — пресечь ошибку деления на ноль.

Это один из самых распространённых вариантов использования. Например, если вы пытаетесь поделить один столбец на другой, и есть вероятность, что во втором столбце (делителе) могут оказаться нули — оберните второй столбец в NULLIF и вы не получите ошибок.

SELECT column1/NULLIF(column2, 0)
FROM table1

То есть когда значение второго столбца равно 0 (аргументы в NULLIF равны), вернется NULL, а не ZeroDivisionError.

💻 Поиск среднего значения

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

Например, дана такая таблица:

| column1 | column2 |
|---------|---------|
| 0       | a       |
| 7       | a       |

Выполнив:

SELECT column2, AVG(column1)
FROM table1
GROUP BY column2;

Получим:

| column2 | avg |
|---------|-----|
| a       | 3.5 |

А с использованием NULLIF получим другой результат:

SELECT column2, AVG(NULLIF(column1, 0))
FROM table1
GROUP BY column2;

| column2 | avg |
|---------|-----|
| a       | 7   |

💻 Преобразование пустых строк

Другой вариант использования NULLIF — преобразование пустых строк в NULL. Например, в таблице некоторые столбцы содержат пустые строки, которые необходимо трактовать как NULL — идеально подходящая ситуация для NULLIF:

SELECT NULLIF(column1, '') FROM table1;

Получим NULL, если столбец 1 содержит пустую строку, что эффективно обработает все пустые строки.

💡 В следующий раз, когда вы будете работать над проектом, попробуйте найти, где бы вы могли использовать NULLIF и убедитесь, как он легко поможет решать сложные задачи и избегать больших CASE/WHEN конструкций. Кстати говоря, NULLIF — это тот же CASE/WHEN, так что, возможно, стоит провести ревизию старых проектов и увидеть потенциальные «use» кейсы.

Если вы и раньше использовали NULLIF, расскажите, в каких интересных задачах он вам пригодился? И ставьте 🔥, если было полезно!

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

«ON CONFLICT DO UPDATE command cannot affect row a second time»: как мы теряли данные из-за этой ошибки

Привет! На связи Валерия Елпатьевская, ментор курса «Инженер данных» 👋🏻

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

ERROR: ON CONFLICT DO UPDATE command cannot affect row a second time

Какой же second time? Как вообще такое возможно? Так вот рассказываю.

Если вы делаете `INSERT ... ON CONFLICT DO UPDATE` большими батчами (пакетами данных), дедуплицируйте входные данные до `UPSERT`.

Допустим, в батче пришли две записи с одним id:

INSERT INTO users (id, updated_at, name)
SELECT id, updated_at, name
FROM staging
ON CONFLICT (id) DO UPDATE
SET
    updated_at = EXCLUDED.updated_at,
    name = EXCLUDED.name;

Если staging содержит несколько строк с одинаковым id, PostgreSQL завершит такую операцию ошибкой, как выше.

Причина в том, что внутри одного INSERT несколько входных строк пытаются изменить одну и ту же target-строку. PostgreSQL не выбирает автоматически, какая из них является истиной. Он не пытается угадать, а просто отказывается выполнять операцию.

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

Поэтому перед UPSERT лучше явно определить правило разрешения конфликта и избавиться от дубликатов:

WITH ranked AS (
    SELECT
        *,
        ROW_NUMBER() OVER (
            PARTITION BY id
            ORDER BY updated_at DESC
        ) AS rn
    FROM staging
)
INSERT INTO users (id, updated_at, name)
SELECT id, updated_at, name
FROM ranked
WHERE rn = 1
ON CONFLICT (id) DO UPDATE
SET
    updated_at = EXCLUDED.updated_at,
    name = EXCLUDED.name;

Теперь для каждого id в батче остаётся ровно одна запись — например, самая свежая по updated_at.

📌 Вывод: ON CONFLICT решает конфликт между входящей и целевой строкой, но не занимается бизнес-логикой выбора между несколькими строками с одним ключом.

Ставьте 🔥 и пересылайте тем, кто мог бы столкнуться с этой проблемой ❤️

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

🎓 3 дня до завершения приёма в магистратуру

Друзья, осталось всего несколько дней, чтобы принять решение о поступлении! А в этом посте напоминаем основные моменты ❤️

Магистерская программа по аналитике данных совместно с НИЯУ МИФИ — это:

🔶 Научная база от одного из лучших технических вузов страны;
🔶 Практика на симуляторе — работа с реальными бизнес-кейсами «как в работе»;
🔶 Гарантированное портфолио, которое выделит вас среди других кандидатов;
🔶 Возможность получить диплом магистра;
🔶 Гибкий онлайн-формат — учитесь из любой точки мира;
🔶 Все льготы студента МИФИ — диплом, отсрочка, налоговый вычет.

❗️ Заявки принимаются до 21 августа включительно. Для новых поступающих действует реферальная программа: приводите второго человека и получите скидку 20% каждому!

➡️ Узнать больше и оставить заявку

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

Репрезентативность: когда выборка «говорит правду»

Привет, на связи Аслан Байрамкулов, автор курса по A/B-тестированию 👋🏻

Тест может быть безупречно посчитан — правильная метрика, честный p-value, никакого подглядывания — и всё равно врать. Если сама выборка не похожа на генеральную совокупность, статистика посчитает верно ответ на неверный вопрос.

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

✅ Как это измеряют?

Репрезентативность оценивают стандартизованной разностью d между выборкой и генеральной совокупностью по ключевым признакам:

➖ d < 0,1 — отличная репрезентативность;
➖ d 0,1–0,2 — хорошая;
➖ d 0,2–0,5 — умеренная;
➖ d ≥ 0,5 — плохая, выборке доверять нельзя.

✅ Как обеспечить репрезентативность?

➖ Стратифицированная рандомизация. Делим пользователей на страты — по возрасту, географии, каналу — и рандомизируем внутри каждой страты. Это гарантирует, что обе группы сбалансированы, а не просто «в среднем похожи».

➖ Мониторинг баланса. После запуска теста проверяем, что группы A и B не отличаются по ключевым характеристикам. Доля мобильного трафика 60% в группе A и 45% в группе B — уже повод остановиться и разобраться, а не запускать анализ дальше.

➖ AA-тестирование. Перед реальным тестом запускаем «пустой» тест, где обе группы получают одинаковый опыт. Если находим статистически значимые различия там, где их не должно быть — проблема не в продукте, а в системе рандомизации.

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

⭐️ Именно поэтому на курсе «A/B-тестирование» мы начинаем не с формул значимости, а с проверки самой выборки: стратификация, мониторинг баланса, AA-тесты как обязательный шаг перед любым реальным экспериментом. Программу веду я сам на основе методологии, которую строил в X5, Wildberries и МТС (open-source библиотека Ambrosia).

⭐️ Посмотреть программу курса

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

💻💻💻💻💻Как аналитику данных использовать ИИ

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

На вебинаре вы:
➡️ Узнаете, для каких задач ИИ применяет команда дата-аналитиков в Яндекс eLama;
➡️ Разберётесь, какие модели для чего хороши, и перестанете хвататься за одну на все случаи;
➡️ Познакомитесь с инструментами обращения к ИИ: чаты в браузере, Ollama для локальных моделей, расширение для VS Code;
➡️ Увидите на живом примере, как Павел использует ИИ для собственного самообучения;
➡️ Разберём ваши вопросы и темы с помощью ИИ-ассистентов.

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

📆 Когда: 22 августа, 14:00 МСК
➡️ Поставить напоминание в календарь
➡️ Ссылка на эфир

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

💻💻💻💻 Собираем ETL-пайплайн для 9 млн строк

Присоединяйтесь сегодня к практическому стриму — Валерия Елпатьевская, инженер данных в Альфа-Банке, соберёт полный ETL-пайплайн на реальных данных: от сырых parquet-файлов до готового аналитического отчёта и витрин в DuckDB. В работе — открытый датасет поездок нью-йоркского такси за осень 2025 года, больше 9 млн строк!

Что сделаем:
1️⃣ Загрузим данные из открытых источников;
2️⃣ Почистим датасет от аномалий;
3️⃣ Обогатим поездки данными о погоде;
4️⃣ Визуализируем статистику по датасету;
5️⃣ Загрузим агрегаты в DuckDB и напишем запросы для финального отчёта.

Если вы только присматриваетесь к профессии дата-инженера и хотите понять, из чего реально состоит его работа, приходите! Стрим пригодится и тем, кто уже сам пишет ETL: сверите свой подход с тем, как выстраивает пайплайн инженер с опытом.

📆 Когда: 24 августа, 19:00 МСК
➡️ Поставить напоминание в календарь

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

💻💻💻💻💻Онлайн-практикум: превращаем SQL-проект в первый кейс для портфолио

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

Что будет происходить на вебинаре:
➡️ Разберём финальный SQL-проект и подход к его решению;
➡️ Поймём, как оформить проект так, чтобы он выглядел сильным кейсом в портфолио;
➡️ Обсудим, что сейчас происходит на рынке и как заходить в аналитику в 2026 году.

🧑‍💻 Спикер: Евгений Буторин, руководитель CRM-аналитики развития клиентской базы в Альфа Банке, ментор бесплатного интенсива по SQL

📆 Когда: 25 августа, 19:00 МСК
➡️ Поставить напоминание в календарь

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

💻 Как база данных устроена изнутри, и почему PostgreSQL и ClickHouse решают разные задачи?

Привет! На связи Валерия Елпатьевская, ментор курса «Инженер данных» 👋🏻

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

И здесь важно понимать разницу между OLTP и OLAP.

💻 OLTP (Online Transaction Processing), как видно из названия, заточена под транзакции. То есть эти базы предполагают операционную нагрузку.

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

Под такую нагрузку обычно берут PostgreSQL. Он хранит данные построчно, использует индексы, WAL, MVCC и механизмы очистки старых версий. Это хорошо подходит для сценария: «найди пользователя по id», «обнови заказ» или «вставь новую запись».

💻 OLAP (Online Analytical Processing), как опять же ясно из названия, заточен под аналитику. Здесь запросы часто читают миллионы строк, считают различные агрегаты, группируют данные по времени, регионам, каналам. Примеры данных, которым больше подойдёт OLAP — метрики, продажи и поведение пользователей.

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

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

Если сильно упростить:
➡️ PostgreSQL — про состояние системы и транзакции.
➡️ ClickHouse — про аналитику по большим потокам событий.

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

Ставьте ❤️, если полезно, и сохраняйте, чтобы не потерять!

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

Привет! Меня зовут Ева Панкратова, и я новый ментор курса «Аналитик данных» в Симулейтив 👋🏻

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

Пять фактов обо мне:
➖ Работаю с данными больше 6 лет: финтех, телеком и IT:  Accenture, МегаФон, Райффайзенбанк, М2. Последние два года — в руководящей роли.
➖ Строила аналитику со всех сторон: начинала как DWH-аналитик, который строит и тестирует витрины данных, а затем перешла к плотной работе с бизнесом и проверке продуктовых гипотез.
➖ Специализируюсь на А/В и экспериментах. Провела десятки тестов как аналитик, а потом запускала А/B-тестирование в компании, занимаясь как выбором платформы для тестов, так и выстраиванием культуры экспериментов.
➖ Провела 162 собеседования, собирая команду. Так что не понаслышке знаю, что спрашивают на собеседованиях и как выглядит цепляющее резюме.
➖ Считаю важным делиться опытом: пишу курсы и веду воркшопы для корпоративного университета, выступаю на профессиональных конференциях и периодически менторю студенческие стартапы.

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

Присоединяйтесь, старт потока 31 августа ❤️

📌 Записаться на профессию «Аналитик данных»

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

💻 Ошибка в SQL: избыточные подзапросы

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

✅ Почему так происходит?

Из-за того, что многие пишут SQL-запросы так же, как это «звучит» в их голове. А SQL работает немного иначе — на нём нужно буквально «мыслить». Но это приходит с опытом, за счёт большого количества практики (как правило, к концу модуля по SQL такие ошибки уже никто не делает). 

✅ Пример

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

Итак, задача: вывести id транзакции и предыдущую сумму транзакции со знаком минус. Вот решение студента:

SELECT id, 
       LAG(neg) OVER(ORDER BY id) 
       AS lg
FROM (
      SELECT id, sm, -sm AS neg
      FROM (
            SELECT id, sum AS sm 
            FROM transactions t
  ) t
) t1

И это ещё не всё, можно и побольше накрутить. Но зачем так, если можно так:

SELECT id, LAG(-sum) OVER(ORDER BY id) 
FROM transactions t

✅ А как писать такие запросы? 

Отсекайте лишнее. Напишите запрос так, как получилось. Затем попробуйте упростить. Затем ещё. И так до тех пор, пока не получите минимально возможный запрос.

✅ Совет

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

Ставьте 🔥, если полезно, и сохраняйте, чтобы не потерять!

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

💻💻💻💻💻Как использовать ИИ в аналитике на трёх уровнях?

Два аналитика посчитали retention по одному и тому же вопросу — один получил 34%, другой 21%. Оба SQL-запроса технически верны, но каждый объяснял нейросети метрику по-разному. Как такое может быть?

29 августа вместе с Ильёй Ковалёвым, тимлидом команды клиентской аналитики в Dodo Brands, разберём, как устроена работа с ИИ на трёх уровнях — от разового промпта до процесса, который сам ловит свои ошибки.

На вебинаре вы:
➡️ Узнаете, почему хороший промпт из пяти блоков даёт совсем другой результат, чем «напиши запрос», и увидите это на реальном SQL-примере;
➡️ Разберётесь, как контекст команды выносится из головы аналитика в репозиторий, и почему это меняет качество ответов ИИ;
➡️ Увидите на одной и той же задаче — расчёте retention — все три уровня подряд и разницу в результате;
➡️ Узнаете три правила, которые не меняются ни на одном из уровней.

🧑🏻‍💻 Спикер: Илья Ковалёв, тимлид команды клиентской аналитики в Dodo Brands, автор Telegram-канала Кусочек пиццы

📆 Когда: 29 августа, 12:00 МСК
➡️ Поставить напоминание в календарь

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

💻💻💻💻💻 Кто такой аналитик данных? Разбираем профессию с лидом из Альфа-Банка

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

1 сентября открываем новый поток бесплатного интенсива по SQL — вместе с ментором интенсива Евгением Буториным разберём профессию по полной: от рынка труда до практики!

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

👨🏻‍💻 Спикер: Евгений Буторин, руководитель CRM-аналитики развития клиентской базы в Альфа Банке, ментор бесплатного интенсива по SQL.

📆 Когда: 1 сентября, 19:00 МСК
➡️ Поставить напоминание в календарь

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

🍂 Расписание в сентябре

Присоединяйтесь к потокам в сентябре и освойте актуальные и востребованные профессии за 10 недель 📈

🛎️ Напоминаем, что все наши курсы (включая те, что выйдут в течение следующего года) доступны по подписке с выгодой до 70%!

15 сентября

🍂 Профессия «Аналитик данных»
Ментор курса: Ева Панкратова, руководитель продуктовой аналитики в Метр Квадратный

23 сентября

🍂 Дата-сайентист
Ментор курса: Мария Жарова, ML-инженер в команде рекомендаций в Wildberries

28 сентября

🍂 Профессия «Аналитик данных»
Ментор курса: Ева Панкратова, руководитель продуктовой аналитики в Метр Квадратный

🍂 Инженер данных
Ментор курса: Валерия Елпатьевская, инженер данных в Альфа-Банке

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