Симулейтив

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

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

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

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

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

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

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

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

#проанализировали_и_поняли

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

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

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

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

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

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

📈 Симулейтив | 📱 ВК | 📱 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#проанализировали_и_поняли

13 сентября — день айтишника. И да, это не повод дарить ежедневник с принтом «SELECT * from users» ☺️

Мы в Симулейтив против шаблонных поздравлений. Собрали чек-лист главных ошибок при поздравлении айтишника — и что сказать/сделать вместо них, чтобы это не звучало как открытка из 2000-х.

Листайте карточки ⬆️

Поздравляем вас, дорогие аналитики! С днём тех, кто действительно понимает, что происходит в БД и проде 🧡

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

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

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

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

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

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

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

💻 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

💻 Конвейер данных

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

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

Ценность аналитики заключается в том, что представитель бизнеса может принимать решения на её основе.

А для этого данные следует прогнать через несколько процессов и стадий. Я называю этот путь конвейером данных.

Конвейер данных включает в себя следующие основные этапы:

1️⃣ Формирование вопросов

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

2️⃣ Сбор данных

Сырые, необработанные данные собираются из источников в аналитическое хранилище (АХ), где и производится всяческая аналитическая «магия».

В качестве АХ могут использоваться различные системы управления базами данных (СУБД), например, Clickhouse или PostgreSQL.

Запросы к СУБД выполняются на языке SQL. А процессы сбора и транспорта данных осуществляются специальными инструментами, например, Airflow, который «дирижирует» Python-скриптами.

3️⃣ Преобразование данных

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

С данными производятся операции фильтрации, объединения, расчета, приведения к нужному виду и т.д. Обычно для этого используются языки SQL или Python.

4️⃣ Визуализация

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

Визуализация делается с помощью соответствующих инструментов: Power BI, Data Lens, Looker Studio, Metabase и др.

5️⃣ Анализ

Собственно, процесс изучения, осознания ситуации, а также формирования выводов, ответов на поставленные вопросы.

Рассчитанные метрики сопоставляются с некими желаемыми эталонами, изучаются тренды, обнаруживаются и обосновываются выбросы, проседания и т.д.

6️⃣ Решение

На основе выводов решается, достигнуты ли цели, что делать дальше, работает ли новая фича и т. п.

Путь данных весьма насыщен приключениями и этим он интересен!

50 ❤️ — и расскажу, с какими вызовами может столкнуться дата-аналитик в реальной работе!

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

Как подать себя на собеседовании? 5 советов от того, кто провёл 162 интервью за год

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

За прошлый год я отсмотрела 500+ резюме и провела 162 собеседования на позиции продуктовых аналитиков. И вот что скажу: чаще всего кандидаты проваливаются не потому, что чего-то не знают. А потому что забывают показать главное — как они думают.

Ниже 5 советов, как подать себя на собеседовании:

1️⃣ Не бросайтесь решать задачу с наскока

Почти на каждом интервью вам дадут мини-кейс, где намеренно мало вводных. Это не забывчивость интервьюера — это и есть задание. Сильный кандидат сразу замечает пробелы и начинает с вопросов:
➖ О каком продукте и сегменте пользователей речь?
➖ Какую метрику мы считаем целевой и за какой период?
➖ Что уже известно, а что придётся допустить?

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

2️⃣ Думайте вслух

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

3️⃣ Нейронки и гугл — не читерство

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

4️⃣ Светлый ум не отменяет хардов

Умение думать слабо связано с грейдом: бывают джуны, которые структурируют мысль лучше сеньоров. Но встроить в команду человека, который не пишет код, — боль для всех. Так что SQL, Python и статистика всё равно должны быть в форме: подготовьте оконные функции, дизайн A/B-теста и разбор метрик до автоматизма.

5️⃣ Резюме — это уже первый этап собеседования

Из большинства резюме понятно только одно: человек работал работу. Какие задачи были важны и что изменилось благодаря аналитику — загадка. А задача аналитика не в том, чтобы собрать побольше дашбордов или закрыть побольше тикетов. Задача аналитика — заставить данные заработать деньги. Пишите не «строил отчётность», а «перевёл команду на единый источник правды, ad-hoc-запросы сократились на треть».

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

Ставьте 🔥 и сохраняйте к себе!

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

#проанализировали_и_поняли

💻💻💻💻💻 Профессия инженер данных: строим витрину продаж с нуля

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

6 сентября вместе с Юрием Ламиховым, дата-инженером в Wildberries, за час пройдём путь от теории до практики: разберём профессию по уровням и вживую соберём витрину продаж на dbt.

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

🧑🏻‍💻 Спикер: Юрий Ламихов, дата-инженер в Wildberries

📆 Когда: 6 сентября, 18:00 МСК
➡️ Регистрация

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

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

Время учиться аналитике!