Стрим завтра, 8 мая 20:00 мск

Разбираемся в разнице систем дизайн интервью в корпорации и стартапе

В гостях Макс C и Дима К

https://youtube.com/live/pZBve6IJ3WI?feature=share

Мокаемся в Study & Learn

В OpenAI завезли Study & Learn. Я решил попробовать на o3 модели, можно ли помокаться по SQL

Промпт на входе.

I want to test my knowledge on SQL, can you prepare test questions for me and work on them with commentary?

Experience level - advanced
Focus area - should cover all aspects
Format & length - mix, it should cover standard 30 minute interview

Получился план из 6 задач

===
1. Окна: вторая по выручке дата
Таблица sales(salesperson_id, sale_date, amount). Для каждого продавца вернуть дату второй по сумме выручки за день.

Классическая задача на оконки с агрегатными функциям. GROUP BY, SUM(amount), ROW_NUMBER(), фильтр rown = 2, исключить продавцов с одной датой.

Диалог

Я специально забыл GROUP BY → бот подсказал.

Потом бот спросил, как исключить продавцов с одной датой → добавил COUNT(*) OVER (...) >= 2 Что на самом деле было избыточно, так как rownum покрывал этот юз кейс, на что я указал агенту =)

===
2. Индекс под ORDER BY … LIMIT

Какой индекс стоит использовать


SELECT order_id, total_amount
FROM orders
WHERE customer_id = $1
AND status = 'shipped'
ORDER BY order_date DESC
LIMIT 10;


Варианты индексов

A. (status)
B. (customer_id, status, order_date DESC, order_id)
C. (order_date)
D. (status, customer_id)

Диалог

- Сначала выбрал D.
- Бот уточнил про сортировку и LIMIT и задал наводящий вопрос по high/low cardinality.
- Перешёл на B — бот подтвердил, что это оптимально, и задал вопрос, надо ли что-то изменять если мы хотим поменять сортировку по order_date по нарастающей и ухудшится ли план, если убрать order_id из индекса

===
3. Теория: write-skew

Формулировка

Пояснить, что такое write-skew на уровне REPEATABLE READ и почему SERIALIZABLE это ловит.

Диалог

Я совершенно не помнил про write-skew и описал lost-update проблему, но затем бот зафоллоапил пример, и уточнил про отличие от lost-update

В рамках SERIALIZABLE обсуждение было про predicate locking

===
4. Рекурсивный CTE: зарплата команды

Таблица employees(emp_id, manager_id, salary), у CEO manager_id is null

Для каждого менеджера посчитать кол-во и сумму зарплат всех подчинённых (прямых и косвенных).

Диалог

Всеми любимые задачи на рекурсию =) Причем эта была не классический top down, а down to top, что было более интересное
Я несколько раз косячил в SQL, и бот поправлял и делал follow-up примерно, как бы это было бы на интервью

===
5. Когда нужен PL/pgSQL

Выбрать, где процедурное расширение уместнее чистого SQL.

Варианты

A. Обновить все строки сложной формулой.
B. Пройти курсором, вызвать веб-API для каждой строки, сохранить ответ.
C. Джойнить три большие таблицы, агрегировать и вернуть отчёт.
D. Ночью обновлять материализованное представление.

Диалог

Выбрал B. Бот согласился. Follow up question:
What precaution would you take to avoid bogging down the DB while that PL/pgSQL loop waits on each API call?

===
6. JOIN + агрегаты: завышенная сумма

Формулировка

Дебаг запроса - Problem: Finance says some “total_spent” figures are *too large*.

SELECT
    c.customer_id,
    c.name,
    SUM(o.total_amount)           AS total_spent,
    SUM(oi.quantity)              AS total_items
FROM customers         c
LEFT JOIN orders       o  
   ON o.customer_id = c.customer_id
LEFT JOIN order_items  oi 
   ON oi.order_id    = o.order_id
WHERE o.status = 'shipped'
GROUP BY c.customer_id, c.name;

Тут бот ожидал 4 изменения и переписанный запрос. Бот указаывал опечатки, проверял наличие alias

===
Итог

- Бот ведёт сценарий, даёт ровно столько подсказок, сколько нужно, иногда ожидает избыточного ответа
- После сессии остаётся готовый «черновик» диалога со всеми вариантами и решениями
- Стоит попробовать помокать с чатгпт, особенно если у вас есть готовый список вопросов и / или тематика, которую вы хотите проработать. Однако я думаю, есть и более подходящие агенты (Если кто-то знает какие-нибудь, посоветуйте в комментариях)

Уже не раз ловил агентов на том, что когда они не могу получить данные, они их придумывают и генерят сверху какую-то около правдоподобную статистику

Ждем кул стори, как CEO/CPO принимали решения на чистой синтетике

Всем привет! А у нас снова онлайн митап!

Осенняя серия dbt & modern data stack talks начинается 25 сентября в 19:00 (+3 GMT)

Подробные детали по спикерам и темам - https://inzhenerka.tech/dbt_meetup

Можно регаться в бот по ссылке, если предпочитаете подписку через бота - https://news.1rj.ru/str/dbtmeetup_bot?start=211128

Как обычно, прямая трансляция будет в ютуб и других платформах

Привет! Книжного Клуба анонс!

У нас с коллегами дата инженерами появилась идея по/перечитать книги, связанные с дата инженерией!

Первая книгу, которую мы хотели бы обсудить - Data Engineering Desing Patterns.

Планируем делать созвоны на еженедельной основе - вторник 19:30 MSK (17:30 CET).

Первый созвон - следующий вторник 25 ноября, разберем первые паттерны по полной и инкрементальным загрузкам.

Все детали книжного клуба будут в @de_zoomcamp, если вам интересно, залетайте в канал