Симулейтив

Как писать красивый код на Pandas

Одна из самых классных фишек Pandas, которой многие не пользуются — это method chaining или цепочки методов.

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

# Здесь у нас длинная строка с кучей методов - все в кашу
df.do().do_more().do_something_else()...

Вариант 2:

# Здесь каждое действие делается в отдельной строке
# так еще и лишнее переопределение df происходит
df = df.do()
df = df.do_more()
df = df.do_something_else()
...

А вот как пишут код на Pandas люди, которые шарят в Pandas и любят красивый код:

redistributed_orders_amount = (
    area_orders_agg.drop(columns="warehouse_name")
    .rename(columns={"preferred_warehouse": "warehouse_name"})
    .query("~is_local_delivery")
    .groupby(group_fields)["orders_amount"]
    .sum()
    .rename("redistributed_orders_amount")  
)

Этот код писал один из членов нашей команды, Даниил. Чтобы понять его на 100%, надо немного погрузиться в задачу и понимать Pandas, но одно можно сказать точно — это максимально красиво и удобно! Согласны?

Делается method chaining очень просто (в коде выше видно):

1. Вся последовательность команд оборачивается в скобки;
2. Каждая новая операция переносится на новую строку.

А если ещё красиво оформить отступы (как в примере), то вообще будет отлично! В основном, IDE, в которой вы пишите код, делает это за вас.

Как вам такой метод? Ждём 🔥

➡️ Ну а если хотите еще лучше разбираться в Pandas — присоединяйтесь к нам в бесплатном курсе! Регистрация: simulative.ru/pandas

📊 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

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

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

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

📊 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

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

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

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

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

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

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

📊 Simulative

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

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

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

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

📊 Simulative

А мы продолжаем наш Q&A с Настей Кузнецовой!

Вопрос:

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

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

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

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

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

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

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

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

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

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

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

📊 Simulative

Вопрос:

Как понять, что хочет увидеть в дашборде заказчик, если он сам этого не понимает и не может объяснить?

Очень хороший вопрос! Помогут разные техники user discovery, когда мы пытаемся самостоятельно «стать заказчиком» и попробовать понять с его стороны, что же нужно.

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

Из фреймворков — это подходы JTBD (jobs to be done), user persona, user story. Это как представить себе, что вы запускаете новый продукт и пытаетесь найти нишу и product market fit — для кого же будет этот продукт и какие проблемы он будет решать.

Вопрос:

Всегда мучает вопрос, что делать со stacked bar chart, где много категорий.

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

Есть ли альтернативные способы визуализации для таких кейсов? Как правильно подобрать цвета, чтобы категории отличались, но это не выглядело паршиво?

Всё зависит от задачи. Супер-редко, когда нужны прям все категории — обычно мы можем сгруппировать основные в топ-5 и остальные положить в «другое». Если заказчик просит уместить всё, то стоит посмотреть, а как же с этим графиком работают и какие выводы пытаются получить. Часто такие графики просто дополнительно фильтруют и поэтому дефолтное состояние с кучей категорий не так пугает.

Из альтернативных способов визуализации:
— Хитмап + его можно скомбинировать с графиком динамики ровно над ним. Так можно будет посмотреть и общий тренд, и каждую категорию и её долю/значение отдельно;
— Разбить график на много маленьких. Это может быть small multiples (его ещё называют треллис-график) или таблица со спарклайнами — когда вы показываете столбиком общие значения по категории и рядом спарклайн с динамикой.

Собирала ещё решения для спагетти-графиков тут, часть подойдёт и для этого кейса.

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

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

📊 Simulative

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

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

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

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

📊 Simulative