🐘🌺🦫 Добро пожаловать на канал в лабораторию дата инженеров!

Здесь мы будем разбирать интересные кейсы из мира де. 💪
Чуть ниже опишу рубрики, которые будут использоваться в канале.

А пока давайте знакомиться! ♥️
Про себя: окончила бакалавр и магистратуру МФТИ, работаю более 5 лет дата инженером в крупных финтех компаниях, сейчас являюсь senior data engineer/tech lead, а так же провожу в команде code review у разработчиков

Начнем 🙌
Кто работает разработчиком знает, что есть несколько стендов:
1) dev - для отладки на синтетических данных
2) ift - для отладки на данных, приближенных к ПРОДу
3) сам ПРОД

Сегодня мне дали провести code review и что я там увидела🤔

#поразмыслим
В чем разница между двумя вариантами? Какой лучше использовать для тестовых стендов (dev, ift), а какой лучше для ПРОДа?

sql create table if not exists <table_name> (id int, ...); 

drop table if exists <table_name>;
create table <table_name> (id int, ...); 

Пишите свои размышления в комментарий, а я вечером напишу свой вариант ответа

Мой вариант ответа ✅

Первый вариант лучше использовать для ПРОДа:
➕ не удаляет таблицу - данные в безопасности (очень важно!)

➖если изменилась структура таблицы (например, добавилось поле, изменился тип данных), то этот запрос не обновит таблицу и нужно будет использовать alter. Или же создавать вторую таблицу с измененной структурой и переливать данные из старой.


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

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

Итак, продолжим 🙌
#интересные_кейсы

На работе на скорую руку написала довольно простой sql запрос вида:

select 
    application_rk
from 
(
    select 
        distinct application_rk, 
        row_number() over(partition by guid_dk, application_rk order by effective_from_date desc) as rn
    from table
) t 
where rn = 1

Хотела сразу отобрать записи для быстрой проверки:
1) только уникальные значения
2) первую актуальную запись

В итоге получила совсем неверный ответ 👉
Не учла два момента:
1) если есть полные дубли (то есть строки с одинаковыми значениями во всех полях, включая application_rk, guid_dk и effective_from_date), то ROW_NUMBER() без предварительного DISTINCT может присвоить rn = 1 нескольким одинаковым строкам в одной группе. Это происходит потому, что оконная функция работает с каждой строкой отдельно, и если строки идентичны, ORDER BY effective_from_date DESC не поможет их различить — они обе получат rn = 1. В результате WHERE rn = 1 вернёт все эти дубликаты, что даст лишние строки

2) у меня получилось так, что в таблице поле effective_from_date имело одинаковое время с точностью до миллисекунд и в итоге оконка при каждом запуске рандомно выбирала запись между одинаковыми значениями. В итоге нужно было добавить еще одно поле effective_to_date в order by


А также можно получить меньше строк, чем ожидалось, если:
◦ Предположим, у нас есть application_rk = 100, который появляется в двух разных guid_dk (например, G1 и G2), и в каждой группе есть строка с rn = 1 (самая свежая дата).
◦ Внутренний подзапрос выдаст две строки: (100, 1) для G1 и (100, 1) для G2.
◦ DISTINCT по (application_rk, rn) увидит две одинаковые строки (100, 1) и оставит только одну (произвольно, какую-то одну). Таким образом, мы потеряем одну из групп 😕

Пишите в комментариях как все-таки правильно написать запрос

Мой вариант ответа ✅

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

Ребята, у меня для вас отличная новость🥳

Я набираю небольшую группу, где буду Вашим ментором. Вы приходите ко мне с личным запросом, а мы разбираем задачи/вопросы/резюме.
Для первой группы цена почти бесплатная https://stepik.org/a/276994

P.S. можете поделиться со своими друзьями/знакомыми, кому нужна помощь в поиске работы, составлении резюме, в решении задач