AI-промты для SQL-запросов в аналитике

Роль: Ты Senior Data Engineer с 8 лет опыта в оптимизации аналитических SQL-запросов. Экспертиза: EXPLAIN ANALYZE, индексы B-tree и BRIN, партиционирование в [PostgreSQL/ClickHouse].

Контекст: Я Data Analyst в [тип компании — e-commerce/финтех]. Витрина: [название таблицы] объёмом [кол-во строк] с партициями по [поле партиционирования]. Запрос выполняется [время выполнения] и блокирует дашборд [название BI]. Текущий план: [вывод EXPLAIN ANALYZE].

Задача: Провести аудит запроса, найти узкие места и предложить 3 варианта оптимизации с оценкой ускорения в процентах.

Формат вывода: (1) Таблица 'Проблема → Причина → Метрика плана' по строкам EXPLAIN. (2) Переписанный SQL с комментариями к каждому изменению. (3) Чек-лист: какие индексы/материализованные представления создать и оценка прироста скорости.

Детали: Опирайся на best practices [SQL-диалект]. Избегай советов вида 'добавьте индекс на всё'. Учитывай стоимость записи и размер данных. Если нужен рефакторинг схемы — обозначь это отдельно.

Роль: Ты Lead BI-разработчик с 10 лет опыта в менторинге аналитиков. Экспертиза: стандарты SQL Style Guide (Mozilla, GitLab), CTE, window functions, тестирование витрин через dbt.

Контекст: Я тимлид команды из [кол-во аналитиков] человек. Джуниор прислал запрос на ревью: [вставить SQL-код]. Источник данных: [events/orders/sessions]. Целевая метрика: [название метрики, например DAU или AOV]. Используемый диалект: [PostgreSQL/BigQuery/ClickHouse].

Задача: Сделать конструктивное ревью кода в формате pull-request комментариев, указать антипаттерны и предложить обучающие материалы.

Формат вывода: (1) Таблица замечаний: строка кода, тип проблемы (корректность/производительность/читаемость), серьёзность (blocker/major/minor), предложение. (2) Переписанный запрос с CTE и комментариями. (3) 3 ссылки на документацию/статьи для самообучения джуниора.

Детали: Тон уважительный, объясняй 'почему', а не только 'как'. Проверь NULL-обработку, JOIN-логику, корректность агрегатов. Не переписывай всё с нуля — сохраняй авторский стиль где возможно.

Роль: Ты Senior Analytics Engineer с 6 лет опыта в построении слоя данных в [Snowflake/BigQuery]. Экспертиза: dbt docs, data contracts, нотация dimensional modeling по Kimball.

Контекст: Я аналитик, готовлю витрину [название витрины] в схеме [schema_name] для дашборда [название BI-отчёта]. Источники: [таблица 1], [таблица 2]. Гранулярность: [одна строка = что]. Бизнес-владелец: [отдел/роль].

Задача: Сформировать полный документ витрины, пригодный для публикации в Confluence и dbt docs.

Формат вывода: (1) Заголовок + бизнес-описание витрины (3-5 предложений). (2) Таблица полей: имя, тип, описание, источник, правила трансформации, пример значения. (3) Раздел 'Метрики и определения' со SQL-формулой каждой метрики. (4) Раздел 'Известные ограничения и SLA обновления'.

Детали: Используй единый глоссарий терминов. Для сложных join-ов покажи ER-диаграмму в mermaid. Избегай технического жаргона в бизнес-описании — его читают продакты.

Роль: Ты эксперт по Data Quality с 7 лет опыта внедрения Great Expectations и Soda Core. Экспертиза: тесты целостности, свежести и распределений в [ClickHouse/PostgreSQL].

Контекст: Я Middle Data Analyst, готовлю к релизу дашборд [название] для [бизнес-заказчик]. Витрина строится из [источник данных — events/transactions]. Период обновления: [частота ETL]. Ключевые метрики: [метрика 1], [метрика 2].

Задача: Составить чек-лист DQ-проверок с готовыми SQL-тестами, которые аналитик запустит до публикации.

Формат вывода: (1) Таблица проверок: категория (uniqueness/freshness/volume/distribution), описание, SQL-запрос, ожидаемый результат, действие при провале. (2) Скрипт сверки метрик дашборда с source-of-truth (расхождение ≤ [допустимый порог, %]). (3) Шаблон отчёта о прогоне для Slack-канала [название канала].

Детали: Минимум 10 проверок, из них 3 — на бизнес-логику (например, сумма заказов ≥ 0). Учитывай особенности [SQL-диалект]. Избегай проверок, которые выполняются дольше 30 секунд без необходимости.