DA
it пингвин | data engineer
https://t.me/data_penguin
Idade do canal
Criado
Linguagem
Russo
-
ER (semana)
39.96%
ERRAR (semana)
Канал главного разработчика Data Lake крупного банка. База знаний для джунов, разбор собесов, задачи (jun/mid/sen) с решениями, полезные материалы, обзоры технологий и архитектур. По вопросам @it_pengwin
Encontrado
35
resultados
DA
it пингвин | data engineer
377
assinantes
Продолжим историю с полезными презенташками 😎
Прошлые презентации можете взять здесь
Сегодня прикреплю следующий материал(продолжу нумерацию с прошлого поста):
3️⃣ Введение в Python
4️⃣ Python Advanced
5️⃣ MapReduce
6️⃣ HDFS
3,4 - люблю готовые ноутбуки, где можно идти по порядку запускать код, при желании что-то менять и сразу смотреть результат.
Открывайте с помощью jupyter notebook. *Если не знаете как это сделать, пишите, на след недели сделаю инструкцию 🤝
5 - презентация + программы + данные. Здесь нужно разбираться как все работает.
6 - просто классная презентация по hdfs
Совет по всем материал - при возможности изучайте все сразу. Иначе все будет складивароваться и только расти. У меня сейчас так. Стараюсь все разгребать😁
Дайте обратную связь, как вам материал?⬇️😊
it пингвин | data engineer 🐧
#полезная_инфа
Прошлые презентации можете взять здесь
Сегодня прикреплю следующий материал(продолжу нумерацию с прошлого поста):
3️⃣ Введение в Python
4️⃣ Python Advanced
5️⃣ MapReduce
6️⃣ HDFS
3,4 - люблю готовые ноутбуки, где можно идти по порядку запускать код, при желании что-то менять и сразу смотреть результат.
Открывайте с помощью jupyter notebook. *Если не знаете как это сделать, пишите, на след недели сделаю инструкцию 🤝
5 - презентация + программы + данные. Здесь нужно разбираться как все работает.
6 - просто классная презентация по hdfs
Совет по всем материал - при возможности изучайте все сразу. Иначе все будет складивароваться и только расти. У меня сейчас так. Стараюсь все разгребать😁
Дайте обратную связь, как вам материал?⬇️😊
it пингвин | data engineer 🐧
#полезная_инфа
25.04.2025, 12:49
t.me/data_penguin/60
DA
it пингвин | data engineer
377
assinantes
Небольшой обзор бота - карьерного консультанта
Канал:@data_brew
Ссылка на бота: @CV_analytic_bot
Просили сделать честный обзор 😁
Идея правда крутая. Закинули в тг бота свое резюме,а он тебе делает его обзор, дает советы по его улучшению и помогает написать сопроводительное письмо.
Реализация. Парсинг резюме с хх ру делает нормально, в других форматах немного тупил. То есть бот может коряво распарсить резюме и не увидеть контактные данные, опыт, образование и тд. Есть ограничение по объему файла - отправил файл 1мб, ответ :"💔Слишком большой файл".
Когда резюме парсится - обзор резюме выглядит неплохо.
Сопроводительное письмо пишет хорошее, но возможно можно сделать генерацию чуть короче.
В целом ботом можно уже пользоваться. Но надеюсь он будет еще улучшаться.
it пингвин | data engineer 🐧
#полезная_инфа
Канал:@data_brew
Ссылка на бота: @CV_analytic_bot
Просили сделать честный обзор 😁
Идея правда крутая. Закинули в тг бота свое резюме,а он тебе делает его обзор, дает советы по его улучшению и помогает написать сопроводительное письмо.
Реализация. Парсинг резюме с хх ру делает нормально, в других форматах немного тупил. То есть бот может коряво распарсить резюме и не увидеть контактные данные, опыт, образование и тд. Есть ограничение по объему файла - отправил файл 1мб, ответ :"💔Слишком большой файл".
Когда резюме парсится - обзор резюме выглядит неплохо.
Сопроводительное письмо пишет хорошее, но возможно можно сделать генерацию чуть короче.
В целом ботом можно уже пользоваться. Но надеюсь он будет еще улучшаться.
it пингвин | data engineer 🐧
#полезная_инфа
25.04.2025, 09:38
t.me/data_penguin/59
DA
it пингвин | data engineer
377
assinantes
Привет, подписчики!😎
Сейчас расскажу про полезные источники информации (темки)
*Скорее всего пост через время дропну.
1) Слив курсов 🥳🤩
https://s1.sharewood.co/
На шердвуде есть много сливов курсов. Видео все в хорошем качестве, теория и задания тоже есть (с ними бывают косяки). Но в любом случае вместо 100к за курс, можно бесплатно скачать 😊
Точнее бесплатно можно скачивать 1 раз в 3 дня вроде бы или купить недорогую подписку и скачивать все без ограничений (не вижу в этом смысла). Так что халявим по полной🤑
Там есть курсы Яндекса, Карпова, Нетологии и тд.
Я сам скачивал несколько курсов по дата инженерии.
И супер удобно у них есть бот @sharewood_bot. Можно искать по названиям курсов или по источникам.
В общем, разберетесь😁
Пользуйтесь и оставьте обратную связь здесь плз. Интересно как вам.
2) Слив it книг🤩
Вот несколько каналов где выкладывают книги.
▪️https://t.me/book_sbornik
▪️https://t.me/dbbooks и https://t.me/readandget
▪️https://t.me/dsbookru
Ставим реакции, если понравились темки⬇️
И оч важно, если у вас есть свои "интересные" источники делитесь в комментах.
it пингвин | data engineer 🐧
#полезная_инфа
Сейчас расскажу про полезные источники информации (темки)
*Скорее всего пост через время дропну.
1) Слив курсов 🥳🤩
https://s1.sharewood.co/
На шердвуде есть много сливов курсов. Видео все в хорошем качестве, теория и задания тоже есть (с ними бывают косяки). Но в любом случае вместо 100к за курс, можно бесплатно скачать 😊
Точнее бесплатно можно скачивать 1 раз в 3 дня вроде бы или купить недорогую подписку и скачивать все без ограничений (не вижу в этом смысла). Так что халявим по полной🤑
Там есть курсы Яндекса, Карпова, Нетологии и тд.
Я сам скачивал несколько курсов по дата инженерии.
И супер удобно у них есть бот @sharewood_bot. Можно искать по названиям курсов или по источникам.
В общем, разберетесь😁
Пользуйтесь и оставьте обратную связь здесь плз. Интересно как вам.
2) Слив it книг🤩
Вот несколько каналов где выкладывают книги.
▪️https://t.me/book_sbornik
▪️https://t.me/dbbooks и https://t.me/readandget
▪️https://t.me/dsbookru
Ставим реакции, если понравились темки⬇️
И оч важно, если у вас есть свои "интересные" источники делитесь в комментах.
it пингвин | data engineer 🐧
#полезная_инфа
24.04.2025, 09:52
t.me/data_penguin/58
DA
it пингвин | data engineer
377
assinantes
22.04.2025, 09:35
t.me/data_penguin/57
DA
it пингвин | data engineer
377
assinantes
Вакансия: Старший ETL разработчик
Компания: Газпромбанк
Предполагаемая вилка: 325к net (можно было 350 выбить)
Период собеседования:
Февраль 2025
Формат работы: Удаленка из РФ
Этапы собеседований:
HR-> Tech interview -> Tech interview -> Offer -> Rejected
Что будет на проекте:
Разработка sql в КХД банка на старой СУБД Sybase, отчетность для BI. В перспективе участие в миграции КХД на современный стек - S3, GP, ClickHouse, DBT, Spark/Flink, Airflow.
Краткая справка о процессе интервью:
Было два тех интервью - с руководством dwh банка и с командой.
На первом интервью в основном я рассказывал о своем опыте, потом дали несколько простых задач по sql (например, была задачка на накопительную сумму).
Второе интервью я запомню надолго:
Эта был вечер пятницы. Я говорил 1 на 1 с тимлидом команды. Исходя из разговора я понял, что интервьюер лежал в темноте на диване, говорил по телефону. Задавал мне загадки про вероятности(по ним сделаю пост) и болтал со мной о разных технологиях.
Диалог был максимально странный, но мне понравился😅
Позже подключился главный разработчик команды, и мы начали говорить про архитектуру dwh, про оптимизацию, разницу исторических и фактовых таблиц, задачка на self join. Моделировали таблицы - разраб спросил как мы будем хранить паспортные данные?
Еще был вопрос - Как работает накопительная сумма если встречается null?
Через 3 дня прислали оффер на 325к, я отказался, тк не захотел работать с СУБД Sybase (после работы на таком проекте моя ценность особо не выросла б). *+ уже был на руках более привлекательный оффер в другой банк.
Если бы я принял оффер, то был бы еще один этап - проверка психологом🤡
Как вам собеседование? Приняли бы оффер😁?
it пингвин | data engineer 🐧
#Собес
Компания: Газпромбанк
Предполагаемая вилка: 325к net (можно было 350 выбить)
Период собеседования:
Февраль 2025
Формат работы: Удаленка из РФ
Этапы собеседований:
HR-> Tech interview -> Tech interview -> Offer -> Rejected
Что будет на проекте:
Разработка sql в КХД банка на старой СУБД Sybase, отчетность для BI. В перспективе участие в миграции КХД на современный стек - S3, GP, ClickHouse, DBT, Spark/Flink, Airflow.
Краткая справка о процессе интервью:
Было два тех интервью - с руководством dwh банка и с командой.
На первом интервью в основном я рассказывал о своем опыте, потом дали несколько простых задач по sql (например, была задачка на накопительную сумму).
Второе интервью я запомню надолго:
Эта был вечер пятницы. Я говорил 1 на 1 с тимлидом команды. Исходя из разговора я понял, что интервьюер лежал в темноте на диване, говорил по телефону. Задавал мне загадки про вероятности(по ним сделаю пост) и болтал со мной о разных технологиях.
Диалог был максимально странный, но мне понравился😅
Позже подключился главный разработчик команды, и мы начали говорить про архитектуру dwh, про оптимизацию, разницу исторических и фактовых таблиц, задачка на self join. Моделировали таблицы - разраб спросил как мы будем хранить паспортные данные?
Еще был вопрос - Как работает накопительная сумма если встречается null?
Через 3 дня прислали оффер на 325к, я отказался, тк не захотел работать с СУБД Sybase (после работы на таком проекте моя ценность особо не выросла б). *+ уже был на руках более привлекательный оффер в другой банк.
Если бы я принял оффер, то был бы еще один этап - проверка психологом🤡
Как вам собеседование? Приняли бы оффер😁?
it пингвин | data engineer 🐧
#Собес
21.04.2025, 12:50
t.me/data_penguin/56
DA
it пингвин | data engineer
377
assinantes
17.04.2025, 16:14
t.me/data_penguin/55
DA
it пингвин | data engineer
377
assinantes
Друзья, я получил обратную связь, что даю сложные задачки🫠
Я с этим согласен 🤝👍
Скоро я сделаю краткий обзор собеседования с Газпромбанком✍️
После собеса мне прилетела положительная обратная связь и оффер 325к.💰
На одном из этапов мне давали легкие задачки (скорее загадки). По ним сделаю пост, вам должно понравиться 😁
Я с этим согласен 🤝👍
Скоро я сделаю краткий обзор собеседования с Газпромбанком✍️
После собеса мне прилетела положительная обратная связь и оффер 325к.💰
На одном из этапов мне давали легкие задачки (скорее загадки). По ним сделаю пост, вам должно понравиться 😁
16.04.2025, 10:43
t.me/data_penguin/54
DA
it пингвин | data engineer
377
assinantes
Привет, подписчики!😎
Выкладываю решения по пятничной задачки.
Данные:
with rest_history (id_dog, dt, balance) as (
select 111, to_date('10.07.2022', 'dd.mm.yyyy'), 10 union all
select 111, to_date('15.08.2022', 'dd.mm.yyyy'), 0 union all
select 111, to_date('20.09.2022', 'dd.mm.yyyy'), 15 union all
select 111, to_date('15.07.2022', 'dd.mm.yyyy'), 25 union all
select 111, to_date('15.07.2022', 'dd.mm.yyyy'), 35 union all
select 222, to_date('15.07.2022', 'dd.mm.yyyy'), 5 union all
select 222, to_date('15.08.2022', 'dd.mm.yyyy'), 7 union all
select 222, to_date('15.09.2022', 'dd.mm.yyyy'), 0 union all
select 222, to_date('03.03.2023', 'dd.mm.yyyy'), 33 union all
select 222, to_date('04.04.2023', 'dd.mm.yyyy'), 44 union all
select 222, to_date('10.05.2023', 'dd.mm.yyyy'), 0
) select * from rest_history
1)
SELECT
id_dog, dt, new_dt
FROM
(
SELECT
id_dog, dt, balance,
COALESCE((LEAD(dt) OVER(PARTITION BY id_dog ORDER BY dt) - INTERVAL '1 day'),
to_date('31.12.2999', 'DD.MM.YYYY')) AS new_dt
FROM
(
SELECT
id_dog, dt, balance,
CASE WHEN COALESCE(LAG(balance) OVER(PARTITION BY id_dog ORDER BY dt), 0) = 0
THEN 1
ELSE 0
END AS bal_flg
FROM rest_history
) t1
WHERE bal_flg = 1 OR balance = 0
) t2
WHERE balance != 0
ORDER BY id_dog, dt
2)
,rest_history_l AS (
SELECT
ID_DOG,
DT,
BALANCE,
lag(BALANCE, 1, 0) OVER (PARTITION BY ID_DOG ORDER BY DT) AS BALANCE_L
FROM rest_history
)
SELECT
rl.ID_DOG,
to_char(rl.DT, 'DD.MM.YYYY') AS DATE_BEG,
COALESCE(
to_char(
(SELECT MIN(rl1.DT) - INTERVAL '1 day'
FROM rest_history_l rl1
WHERE rl1.BALANCE = 0 AND rl1.BALANCE_L <> 0
AND rl1.DT > rl.DT
AND rl1.ID_DOG = rl.ID_DOG),
'DD.MM.YYYY'),
'31.12.2999'
) AS DATE_END
FROM rest_history_l rl
WHERE BALANCE > 0 AND BALANCE_L = 0
ORDER BY ID_DOG, DT
3)
SELECT id_dog,
MIN(dt_start) AS dt_start,
COALESCE(dt_end, TO_DATE('31.12.2999', 'DD.MM.YYYY')) AS dt_end
FROM (
SELECT id_dog,
dt AS dt_start,
MIN(CASE WHEN balance = 0 THEN dt - INTERVAL '1 day' END)
OVER(PARTITION BY id_dog ORDER BY dt
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING) AS dt_end
FROM rest_history
) t
GROUP BY id_dog, dt_end
ORDER BY id_dog, dt_end
Позапускайте решения, сравните разные реализации 👍
it пингвин | data engineer 🐧
Выкладываю решения по пятничной задачки.
Данные:
with rest_history (id_dog, dt, balance) as (
select 111, to_date('10.07.2022', 'dd.mm.yyyy'), 10 union all
select 111, to_date('15.08.2022', 'dd.mm.yyyy'), 0 union all
select 111, to_date('20.09.2022', 'dd.mm.yyyy'), 15 union all
select 111, to_date('15.07.2022', 'dd.mm.yyyy'), 25 union all
select 111, to_date('15.07.2022', 'dd.mm.yyyy'), 35 union all
select 222, to_date('15.07.2022', 'dd.mm.yyyy'), 5 union all
select 222, to_date('15.08.2022', 'dd.mm.yyyy'), 7 union all
select 222, to_date('15.09.2022', 'dd.mm.yyyy'), 0 union all
select 222, to_date('03.03.2023', 'dd.mm.yyyy'), 33 union all
select 222, to_date('04.04.2023', 'dd.mm.yyyy'), 44 union all
select 222, to_date('10.05.2023', 'dd.mm.yyyy'), 0
) select * from rest_history
1)
SELECT
id_dog, dt, new_dt
FROM
(
SELECT
id_dog, dt, balance,
COALESCE((LEAD(dt) OVER(PARTITION BY id_dog ORDER BY dt) - INTERVAL '1 day'),
to_date('31.12.2999', 'DD.MM.YYYY')) AS new_dt
FROM
(
SELECT
id_dog, dt, balance,
CASE WHEN COALESCE(LAG(balance) OVER(PARTITION BY id_dog ORDER BY dt), 0) = 0
THEN 1
ELSE 0
END AS bal_flg
FROM rest_history
) t1
WHERE bal_flg = 1 OR balance = 0
) t2
WHERE balance != 0
ORDER BY id_dog, dt
2)
,rest_history_l AS (
SELECT
ID_DOG,
DT,
BALANCE,
lag(BALANCE, 1, 0) OVER (PARTITION BY ID_DOG ORDER BY DT) AS BALANCE_L
FROM rest_history
)
SELECT
rl.ID_DOG,
to_char(rl.DT, 'DD.MM.YYYY') AS DATE_BEG,
COALESCE(
to_char(
(SELECT MIN(rl1.DT) - INTERVAL '1 day'
FROM rest_history_l rl1
WHERE rl1.BALANCE = 0 AND rl1.BALANCE_L <> 0
AND rl1.DT > rl.DT
AND rl1.ID_DOG = rl.ID_DOG),
'DD.MM.YYYY'),
'31.12.2999'
) AS DATE_END
FROM rest_history_l rl
WHERE BALANCE > 0 AND BALANCE_L = 0
ORDER BY ID_DOG, DT
3)
SELECT id_dog,
MIN(dt_start) AS dt_start,
COALESCE(dt_end, TO_DATE('31.12.2999', 'DD.MM.YYYY')) AS dt_end
FROM (
SELECT id_dog,
dt AS dt_start,
MIN(CASE WHEN balance = 0 THEN dt - INTERVAL '1 day' END)
OVER(PARTITION BY id_dog ORDER BY dt
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING) AS dt_end
FROM rest_history
) t
GROUP BY id_dog, dt_end
ORDER BY id_dog, dt_end
Позапускайте решения, сравните разные реализации 👍
it пингвин | data engineer 🐧
16.04.2025, 10:02
t.me/data_penguin/53
DA
it пингвин | data engineer
377
assinantes
Буллинг от руководителя
Осень 2021 года. Мое первое место работы в it было в суппорте BI портала одной большой телеком компании.
Это был очень важный проект для компании и его только разработали.
Набрали инженеров в суппорт, в том числе и меня. Их было четверо, четыре пацана. Кхм.. Нет. Нас было восемь, восемь джунов.
Работали мы 2/2 по 12 часов. Раскиданы по всей территории РФ, по разным часовым поясам. Таким образом наша команда дежурила 24/7.
Мы следили за дашбордами, если находили косяки заводили заявки на разработку или эксплуатацию, делали какие-то пересчеты, проводили консультации.
Мы были все джунами, примерно одного уровня. Знали sql, немного архитектуру. Кто-то имел опыт программирования в прошлом. У меня хардскиллы были средние, но я был очень ответственный. Все почему-то боялись брать задачки в работу. А я сразу понял что их все равно надо делать. И в итоге в конце года у меня было закрытых задач столько же сколько у остальной команды в сумме. Но эта история не обо мне.
Среди нас был один инженер более слабый. Он плохо знал sql и вообще не особо понимал, что от него хотят. И наша руководитель (недавно была обычным инженером и ее только повысили до руководителя) как-то быстро поняла, что он слабоват и начала его буллить. Она при всех часто подкалывала его, что он что-то не знает. Давала ему отдельные стремные задачи по sql, найти какие-то страницы в конфе и сделать из них доки, пересказать статьи, которые она сама присылала. То есть, когда у остальных инженеров было свободное время на работе, мы или кайфовали или занимались саморазвитием, а этот инженер делал бессмысленные задачки руководителя.
Самое неприятное когда она его чмырила за спиной. У нас созвон - я, два инженера и руководитель. И она его прям сильно обсирала - какой он ТУПОЙ (прям так и говорила), ничего не знает, не понимает. НЕ ПОМОГАЙТЕ ему выполнять задачи, пусть сам разбирается. На корпоративах точно также подкалывала, унижала. Этот инженер рассказывает какую-то историю, руководитель перебивает его и рассказывает свое. И такие вещи были во всем, лишь бы найти повод.
С остальными руководитель, наоборот, была доброжелательна, мило разговаривала и помогала.
И хочу уточнить - мы все были джунами, он не особо от нас отличался. Грубо говоря, ему нужно было просто подтянуть sql и чуть подробнее узнать про DWH.
Мне это все как-то сразу не очень понравилось. И этот инженер со мной общался лучше всех, я ему часто помогал и что-то объяснял. Мы решали sql задачки, лазили по процедурам, смотрели как работает Oracle BI и тд.
*Справедливости ради хочу отметить, иногда он сам даже особо не разбирался в вопросах/задачах, а сразу приходил ко мне. Я сначала в таких ситуациях помогал ему, потом стал пресекать и говорил, посмотри сначала вот это, сделай это и только потом возвращайся.
Что интересно, спустя почти 4 года из 8 инженеров в том суппорте работает только этот инженер, которого буллили. И как я знаю, его отношения с руководителем нормализовались.
Я об этом размышлял и мне кажется, что это тоже херовый показатель. Многие знают, что в суппорте работают или джуны или уходят на пенсию. А этот инженер до сих пор там сидит. Может быть ему там все нравится, может быть у него просто нет амбиций. А может он до сих пор добивается одобрения своего руководителя.
Такая вот маленькая история.. Что думаете по этому поводу? Интересно, были ли у вас подобные случаи?
it пингвин | data engineer 🐧
#трустори
Осень 2021 года. Мое первое место работы в it было в суппорте BI портала одной большой телеком компании.
Это был очень важный проект для компании и его только разработали.
Набрали инженеров в суппорт, в том числе и меня. Их было четверо, четыре пацана. Кхм.. Нет. Нас было восемь, восемь джунов.
Работали мы 2/2 по 12 часов. Раскиданы по всей территории РФ, по разным часовым поясам. Таким образом наша команда дежурила 24/7.
Мы следили за дашбордами, если находили косяки заводили заявки на разработку или эксплуатацию, делали какие-то пересчеты, проводили консультации.
Мы были все джунами, примерно одного уровня. Знали sql, немного архитектуру. Кто-то имел опыт программирования в прошлом. У меня хардскиллы были средние, но я был очень ответственный. Все почему-то боялись брать задачки в работу. А я сразу понял что их все равно надо делать. И в итоге в конце года у меня было закрытых задач столько же сколько у остальной команды в сумме. Но эта история не обо мне.
Среди нас был один инженер более слабый. Он плохо знал sql и вообще не особо понимал, что от него хотят. И наша руководитель (недавно была обычным инженером и ее только повысили до руководителя) как-то быстро поняла, что он слабоват и начала его буллить. Она при всех часто подкалывала его, что он что-то не знает. Давала ему отдельные стремные задачи по sql, найти какие-то страницы в конфе и сделать из них доки, пересказать статьи, которые она сама присылала. То есть, когда у остальных инженеров было свободное время на работе, мы или кайфовали или занимались саморазвитием, а этот инженер делал бессмысленные задачки руководителя.
Самое неприятное когда она его чмырила за спиной. У нас созвон - я, два инженера и руководитель. И она его прям сильно обсирала - какой он ТУПОЙ (прям так и говорила), ничего не знает, не понимает. НЕ ПОМОГАЙТЕ ему выполнять задачи, пусть сам разбирается. На корпоративах точно также подкалывала, унижала. Этот инженер рассказывает какую-то историю, руководитель перебивает его и рассказывает свое. И такие вещи были во всем, лишь бы найти повод.
С остальными руководитель, наоборот, была доброжелательна, мило разговаривала и помогала.
И хочу уточнить - мы все были джунами, он не особо от нас отличался. Грубо говоря, ему нужно было просто подтянуть sql и чуть подробнее узнать про DWH.
Мне это все как-то сразу не очень понравилось. И этот инженер со мной общался лучше всех, я ему часто помогал и что-то объяснял. Мы решали sql задачки, лазили по процедурам, смотрели как работает Oracle BI и тд.
*Справедливости ради хочу отметить, иногда он сам даже особо не разбирался в вопросах/задачах, а сразу приходил ко мне. Я сначала в таких ситуациях помогал ему, потом стал пресекать и говорил, посмотри сначала вот это, сделай это и только потом возвращайся.
Что интересно, спустя почти 4 года из 8 инженеров в том суппорте работает только этот инженер, которого буллили. И как я знаю, его отношения с руководителем нормализовались.
Я об этом размышлял и мне кажется, что это тоже херовый показатель. Многие знают, что в суппорте работают или джуны или уходят на пенсию. А этот инженер до сих пор там сидит. Может быть ему там все нравится, может быть у него просто нет амбиций. А может он до сих пор добивается одобрения своего руководителя.
Такая вот маленькая история.. Что думаете по этому поводу? Интересно, были ли у вас подобные случаи?
it пингвин | data engineer 🐧
#трустори
14.04.2025, 10:13
t.me/data_penguin/52
DA
it пингвин | data engineer
377
assinantes
🔹Задача🔹
Задача была дана на собеседовании в одном из банков. Собеседование было на middle+.
📌Имеется таблица остатков rest_history.
▫️id_dog - id договора
▫️dt - дата изменения остатка
▫️balance - остаток на конце дня dt (0 или положительный)
Условия:
▫️ в таблице для каждого договора первой строкой является строка с ненулевым остатком.
Необходимо написать SQL-запрос:
▫️для каждого договора вычислить периоды, когда он имел ненулевой остаток;
▫️период закрывается датой dt-1 строки с нулевым остатком;
▫️eсли ненулевой остаток остается, то период закрывается датой 31.12.2999.
Тестовые данные (см. скрин):
with rest_history (id_dog, dt, balance) as (
select 111, to_date('10.07.2022', 'dd.mm.yyyy'), 10 union all
select 111, to_date('15.08.2022', 'dd.mm.yyyy'), 0 union all
select 111, to_date('20.09.2022', 'dd.mm.yyyy'), 15 union all
select 111, to_date('15.07.2022', 'dd.mm.yyyy'), 25 union all
select 111, to_date('15.07.2022', 'dd.mm.yyyy'), 35 union all
select 222, to_date('15.07.2022', 'dd.mm.yyyy'), 5 union all
select 222, to_date('15.08.2022', 'dd.mm.yyyy'), 7 union all
select 222, to_date('15.09.2022', 'dd.mm.yyyy'), 0 union all
select 222, to_date('03.03.2023', 'dd.mm.yyyy'), 33 union all
select 222, to_date('04.04.2023', 'dd.mm.yyyy'), 44 union all
select 222, to_date('10.05.2023', 'dd.mm.yyyy'), 0
) select * from rest_history
Результат после обработки скриптом:
111 | 10.07.2022 | 14.08.2022
111 | 20.09.2022 | 31.12.2999
222 | 15.07.2022 | 14.09.2022
222 | 03.03.2023 | 09.05.2023
Присылайте решения😊
Свои решения я опубликую на следующей недели 💅
it пингвин | data engineer 🐧
#sql #задача
Задача была дана на собеседовании в одном из банков. Собеседование было на middle+.
📌Имеется таблица остатков rest_history.
▫️id_dog - id договора
▫️dt - дата изменения остатка
▫️balance - остаток на конце дня dt (0 или положительный)
Условия:
▫️ в таблице для каждого договора первой строкой является строка с ненулевым остатком.
Необходимо написать SQL-запрос:
▫️для каждого договора вычислить периоды, когда он имел ненулевой остаток;
▫️период закрывается датой dt-1 строки с нулевым остатком;
▫️eсли ненулевой остаток остается, то период закрывается датой 31.12.2999.
Тестовые данные (см. скрин):
with rest_history (id_dog, dt, balance) as (
select 111, to_date('10.07.2022', 'dd.mm.yyyy'), 10 union all
select 111, to_date('15.08.2022', 'dd.mm.yyyy'), 0 union all
select 111, to_date('20.09.2022', 'dd.mm.yyyy'), 15 union all
select 111, to_date('15.07.2022', 'dd.mm.yyyy'), 25 union all
select 111, to_date('15.07.2022', 'dd.mm.yyyy'), 35 union all
select 222, to_date('15.07.2022', 'dd.mm.yyyy'), 5 union all
select 222, to_date('15.08.2022', 'dd.mm.yyyy'), 7 union all
select 222, to_date('15.09.2022', 'dd.mm.yyyy'), 0 union all
select 222, to_date('03.03.2023', 'dd.mm.yyyy'), 33 union all
select 222, to_date('04.04.2023', 'dd.mm.yyyy'), 44 union all
select 222, to_date('10.05.2023', 'dd.mm.yyyy'), 0
) select * from rest_history
Результат после обработки скриптом:
111 | 10.07.2022 | 14.08.2022
111 | 20.09.2022 | 31.12.2999
222 | 15.07.2022 | 14.09.2022
222 | 03.03.2023 | 09.05.2023
Присылайте решения😊
Свои решения я опубликую на следующей недели 💅
it пингвин | data engineer 🐧
#sql #задача
11.04.2025, 09:39
t.me/data_penguin/51
DA
it пингвин | data engineer
377
assinantes
Привет, подписчики!😎
За 3,5 года работы в it у меня скопилось не мало интересной полезной информации.
Буду делиться ею с вами.
В комменты прикреплю две прикольных презенташки с классным дизайном:
1️⃣- BigData 2021 (да, чуть старовата)
2️⃣- Linux
Как по мне такое интересно полистать, сохранить и иногда возвращаться к основам.
Дайте обратную связи по презенташкам и интересно ли вам такое?
#полезная_инфа
За 3,5 года работы в it у меня скопилось не мало интересной полезной информации.
Буду делиться ею с вами.
В комменты прикреплю две прикольных презенташки с классным дизайном:
1️⃣- BigData 2021 (да, чуть старовата)
2️⃣- Linux
Как по мне такое интересно полистать, сохранить и иногда возвращаться к основам.
Дайте обратную связи по презенташкам и интересно ли вам такое?
#полезная_инфа
9.04.2025, 09:14
t.me/data_penguin/50
DA
it пингвин | data engineer
377
assinantes
Разбор пятничной задачки.
Данные задачки решаются с помощью оконок и флагов (меток) 🤓❗️
Главное не запутаться.
Предлагаю свое решение:
WITH t1 AS ( -- проставляем флаги
SELECT t.*,
CASE WHEN end_t = LEAD(start_t) OVER (PARTITION BY phone_number ORDER BY start_t) THEN 1 ELSE 0 END AS start_lead, -- если end_t равен start_t след строки , ставим флаг 1
CASE WHEN start_t = LAG(end_t) OVER (PARTITION BY phone_number ORDER BY start_t) THEN 1 ELSE 0 END AS end_lag -- если start_t равен end_t пред строки, ставим флаг 1
FROM test_table t
)
SELECT DISTINCT phone_number,
CASE WHEN end_lag = 1 THEN LAG(start_t) OVER (PARTITION BY phone_number ORDER BY start_t) ELSE start_t END AS start_t,
CASE WHEN start_lead = 1 THEN LEAD(end_t) OVER (PARTITION BY phone_number ORDER BY start_t) ELSE end_t END AS end_t
FROM t1
-- строки с двумя флагами 1 надо отрезать
WHERE start_lead = 0
OR end_lag = 0
ORDER BY phone_number;
▪️Сначала проставляем флаги по нашей придуманной логике.
▪️Отрезаем лишние строки при помощи флагов.
▪️В последнем шаге правильно проставляем start_t и end_t.
В комментариях было выложено очень крутое правильное решение. Здесь классно используется накопительная сумма (оконка sum) и group by с min и max 👍
with t1 as (
select phone_number, start_t, end_t,
case when start_t = lag(end_t) over (partition by phone_number order by start_t) then 0 else 1 end as metka
from test_table),
t2 as (
select phone_number, start_t, end_t,
sum(metka) over (partition by phone_number order by start_t) as shlop
from t1)
select phone_number, min(start_t) as start_t, max(end_t) as end_t
from t2
group by 1, shlop
order by 1, 2
Решений таких задач можно много придумать. Полный разбор текстом не вижу смысла делать😄💅
Все скрипты создания таблицы и наполнения данными есть. Решения тоже есть. Кому интересно, посидите покрутите, будет точно полезно👍 На собеседование на мидла подобную задачу могут дать 💯
Если у кого еще появятся идеи, обязательно делитесь. Будем обсуждать😊
Данные задачки решаются с помощью оконок и флагов (меток) 🤓❗️
Главное не запутаться.
Предлагаю свое решение:
WITH t1 AS ( -- проставляем флаги
SELECT t.*,
CASE WHEN end_t = LEAD(start_t) OVER (PARTITION BY phone_number ORDER BY start_t) THEN 1 ELSE 0 END AS start_lead, -- если end_t равен start_t след строки , ставим флаг 1
CASE WHEN start_t = LAG(end_t) OVER (PARTITION BY phone_number ORDER BY start_t) THEN 1 ELSE 0 END AS end_lag -- если start_t равен end_t пред строки, ставим флаг 1
FROM test_table t
)
SELECT DISTINCT phone_number,
CASE WHEN end_lag = 1 THEN LAG(start_t) OVER (PARTITION BY phone_number ORDER BY start_t) ELSE start_t END AS start_t,
CASE WHEN start_lead = 1 THEN LEAD(end_t) OVER (PARTITION BY phone_number ORDER BY start_t) ELSE end_t END AS end_t
FROM t1
-- строки с двумя флагами 1 надо отрезать
WHERE start_lead = 0
OR end_lag = 0
ORDER BY phone_number;
▪️Сначала проставляем флаги по нашей придуманной логике.
▪️Отрезаем лишние строки при помощи флагов.
▪️В последнем шаге правильно проставляем start_t и end_t.
В комментариях было выложено очень крутое правильное решение. Здесь классно используется накопительная сумма (оконка sum) и group by с min и max 👍
with t1 as (
select phone_number, start_t, end_t,
case when start_t = lag(end_t) over (partition by phone_number order by start_t) then 0 else 1 end as metka
from test_table),
t2 as (
select phone_number, start_t, end_t,
sum(metka) over (partition by phone_number order by start_t) as shlop
from t1)
select phone_number, min(start_t) as start_t, max(end_t) as end_t
from t2
group by 1, shlop
order by 1, 2
Решений таких задач можно много придумать. Полный разбор текстом не вижу смысла делать😄💅
Все скрипты создания таблицы и наполнения данными есть. Решения тоже есть. Кому интересно, посидите покрутите, будет точно полезно👍 На собеседование на мидла подобную задачу могут дать 💯
Если у кого еще появятся идеи, обязательно делитесь. Будем обсуждать😊
7.04.2025, 16:43
t.me/data_penguin/49
DA
it пингвин | data engineer
377
assinantes
🔹Задача на схлопывание строк🔹
Есть данные привязки абонентов к базовым станциям оператора, необходимо схлопнуть строки, если дата окончания привязки абонента = дате начала следующей.
Для упрощения будем считать так:
📌Есть таблица, в которой три колонки - номер телефона, дата начала действия строки, дата окончания.
Если дата окончания текущей строки одного номера телефона = дате начала действия следующей строки этого же номера телефон, то мы должны схлопнуть эти строки в одну.
Пример:
88001153535 01.11.2024 13:23 01.11.2024 13:24
88001153535 01.11.2024 13:24 01.11.2024 13:25
Должны схлопнуть в одну строку:
88001153535 01.11.2024 13:23 01.11.2024 13:25
А строки
88001264545 01.11.2024 11:15 01.11.2024 11:24
88001264545 01.11.2024 12:00 01.11.2024 12:01
88001264545 01.11.2024 12:01 01.11.2024 12:08
88001264545 01.11.2024 12:15 01.11.2024 12:26
88001264545 01.11.2024 12:26 01.11.2024 12:35
88001264545 01.11.2024 12:35 01.11.2024 12:45
88001264545 01.11.2024 12:45 01.11.2024 13:14
88001264545 01.11.2024 13:14 01.11.2024 13:21
88001264545 01.11.2024 13:21 01.11.2024 13:26
88001264545 01.11.2024 13:26 01.11.2024 13:28
Должны схлопнуть в:
88001264545 01.11.2024 11:15 01.11.2024 11:24
88001264545 01.11.2024 12:00 01.11.2024 12:08
88001264545 01.11.2024 12:15 01.11.2024 13:28
(обратите внимание как 7 строк каскадно схлопнулись в одну)
Прикреплю скрин данных до обработки и после.
Также в комменты прикреплю скрипты создания таблицы и наполнения данными (для постгри).
Это реальный рабочий кейс и в целом типичная задача на схлопывание строк, которые дают на собесах.
Присылайте решения😊
Свои я опубликую в понедельник ближе к вечеру 💅
#sql #задача
Есть данные привязки абонентов к базовым станциям оператора, необходимо схлопнуть строки, если дата окончания привязки абонента = дате начала следующей.
Для упрощения будем считать так:
📌Есть таблица, в которой три колонки - номер телефона, дата начала действия строки, дата окончания.
Если дата окончания текущей строки одного номера телефона = дате начала действия следующей строки этого же номера телефон, то мы должны схлопнуть эти строки в одну.
Пример:
88001153535 01.11.2024 13:23 01.11.2024 13:24
88001153535 01.11.2024 13:24 01.11.2024 13:25
Должны схлопнуть в одну строку:
88001153535 01.11.2024 13:23 01.11.2024 13:25
А строки
88001264545 01.11.2024 11:15 01.11.2024 11:24
88001264545 01.11.2024 12:00 01.11.2024 12:01
88001264545 01.11.2024 12:01 01.11.2024 12:08
88001264545 01.11.2024 12:15 01.11.2024 12:26
88001264545 01.11.2024 12:26 01.11.2024 12:35
88001264545 01.11.2024 12:35 01.11.2024 12:45
88001264545 01.11.2024 12:45 01.11.2024 13:14
88001264545 01.11.2024 13:14 01.11.2024 13:21
88001264545 01.11.2024 13:21 01.11.2024 13:26
88001264545 01.11.2024 13:26 01.11.2024 13:28
Должны схлопнуть в:
88001264545 01.11.2024 11:15 01.11.2024 11:24
88001264545 01.11.2024 12:00 01.11.2024 12:08
88001264545 01.11.2024 12:15 01.11.2024 13:28
(обратите внимание как 7 строк каскадно схлопнулись в одну)
Прикреплю скрин данных до обработки и после.
Также в комменты прикреплю скрипты создания таблицы и наполнения данными (для постгри).
Это реальный рабочий кейс и в целом типичная задача на схлопывание строк, которые дают на собесах.
Присылайте решения😊
Свои я опубликую в понедельник ближе к вечеру 💅
#sql #задача
4.04.2025, 09:57
t.me/data_penguin/48
DA
it пингвин | data engineer
377
assinantes
Стандартизация SQL
SQL — один из самых старых языков программирования, но мало кто знает, как он менялся за 40 лет. Сегодня разберём стандартизацию SQL.
История SQL берёт начало в 1974 году, когда в лабораториях IBM в рамках проекта System R началась разработка экспериментальной реляционной СУБД. Изначально язык носил название SEQUEL (Structured English Query Language), но потом слово «English» пропало из этого словосочетания, а аббревиатура приобрела тот вид, к которому мы давно уже привыкли.
Бурное развитие коммерческих реализаций SQL и появление множества диалектов могло привести к серьёзным проблемам совместимости. Однако процесс стандартизации начался своевременно - уже в 1982 году ANSI (Американский национальный институт стандартов) поручил своему комитету по базам данных разработать единую спецификацию реляционного языка запросов, что позволило сохранить целостность экосистемы.
Основные стандарты SQL
➖ SQL-86. Первый вариант стандарта, принятый институтом ANSI и одобренный ISO в 1987 году. Базовые операции: SELECT, INSERT, UPDATE, DELETE, CREATE TABLE.
➖ SQL-89. Незначительные доработки предыдущего стандарта.
➖ SQL-92. Существенные изменения. Уровень Entry Level. JOIN-синтаксис (INNER /LEFT /RIGHT JOIN), ALTER TABLE, ограничения (CHECK, FOREIGN KEY), подзапросы. Стандартизировал поведение NULL и агрегатные функции. Золотой стандарт до сих пор.
➖ SQL:1999. Добавлены: регулярные выражения, рекурсивные запросы, триггеры, процедурные расширения, нескалярные типы данных, ООП-возможности.
➖ SQL:2003. Расширения для XML, оконные функции (OLAP), MERGE (UPSERT-операция), генераторы последовательностей.
➖ SQL:2006. Улучшена работа с XML, интеграция SQL и XQuery в запросах.
➖ SQL:2008. Устранены неоднозначности SQL:2003. TRUNCATE TABLE, улучшенные оконные функции (OVER, PARTITION BY). Пагинация через FETCH FIRST n ROWS ONLY (аналог LIMIT).
➖ SQL:2011. Поддержка временных данных (PERIOD FOR), уточнение ACID-транзакций для распределенных систем.
➖ SQL:2016. Защита на уровне строк, JSON-функции (JSON_ARRAY, JSON_OBJECT), ROW PATTERN MATCHING (поиск шаблонов в данных), полиморфные табличные функции.
➖ SQL:2023. Операции над графами, ANY_VALUE(), поддержка шестнадцатеричных/двоичных литералов, GREATEST/LEAST - функции для выбора max/min из списка значений, улучшенный MERGE - контроль над конфликтами при вставке, улучшения JSON - новые операторы для работы с JSON.
Куда движется SQL?
Современные стандарты SQL развиваются в сторону гибридных моделей данных (JSON, графы, векторы для AI) и глубокой аналитики – в будущем появятся встроенные ML-функции и улучшенная обработка временных рядов. Упор делается на безопасность (динамическое маскирование, аудит) и производительность (оптимизация JOIN, распределённые транзакции).
Постепенно стираются границы между SQL и NoSQL: новые версии стандарта добавляют поддержку полуструктурированных данных. Главный тренд – универсальность: один язык для OLTP, OLAP и даже машинного обучения.
Ни одна СУБД не поддерживает стандарты SQL полностью — все они используют собственные расширения и модификации.
Зачем тогда нужны стандарты?
Стандарты SQL служат универсальным ориентиром, задающим общую логику языка и основные принципы работы с данными. Хотя ни одна СУБД не реализует стандарт полностью, именно благодаря ему разные системы сохраняют базовую совместимость - например, все понимают запросы SELECT, WHERE или JOIN. Это позволяет разработчикам легче осваивать новые СУБД и переносить знания между проектами.
Кроме того, стандарт выступает "дорожной картой" развития - новые функции (вроде работы с JSON или оконных функций) сначала появляются в спецификации, а затем постепенно внедряются производителями СУБД. Без единого стандарта различия между диалектами были бы гораздо более радикальными, что затруднило бы работу с базами данных.
#sql
SQL — один из самых старых языков программирования, но мало кто знает, как он менялся за 40 лет. Сегодня разберём стандартизацию SQL.
История SQL берёт начало в 1974 году, когда в лабораториях IBM в рамках проекта System R началась разработка экспериментальной реляционной СУБД. Изначально язык носил название SEQUEL (Structured English Query Language), но потом слово «English» пропало из этого словосочетания, а аббревиатура приобрела тот вид, к которому мы давно уже привыкли.
Бурное развитие коммерческих реализаций SQL и появление множества диалектов могло привести к серьёзным проблемам совместимости. Однако процесс стандартизации начался своевременно - уже в 1982 году ANSI (Американский национальный институт стандартов) поручил своему комитету по базам данных разработать единую спецификацию реляционного языка запросов, что позволило сохранить целостность экосистемы.
Основные стандарты SQL
➖ SQL-86. Первый вариант стандарта, принятый институтом ANSI и одобренный ISO в 1987 году. Базовые операции: SELECT, INSERT, UPDATE, DELETE, CREATE TABLE.
➖ SQL-89. Незначительные доработки предыдущего стандарта.
➖ SQL-92. Существенные изменения. Уровень Entry Level. JOIN-синтаксис (INNER /LEFT /RIGHT JOIN), ALTER TABLE, ограничения (CHECK, FOREIGN KEY), подзапросы. Стандартизировал поведение NULL и агрегатные функции. Золотой стандарт до сих пор.
➖ SQL:1999. Добавлены: регулярные выражения, рекурсивные запросы, триггеры, процедурные расширения, нескалярные типы данных, ООП-возможности.
➖ SQL:2003. Расширения для XML, оконные функции (OLAP), MERGE (UPSERT-операция), генераторы последовательностей.
➖ SQL:2006. Улучшена работа с XML, интеграция SQL и XQuery в запросах.
➖ SQL:2008. Устранены неоднозначности SQL:2003. TRUNCATE TABLE, улучшенные оконные функции (OVER, PARTITION BY). Пагинация через FETCH FIRST n ROWS ONLY (аналог LIMIT).
➖ SQL:2011. Поддержка временных данных (PERIOD FOR), уточнение ACID-транзакций для распределенных систем.
➖ SQL:2016. Защита на уровне строк, JSON-функции (JSON_ARRAY, JSON_OBJECT), ROW PATTERN MATCHING (поиск шаблонов в данных), полиморфные табличные функции.
➖ SQL:2023. Операции над графами, ANY_VALUE(), поддержка шестнадцатеричных/двоичных литералов, GREATEST/LEAST - функции для выбора max/min из списка значений, улучшенный MERGE - контроль над конфликтами при вставке, улучшения JSON - новые операторы для работы с JSON.
Куда движется SQL?
Современные стандарты SQL развиваются в сторону гибридных моделей данных (JSON, графы, векторы для AI) и глубокой аналитики – в будущем появятся встроенные ML-функции и улучшенная обработка временных рядов. Упор делается на безопасность (динамическое маскирование, аудит) и производительность (оптимизация JOIN, распределённые транзакции).
Постепенно стираются границы между SQL и NoSQL: новые версии стандарта добавляют поддержку полуструктурированных данных. Главный тренд – универсальность: один язык для OLTP, OLAP и даже машинного обучения.
Ни одна СУБД не поддерживает стандарты SQL полностью — все они используют собственные расширения и модификации.
Зачем тогда нужны стандарты?
Стандарты SQL служат универсальным ориентиром, задающим общую логику языка и основные принципы работы с данными. Хотя ни одна СУБД не реализует стандарт полностью, именно благодаря ему разные системы сохраняют базовую совместимость - например, все понимают запросы SELECT, WHERE или JOIN. Это позволяет разработчикам легче осваивать новые СУБД и переносить знания между проектами.
Кроме того, стандарт выступает "дорожной картой" развития - новые функции (вроде работы с JSON или оконных функций) сначала появляются в спецификации, а затем постепенно внедряются производителями СУБД. Без единого стандарта различия между диалектами были бы гораздо более радикальными, что затруднило бы работу с базами данных.
#sql
3.04.2025, 09:18
t.me/data_penguin/47
DA
it пингвин | data engineer
377
assinantes
3.04.2025, 09:17
t.me/data_penguin/46
DA
it пингвин | data engineer
377
assinantes
1.04.2025, 12:15
t.me/data_penguin/45
DA
it пингвин | data engineer
377
assinantes
Привет, подписчики!😎
Вдруг еще кто-то не знает как обходить замедление ютуба на пк без vpn и всяких скамерских расширений, рассказываю:
Есть специальная приблуда, которой я пользуюсь с начала замедления ютуба и дискорда. Запускается батник (файлик) на винде, который, грубо говоря, не допускает срабатывания триггера запрета. Кому интересно, прочитаете про принцип работы на гите, там все подробно описано.
Этим обходом пользуются все мои коллеги. Вот ссылочка на git репу, скачивайте архив и запускайте файлик general (под админом) и все!
https://github.com/bol-van/zapret
* на всякий случай еще прикреплю архив
Дальше в планировщике заданий windows (открыть лучше под админом ) я создал задачу, которая запускает этот батник при входе винду. Cкрины задачи прикрепил в комментах (важно настроить запуск под админом).
И все просто работает, вы забываете про замедление ютуба, ресурсов никаких не тратится на этот обход, скама нет. Кому это было полезно, дайте знать. 😁
p.s. это не 1 апрельская шутка*
#полезные_инструменты
Вдруг еще кто-то не знает как обходить замедление ютуба на пк без vpn и всяких скамерских расширений, рассказываю:
Есть специальная приблуда, которой я пользуюсь с начала замедления ютуба и дискорда. Запускается батник (файлик) на винде, который, грубо говоря, не допускает срабатывания триггера запрета. Кому интересно, прочитаете про принцип работы на гите, там все подробно описано.
Этим обходом пользуются все мои коллеги. Вот ссылочка на git репу, скачивайте архив и запускайте файлик general (под админом) и все!
https://github.com/bol-van/zapret
* на всякий случай еще прикреплю архив
Дальше в планировщике заданий windows (открыть лучше под админом ) я создал задачу, которая запускает этот батник при входе винду. Cкрины задачи прикрепил в комментах (важно настроить запуск под админом).
И все просто работает, вы забываете про замедление ютуба, ресурсов никаких не тратится на этот обход, скама нет. Кому это было полезно, дайте знать. 😁
p.s. это не 1 апрельская шутка*
#полезные_инструменты
1.04.2025, 09:21
t.me/data_penguin/38
DA
it пингвин | data engineer
377
assinantes
Друзья, всем привет 👋. Врываемся в рабочую неделю! 🫠
Итак, давайте разберем результаты решения вот этой задачки.
Правильно ответили всего лишь 33% 😳. Возможно, варианты ответов были запутанные (я старался 🤝), но все-таки кто знает, как работают джоины решил бы легко. Думал будет больше правильных ответов.
Я попробую разжевать как решаются данные задачи🫡.
Пойдем поэтапно. Я сделал 3 схемы, скрин прикрепил. Внимательно изучите.
Дальше попробую объяснить текстом ( это сложновато, но попробую).
Объяснение:
1) Посмотрим, как соединяются строки с числами без null и без дублей. Здесь все легко.
• inner join – берем все что пересекается в двух таблицах, 2 и 3 есть в двух таблицах, значит берем 2 строки.
• left join – сразу берем все из левой таблицы (1,2,3) и ищем соответствия из правой (2, 3 соответствует), если в правой таблице нет равного значения ставим null.
• right join - наоборот, берем все из правой (2,3,4) , берем такие же значения из левой, если в левой таблице такого значения нет – ставим null.
• full join – как бы соединяем left и right, берем все из левой (1,2,3) и все из правой таблицы (2,3,4), если соответствий нет - ставим null. У 1 (единицы) из левой таблицы нет равного значения в правой, ставим null, у 4 (четверки) из правой таблицы, нет равного равного значения в левой - тоже ставим null.
• cross join. Запомните, при cross join-e всегда тупо все перемножаем. Без разницы равно или не равно. Проходимся по всем строкам в цикле. Берем 1 из левой таблицы, пробегаемся по всей правой ( (1,2), (1,3),(1,4)). Потом берем следующие строки..
2) Как соединятся строки с числа и с дублями, без null.
Что в этом случае будет отличаться. У нас здесь в левой таблице одна 2, а правой таблице две 2. Значит эти 2 (двойки) везде просто замножатся. Достаточно посмотреть на скрин.
3) Как соединяются null-ы (наша задачка)
Вот этот третий случай, на самом деле не очень простой (как и показал результат опроса). Его советую разок прям покрутить, создать таблицы и посмотреть, как выполняются соединения. Скрипты отправлю в комменты.
Здесь самое главное понять: Null не равно Null ❗️‼️
То есть null = null вернет False. Null is Null вернет True, но в соединении стоит = (равно). Поэтому в результате соединения с null-ми у нас всегда будет ложь и никаких соответствий не будет. И тем более не будет дублей.
Разберем. В левой таблиц три null-a, в правой два null-a.
• inner join – берем только то, что пересекается. Null из левой таблице не равен Null из правой. В результате у нас ничто ничему не равно. Возвращается 0 строк.
• left join - берем все из левой таблицы, это три null-a. У нас нет соответствии из правой таблицы (null не равен null), и тут интересный момент – мы все равно ставим null из справой. Но это как бы Null не из правой таблицы, а null то есть нет соответствия. Это надо осознать 🤔 . В рез-те возвращается 3 строки.
• right join – аналогично. Берем все из правой таблицы (два null-a), равных значений в левой таблице нет, значит ставим null. В рез-те возвращается 2 строки.
• full join – тоже сложновато представить. Мы берем все из левой таблицы (три null), равных значений в правой таблице – нет, значит ставим null. Далее также берем все из правой таблицы (два null), равных значений в левой таблице нет, ставим null. В результате возвращается 5 строк ( 3 из левой+ 2 из справой).
• cross join. Как писал ранее – тупо перемножаем. 3 null-a из левой * 2 null-a из правой таблицы = 6 строк со всеми null-ми. Нам без разницы равно что-то друг другу или нет, мы просто в цикле пробегаемся по все строкам.
Что касается, нашей задачки❗️. Слева 4 строки с null-ми, справа 10 строк с null-ми.
• inner join ничего не вернет ( 0 строк).
• left join вернет 4 строки (все из левой)
• right join вернет 10 строк (все из правой).
• full join 4 + 10 = 14 строк, все из левой + все из правой, а пересечений нет (null != null).
• cross join, перемножаем, 4*10=40 строк.
Если остались вопросы, смело задавайте!
#sql #база #jun
Итак, давайте разберем результаты решения вот этой задачки.
Правильно ответили всего лишь 33% 😳. Возможно, варианты ответов были запутанные (я старался 🤝), но все-таки кто знает, как работают джоины решил бы легко. Думал будет больше правильных ответов.
Я попробую разжевать как решаются данные задачи🫡.
Пойдем поэтапно. Я сделал 3 схемы, скрин прикрепил. Внимательно изучите.
Дальше попробую объяснить текстом ( это сложновато, но попробую).
Объяснение:
1) Посмотрим, как соединяются строки с числами без null и без дублей. Здесь все легко.
• inner join – берем все что пересекается в двух таблицах, 2 и 3 есть в двух таблицах, значит берем 2 строки.
• left join – сразу берем все из левой таблицы (1,2,3) и ищем соответствия из правой (2, 3 соответствует), если в правой таблице нет равного значения ставим null.
• right join - наоборот, берем все из правой (2,3,4) , берем такие же значения из левой, если в левой таблице такого значения нет – ставим null.
• full join – как бы соединяем left и right, берем все из левой (1,2,3) и все из правой таблицы (2,3,4), если соответствий нет - ставим null. У 1 (единицы) из левой таблицы нет равного значения в правой, ставим null, у 4 (четверки) из правой таблицы, нет равного равного значения в левой - тоже ставим null.
• cross join. Запомните, при cross join-e всегда тупо все перемножаем. Без разницы равно или не равно. Проходимся по всем строкам в цикле. Берем 1 из левой таблицы, пробегаемся по всей правой ( (1,2), (1,3),(1,4)). Потом берем следующие строки..
2) Как соединятся строки с числа и с дублями, без null.
Что в этом случае будет отличаться. У нас здесь в левой таблице одна 2, а правой таблице две 2. Значит эти 2 (двойки) везде просто замножатся. Достаточно посмотреть на скрин.
3) Как соединяются null-ы (наша задачка)
Вот этот третий случай, на самом деле не очень простой (как и показал результат опроса). Его советую разок прям покрутить, создать таблицы и посмотреть, как выполняются соединения. Скрипты отправлю в комменты.
Здесь самое главное понять: Null не равно Null ❗️‼️
То есть null = null вернет False. Null is Null вернет True, но в соединении стоит = (равно). Поэтому в результате соединения с null-ми у нас всегда будет ложь и никаких соответствий не будет. И тем более не будет дублей.
Разберем. В левой таблиц три null-a, в правой два null-a.
• inner join – берем только то, что пересекается. Null из левой таблице не равен Null из правой. В результате у нас ничто ничему не равно. Возвращается 0 строк.
• left join - берем все из левой таблицы, это три null-a. У нас нет соответствии из правой таблицы (null не равен null), и тут интересный момент – мы все равно ставим null из справой. Но это как бы Null не из правой таблицы, а null то есть нет соответствия. Это надо осознать 🤔 . В рез-те возвращается 3 строки.
• right join – аналогично. Берем все из правой таблицы (два null-a), равных значений в левой таблице нет, значит ставим null. В рез-те возвращается 2 строки.
• full join – тоже сложновато представить. Мы берем все из левой таблицы (три null), равных значений в правой таблице – нет, значит ставим null. Далее также берем все из правой таблицы (два null), равных значений в левой таблице нет, ставим null. В результате возвращается 5 строк ( 3 из левой+ 2 из справой).
• cross join. Как писал ранее – тупо перемножаем. 3 null-a из левой * 2 null-a из правой таблицы = 6 строк со всеми null-ми. Нам без разницы равно что-то друг другу или нет, мы просто в цикле пробегаемся по все строкам.
Что касается, нашей задачки❗️. Слева 4 строки с null-ми, справа 10 строк с null-ми.
• inner join ничего не вернет ( 0 строк).
• left join вернет 4 строки (все из левой)
• right join вернет 10 строк (все из правой).
• full join 4 + 10 = 14 строк, все из левой + все из правой, а пересечений нет (null != null).
• cross join, перемножаем, 4*10=40 строк.
Если остались вопросы, смело задавайте!
#sql #база #jun
31.03.2025, 10:42
t.me/data_penguin/37
DA
it пингвин | data engineer
377
assinantes
28.03.2025, 16:04
t.me/data_penguin/36
DA
it пингвин | data engineer
377
assinantes
Задача
Есть две таблицы из одного поля. В левой таблице table_1 - 4 строки, во всех null. В правой таблице table_2 - 10 строк, во всех также null.
Сколько строк вернет запрос из этих двух таблиц в результате соединений:
A - inner join
Б - left join
В - right join
Г - full join
Д - cross join
Есть две таблицы из одного поля. В левой таблице table_1 - 4 строки, во всех null. В правой таблице table_2 - 10 строк, во всех также null.
Сколько строк вернет запрос из этих двух таблиц в результате соединений:
A - inner join
Б - left join
В - right join
Г - full join
Д - cross join
28.03.2025, 16:04
t.me/data_penguin/35
DA
it пингвин | data engineer
377
assinantes
Ч.2.
Операция UPDATE
При INSERT добавлении новых данных UPDATE изменяются уже существующие — и вот тут-то все становится сложнее. UPDATE Операции часто задействуют несколько подсистем в базе данных, что делает их ресурсоемкими.
Нахождение строк
Каждый UPDATE начинается с поиска. Механизм базы данных должен найти точные строки, которые соответствуют WHERE предложению.
Если WHERE предложение нацелено на индексированные столбцы, это может быть относительно эффективно. Однако, если запрос фильтрует неиндексированные столбцы, движку может потребоваться некоторое время для сканирования всей таблицы. На небольших наборах данных это управляемо, но по мере роста таблицы процесс поиска может стать мучительно медленным.
💡 Плохо оптимизированные запросы или отсутствующие индексы могут увеличить стоимость поиска строк, что значительно повлияет на производительность. Опять же, оптимизацию часто нужно выполнять в пространстве между монитором и креслом.
Индексированные столбцы
Хотя индексы отлично подходят для ускорения поиска, при их изменении они добавляют значительные накладные расходы. База данных должна не только обновить строку, но и пересмотреть каждый связанный индекс. Следовательно, обновление индексированных столбцов может быть медленным.
Для составных индексов сложность умножается. Обновление одного значения может привести к пересчету и изменению положения записи индекса. Чем больше индексов привязано к столбцу, тем больше времени база данных тратит на перетасовку данных, замедляя UPDATE.
Параллелизм
В отличие от относительно дружественных к параллелизму операций INSERT, UPDATE операции могут быть блокировочными. Чтобы обеспечить целостность данных, база данных часто блокирует обновляемые ею строки, не давая другим операциям изменять их одновременно. Для небольших таблиц с низким трафиком это нормально. Но в средах с высоким параллелизмом эти блокировки могут перерасти в тех же двух подозреваемых: конфликт блокировок или взаимоблокировки.
💡 Минимизируйте область блокировок, ограничив строки, на которые нацелены запросы UPDATE (предложения WHERE — ваши лучшие друзья). Пакетные обновления также могут помочь уменьшить конкуренцию.
Журналы транзакций
Базы данных ведут журналы транзакций для обеспечения согласованности и поддержки откатов. Хотя INSERTи UPDATE запись в журнал транзакций, UPDATE как правило, более многословна.
Это особенно актуально для баз данных, таких как PostgreSQL, которые используют Multi-Version Concurrency Control (MVCC) . Здесь UPDATE не перезаписывает существующую строку, а создает новую версию строки и помечает старую как «мертвую». Этот процесс обеспечивает согласованность и поддерживает параллельные чтения, но со временем может привести к фрагментации и потребовать регулярных VACUUM операций по освобождению хранилища.
Что сложнее?
Если вы добавляете новые строки с небольшим количеством индексов или без них и минимальными ограничениями, INSERT обычно это будет более простым вариантом. Обычно это проще и понятнее, когда данные свежие и таблица не сильно индексирована. Но как только в дело вступают индексы, триггеры и высокая степень параллелизма, INSERT это может начать нагружать ресурсы базы данных.
UPDATE, с другой стороны, часто требует большего от базы данных с самого начала. От поиска строк, обновления данных, управления индексами до блокировки ресурсов — это многоуровневый процесс, и каждый шаг может привести к узким местам производительности. При наличии нескольких индексов или большого объема транзакций UPDATE может стать дорогостоящей операцией как с точки зрения времени, так и производительности базы данных.
Подводя итоги
Выбор между INSERT и UPDATE во многом зависит от вашего варианта использования и структуры вашей базы данных. Например, если вы имеете дело с большими объемами обновлений, вы можете рассмотреть альтернативные стратегии, такие как вставка новой строки и удаление старой, вместо выполнения тяжелого обновления, особенно если обновления рискуют фрагментировать таблицу или повлиять на несколько индексов.
Операция UPDATE
При INSERT добавлении новых данных UPDATE изменяются уже существующие — и вот тут-то все становится сложнее. UPDATE Операции часто задействуют несколько подсистем в базе данных, что делает их ресурсоемкими.
Нахождение строк
Каждый UPDATE начинается с поиска. Механизм базы данных должен найти точные строки, которые соответствуют WHERE предложению.
Если WHERE предложение нацелено на индексированные столбцы, это может быть относительно эффективно. Однако, если запрос фильтрует неиндексированные столбцы, движку может потребоваться некоторое время для сканирования всей таблицы. На небольших наборах данных это управляемо, но по мере роста таблицы процесс поиска может стать мучительно медленным.
💡 Плохо оптимизированные запросы или отсутствующие индексы могут увеличить стоимость поиска строк, что значительно повлияет на производительность. Опять же, оптимизацию часто нужно выполнять в пространстве между монитором и креслом.
Индексированные столбцы
Хотя индексы отлично подходят для ускорения поиска, при их изменении они добавляют значительные накладные расходы. База данных должна не только обновить строку, но и пересмотреть каждый связанный индекс. Следовательно, обновление индексированных столбцов может быть медленным.
Для составных индексов сложность умножается. Обновление одного значения может привести к пересчету и изменению положения записи индекса. Чем больше индексов привязано к столбцу, тем больше времени база данных тратит на перетасовку данных, замедляя UPDATE.
Параллелизм
В отличие от относительно дружественных к параллелизму операций INSERT, UPDATE операции могут быть блокировочными. Чтобы обеспечить целостность данных, база данных часто блокирует обновляемые ею строки, не давая другим операциям изменять их одновременно. Для небольших таблиц с низким трафиком это нормально. Но в средах с высоким параллелизмом эти блокировки могут перерасти в тех же двух подозреваемых: конфликт блокировок или взаимоблокировки.
💡 Минимизируйте область блокировок, ограничив строки, на которые нацелены запросы UPDATE (предложения WHERE — ваши лучшие друзья). Пакетные обновления также могут помочь уменьшить конкуренцию.
Журналы транзакций
Базы данных ведут журналы транзакций для обеспечения согласованности и поддержки откатов. Хотя INSERTи UPDATE запись в журнал транзакций, UPDATE как правило, более многословна.
Это особенно актуально для баз данных, таких как PostgreSQL, которые используют Multi-Version Concurrency Control (MVCC) . Здесь UPDATE не перезаписывает существующую строку, а создает новую версию строки и помечает старую как «мертвую». Этот процесс обеспечивает согласованность и поддерживает параллельные чтения, но со временем может привести к фрагментации и потребовать регулярных VACUUM операций по освобождению хранилища.
Что сложнее?
Если вы добавляете новые строки с небольшим количеством индексов или без них и минимальными ограничениями, INSERT обычно это будет более простым вариантом. Обычно это проще и понятнее, когда данные свежие и таблица не сильно индексирована. Но как только в дело вступают индексы, триггеры и высокая степень параллелизма, INSERT это может начать нагружать ресурсы базы данных.
UPDATE, с другой стороны, часто требует большего от базы данных с самого начала. От поиска строк, обновления данных, управления индексами до блокировки ресурсов — это многоуровневый процесс, и каждый шаг может привести к узким местам производительности. При наличии нескольких индексов или большого объема транзакций UPDATE может стать дорогостоящей операцией как с точки зрения времени, так и производительности базы данных.
Подводя итоги
Выбор между INSERT и UPDATE во многом зависит от вашего варианта использования и структуры вашей базы данных. Например, если вы имеете дело с большими объемами обновлений, вы можете рассмотреть альтернативные стратегии, такие как вставка новой строки и удаление старой, вместо выполнения тяжелого обновления, особенно если обновления рискуют фрагментировать таблицу или повлиять на несколько индексов.
28.03.2025, 09:58
t.me/data_penguin/34
DA
it пингвин | data engineer
377
assinantes
Ч.1.
INSERT и UPDATE и их влияние на прием данных
«С чем сложнее работать базе данных — INSERT с данными или UPDATE?»
Сначала вы можете подумать: «А какое это имеет значение? Они служат разным целям, верно?» INSERT добавляет новые строки и UPDATE изменяет существующие — дело закрыто. Когда вы загружаете данные в систему — синхронизируете внешние источники, вставляете данные или обновляете аналитические таблицы — выбор между INSERT и UPDATE может существенно повлиять на производительность и масштабируемость вашей базы данных.
Операция INSERT
На первый взгляд, INSERT кажется, все просто — добавить новую строку в систему. Но если заглянуть под капот, то все сложнее, чем может показаться.
Индексы
Когда вы вставляете строку, это не просто добавление данных в таблицу. Движок базы данных также должен обновить все связанные индексы. Если вы думаете об индексах как о каталогах, то каждая новая запись должна быть аккуратно помещена на свое правильное место, гарантируя, что каталог останется отсортированным и полезным.
Больше индексов означает больше накладных расходов. Каждый дополнительный индекс требует дополнительных усилий для расчета, поиска и хранения новых данных. В то время как индекс с одним столбцом обновляется относительно быстро, составные или уникальные индексы (например, (user_id, created_at)) добавляют сложности и задержки.
💡 Избегайте слепого добавления индексов. Каждый из них повышает производительность запросов, но замедляет INSERT. Стремитесь к балансу.
Ограничения и триггеры
Прежде чем новые данные официально попадут в таблицу, они должны пройти несколько проверок целостности. Эти ограничения включают внешние ключи для обеспечения связей, UNIQUE ограничения для предотвращения дублирования записей и NOT NULL требования для обеспечения качества данных. Если схема включает вычисляемые столбцы, база данных должна вычислять их значения на лету.
Кроме того, триггеры могут выполнять пользовательскую логику во время вставки, например, ведение журнала или каскадные обновления (или любую другую пользовательскую логику, которая у вас может быть). Хотя они полезны, они могут значительно увеличить рабочую нагрузку, особенно для сложных схем данных.
Параллелизм
INSERT Операции, как правило, хорошо взаимодействуют с блокировками, используя минимальные механизмы блокировки, такие как блокировки строк или страниц . Однако параллелизм все еще может вызывать головную боль в системах с высокой нагрузкой. Если несколько потоков одновременно пытаются вставить данные в одну и ту же таблицу или раздел, может возникнуть конфликт блокировок. Или, что еще хуже, взаимоблокировки — когда две транзакции блокируют друг друга на неопределенный срок.
💡 Для сред с высоким уровнем параллелизма:
1. Используйте пакетирование для массовых вставок.
2. Рассмотрите возможность секционирования или сегментирования для распределения нагрузки.
Раздувание хранилища
Массовые вставки или частые небольшие вставки могут со временем привести к раздуванию таблицы при увеличении ее физического размера, даже если объем полезных данных в таблице может и не увеличиться существенно:
Фрагментация : частые вставки могут фрагментировать базовое хранилище, снижая производительность последующих операций чтения и записи.
Раздувание : таблицы без надлежащего обслуживания (например, периодической очистки или архивации) могут неоправданно разрастаться, занимая место в хранилище и снижая производительность.
💡 Планируйте регулярные задачи по обслуживанию, такие как VACUUM, ANALYZE или архивирование, чтобы бороться с раздуванием и фрагментацией. Однако будьте осторожны — эти операции могут полностью заблокировать вашу базу данных.
INSERT и UPDATE и их влияние на прием данных
«С чем сложнее работать базе данных — INSERT с данными или UPDATE?»
Сначала вы можете подумать: «А какое это имеет значение? Они служат разным целям, верно?» INSERT добавляет новые строки и UPDATE изменяет существующие — дело закрыто. Когда вы загружаете данные в систему — синхронизируете внешние источники, вставляете данные или обновляете аналитические таблицы — выбор между INSERT и UPDATE может существенно повлиять на производительность и масштабируемость вашей базы данных.
Операция INSERT
На первый взгляд, INSERT кажется, все просто — добавить новую строку в систему. Но если заглянуть под капот, то все сложнее, чем может показаться.
Индексы
Когда вы вставляете строку, это не просто добавление данных в таблицу. Движок базы данных также должен обновить все связанные индексы. Если вы думаете об индексах как о каталогах, то каждая новая запись должна быть аккуратно помещена на свое правильное место, гарантируя, что каталог останется отсортированным и полезным.
Больше индексов означает больше накладных расходов. Каждый дополнительный индекс требует дополнительных усилий для расчета, поиска и хранения новых данных. В то время как индекс с одним столбцом обновляется относительно быстро, составные или уникальные индексы (например, (user_id, created_at)) добавляют сложности и задержки.
💡 Избегайте слепого добавления индексов. Каждый из них повышает производительность запросов, но замедляет INSERT. Стремитесь к балансу.
Ограничения и триггеры
Прежде чем новые данные официально попадут в таблицу, они должны пройти несколько проверок целостности. Эти ограничения включают внешние ключи для обеспечения связей, UNIQUE ограничения для предотвращения дублирования записей и NOT NULL требования для обеспечения качества данных. Если схема включает вычисляемые столбцы, база данных должна вычислять их значения на лету.
Кроме того, триггеры могут выполнять пользовательскую логику во время вставки, например, ведение журнала или каскадные обновления (или любую другую пользовательскую логику, которая у вас может быть). Хотя они полезны, они могут значительно увеличить рабочую нагрузку, особенно для сложных схем данных.
Параллелизм
INSERT Операции, как правило, хорошо взаимодействуют с блокировками, используя минимальные механизмы блокировки, такие как блокировки строк или страниц . Однако параллелизм все еще может вызывать головную боль в системах с высокой нагрузкой. Если несколько потоков одновременно пытаются вставить данные в одну и ту же таблицу или раздел, может возникнуть конфликт блокировок. Или, что еще хуже, взаимоблокировки — когда две транзакции блокируют друг друга на неопределенный срок.
💡 Для сред с высоким уровнем параллелизма:
1. Используйте пакетирование для массовых вставок.
2. Рассмотрите возможность секционирования или сегментирования для распределения нагрузки.
Раздувание хранилища
Массовые вставки или частые небольшие вставки могут со временем привести к раздуванию таблицы при увеличении ее физического размера, даже если объем полезных данных в таблице может и не увеличиться существенно:
Фрагментация : частые вставки могут фрагментировать базовое хранилище, снижая производительность последующих операций чтения и записи.
Раздувание : таблицы без надлежащего обслуживания (например, периодической очистки или архивации) могут неоправданно разрастаться, занимая место в хранилище и снижая производительность.
💡 Планируйте регулярные задачи по обслуживанию, такие как VACUUM, ANALYZE или архивирование, чтобы бороться с раздуванием и фрагментацией. Однако будьте осторожны — эти операции могут полностью заблокировать вашу базу данных.
28.03.2025, 09:58
t.me/data_penguin/33
DA
it пингвин | data engineer
377
assinantes
Вчера наткнулся на интересную статью и решил поделиться с вами (украсть💅) .
Статья взята из блога Senior-а DE из Spotify https://luminousmen.com, рекомендую.
Статья взята из блога Senior-а DE из Spotify https://luminousmen.com, рекомендую.
28.03.2025, 09:57
t.me/data_penguin/32
DA
it пингвин | data engineer
377
assinantes
Коллеги, спасибо за прохождение опросов 😊. Данные приняты к сведению, будем работать ✊
28.03.2025, 09:56
t.me/data_penguin/31
DA
it пингвин | data engineer
377
assinantes
27.03.2025, 14:51
t.me/data_penguin/30
DA
it пингвин | data engineer
377
assinantes
27.03.2025, 14:48
t.me/data_penguin/29
DA
it пингвин | data engineer
377
assinantes
27.03.2025, 14:46
t.me/data_penguin/28
DA
it пингвин | data engineer
377
assinantes
27.03.2025, 14:45
t.me/data_penguin/27
DA
it пингвин | data engineer
377
assinantes
Прошла ровно неделя с момента создания, а к каналу 🐧 присоединилось уже 88 человек (будет круто если сегодня до 100 дойдем 😁).
Отличный результат, спасибо!🔥
Давайте проведем несколько опросов, чтоб понимать какая у нас аудитория и какие интересы.
* свои варианты опросов можете тоже предлагать
Отличный результат, спасибо!🔥
Давайте проведем несколько опросов, чтоб понимать какая у нас аудитория и какие интересы.
* свои варианты опросов можете тоже предлагать
27.03.2025, 14:44
t.me/data_penguin/26
DA
it пингвин | data engineer
377
assinantes
27.03.2025, 08:28
t.me/data_penguin/25
DA
it пингвин | data engineer
377
assinantes
Вакансия: Senior DWH разработчик
Компания: Магнит TECH
Предполагаемая вилка: от 270к на руки
Период собеседования: Декабрь 2024
Формат работы: Удаленная работа
Этапы собеседований:
HR -> Tech Interview -> Offer
Краткая справка о процессе интервью:
Собеседовал тех лид команды, который был очень технически подкован. Тех лид задавал интересные вопросы про опыт работы, моделирование, индексы, оптимизацию, план запроса и дал пару задачек. То есть он не просто задавал банальные вопросы, а копал все глубже и глубже, чтоб понять уровень знаний. И большой респект, что сам давал какие-то ответы и объяснял технические нюансы.
Более подробно:
Я рассказал о своем опыте. Тех лида заинтересовал опыт с созданием с нуля витрины данных. Он спрашивал про выбор модели, как я оценивал объем данных и прогнозировал что будет через год. Спрашивал про типы полей, размерности, индексы.
Блок про моделирование. Снежинка/звезда/ - где что используются, плюсы и минусы. Data vault- что это и за счет чего достигается гибкость.
Большой блок вопросов про внутренности БД - про план запроса, статистику, кардиналити, какие бывают методы доступа к таблицам. Индексы – что это и какие виды знаю, чем отличается бинарное дерево от сбалансированного, сколько уровней в сбалансированном дереве, битмап индекс. Методы физического соединения – какие есть виды(по каждому виду задавал много вопросов), какой метод соединения предпочтителен при соединении больших таблиц (важно учитывать какая СУБД), что такое хэш мапа, почему по ней быстрый поиск.
Когда говорили про переезд в облако, собеседующий сказал, что до конца не решили на какой стек они переедут. Активно занимаются этим вопросом. Смотрят на опыт других больших компаний. DWH на GP не хотят мигрировать. Сказал, что очень много косяков с GP и он считает, что многие компании тоже от GP откажутся.
В конце дал две несложных задачки на джоины и оконки.
Через неделю пришел отказ, так как магнит тех переезжает в облако и им нужен более опытный инженер (ближе к архитектору), который также шарит за S3 и желательно Impala.
Люблю такие собесы – получается бесплатная проверка знаний + собеседующий много всего сам объяснил и сказал, что можно изучить. Отношение к компании улучшилось.
Еще из интересного вакансию нашел не на hh, а на их сайте и сам отправил свое резюме.
*идея позаимствована у https://t.me/get_rejected
#Собес
Компания: Магнит TECH
Предполагаемая вилка: от 270к на руки
Период собеседования: Декабрь 2024
Формат работы: Удаленная работа
Этапы собеседований:
HR -> Tech Interview -> Offer
Краткая справка о процессе интервью:
Собеседовал тех лид команды, который был очень технически подкован. Тех лид задавал интересные вопросы про опыт работы, моделирование, индексы, оптимизацию, план запроса и дал пару задачек. То есть он не просто задавал банальные вопросы, а копал все глубже и глубже, чтоб понять уровень знаний. И большой респект, что сам давал какие-то ответы и объяснял технические нюансы.
Более подробно:
Я рассказал о своем опыте. Тех лида заинтересовал опыт с созданием с нуля витрины данных. Он спрашивал про выбор модели, как я оценивал объем данных и прогнозировал что будет через год. Спрашивал про типы полей, размерности, индексы.
Блок про моделирование. Снежинка/звезда/ - где что используются, плюсы и минусы. Data vault- что это и за счет чего достигается гибкость.
Большой блок вопросов про внутренности БД - про план запроса, статистику, кардиналити, какие бывают методы доступа к таблицам. Индексы – что это и какие виды знаю, чем отличается бинарное дерево от сбалансированного, сколько уровней в сбалансированном дереве, битмап индекс. Методы физического соединения – какие есть виды(по каждому виду задавал много вопросов), какой метод соединения предпочтителен при соединении больших таблиц (важно учитывать какая СУБД), что такое хэш мапа, почему по ней быстрый поиск.
Когда говорили про переезд в облако, собеседующий сказал, что до конца не решили на какой стек они переедут. Активно занимаются этим вопросом. Смотрят на опыт других больших компаний. DWH на GP не хотят мигрировать. Сказал, что очень много косяков с GP и он считает, что многие компании тоже от GP откажутся.
В конце дал две несложных задачки на джоины и оконки.
Через неделю пришел отказ, так как магнит тех переезжает в облако и им нужен более опытный инженер (ближе к архитектору), который также шарит за S3 и желательно Impala.
Люблю такие собесы – получается бесплатная проверка знаний + собеседующий много всего сам объяснил и сказал, что можно изучить. Отношение к компании улучшилось.
Еще из интересного вакансию нашел не на hh, а на их сайте и сам отправил свое резюме.
*идея позаимствована у https://t.me/get_rejected
#Собес
26.03.2025, 12:17
t.me/data_penguin/18
DA
it пингвин | data engineer
377
assinantes
Вопросы про джоины:
Буду делать серию постов про самые популярные вопросы по sql секции.
Я думаю, на любом собесе будут вопросы про джоины. Давайте разберем популярные вопросы/задачи:
1) Минимальное и максимальное количество строк в результате джоинов.
Допустим левая таблица t1 (поле id) – 100 строк, правая таблица t2 (id) – 10 строк
inner join:
Min – 0 строк. Если никаких пересечений нет, в двух таблицах нет одинаковых id.
Max – 1000 строк. Если в двух таблицах только одно значение (например, 1). Просто делаем перемножение.
left join:
Min – 100 строк. Если никаких пересечений нет, в результате будут все значения из левой таблицы.
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.
right join:
Min – 10 строк. Если никаких пересечений нет, в результате будут все значения из правой таблицы
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.
full join:
Min – 100 строк. Вот этот момент важно понять, на нем часто допускают ошибки. Минимальное количество при full join будет – количество строк из большей таблицы. Например, в левой таблице значения от 1 до 100, а в правой от 1 до 10.
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.
cross join:
Min и Max – 1000 строк. Делаем перемножение.
2) Сколько строк вернет операция FULL JOIN, если известно следующее:
INNER JOIN - 6 строк
LEFT JOIN - 10 строк
RIGHT JOIN - 12 строк
Давайте попробуем ее решить без запоминаний и просто понять.
Если вспомнить круги Эйлера (о их корректности будет отдельный пост):
FULL JOIN – это левая непересекающаяся часть + средняя пересекающаяся часть + правая непересекающаяся часть. Просуммируем эти три части:
FULL JOIN = (LEFT JOIN - INNER JOIN) + (INNER JOIN) + (RIGHT JOIN - INNER JOIN)
FULL JOIN = (10 - 6) + (6) + (12-6)
FULL JOIN = 16
Также если раскрыть скобки, то можно понять, что по сути
FULL JOIN = (RIGHT JOIN) + (LEFT JOIN) – (INNER JOIN) = 10 + 12 – 6 = 16
3) Заполнение результата после всех видов джоинов.
Такую задачу тоже часто дают, здесь важно не запутаться. Я приложил скрин с результатами джоинов, внимательно изучите. Особенно обратите внимание на результат соединения дублей и null-ов.
Расскажите какие у вас были интересные вопросы про джоины: 💭
#Вопросы_с_собесов
Буду делать серию постов про самые популярные вопросы по sql секции.
Я думаю, на любом собесе будут вопросы про джоины. Давайте разберем популярные вопросы/задачи:
1) Минимальное и максимальное количество строк в результате джоинов.
Допустим левая таблица t1 (поле id) – 100 строк, правая таблица t2 (id) – 10 строк
inner join:
Min – 0 строк. Если никаких пересечений нет, в двух таблицах нет одинаковых id.
Max – 1000 строк. Если в двух таблицах только одно значение (например, 1). Просто делаем перемножение.
left join:
Min – 100 строк. Если никаких пересечений нет, в результате будут все значения из левой таблицы.
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.
right join:
Min – 10 строк. Если никаких пересечений нет, в результате будут все значения из правой таблицы
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.
full join:
Min – 100 строк. Вот этот момент важно понять, на нем часто допускают ошибки. Минимальное количество при full join будет – количество строк из большей таблицы. Например, в левой таблице значения от 1 до 100, а в правой от 1 до 10.
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.
cross join:
Min и Max – 1000 строк. Делаем перемножение.
2) Сколько строк вернет операция FULL JOIN, если известно следующее:
INNER JOIN - 6 строк
LEFT JOIN - 10 строк
RIGHT JOIN - 12 строк
Давайте попробуем ее решить без запоминаний и просто понять.
Если вспомнить круги Эйлера (о их корректности будет отдельный пост):
FULL JOIN – это левая непересекающаяся часть + средняя пересекающаяся часть + правая непересекающаяся часть. Просуммируем эти три части:
FULL JOIN = (LEFT JOIN - INNER JOIN) + (INNER JOIN) + (RIGHT JOIN - INNER JOIN)
FULL JOIN = (10 - 6) + (6) + (12-6)
FULL JOIN = 16
Также если раскрыть скобки, то можно понять, что по сути
FULL JOIN = (RIGHT JOIN) + (LEFT JOIN) – (INNER JOIN) = 10 + 12 – 6 = 16
3) Заполнение результата после всех видов джоинов.
Такую задачу тоже часто дают, здесь важно не запутаться. Я приложил скрин с результатами джоинов, внимательно изучите. Особенно обратите внимание на результат соединения дублей и null-ов.
Расскажите какие у вас были интересные вопросы про джоины: 💭
#Вопросы_с_собесов
24.03.2025, 10:12
t.me/data_penguin/17
DA
it пингвин | data engineer
377
assinantes
Предыстория: 📚
Книги я особо не читаю. Начал читать в 20+ лет и только в последний год читаю одну книгу в два месяца. Читаю художественную литературу (нравится больше всего), техническую и историческую.
Бизнесовую/саморазвития/психологическую литературу не очень люблю. Как-то начал читать всеми известную «Богатый папа, бедный папа». Прочитал страниц 15 и бросил. Банальщина... 🙄
Недавно купил еще одну классику «Думай и богатей» (авт. Наполеон Хилл), просто ради интереса. Это похоже на прародителя инфоцыган, там есть основные заповеди для достижения цели – мечтай, воображай, верь и перечитывай эту книгу каждый день.. 🫢
Но читается легко. Там приводятся в пример истории реальных людей, и это иногда интересно. 🧐
Зачем я об этом вообще пишу:
Книга 1937 года! И вот вчера я наткнулся на такой абзац ( фото в закрепе).
Почти 100 лет назад в Америке уже учили, как составлять резюме и продавать себя. Многое из рекомендаций сейчас, конечно, неактуально – печать резюме на дорогой бумаге, класть его в очень дорогую, красивую папку, делать фото в крутой студии и т.д.
Просто как факт, 100 лет назад в США уже была корпоративная культура, многие люди уже были заряжены на построение успешной карьеры. 💼✨
А до нашей страны это дошло недавно. Ну, наверное, лет 20 назад (можете поправить)..
В России всё только зарождается, и у нас есть большие перспективы преуспеть в корпоративной культуре. Но считаю нормальным и очень полезным перенимать опыт западных стран, модифицировать, улучшать и применять его у нас. 🌍🚀
Что думаете? 🤔 Может, у вас есть свои примеры или мысли на эту тему? 💭
#книги
Книги я особо не читаю. Начал читать в 20+ лет и только в последний год читаю одну книгу в два месяца. Читаю художественную литературу (нравится больше всего), техническую и историческую.
Бизнесовую/саморазвития/психологическую литературу не очень люблю. Как-то начал читать всеми известную «Богатый папа, бедный папа». Прочитал страниц 15 и бросил. Банальщина... 🙄
Недавно купил еще одну классику «Думай и богатей» (авт. Наполеон Хилл), просто ради интереса. Это похоже на прародителя инфоцыган, там есть основные заповеди для достижения цели – мечтай, воображай, верь и перечитывай эту книгу каждый день.. 🫢
Но читается легко. Там приводятся в пример истории реальных людей, и это иногда интересно. 🧐
Зачем я об этом вообще пишу:
Книга 1937 года! И вот вчера я наткнулся на такой абзац ( фото в закрепе).
Почти 100 лет назад в Америке уже учили, как составлять резюме и продавать себя. Многое из рекомендаций сейчас, конечно, неактуально – печать резюме на дорогой бумаге, класть его в очень дорогую, красивую папку, делать фото в крутой студии и т.д.
Просто как факт, 100 лет назад в США уже была корпоративная культура, многие люди уже были заряжены на построение успешной карьеры. 💼✨
А до нашей страны это дошло недавно. Ну, наверное, лет 20 назад (можете поправить)..
В России всё только зарождается, и у нас есть большие перспективы преуспеть в корпоративной культуре. Но считаю нормальным и очень полезным перенимать опыт западных стран, модифицировать, улучшать и применять его у нас. 🌍🚀
Что думаете? 🤔 Может, у вас есть свои примеры или мысли на эту тему? 💭
#книги
21.03.2025, 14:13
t.me/data_penguin/14
DA
it пингвин | data engineer
377
assinantes
21.03.2025, 09:43
t.me/data_penguin/13
DA
it пингвин | data engineer
377
assinantes
Всем привет! Это IT Пингвин 🐧.
Сейчас, как никогда, популярно создавать айтишные Telegram-каналы, и я тоже решил попробовать свои силы. Мне действительно есть чем поделиться, и я думаю, что мой канал будет полезен многим. 💡
О себе:
Мне 25 лет, и я - главный разработчик озера данных в одном из топовых банков России. 🏦 За плечами - опыт работы в крупных IT-компаниях (телеком и банки), а в трудовой книжке есть записи: инженер КХД, ETL-разработчик, Data Engineer. 💻
За последний год я прошел около 30 собеседований, и многие из них подробно задокументировал и разобрал. 📝 Кроме того, я сам проводил собеседования для стажеров, был ментором на стажировках и помог десятку ребят попасть на проекты топовых банков РФ.
Я также занимаюсь менторством: обучаю SQL, Oracle, немного Python, помогаю готовиться к собеседованиям и делюсь лайфхаками из личного опыта. 📚 Еще у меня есть опыт подготовки студентов из ВШЭ и МГУ к экзаменам и выполнения лабораторных работ. 🎓
Несколько фактов обо мне:
• Учусь на работе. Даже будучи главным разработчиком, я продолжаю учиться и развиваться. 📖
• Неосознанно крутил опыт в резюме. Сделаю об этом пост. 🤫
• Играл (и иногда играю) в доту в рабочее время. Ну а кто не играл? 😅
Цели на будущее: хочу попробовать работать параллельно на двух работах и, возможно, на валютной удаленке из РФ. 🌍
Что ждет на канале:
Этот канал - это место, где я делюсь тем, что было бы полезно и интересно мне самому. Здесь будет много полезной информации: от базовых основ для новичков 🐣 до продвинутых лайфхаков и хардкорных инсайдов. 💥
Я буду прикреплять крутые пет-проекты, рекомендовать статьи, книги и бесплатные курсы, которые сам прошел и проверил на себе. 📂
Расскажу о своем пути в IT, поделюсь личным опытом и лайфхаками, которые помогли мне расти. 📈
Будет много информации с собесов: как составить резюме, которое заметят, какие вопросы задают на собесах, как решать задачки, торговаться за оффер и на что обращать внимание при выборе компании. 💼 Буду делиться своими кейсами прохождения собесов (привет реджектику) - от первых шагов до успешных офферов. 🎯
Но самое главное - этот канал будет правдивым и искренним. Да, я многое знаю, и на всех работах мною были довольны: меня ценили за результат, не хотели отпускать и перебивали офферы . Но я всегда помню, что мне еще очень многому нужно научиться. Поэтому я постоянно учусь, ошибаюсь, и (добавим пафоса) падаю и снова встаю. 💪
Я буду писать не только о своих успехах, но и о неудачах, банальных открытиях, провалах и даже конфликтах. Потому что именно через ошибки мы растем.
Этот канал - для тех, кто хочет развиваться в IT, учиться на реальном опыте и не боится быть искренним. Присоединяйся! 🐧✨
Сейчас, как никогда, популярно создавать айтишные Telegram-каналы, и я тоже решил попробовать свои силы. Мне действительно есть чем поделиться, и я думаю, что мой канал будет полезен многим. 💡
О себе:
Мне 25 лет, и я - главный разработчик озера данных в одном из топовых банков России. 🏦 За плечами - опыт работы в крупных IT-компаниях (телеком и банки), а в трудовой книжке есть записи: инженер КХД, ETL-разработчик, Data Engineer. 💻
За последний год я прошел около 30 собеседований, и многие из них подробно задокументировал и разобрал. 📝 Кроме того, я сам проводил собеседования для стажеров, был ментором на стажировках и помог десятку ребят попасть на проекты топовых банков РФ.
Я также занимаюсь менторством: обучаю SQL, Oracle, немного Python, помогаю готовиться к собеседованиям и делюсь лайфхаками из личного опыта. 📚 Еще у меня есть опыт подготовки студентов из ВШЭ и МГУ к экзаменам и выполнения лабораторных работ. 🎓
Несколько фактов обо мне:
• Учусь на работе. Даже будучи главным разработчиком, я продолжаю учиться и развиваться. 📖
• Неосознанно крутил опыт в резюме. Сделаю об этом пост. 🤫
• Играл (и иногда играю) в доту в рабочее время. Ну а кто не играл? 😅
Цели на будущее: хочу попробовать работать параллельно на двух работах и, возможно, на валютной удаленке из РФ. 🌍
Что ждет на канале:
Этот канал - это место, где я делюсь тем, что было бы полезно и интересно мне самому. Здесь будет много полезной информации: от базовых основ для новичков 🐣 до продвинутых лайфхаков и хардкорных инсайдов. 💥
Я буду прикреплять крутые пет-проекты, рекомендовать статьи, книги и бесплатные курсы, которые сам прошел и проверил на себе. 📂
Расскажу о своем пути в IT, поделюсь личным опытом и лайфхаками, которые помогли мне расти. 📈
Будет много информации с собесов: как составить резюме, которое заметят, какие вопросы задают на собесах, как решать задачки, торговаться за оффер и на что обращать внимание при выборе компании. 💼 Буду делиться своими кейсами прохождения собесов (привет реджектику) - от первых шагов до успешных офферов. 🎯
Но самое главное - этот канал будет правдивым и искренним. Да, я многое знаю, и на всех работах мною были довольны: меня ценили за результат, не хотели отпускать и перебивали офферы . Но я всегда помню, что мне еще очень многому нужно научиться. Поэтому я постоянно учусь, ошибаюсь, и (добавим пафоса) падаю и снова встаю. 💪
Я буду писать не только о своих успехах, но и о неудачах, банальных открытиях, провалах и даже конфликтах. Потому что именно через ошибки мы растем.
Этот канал - для тех, кто хочет развиваться в IT, учиться на реальном опыте и не боится быть искренним. Присоединяйся! 🐧✨
20.03.2025, 11:14
t.me/data_penguin/8
Os resultados da pesquisa são limitados a 100 mensagens.
Esses recursos estão disponíveis apenas para usuários premium.
Você precisa recarregar o saldo da sua conta para usá-los.
Cronologia de mensagens semelhante:
Data, mais novo primeiro
Mensagens semelhantes não encontradas
Mensagens
Encontre avatares semelhantes
Canais 0
Alta
Título | Assinantes | |
|---|---|---|
Nenhum resultado corresponde aos seus critérios de pesquisa
| ||