У нас есть продукт и нам нужно рассчитать ключевые метрики, которые показывают здоровье продукта:
- DAU/MAU – вовлеченность
- Conversion Rate – конверсия в целевое действие (у нас это создание объявления)
- Retention – удержание пользователей
- LTV – жизненная ценность клиента
- ARPPU – средний доход с платящего пользователя
В статье разберем последовательный расчет с примером синтетических данных и готового кода на SQL.
Проблема N+1 стара как мир. Инструментов много: Debugbar хорош локально, Telescope тяжеловат для продакшена. Мне хотелось решения, которое будет «стучать» в Slack или Telegram именно тогда, когда проблема случилась на проде, и при этом сразу показывать пальцем на виновную строку кода.
Работая с аналитикой, мы часто сталкиваемся с одной и той же проблемой: данные есть, но исследовать их неудобно.
Представим типичную ситуацию. Есть таблица с десятками колонок и миллионами строк. Нужно понять, почему изменился какой-то показатель — например, выручка или конверсия. Обычно это превращается в цепочку SQL-запросов: сначала агрегируем данные по стране, потом по городу, потом по конкретному сегменту пользователей и тд.
Если таких гипотез несколько, количество запросов быстро растёт с геометрической прогрессией. Каждый новый уровень детализации требует отдельного SQL.
В какой-то момент хочется просто кликнуть по графику и мгновенно увидеть более детальные данные. Без написания нового запроса.
Именно здесь на помощь приходят BI-инструменты. Один из самых популярных open-source инструментов для аналитики — Apache Superset.
Почему SUM() OVER (ORDER BY ...) иногда даёт неожиданный результат, даже когда запрос синтаксически правильный? В статье на практических примерах разбираю, как работают оконные фреймы в SQL, чем отличаются ROWS, RANGE и GROUPS, где чаще всего возникает путаница и как писать накопительные итоги и скользящие метрики без сюрпризов. Если используете оконные функции в аналитике, этот разбор поможет сделать их поведение предсказуемым и управляемым.
Договоримся о терминах:·
*Шардинг БД (db sharding) — это метод горизонтального масштабирования, при котором большая база данных разбивается на более мелкие, независимые части (shards), размещаемые на разных физических или виртуальных серверах. Каждый шард содержит подмножество данных, что снижает нагрузку на отдельные узлы, ускоряет запросы и позволяет хранить большие объемы информации, преодолевая ограничения вертикального масштабирования
**Read consistency (согласованность чтения) в БД — это гарантия того, что транзакция видит согласованное состояние данных, соответствующее определенному моменту времени (обычно моменту начала транзакции или запроса).
Эта статья будет полезна в первую очередь студентам и начинающим разработчикам. В начале своего пути получения навыков проектирования и разработки программ каждому начинающему специалисту нужно на что-то опираться. Потом появится собственный опыт и собственные представления о том, как хорошо и как правильно. Я предлагаю познакомиться с идеями, которые могут стать такой первоначальной опорой.
SQL в 2026: что реально нужно знать аналитику? 🤔
Спойлер: не только JOIN и GROUP BY, а еще и оконные функции, когортный анализ, оптимизация запросов и работа с BigQuery.
Пошаговый план для новичков с бесплатными тренажерами, курсами (да, Карпов там есть) и списком тем, без которых вас не наймут.
Давайте разберем четкий план: что учить, где брать практику и как не потеряться в море информации 👇
Привет, Хабр!
Меня зовут Андрей Жуйков, и в этой статье я хочу рассказать вам историю абсолютно практического содержания. Без теоретических рассуждений и без лозунгов про импортозамещение. Это реальный кейс о том, как мы перевели несколько наших корпоративных 1С с Microsoft SQL Server на Digital Q.DataBase.
Бывают ситуации, когда есть список значений, и нужно найти значения, которых нет в БД. Прямым SQL-запросом найти отсутствующие значения невозможно, так как из базы нельзя получить значения, которых там нет. В статье рассмотрим какие есть замены временным таблицам в SQL.
Спроси любого уважаемого аналитика или инженера данных о том, какие бывают способы моделирования данных, тебе ответят: звезда, 3NF и DataVault. Спроси ИИ, получишь примерно такой же ответ. Придешь на какой-нибудь проект в компанию, также скорее всего встретишь там кого-нибудь из этих друзей. В 90% материалах про методологии моделирования освещаются только эти трое. Как будто других методологий не существует.
Да, эта троица, наверное, самая популярная и подходящая под большую часть задач, но в мире есть еще уйма других не менее интересных способов как организовать свои данные. И сегодня мы постараемся целиком их рассмотреть.
Аналитик данных сегодня –это не человек, который умеет просто выгружать данные и знает SQL и этого достаточно, сейчас это человек-оркестр, который умеет выбирать правильный инструмент под задачу, конечно, где-то может быть и достаточно Excel, а для каких-то задач уже нужен сложный запрос с оконными функциями, а где-то нужно собрать быстрый дашборд в Power BI, чтобы заказчик сам мог смотреть цифры.
В этой статье разберу реальный инструментарий аналитика – не тот, который пишут в идеальных вакансиях, а тот, который реально используется в работе.
В ритейле каждый сантиметр полки – это деньги (буквально). В этой статье я разберу примеры задач, которые решает аналитик в ритейле, и покажу, как их решать на SQL.
Каждая задача сложнее предыдущей для каждой есть код и готовые синтетические данные, поэтому все результаты можно получить самостоятельно, повторив код.
«Поднятие» унаследованного Postgres без специнструментов быстро превращается в головную боль: вас ждет ручной разбор схем, перелопачивание десятков таблиц и прочая невеселая археология - где лежат персональные данные, что за колонки, как это всё соотносится с 152-ФЗ… Один неверный шаг – и можно запросто упустить что-то важное. Встроенного защитного преобразования данных на диске нет, приходится либо городить огород на уровне приложений, либо создавать триггеры. Хранить ключи, тестировать производительность, поддерживать это всё, руками выставлять фильтры, думать, куда писать логи, как следить за аномалиями и так далее. Всё, что связано с безопасностью – проверять вручную. Любое изменение схемы — снова садись и аудируй заново. Времени уходить будет очень много, и неизвестно, какие грабли вылезут.
В СУБД Tantor Certified то, что обычно делается на коленке, превращается в понятный и безопасный процесс, который подробно описывается в статье.
В этой статье мы разберём, как PostgreSQL обрабатывает запросы, изучим работу планировщика запросов и освоим анализ отчётов EXPLAIN ANALYZE — важнейшего инструмента оптимизации запросов. Эти знания помогут вам находить и устранять узкие места в производительности, оптимизировать запросы и предотвращать проблемы, из-за которых СУБД может работать медленнее.
SQL для аналитика: разбор 4 задач со скриптами и примерами данных
Собрала 4 задачи, которые решала на старте карьеры на реальных проектах, и показываю:
- как обычный GROUP BY превращается в полноценный ABC-анализ;
- как оконные функции помогают увидеть динамику, которую в Excel считать часами;
- как найти неэффективные категории (даже если по цифрам всё "нормально");
- как построить прогноз на паре оконных функций.
Внутри:
- Скрипты с пояснениями;
- Сгенерированные данные (можно скопировать и проверить);
- Пример бизнес-вывода к каждому запросу.
Статья для аналитиков, которые хотят прокачать SQL и понимать, что на самом деле происходит в их данных.
CJM в аналитике: почему ваши клиенты уходят и как это увидеть в данных
Вы наверняка видели красивые CJM-картинки с эмоциями, лицами и стрелочками, это красиво, но бесполезно, потому что настоящая карта пути клиента строится на данных, CJM – это не про «нарисовать портрет клиента», это про цифры, воронки и узкие места.
В этой статье я рассказываю:
- Что такое CJM с точки зрения данных (и почему это не про эмоции);
- SQL-скрипты для построения воронки, расчета времени между этапами и анализа переходов;
- Как искать узкие места, где клиенты реально страдают (и теряются деньги).
👉 Без абстракций, с кодом и готовыми данными для проверки.
Привет, Хабр! Это четвёртая статья из серии про QA собеседования. Уже разобрали тест-дизайн, API и Security и System Design. Теперь — SQL. На собеседованиях SQL задают чаще, чем многие ожидают. Не уровня DBA, но и не SELECT * FROM users. Обычно дают таблицу и просят написать запрос прямо на доске или в Google Docs. Если впадаете в ступор при слове JOIN — эта статья для вас.
Статья представляет компактную математическую нотацию для SQL-препроцессора, разработанную для формирования сложных условных выражений из JSON-конфигураций. Нотация позволяет кратко записывать операции с множествами и интервалами: комбинированные операторы (>=[18,65]), стрелочные символы для интервалов (>> — BETWEEN, >< — NOT BETWEEN) и логическое отрицание через знак минус. Цель — создать интуитивно понятный, непротиворечивый и расширяемый язык запросов. Практическое применение — генерация SQL-кода в препроцессорах, DSL для построителей запросов, компактные фильтры в JSON-API. Рассматриваются сильные стороны и потенциальные проблемы нотации, сравнительный анализ с аналогами (Quist, SQL++, PRQL), выявляется уникальность подхода. Автор приглашает к обсуждению и предлагает сотрудничество.
В статье разберем реальную задачу аналитика ассортимента в ритейле: «Какие товары люди покупают вместе», на учебных данных, с кодом SQL, со всей необходимой математикой и с примером выводов.
Когда я решила стать аналитиком, я не знала про SQL вообще ничего, совсем, базовое образование у меня экономическое и в университете SQL нам никто не преподавал.
В этой статье приведу пример 5 задач, которые меня научили SQL по-настоящему, все они построены на том, с чем работает аналитик ассортимента: товары, категории, продажи и поставки.
