Большинство начинающих аналитиков тратят месяцы на изучение Python, статистики и Excel — а потом на первом же реальном собеседовании выясняют, что без SQL они не пройдут даже техническое интервью. SQL — это не «программирование для программистов». Это язык, на котором бизнес разговаривает с данными, и без него карьера аналитика не начнётся.
Зачем аналитику данных нужен язык SQL
SQL (Structured Query Language) — это декларативный язык запросов к реляционным базам данных. Именно через него аналитик получает доступ к тем самым данным, с которыми потом работает: строит отчёты, считает метрики, формирует выгрузки для дашбордов. SQL создан в 1974 году и применяется для создания, обработки и управления данными в реляционных базах данных.
Почему SQL — это не опция, а базовый навык? В анализе вакансий SQL уверенно обгоняет Python и R: знанием языка R интересовались лишь в единицах позиций, тогда как SQL упоминается повсеместно. На собеседовании на позицию продуктового или дата-аналитика SQL-секция занимает от 40 минут до 1,5 часов, а SQL проверяют в 89% собеседований на аналитические позиции — больше, чем Python и Excel вместе взятые.
Анализ вакансий на hh.ru за 2024–2025 годы показывает: SQL и Excel — это минимум, который нужен почти везде. Как крупные корпорации, так и стартапы нанимают специалистов по анализу данных. Среди работодателей, публиковавших вакансии SQL-аналитиков, — банки (Тинькофф, Росбанк, Альфа-Банк), ритейл (Магнит, Ozon), телеком (Билайн).
Теперь о страхе перед «программированием». SQL — не язык разработки в привычном смысле. Здесь не нужно писать алгоритмы, управлять памятью или строить классы. SQL работает по принципу «скажи, что хочешь получить, а база данных разберётся как». Логика запросов читается почти как человеческий язык: SELECT (выбери) — FROM (из таблицы) — WHERE (где выполняется условие). Это намного ближе к формулам Excel, чем к коду на Python.
Конкретные задачи, которые аналитик решает через SQL каждый день:
- 🔍 Выгрузка данных — получить нужный срез из миллионов строк за секунды
- 📊 Отчётность — автоматизировать регулярные отчёты по продажам, конверсии, активности
- 📐 Расчёт метрик — считать DAU, MAU, LTV, retention, средний чек прямо в базе
- 🔗 Объединение источников — связывать данные из CRM, транзакционных систем и логов
- 🧹 Контроль качества данных — искать дубликаты, пропуски, аномалии
Аналитик получает информацию из разных источников — баз данных, CRM-систем, сайтов, приложений, использует SQL для поиска закономерностей и трендов, создаёт графики, дашборды и отчёты. SQL — инструмент первого касания с данными, без которого всё остальное просто не работает.
Как устроены базы данных и таблицы для старта
Прежде чем писать первый запрос, нужно понять, с чем именно вы работаете. База данных — это организованное хранилище информации. Внутри неё данные хранятся в таблицах — структурах, напоминающих Excel-листы. Каждая таблица состоит из строк (записей, или кортежей) и столбцов (полей, или атрибутов). Строка — это один объект или событие. Столбец — одна характеристика этого объекта.
Ключевые понятия, без которых не обойтись:
- 🔑 Первичный ключ (Primary Key) — уникальный идентификатор каждой строки в таблице. Например, order_id в таблице заказов. Гарантирует, что две записи не будут одинаковыми.
- 🔗 Внешний ключ (Foreign Key) — столбец, который ссылается на первичный ключ другой таблицы. Через него и строятся связи между таблицами.
Реляционные базы данных структурируют данные в таблицы со строками и столбцами: строки являются записями, а столбцы — полями. Зачастую эти данные имеют отношения друг с другом или зависимости.
Реляционные vs нереляционные базы данных — просто о сложном. Реляционная база (РСУБД) хранит данные в таблицах с жёсткой схемой и связями между ними. Это PostgreSQL, MySQL, SQLite. Нереляционная (NoSQL) — хранит данные в виде документов, графов или пар «ключ-значение» без фиксированной структуры. Это MongoDB, Redis, Cassandra. С всплеском популярности искусственного интеллекта и машинного обучения NoSQL-системы набирают вес, поскольку в них часто обрабатываются огромные массивы неструктурированных данных. Аналитику данных на старте нужны именно реляционные базы — они составляют основу большинства корпоративных хранилищ.
Типы данных в таблицах — это то, какой вид информации хранится в каждом столбце:
| Тип данных | Примеры | Примеры столбцов |
| Числа (INTEGER, FLOAT, NUMERIC) | 42, 3.14, 1000000 | order_id, price, quantity |
| Строки (VARCHAR, TEXT) | 'Иван', 'Москва' | name, city, category |
| Даты и время (DATE, TIMESTAMP) | '2025-01-15', '2025-01-15 12:30:00' | order_date, created_at |
| Логические (BOOLEAN) | TRUE / FALSE | is_active, is_paid |
| NULL | отсутствие значения | любой столбец с пропуском |
Связи между таблицами — это архитектурный фундамент реляционной базы. Например, есть таблица users (пользователи) и таблица orders (заказы). В таблице orders хранится столбец user_id — внешний ключ, который ссылается на поле id в таблице users. Это означает, что каждый заказ привязан к конкретному пользователю. Такая структура позволяет хранить данные без дублирования и соединять их в нужный момент через запросы.
Базовые команды SQL для выборки данных
Это критически важный момент: вы пишете SELECT в начале запроса, но база данных выполняет его почти последним. Понимание этого порядка объясняет, почему нельзя использовать алиас из SELECT в условии WHERE — на момент выполнения WHERE этого алиаса ещё не существует.
SELECT и его структура. Базовый запрос выглядит так: SELECT столбец1, столбец2 FROM таблица. Если нужны все столбцы — пишут SELECT *. Но на практике лучше указывать конкретные столбцы: это делает запрос быстрее и читаемее.
Фильтрация через WHERE. WHERE отсекает строки, которые не соответствуют условию. Логические операторы позволяют строить сложные фильтры:
- AND — оба условия должны выполняться одновременно
- OR — достаточно одного из условий
- NOT — инвертирует условие
- IN — значение входит в список: WHERE city IN ('Москва', 'СПб')
- BETWEEN — значение в диапазоне: WHERE price BETWEEN 100 AND 500
- LIKE — поиск по шаблону: WHERE name LIKE 'Ив%'
- IS NULL / IS NOT NULL — проверка на отсутствие значения
Сортировка ORDER BY и ограничение LIMIT. ORDER BY задаёт порядок строк в результате: ASC — по возрастанию (по умолчанию), DESC — по убыванию. LIMIT ограничивает число возвращаемых строк: LIMIT 10 вернёт первые десять строк после сортировки. Это незаменимо при первичном знакомстве с данными или при построении топ-списков.
DISTINCT для устранения дубликатов. SELECT DISTINCT city FROM orders вернёт список уникальных городов из таблицы заказов. Важно понимать: DISTINCT работает по всей комбинации выбранных столбцов, а не по одному из них. Если написать SELECT DISTINCT city, status FROM orders — уникальность проверяется по паре (city, status).
Агрегация и группировка данных в SQL
GROUP BY — движок группировки. GROUP BY разбивает строки таблицы на группы по значению одного или нескольких столбцов, а затем применяет агрегирующую функцию к каждой группе отдельно. Например: SELECT city, COUNT(*) FROM orders GROUP BY city — вернёт количество заказов по каждому городу. Важное правило: все столбцы в SELECT, которые не являются агрегатами, обязаны присутствовать в GROUP BY.
HAVING vs WHERE — в чём разница. WHERE фильтрует строки до группировки — работает с исходными данными. HAVING фильтрует группы после группировки — работает с результатами агрегации. Например, WHERE price > 1000 отфильтрует строки с ценой ниже 1000 ещё до подсчёта. А HAVING COUNT(*) > 5 оставит только те группы, в которых оказалось больше 5 записей. Использовать HAVING без GROUP BY бессмысленно.
Практические бизнес-метрики, которые считаются через агрегацию:
- 💰 Выручка за период: SUM(amount) WHERE order_date BETWEEN .....
- 👥 Количество уникальных покупателей: COUNT(DISTINCT user_id)
- 🧾 Средний чек: AVG(order_amount) GROUP BY месяц
- 📦 Топ-категории по продажам: SUM(revenue) GROUP BY category ORDER BY 1 DESC
- 📅 Дни с аномальной активностью: HAVING COUNT(*) > пороговое значение
Анна Серёгина, продуктовый аналитик
Я пришла в аналитику из маркетинга. Умела делать сводные таблицы в Excel, знала Google Analytics, могла нарисовать воронку. Казалось — этого достаточно. Первое собеседование в продуктовую команду расставило всё по местам. Технический вопрос звучал просто: «Посчитай среднее время между первым и вторым заказом по каждому городу». Я знала, что нужно сделать — но не знала, как это написать. Проект прошёл мимо.
После этого я дала себе месяц на SQL. Без курсов, только практика: брала открытый датасет интернет-магазина и каждый день придумывала себе задачи. Сначала — простые выборки и фильтрация. Потом — GROUP BY и агрегаты. Потом — первые JOIN. На третьей неделе я решила ту самую задачу про среднее время. Просто написала: считаем дату первого и второго заказа через MIN и второй MIN с подзапросом, джойним, вычитаем, группируем по городу. Элегантно — нет. Работает — да.
На следующем собеседовании аналогичный вопрос решила за четыре минуты. Оффер получила в тот же день. SQL не стал для меня страстью — он стал инструментом. Молотком, который просто должен быть в ящике.
Объединение таблиц через JOIN для аналитика
Реальные данные никогда не хранятся в одной таблице. Информация о пользователях — в одном месте, о заказах — в другом, о платёжных транзакциях — в третьем. JOIN — механизм, который позволяет соединить эти таблицы в один результат, опираясь на ключи связи.
Виды соединений и их логика:
| Тип JOIN | Что возвращает | Когда использовать |
| INNER JOIN | Только строки, для которых есть совпадение в обеих таблицах | Нужны только «полные» пары: заказы с известным пользователем |
| LEFT JOIN | Все строки левой таблицы + совпадающие из правой (NULL если нет пары) | Нужны все пользователи, в том числе те, кто не сделал заказ |
| RIGHT JOIN | Все строки правой таблицы + совпадающие из левой | Используется редко — чаще заменяют LEFT JOIN с переставленными таблицами |
| FULL JOIN | Все строки из обеих таблиц, NULL там, где нет пары | Нужно сравнить два набора данных и найти расхождения |
Логика объединения. JOIN работает по условию ON: LEFT JOIN orders ON users.id = orders.user_id. База перебирает каждую строку левой таблицы и ищет совпадения в правой. Если соответствие найдено — строки соединяются. Если нет — зависит от типа JOIN: INNER отбросит строку, LEFT оставит с NULL.
Частые ошибки новичков с JOIN:
- 🚨 Декартово произведение — JOIN без условия ON или с неверным ключом. Если в таблице A 1 000 строк, а в B — 1 000, результат будет 1 000 000 строк. База не упадёт, но запрос зависнет.
- 🚨 Дублирование строк при связи «один ко многим» — если один пользователь имеет несколько заказов, при JOIN каждая строка пользователя повторится для каждого его заказа. Это не ошибка — это ожидаемое поведение, которое нужно контролировать.
- 🚨 Путаница LEFT и INNER — при INNER JOIN пользователи без заказов молча пропадают из результата. Это искажает метрики. Всегда думайте: нужны мне «все» или только «совпавшие»?
- 🚨 NULL в условиях WHERE после LEFT JOIN — если написать LEFT JOIN и потом WHERE orders.order_id IS NOT NULL — это превратит LEFT JOIN в INNER JOIN, потому что строки с NULL будут отфильтрованы.
Продвинутые инструменты SQL для роста аналитика
После освоения SELECT, WHERE, GROUP BY и JOIN открывается следующий уровень — инструменты, которые отделяют уверенного аналитика от новичка. На многих собеседованиях middle-уровня именно они становятся водоразделом.
Подзапросы (subqueries). Вложенный запрос — это запрос внутри другого SQL-запроса, который разбивает сложный процесс выборки или анализа на более мелкие шаги. Подзапросы бывают в секции FROM (производная таблица), в WHERE (условие через результат запроса) и в SELECT (вычисляемый столбец). Например: SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE city = 'Москва'). Подзапросы работают, но у них есть ограничение — с ростом вложенности код становится нечитаемым.
CTE (Common Table Expressions) — общие табличные выражения. CTE — одна из самых мощных и недостаточно используемых функций SQL. Они позволяют определять временные именованные наборы результатов, которые можно использовать в более крупном запросе. CTE могут включать объединения, агрегации, оконные функции — и разбивают сложные запросы на логичные части, которые легче понять и поддерживать. Синтаксис: WITH имя_cte AS (SELECT ...) SELECT * FROM имя_cte WHERE .... CTE — это читаемость и структура там, где подзапросы создают хаос.
Оконные функции (Window Functions). В отличие от агрегатных функций, которые группируют данные с помощью GROUP BY, оконные функции вычисляют значения для каждой строки отдельно, что позволяет использовать как исходные, так и обработанные данные одновременно. Чаще всего оконные функции применяются для ранжирования, кумулятивных вычислений, анализа временных рядов, метода скользящего среднего и вычисления разниц между строками. Ключевые функции: ROW_NUMBER(), RANK(), LAG(), LEAD(), SUM() OVER(), AVG() OVER(). Оконные функции доступны в большинстве современных СУБД, включая PostgreSQL, Oracle, SQL Server и MySQL начиная с версии 8.0.
Работа с датами и временем. Аналитик почти всегда работает с временными рядами: динамика по дням, когортный анализ, сравнение периодов. Ключевые функции: DATE_TRUNC() (усечь до месяца/недели/дня), EXTRACT() (вытащить год, месяц, час), DATE_DIFF() (разница между датами), NOW() / CURRENT_DATE (текущее время). Даты позволяют группировать по периодам и строить хронологию событий — основу любого продуктового анализа.
CASE — условная логика и категоризация. CASE — аналог IF/ELSE прямо внутри SQL-запроса. Синтаксис: CASE WHEN условие THEN значение WHEN другое_условие THEN другое_значение ELSE по_умолчанию END. Условия CASE WHEN используются для разметки данных — например, для присвоения группы в ABC-анализе. Практические применения: сегментация пользователей по активности, разбивка суммы заказа на диапазоны, пометка аномальных значений.
Дорожная карта изучения SQL для аналитика
Чаще всего начинающие делают одну из двух ошибок: либо изучают слишком мало и заходят на собеседование неготовыми, либо тратят месяцы на темы, которые на реальных задачах не встречаются первый год. Вот честная карта минимума и роста.
Минимальный уровень для джуниора:
- ✅ SELECT, FROM, WHERE с логическими операторами
- ✅ ORDER BY, LIMIT, DISTINCT
- ✅ GROUP BY + агрегирующие функции COUNT, SUM, AVG, MIN, MAX
- ✅ HAVING
- ✅ INNER JOIN и LEFT JOIN (это нужно понимать отлично)
- ✅ Базовая работа с датами (DATE_TRUNC, EXTRACT)
- ✅ CASE WHEN
- ✅ Простые подзапросы
Минимум для входа в профессию: Excel, SQL, основы Python. SQL при этом — приоритет номер один: без него вы не получите данные для работы ни в одном из других инструментов.
Оптимальная последовательность освоения:
- SELECT / FROM / WHERE / ORDER BY / LIMIT — 3–5 дней практики
- Агрегаты и GROUP BY / HAVING — 5–7 дней
- JOIN (начать с INNER и LEFT, понять RIGHT и FULL) — 7–10 дней
- Подзапросы + CASE WHEN — 5 дней
- CTE — 3–5 дней
- Работа с датами — 3–4 дня
- Оконные функции — 10–14 дней (это требует времени)
Что проверяют на собеседованиях. На собеседовании на позицию продуктового или дата-аналитика SQL-секция занимает от 40 минут до 1,5 часов интервью. Типичный набор задач: написать запрос с GROUP BY и HAVING, соединить 2–3 таблицы через JOIN и посчитать метрику, найти дубликаты или пользователей без активности, посчитать retention или когорту. На джуниора — без оконных функций. На middle — с ними.
Как понять, достаточно ли знаний: если вы можете за 10–15 минут написать запрос, который считает количество уникальных активных пользователей по каждому городу за последние 30 дней, с фильтром на минимальное число заказов и сортировкой по убыванию — уровень джуниора закрыт. Куда двигаться дальше: оконные функции, оптимизация запросов (индексы, EXPLAIN), работа с большими данными в ClickHouse или BigQuery.
Где практиковаться и закреплять навыки SQL
Знание теории без практики — бесполезный груз. SQL учится руками. Вот конкретные форматы, которые работают.
Тренажёры и интерактивные платформы:
- 🖥️ SQLZoo — бесплатные интерактивные уроки прямо в браузере, от базовых SELECT до оконных функций
- 🖥️ LeetCode (раздел Database) — задачи с автопроверкой, хорошо имитируют формат собеседований
- 🖥️ sql-ex.ru — русскоязычный тренажёр с большой базой задач и трекингом прогресса
- 🖥️ Mode Analytics SQL Tutorial — практика на реальных датасетах с объяснениями
- 🖥️ Kaggle (SQL курсы) — бесплатно, с открытыми датасетами и задачами аналитического характера
Тренажёры предлагают большую базу задач от базового до продвинутого уровня с автопроверкой и трекингом прогресса — хорошо подходят для интервальной практики перед собеседованиями.
Выбор СУБД для старта. Три главных варианта для начинающих аналитиков:
- ⚙️ PostgreSQL — лучший выбор для глубокого изучения. PostgreSQL включает расширенные функции SQL, такие как рекурсивные запросы, оконные функции и общие табличные выражения. Де-факто стандарт в аналитических командах и дата-инженерии.
- ⚙️ MySQL — самая популярная и часто используемая реляционная СУБД. Хорошо подходит для работы с веб-приложениями и как первый опыт с серверными базами.
- ⚙️ SQLite — встраиваемая библиотека, предоставляющая отличный набор инструментов для более простой обработки данных без необходимости разворачивать сервер. Идеально для первых шагов: скачали, открыли, начали писать запросы.
Рекомендация: начните с SQLite для первых экспериментов, затем переходите на PostgreSQL — это тот диалект SQL, который встречается чаще всего в реальной работе аналитика.
Как тренироваться на реальных задачах. Абстрактные упражнения быстро надоедают. Возьмите открытый датасет с Kaggle (например, датасет интернет-магазина, такси-поездок или транзакций) и поставьте себе бизнес-вопрос: «Какие категории товаров дают наибольший доход в марте?» — и напишите запрос, который отвечает на него. Взять открытый датасет и провести полноценный анализ с визуализацией — это портфолио, которое работает.
Типичные ошибки начинающих при отработке навыка:
- ❌ Читать, а не писать — SQL нельзя выучить пассивно. Каждую конструкцию нужно написать самому, получить ошибку и исправить её.
- ❌ Не читать сообщения об ошибках — СУБД всегда сообщает, что пошло не так. Научитесь читать error message — это сэкономит часы.
- ❌ Пропускать EXPLAIN — даже на старте полезно смотреть план выполнения запроса. Это формирует правильное мышление о производительности.
- ❌ Избегать JOIN — многие новички пишут несколько отдельных запросов вместо одного с соединением. Это замедляет работу и не проходит на собеседованиях.
- ❌ Не проверять результат на аномалии — после каждого запроса смотрите: реалистичны ли цифры? Не стало ли строк вдруг в 10 раз больше? Это признак ошибки в JOIN.
Хорошая точка отсчёта для самопроверки — документация PostgreSQL на официальном сайте postgresql.org/docs и учебные материалы платформы Хабр, хаб SQL — там собраны разборы реальных задач от практикующих аналитиков. Анализ вакансий и требований работодателей удобно отслеживать на hh.ru.
SQL — не магия и не барьер для «нетехнарей». Это инструмент с чёткой логикой: понял структуру запроса, освоил базовые команды, научился соединять таблицы и считать агрегаты — и ты уже решаешь 80% реальных аналитических задач. Дальше — оконные функции, CTE, работа с датами. Двигайтесь последовательно, практикуйтесь на реальных данных и не ждите момента, когда «будете готовы»: готовность приходит только через написанные запросы, а не через прочитанные статьи.
