🎯 3 задачи, после которых ты точно не скажешь "я аналитик-любитель"

Хочешь проверить, джун ты или уже почти бог дата-инженерии? Погнали:

▪️Junior
Классика: найди тех, у кого >3 заказа за 30 дней.
Фильтрация, группировка, агрегация — ну ты понял.
Если не понял — точно джун

▪️Middle
Когортный анализ.
Pivot, даты, удержание — тот случай, когда таблицы становятся интригой.
Почувствуй себя аналитиком стартапа на грани успеха.

▪️Senior
Pydantic, валидация, conint(gt=0) — кайф для тех, кто любит, чтоб всё чётко.
Если ты валидировал хоть раз JSON на проде — ты в клубе.

💸 Поддержать канал и скачать .ipynb можно уже с шаблонами, проверками и баллами - тут 😌

Сделал — респект.
Завтыкал — попробуй ещё.
В любом случае: весело, больно, по-настоящему.

👉 Senior Data Analyst | #python

🧠 Почему аналитик должен знать Airflow
Или как перестать быть ручным исполнителем скриптов

▪️Cron — это не автоматизация. Это ловушка.
Ты вроде бы всё настроил, но…
— логов нет
— ретраев нет
— зависимости мимо
— мониторинг — руками
— и вообще непонятно, что пошло не так 😵‍💫
В итоге аналитик вручную запускает скрипт, потому что «крон опять не сработал».

▪️ Что даёт Airflow?
Airflow — это не просто планировщик, а полноценная система исполнения задач. Он:
• понимает зависимости (запусти шаг 2 только после успешного шага 1)
• оборачивает код в управляемые блоки (Python, Bash, SQL — на выбор)
• даёт отладку и мониторинг (UI, stacktrace, перезапуск одной задачи)
• хранит историю запусков (можно посмотреть, что падало месяц назад)
• дружит с расписаниями и шаблонами (@daily, {{ ds }})

▪️ Что можно автоматизировать
Не только ETL, но и:
• выгрузки и пересчёты
• алёрты по данным
• обновление отчётов
• ML-пайплайны
• проверки и напоминания

💸 Поддержать канал
👉 Senior Data Analyst | #python

Зачем вообще DAG для Pandas?

У каждого аналитика есть «та самая папка со скриптами».
API, Excel, выгрузки, подсчёты, пересчёты — всё вручную. Потом через cron. Но если честно — пора переходить на DAG.

Этот пример показывает, как из ручного ETL сделать стабильный, управляемый и приятный пайплайн, который:
• выполняется по расписанию
• логирует каждый шаг
• сохраняет результат по структуре
• валится с ошибкой, если что-то пошло не так
• и вообще выглядит по-взрослому

Как устроен код?

1️⃣ fetch_data
Качает данные из https://dummyjson.com/products
→ Превращает JSON в pandas.DataFrame
→ Сохраняет как data/raw/products_<ds>.csv
→ Использует дату из контекста (context["ds"]) — то есть работает "по календарю"

2️⃣ process_data
→ Читает csv, считает price_with_tax
→ Сохраняет результат в data/processed/products_cleaned_<ds>.xlsx
→ Демонстрирует, как можно обрабатывать данные Pandas внутри DAG

3️⃣ DAG
→ Запускается ежедневно (@daily)
→ Использует PythonOperator
→ Передаёт дату через контекст (магия, но понятная)


▪️ Структура данных выглядит вот так:

/opt/airflow/data/
├── raw/
│   └── products_2025-07-22.csv
└── processed/
    └── products_cleaned_2025-07-22.xlsx

Чёткое разделение на raw и processed
Можно вернуться к исходнику, пересчитать, проверить. Красота.

▪️Почему это лучше, чем просто скрипт fetch_and_process.py?
Ну смотри, что ты получаешь с Airflow:
• Ретрай, если API временно отвалился
• Контроль за успехом выполнения
• Отправку алёртов, если что-то пошло не так
• Удобный UI — наглядно видно, что работает, а что нет
• Логи — по каждому шагу, с ошибками, stacktrace и временем

И всё это — автоматически. Просто потому что ты перешёл от «файлика» к DAG.

▪️Как адаптировать под свои задачи?
Airflow гибкий. Меняешь куски — и вуаля:
• вместо Excel → пишем в ClickHouse, PostgreSQL или в облако
• вместо API → читаем Google Sheets, S3, базы
• вместо Pandas → ставим Polars или SQLAlchemy

DAG — это про структуру.

▪️А что насчёт прикладной аналитики?
Вот реальные кейсы:
• Парсинг прайс-листов → автоматическая сводка изменений
• Проверка API магазинов → алёрт, если скидки исчезли
• Сводка по REST-запросам → Excel-отчёт или сообщение в мессенджер

Всё, что раньше делалось вручную — теперь живёт в пайплайне. И ты не вспоминаешь про него, пока не придёт алёрт.

▪️Главный вывод
Airflow — это не только для big data и дата-инженеров.
Это про предсказуемость, контроль.

Если ты один раз скачал и обработал файл — да, это скрипт.
Но если ты делаешь это каждый день — это уже DAG. И его пора так оформить.

💥 Как тебе ?
🔥 — узнал(а) что-то новое
🤝 — темы хорошо знакомы

💸 Поддержать канал
👉 Senior Data Analyst | #python

Продолжение следует....

🧠 Python для аналитиков: if, elif, else — без боли
Когда «управление логикой» звучит не как философия, а как реальный навык

Это первая серия модуля 3 — и она про то, как писать условия, не превращаясь в программиста 2008 года.

Что внутри:
→ на пальцах объясняем, как работает if, elif, else
→ 10 примеров с комментариями: от “число положительное?” до “если всё сложно, делай красиво”
→ практическое задание: определяем возрастную категорию
→ советы и фейлы: как не закопаться в условиях и не получить else: print('что-то пошло не так')
→ реальный кейс: расчёт налога по типу дохода, возрасту и льготам — пригодится даже в жизни

Это не учебник. Это фундамент.
После этой серии if перестанет быть пугающим, а начнёт работать на вас.

💸 Поддержать канал и скачать серию можно здесь
📣 И да, поставь реакцию за старание

👉 Senior Data Analyst | #python #модуль_03 #серия_01

🧠 Зачем вообще SQL-функции, если можно просто написать SELECT?

На ранних этапах всё просто: CASE WHEN, пара JOIN-ов, и ты доволен.
Но с ростом проекта — и твоим опытом — появляется ощущение, что код начинает душить.

Когда проект растёт, вместе с ним растёт и боль:
• дублирующаяся логика
• громоздкие CASE WHEN
• правила, разбросанные по десяткам CTE
• метрика меняется — ты бегаешь по скриптам с огнетушителем

Вот тут и заходят на сцену SQL-функции (UDF).
Они позволяют вынести логику в одно место. Изолированно. Переиспользуемо. Как функции в коде, только внутри БД.

▪️ Какие бывают функции в PostgreSQL?
• Скалярные
normalize(score, avg, sd) → возвращают одно значение
Используются в метриках, флагах, категоризациях

• Табличные
top_n_per_category(n) → возвращают таблицу
Удобны для создания витрин и кастомных выборок с параметрами

• Агрегатные
my_median(val) → агрегируют значения
Нужны, если стандартных агрегатов мало или не подходят


▪️Реальные кейсы
1️⃣ Категоризация пользователей
Было: CASE WHEN spend > 10000 AND visits > 5 THEN 'VIP' ...
Стало: customer_segment(spend, visits)
→ читается, тестируется, правится в одном месте

2️⃣ Флаг аномалии

is_outlier(val, avg, stddev)

→ можно использовать в WHERE, CASE, JOIN, даже в dbt-тестах

3️⃣ Параметризуемая витрина

SELECT * FROM top_n_per_category(3)

→ больше не пишешь ROW_NUMBER вручную в каждом скрипте

▪️IMMUTABLE, STABLE, VOLATILE — важнее, чем кажется
• IMMUTABLE — всегда даёт одинаковый результат при одних и тех же аргументах
→ используется для расчётов (abs(x), normalize(...))

• STABLE — может читать таблицы, но не меняет данные
→ подходит для SELECT ... WHERE id = x

• VOLATILE — может вести себя непредсказуемо
→ random(), now(), count(*)

Если не указать тип, PostgreSQL подставит VOLATILE, и оптимизации не будет. А это уже тормоза.


▪️Тестирование UDF
Функции можно (и нужно) тестировать:
• pgTAP — юнит-тесты прямо в PostgreSQL
• ручные тесты через begin...end
• автотесты через CI: пушнул код — сравнил результат

SELECT customer_segment(11000, 6) = 'VIP' AS test_1;

▪️Как устроено в проде
1. Версионирование
segment_v1, segment_v2, segment_active
→ переключаешь alias, не ломаешь пайплайн

2. Интеграция с dbt и Airflow
→ в dbt — используешь как обычную функцию
→ в Airflow — вызываешь в PostgresOperator

3. Документация
→ COMMENT ON FUNCTION внутри тела
→ changelog логики — в доках проекта


▪️Типичные ошибки

• писать скалярную функцию, которая делает SELECT
→ это отдельный запрос на каждую строку → тормозит

• не указывать IMMUTABLE или STABLE
→ теряется кеш, растёт нагрузка

• изменять функции без версионирования
→ одно изменение — и всё падает

• писать гигантские UDF без профилирования
→ сложно читать, плохо оптимизируется

▪️Вывод

SQL-функции — про стабильность, переиспользуемость и контроль.

Они дают тебе одно: уверенность, что логика работает так, как ты задумал. И что её не нужно чинить каждую неделю.

💸 Поддержать канал
👉 Senior Data Analyst | #sql

🧠 Погнали разогревать мозги — задачи ждут!

Если и есть день для чётких решений — это сегодня. Среда, энергия есть, мозг включён!

💸 Поддержать канал
👉 Senior Data Analyst | #матстат #теорвер

🔵 Задача №1: Среднее или медиана?
Математическая статистика

Доходы в выборке (в рублях):
40 000, 42 000, 43 000, 44 000, 2 000 000

Какую метрику лучше использовать — среднее или медиану? Почему?

Разбор:
Среднее = (40к + 42к + 43к + 44к + 2млн)/5 ≈ 442 000
Медиана = 43 000

✅ Ответ: медиану

Среднее сильно искажено выбросом (2 млн). В таких случаях для описания "типичного" дохода лучше использовать медиану.
Это основа устойчивости статистик — всегда проверяй выбросы перед расчетом среднего!


🔵 Задача №2: Доверие к результату
Математическая статистика

Вы провели A/B-тест:
• Группа A: 5000 юзеров, конверсия — 5%
• Группа B: 100 юзеров, конверсия — 6%

Можно ли сказать, что B лучше?

Разбор:
Повышение есть (5% → 6%), но выборка в B слишком мала, чтобы делать вывод.

✅ Ответ: Нет, нельзя
Для вывода нужна статистическая значимость. При малом размере выборки возможна случайная флуктуация.
Хорошая практика: сначала убедись, что выборка достаточна, потом — смотри на конверсии и p-value.


🔴 Задача №3 : Монетка и игральный кубик
Теория вероятностей

Сначала подбрасываем честную монету.
Если выпал орёл — бросаем кубик один раз.
Если решка — бросаем кубик дважды и берём сумму.

Какова вероятность, что в итоге получим число 6?

Разбор:
Делим на 2 сценария:
1. Орёл → 1 бросок → P(выпадет 6) = 1/6
2.Решка → 2 броска → сколько комбинаций даёт сумму 6?

Варианты:
(1,5), (2,4), (3,3), (4,2), (5,1) — 5 из 36

Общий ответ:
P = 0.5 × (1/6) + 0.5 × (5/36) = (3/36) + (5/72) = 0.2083… ≈ 20.8%

✅ Ответ: ≈ 20.8%
Тут важна комбинация условной и полной вероятности, учитывая разные сценарии.


🔴 Задача №4 : День рождения в команде
Теория вероятностей

В команде из 23 человек — какова вероятность, что у хотя бы двух день рождения в один день?
(Принять 365 дней в году, игнорируем високосные)

Разбор:
Эта задача известна как парадокс дня рождения.
Вместо прямого счёта — удобнее посчитать обратное событие:
P(все разные) ≈ 0.493
365/365 × 364/365 × 363/365 × ... × 343/365 ≈ 0.4927
Шанс, что все 23 дня рождения разные → 49%

Но, нас-то интересует обратное событие —
что хотя бы у кого-то дни рождения совпадут:
→ P(хотя бы совпадение) = 1 – 0.493 = 0.507


✅ Ответ: ≈ 50.7%
Парадокс: всего 23 человека, а шанс совпадения уже больше 50%!
Классический пример, где человеческая интуиция сильно ошибается.