😶🍏🍏🍏😶
😶🍎🍎🍎😶
😶🍏🍏🍏😶

Отлично, вы рассортировали яблоки по контейнерам! А теперь сортируем данные с помощью ORDER BY:

https://simulative.ru/blog/sql-order-by

📊 Simulative

Команда Simulative на связи! 🚀

Напоминаем: у нас есть бесплатный курс «Основы SQL» — отличный способ разобраться с базой и наконец подружиться с данными.

SQL — это навык, который сегодня нужен почти всем, кто хоть немного работает с цифрами. Без него не обойтись ни аналитикам, ни маркетологам, ни продактам: 87% вакансий в аналитике требуют знания SQL. А специалисты, которые умеют быстро извлекать и анализировать данные, зарабатывают в среднем на 30-50% больше.

На курсе вы:
🟠 Разберётесь с основами SQL — от простых запросов до оконных функций;
🟠 Пройдёте 70+ практических задач в PostgreSQL;
🟠 Сделаете свой первый мини-проект: проанализируете активность пользователей.

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

Всё обучение — онлайн и бесплатно. Доступ открывается сразу после регистрации.

➡️ Зарегистрироваться на бесплатный SQL

📊 Simulative

Из каких сфер чаще всего приходят в ML-инженеры?

Привет! Кристина Желтова на связи ✨

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

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

Самый очевидный и наиболее успешный путь перехода — из аналитиков в ML-инженеры. У дата-аналитиков уже, как правило, есть опыт работы с данными, навыки SQL и python, понимание статистики и A/B-тестирования, а также самое ценное — аналитическое мышление.

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

Еще одна хорошая тропа перехода — из разработчиков или дата-инженеров в ML-инженеры. Подобные специалисты обычно обладают сильными инженерными навыками — умением писать «чистый» эффективный код, работать с Git, CI/CD, контейнеризацией, пайплайнами и прочими production-практиками. Разработчикам необходимо доучить, как минимум, статистику и алгоритмы ML, хотя также сложившаяся техническая база позволяет быстро освоить MLOps и перейти в эту профессию.

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

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

⚡️ 15 октября на вебинаре соберём пошаговый план перехода в профессию ML-инженера. Я расскажу, какие навыки и технологии будет полезно освоить людям из других направлений, а также покажу, как перейти от теории к решению проблем бизнеса.

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

📊 Simulative

Мой путь в SQL: от SELECT * и боли до архитектуры

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

Многие спрашивают, как я начинал свой путь в SQL, и этот пост как раз об этом)

Изначально я не мечтал быть DBA или аналитиком. Познакомился с SQL случайно на первой работе, после окончания университета, нужно было вытаскивать данные из пары таблиц БД и делать отчёты в Excel. Знал только SELECT * FROM table — и думал, что это и есть вся база.

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

И начался ад.

Срочные отчёты для руководства, дедлайны, нехватка знаний для быстрой выгрузки данных из БД, а ещё же надо было потом всё это обрабатывать в Excel. Тогда я сильно нервничал и буквально жил на работе. Писал запросы на 100 строк без нормальных JOIN (только подзапросы), не знал, что такое CTE, думал, что GROUP BY — это для красивой группировки, и прочие прелести начинающего специалиста.

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

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

➖ Учил синтаксис, а не логику. Зубрил CASE, WINDOW FUNCTIONS, но не понимал, как данные связаны. Сейчас я рисую ER-диаграммы даже для простых задач, связанных с отчётностью. Да, на это тратится какое-то время, но зато и я и коллеги понимают, как работает код.

➖ Боялся production. Думал, а вдруг сломаю? Потом понял — без боевых условий не научишься. Начал с малого — перед запуском запросов читал их explain-план.

➖ Думал, что красивый отчёт = хороший анализ. Составлял дашборды с кучей графиков, но не проверял, откуда берутся метрики. Однажды выяснилось, что уникальные пользователи считались по COUNT(user_id), а не COUNT(DISTINCT user_id). После решил — любую метрику сначала верифицирую на сырых данных, а потом уже визуализирую.

➖ Не задавал вопросы заказчику отчёта. Делал отчёт по ТЗ, но не уточнял, что за этим числом стоит. Выяснилось, что метрика «Активные пользователи» для маркетинга — это однодневные заходы, а для продукта 7-дневные.

➖ Хранил запросы в клиенте СУБД. Однажды потерял критически важный скрипт перед дедлайном. Теперь всё в Git, даже временные запросы. И даю файлам нормальные имена, пишу документацию.

Как принимал решения? На первых порах — по боли:

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

Дальше решал по принципу «максимальный рычаг» — что даст больше роста за единицу времени? Например, изучить оконные функции и читать execution plan — и таким образом сразу ускорю отчёты.

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

И напоследок. Мой путь — не линейный. Были проекты, где я ломал продакшн (да, такое было). Были месяцы, когда казалось: всё уже изучил. А потом приходил новый кейс — и снова ноль. Путь был сложным, и он продолжается до сих пор.

Главное — не переставать учиться.

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

💎 Записаться на продвинутый SQL до 17 октября

📊 Simulative

4 «подводных камня» на пути аналитика

Всем привет, на связи Александр Грудинин, Lead Data Analyst в компании AdTech Holding и ментор курса «Аналитик данных».

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

1️⃣ Перестройка мышления

Самое сложное — начать видеть за метриками бизнес, а не просто числа в таблице.

Студент научился считать метрики, видит, что CR просел на 5%, но не может объяснить, что это значит для бизнеса, какие гипотезы проверить и что с этим делать. Именно этот переход от технического к бизнес-мышлению даётся далеко не сразу.

2️⃣ SQL и мышление таблицами

В жизни любого аналитика рано или поздно появляются JOIN’ы, и в чате появляется знакомое сообщение: «Я всё понял… пока не попробовал объединить таблицы».

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

3️⃣ Понимание данных перед анализом

Часто студенты сразу набрасываются на данные, не разобравшись, как вообще они устроены: какие есть пограничные случаи (corner cases), пропуски, странные значения, какая логика формирования витрин данных и т. п.

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

4️⃣ Оптимальный код

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

Кто-то пишет подзапросы в подзапросах, и бывает, что до последнего не агрегируют данные или, делая аналитику за последние 30 дней, тянут данные на всю глубину таблицы. Потом всё это крутится минутами, а иногда и падает.

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

✨ Эти сложности можно преодолеть на нашем курсе «Аналитик данных» — есть структурированная программа с реальными бизнес-кейсами и поддержка ментора. Врывайтесь в обучение со скидкой, которая действует до завтрашнего дня!

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

📊 Simulative

⬆️ А мы напоминаем, что через пару часов, в 19:00 по МСК ждём вас на вебинаре «Как построить карьеру в ML»!

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

📊 Simulative

Data Engineer: почему эта профессия сегодня востребована как никогда

Привет! На связи Георгий Семенов, ментор курса «Инженер данных».

Рынок IT в последние пару лет переживает настоящий бум спроса на инженеров данных (DE) — специалистов по надёжному хранению и качественной и своевременной обработке данных. Особенно когда речь идет про big data.

Я работаю в этой индустрии уже больше 7 лет, в CTC, Wildberries, VK, Яндексе, и наблюдаю это всё своими глазами.

А вы можете просто посмотреть на зарплатный дашборд от Ромы Бунина. Невооруженным глазом видно, что распределение зарплат инженеров данных находится на одном уровне с ML/DS и значимо выше, чем у аналитиков. Это подтверждают и самые свежие данные Хабр Карьеры (раздел про зарплаты аналитиков).

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

Почему сейчас?

🟠 Бурный рост AI требует качественных данных и процессов.
🟠 Все, от бигтехов до кофеен, стремятся быть data-driven.
🟠 Чатбот-аналитики растут как грибы, но заменить DE сложнее.

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

Какие навыки обычно требуются в работе?

👑 Читать, писать и оптимизировать код на SQL или Python.
👑 Создавать ETL/ELT-процессы с помощью Airflow и Spark.
👑 Знать нюансы работы различных СУБД и платформ данных.
👑 Разбираться в моделях данных и архитектурах хранилищ.

Data Engineering — это ваш шанс на стабильную, высокооплачиваемую и перспективную карьеру в IT. Готовы сделать шаг в будущее? Тогда самое время действовать!

➡️ Забронировать место со скидкой 25%

📊 Simulative

Как делать понятные визуализации в Python: принципы, инструменты и практика

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

На вебинаре разберём, как делать такие визуализации в Python. Вместе с Александром Грудининым, Lead Data Analyst в AdTech Holding, вы познакомитесь с ключевыми принципами визуализации и попробуете ключевые библиотеки на бизнес-кейсах.

Что узнаете на вебинаре:
➡️ Когда аналитикам стоит использовать Python для визуализации, а когда хватит Excel или BI-систем;
➡️ Основные принципы хорошей визуализации: подписи, цвета, легенды, масштаб;
➡️ Как выбрать тип графика под задачу и данные;
➡️ Ключевые библиотеки Python для визуализации — pandas, matplotlib, seaborn, plotly;
➡️ Примеры визуализаций из реальных бизнес-кейсов.

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

💬 Подключайтесь в прямой эфир, чтобы разобраться в визуализации данных и попробовать всё на практике!

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

📊 Simulative

5 ошибок новичков на пути в ML-инженеры

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

ML-инженеры в начале своего профессионального пути часто сталкиваются с одними и теми же ловушками. Зная их заранее, вы сможете выделиться из массы кандидатов и сэкономить время на прокачку.

1️⃣ Избыточная вера в сложные алгоритмы и пренебрежение простыми бейзлайнами

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

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

2️⃣ Недостаточное погружение в правила выбор метрик качества

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

3️⃣ Переобучение и ошибки в схеме валидации

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

4️⃣ Отсутствие планирования экспериментов

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

5️⃣ Слишком узкий выбор стека

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

☝🏻 Избегайте этих ошибок, и ваш путь к профессии ML-инженера станет более гладким и результативным!

➡️ Забронировать место на курсе «ML-инженер» со скидкой 15%

📊 Simulative

После этой статьи (надеемся) вы разберётесь, чем отличаются разные алгоритмы машинного обучения:

https://simulative.ru/blog/algorithms-ml

📊 Simulative

Вебинар: как дата-инженеру проектировать хорошие ETL/ELT-процессы

ETL/ELT-процессы (они же пайплайны) — основа любой дата-инженерной системы. Именно пайплайны собирают и превращают сырые данные в структурированную информацию, на которую опираются аналитики и бизнес. Но как спроектировать процесс правильно, чтобы данные поставлялись стабильно, а пайплайны не ломались при каждом изменении на стороне источника?

На вебинаре c Георгием Семеновым разберём ключевые подходы к построению пайплайнов — разберем батч и стриминг, сравним ETL и ELT, а также посмотрим, как работают инструменты оркестрации вроде Airflow и Dagster. Поговорим о важных инженерных деталях — партицировании, бэкфиллах, контрактах и тестах — и покажем, из чего складываются надёжные дата-процессы в крупных компаниях.

Что вы узнаете:
➖ Как устроен путь данных — от источников до аналитических витрин;
➖ Чем отличаются стриминг и батч, ETL и ELT, и когда какой применять;
➖ Какие инструменты помогают строить пайплайны — разберём Airflow и Dagster;
➖ Какие нюансы важно учитывать: партицирование, бэкфиллы, контракты, тесты;
➖ Как спроектировать надёжный и легко поддерживаемый пайплайн.

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

💬 Подключайтесь к эфиру, чтобы задать Георгию вопросы про архитектуру данных, ETL/ELT и тонкости построения стабильных пайплайнов!

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

📊 Simulative

Бесплатный курс «Основы Python» — старт для тех, кто хочет разобраться с языком с нуля 🐍

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

Если вы пока только копите советы из интернета, самое время перейти к системному изучению. На курсе вы:

🟠 Начнёте с простого и шаг за шагом дойдёте до практических задач.
🟠 Научитесь автоматизировать типовые процессы — от проверки отчётов до выгрузки данных.
🟠 Получите поддержку и сможете задать вопросы в чате.
🟠 А ещё получите доступ к дополнительным материалам и реферальной программе!

🖱 Курс уже прошли более 1500 человек — присоединяйтесь и сделайте Python своим инструментом роста!

🔗 Зарегистрироваться бесплатно

📊 Simulative

📊 Почему графики не работают (и как это исправить)

Привет, аналитики! Ментор потока «Аналитик данных» Александр Грудинин на связи 😉

Иногда смотришь на дашборд и понимаешь, что ничего не понимаешь 😄 Или тратишь часы на создание визуализации, которую в итоге никто не смог интерпретировать…

Проблема не в данных. Проблема в том, что график не соответствует задаче.

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

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

🟠 Нужно показать, как менялись показатели во времени, а выбирается bar chart вместо линейного графика. Тренд размывается.

🟠 Сравниваете пять категорий и используете pie chart. Глаз не различает доли точно, особенно если их больше трёх.

🟠 Хотите показать взаимосвязь двух переменных и теряетесь между таблицей и столбцами, хотя scatter plot справился бы за секунды.

🟠 Нужно понять распределение данных, а опять строится обычный bar chart, который скрывает всю картину. Гистограмма или boxplot (ящик с усами) дали бы гораздо больше информации.

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

На ближайшем вебинаре, который я проведу 21 октября, разберём:

➡️ Когда аналитикам стоит использовать Python для визуализации, а когда хватит Excel или BI-систем;
➡️ Основные принципы хорошей визуализации: подписи, цвета, легенды, масштаб;
➡️ Как выбрать тип графика под задачу и данные;
➡️ Ключевые библиотеки Python для визуализации — pandas, matplotlib, seaborn, plotly;
➡️ Примеры визуализаций из реальных бизнес-кейсов.

Вы научитесь выбирать тип графика осознанно — под конкретные данные и задачу. Без гаданий, без перебора вариантов.

Регистрируйтесь и узнайте, как превратить данные в понятную историю, которую увидит каждый! 👇

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

📊 Simulative

Проблемы снэпшотов: не все данные одинаково полезны

Приветствую! Георгий Семенов, ментор потока «Инженер данных», на связи 👋

Ты — Data Engineer. Перед тобой стоит задача: ежедневно собирать из внешнего сервиса статистику по рекламным кампаниям твоих клиентов (дальше будем называть РК).

У сервиса есть два метода API:

🟠 /adv_list возвращает список всех РК и их статусы на момент запроса (aka снэпшот). На вход принимает ID клиента.
🟠 /adv_stat возвращает статистику по РК за указанный день. На вход принимает ID РК и дату.

Однако у клиентов много РК в статусе «неактивный», по которым не бывает статистики за день. А нам не хочется делать лишние запросы к API — есть лимиты, которые сильно замедляют процесс. Для иллюстрации: у одного клиента 150 активных РК и 1750 неактивных. Активные мы грузим за 5 минут, а все вместе — час. Поэтому хотим запрашивать статистику только по активным РК.

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

Проблема №1. Если РК будет активной в течение дня, но станет неактивной, когда мы придём за данными, то мы не получим статистику по этой РК за этот день, хотя она есть.

Проблема №2. Допустим, что-то пошло не так и загрузка сломалась, а мы заметили это только через несколько дней. Естественно, мы хотим залить провалы за эти дни, чтобы статистика была полной. Но /adv_list вернёт только текущие статусы.

Благо, в твоём случае нашлось неплохое решение. Метод /adv_list возвращает не только текущий статус, но и таймстэмп последнего изменения РК. Поэтому для загрузки статистики за пропущенные даты ты можешь отобрать РК по следующему условию:

статус = "активный" или последнее изменение >= {дата_провала}

Иначе тебе пришлось бы выбирать между сильным снижением скорости импорта и потенциальной частичной потерей данных.

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

🤔 Если вы не до конца поняли пост, или наоборот, поняли, и хотите узнать ещё про разные виды датасетов, партицирование, бэкфиллинг и другие приколы процессов обработки данных — жду вас завтра, 22 октября, на моём бесплатном вебинаре.

P. S. Можно усложнить решение задачи, чтобы ещё сильнее уменьшить потенциальное количество запросов к /adv_stat. Пишите свои варианты в комментариях.

📊 Simulative