Привет, аналитики!
Первая рабочая неделя на новой работе позади. Ура!
Итак...
Я устроился в компанию Excite Kit (https://uxrocket.ru/about).
Сейчас (на испытательный период) я занимаюсь отчётностью для одного крупного клиента. У них большой переезд из Oracle в ClickHouse (этим занимаюсь не я) и из OracleBI в DataLens (а вот этим как раз занимаюсь я).
Более 50 различных отчётов нужно превратить в удобоваримый дашборд (а может и не один).
Часть отчётов нужно перенести как есть, а другую часть они будут менять и сейчас формируют для этого ТЗ.
Некоторые таблицы там 150+ млн строк. А отчёты содержат джоины по 5-6 таблиц сразу... Вот и надо как-то это ещё и оптимизировать, потому что у DataLens тоже есть свои ограничения как по количеству строк, так и по выделяемой для этого памяти.

@nullpp #работа

Привет, аналитики!
Сегодня без лирики, сразу к делу. Хочу рассказать про одну годную штуку в ClickHouse.
Все мы без сомнений любим LEFT JOIN, но всегда есть нюанс: если справа несколько строк — получишь дублирование строк из левой таблицы + соответствующие значения из правой. Классика, всё работает так, как и должно.
Но при таком соединении соответствия ищутся и ищутся, пока поиск не дойдёт до конца правой таблицы.
А что делать, если я точно уверен, что правая таблица - это справочник, где только уникальные строки? Или мне не нужны все совпадения, а нужно только одно совпадение? В таких случаях можно использовать LEFT ANY JOIN.

-- Обычный LEFT JOIN (найдёт все совпадения)
SELECT t1.id, t2.value
FROM left_table AS t1
LEFT JOIN right_table AS t2 ON t1.id = t2.id;

-- ANY LEFT JOIN (возьмёт ПЕРВОЕ попавшееся значение)
SELECT t1.id, t2.value
FROM left_table AS t1
LEFT ANY JOIN right_table AS t2 ON t1.id = t2.id;

Разница колоссальная:
LEFT JOIN → 3 строки, если справа 3 записи с одним id.
LEFT ANY JOIN → 1 строка на каждый ключ. Берётся первое значение (не детерминировано, нужно быть очень аккуратным, зависит от порядка чтения данных: сортировка на диске, партиции, ORDER BY в запросе, движок таблицы).

Или вот ещё пример:

SELECT m.name, g.genre
FROM movies AS m
LEFT ANY JOIN genres AS g
ON m.id = g.movie_id;

В этом примере для каждой строки из таблицы movies выбирается первая найденная совпадающая строка из таблицы genres.

Где полезно?
- Быстрые джойны на миллионах строк
- Когда тебе всё равно, какое значение подтянется (первые попавшиеся метаданные, например)

То есть, LEFT ANY JOIN может быть полезен в сценариях, где точное совпадение не критично, а цель - быстро получить данные без обработки нескольких совпадений.

А ещё есть:
- LEFT SEMI JOIN
- LEFT ANTI JOIN
- LEFT ASOF JOIN
О них я напишу в следующих постах

Ну как, полезно? Забирай в заметки и жми 🔥

Привет, аналитики!
Продолжаем разговор про ClickHouse-джойны. В прошлый раз затронул LEFT ANY JOIN, сегодня на очереди LEFT SEMI JOIN.
LEFT SEMI JOIN возвращает только строки из левой таблицы, для которых есть хотя бы одно совпадение в правой. При этом возвращается только первое найденное совпадение, декартово произведение не формируется и колонки из правой таблицы не добавляются.

-- INNER JOIN (может размножить строки, если справа несколько совпадений)
SELECT users.*, orders.amount
FROM users
INNER JOIN orders ON users.id = orders.user_id;

-- LEFT SEMI JOIN (каждый пользователь - максимум один раз, без колонок из orders)
SELECT users.*
FROM users
LEFT SEMI JOIN orders ON users.id = orders.user_id;

Важно учитывать, что поведение LEFT SEMI JOIN может зависеть от конкретной СУБД и алгоритма, который использует оптимизатор запросов. В некоторых случаях вместо него могут применяться другие типы соединений или методы оптимизации.
Вот ещё примеры:

-- Найти пользователей, у которых был хотя бы один заказ
SELECT id, name, email
FROM users
LEFT SEMI JOIN orders ON users.id = orders.user_id;

-- Найти курсы, на которые есть хотя бы одна успешная проверка
SELECT course_id, course_name
FROM courses
LEFT SEMI JOIN reviews ON courses.id = reviews.course_id 
WHERE reviews.status = 'approved';

-- Клиенты с платежами больше 1000₽
SELECT client_id, name
FROM clients
LEFT SEMI JOIN payments ON clients.id = payments.client_id
WHERE payments.amount > 1000;

Применять или не применять - дело каждого)
И не забываем, что нельзя однозначно сказать, какая из операций будет дешевле - LEFT SEMI JOIN или обычный LEFT JOIN. Это зависит от конкретных условий запроса, характеристик данных и настроек СУБД. Для оценки стоимости, как уже писал ранее, используй инструменты анализа планов запросов (например, EXPLAIN), которые помогут оценить ресурсы, необходимые для выполнения операции.
Но обычно SEMI JOIN более эффективен, так как хеш-сет может быть меньше полной хеш-таблицы, а для каждой строки левой таблицы больше не выполняется дополнительное сопоставление.
В любом случае, забирай в заметки и ставь 🔥, если полезно.

Привет, аналитики!
Сегодня разбираю ещё одну крутую фишку ClickHouse, с которой сталкивался далеко не каждый. Речь про ANTI JOIN. И он делает ровно противоположное тому, к чему мы привыкли.

Простыми словами:
Обычный JOIN находит совпадения между таблицами. А ANTI JOIN находит НЕСОВПАДЕНИЯ.

Отличный пример:

-- Найти пользователей, у которых НЕ БЫЛО заказов
SELECT u.*
FROM users u
ANTI LEFT JOIN orders o ON u.id = o.user_id;

Согласитесь - читается как обычная фраза на русском: "дай пользователей, к которым не присоединилось ни одного заказа".

Как это работало бы без ANTI JOIN?

Через NOT EXISTS или LEFT JOIN + WHERE right.id IS NULL:

-- Классический способ (работает везде)
SELECT u.*
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.id IS NULL;

-- ClickHouse способ (короче и понятнее)
SELECT u.*
FROM users u
ANTI LEFT JOIN orders o ON u.id = o.user_id;

Разница в читаемости и иногда в производительности.

Вот ещё несколько примеров:

-- 1. Курсы без единого студента
SELECT c.id, c.name
FROM courses c
ANTI LEFT JOIN enrollments e ON c.id = e.course_id;

-- 2. Менторы, которые пока не проверили ни одной работы
SELECT m.id, m.name
FROM mentors m
ANTI LEFT JOIN reviews r ON m.id = r.mentor_id;

-- 3. Товары, которые ни разу не покупали
SELECT p.id, p.name
FROM products p
ANTI LEFT JOIN sales s ON p.id = s.product_id;

-- 4. Пользователи без сессий за последний месяц
SELECT u.id, u.email
FROM users u
ANTI LEFT JOIN sessions s 
    ON u.id = s.user_id AND s.date >= '2025-06-01';

Важный нюанс:
ANTI LEFT JOIN (как и рассмотренный до этого SEMI JOIN) не добавляет колонки из правой таблицы - только фильтрует левую.

-- Так НЕ сработает (правой колонки в результате не будет)
SELECT u.*, o.amount
FROM users u
LEFT ANTI JOIN orders o ON u.id = o.user_id;
-- ошибка: column o.amount not found

Когда использовать вместо NOT EXISTS:
1. Маленькие таблицы - без разницы, оба варианта хороши
2. Большие данные + простой фильтр - ANTI JOIN часто быстрее
3. Сложные условия в подзапросе - NOT EXISTS может быть удобнее
4. ClickHouse + миллиарды строк - однозначно ANTI JOIN

Короткий алгоритм для себя:
Нужно найти то, чего НЕТ в другой таблице? → ANTI JOIN
Запомнить легко: ANTI = противоположность INNER. Если INNER оставляет только совпавшие строки, то ANTI оставляет только НЕ совпавшие.
Полезно? Забирай в заметки и жми 🔥

@nullpp #полезное #ClickHouse

Привет, аналитики!
С новой работы прислали/подарили книгу "Доверительное A/B-тестирование". Сходил сейчас, забрал из доставки. Сказали, что в ближайшее время она мне очень пригодится 😁
Чтож, будем её внимательно изучать

#книги #абтесты #абтестировние @nullpp

Привет, аналитики!
Всю эту неделю я проходил интенсив по A/B-тестированию от ШАД Яндекса.
Начну с главного: мне, как "дилетанту" в A/B-тестах, не зашло. При этом, в чатах участников я видел сплошной положительный отклик и "вау-эффект". Почему? Наверное, я ожидал немного другого.
Давайте по фактам.
Что было круто (да, плюсы тоже есть):
+ Глубокое погружение в матстат (хотя в этом есть и минус, напишу дальше об этом), но фундамент дают мощный.
+ Спикер реально работает с A/B-тестами на данных Яндекс.Такси - это не абстрактные апельсинки и котики, а настоящий продакшн. Было множество примеров из работы спикера.
+ Много вычислений и визуализаций на питоне. Код пишут, показывают, графики строят - глаз радуется.
А теперь минусы:
- Несмотря на крутой бэкграунд спикера, большинство примеров исследований были синтетическими и далекими от жизни.
- Математический оверскилл. Я понимаю, что это ШАД! Но иногда казалось что это лекция для аспирантов математического факультета. Много абстракций, за которыми я терял всякий смысл (учтём факт, что я много лет отдал матфаку, хоть это было и очень давно)
- Хромает педагогический подход. Между некоторыми темами переход резкий, и мостики понимания в принципе отсутствуют.
- Питона то много, но всё написано только "с нуля" как и показано в формулах до этого. Очень мало использований уже готовых библиотек и функций.
И тут у меня главный вопрос к сообществу (и к ребятам из Яндекса, если вдруг они это прочитают): Неужели вы в реальной работе для каждой статистики пишете велосипеды с нуля?
Как итог: Интенсив скорее для математиков, которые хотят пощупать прикладную область, чем для аналитиков, которые хотят прокачать скилл в продакшене.

Есть у кого ещё какие интересные бесплатные курсы по A/B-тестированиям?

Кстати, вот ссылка на этот интенсив: https://shad.yandex.ru/abweek

#ABтестирование #ШАД #Яндекс #Аналитика #Обучение @nullpp

Привет, аналитики!
Интересно, куда я опять пропал? 🤔
А я устроил себе небольшой отпуск в Калининграде.
Посмотрел на старинную архитектуру, побывал во многих музеях, да и просто гулял по городу во всех возможных направлениях. Большую часть времени я провёл в самом Калининграде, но также съездили в Зеленоградск — город котиков.
Не повезло немного с погодой — попали в самый шторм (который сейчас в Москве, а затем по прогнозам направится в мой родной Архангельск).
В Зеленоградске, конечно, совсем всё серьёзно было, а в Калининграде - очень сильный ветер и 12-13 градусов на улице. Но я человек северный — я не замёрз 😁
Что могу ещё сказать: Калининградская область — это очень атмосферно. Будто смесь Европы, советского наследия и морского бриза. Советую обязательно посетить, если ещё не бывали тут.
Вообще, в нормальном отпуске не был целый год и очень устал за это время.
Но вроде получилось отдохнуть от рутины, и сегодня я отправляюсь в обратный путь. Поездом.
Люблю путешествовать поездом, несмотря на то, что обычно от дома до места отдыха поездка занимает около 2х дней. Это мой отдельный вид "медитации". Особенно когда мобильный интернет исчезает часов на 7 (когда едешь по Архангельской области).
Читаешь книги, смотришь заранее скаченные сериальчики, спишь — красота! Ах да, ещё есть много времени на "подумать".
А вы уже в этом году ездили в отпуск?
П.С.: Хотите немного фоток? Тогда ставь 🔥 и я напишу пару постов о том, где побывал и что видел.

@nullpp #отпуск #калининград #зеленоградск

Привет, аналитики!
Небольшой короткий запланированный пост, пока я еду без связи в поезде :)
Сегодня у меня профессиональный день рождения! 🎉
Ровно год назад был мой первый рабочий день в качестве BI-аналитика.
Это был очень интересный и даже увлекательный год — я узнал очень много всего, получил очень ценный практический опыт как в BI, так и в самой аналитике данных и дата-инженерии.
Временами было сложно, иногда хотелось всё бросить и уехать смотрителем маяка, чтобы меня никто не нашёл 😁 Но каждый раз, когда дашборд собирался, а цифры сходились — появлялся тот самый огонёк.
Какие планы у меня на следующий профессиональный год? Ну...
- Надо научиться дизайнить, проводить A/B-тесты, а также правильно и качественно оценивать их результаты.
- Хочется ещё больше углубиться в ML, особенно в рекомендательные системы.
- И, конечно же, продолжать делиться тут всем этим с вами!
А какой был у вас самый запоминающийся профессиональный момент за последний год? Делитесь в комментариях!
@nullpp #работа #профессия

Привет, аналитики!
Первая рабочая неделя после отпуска заканчивается, и я обещал немного рассказать про свою поездку в Калининград.
Я побывал во многих музеях города, но хочу рассказать о двух, которые прям врезались в моё сердечко и навсегда останутся у меня в памяти.
Сегодняшний пост о Музее ретро-игр "Бит и Пиксель".
Я попал туда случайно. Мы просто гуляли и я решил посмотреть на картах, что находится поблизости. Несмотря на то, что сам музей находится на задворках и имеет не очень презентабельный вид — мне очень понравилось =) Ведь я очень люблю игры и приставки, особенно ретро =)
В музее есть возможность поиграть в игры на NES, Sega MD, Sega Dreamcast, PS1, PS2, PS3, PS4, Xbox360 и много чего ещё.
А главное — детям тоже понравилось!
С удовольствием показал детям и вместе с ними поиграл в легендарные Quake III и CS1.6. Аутентичность на 146%: "пузатые" мониторы, клавиатуры с заедающим пробелом (ну у меня такая была) и даже мышки были с шариком)
Приставки тоже подключены к ЭЛТ-телекам, стульчики и кресла из 90х, на полу лежат ковры — почти домашняя ностальгическая обстановка из моего детства.
В общем, эмоции меня переполняли, я и дети не хотели уходить оттуда.
И знаете, я поймал себя на мысли: в нашей работе мы постоянно оптимизируем запросы, ускоряем дашборды, считаем миллисекунды. А тут — приходишь, садишься за компьютер с 256 МБ оперативки, и игра может запускаться пару минут. И ты получаешь кайф!
Технологии ушли вперёд, но дух тех лет — он навсегда.

Все фотки в комментариях! (из-за ограничения ТГ)

А у вас были походы в такие места? Или, может, дома сохранилась старая приставка?

@nullpp #калиниград #музей #ретро #игры

Привет, аналитики!
Напоминаю, что я продолжаю потихоньку учиться в сторону ML 😏
И я столкнулся с задачей: построить рекомендательную систему для интернет-магазина. Саму задачу и моё решение, кому интересно, можно глянуть тут: vk.cc/cZLJI3
Но я хочу рассказать не об этом.
Чтобы немного сэкономить время оформления репозитория, я закинул все файлы (включая мой ноутбук ipynb) в deepseek и попросил написать readme.md. Совсем немного его потом подправил, и вышло довольно-таки неплохо, я считаю 😊
Фактически, дипсик вытащил всё, что я бы и сам написал в описании.
Но была надоедливая проблема — постоянно "ломался" формат md. Я полагаю, это из-за сочетания символов ```. Пришлось по частям копировать и самому доделывать/компоновать 😔
Кто-нибудь знает как побороть такое? Или это проблема бесплатной версии дипсика?
P.S. Думаю, такой проект будет не стыдно и в портфолио закинуть. Напомню, оно тут: mishandri.github.io

@nullpp #нейросети #github #портфолио #deepseek #ml #machinelearning

Привет, аналитики!
Уже больше года прошло с тех пор, как я сменил профессию и устроился работать аналитиком данных. Переобучение давно закончено, дипломы получены. Но я продолжаю посещать различные учебные мероприятия. Почему?
В этом посте я попробую объяснить то, что давно вертится у меня в голове, но я не мог подобрать слов, чтобы это описать.
По первому диплому я учитель математики и информатики. И я 8+ лет практиковался в этом направлении :)
Так вот, в постсоветской педагогике есть такая концепция — ЗУН (знания-умения-навыки), которая сейчас активно применяется в современном образовании. Хорошая или плохая эта концепция — это отдельный длинный разговор.
Концепция делит обучение на три этапа:
- Что-то узнать теоретически (лекция / параграф в учебнике).
- Посмотреть, как теория работает на практике, отработать, закрепить (решение однотипных задач / практика).
- Проверить, как усвоились знания (контрольные / тесты / лабораторная работа).
У этого подхода есть один большущий минус: в человека пытаются вложить весь объём современных сведений о мире.
Но когда я всерьёз занялся самообучением, я понял, что этого метода недостаточно, чтобы развиваться как профессионал.
Я пришёл к выводу, что все знания, которые мы получаем, можно разделить на два типа.

Первый тип — «тяжёлые» знания. Когда ты садишься и целенаправленно учишься: читаешь теорию, статьи, документацию (или смотришь видео об этом). Затем решаешь задачки, пишешь код, ошибаешься, переписываешь, доводишь до ума — как раз тот самый метод ЗУН.
Другими словами - это задачи, которые нужно решать самому. Они прокачивают тебя напрямую. Берёшь реальную проблему, ищешь вариант, исправляешь его — и это остаётся с тобой навсегда. В этом случае ты не забудешь синтаксис, потому что сам три часа мучился с ним в боевом режиме.

А есть второй — «лёгкие» знания. Это когда ты просто где-то услышал, увидел, краем уха зацепился. Такой тип называют «насмотренностью» или «наслушенностью».
Это задачи, которые достаточно один раз увидеть, как решает кто-то другой. И ты не запоминаешь каждую строчку кода. Ты запоминаешь паттерн, подход, идею: «А так вообще можно было?» И через месяц, когда встречаешь похожую ситуацию, в голове всплывает: «Я где-то это видел, там было примерно так, надо попробовать».
И вот второго типа мне как раз и не хватало долгое время. Я понял, что эта наслушенность / насмотренность — она бесценна.

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

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

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

@nullpp #размышления #теория #практика #задачи #работа #профессия

Привет, аналитики!
Сегодняшний пост будет продолжением рассказа про отпуск.
Я упоминал, что два места в Калиниграде произвели на меня сильное впечатление. И вот наконец дошли руки написать про второе — Историко-Художественный музей.
Но не весь целиком... Первый этаж мало чем отличается от аналогичных музеев в любом другом крупном городе. А вот второй этаж — это просто муражки по коже.
Почти весь этаж занимает один огромный экспонат - «Кёнингсберг-45. Последний штурм».
Это масштабная трёхмерная панорама, которая буквально переносит тебя на улицы охваченного войной города. Глубокий и атмосферный рассказ о решающем бое за Кёнигсберг.
Статичный макет кажется настолько реальным, что ком подступает к горлу. Декорации, свет, детали — всё работает на погружение. Ты не просто смотришь, ты оказываешься внутри.
Я, например, ощутил всю силу отвратительности войны. Одновременно — отчаяние настоящего и надежду на будущее. Это было сильно.
Фото прикладываю в комментариях, но если у вас будет возможность — обязательно сходите. Это тот случай, когда лучше один раз увидеть.
Я впервые столкнулся с таким форматом повествования. А вы были в похожих музеях?

@nullpp #калиниград #музей #война #Кёнингсберг #ВОВ

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

Чем отличаются DROP, DELETE и TRUNCATE?

Начну с того, что все три команды так или иначе удаляют данные 😁
Но фишка в том, что делают это они по-разному. Поэтому простого ответа "все они удаляют данные" на этот вопрос недостаточно.

Давайте разбираться!

1. DELETE — удаляет строки в таблице

DELETE FROM users

Есть возможность удалять строки по условию, то есть конкретные записи. Например, пользователей с пустым e-mail.

DELETE FROM users WHERE email IS NULL

Особенности:
- Удаление происходит построчно. Да и удалением это назвать не совсем правильно. Строки помечаются как удалённые, но всё равно некоторое время хранятся в таблице. Кстати, при вставке строк INSERT СУБД старается сначала заполнить именно вот такие помеченные строки.
- Не освобождает занимаемое место в БД.
- Если внутри транзакции, то результат можно откатить через ROLLBACK.
- Можно удалить не всё, а лишь определённые строки, использовав WHERE.
- Не сбрасывает автоинкремент, если он есть в таблице.
- Работает медленно (особенно на больших таблицах), ведь нужно пробежаться по каждой строке, пометить её "удалённой"

2. TRUNCATE — очищает таблицу полностью, сохраняя лишь её структуру (название и типы полей, связи, ограничения и т.д.).
Например, почистить таблицу, где хранятся логи:

TRUNCATE TABLE logs

Особенности:
- Удаляет все строки разом.
- Нельзя использовать WHERE.
- В большинстве СУБД нельзя откатить.
- Сбрасывает счётчик автоинкремента.
- Работает быстро.
- В большинстве СУБД автоматически освобождает место.

3. DROP — удаляет саму таблицу (или базу данных) вместе со структурой.

DROP TABLE temp_table

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

Поэтому запоминаем раз и на всегда:
DELETE — скальпель, удаляем выборочно.
TRUNCATE — лопата, вычищаем всё содержимое, оставляя коробку.
DROP — бульдозер, сносим коробку вместе с содержимым.

P.S. В ClickHouse, например, TRUNCATE работает моментально, даже на терабайтных таблицах. Потому что там нет транзакций в классическом понимании.

Надеюсь, теперь на собеседовании этот вопрос не застанет тебя врасплох 😄

Забирай в заметки и ставь 🔥, если полезно!

Попадался такой вопрос на собесе? Или может случайно что-то не то удалял? 😂 Пиши в комментах

@nullpp #sql #вопрос #собеседование