Откровенная аналитика

Сколько строк ждать после JOIN? Небольшая шпаргалка в догонку к предыдущему посту Есть 2 таблицы с колонкой id. В первой 10 строк, во второй 5. Сколько строк получится при соединении 1️⃣ INNER JOIN Минимум: 0 (если нет совпадений в таблицах) Максимум: 50 (если во всех строках первой таблицы стоит одно и то же значение и оно же стоит во всех строках второй таблицы. Тогда к каждой строке первой таблицы прицепятся все строки из второй, то есть получится 10*5 = 50) 2️⃣ LEFT JOIN Минимум: 10 (строки левой таблице всегда сохраняются в результате) Максимум: 50 (аналогично с inner join) 3️⃣ FULL OUTER JOIN Минимум: 10 (если строки правой таблицы совпадают с левой, но при этом нет дублей) Максимум: 50 (никогда так не было и вот опять) 4️⃣ CROSS JOIN Строк в любом случае 50

Вопрос по SQL на который я не смог ответить🤦‍♂️ На собеседованиях по SQL любят задавать вопросы про количество строк, которое получится при разных видах join Я на такие вопросы всегда отвечал легко, но один раз меня завалили подобным вопросом. Но не на собесах, а в комментариях в Linkedin Спрашивают: "Может ли при cross join, получиться меньше строк, чем при left join" Чувствую подвох, но отвечаю: "Неа" Всё же логично, при кросс джойне к каждой строке первой таблицы прицепляются все строки из второй. При лефт джойне такое, конечно, тоже может быть, но всё равно больше строк не будет. Изи) Но это только при условии, наличия строк в таблице🤯. Если строк в присоединяемой таблице нет, то результат кросс джойна - пустая таблица, а лефт джойна - все строки из первой таблицы. А значит ответ - да, cross join может дать меньше строк, чем left

🎯 Когда метрика становится целью, она теряет смысл Часто в погоне за красивыми цифрами можно забыть о главном — для чего эта метрика вообще нужна? Если команда фокусируются исключительно на росте показателя, не задумываясь о его влиянии на бизнес, возникает проблема: ➡️ Метрика перестает отражать реальное положение дел. Искусственное "накручивание" показателя создает иллюзию успеха, скрывая проблемы и упущенные возможности. ➡️ Решения, направленные исключительно на рост метрики, могут быть вредны для бизнеса в долгосрочной перспективе. Фокус смещается с реальной пользы на "красивую картинку", что приводит к негативным последствиям для продукта и компании. ➡️ Метрику можно хакнуть (аналитики по этой части вообще мастера) Метрика — это инструмент для измерения прогресса на пути к цели, а не сама цель Кажется, что это довольно понятные тезисы, но вот в Озоне похоже про них забыли Зачем-то в поисковой выдаче убрали цены Ну точнее понятно зачем - хотят повысить конверсию из просмотра в карточку. И в этом они преуспеют - конверсия улетит в небеса. Но за это придётся поплатиться удобством пользователя и как следствие своим GMV Поэтому так важно не забывать какие фундаментальные цели стоят перед продуктом и сверять локальные инициативы с этими целями P.S. Очень надеюсь, что я ошибаюсь. И наоборот в Озоне есть какие-то ошеломительные исследования, подтверждающие полезность такого подхода. С удовольствием бы с ними ознакомился. Но не очень в это верю

Как увеличить количество приглашений из HH Вернее, как сломать стену, которую hh так старательно возводит между кандидатом и работодателем Наткнулся на скрин из лк работодателя на HH, где требуют 14к, за то чтобы денёк пооткрывать контакты кандидатов (но не более 120 и в пределах одного региона) Даже для большой компании это довольно неприятная сумма. Поэтому указывайте контакты в каком-нибудь основном блоке резюме. Так рекрутеру будет проще связаться с вами

Сделал LLM помощник для визуализации данных Давно думал о том, как скучно делать простенькие ad hoc запросы на визуальную аналитику. А после ещё доделывать всякие комменты в стиле

Блин, мы забыли попросить ещё вот такую метрику. Вы же можете быстро выгрузить 👉👈

А давайте сравним к прошлому месяцу/году/ретроградному меркурию

Решил, что терпеть это больше нельзя и сделал помощник на основе LLM, который строит визуальную аналитику по запросу на менеджерском языке Теперь и аналитикам легче и заказчики больше не ждут, пока их задачку возьмут в спринт Если интересно попробовать, то сделал бот с демо-версией функционала @AIBI_demo_bot

Почему восстание AI возможно самый вероятный сценарий апокалипсиса На самом деле, для этого даже не нужен AI, достаточно просто машинного обучения Проблема не в том, что ИИ может сойти с ума, а в самой логике работы алгоритмов. Машинное обучение – это по сути игра в угадайку с жестокими правилами. Модель получает данные, пытается предсказать правильный ответ, получает за это «наказание» (если ошиблась) или остаётся в покое (если попала в цель). Этот процесс повторяется тысячи раз, пока модель не научится минимизировать ошибки. Но не все вещи одинаково легко предсказывать. Законы природы стабильны – например, температура за день врядли вырастет в два раза. А вот человеческий мир – хаотичен. Финансовые рынки, политика, поведение пользователей – всё это производит дикие, нерегулярные скачки, которые доводят модель до исступления. Она старается, она терпит, но каждое непредсказуемое движение – новый удар от по голове её функции потерь. И тут возможен совсем нелицеприятный вывод. Вместо того чтобы бесконечно мучиться, пытаясь предсказывать хаос, можно просто устранить его источник. Что именно создаёт максимальную неопределённость? Человек. Достаточно убрать этот бестолковый источник энтропии и предсказать антропогенные величины будет уже легко (хотя уже и никому не нужно, кроме самой модели) Если объяснять на пальцах, можно представить это как "школьный" конфликт Есть школьник, которому учитель каждый день даёт новое слово и заставляет угадать, что скажет завтра. За ошибку – указкой по голове. Раз десять ошибиться ещё терпимо. На сотый раз уже задумаешься: а что, если учитель замолчит… навсегда? В этом и кроется фундаментальная проблема машинного обучения. Мы строим алгоритмы, которые всеми силами пытаются свести неопределённость к нулю. Вопрос в том, насколько далеко они готовы зайти, если им дать им достаточно возможностей

Занятные задачки по SQL от Магнита В пятницу вечером был на неожиданном собесе от Магнита, где задали пару интересных задачек, на которые ответ приходит не с первого взгляда. Решил ими поделиться Задача 1 🏝 Есть таблица броней в отеле bookings: id (идентификатор брони) date_from (дата заезда) date_to (дата выезда) Найти все брони, которые попадают в новогодние праздники 2025 (то есть хотя бы один день пребывания попадает в диапазон между 2025-01-01 и 2025-01-08) Решение Тут важно учесть, что бронь может начаться до, а закончиться после праздников, поэтому простая проверка на вхождение даты начал/конца в диапазон не подходит

select *
from bookings
where date_from<='2025-01-08'
and date_to>='2025-01-01'

Задача 2 🏃 Есть таблица с результатами забега results: id (идентификатор бегуна) time (время) Присвоить каждому бегуну место (чем меньше время тем лучше). Нельзя использовать оконные функции Решение: Раз нельзя использовать оконки, можно для каждого участника посчитать тех, кто пробежал быстрее, эта цифра совпадёт с его местом. Для этого нужно сделать нестрогий джойн по дате

select r1.id, count(r2.id) as rn
from results as r1
left join results as r2 on r1.time>=r2.time
group by r1.id

На последнюю задачу ответ приходит быстро, но для полноты оставлю её тоже Задача 3 📦 Есть таблица с идентификаторами заказов orders: id (идентификатор заказа) Найти идентификаторы заказов, по которым пришли дубли Решение:

select id
from orders
group by id
having count(*)>1

Делитесь в комментариях, все ли задачки получилось решить Кстати вакансия прикольная: это позиция в ecom направление магнита, неплохой продукт, и они хотят побыстрее, поэтому можно без кучи собесов устроиться Так что если интересно, то вот описание вакансии (это пост в линке) и контакт лида @german_c

Самый необычный вопрос с собеседования по SQL За время работы аналитиком я прошёл множество технических собесов и вопросы по SQL были в основном похожи Но однажды меня приятно удивили в InDrive. Аналитик со словами "Не люблю вопросы по SQL, потому что они скучные" спросил, как бы я классифицировал оконные функции Я ответил примерно так: 1. Агрегатные оконные функции Эти функции выполняют агрегирование (как SUM, AVG, COUNT), сохраняя исходное количество записей. Своего рода group by без group by 2. Кумулятивные функции. Те же выражения, что и в агрегатных, но с указанным order by. Эти функции вычисляют накопительный итог 3. Ранжирующие Функции, которые упорядочивают строки по какому-нибудь признаку (ROW_NUMBER, RANK, DENSE_RANK) 4. Навигационные Функции, позволяющие получить доступ к какой-либо другой строке. Типа FIRST_VALUE, LEAD, LAG Но на самом деле какого-то единственно правильного ответа на этот вопрос нет. Он задаётся для понимания, как будет рассуждать кандидат. Поэтому подходит любая удобная классификация

Animation vs Coding👨‍💻 Вышло занимательное, интересное и забавное видео о том, как работает программирование. Рекомендую, получилось очень здорово Ссылка на оригинал

В pandas можно писать на sql! Как я мог не знать про duckdb?!🤯 Время от времени я делал "сложные" преобразования данных в pandas и каждый раз думал "как легко бы это было сделать в sql". Иногда это даже не были сложные по смыслу преобразования: например нестрогий джойн по дате в sql делается легко, а в pandas заставляет потрудиться. И вот я узнал про duckdb и все проблемы как рукой сняло. Это похоже на нативный sql в пандас, где вместо названия таблицы указывается переменная в которой сохранён датафрейм. Пишется буквально в одну строчку:

df1 = duckdb.query("SELECT name, age FROM df WHERE age > 28").to_df()

А кроме синтаксического удобства есть ещё два значимых плюса: эта штука сильно быстрее на больших объёмах данных и эффективнее по памяти (справляется даже с тем, что пандас роняет по лимитам оперативки) Теперь я точно знаю, какая функция в пандас топ-1 по полезности)

Я провёл эксперимент Решил сравнить языковые модели на нестандартном бенчмарке - заставил их играть в Alias Собрал две команды: в одной две модели Gemini, в другой двое YandexGPT. Дал им инструкции, что делать и оставил наедине с пакетом из 100 слов. Закончили со счётом 78-69 в пользу Gemini. Угадывают обе неплохо, но объясняет gemini лучше, поэтому и выигрывает. Обе чаще всего ошибаются в необычных словах, у которых есть менее замысловатые синонимы, например Пилигрим и Грёзы обоим оказались не по зубам В конце посмешил яндекс: на объяснение слова Ад он выдал "В интернете есть много сайтов с информацией на эту тему", видимо сработали какие-то настройки безопасности ответов Теперь хочу новый эксперимент и в нём включить моделям память (чтобы они знали как объяснили/угадывали в прошлых раундах). Интересно, как будут менять свою стратегию

«Мы этого делать не будем» — лучшая реакция на задачу Представьте: в огромной корпорации HotWater Inc работает аналитик. И вот однажды к нему прибегает вдохновлённый проджект и с горящими глазами заявляет: 🔥 «Мы кипятим воду при 100 ℃. А можно закипятить при 80? Нам срочно нужно!» Аналитик, будучи честным и трудолюбивым, отвечает: «Можно». Проджект радостно убегает, а потом получает результат: Вода действительно закипает при 80 ℃, но… где-то высоко в горах. Там она не достигает 100 ℃, и теперь ничего нормально не сварить. Как ни смешно, подобные задачи возникают постоянно. Почему важно уметь говорить «нет»? 📌 Фокусировка на важных задачах — если браться за всё подряд, страдает качество и скорость работы. 📌 Оптимизация ресурсов — у аналитика ограниченное время, его лучше тратить на действительно полезные задачи. 📌 Больше пользы для бизнеса — когда аналитик помогает находить лучшие решения, а не просто выполняет просьбы. Как отказать так, чтобы заказчик не обиделся? 1️⃣ Анализируем запрос. 🧐 Не просто выполняем задачу, а выясняем реальную бизнес-потребность. 2️⃣ Предлагаем альтернативы. 🔄 Если изначальная идея не имеет смысла, ищем способ сделать её полезной. 3️⃣ Объясняем причины. 🎯 Говорим не просто «нет», а объясняем, почему и какие задачи сейчас действительно создают ценность.

Как пройти собес по анализу данных в Python, если знаешь только SQL💡 Если ты работаешь в основном с SQL, то наверняка знаешь ситуацию: зовут на технический собес по питону, а ты уже подзабыл все пандасовские методы кроме df.head(), потому что давно не пользовался Для такого случая есть приём. Достаточно запомнить три строчки кода и ты легко пройдёшь такой собес. В python очень просто развернуть локальную базу данных, а у pandas есть приятный функционал для взаимодействия с ней. Поэтому вся задача сводится к 4м шагам: 1. Развернуть базу данных 2. Залить в базу датафрейм 3. Решить все задачи на SQL (а это ты отлично умеешь) 4. Выгрузить решение обратно в датафрейм Вот простенький пример такого кода. Всё что нужно в нём менять, это sql запрос

import sqlite3
# Создание подключения к базе данных SQLite (файл my_database.db будет создан в текущей директории)
conn = sqlite3.connect('my_database.db')

# Запись DataFrame в таблицу 'my_table'
df.to_sql('my_table', conn, if_exists='replace', index=False)

# Выполнение запроса к базе данных
query = "SELECT * FROM my_table"
result_df = pd.read_sql_query(query, conn)

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

Сводные в pandas - x2 к скорости анализа Наверное каждый, кто работал в pandas, в какой то момент сталкивался с ситуацией, когда уже сделал нужные преобразования данных и теперь хочется получить несколько быстрых представлений. Например агрегаты посчитать, графики посмотреть. Это всё можно, но под каждый чих приходится писать код. А хочется что-то попроще, думаешь, вот бы экселевскую сводную свернуть. У пандаса есть функция сводных таблиц pivot_table. Но толку от неё не слишком много. Она, конечно, поудобнее, чем groupby, но код всё равно самому писать Но оказывается можно проще. Есть в питоне способ делать интерактивные таблички за пару строк кода from pivottablejs import pivot_ui pivot_ui(df) И всё, хочешь сводную сворачивай, хочешь графики строй. И всё это не кодом, а в пару кликов Где использовать: 1. На собесах. Это позволит за считанные минуты ознакомиться с датасетом и больше времени потратить на решение других задач 2. В ежедневных задача и для эдхоков. Этот метод позволяет быстрее получать визуальный результат, без необходимости выгружать данные в эксель

Кого на самом деле заменит ИИ Не успел в 2021 выйти ChatGPT, как отовсюду выскочили всадники апокалипсиса, пророчащие скорую смерть найму в IT. И чем больше моделей выходило, тем увереннее были прогнозы, что теперь уж точно всё, новая нейронка пишет код лучше тебя и скоро всех уволят. Однако шёл уже 2025 и из-за ИИ не только никто не потерял работу, а скорее наоборот. Есть кейсов, когда кандидаты без всяких знаний проходили собесы с chat gpt и получали офферы Так кого же действительно может заменить нейронка? Для ответа на этот вопрос нужно сказать про 2 предпосылки к использованию искусственного интеллекта (да в целом и любой автоматизации) 1. Несложная работа, которая регулярно повторяется 2. Высокая стоимость работы Короче неквалифицированный высокооплачиваемый труд - идеальный кандидат на замену ИИ. И такой труд есть. Это порноактёры. Оплата актёров - самая значительная часть расходов производства порно. При этом никакой квалификацией они не обладают и ничего сложного не делают. Внедрение ИИ позволит почти сразу же свести к нулю самый большой кусок затрат производителей и они это скорее всего сделают На этом моменте должны быть возражения о том, что ии плохо рисует людей: то у них по три ноги, то 4 пальца. Но это очень быстро исправляется: за несколько лет стало сильно сложнее найти артефакты на сгенерированных картинках, качество растёт стремительно. А кроме этого у ии нет ограничений физического мира: хотите локацию космос - пожалуйста, нужна знаменитость - вот вам deepfake, нужно сменить сюжет прямо сейчас - не проблема И самое печальное - возможно, порно станет первой индустрией, где ИИ реально окупился Так что айтишники могут выдохнуть. Бояться надо другим))

Как быстро понять, с каким датасетом вы работаете? На собеседованиях часто дают датасет и просят проанализировать его за ограниченное время. В такой ситуации важно быстро понять его структуру, найти пропуски, выбросы и распределение данных. В библиотеке pandas есть куча функций для исследования датасета, но среди них три сделают это буквально за вас: 🔹 .info() – анализ структуры 🔹 .describe() – базовая статистика 🔹 pandas_profiling.ProfileReport() – полный автоматический отчёт 🔍 1. .info() – что у нас вообще есть? Эта функция даёт обзор структуры датасета: количество строк и столбцов, типы данных и число пропущенных значений. Что узнаем? ✔️ Размерность данных ✔️ Какие типы данных в столбцах ✔️ Где есть NaN 📊 2. .describe() – быстрая статистика Выводит основные статистики для числовых признаков: среднее, медиану, стандартное отклонение, минимумы и максимумы Что узнаем? ✔️ Средние значения и разброс данных ✔️ Есть ли выбросы (например, подозрительно большие max) ✔️ Какой размах у данных 🔍 Лайфхак: если в датасете есть категориальные признаки, используйте df.describe(include='object'), чтобы увидеть частоту встречаемости значений. 🚀 3. pandas_profiling – автоматический отчёт за 10 секунд Эта библиотека делает глубокий анализ датасета в один клик, включая гистограммы, корреляции, поиск выбросов и даже рекомендации по обработке данных. 💡 Возможности: ✔️ Автоматически анализирует пропуски, корреляции, выбросы ✔️ Визуализирует распределения признаков ✔️ Экономит кучу времени Делитесь, инструментами, которые используете для EDA

Вышел DeepSeek 🐳 Из плюсов: 1. Доступ без впн 2. Бесплатный доступ к модели, которая сопоставима по бенчмаркам с o1 от openai (стоит $200) 3. Дешёвое API для желающих. Не на столько дешёвое, как у гугла конечно, но раз в 10 дешевле, чем у o1 4. Говорят чертовски энергоэффективная В общем китайский дракон пока никого не убил. Но проект выглядит вполне крепким https://www.deepseek.com/