Новая поляна

Всем привет! Недавно я обещал рассказать о том, куда я ухожу после Яндекса. Думаю, время настало, так как я успел отработать 5 дней 🥳

Я ушел Sr продуктовым аналитиком в рекламную платформу в WB 🛒.

По первым впечатлениям, все заходит и стек похож очень сильно на 💙, чему я очень сильно рад. Мне интересно написать будет про оптимизацию запросов, различные технологии (ближе к DE), планирую опубликовать пилотный пост, если зайдет, то в эту сторону тоже будем двигать!

По стеку: ClickHouse, Trino, SuperSet, Spark, HDFS, JupyterHub, GitLab.

Задач, которые можно тут сделать большое количество (как и везде в принципе, всегда найдется время что-то поделать): от базовой отчетности и исследований до реализации методологии A/B тестирования. Делать есть что и есть где развернуться 💻

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

Сейчас я поступаю в магистратуру. Предварительно сдал большее количество вступительных испытаний (5+, без учета конкурсов портфолио). Если отдельно интересна эта тема, ставьте реакции (🐳 киты важно!). Скажу, как выбирал, почему рассматривал.

Делитесь в комментариях, кем и где работаете, чем занимаетесь, интересно понимать, где вы сейчас!

💫 Spark для аналитика (ч. 1)

Раньше в 💙 я работал немного со Spark, большая часть задач спокойно решалась внутри одной БД или выгрузкой в pandas.

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

🥳 Как я использую сейчас

1. Собираю данные из разных источников
В реальных задачах часто нужно объединять сразу несколько источников: выгрузки из разных баз, parquet и тд. Пока всё влезает в pandas - норм, но когда данных слишком много, pandas начинает падать. Spark позволяет легко подтянуть все необходимые источники и собрать их в одну большую таблицу, не заботясь об ограничениях памяти.

2. Выполняю тяжёлые вычисления и агрегации
После того как все данные собраны, начинаются подсчеты метрик по большим объёмам данных. Здесь Spark выигрывает за счёт распределённых вычислений: вся тяжёлая работа идёт на кластере, а не на ноутбуке. Как только нужные агрегаты посчитаны, можно забрать результат и уже дальше анализировать, строить графики и т.д.

😍 Spark реально может работать дольше, чем pandas, если данных немного. Всё из-за архитектуры: Spark каждый раз поднимает распределённую систему, разбивает задачи на части, отправляет их на кластер и только потом собирает результат. Pandas же считает всё в оперативке и на небольших данных это быстрее почти всегда.

🔽Ниже прикрепляю основные функции для работы в Spark, которые я использую для решения задач аналитики

from pyspark.sql import SparkSession
from pyspark.sql.functions import avg, count

# запускаем Spark-сессию, тут еще можно закопаться в настройки приложения (если будет много 🐳, выложу) 

spark = SparkSession.builder.appName("zasql_python").getOrCreate()  # название приложения может быть произвольным

# читаем csv и кучу источников

df_csv = spark.read.csv("file.csv", header=True, inferSchema=True)
df_parquet = spark.read.parquet("file.parquet")
df_json = spark.read.json("file.json")

# джойним таблицы между собой

df_joined = df_csv.join(df_parquet, on="user_id", how="inner")

# фильтруем данные

df_filtered = df_joined.filter(df_joined["is_active"] == 1)

# применяем агрегирующие функции, считаем сумму строчек, среднее значение по заказам

df_grouped = (
    df_filtered
    .groupBy("country")
    .agg(
        count("*").alias("users_count"),
        avg("order_sum").alias("avg_order_sum")
    )
)

df_pandas = df_grouped.toPandas()

🐼 Очень похоже на pandas + можно в любой момент пересесть на spark.sql и писать в sql-формате любой запрос.

from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("zasql_python_sql").getOrCreate() # произвольное название приложения, должно быть другим, если запускаем параллельно

df_orders = spark.read.parquet("orders.parquet")  # читаем в Spark DataFrame первый источник источник
df_users = spark.read.csv("users.csv", header=True, inferSchema=True) # читаем в Spark DataFrame второй источник

df_orders.createOrReplaceTempView("orders") # создаем темповые таблицы заказов
df_users.createOrReplaceTempView("users") # создаем темповые таблицы юзеров

# теперь читаем тут в sql-формате

query = """
    SELECT 
        u.country,
        COUNT(DISTINCT o.user_id) AS active_users,
        AVG(o.order_sum) AS avg_order_sum
    FROM orders o
    JOIN users u ON o.user_id = u.user_id
    WHERE o.is_active = 1
    GROUP BY u.country
    ORDER BY avg_order_sum DESC
"""

result = spark.sql(query) # читаем в spark.sql, результат тот же получаем, но в SQL-формате
result.show() # показать значения, но можно перевести и в pandas, но ресурсов много сожрет

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

Ставьте 🐳, если хотите продолжение истории про Spark 💫

😋 Когда задачи кочуют из спринта в спринт

Всем привет! У кого в трекере задач был таск, который существовал бесконечно (по крайнем мере вам так кажется)?

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

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

❓ Как это выглядит на практике
1. Встречи проходят, а таска осталась на месте, никаких апдейтов не произошло.
2. Заказчик на вопрос "актуально ли?" отвечает что-то типа "ну, наверное, да…", но сам не уверен. Обычно вот тут нужно остановиться и спросить более конкретно про задачу, которую покрывает инструмент.
3. На стендапах появляется лёгкая неловкость (или часть людей в принципе не интересуются): все понимают, что задача висит, но почему - никто не знает. Было такое, что задача у смежного направления могла висеть и по 2-3 месяца, хотя по сути нужно было декомпозировать до более мелких задач и прокачивать видимость выполнения работы)
4. В голове включается голос (от тебя): "Может, со мной что-то не так?" — и начинается самокопание. Расслабься, попробуй посмотреть с холодной головой, что ты действительно сделал и почему вообще это было нужно.

😋 Что делать?
1. Декомпозировать. Разбиваю задачу на мелкие шаги. Вообще это может выглядеть вот так, если, например, задача - это собрать классный дашборд!

а) поговорить с заказчиком
б) собрать сырые данные
в) проверить метрики
г) собрать прототип
д) выкатить первую версию.
е) поддержка.

2. Фиксировать всё письменно. Заказчик сказал устно - завтра забудет. И да, спустя время это спасает, когда возвращаемся к болям, тут важно ее закрыть и все будет топчик.
3. Не бояться возвращать задачу. Если ТЗ меняется - переоткрываю и честно спрашиваю: "А что реально нужно?" Часто оказывается, что половину уже не надо или приоритеты поменялись.

В следующих постах вернемся к техническим аспектам, ну а пока все!

Ставьте мои любимые реакции 🐳🐬, делитесь постом и пишите в комментариях были ли такие ситуации у вас!

Аналитика мемов

😏 Возможно вы уже заметили подозрительную активность с каналом @ds_memes

😐 Рад поделиться с вами своим новым проектом. Хочу сделать его максимально прозрачным и раскрыть все карты.

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

В чем суть?
Порционно: посты будут выходить ограниченное количество раз в день (пока 3, буду тюнить в зависимости от предпочтений подписчиков) в определенные промежутки времени - до работы / во время обеда / после работы.

Тематика: контент подобран только на определенную тему IT / работа / офис 💻

Ничего лишнего: никакой тяжелой теории и смыслов - только мемы.

Если вам интересно следить за развитием такого продукта, ставьте реакции - расскажу как полностью автоматизировал процесс публикации и подбора контента. Ставьте 🐳🐬, если интересно. Ссылочку продублирую тут.

И пусть у вас всегда будет под рукой база мемов для чата с коллегами 😎

💫 Spark для аналитика (ч.2.)

Собралось много реакций на предыдущем посте про Spark, делаю еще один!

Repartition в Spark. Зачем это вообще нужно?

В pandas не задумываешься про куски данных: читаете DataFrame и сразу работаешь с ним целиком. В Spark всё иначе: данные делятся на партиции (шарды), которые обрабатываются разными воркерами. Repartition позволяет управлять тем, как и насколько равномерно эти куски разбросаны по кластеру.

❓ Зачем?

⚖️ Баланс нагрузки на кластер. Spark работает быстрее, если данные распределены по всем воркерам более-менее равномерно. Если партиций мало, часть узлов простаивает, остальные тянут всё на себе и теряется весь смысл распределённых вычислений.

🚤 Ускоряет джойны и агрегации. Самая частая боль в Spark - это медленные джойны или группировки. Причина часто в том, что данные по ключу раскиданы неравномерно. Если сделать .repartition("key") перед джойном Spark сможет склеить нужные куски локально, а не гонять данные по всему кластеру.

📝 Экономит память и снижает риск падений приложений. Иногда Spark после фильтрации или select делает ОЧЕНЬ перекошенные партиции: на одной куча данных, на другой почти ничего. Это может привести к OutOfMemory именно на одном воркере, при том что на других куча свободной памяти. Repartition выравнивает данные и размазывает нагрузку.

🗃️ Контроль количества файлов на выходе. Когда записываешь данные в parquet/csv, Spark по дефолту делает столько файлов, сколько партиций в DataFrame.
Если хочешь один файл — обязательно делайте .repartition(1) перед записью, иначе получишь кучу маленьких частей.

📝 Как это выглядит на практике

🔗 Джойны (делаем repartition по ключу объединения таблиц, так проще собрать ключи, разбросанные по кластеру)

df_left = df_left.repartition("user_id")
df_right = df_right.repartition("user_id")
df_joined = df_left.join(df_right, on="user_id", how="inner")

✍️ Запись (в примере ниже указано то, что на выходе мы получаем один файл).

df_result.repartition(1).write.parquet("result.parquet")

☝️ Изменяем количество партиций вручную.

df = df.repartition(50)  # вручную задаём 50 партиций

Обычно количество партиций автоматически подтягивается из конфига приложения, возможно, при настройке видели параметр spark.sql.shuffle.partitions

⚠ Самое важное в этом посте, что нужно искать размен между количеством партиций и размером задач на воркеры.

1️⃣

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

2️⃣

Слишком мало партиций. Неэффективно, Spark теряет свою распределённость, одна нода делает всю работу.

Вообще в DA / DS / ML / DE мы всегда работаем с разменом (трейд-оффами) и все упирается в задачи, которые мы решаем)

Пишем дальше про Spark или нет?
🐳 — Пишем, давай еще, очень интересно
🤝 — Давай уже про что-то другое!

🔭 Пост про магистратуры

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

⚠️ На что я обращаю внимание

1. Онлайн-формат обучения, так как не в кайф подрываться на другой конец города (или вообще в другой город) за учебой.

2. Очная форма обучения + акредитованный вуз. Сейчас практически все онлайн-магистратуры предоставляют очный формат обучения, то есть все плюшки от него будут получены (если вы понимаете о чем я).

3. Айтишное образование. Первое мое образование (Менеджмент) не связано с айтишкой, по крайнем мере его нет в реестре специальностей на отсрочку, поэтому иду получать.

4. Возможное обучение чему-то новому. Управление AI-продуктами, ML. Постоянно чему-то учиться тоже кайф + если тут применить обязательные дедлайны (хочется еще не страдать от этого), обучение пройдет намного эффективнее.

5. Стоимость. Большинство магистратур предоставляют только платное обучение. Есть образовательные кредиты, но не хочется растягивать эту историю, учитывая, что брать его нужно на 15 лет. Конечно, можно все разом выплатить и не париться, но тоже один из факторов.

Куда я прошел вступительные испытания

💻💻💻 НИУ ВШЭ

1. Аналитика больших данных. Достаточно простенькое вступительное, очень сильно похоже на демовариант + курс на Stepik. Скидки нет, стоимость 490к в год. По модулям есть классные дисциплины с LLM / MLOps / ML для аналитики / DE / Продуктовые метрики. В общем, получается неплохой фуллстек аналитик.

2. Магистр по наукам о данных. Суммарный балл складывается из тестирования по математике, мотивационного письма, личных достижений и собеседования. Демовариант. Скидки нет, стоимость 490к в год. Тут больше упор на ML. По программе тоже зашло + процедура сама по себе не была такой сложной.

3. Искусственный интеллект. Более хардовая магистратура, есть скидки. Стоимость 520к в год. Упор на современные архитектуры, фундаментальные знания. В магистратуре нужно уделять больше времени, чем в предыдущих. В программе более детально описано. По демовариантам можно хорошо подготовиться + есть отдельные курсы на Stepik

🟢 МИФИ. Множество компаний коллабятся с этим вузом. От некоторых из них я прошел вступительные (простенькая математика + кейс), проблем с поступлением не вижу, стоимость ~400к + по наполнению у всех примерно одинаково. Есть плюсом военная кафедра. Вот пример одной из программ, хороший план.

▪️ Центральный университет. Посмотрел по программам, есть топовые преподаватели, например, Александр Дьяконов и Рома Васильев.
По вступительным: был контекст по математике и программированию.
Слышал много положительных отзывов + получил грант, по идее можно идти туда, но обучение очное в кампусе несколько раз в неделю. Ребята из ЦУ, если вы тут есть, напишите в комменты, как вам, очень интересно почитать.

😮 ИТМО. Подавался с портфолио на несколько программ по портфолио, сформировал релевантный опыт + достижения в виде участия в хакатонах, кейс-чемпионатах + выступлений. Понравилось, что есть бюджет + можно получить достаточное хорошее образование AI Talent Hub, УВБ и др. Будем отталкиваться от результатов собеседований и конкурса портфолио. Если будет еще и удаленный формат обучения — будет кайф!

Сейчас я склоняюсь к выбору МИФИ, но, возможно, мое решение поменяется. Поэтому буду рад услышать ваши за и против.

Ставьте 🐳, если пост понравился, делитесь вашим мнением

@zasql_python 👉 @ds_memes

Мемы

Всем доброе утро! Сегодня суббота, а это значит, что нужно отдыхать, уделять время себе после рабочей неделе, предлагаю прислать любимые мемы про DS / IT / работу в комментарии.

😏 Если мемы будут классные, то я их выложу в @ds_memes, а пока начну эстафету в комментариях.

Следующий пост выложу про то, как устроен пайплайн публикации мемов.

🐳🐳🐳

@zasql_python

😎 Крутые статьи на Хабре про A/B-тестирование от крупных компаний

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

Топ постов от IT-компаний, в которых активно используется 🆎.

💙 Ozon

🟢Шесть причин, почему ваши A/B-тесты не работают
🟢Без А/B результат XЗ, или Как построить высоконагруженную платформу А/B-тестов

🖤 X5 Tech

🟢А/Б тесты с метрикой отношения. Дельта-метод
🟢Как проводить A/B-тестирование на 15 000 офлайн-магазинах
🟢50 оттенков линейной регрессии, или почему всё, что вы знаете об A/B тестах, помещается в одно уравнение
🟢Varioqub: за Mann-Whitney замолвите слово

🛒 Купер (ex. СберМаркет)

🟢Линеаризация: зачем и как укрощать ratio-метрики в A/B-тестах
🟢База: айсберг A/B-тестов

🌏 Авито

🟢Как устроено A/B-тестирование в Авито
🟢Как улучшить ваши A/B-тесты: лайфхаки аналитиков Авито. Часть 1
🟢Как улучшить ваши A/B-тесты: лайфхаки аналитиков Авито. Часть 2
🟢Сетап А/В-теста, который помог снизить MDE выручки в 2 раза
🟢Как мы в Авито проводим A/B-тесты CRM-рассылок

🤪 Lamoda Tech

🟢Как же мощно я провел A/B-тест, или почему не стоит сравнивать наблюдаемый аплифт с MDE

❤️ Яндекс

🟢10 мифов об A/B-тестировании: как избежать распространённых заблуждений в статистическом анализе

🏦 Т-банк

🟢Использование последовательного тестирования для уменьшения размера выборки

Ставьте 🐳, если подборка была полезной, сохраняйте к себе, чтобы не забыть! Следующую подборку сделаю по методам оценки эффекта без A/B тестирования

@zasql_python 👉 @ds_memes

Что-то забыл? Пишите в комментариях!

Пятница, играем в русскую рулетку.

😏 @ds_memes

Хотите выйти за рамки простых SELECT? Или практики на реальных коммерческих задачах?

Приглашаем на практический вебинар с Александром Грудининым — Lead Data Analyst в AdTech Holding и ментором курса «Аналитик данных»!

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

⚡️Что будем разбирать:

🟠Как найти вторую по величине зарплату в отделе: чтобы HR понимал, какие компенсации предлагать.
🟠Рекурсия в SQL: например, как собрать полный список деталей велосипеда, включая все вложенные компоненты.
🟠Поиск «островов» в данных: например, периоды просрочки платежей клиента банка.
🟠Расчёт непрерывных последовательностей: сколько дней подряд пользователь смотрит кино без перерыва?
🟠Продвинутые оконные функции (поиск аномалий): как быстро выявить резкие скачки продаж в интернет-магазине.
🟠Сравнение данных через самоджойн: например, рекламные метрики за два месяца у одного клиента.

Кому будет полезно?

🟠Начинающим аналитикам, которые хотят выйти за рамки простых SELECT.
🟠Опытным специалистам, которым нужно решать нестандартные задачи.
🟠Всем, кто хочет писать эффективные запросы, а не просто знать синтаксис.

Если вы хотите прокачать навыки работы с SQL на примерах из реальных бизнес-задач — присоединяйтесь 19 августа в 19:00 (МСК), будет много практики и полезных инсайтов!

🕗 19 августа в 19:00 по МСК

😶Регистрируйтесь сейчас — вебинар будет максимально практическим!

Буквально 2 дня назад вышла статья Avito 🌍 по 🆎. Разбираем по шагам механику A/B-тестирования: математика, интуиция и код

Почитал, в целом могу сказать, что хорошее чтиво для разбора A/B тестов.

Обычно, я смотрю графически на то, как изменяется MDE (тут это написано в зависимости от длительности эксперимента), также смотрю и по количеству пользователей в эксперименте (10/10, 20/20 и тд), только равные группы пользователей.

🧑‍🎓 Теоретическое

def compare_mde(current_a, current_b, new_a, new_b):
    return np.sqrt(1/current_a + 1/current_b) / np.sqrt(1/new_a + 1/new_b)

# здесь смотрят на то, а как изменится mde, если мы перейдем от 10/10 к 50/50 разбиению
compare_mde(0.1, 0.1, 0.5, 0.5) # ~2.236

💻 Практическое

def check_mde_reduce_from_size(grouped_dataset, current_t, current_c, new_t, new_c):
    """
    Функция для сравнения MDE в текущем варианте сплитования и в новом.
    Параметры:
        - grouped_dataset: сгруппированный поюзерный датасет, на осоновании которого будут сравниваться MDE
        - current_t: доля пользователей в тесте в текущем сетапе
        - current_c: доля пользователей в контроле в текущем сетапе
        - new_t: доля пользователей в тесте в новом сетапе
        - new_c: доля пользователей в контроле в новом сетапе
    Возвращает:
        - отношение MDE_current / MDE_new
    """


    grouped_dataset['group_current'] = np.random.choice(['test', 'control', '-'],
                                                        p=[current_t, current_c, 1 - current_c - current_t],
                                                        size=len(grouped_dataset))
    grouped_dataset['group_new'] = np.random.choice(['test', 'control', '-'],
                                                    p=[new_t, new_c, 1 - new_t - new_c],
                                                    size=len(grouped_dataset))
    metric = 'promotion_revenue'


    test_curr = np.array(grouped_dataset[(grouped_dataset['group_current'] == 'test')][metric])
    control_curr = np.array(grouped_dataset[(grouped_dataset['group_current'] == 'control')][metric])

    test_new = np.array(grouped_dataset[(grouped_dataset['group_new'] == 'test')][metric])
    control_new = np.array(grouped_dataset[(grouped_dataset['group_new'] == 'control')][metric])

    MDE_current = get_relative_MDE(test_curr, control_curr, alpha=0.05, beta=0.2)
    MDE_new = get_relative_MDE(test_new, control_new, alpha=0.05, beta=0.2)
    return MDE_current / MDE_new

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

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

Написано еще тут и про прокси-метрики, что их нужно выбирать в зависимости от каждого кейса, про оценку эффекта при переходе от обычной метрики к прокси-метрике, интерпретацию прокси-метрик

+ итоги правильной подготовки сетапа теста, где выбрали

а) сплит 50/50, а не 10/10
б) выбрали прокси-метрику, а не основную (которая обладает меньшей чувствительностью)
в) держать тест не 1, а 7 недель.

🔽 как результат, получили сокращение MDE в 9.2 раза!

Ну и дополнительно рассказали про контр-метрики, в очередной раз упомянули линеаризацию + доверительный интервал для оценки эффекта Ratio-метрик.

В целом, хорошая и ненапряжная статья, которую я вам советую прочитать, если хотите начать разбираться в A/B тестах + подметить для себя что-то новое)

Ставьте 🐳, если понравился пост, делитесь своими мыслями в комментариях.