Редкое явление для нашего острова!
Зато под одной крышей солидная кучка дата инженеров и дата аналитиков!

Максимальное спасибо @valiotti и @cyprusdata за организацию этого эвента!

Если вы на Кипре и вы хотите быть в курсе дата-событий и понетворкаться и пообсуждать датку -> вступайте (через формочку) https://tally.so/r/nPpOEP

Давненько я не рассказывал про другие каналы и ничего не репостил (да и не писал в целом почти 2! недели).
Как-то надо возвращаться в строй =)

Вот, например, Алиса попросила рассказать про свой канал про дата-виз. Мб кому-то будет полезно и интересно 😏

Первый дашборд в новой рубрике #референс

Референс (от англ. reference — «отсылка», «справка») — это изображение, которое используется для поиска вдохновения и идей.

💡И то, что вдохновляет, и то, откуда можно взять концепцию.

Под этим хэштегом я планирую выкладывать примеры дашбордов и отмечать в них интересные детали, которыми можно обогатить свои проекты.

Почему я решила создать такую рубрику?

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

Такие разборы очень полезны для развития датавиз-навыков и понимания того, «как не надо», но для развития также важно тренировать насмотренность на хорошее и черпать свежие идеи.

Итак, открывает рубрику «антипрожарки» дашборд Прадипа Кумара HR Attrition Dashboard, который занял 3-е место в номинации «Бизнес-аналитика» в конкурсе Information is Beautiful 2022.

Что интересного хочется отметить?

✅ Есть переключатель «Показать только текучесть», чтобы убрать с дашборда отображение второй метрики

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

✅ В карточках KPI названия метрик написаны светло-серым цветом и более мелким шрифтом, потому что акцент сделан на сами числа

✅ Есть переключатель для изменения гранулярности графика с динамикой: W/M/Q/Y – неделя/месяц/квартал/год.

При выборе другого периода перестраивается сама визуализация и изменяется название в подписи предыдущего периода для величины изменения

✅ В этом же графике динамики есть ориентир для анализа — линия среднего значения

✅ Таблица небольшая и находится в нижнем правом углу, таким образом не занимает много места и не перетягивает внимание на себя.

Кому нужно, тот выгрузит или увеличит таблицу с детализированными данными, а по умолчанию акцент в дашборде сделан на общие показатели и визуализации

✅ Указан автор дашборда (в левом нижнем углу)

❓Что еще вы бы взяли на заметку?

Для развития рубрики присылайте примеры дашбордов: @alisaruchkina. Буду рада их рассмотреть!

#дашборд

Агенты (не AI) говорят, что появился черновик (то есть сырая версия до редактуры) второй версии кабанчика.

@ohmydataengineer

Пятничный юмор.
Хайп-трейн не остановить!🤪

Мокаемся в 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

===
Итог

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

От этого мема меня порвало в клочья 😂

@ohmydataengineer