Работаешь дата инженером не первый год, а PostgreSQL всё ещё может удивить 😅 Недавно столкнулся с ситуацией, которая, казалось бы, должна быть довольно распространённой. Нужно переименовать таблицу через ALTER TABLE ... RENAME, но ты не OWNER этой таблицы. Права на переименования раздать тоже нельзя Вроде штука достаточно распространненая должна быть, но раньше я как-то не сталкивался с такой задачей. В итоге решение оказалось довольно интересным — SECURITY DEFINER. Можно создать процедуру, которая будет выполняться с правами своего владельца, и дать пользователю доступ только к её вызову.

CREATE PROCEDURE ...
SECURITY DEFINER

В результате пользователь может выполнить нужное переименование, не получая права OWNER на сами таблицы. Я в такие моменты всегда задаюсь вопросом: "А точно ли я все эти годы чем-то занимаюсь, если мне еще не встречались такие вещи?)" А у вас были подобные моменты, когда внезапно узнаёшь что-то новое в технологии, с которой давно работаешь?

OpenAI побили еще сотню стартапов "AI аналитики" Выпустила Data agent в ChatGPT Work – плагин, который подключается к корпоративным данным, сам пишет SQL, ищет, что изменилось, и собирает интерактивные дашборды, которыми можно поделиться. Вопрос задаёшь словами, код не нужен. Что внутри: – источники: Snowflake, BigQuery, Databricks, Redshift, ClickHouse, MongoDB, Datadog, плюс Google Drive и SharePoint – BI: Tableau, Power BI, Sigma, ThoughtSpot, Omni, Oracle BI – семантический слой: агент берёт термины, метрики и формулы из dbt, Databricks Genie, Snowflake Horizon, GitHub и самих дашбордов – чтобы «выручка» считалась так, как у вас принято, а не как модели показалось – права: запросы идут под учёткой пользователя со всеми ограничениями по таблицам, строкам и колонкам – после анализа – рекомендации, кому из коллег это показать, и выгрузка в Slack или почту Внутри OpenAI это уже стандарт: почти вся продуктовая команда и две трети GTM сидят в этом агенте. Года 2 назад, еще до размышляющих моделей, как раз строили подобную штуку... Теперь это из коробки доступно. Text-to-SQL без него все пробовали, и все получали красивые уверенные цифры, которым нельзя верить. Много приходилось писать прям функций руками, которые может вызывать ИИ, чтобы результат был одинаковый. Теперь думаю с такой клиентской базой и такими провайдерами это вопрос решенный https://openai.com/index/put-data-to-work/

Небольшой постик для тех кому интересно, что сейчас спрашивают на позицию дата инженера Во первых это, конечно, sql и python и как правило (в процентах 80%) будет лайв кодинг. Иногда задачку на собеседовании можно решить не на питоне, а на другом языке Задачки, как правило, не супер сложные и объемные, но в условиях собеседования и ограниченного времени можно не справится По питону задачка например сделать что-то с массивом или словарем. Например вывести первое повторяющееся значение в массиве По SQL задачка например найти сотрудника со второй по величине зарплатой Задачки как правило действительно не очень сложные и можно их натренировать Еще вопросы которые присутствуют почти всегда это вопросы про БД. Например рассказать про индексы или партиции. Часто эти вопросы практические - например рассказать про выбор поля партиции, но часто и больше в теорию - например рассказать про того как джойны могут происходить под капотом И на самом деле эти 3 вещи (бд, sql, python) дают большую часть того что вас спросят (по крайне мере у меня было так) Конечно, спрашивают еще и другие вещи. И про некоторые эти вещи нужно подробно рассказать, но например по Airflow большая часть услышанных мной вопросов было в формате «Расскажи какие операторы знаешь», то есть если работаешь с этим инструментом, то вопросов не возникнет

А чем я вообще занимаюсь? Хоть у меня и нет синдрома самозванца, но я иногда смотрю на свою работу со стороны и такой: «Да чем ты вообще занимаешься целый день?! Твоя задача всего лишь переложить таблички с одного места на другое и потом соеденить их. Что в этом сложного» 🤔 И на словах оно в целом так и есть. И вроде бы в работе с табличками особо ничего сложного нет, но потом работаешь и … Была у меня тут простая на первый взгляд задача - заинсертить (положить) данные в таблицу) Ну то есть что-то типо такого запроса:

insert table1
select * from table2
where id in (ну и тут айдишники отобранные по условию)

Опустим часть о том как именно достать эти айдишники (это тоже не всегда просто, но сейчас не об этом) - это делается с помощью запроса с джойнами у условиями Казалось бы задача решена - просто подставить наше условие в скобки в скрипте выше, но так не всегда работает, так как запрос тяжелый. Не понятно когда отработает, а там таймаут, ресурсов много хочет и тд Пришлось не много помаяться с этим 🤔 Короче в итоге я создал промежуточную таблицу, куда заинсертил нужные мне айдишники. Но и заинсертить было не так просто: сделал ДАГ который берет данные за один день, дальше это один день еще резался на чанки, дальше были вычисления и инсерт 🎉 И вот маленькая задача (даже задачей это сложно назвать), превратилась в целый квест А у вас бывают мысли о том что вы на работе занимаетесь не пойми чем?

MetaORM — когда устал от ORM настолько, что написал свою 16 лет в разработке, 10 из них ежедневно с базами данных, и человек спокойно пишет, что путается в уровнях изоляции, не выучил расшифровку ACID и простой запрос с JOIN осиливает только через Гугл. За 7 лет коммерческой разработки сложный SQL-запрос не понадобился ни разу, а больше половины возможностей популярных ORM так и остались нетронутыми. Один и тот же кусок кода перекочёвывал из проекта в проект, пока не превратился в отдельный пакет. Внутри декларативные фильтры, генераторы стандартных CRUD-операций и тонкий слой транзакций через contextvars. Ни unit-of-work, ни identity map, ни ленивых прокси, ни магического отслеживания состояния объектов. Остаётся только то, с чем backend сталкивается каждый день, взять запись по идентификатору, отфильтровать список, обновить пару полей, создать сущность внутри транзакции. Посмотрим, что остаётся от ORM, когда убираешь из неё всё, чем не пользуешься.

Как не надо проходить собеседования Значит где-то год назад: Захотел я поменять свое место работы (но не прям сильно захотел), обновил резюме и сижу жду пока меня крутого дата инженера куда-то позовут. Если кто-то будет приходить то буду проходить собесы, а если нет, то мне и тут хорошо И в целом ко мне приходили и звали на собес, но понятно что это происходило реже по сравнению с тем что если бы я сам откликался на вакансии И тут то и возникает главная проблема - умение проходить собеседование это все равно навык, он, конечно, имеет определенную корреляцию с тем насколько ты крутой спец, но все равно далеко не полностью Например на собесах на DE обычно дают sql задачку и часто какую-то простенькую (по крайне мере одну из первых) на оконные функции (пример в коментах) Я оконки знаю и умею с ними работать, но например за последние пару месяцев я их вообще не касался, а работал с другими вещами и в итоге простейшая задача, которая должна занять у меня меньше 5 минут, занимает минут 15 и еще какую-то глупую ошибку сделаю И как же с этим бороться? Ну если мы говорим именно про часть лайв кодига (а помимо sql часто еще и питон дают), то тут есть 2 варианта: 1) Заходить на специальные ресурсы для решения задач по питону и sql (тут писал как меня заблокировали на одном из таких). Ну это ведь это получается, что мы готовимся к собесу, а готовится к собесу это айтой (автор выражает лишь собственное безоговорочно правильное мнение) 2)Посещать больше собесов. И в итоге мы получаем, что к предстоящим собесам готовимся на предыдущих Если мы выбираем второй вариант (а мы выбираем второй вариант), то получаем, что чем больше собесов тем лучше. И поэтому мы не ждем рыбы у моря (ну или как там говорится), а сами откликаемся на вакансии и готовимся к собесам на собесах

Иммутабельная денормализация Изучение баз данных всегда сопровождается понятием нормализации, а конкретно первыми тремя формами, которые задают нам ограничения, помогающие правильно разложить все по таблицам. И это действительно база, без которой нормально работать не получится. Но есть, как обычно, нюансы. В реальных проектах выясняется, что нормализованные данные сложно соединять и выбирать. При глубоком уровне зависимостей, чтобы добраться до внешней сущности, нужно либо соединять 5 таблиц, либо делать 5 запросов. Пример из Хекслета. У нас есть программа обучения, которая состоит из модулей, в которые входят темы которые состоят из уроков, которые состоят из юнитов (теория, практика, тесты). На это все накручено много логики по прогрессу и отображению. В такой структуре, вопросы типа "какой урок следующий по порядку?" заставляют поломать голову. В таких ситуациях мы начинаем денормализацию данных. В основном она сводится к добавлению внешних ключей на косвенно связанные сущности, например, урок связан с программой обучения через модуль. Здесь мы добавляем ключ на программу прямо из урока, что позволяет выполнять запросы на уроки одной программы без необходимости соединять таблицы. В принципе это довольно базовая концепция с которой знакомы большинство разработчиков, но дальше начинается самое интересное. Как только мы делаем денормализацию, то сразу упираемся в необходимость синхронизировать данные. Если поменялось в одном месте, надо не забыть поменять и в другом месте. Это цена денормализации и ее надо платить. > Кстати есть такой концепт как синхронизирующие триггеры, которые вешают только для того, чтобы синхронизировать подобные данные. Когда-то я его активно использовал, но сейчас не стал бы Но есть и альтернативный подход, который иногда работает лучше. Вместо того, чтобы синхронизировать денормализованные данные, мы можем пересмотреть саму систему и сделать данные иммутабельными (неизменяемыми), чтобы их не нужно было синхронизировать. Например в том же примере с уроками, мы сделали так, что урок принадлежит одной программе и не может перемещаться между программами. А это значит, что мы можем записать в урок все внешние ключи, которые никогда не поменяются. В таком случае цена денормализации это занятое место ключами, чем обычно можно пренебречь. А что касается бизнес-логики? Да, такой подход работает не всегда, но, как показала практика, его можно использовать намного чаще чем кажется. Например в нашем случае это даже наоборот хорошо, иначе получается ситуация, что при переносе урока нужно переносить прогресс, что значительно усложняет логику и создает странное впечатление, когда в середине программы вдруг появляются пройденные уроки. При этом сама процедура довольно редкая, поэтому если кому-то придется пройти два раза один и тот же урок (перенос в нашем случае это копирование), то ничего страшного не случается. Но есть места где без синхронизации данных не обойтись никак. В основном это касается статусов, они могут меняться и за ними нужно следить. Telegram | YouTube | AI Клуб

💉 Что такое SQL Injection? SQL Injection — одна из самых известных веб-уязвимостей, о которой слышал практически каждый, кто начинает изучать пентест. Но что она означает на самом деле?

📌 SQL Injection (SQLi) — это уязвимость, которая возникает, когда приложение неправильно обрабатывает пользовательский ввод при обращении к базе данных.

Проще говоря, злоумышленник может повлиять на SQL-запрос, который приложение отправляет в базу данных. 🧠 Представьте обычную форму входа на сайте. Вы вводите: — логин — пароль После чего приложение обращается к базе данных и проверяет, существует ли такой пользователь. Если разработчик не проверяет входные данные должным образом, появляется риск SQL Injection. 💀 Почему это опасно? В зависимости от приложения и уровня защиты последствия могут быть разными: — получение данных пользователей; — просмотр информации из базы данных; — обход аутентификации; — изменение или удаление данных. Именно поэтому SQL Injection уже много лет входит в список самых опасных веб-уязвимостей. 🛡 Как защититься? Основные рекомендации: — использовать параметризованные запросы (Prepared Statements); — проверять и фильтровать пользовательский ввод; — не собирать SQL-запросы простой конкатенацией строк; — использовать принцип минимальных привилегий для доступа к базе данных. 📌 Несмотря на появление современных фреймворков и ORM, SQL Injection до сих пор регулярно встречается в реальных проектах. Именно поэтому понимание принципов её возникновения остаётся одним из базовых навыков для любого специалиста по веб-безопасности. #web #owasp #sqli #injection