Симулятор SQL: чем он отличается от тренажёра и как в нём учатся

Коротко

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

• Тренажёр проверяет, умеете ли вы написать конструкцию. Симулятор — умеете ли вы понять, какая конструкция нужна и можно ли верить результату.
• Главное в симуляторе — данные с подвохом: неполный последний день, дубли событий, соединения, которые размножают строки, незрелые когорты.
• Вопрос сформулирован словами менеджера. Таблицы, период и определение метрики выбираете вы.
• Симулятор не заменяет основы. Если GROUP BY и JOIN ещё не знакомы, начинать лучше с курса, где одна тема — один урок.
• Проверить себя можно сразу: три запроса из этой статьи выполняются в песочнице без регистрации.

Что такое симулятор SQL

Слово «симулятор» пришло из обучения пилотов и врачей: там, где ошибка на работе стоит дорого, её сначала дают совершить в безопасной копии. В аналитике цена ошибки — решение, принятое по неверному числу. Отключили рекламный канал, который на самом деле окупался. Объявили падение аудитории, которого не было. Симулятор SQL воспроизводит такую ситуацию: база, похожая на рабочую, коллега с вопросом и последствия ответа.

От тренажёра его отличает не сложность запросов, а то, что именно проверяется. В тренажёре условие звучит так: «выведите число пользователей по каналам, отсортируйте по убыванию». В нём уже названо действие, группировка и порядок. В симуляторе тот же навык спрятан в вопрос: «Какой канал приводит людей, которые ничего не делают в продукте?» Прежде чем писать запрос, придётся решить, что значит «ничего не делают», за какой период смотреть и на что делить.

В поиске эти слова часто смешивают: по запросу «симулятор SQL» выдача показывает и тренажёры с задачами, и онлайн-редакторы, и курсы. Ниже они разведены по тому, что дают.

Три признака настоящего симулятора

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

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

Второй — вопрос вместо условия. В задании не сказано «используйте LEFT JOIN». Сказано, что нужно менеджеру и зачем. Если по формулировке можно написать запрос, не открывая схему, это тренажёр.

Третий — проверка выполнением на данных, которые ловят типичную ошибку. Хорошее задание устроено так, что запрос с перепутанным count(*) и count(DISTINCT user_id) даёт другое число. Если неверное решение проходит, потому что на учебных данных оно случайно совпало с верным, вы уносите ошибку с собой.

Пример первый: падение, которого не было

Вопрос менеджера: «В субботу, 30 августа, аудитория упала вдвое. Что сломалось?» Запрос на число активных пользователей по дням пишется за минуту, и он подтверждает тревогу: 541, 567, 506 — и вдруг 221.

В тренажёре на этом задача кончилась бы: число посчитано, ответ принят. В симуляторе это середина. Третий столбец запроса показывает время последнего события за день, и для 30 августа это 12:59, а для остальных дней — около девяти вечера. Выгрузку закрыли в час дня. День неполный, сравнивать его с полными нельзя, и правильный ответ менеджеру — «падения нет, суббота ещё не кончилась, в понедельник посмотрим целиком».

Привычка проверять границу периода не появляется от чтения правила. Она появляется, когда вы один раз почти отправили коллеге «аудитория упала на 56%».

SELECT CAST(event_time AS DATE) AS day,
       count(DISTINCT user_id) AS dau,
       max(event_time)         AS last_event
FROM events
WHERE event_name = 'app_open'
  AND CAST(event_time AS DATE) >= DATE '2026-08-27'
GROUP BY 1
ORDER BY 1;

Пример второй: строки — это не люди

Вопрос: «Сколько у нас платящих пользователей по каналам?» Естественное решение — соединить пользователей с платежами и посчитать строки. Запрос выполняется без ошибок и возвращает правдоподобные числа: 566 в organic, 384 в referral.

Но одна строка после такого соединения — это платёж, а не человек. Кто-то продлевал подписку и заплатил дважды. Платящих в organic 410, а не 566: наивный счёт завышает их на 38%. По всей базе 1251 платёж приходится на 912 человек. Выручка при этом верная в обоих вариантах, и именно поэтому ошибку легко не заметить: одна цифра в отчёте сходится с бухгалтерией, а соседняя — нет.

В симуляторе это правило формулируют как вопрос, который задают себе перед каждым запросом: «Одна строка результата — это что?» Пока на него нет ответа, считать рано.

SELECT u.channel,
       count(*)                  AS join_rows,
       count(DISTINCT u.user_id) AS payers,
       sum(p.amount)             AS revenue
FROM users AS u
JOIN payments AS p ON p.user_id = u.user_id
GROUP BY u.channel
ORDER BY revenue DESC;

Пример третий: вопрос, в котором нет определения

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

Дальше появляется техническая развилка. Если соединить пользователей с событиями обычным JOIN, из результата исчезнут те, кто отчёт не создал, — то есть ровно те, о ком спрашивали. Нужен LEFT JOIN к списку активированных и счёт по правой таблице: count(a.user_id) пропускает пустые значения и считает только нашедших пару.

Ответ: в paid_search отчёт создали 238 из 1015 зарегистрированных, 23,4%. В referral — 46,9%, вдвое больше. Это уже не упражнение на LEFT JOIN, а довод для разговора о рекламном бюджете. И сразу следующий вопрос, который задаст внимательный менеджер: а пользователи последних дней успели создать отчёт? Регистрации 29 августа сравнивают с июньскими, у которых было два месяца. Так из одного запроса вырастает тема незрелых когорт.

SELECT u.channel,
       count(*)         AS signups,
       count(a.user_id) AS activated,
       round(100.0 * count(a.user_id) / count(*), 1) AS activation_pct
FROM users AS u
LEFT JOIN (
  SELECT DISTINCT user_id
  FROM events
  WHERE event_name = 'report_created'
) AS a ON a.user_id = u.user_id
GROUP BY u.channel
ORDER BY activation_pct DESC;

Как устроен Симулятор SQL-аналитика

Все три примера взяты из учебной базы Симулятора SQL-аналитика КейсПрактики. Это вымышленный продукт «Маяк», в котором пользователи создают рабочие пространства и отчёты. В полной базе пять таблиц и 45 185 строк: пользователи, события, платежи, подписки и участники A/B-эксперимента. Регистрации идут с 1 июня по 29 августа 2026 года, выгрузка закрыта 30 августа в 13:00.

В симуляторе 18 глав и 55 заданий на запрос. Главы о языке идут на небольшой выборке из той же базы, чтобы результат можно было проверить глазами. Аналитические кейсы и песочница работают на полной базе. Каждый запрос выполняет сервер и сравнивает результат с эталоном; принимается один SELECT или WITH.

Задания кейсов построены на данных с заложенной ошибкой. В главе про DAU к базе добавлена повторная доставка событий за 25 августа: 511 открытий приложения пришли дважды. Запрос через count(*) даёт за этот день 1022, запрос через count(DISTINCT user_id) — 511, и проверка принимает только второй.

Четыре главы открыты без оплаты и без регистрации: устройство базы, первый SELECT, WHERE и первый аналитический кейс про DAU. В них 11 заданий. Этого хватает, чтобы понять, подходит ли формат.

Кому симулятор нужен, а кому пока рано

Симулятор — не первая ступень. Он предполагает, что вы уже можете написать запрос с фильтром и группировкой и не тратите внимание на то, где ставится запятая. Если это пока не так, вопрос менеджера и незнакомый синтаксис сложатся в двойную нагрузку, и вы будете угадывать, а не думать.

Тем, кто начинает с нуля, удобнее курс, где одна тема — один урок, а задача стоит сразу под объяснением. В курсе «SQL с нуля» 31 урок и 94 задачи; первые 10 уроков открыты бесплатно. После него в симуляторе можно начать сразу с шестой главы, с первого кейса.

Тем, кто готовится к собеседованию, симулятор полезен в паре с задачником. Задачник тренирует скорость. Симулятор — умение объяснить решение вслух и ответить на «а почему вы уверены в этом числе?», на чём обычно и теряются.

Тем, кто уже работает аналитиком, симулятор даст меньше всего: рабочая база и есть лучший симулятор. Исключение — темы, с которыми вы пока не сталкивались: когортный retention или разбор A/B-теста по сегментам.

Как заниматься, чтобы навык переносился на работу

Симулятор можно пройти как тренажёр: подбирать запрос, пока проверка не примет. Так он ничего не даст. Четыре привычки, ради которых формат существует, приходится включать самому.

• До запуска назовите ожидаемый порядок числа: сотни или тысячи, около 20% или около 60%. Если результат не попал в ожидание, разберитесь, кто ошибся — вы или запрос.
• Перед запросом скажите вслух, что такое одна строка результата: пользователь, платёж, день, пара «пользователь и день».
• После каждого соединения сравните число строк с числом уникальных ключей. Расхождение — не всегда ошибка, но всегда повод остановиться.
• Закончив, напишите ответ одной фразой, как написали бы коллеге в рабочий чат. Число без вывода — это половина задания.

Частые вопросы о симуляторах SQL

Итог

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