Симулейтив

💻 Как база данных устроена изнутри, и почему PostgreSQL и ClickHouse решают разные задачи?

Привет! На связи Валерия Елпатьевская, ментор курса «Инженер данных» 👋🏻

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

И здесь важно понимать разницу между OLTP и OLAP.

💻 OLTP (Online Transaction Processing), как видно из названия, заточена под транзакции. То есть эти базы предполагают операционную нагрузку.

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

Под такую нагрузку обычно берут PostgreSQL. Он хранит данные построчно, использует индексы, WAL, MVCC и механизмы очистки старых версий. Это хорошо подходит для сценария: «найди пользователя по id», «обнови заказ» или «вставь новую запись».

💻 OLAP (Online Analytical Processing), как опять же ясно из названия, заточен под аналитику. Здесь запросы часто читают миллионы строк, считают различные агрегаты, группируют данные по времени, регионам, каналам. Примеры данных, которым больше подойдёт OLAP — метрики, продажи и поведение пользователей.

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

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

Если сильно упростить:
➡️ PostgreSQL — про состояние системы и транзакции.
➡️ ClickHouse — про аналитику по большим потокам событий.

На практике это часто работает вместе. PostgreSQL хранит основные бизнес-данные: пользователей, заказы, настройки. ClickHouse собирает события, метрики и поведение для дашбордов и отчётов.

Ставьте ❤️, если полезно, и сохраняйте, чтобы не потерять!

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

Репрезентативность: когда выборка «говорит правду»

Привет, на связи Аслан Байрамкулов, автор курса по A/B-тестированию 👋🏻

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

Репрезентативность — это соответствие выборки генеральной совокупности по ключевым характеристикам. Без неё даже самый тщательный анализ приведёт к ошибочным выводам.

✅ Как это измеряют?

Репрезентативность оценивают стандартизованной разностью d между выборкой и генеральной совокупностью по ключевым признакам:

➖ d < 0,1 — отличная репрезентативность;
➖ d 0,1–0,2 — хорошая;
➖ d 0,2–0,5 — умеренная;
➖ d ≥ 0,5 — плохая, выборке доверять нельзя.

✅ Как обеспечить репрезентативность?

➖ Стратифицированная рандомизация. Делим пользователей на страты — по возрасту, географии, каналу — и рандомизируем внутри каждой страты. Это гарантирует, что обе группы сбалансированы, а не просто «в среднем похожи».

➖ Мониторинг баланса. После запуска теста проверяем, что группы A и B не отличаются по ключевым характеристикам. Доля мобильного трафика 60% в группе A и 45% в группе B — уже повод остановиться и разобраться, а не запускать анализ дальше.

➖ AA-тестирование. Перед реальным тестом запускаем «пустой» тест, где обе группы получают одинаковый опыт. Если находим статистически значимые различия там, где их не должно быть — проблема не в продукте, а в системе рандомизации.

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

⭐️ Именно поэтому на курсе «A/B-тестирование» мы начинаем не с формул значимости, а с проверки самой выборки: стратификация, мониторинг баланса, AA-тесты как обязательный шаг перед любым реальным экспериментом. Программу веду я сам на основе методологии, которую строил в X5, Wildberries и МТС (open-source библиотека Ambrosia).

⭐️ Посмотреть программу курса

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

«ON CONFLICT DO UPDATE command cannot affect row a second time»: как мы теряли данные из-за этой ошибки

Привет! На связи Валерия Елпатьевская, ментор курса «Инженер данных» 👋🏻

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

ERROR: ON CONFLICT DO UPDATE command cannot affect row a second time

Какой же second time? Как вообще такое возможно? Так вот рассказываю.

Если вы делаете `INSERT ... ON CONFLICT DO UPDATE` большими батчами (пакетами данных), дедуплицируйте входные данные до `UPSERT`.

Допустим, в батче пришли две записи с одним id:

INSERT INTO users (id, updated_at, name)
SELECT id, updated_at, name
FROM staging
ON CONFLICT (id) DO UPDATE
SET
    updated_at = EXCLUDED.updated_at,
    name = EXCLUDED.name;

Если staging содержит несколько строк с одинаковым id, PostgreSQL завершит такую операцию ошибкой, как выше.

Причина в том, что внутри одного INSERT несколько входных строк пытаются изменить одну и ту же target-строку. PostgreSQL не выбирает автоматически, какая из них является истиной. Он не пытается угадать, а просто отказывается выполнять операцию.

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

Поэтому перед UPSERT лучше явно определить правило разрешения конфликта и избавиться от дубликатов:

WITH ranked AS (
    SELECT
        *,
        ROW_NUMBER() OVER (
            PARTITION BY id
            ORDER BY updated_at DESC
        ) AS rn
    FROM staging
)
INSERT INTO users (id, updated_at, name)
SELECT id, updated_at, name
FROM ranked
WHERE rn = 1
ON CONFLICT (id) DO UPDATE
SET
    updated_at = EXCLUDED.updated_at,
    name = EXCLUDED.name;

Теперь для каждого id в батче остаётся ровно одна запись — например, самая свежая по updated_at.

📌 Вывод: ON CONFLICT решает конфликт между входящей и целевой строкой, но не занимается бизнес-логикой выбора между несколькими строками с одним ключом.

Ставьте 🔥 и пересылайте тем, кто мог бы столкнуться с этой проблемой ❤️

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

💻 Сценарии использования NULLIF

Вас когда-нибудь спрашивали на собеседовании о функции NULLIF?

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

✅ Что такое NULLIF и как это использовать?

NULLIF — это функция, которая принимает два аргумента и возвращает NULL, если аргументы равны, в противном случае она возвращает первый аргумент. Синтаксис выглядит следующим образом:

NULLIF(выражение 1, выражение 2)

💻 Деление на ноль

Пожалуй, самое полезное, что можно сделать, используя NULLIF — пресечь ошибку деления на ноль.

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

SELECT column1/NULLIF(column2, 0)
FROM table1

То есть когда значение второго столбца равно 0 (аргументы в NULLIF равны), вернется NULL, а не ZeroDivisionError.

💻 Поиск среднего значения

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

Например, дана такая таблица:

| column1 | column2 |
|---------|---------|
| 0       | a       |
| 7       | a       |

Выполнив:

SELECT column2, AVG(column1)
FROM table1
GROUP BY column2;

Получим:

| column2 | avg |
|---------|-----|
| a       | 3.5 |

А с использованием NULLIF получим другой результат:

SELECT column2, AVG(NULLIF(column1, 0))
FROM table1
GROUP BY column2;

| column2 | avg |
|---------|-----|
| a       | 7   |

💻 Преобразование пустых строк

Другой вариант использования NULLIF — преобразование пустых строк в NULL. Например, в таблице некоторые столбцы содержат пустые строки, которые необходимо трактовать как NULL — идеально подходящая ситуация для NULLIF:

SELECT NULLIF(column1, '') FROM table1;

Получим NULL, если столбец 1 содержит пустую строку, что эффективно обработает все пустые строки.

💡 В следующий раз, когда вы будете работать над проектом, попробуйте найти, где бы вы могли использовать NULLIF и убедитесь, как он легко поможет решать сложные задачи и избегать больших CASE/WHEN конструкций. Кстати говоря, NULLIF — это тот же CASE/WHEN, так что, возможно, стоит провести ревизию старых проектов и увидеть потенциальные «use» кейсы.

Если вы и раньше использовали NULLIF, расскажите, в каких интересных задачах он вам пригодился? И ставьте 🔥, если было полезно!

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

Растим в себе сильного джуна 💪🏻

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

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

На канале «Модель предскажет» я рассказала, что реально ценят в команде — не «уметь бустинг руками написать», а гораздо более приземлённые вещи. Именно они отличают джуна, которого через полгода зовут на новые задачи, от того, за кем приходится всё переделывать.

📌 Читать пост: https://t.me/modprod/68

Сохраняйте, чтобы не потерять!

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

Булевы флаги через ::int: один трюк, шесть применений

Всем привет! На связи Александр Грудинин, ментор профессии «Аналитик данных» 👋🏻

В учебниках мы часто видим, как условную логику реализуют через CASE WHEN ... THEN 1 ELSE 0 END. В боевых запросах то же пишут короче: условие в скобках и приведение к числу. В PostgreSQL любое сравнение это булево значение, а TRUE::int = 1, FALSE::int = 0:

(status = 'active')::int AS is_active,
((age > 18) AND (verified = true))::int AS is_adult_verified

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

💡 Флаг существования после LEFT JOIN

После LEFT JOIN непарные строки получают NULL в колонках правой таблицы. Проверка на NULL, свёрнутая во флаг, отвечает на вопрос «есть ли связанная запись»:

(o.order_id IS NOT NULL)::int AS has_order

Дальше has_order работает и как фильтр, и как метрика: «сколько клиентов с заказом» — просто SUM(has_order).

💡 SUM(флаг) — счётчик, AVG(флаг) — доля

Раз флаг — это 0 или 1, агрегаты читаются напрямую:

SUM(is_active)              -- сколько активных строк
AVG(is_active)              -- доля активных (готовый процент)
COUNT(*) - SUM(has_order)   -- сколько клиентов без заказа

Один проход по таблице вместо трёх запросов с разными WHERE.

💡 MAX(флаг) по группе — «случалось ли хоть раз»

Если внутри группы флаг хоть в одной строке равен 1, то MAX по группе тоже даст 1. То есть MAX(флаг) отвечает на вопрос «было ли такое хотя бы раз»:

SELECT
    user_id,
    MAX((amount > 1000)::int) AS had_big_purchase
FROM orders
GROUP BY user_id

Читается так: «у пользователя был хотя бы один заказ дороже 1000». Без трюка пришлось бы писать самоджойн или коррелированный подзапрос.

Симметрично работает MIN(флаг) = 1 — «условие выполнилось во всех строках группы».

Ставьте 🔥, если было полезно!

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

🤖 Как я использую ИИ?

Всем привет! На связи Александр Грудинин, ментор профессии «Аналитик данных» 👋🏻

Сегодня я расскажу, как я использую ИИ в работе.

🧠 Еженедельный отчёт
Раньше требовался час, чтобы перебрать Jira руками и перечитать чаты. Теперь агент сам вытаскивает закрытые за неделю тикеты, ходит в Slack, группирует по направлениям, пишет по строке результата на каждый. Я правлю пару строк и публикую. Работает только потому, что для агента написал инструкцию (скилл) + досконально ведём описание задача в Jira.

🧠 Тикеты из встреч
Обычная история — обсудили что-то на встрече, но после никто не завёл задачу/не написал постмит. Сейчас все встречи транскрибируются, агент по записи собирает черновик задачи по шаблону. Человек проверяет и подтверждает.

🧠 Ревью своего ресёрча
Закончил анализ — отдаю агенту: проверить логику, найти места, где данные не тянут вывод. Один такой прогон вскрывает дыры до того, как их увидели стейкхолдеры. Глаз может «замылиться», и свои ошибки в своём ноутбуке не увидишь, а агент видит.

🧠 Продакшн-разработка
Не пет-проекты, а боевые репозитории: SQL и дата-сорсы для Tableau, даги в Airflow. Агент пишет код по тикету, гоняет тесты, проходит CI и ревью на общих основаниях. Доходит до забавного, в истории коммитов в Git уже порой не отличишь, где человек, а где агент. Секрет не в модели: в каждом репозитории лежит файл с правилами/скиллами — стайлгайд SQL, конвенции проекта, как деплоить, как тестировать, какая схема данных и т. д. и т. п. Агент читает всё это в начале сессии и пишет так, как принято у нас.

Ну и конечно, есть разного по мелочи — почитать Confluence, поискать в интернете, собрать google sheet и т. д. и т. п.

А как вы используете ИИ? 🙂

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

VAR — математическая взаимосвязь рядов

Всем привет, с вами Павел Беляев, ведущий канала Тимлидское об аналитике и автор курса «Временные ряды» 👋🏻

Анализировать один временной ряд — это хорошо, а два и более — лучше!

В природе и в бизнесе метрики, как правило, не существуют изолированно — на них что-то влияет, какие-то процессы, факторы, словом, другие метрики. Это сложное взаимодействие разных процессов подводит нас к понятию многомерных временных рядов.

Например, мы анализируем продажи, но на них влияет маркетинговый бюджет. А бюджет, в свою очередь, зависит от продаж прошлого месяца (логично — есть деньги, есть, что вкладывать). Получается замкнутый круг взаимных влияний, и обычная ARIMA тут не поможет — она умеет работать только с одним рядом.

Вот тут на сцену выходит VAR — Vector AutoRegression, векторная авторегрессия.

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

Что это даёт на практике:
➖ Совместный прогноз сразу нескольких метрик с учётом их взаимного влияния.
➖ Причинность по Грейнджеру — можем формально проверить, помогает ли история одного ряда предсказывать другой.
➖ Impulse Response Functions — можно смоделировать «шок» в одной переменной и посмотреть, как он расходится по системе во времени. А подсказывает нам, как изменится зависимая, неуправляемая метрика, если мы "подтолкнем" управляемую.

📈 В этом блокноте показано, как выглядит работа с VAR. На выходе мы имеем коэффициенты системы линейных уравнений, где количество уравнений равно количеству метрик в многомерном ряду, а число членов — это число значимых лагов, то есть, предыдущих значений в каждом ряду.

Эти коэффициенты, по сути, объясняют, какой лаг какой метрики влияет на всю систему.

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

Хотите научиться видеть не отдельные ряды, а целые системы взаимосвязанных процессов? Присоединяйтесь к курсу «Временные ряды», который стартует уже в субботу, 15 августа:

📌 Узнать больше о курсе «Временные ряды»
📌 Подписаться на бота уведомлений

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS