Когда чуть подразгребу дела и пройду испыталку (летом) готов ради контента пройти 7 кругов ада (собесов) ради контента 😱
На какой грейд интересны собесы?
На какой грейд интересны собесы?
Anonymous Poll
39%
джун
65%
мидл
30%
синьор
2%
неинтересно
Коллеги, спасибо за прохождение опросов 😊 . Данные приняты к сведению, будем работать ✊
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝4👍1🔥1
Вчера наткнулся на интересную статью и решил поделиться с вами (украсть💅 ) .
Статья взята из блога Senior-а DE из Spotify https://luminousmen.com, рекомендую.
Статья взята из блога Senior-а DE из Spotify https://luminousmen.com, рекомендую.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁4👍1💅1
Ч.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 или архивирование, чтобы бороться с раздуванием и фрагментацией. Однако будьте осторожны — эти операции могут полностью заблокировать вашу базу данных.
🔥4👍2❤1
Ч.2.
Операция UPDATE
При 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
При 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 во многом зависит от вашего варианта использования и структуры вашей базы данных. Например, если вы имеете дело с большими объемами обновлений, вы можете рассмотреть альтернативные стратегии, такие как вставка новой строки и удаление старой, вместо выполнения тяжелого обновления, особенно если обновления рискуют фрагментировать таблицу или повлиять на несколько индексов.
👍5🔥1👏1
Задача
Есть две таблицы из одного поля. В левой таблице 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
#задача
🔥5👀3👍1
👍4🔥4❤1
Друзья, всем привет 👋. Врываемся в рабочую неделю! 🫠
Итак, давайте разберем результаты решения вот этой задачки.
Правильно ответили всего лишь 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 то есть нет соответствия. Это надо осознать
• 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-ми. Нам без разницы равно что-то друг другу или нет, мы просто в цикле пробегаемся по все строкам.
Что касается, нашей задачки
• inner join ничего не вернет ( 0 строк).
• left join вернет 4 строки (все из левой)
• right join вернет 10 строк (все из правой).
• full join 4 + 10 = 14 строк, все из левой + все из правой, а пересечений нет (null != null).
• cross join, перемножаем, 4*10=40 строк.
Если остались вопросы, смело задавайте!
#sql #база #jun
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥11❤3👍3
no_zapret_it_penguin.7z
1008.9 KB
Привет, подписчики!😎
Вдруг еще кто-то не знает как обходить замедление ютуба на пк без 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 апрельская шутка*
#полезные_инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍4❤1
Популярный вопрос с собеседований
data engineer/data analyst (lvl jun/mid)
*здесь база данных понимается не в общем смысле, а как БД под капотом у классического ПО и транзакционных приложений*
1. База данных (Database, DB) - это система для хранения и управления операционными данными, предназначенная для частых транзакций (добавление, изменение, удаление).
Назначение: Операционная обработка данных (OLTP).
Основные характеристики:
✔️ Оптимизирована для частых транзакций (добавление, изменение, удаление)
✔️ Текущие данные (актуальное состояние системы)
✔️ Нормализованная структура (минимум дублирования)
Примеры:
➖ PostgreSQL
➖ MySQL
➖ Oracle
Когда использовать?
➜ Когда нужна работа с актуальными данными в реальном времени (например, онлайн-платежи, заказы в интернет-магазине).
2. Хранилище данных (Data Warehouse, DWH) - это централизованное хранилище структурированных данных, оптимизированное для аналитики и отчетности. Оно собирает информацию из разных источников, очищает и преобразует её для удобного анализа.
Назначение: Аналитика и отчёты (OLAP).
Основные характеристики:
✔️ Структурированные данные (таблицы, схемы)
✔️ Оптимизировано для сложных аналитических запросов
✔️ Исторические данные (хранятся годами)
✔️ ETL-процессы (очистка и преобразование перед загрузкой)
✔️ Денормализованные схемы ("звезда", "снежинка")
Примеры:
➖ Snowflake
➖ Greenplum
➖ Oracle Exadata
Когда использовать?
➜ Когда нужна аналитика на структурированных данных (например, отчёты по продажам за 5 лет, BI-дашборды).
3. Озеро данных (Data Lake) - это хранилище сырых данных любого формата (структурированных, полуструктурированных, неструктурированных), без строгой схемы.
Назначение: Хранение сырых данных любого формата.
Основные характеристики:
✔️ Любые данные (структурированные, JSON, логи, видео, изображения)
✔️ Масштабируемость (Big Data: Hadoop, S3)
✔️ Используется для ML, AI и глубокого анализа, архивации больших данных на дешевом железе
Примеры:
➖ AWS S3 + Athena
➖ Hadoop HDFS
➖ Yandex Object Storage
Когда использовать?
➜ Когда нужно хранить разнородные данные для последующей обработки (например, логи сервера, данные IoT-устройств, архивы).
Еще раз 😁
🔹 Ключевые отличия 🔹
📌 База данных (DB)
▪️ Тип данных: Структурированные
▪️ Оптимизация: OLTP (транзакции)
▪️ Пример: Банковские транзакции
📌 Хранилище (DWH)
▪️ Тип данных: Структурированные
▪️ Оптимизация: OLAP (аналитика)
▪️ Пример: Анализ продаж за 5 лет
📌 Озеро данных (Data Lake)
▪️ Тип данных: Любые (структур./неструктур.)
▪️ Оптимизация: Хранение + гибкий анализ
▪️ Пример: Хранение логов сервера
Современные системы часто комбинируют подходы, например:
➖ Data Lakehouse (озеро + хранилище) – как в Delta Lake или Databricks.
➖ Гибридные DWH (поддержка полуструктурированных данных, как в Snowflake).
#Вопросы_с_собесов #архитектура
data engineer/data analyst (lvl jun/mid)
Что такое хранилище данных? Чем хранилище отличается от обычной Базы данных? Что такое озеро данных?
*здесь база данных понимается не в общем смысле, а как БД под капотом у классического ПО и транзакционных приложений*
1. База данных (Database, DB) - это система для хранения и управления операционными данными, предназначенная для частых транзакций (добавление, изменение, удаление).
Назначение: Операционная обработка данных (OLTP).
Основные характеристики:
✔️ Оптимизирована для частых транзакций (добавление, изменение, удаление)
✔️ Текущие данные (актуальное состояние системы)
✔️ Нормализованная структура (минимум дублирования)
Примеры:
Когда использовать?
➜ Когда нужна работа с актуальными данными в реальном времени (например, онлайн-платежи, заказы в интернет-магазине).
2. Хранилище данных (Data Warehouse, DWH) - это централизованное хранилище структурированных данных, оптимизированное для аналитики и отчетности. Оно собирает информацию из разных источников, очищает и преобразует её для удобного анализа.
Назначение: Аналитика и отчёты (OLAP).
Основные характеристики:
✔️ Структурированные данные (таблицы, схемы)
✔️ Оптимизировано для сложных аналитических запросов
✔️ Исторические данные (хранятся годами)
✔️ ETL-процессы (очистка и преобразование перед загрузкой)
✔️ Денормализованные схемы ("звезда", "снежинка")
Примеры:
Когда использовать?
➜ Когда нужна аналитика на структурированных данных (например, отчёты по продажам за 5 лет, BI-дашборды).
3. Озеро данных (Data Lake) - это хранилище сырых данных любого формата (структурированных, полуструктурированных, неструктурированных), без строгой схемы.
Назначение: Хранение сырых данных любого формата.
Основные характеристики:
✔️ Любые данные (структурированные, JSON, логи, видео, изображения)
✔️ Масштабируемость (Big Data: Hadoop, S3)
✔️ Используется для ML, AI и глубокого анализа, архивации больших данных на дешевом железе
Примеры:
Когда использовать?
➜ Когда нужно хранить разнородные данные для последующей обработки (например, логи сервера, данные IoT-устройств, архивы).
Еще раз 😁
🔹 Ключевые отличия 🔹
📌 База данных (DB)
▪️ Тип данных: Структурированные
▪️ Оптимизация: OLTP (транзакции)
▪️ Пример: Банковские транзакции
📌 Хранилище (DWH)
▪️ Тип данных: Структурированные
▪️ Оптимизация: OLAP (аналитика)
▪️ Пример: Анализ продаж за 5 лет
📌 Озеро данных (Data Lake)
▪️ Тип данных: Любые (структур./неструктур.)
▪️ Оптимизация: Хранение + гибкий анализ
▪️ Пример: Хранение логов сервера
Современные системы часто комбинируют подходы, например:
#Вопросы_с_собесов #архитектура
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥4⚡2
Всем привет!🫡
Читал книгу Том Кайт "Oracle для профессионалов" (классика) и там был интересный момент про стандарты SQL:
Странно, вроде бы стандарты, а даже большие гиганты СУБД не полностью их поддерживают. Решил чуть разобраться в стандартизации и сделал для вас ( и для себя) небольшую выжимку. Если такое интересно, жду реакции😎
Читал книгу Том Кайт "Oracle для профессионалов" (классика) и там был интересный момент про стандарты SQL:
Ни один поставщик не подтверждает сертификатом "совместимость" своих баз
данных со стандартом SQL99 на основном или расширенном уровне. Более того,
я не знаю ни одного поставщика, который заявлял бы, что его продукт полностью
совместим со стандартом на любом из упомянутых уровней.
Странно, вроде бы стандарты, а даже большие гиганты СУБД не полностью их поддерживают. Решил чуть разобраться в стандартизации и сделал для вас ( и для себя) небольшую выжимку. Если такое интересно, жду реакции
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥2🤔1
Стандартизация 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?
Современные стандарты SQL развиваются в сторону гибридных моделей данных (JSON, графы, векторы для AI) и глубокой аналитики – в будущем появятся встроенные ML-функции и улучшенная обработка временных рядов. Упор делается на безопасность (динамическое маскирование, аудит) и производительность (оптимизация JOIN, распределённые транзакции).
Постепенно стираются границы между SQL и NoSQL: новые версии стандарта добавляют поддержку полуструктурированных данных. Главный тренд – универсальность: один язык для OLTP, OLAP и даже машинного обучения.
Ни одна СУБД не поддерживает стандарты SQL полностью — все они используют собственные расширения и модификации.
Зачем тогда нужны стандарты?
Стандарты SQL служат универсальным ориентиром, задающим общую логику языка и основные принципы работы с данными. Хотя ни одна СУБД не реализует стандарт полностью, именно благодаря ему разные системы сохраняют базовую совместимость - например, все понимают запросы SELECT, WHERE или JOIN. Это позволяет разработчикам легче осваивать новые СУБД и переносить знания между проектами.
Кроме того, стандарт выступает "дорожной картой" развития - новые функции (вроде работы с JSON или оконных функций) сначала появляются в спецификации, а затем постепенно внедряются производителями СУБД. Без единого стандарта различия между диалектами были бы гораздо более радикальными, что затруднило бы работу с базами данных.
#sql
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥3🥴1🤓1
🔹Задача на схлопывание строк🔹
Есть данные привязки абонентов к базовым станциям оператора, необходимо схлопнуть строки, если дата окончания привязки абонента = дате начала следующей.
Для упрощения будем считать так:
📌Есть таблица, в которой три колонки - номер телефона, дата начала действия строки, дата окончания.
Если дата окончания текущей строки одного номера телефона = дате начала действия следующей строки этого же номера телефон, то мы должны схлопнуть эти строки в одну.
Пример:
Должны схлопнуть в одну строку:
А строки
Должны схлопнуть в:
(обратите внимание как 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 #задача
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤2🔥1
Разбор пятничной задачки.
Данные задачки решаются с помощью оконок и флагов (меток)🤓 ❗️
Главное не запутаться.
Предлагаю свое решение:
▪️Сначала проставляем флаги по нашей придуманной логике.
▪️Отрезаем лишние строки при помощи флагов.
▪️В последнем шаге правильно проставляем start_t и end_t.
В комментариях было выложено очень крутое правильное решение. Здесь классно используется накопительная сумма (оконка sum) и group by с min и max 👍
Решений таких задач можно много придумать. Полный разбор текстом не вижу смысла делать😄 💅
Все скрипты создания таблицы и наполнения данными есть. Решения тоже есть. Кому интересно, посидите покрутите, будет точно полезно👍 На собеседование на мидла подобную задачу могут дать💯
Если у кого еще появятся идеи, обязательно делитесь. Будем обсуждать😊
#sql #задача
Данные задачки решаются с помощью оконок и флагов (меток)
Главное не запутаться.
Предлагаю свое решение:
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
Решений таких задач можно много придумать. Полный разбор текстом не вижу смысла делать
Все скрипты создания таблицы и наполнения данными есть. Решения тоже есть. Кому интересно, посидите покрутите, будет точно полезно👍 На собеседование на мидла подобную задачу могут дать
Если у кого еще появятся идеи, обязательно делитесь. Будем обсуждать
#sql #задача
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥2✍1🫡1
Привет, подписчики!😎
За 3,5 года работы в it у меня скопилось не мало интересной полезной информации.
Буду делиться ею с вами.
В комменты прикреплю две прикольных презенташки с классным дизайном:
1️⃣ - BigData 2021 (да, чуть старовата)
2️⃣ - Linux
Как по мне такое интересно полистать, сохранить и иногда возвращаться к основам.
Дайте обратную связи по презенташкам и интересно ли вам такое?
#полезная_инфа
За 3,5 года работы в it у меня скопилось не мало интересной полезной информации.
Буду делиться ею с вами.
В комменты прикреплю две прикольных презенташки с классным дизайном:
Как по мне такое интересно полистать, сохранить и иногда возвращаться к основам.
Дайте обратную связи по презенташкам и интересно ли вам такое?
#полезная_инфа
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤5🤝4🔥2
🔹Задача🔹
Задача была дана на собеседовании в одном из банков. Собеседование было на middle+.
📌Имеется таблица остатков rest_history.
▫️id_dog - id договора
▫️dt - дата изменения остатка
▫️balance - остаток на конце дня dt (0 или положительный)
Условия:
▫️ в таблице для каждого договора первой строкой является строка с ненулевым остатком.
Необходимо написать SQL-запрос:
▫️для каждого договора вычислить периоды, когда он имел ненулевой остаток;
▫️период закрывается датой dt-1 строки с нулевым остатком;
▫️eсли ненулевой остаток остается, то период закрывается датой 31.12.2999.
Тестовые данные (см. скрин):
Результат после обработки скриптом:
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 #задача
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2🔥1
Буллинг от руководителя
Осень 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 🐧
#трустори
5😢10👍9❤2😱2✍1🔥1🤬1😭1
Привет, подписчики!😎
Выкладываю решения по пятничной задачки.
Данные:
1)
2)
3)
Позапускайте решения, сравните разные реализации 👍
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 🐧
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥6👍4✍1🥰1🤬1
Друзья, я получил обратную связь, что даю сложные задачки🫠
Я с этим согласен 🤝👍
Скоро я сделаю краткий обзор собеседования с Газпромбанком✍️
После собеса мне прилетела положительная обратная связь и оффер 325к.💰
На одном из этапов мне давали легкие задачки (скорее загадки). По ним сделаю пост, вам должно понравиться 😁
Я с этим согласен 🤝👍
Скоро я сделаю краткий обзор собеседования с Газпромбанком
После собеса мне прилетела положительная обратная связь и оффер 325к.
На одном из этапов мне давали легкие задачки (скорее загадки). По ним сделаю пост, вам должно понравиться 😁
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍4✍3🤬1👌1
Стало интересно🤔 , какой для вас идеальный вариант работы? Даже если вы еще только вкатываетесь, то к чему вы стремитесь?
Anonymous Poll
35%
Работать в РФ на полной удаленке
20%
Гибрид в РФ - 2 дня в неделю офис, 3 удаленка
4%
Работать в РФ в комфортном офисе
11%
Работать из РФ на валютной удаленке
9%
Совмещать две работы. Жестко пахать (от 12 часов в день) и много зарабатывать
18%
Жить и работать за границей, получать в валюте
4%
Свой вариант
1🔥4👍3😱1🤬1
Вакансия: Старший ETL разработчик
Компания: IT_One (Проект Газпромбанка)
Предполагаемая вилка: 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 🐧
#Собес
Компания: IT_One (Проект Газпромбанка)
Предполагаемая вилка: 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 🐧
#Собес
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥8🌚7👍4🤣2🤬1