Разблокировалось тут забавное воспоминание!

Cвою первую работу в айтишке (в Х5) я получил довольно забавно: случайно увидел пост от одного из хедов в фейсбуке, что ребята нанимают дата саентистов. Написал в личку "Я не DS, но умный и смышленый!".
Мое резюме отправили руководителю разработки, который меня позвал на собес (тут я уже обрадовался от радости). А собес я провалил, знатно, причем вопросы были не алгоритмические упражнения с литкода, а вполне себе разработческие, например, чем отличается `git pull` от `git fetch`?

Но мне дали второй шанс: тестовое домашнее задание. Нужно было написать сервис, который делает всякое разное с записями в базе данных. И я тут отыгрался: и докер контейнер сделал, и документацию на английском, и скрипт деплоя, и даже все в облако положил и сделал доступным, куча свистопирделок.

Потом уже мой начальник Сергей признался, что дал тестовое задание, чтобы я с ним не справился, и мне стало стыдно и я не писал бы больше им. А когда они получили его и увидели, они поняли, что меня надо брать.😂


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

>>> @roadofbugs_channel <<<

Comparing Analytics Engines

Очень интересный материал и хорошим сравнением нескольких аналитических движков. Редакция активно использует ClickHouse, но интересно было почитать и о других решениях. Очевидно, что универсального подхода к выбору лучшего движка для аналитических задач не существует, поэтому всегда полезно расширить кругозор.

Авторы предлагаю следующую классификацию для OLAP DB: General Purpose Engines (Spark), Interactive SQL Engines (Presto, Trino), and Realtime OLAP Engines (ClickHouse, StarRocks)

Кстати, StarRocks имеет на удивление самый высокий metascore. Spark - самый старый и в целом уже с legacy концепцией работы поверх map reduce - раза в 3 меньше по рейтингу, хотя он наименее требовательный к дискам и у него самая лучшая поддержка различными библиотеками для работы и наиболее развитая экосистема. Presto - самый масштабируемый, а Concurrency лучше всех справляется с конкурентными запросами. Clickhouse, в свою очередь, имеет наилучшую коммерческую поддержку.

В статье содержится довольно подробное сравнение движком по каждому пункту выше и ссылки на хороше use cases.

https://www.onehouse.ai/blog/apache-spark-vs-clickhouse-vs-presto-vs-starrocks-vs-trino-comparing-analytics-engines

Исследование специалистов по работе с данными — 2025

DevCrowd запускает новый опрос для дата-инженеров, аналитиков, дата-сайентистов, ML-инженеров и их руководителей.

Зачем участвовать?

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

🗂 Пример прошлогоднего исследования — https://devcrowd.ru/ds24

📝 Опрос займёт 15 минут, результаты появятся в открытом доступе в августе.

👉 Пройти опрос - https://survey.alchemer.eu/s3/90842227/data-2025

@ohmydataengineer

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

Максимальное спасибо @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

===
Итог

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