Присоединяйтесь сегодня в 19:00 по МСК к нашему вебинару!

Павел Беляев, тимлид дата-аналитиков в Яндекс eLama, поделится своим решением тестового задания в Lamoda.

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

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

📊 Simulative

5 ошибок новичков в SQL

Привет, будущие аналитики! С вами Павел Беляев, ментор курса «Аналитик данных» и ведущий канала Тимлидское об аналитике 👋🏻

Хочу привести несколько ошибок начинающих в SQL, которые наблюдал в своей практике. Предупреждён — значит вооружён!

1️⃣ JOIN вместо LEFT JOIN

Положим, есть таблица с юзерами users и таблица с их финансовыми активностями. Мы хотим вывести юзеров, которые зарегистрировались в 2026 году, и подтянуть их транзакции.

SELECT u.user_id, money_sum
FROM
(
    SELECT user_id
    FROM users
    WHERE DATE(date_registration)>=DATE('2026-01-01')
) AS u

JOIN
(
    SELECT user_id, SUM(amount) AS money_sum
    FROM transactions
    GROUP BY user_id
) AS t

Так? Нет! В этом запросе мы увидим не всех пользователей, а лишь тех, у которых были транзакции.

2️⃣ BETWEEN и формат даты

Чтобы вытащить данные временного ряда из определённого интервала, часто прибегают к BETWEEN в условии:

SELECT user_id, SUM(amount) AS money_sum
FROM transactions
WHERE paid_at BETWEEN '2025-12-01' AND '2025-12-31'
GROUP BY user_id

Оператор BETWEEN включает границы в выборку, так что вроде всё верно, да? Нет. Дело в том, что обычно транзакции хранятся в формате «дата-время»: 'YYYY-MM-DD HH:MM:SS'.

В нашем запросе '2025-12-31' будет приведено к форме '2025-12-31 00:00:00', а значит, почти весь день из правой границы не попадёт в выборку!

Правильный вариант — привести поле paid_at к формату «дата» и только потом подставлять в условие:

WHERE DATE(paid_at) BETWEEN '2025-12-01' AND '2025-12-31'

3️⃣ Пересечения условий в CASE WHEN ... END

Рассмотрим запрос, сегментирующий пользователей по их суммарному обороту:

SELECT user_id,
    CASE
        WHEN SUM(amount)<100 THEN 'C'
        WHEN SUM(amount)<=150 THEN 'B'
        WHEN SUM(amount)>=150 THEN 'A'
    END AS segment
FROM transactions
GROUP BY 1

К какому сегменту отнесётся пользователь с оборотом 150? Исходя из кода — к 'B'. Но отвечает ли это бизнес-логике?

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

WHEN SUM(amount) < 100 THEN 'C'
WHEN SUM(amount) < 150 THEN 'B'
WHEN SUM(amount) >= 150 THEN 'A'

4️⃣ Проверка на NULL в условиях

При составлении любых фильтрующих условий (WHERE, ON, HAVING и т. п.) следует помнить, что 0 и NULL — не одно и то же.

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

WHERE money_sum = 0

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

WHERE money_sum IS NULL

5️⃣ NULL в условиях объединения

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

SELECT * FROM t1
LEFT JOIN t2 ON t1.nullable_col = t2.nullable_col

то имейте в виду, что NULL слева не заджойнится с NULL справа. Если в обеих таблицах nullable_col IS NULL, эти строки не попадут в выборку, хотя кажется, что колонки равны, правда?

Для таких случаев следует полю для соединения назначить какое-то значение с помощью функции COALESCE или IFNULL:

SELECT * 
FROM
(
    SELECT *, COALESCE(nullable_col, 'empty') AS j
    FROM t1
) AS j1

LEFT JOIN
(
    SELECT *, COALESCE(nullable_col, 'empty') AS j
    FROM t2
) AS j2 ON j1.j = j2.j

Ставьте реакции, если было полезно!

📊 Simulative

Узнаем, как перейти из Excel в SQL и Python, через пару часов

Вместе с Вугаром Дамировым, Data Analyst Team Lead с 7‑летним опытом, расскажем бизнес-кейсы, где пригодится SQL вместо стандартного Excel.

Что вы получите от вебинара:
➖ Поймёте, когда Excel уже мешает работе: отчёты растут, таблички ломаются, автоматизации нет;
➖ Увидите на примерах, как SQL и Python забирают рутину: сами тянут данные, обновляют отчёты и ускоряют проверку гипотез;
➖ Разберётесь, какие базовые навыки SQL, Python и BI нужны, чтобы претендовать на роль fullstack-аналитика.

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

📊 Simulative

Объявляем Q&A-сессию с Анастасией Кузнецовой!

Спасибо большое вам за вопросы, присланные в форму — Настя ознакомилась со всеми и готова ответить на самые интересные из них. В течение дня мы поделимся её ответами. Stay tuned!

📊 Simulative

⚡️ Прервём наш Q&A важным сообщением: анонсируем новый курс «Инженер глубокого обучения нейросетей» от МИФИ и Simulative!

Эта программа профессиональной переподготовки — сплав науки от лучшего исследовательского вуза страны НИЯУ МИФИ и практики в формате симулятора реальной работы от Simulative.

Почему это ваш шанс?

😶 Диплом МИФИ: официальный диплом о переподготовке с квалификацией «Специалист по большим данным» от вуза, входящего в топ-4 России;
😶 100% практики: вы добавите в портфолио 40+ практических работ;
😶 Гибкий онлайн-формат: учитесь из любой точки мира, совмещая с работой. Доступ к материалам — навсегда;
😶 Для любого уровня: если вы новичок, аналитик, действующий ML-инженер или выпускник — программа выстроит ваш путь в Deep Learning.

Что вы получите?

➖ Навыки создания нейросетей с нуля: Computer Vision, NLP, генеративные модели и MLOps;
➖ Рост от джуна до востребованного специалиста, зарплата уже на старте — от 80 000 до 150 000 ₽, а на следующих этапах — до 350 000 ₽ и больше;
➖ Карьерный трамплин в самой горячей сфере технологий.

📆 Старт обучения — 12 марта, продолжительность 9 месяцев.

Места на поток ограничены! Забронируйте место на курс уже сейчас и сделайте решающий шаг в карьере:

➡️ Оставить заявку на бронь и консультацию

Есть вопросы по программе, оплате от компании или вступительным требованиям? Оставьте свои контакты на сайте, и наши менеджеры подробно ответят!

📊 Simulative

Ещё раз спасибо Насте и всем, кто задавал вопросы!

Напоминаем, что уже 30 января стартует авторский тренинг Насти «Осмысленные дашборды», где она поделится своим опытом построения эффективных дэшей.

За 9 недель вы пройдёте весь путь от сбора требований до релиза и поддержки дашборда и научитесь проектировать дашборды, ориентированные на бизнес-цели. А ещё пополните своё портфолио и сделаете шаг вперёд навстречу карьере!

📈 Бронируйте место на потоке уже сейчас: simulative.ru/bi-training

📊 Simulative

Проект студента: ETL-процесс для обработки данных в LMS

Делимся ещё одним крутым проектом нашего студента курса «Аналитик данных», который высоко оценили преподаватели!

Александр реализовал ETL-процесс для автоматической обработки данных об учебной активности студентов. Система на удалённом сервере с помощью cron ежедневно в 7 утра собирает данные по API, загружает их в PostgreSQL, формирует отчёт в Google Sheets, отправляет email-уведомления, визуализирует результаты в Metabase и логирует все происходящее. Цель — исключить ручной сбор данных и мониторить ключевые метрики.

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

Студент благодарит преподавателя Илью Трофимова и ментора Александра Грудинина за помощь в этом проекте!

👩‍💻 Посмотреть проект можно по ссылке: https://github.com/iwswmb/lms-analytics-pipeline

📊 Simulative

Как аналитику данных покорить рынок в 2026 году? Отвечают NEWHR и Simulative

NEWHR с 2018 года проводят исследование рынка аналитиков: отслеживают тренды рынка и выясняют, как аналитики ищут работу, какие задачи выполняют чаще всего и как планируют развиваться в профессии.

Основатель NEWHR Кира Кузьменко и авторы исследования 2025 года готовы поделиться промежуточными результатами из первых уст 😉

Приглашаем всех аналитиков и тех, кто хочет перейти в эту профессию, на вебинар, где взглянем на поиск работы со стороны HR и поговорим:

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

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

Вебинар проведут:

*️⃣ Кира Кузьменко, фаундер международного рекрутингового агентства NEWHR, автор курса по поиску работы Hello New Job!, сервиса анонимного поиска работы Geekjob и подкаста Собес.
*️⃣ Оксана Прутьянова, лидер направления поиска аналитиков и дата-сайентистов в NEWHR, член исследовательской команды NEWHR;
*️⃣ Наталья Рожкова, HR Simulative, ex-ANCOR IT-рекрутмент, ex-HRtech, эксперт по найму топов.

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

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

💬 Всем зарегистрировавшимся в боте дарим полезные материалы от NewHR для старта карьеры в аналитике!

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

📊 Simulative

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

В статье блога разберёмся, что это такое, какие они бывают и как их использовать:

https://simulative.ru/blog/window-functions-sql

📊 Simulative

О значимости времени и стандартов

Всем привет! На связи Георгий Семенов, руководитель команды Analytics Engineer в Яндекс и ментор курса «Инженер данных».

Давным-давно, еще в доковидные времена, нам понадобилось настроить сбор ежедневных статистик наших мобильных приложений из личного кабинета Apple Developer.

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

Довольно быстро выяснили, что Apple отдаёт даты в таймзоне Pacific Time, который меньше UTC на 7 часов летом и на 8 зимой, тогда как мы всегда использовали UTC. Сейчас Apple уже умеет в UTC, но тогда это стало для нас проблемой, ведь мы не могли сверить свои финансовые и продуктовые отчеты. Хорошо, что нам было с чем сверять. Иначе ошибка могла пройти незамеченной — и такое случается.

А ведь большинство табличных данных — это time-series.

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

И да — для этого недостаточно указать дефолтную timezone в настройках вашей БД.

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

И дело не только во времени. Другие поля (идентификаторы, денежные суммы, категории и прочее) часто имеют в разных источниках разные названия, типы данных и форматы значений даже для одних и тех же реальных объектов. Всё это серьезно осложняет задачу получения ценности из данных.

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

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

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

И что, например, поле business_dttm во всех time-series таблицах является первичным ключом партиции и имеет тип timestamp с таймзоной UTC, а колонка product_id во всех таблицах означает одну и ту же сущность (по крайней мере, в рамках одного бизнес-домена, но это уже отдельная история).

Так они совершат меньше ошибок и зададут вам меньше вопросов. Особенно, если среди них есть неискушенные бизнес-пользователи, а у вас self-service BI.

⁉️ Так как же мы решили этот кейс?

Поскольку date, в отличие от datetime, нельзя конвертировать в наш стандартный часовой пояс, то надо явно дать понять пользователю о нестандартной ситуации. И если мы называли поле с датой business_date, то это назвали business_date_pacific_time.

💬 А как бы сделали вы? Пишите в комментариях) И если у вас были похожие истории — тоже обязательно поделитесь!

📊 Simulative