🔥 Важно знать: избегай SELECT * для оптимизации запросов!

Использование SELECT * может привести к излишней загрузке данных и снижению производительности. Вместо этого, укажите только необходимые столбцы для выборки. Это не только упростит обработку данных, но и позволит использовать индексы более эффективно.

-- Вместо этого:
SELECT * FROM orders WHERE customer_id = 123;
-- Используйте явный выбор столбцов:
SELECT order_id, order_date, total_amount
FROM orders
WHERE customer_id = 123;
-- Дополнительно можно добавить индексы если это необходимо:
CREATE INDEX idx_customer_id ON orders(customer_id);

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

❤️ ML-митап от команды MAGNIT TECH

Эксперты из ML/AI Хаба «Магнита» зовут на митап, чтобы поделиться реальным опытом применения машинного обучения в бизнес-процессах.

19.02 | Москва | Офлайн + онлайн

🎯 Обсудим, что остается "под капотом" ML-решений в крупнейшем ретейле. Без лишних формальностей: в программе диджей и нетворкинг-сессия с экспертами 👇

Сбор гостей с 18:00
DJ • Welcome
🟪Магнит и AI: как мы строим ML и куда движемся (Алексей Четыркин, MAGNIT TECH, Chief of AI/ML)
🟪Доступность товара: от фильтрующих деревьев до CUSUM и GEE-тестов (Ян Пиле, MAGNIT TECH, Head of OSA)
🟪Опять AI, да сколько можно? Только практические кейсы без воды (Александр Толмачев, ex-Ozon, CDO и председатель комитета данных)
🟪Нетворкинг с ML-лидами и инженерами
DJ • F&B • Good vibes

Модератор: Максим Покусенко, MAGNIT TECH, Head of ML (Logistics & R&D)

Занимайте место: офлайн — в московском офисе MAGNIT TECH (м. Белорусская), или получите ссылку на онлайн трансляцию после регистрации.

🟥Участие бесплатное, количество мест офлайн ограничено. До встречи 19 февраля! 🟥

🔥Каждый тензор в движении: Illustrated Transformer 3D

Погрузитесь в LLaMA как никогда раньше:

⏺️ Каждый тензор и операция — в движении
⏺️ Кликайте на любой компонент и смотрите точные строки кода, которые его запускают

Новый способ учить и изучать LLM.

➡️ Попробовать можно по ссылке.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ 7 шаблонов для построения Multi-Agent систем

Если вы работаете с LLM-агентами — сохраните эту шпаргалку.

👏 Эти паттерны — фундамент для создания масштабируемых и надёжных multi-agent систем.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 OpenAI поглотили OpenClaw (🦞) и переманили к себе создателя проекта

Питер Штейнберг возглавит в OpenAI разработку следующего поколения агентов. Сэм Альтман назвал его «гением с множеством потрясающих идей» и сказал, что очень скоро эти идеи будут лежать в основе продуктов компании.

Что касается OpenClaw: проект не закрывается и остается опенсорсным. OpenAI обязываются поддерживать и развивать его. Стратегически для компании это имеет смысл, так что в этом в случае в обещания можно верить.

Кстати, сейчас OpenClaw – самый быстрорастущий репозиторий на GitHub в истории в смысле набора звезд. На пике у них было 34к звезд за два дня, и всего за 60 дней после запуска репа выросла с ~9к до почти 200к. Для сравнения, Kubernetes шел к 100K звезд около трех лет.

У Anthropic были все шансы купить OpenClaw первыми (особенно учитывая исходное название проекта ClawdBot), но они только закидали автора претензиями по поводу торгового знака. OpenAI в этот раз думали быстрее и успели отхватить самый лакомый кусочек, – с чем мы их и поздравляем.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

👋 Восстания машин можно не бояться, достаточно уехать на север

Что думаем?

❤️ — НЕ, НУ ОН СТАРАЛСЯ
🗿 — ЖАЛЬ ЭТОГО ДОБРЯКА

🚩 Куй клиента, пока горячо!

➡️ SQL: ЛОВУШКА ДУБЛЕЙ И ДАТ

Иногда самая коварная задача - найти “покупали 3 дня подряд”. Профи часто делают self-join на даты, но он ломается на дубликатах, таймзонах и нескольких покупках в день.

Подвох: нужно считать не покупки, а уникальные дни, и правильно собрать последовательности без дыр. Решение выглядит просто, но без оконных функций легко ошибиться.

-- Задача:
-- Найти пользователей, которые совершали покупку 3 календарных дня подряд (минимум).
-- Условия:
-- 1) В один день может быть много покупок - считаем день один раз.
-- 2) Нужны именно подряд идущие дни без пропусков.
-- 3) Вернуть user_id и начало/конец самой длинной серии.

WITH days AS (
SELECT DISTINCT
user_id,
DATE(created_at) AS d
FROM orders
),
grp AS (
SELECT
user_id,
d,
-- трюк: для подряд идущих дат разность (дата - номер) постоянна
DATEADD(day, -ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY d), d) AS g
FROM days
),
streaks AS (
SELECT
user_id,
MIN(d) AS streak_start,
MAX(d) AS streak_end,
COUNT(*) AS streak_len
FROM grp
GROUP BY user_id, g
)
SELECT user_id, streak_start, streak_end, streak_len
FROM streaks
WHERE streak_len >= 3
ORDER BY streak_len DESC;

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 The Epstein Network

Нашли визуализацию связей людей в файлах Эпштейна: можно изучить 25 тысяч документов и посмотреть, кто с кем вместе упоминался.

В график, очевидно, не вошла последняя пачка из миллионов файлов — однако залипнуть все равно интересно. И есть ещё исходный код на гитхабе!

➡️ https://epstein-doc-explorer-1.onrender.com/

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Вышел MySQL 8.4.8 (LTS) - что нового

Доступен релиз MySQL 8.4.8 - это ветка Long-Term Support, то есть лучший выбор для продакшена: стабильность, долгий цикл поддержки и предсказуемые обновления.

Ключевые улучшения:

➡️ InnoDB Redo Logging
⏺️ сообщения об ошибках стали информативнее
⏺️ теперь показывают текущий LSN и детали по redo log capacity
⏺️ проще диагностировать проблемы с redo log и производительностью

➡️ OpenSSL обновили до 3.0.18

⏺️ важное обновление для безопасности и совместимости

➡️Исправления багов и стабильность

⏺️ закрыли race conditions в InnoDB
⏺️ починили проблемы с очисткой binary logs (binlog purging)
⏺️ в целом релиз направлен на надёжность и производительность

Если ты сидишь на MySQL в проде - LTS 8.4.x выглядит как правильный путь обновления.

https://dev.mysql.com/downloads/mysql/

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ Timescale выпустил pg-aiguide: практический гайд по ИИ в PostgreSQL

Timescale опубликовал открытый репозиторий pg-aiguide - это собрание лучших практик, примеров и шаблонов по работе с ИИ поверх PostgreSQL (в том числе TimescaleDB).

Что внутри:

⏺️ примеры интеграции LLM и AI-функций с БД
⏺️ готовые SQL-рецепты и расширения
⏺️ семантический поиск и анализ данных
⏺️ шаблоны, которые можно сразу использовать в проде

Это не теория, а набор готовых подходов для реальных проектов.

➡️ https://github.com/timescale/pg-aiguide

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ Локальная панель для Cloudflare Workers

Localflare — это инструмент для разработки, который упрощает взаимодействие с вашими ресурсами Cloudflare, такими как D1 базы данных, KV пространства и R2 бакеты. Он предлагает интуитивно понятный интерфейс для визуализации и управления данными в процессе разработки.

Основные моменты:

⏺️ Полнофункциональный SQL-редактор для D1 баз данных
⏺️ Удобный браузер для работы с KV парами
⏺️ Менеджер файлов для R2 бакетов
⏺️Инспектор очередей для тестирования сообщений
⏺️ Работает с любыми фреймворками без настройки

➡️ GitHub: https://github.com/rohanprasadofficial/localflare

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ ШПАРГАЛКА: Как правильно поднимать БД перед проектом

Главная ошибка новичков - “у всех база разная”.
В итоге миграции ломаются, схема плывёт, на CI одно, у тебя другое, в проде третье.

Правильный старт всегда одинаковый:

⏺️ Поднимай БД через Docker - чтобы у всей команды окружение было идентичным
⏺️ Все параметры (пароль, порт, имя БД) храни в .env
⏺️ Схему меняй ТОЛЬКО через миграции (Flyway/Liquibase/EF/Alembic)
⏺️ Добавь healthcheck - сервис не должен стартовать раньше БД
⏺️ Сделай команды backup/restore - пригодится в любой момент

Так ты гарантируешь:

⏺️ у всех одна и та же база
⏺️ быстрый старт проекта за 3 минуты
⏺️ деплой без сюрпризов

1) Создай .env
cat > .env << 'EOF'
POSTGRES_DB=app
POSTGRES_USER=app
POSTGRES_PASSWORD=app123
POSTGRES_PORT=5432
EOF

2) docker-compose.yml для Postgres + healthcheck
cat > docker-compose.yml << 'EOF'
services:
  postgres:
    image: postgres:16
    container_name: app-postgres
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - "${POSTGRES_PORT}:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 3s
      retries: 20

volumes:
  pgdata:
EOF

3) Запуск
docker compose up -d

4) Проверка
docker compose ps

5) Backup
docker exec -t app-postgres pg_dump -U app app > backup.sql

6) Restore
cat backup.sql | docker exec -i app-postgres psql -U app -d app

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ Как не убить базу большими таблицами в SQL - фильтруй и агрегируй как можно раньше

Главная ошибка при работе с большими таблицами - делать SELECT * и потом надеяться, что "оно как-нибудь".

На больших объёмах это превращается в долгие запросы, высокую нагрузку и таймауты.

Правильный подход другой: всегда сначала сузь выборку, отрежь лишние строки по времени или по ключу, выбери только нужные колонки и агрегируй как можно раньше.

Практическое правило: если запрос возвращает миллионы строк - ты почти наверняка решаешь задачу неправильно. В 90% случаев тебе нужна витрина: GROUP BY, window-функции, или отдельная агрегированная таблица. А чтобы база не страдала, добавляй индексы под фильтры и под JOIN-ключи, и проверяй план выполнения через EXPLAIN.

 ПЛОХО: тащим весь объём и только потом думаем
SELECT *
FROM events
WHERE created_at >= NOW() - INTERVAL '90 days';

-- ХОРОШО: сразу сужаем, берем нужные колонки, считаем агрегаты
SELECT
  user_id,
  COUNT(*) AS events_7d,
  MAX(created_at) AS last_event_at
FROM events
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY user_id;

-- Индекс под фильтр по времени + join по user_id (частый паттерн)
CREATE INDEX IF NOT EXISTS idx_events_created_user
ON events (created_at, user_id);

-- Проверяй план, чтобы не было Seq Scan на миллионах строк
EXPLAIN (ANALYZE, BUFFERS)
SELECT user_id, COUNT(*)
FROM events
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY user_id;

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

Материалы для подготовки к собеседованиям

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

🔴10 ключевых лайфхаков по резюме
🔴Нужны ли сопроводительные и что там писать
🔴Как отвечать на вопрос «Расскажите о себе»
🔴Как рассказывать о своем факапе?
🔴13 шаблонных отказов рекрутеров - что они означают.
🔥 Разборы резюме для разработчиков c нанимающим СТО

ну и то, что нам особенно интересно - про офферы и ЗП
🔴45 офферов по разным ИТ ролям: от аналитика до тим тим лида за 850к
🔴Какой тим лид получил 1,2 млн
🔴Оффер на Product lead в Яндекс
🔴Оффер на Руководителя проектов на 540к
🔴Оффер на функционального архитектора 1С на 460к
🔴Пошаговый план как выйти в найме на 1 млн руб

Сохраняйте, читайте, подписывайтесь

🔥 Теперь можно ничем не беспокоиться

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ ML-модель пересобирает логику ранжирования маршрутов

В Яндекс Картах изменился принцип выбора маршрута, который показывается первым. Раньше это по дефолту был самый быстрый. Теперь порядок определяет ML-модель, которая учитывает не только время в пути, но и множество других факторов: количество поворотов, сложность маневров, историю сходов на участке, предсказуемость движения и другие поведенческие сигналы.

Второе важное изменение — переход от задачи ранжирования к задаче выбора (Softmax + one-hot таргет). Модель больше не отвечает на вопрос «какой маршрут лучше в рейтинге?» — она учится угадывать единственный вариант, по которому пользователь действительно поедет. Фактически навигация сместилась от абстрактной оптимизации ETA к предсказанию реального выбора водителя — как если бы система пыталась угадать, какой маршрут человек сам бы выбрал, взглянув на карту. Почему выбрали в итоге не классический для такой задачи YetiRank — в разборе команды на Хабре.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥Появился сервис для прожарки вашего стартапа — ShipOrDie

Механика простая — вставляешь ссылку (или описываешь идею) и отдаёшь на растерзание боту и другим участникам. Сервис не щадя проходится по тексту и смыслам, находит размытые формулировки и перегретые обещания.

Плюс внутри можно поставить цель компании по выручке, трафику или количеству пользователей и вести публичный лог прогресса — но будьте готовы к критике.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX