SQL и Анализ данных

AI Data Science Team — команда специалистов по анализу данных на базе искусственного интеллекта поможет вам выполнять стандартные задачи в 10 раз быстрее.

Вопрос с собеседования по ML: зачем делить на корень из d в attention? Разбор популярного вопроса на собеседованиях по машинному обучению: почему в attention скалярное произведение делят на корень из d. Показываем на реальных расчётах, как без этого softmax насыщается, а градиенты пропадают. Сохрани, чтобы не завалить на интервью.

One Day Offer: стань щитом для миллионов клиентов! 🔥 В департамент противодействия мошенничеству Сбера нужен аналитик данных в антифрод — чтобы разбирать тренды мошенничества, находить скрытые паттерны и превращать их в правила защиты. Готов к таким задачам — добро пожаловать на One Day Offer: отбор за один день, разбор реальных кейсов, быстрая обратная связь. 24 октября, онлайн, регистрация и подробности — здесь!

🧩 SQL-задача: опечатка, которую база не заметит

CREATE TABLE users (user_id INT PRIMARY KEY);
CREATE TABLE orders (order_id INT PRIMARY KEY, buyer_id INT);

INSERT INTO users VALUES (1), (2), (3);
INSERT INTO orders VALUES (101, 1);

SELECT user_id
FROM users
WHERE user_id IN (
    SELECT user_id FROM orders
);

Что вернёт запрос? Ошибку, только 1 или всех пользователей? 👇 Разбор Вернёт 1, 2, 3. В orders нет user_id, поэтому SQL находит колонку во внешнем запросе. Подзапрос становится коррелированным: для каждого пользователя он возвращает его собственный ID по одному разу на каждую строку orders. Пока в orders есть строки, условие истинно для каждого пользователя. Если таблица пуста, запрос не вернёт ничего. Правильный вариант:

SELECT u.user_id
FROM users AS u
WHERE u.user_id IN (
    SELECT o.buyer_id
    FROM orders AS o
);

💡 Указывайте алиасы таблиц: o.user_id вызвал бы ошибку и сразу выдал опечатку. #SQL

Как не дать проекту по переходу на российскую базу данных превратиться в долгострой и сожрать вашу прибыль? Ответ: увидеть миграцию вживую! 27 октября в Москве, в Кибердоме, пройдёт День СУБД 2026 от «Диасофт». В программе: 📍 Демо переноса схемы с MS SQL и Oracle без переписывания кода – на сцене, с реальной консолью 📍 Кейсы клиентов с цифрами и сроками 📍 Готовый чек-лист и методика оценки трудоёмкости миграции 📍 Личные консультации с архитекторами Digital Q.DataBase – без тикетов и SLA 📍 3 часа нетворкинга с теми, кто уже завершил переход Формат офлайн. Участие бесплатное, но количество мест ограничено. 📅 27 октября, 14:00–23:00 📍 Москва, Кибердом 🔗 Регистрация

🦀 SurrealDB заменяет RocksDB собственным движком на Rust. Команда выпустила SurrealKV 1.0 под лицензией Apache 2.0. В SurrealDB 4 он станет единственным движком постоянного хранения. В тестах разработчиков, где каждый коммит сохраняется на диск до подтверждения, SurrealKV обошёл RocksDB: ⚡ Точечное чтение в 7,95 раза ⚡ Обновление в 6,10 раза ⚡ Создание записей в 26,8 раза В основе ускорения: radix tree для данных в памяти, групповая запись коммитов в журнал и дешёвые операции чтения. Есть транзакции с изоляцией снимков, история версий и шифрование данных на диске. Цифры зависят от режима: без синхронного сохранения RocksDB быстрее на записи. Каждый результат получен за один прогон, а необычно большой разрыв на создании записей авторы пока не объяснили. https://surrealdb.com/blog/we-are-replacing-rocksdb-with-surrealkv-1-0

🔎 Конец программирования: создатель InfluxDB считает, что код скоро перестанут писать и читать люди Пол Дикс, основатель InfluxData и автор InfluxDB, опубликовал эссе «The end of programming». Его тезис: ручное написание кода и построчное ревью вымирают. Софт будут производить агенты, а люди будут проверять результат работы системы, в сам код почти не заглядывая. Главный аргумент Дикса связан с Bun 1.4. Рантайм переписали с Zig на Rust, это больше миллиона новых строк. Сделал это один разработчик, Джаред Самнер, вместе с предрелизной Fable 5 и почти безлимитным бюджетом на токены. Он собрал харнесс для параллельной работы агентов, и за 11 дней они сделали 6778 коммитов. По API это стоило бы около $165 тысяч. На возражение, что переписывать готовую программу легко, ведь старая версия служит эталоном, Дикс отвечает так: если есть система верификации и толковое направление, ИИ доводит до рабочего состояния очень сложный софт. Его собственные эксперименты на форке InfluxDB. Интеграцию с Apache Iceberg, где задействованы API, CLI, компактор, манифесты и S3, Fable собрала за 14 часов: Дикс только описал архитектуру, а дальше работали сабагенты с код-ревью. Репликацию данных с edge-узлов в центральный кластер модель сделала за 28 часов, сама развернула в AWS и чинила баги по логам и метрикам. Система крутится до сих пор. Обе фичи пока остаются прототипами, а держать агента в постоянном цикле улучшений Дикс не может себе позволить: по его оценке, это сотни тысяч долларов в месяц. По словам Дикса, в Anthropic и OpenAI разработчики уже выпускают десятки и сотни PR в неделю. Они строят системы, промпты и инструменты проверки и не читают каждую строку. Остальная индустрия придёт к этому примерно через год. К концу 2027 года интеллект уровня Fable должен стать достаточно дешёвым для работы на полный день, а железо вроде Cerebras даст в 10-100 раз больше токенов в секунду. При этом Дикс не обещает мгновенной революции. Из-за инерции организаций ручной код с построчным ревью во многих компаниях проживёт ещё лет десять. И вместе с полезным софтом нас ждёт море слопа. Самыми продуктивными станут те, кто управляет агентами, строит харнессы, фабрики софта и системы QA. Главными вопросами будут «что мы хотим выпустить?» и «что мы готовы поддерживать?». https://pauldix.com/the-end-of-programming

Трюк Карпаты сработал: локальная LLM на Mac M5 выдает 117 токенов в секунду Как open-source движок Uzu от Mirai обходит потолок пропускной способности памяти на Apple M5 и разгоняет Qwen3.5 9B с 22 до 117 токенов в секунду: квантизация, спекулятивный декодинг, Weaver и бенчмарк против llama.cpp и MLX. https://uproger.com/uzu-uskorenie-lokalnyh-llm-apple-m5/

🌍 SQL-задача: ближайшие точки с подвохом Карта размером 100 × 100 замкнута: переход вправо от x = 100 возвращает к x = 0. По вертикали действует то же правило.

CREATE TABLE points (
    id INT PRIMARY KEY,
    x INT,
    y INT
);

INSERT INTO points VALUES
(1,  1,  1),
(2, 99, 99),
(3, 50, 50),
(4, 52, 52);

Напишите запрос, который найдёт все пары точек с минимальным расстоянием по прямой с учётом переходов через границы. Условия: • точку нельзя сравнивать с собой; • пары (1, 2) и (2, 1) считаются одной; • при одинаковом минимуме выведите все пары; • результат: id1, id2, distance. Обычная формула расстояния без учёта границ даст неверный ответ 👀

SQL с подвохом: могут ли IS NULL и IS NOT NULL одновременно вернуть false? Что выведет PostgreSQL? SELECT ROW(1, NULL) IS NULL AS a, ROW(1, NULL) IS NOT NULL AS b, NOT (ROW(1, NULL) IS NULL) AS c; Назови значения a, b, c.

Как SQLite превращает числа в текст в 2 раза быстрее? Трюк с парами цифр Обычно число переводят в строку по одной цифре, деля на 10 снова и снова. SQLite делит на 100 и берёт готовую пару символов из строки со всеми комбинациями от 00 до 99. Делений вдвое меньше, а результат получается тот же. https://youtube.com/shorts/HIGIWINACL4?si=7b36rnwPk08g2QPi

В субботу, 17 октября, Москва станет точкой притяжения для всех специалистов в области RecSys 🔥 Конференция AI Driver & RecSys — главное событие года для тех, кто создаёт, исследует и развивает рекомендательные системы. 🔝 Весь день ведущие эксперты индустрии из крупнейших IT-компаний проведут на площадке Сбера, чтобы обсудить: — главные тренды и вызовы RecSys — реальные кейсы и новейшие исследования — передовые IT-решения для рекомендательных систем Вы сможете сами пообщаться с теми, кто создает рекомендации для миллионов пользователей. 📍Офис Сбер, Москва, Кутузовский проспект, 32. Участие бесплатное! Количество мест для очного участия ограничено – успейте оставить заявку по ссылке ⚡️

Жиз

📝 5 уровней ИИ-агентов: от промпта до продакшена Context, loop, Jev, harness и evals: разбираем пять слоёв, которые превращают промпт в надёжного ИИ-агента в продакшене, с примерами кода. Вокруг ИИ-агентов сейчас крутятся пять модных терминов: context engineering, loop engineering, Jev engineering, harness engineering и eval engineering. Кажется, что это конкурирующие подходы, но на деле это пять слоёв одной системы, и каждый отвечает на свой вопрос. Автор популярного гайда в X под ником Yarchi предлагает простую метафору: представьте, что вы наняли нового сотрудника. Модель это сам человек, а пять слоёв описывают всё, что его окружает: что лежит у него на столе, работает ли он по чек-листу или сам решает, что делать дальше, кто сортирует ему почту, в каком офисе он сидит и какой экзамен сдаёт каждый месяц. Разберём каждый слой: что это, как работает и как построить его своими руками. https://uproger.com/5-urovnej-ii-agentov-ot-prompta-do-prodakshena/

UPDATE — оператор обновления данных в MySQL 🗂️ Если в таблице нужно изменить значение в уже существующей строке, используют команду UPDATE. Она позволяет обновлять записи точечно, но важно правильно задать условие: без него изменения могут затронуть всю таблицу.

UPDATE products SET price = 50500 WHERE id = 1;

Этот запрос меняет значение price только у записи с id = 1. С помощью UPDATE можно изменить сразу несколько полей:

UPDATE products SET price = 78500, quantity = 3 WHERE id = 2;

Этот запрос обновляет параметры price и quantity у записи с id = 2. 💡 UPDATE используют, когда нужно: ➖ изменить значение в конкретной записи, ➖ обновить несколько полей за один запрос, ➖ выбрать строки по условию, ➖ массово изменить набор записей. 🔗 SQL — это база для работы с базами. Если хотите не просто понять одну команду, а уверенно собирать запросы и менять данные без ошибок, регистрируйтесь на бесплатный мини-курс «MySQL для новичков» от Академии Selectel ➡️ Программа состоит из коротких уроков, которые помогут пройти путь от установки и настройки СУБД до создания таблиц, управления пользователями и основных операций с данными. Реклама. АО "Селектел". erid:2W5zFHzH7Eh

🧠 SQL-задача с подвохом Есть таблица транзакций:

CREATE TABLE transactions (
    id      int PRIMARY KEY,
    user_id int,
    ts      timestamp,
    amount  int
);

Нужно найти пользователей, у которых баланс ни разу не становился отрицательным. Начальный баланс — 0. Но есть важное условие: все операции с одинаковым ts происходят одновременно, поэтому порядок строк внутри одного timestamp учитывать нельзя. Пример:

10:00  +100
11:00   -80
11:00   -30
11:00   +20
12:00   +50

В 11:00 изменение баланса должно считаться как:

-80 - 30 + 20 = -90

То есть баланс:

10:00 → 100
11:00 → 10
12:00 → 60

Наивный вариант:

SUM(amount) OVER (
    PARTITION BY user_id
    ORDER BY ts
)

может дать неправильную логику, если считать операции с одинаковым ts по отдельности. Задача: написать SQL-запрос, который сначала объединит операции одного пользователя с одинаковым timestamp, а затем проверит минимальный накопительный баланс.

Как облегчить работу ИТ-аналитика уже сейчас — без долгосрочных перестроек процессов? Обсудим на IT-analyst Meetup от Сбера! В программе — прикладные доклады: — Как эффективнее использовать возможности мозга — Какие навыки развивать аналитику и как выстроить план роста — SDD на практике: подводные камни внедрения и новые зоны ответственности аналитика 📆 29 сентября 📍 Офис Сбера (Кутузовский пр-т, 32) и трансляция онлайн Выбирайте удобный формат и регистрируйтесь по ссылке

🐧 Linux Cheat Sheet - шпаргалка по командам Linux Самая удобная шпаргалка по Linux и Bash на русском: теория простым языком (как устроены файлы, процессы, права, память, загрузка и сеть), команды терминала, права доступа, процессы, сеть, SSH, systemd, grep/sed/awk, Vim и готовые однострочники - с примерами. А для тех, кто идёт дальше, - продвинутый уровень: Bash для профи, LVM и RAID, трассировка и производительность, ядро, безопасность, контейнеры, восстановление системы и вопросы с собеседований. https://github.com/justxor/Linux-/

⚡️ SQL-задача с подвохом Что вернёт этот запрос в PostgreSQL?

CREATE TABLE payments (
    id     int,
    amount int
);

INSERT INTO payments VALUES
    (1, 100),
    (2, 100),
    (3, 200);

SELECT
    id,
    amount,
    SUM(amount) OVER (ORDER BY amount) AS total
FROM payments
ORDER BY id;

Многие ожидают:

1 | 100 | 100
2 | 100 | 200
3 | 200 | 400

Но результат будет другим: 1 | 100 | 200 2 | 100 | 200 3 | 200 | 400 По умолчанию PostgreSQL использует окно RANGE ... CURRENT ROW. Строки с одинаковым amount считаются равными соседями и попадают в окно вместе. Для построчного накопления нужно указать ROWS: SUM(amount) OVER ( ORDER BY amount, id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) #SQL #PostgreSQL #Database