Data Science. SQL hub

⚡️Кто такие дата-инженеры и почему без них не обойтись современному бизнесу? Сейчас каждая компания собирает тонны данных: продажи, клиенты, маркетинг, логистика. Но сырые цифры бесполезны, если их нельзя превратить в понятные отчёты и выводы. Приглашаем вас на вебинар 3 июня в 18:30 по МСК, где наш новый спикер — Владислав Вареник, Data Engineer в Сравни.ру — расскажет кто такие дата-инженеры и как они ускоряют работу бизнеса. Что вы узнаете на вебинаре? 🟠Поговорим о профессии дата-инженера и почему эта профессия востребована. 🟠Как устроен процесс работы с данными. 🟠Как автоматизировать отчёты с помощью dbt и SQL. 🟠Пример из реальной практики. Даже если вы далеки от аналитики — покажем, как начать с нуля и быстро получить результат. Не упустите шанс научиться тому, что будет цениться ещё десятки лет! 🚀 🕗 Встречаемся 3 июня в 18:30 по МСК 😶Зарегистрироваться на бесплатный вебинар

🧠 Хитрая задача по SQL: максимум без агрегатов? У тебя есть таблица orders со следующими полями:

orders(id, customer_id, order_date, amount)

📌 Задача: Для каждого клиента (`customer_id`) найти наиболее поздний заказ (по order_date`), **не используя `GROUP BY и `MAX()`**. 🔥 Уловка: DISTINCT ON, TOP 1 WITH TIES и RANK() нельзя — ты ограничен базовым SQL, работающим на большинстве СУБД. 💡 Подумай: Как ты решишь эту задачу только с JOIN, WHERE и EXISTS? 📥 Ожидаемый результат: ```sql customer_id | order_id | order_date | amount ------------|----------|------------|-------- 1001 | 87 | 2024-12-01 | 320.00 1002 | 91 | 2024-12-05 | 175.00 ... ``` 🧩 Подсказка: Можно использовать NOT EXISTS, чтобы выбрать заказы, у которых нет более новых у того же клиента.

SELECT o.*
FROM orders o
WHERE NOT EXISTS (
  SELECT 1
  FROM orders o2
  WHERE o2.customer_id = o.customer_id
    AND o2.order_date > o.order_date
)

📎 Такой приём полезен: • Когда нельзя использовать оконные функции • Когда ты работаешь на старых версиях СУБД • Когда нужна универсальность между MySQL / Oracle / SQLite #SQL #Задача #БазыДанных #DataEngineering #Оптимизация @sqlhub

📕 Сравнение индексации в PostgreSQL и ClickHouse для разработчиков, администраторов баз данных, инженеров и аналитиков данных На открытом уроке 3 июня в 20:00 мск мы обсудим различия в механизмах индексации между PostgreSQL и ClickHouse.  📗 На вебинаре разберём: 1. Основы и сравнение производительности разных подходов к индексации; 2. Для каких сценариев распространено использование этих подходов; 📘 В результате на практике разберете и сравните подходы, производительность и архитектуру индексации PostgreSQL и ClickHouse. 👉 Регистрация и подробности о курсе ClickHouse для инженеров и архитекторов БД: https://tglink.io/5ebd2827affd?erid=2W5zFFwCpjA Все участники открытого урока получат скидку на курс "ClickHouse для инженеров и архитекторов БД" Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

📧🤖 ART: интеллектуальный e-mail-агент с памятью, действиями и "мыслями" OpenPipe представили подробный разбор архитектуры ART (Action–Recall–Thought) — это не просто бот, а полноценный агент, который может читать письма, анализировать контекст, планировать действия и запоминать диалог. Такой себе LLM-секретарь, который не забывает, что вы писали неделю назад, и умеет реагировать правильно. 🧠 Что такое ART? ART — это архитектура, построенная вокруг трёх основных элементов: 1️⃣ Action — агент может действовать: писать ответы, создавать события, ставить задачи, отправлять follow-up. 2️⃣ Recall — агент вспоминает: использует векторную память, чтобы помнить важные детали переписки. 3️⃣ Thought — агент думает: размышляет о контексте, выбирает нужные шаги и обновляет своё внутреннее состояние. Каждый запуск агента — это один цикл мышления, в котором он анализирует новое письмо, сравнивает его с памятью и решает, что делать. 🧩 Как работает? Архитектура построена на LangGraph — фреймворке для создания LLM-агентов с управляемыми потоками данных (узлы, переходы, состояния). 🧬 Компоненты: - Nodes: - Reader: разбирает новое письмо - Memory Retriever: ищет релевантные воспоминания - Planner: решает, что делать - Executor: выполняет действия (ответ, событие и т.д.) - Reflector: обновляет размышления агента - Memory: - Используется ChromaDB (векторная база), куда сохраняются ключевые сообщения, решения, действия и мысли. - Tools: - Встроенные функции-агенты (tools) для генерации писем, событий, напоминаний, оповещений и т.п. - Всё вызывается динамически через LLM, как в OpenAI function calling. 🔁 Как агент работает на практике? Пример цикла: 1. Приходит e-mail → Reader извлекает суть. 2. Memory Retriever ищет похожие прошлые переписки. 3. Planner решает: ответить? создать задачу? проигнорировать? 4. Executor выполняет нужное действие. 5. Reflector обновляет память и размышления. Следующее письмо будет уже обрабатываться с учётом прошлого контекста. Агент понимает цепочку, тему, задачи и автоматически действует. 💡 Что делает ART особенным? ✅ Работает в несколько итераций, не просто «prompt → response» ✅ Помнит прошлые письма, решения, даже ошибки ✅ Сам планирует, что делать: отвечать, пересылать, напоминать ✅ Обновляет свои действия при изменении входных данных ✅ Настраивается под любые задачи: продажи, саппорт, личные письма, менеджмент 📎 Полный разбор от OpenPipe с примерами кода, схемами и демонстрацией: 👉 https://openpipe.ai/blog/art-e-mail-agent Если ты хочешь строить LLM-агентов с настоящей памятью и логикой — это must-read. Это шаг к настоящим автономным ассистентам. #AI #LLM #autonomousagents #LangGraph #e-mail #productivity #openpipe #инструменты @sqlhub

🛠️ Что нового в SQLite — свежие обновления и улучшения 🔗 https://www.sqlite.org/changes.html SQLite — одна из самых популярных встраиваемых баз данных в мире, и каждое обновление приносит не только исправления, но и серьёзные улучшения производительности и безопасности. Вот ключевые изменения из последних версий: 🆕 SQLite 3.46.0 (май 2024) - Добавлена поддержка contentless-delete для таблиц FTS5 — меньше места, выше скорость - Новый флаг SQLITE_DBCONFIG_STMT_SCANSTATUS — можно отключать сбор статистики по выполнению запросов - Оптимизации для LEFT JOIN + OR условий в WHERE — запросы выполняются заметно быстрее - Улучшено поведение WITHOUT ROWID таблиц с составными ключами 🧪 Расширенные тесты: - SQLite теперь использует дополнительный fuzzing для анализа стабильности ядра при высоких нагрузках и необычных SQL 🧹 Также исправлены: - Ошибки в индексах при сложной комбинации JOIN + USING - Утечка памяти при специфическом использовании PRAGMA function_list 💡 SQLite остаётся одной из самых лёгких, надёжных и удобных баз данных, которую можно использовать буквально везде: от браузеров и мобильных приложений до IoT и CLI-утилит. 📚 Полный список изменений — здесь: https://www.sqlite.org/changes.html @sqlhub

🎯 SQL-задача с подвохом для аналитиков Таблица sales:

CREATE TABLE sales (
    id SERIAL PRIMARY KEY,
    seller_name VARCHAR,
    sale_amount NUMERIC,
    sale_date DATE
);

📌 Задача: Найди имя продавца, который заработал максимальную сумму за каждый месяц. 🧠 Подвох: Многие пытаются использовать GROUP BY month, seller_name и MAX(), но это не даст имя продавца — только сумму. Нужно вернуть имя лучшего продавца за месяц. А если таких несколько? Тоже учти. 💡 Подсказки: • Сначала сгруппируй продажи по month и seller_name • Посчитай SUM(sale_amount) • Используй оконную функцию RANK() или ROW_NUMBER() • Отфильтруй только те строки, где rank = 1 🧩 Решение:

WITH monthly_totals AS (
    SELECT
        DATE_TRUNC('month', sale_date) AS month,
        seller_name,
        SUM(sale_amount) AS total
    FROM sales
    GROUP BY 1, 2
),
ranked AS (
    SELECT *,
           RANK() OVER (PARTITION BY month ORDER BY total DESC) AS rnk
    FROM monthly_totals
)
SELECT month, seller_name, total
FROM ranked
WHERE rnk = 1
ORDER BY month;

👀 Бонус-вопрос: Что будет, если у двух продавцов одинаковая сумма за месяц? Какой оконной функцией это корректно учесть? 👉 RANK() вернёт обоих, ROW_NUMBER() — только одного. 📌 Отличная задача, чтобы проверить знание оконных функций и работы с агрегацией в SQL. @sqlhub

🚀 Запуск обновленной версии курса «ML для финансового анализа»! Пройдите полный цикл создания торгового агента: от сбора и очистки данных до переноса в продакшн. Уже через полгода вы сможете самостоятельно разработать торгового бота! 🔹 Новое в программе - Портфельные стратегии и модели перебалансировки. - Предсказание цен с LSTM и оценка текстов. - Ансамбль блендинга с LLM. 🔹 Структура курса - Пошаговое обучение с домашними заданиями для создания торгового бота. 🔹 Адаптация под ваши запросы - Синтетические датасеты, свечные графики, очистка данных и многое другое. 🔹 Практический модуль - Перенос модели в продакшн, облачная инфраструктура, микросервисы и контроль метрик. 🎉 Специальное предложение Успейте воспользоваться 🏷10% скидкой на курс «ML для финансового анализа» и 🎁 бонусным промокодом FINANCE_5 и учитесь по ценам мая! Выгодные условия действуют по 31 мая включительно. ➡️ Ссылка для регистрации: https://tglink.io/bc637989f23f?erid=2W5zFK19MMi #реклама О рекламодателе

YTsaurus, разработанная в Яндексе платформа для хранения и обработки больших данных, стала доступна как управляемый сервис в Yandex Cloud. До 2023 года YTsaurus использовалась только внутри компании - для обучения нейросетей, аналитики, обработки телеметрии и работы с поисковым индексом. В прошлом году платформу выложили в опенсорс, и с тех пор она применяется как внутри Яндекса, так и за его пределами. Теперь YTsaurus можно развернуть в облаке - без ручной настройки и с поддержкой от команды Яндекса. Платформа работает с эксабайтами данных, масштабируется до миллиона CPU и десятков тысяч GPU, поддерживает ClickHouse, Spark, MapReduce и подходит для любых сценариев - от ETL до построения хранилищ. Заявки на ранний доступ уже открыты.

🦆 DuckDB теперь дружит с scikit-learn — мощный дуэт для ML-прототипов В свежем гайде от 16 мая 2025 команда DuckDB показывает, как использовать их аналитическую СУБД вместе с scikit-learn — чтобы максимально быстро и удобно прототипировать модели машинного обучения. 💡 Пример — классификация пингвинов (датасет Palmer Penguins): 🔸 Предобработка в DuckDB: Удаление NULL-ов, фильтрация, типизация. Категориальные признаки кодируются через референс-таблицы (вместо LabelEncoder). Используется selection_query с ленивым выполнением — данные грузятся только при необходимости. 🔸 Интеграция с scikit-learn: Извлекаем pandas DataFrame прямо из DuckDB. Обучаем классификатор (например, RandomForestClassifier) по подготовленным данным. 🛠 Идеально для: • Быстрого прототипирования моделей • Малых и средних наборов данных • Python-разработчиков, которым не хочется возиться с SQL-серверами 📎 Подробнее: https://duckdb.org/2025/05/16/scikit-learn-duckdb.html @sqlhub

7–8 июня проводим Weekend Offer Analytics Устроиться в Яндекс за выходные — реально. Ищем крутых аналитиков с опытом работы от 3 лет на Python, готовых работать в офисном или гибридном режиме. Подавайте заявку до 3 июня — и всего за 2 дня пройдите технические собеседования. После сможете пообщаться с двенадцатью нанимающими командами и выбрать ту, которая покажется самой интересной. Если всё сложится хорошо, сразу же пришлём вам офер. Узнать подробности и зарегистрироваться. Реклама. ООО "Яндекс". ИНН 7736207543

🚀 Сертификация DataLens Analyst — способ подтвердить свою экспертизу в BI и систематизировать работу с одним из самых популярных российских BI-инструментов — платформой от Yandex Cloud. Подходит всем, кто строит чарты, дашборды и анализирует данные. Сертификация охватывает ключевые темы: вычисляемые поля, параметры, датасеты, подключения к источникам, навигацию и управление доступом. Подготовка простая: бесплатный курс и примеры заданий собраны на одной странице. 🎯 До конца августа сертификация стоит 2 500 ₽ вместо 5 000 ₽ — отличный повод добавить сильную строчку в резюме https://vk.cc/cMn3KE

🧠 SQL-задача с подвохом: кто на самом деле опоздал? У тебя есть таблица с логами входа сотрудников в офис. Но задача не в том, чтобы просто найти "кто пришёл позже 9:00", а выяснить кого стоит считать реально опоздавшим, если учесть такую бизнес-логику: > Сотрудники входят в офис через турникет. Иногда турникет сканирует пропуск с задержкой, а иногда — несколько сотрудников входят подряд. Поэтому, если кто-то зашёл не позже, чем через 2 минуты после своего коллеги из той же команды — его не считают опоздавшим. 📊 Данные

CREATE TABLE office_logs (
    employee_id INT,
    team_id INT,
    entry_time TIMESTAMP
);

Пример данных: | employee_id | team_id | entry_time | |-------------|---------|---------------------| | 1 | 10 | 2024-01-01 08:59:10 | | 2 | 10 | 2024-01-01 09:00:50 | | 3 | 10 | 2024-01-01 09:02:20 | | 4 | 20 | 2024-01-01 09:03:00 | | 5 | 20 | 2024-01-01 09:04:40 | | 6 | 20 | 2024-01-01 09:10:00 | 🎯 Задача Напиши SQL-запрос, который определяет реально опоздавших сотрудников, если: 1. Время входа позже 09:00:00 2. Они не шли следом за коллегой из своей команды (разница входа больше 2 минут) 3. Один и тот же сотрудник не может быть "оправдан" несколькими — ищем только ближайшего предыдущего по времени из своей команды 💡 Подсказка: тут нужны: - оконные функции (`LAG`) - фильтрация по team_id - расчёт интервалов времени - доп. условия на время и порядок Реальное мышление аналитика начинается там, где бизнес-логика важнее простых фильтров. ✅ Решение: ```sql WITH logs_with_prev AS ( SELECT employee_id, team_id, entry_time, LAG(entry_time) OVER ( PARTITION BY team_id ORDER BY entry_time ) AS prev_entry_time FROM office_logs ), marked_late AS ( SELECT *, EXTRACT(EPOCH FROM (entry_time - prev_entry_time)) AS seconds_diff FROM logs_with_prev ) SELECT employee_id, team_id, entry_time FROM marked_late WHERE entry_time::time > '09:00:00' AND ( prev_entry_time IS NULL OR EXTRACT(EPOCH FROM (entry_time - prev_entry_time)) > 120 ); ``` 🔍 **Что происходит:** • Сначала `LAG` находит предыдущего входившего из той же команды • Затем считаем, сколько секунд прошло между входами • Если прошло больше 2 минут или сотрудник был первым — он **реально опоздал** 📦 Такое решение пригодится, если нужно учитывать **контекст** и **временные связи**, а не просто жёсткие фильтры. @sqlhub

🧠 Уровень Pro: Медиана, ранги и NULL в Oracle SQL 📋 Есть таблица sales:

CREATE TABLE sales (
  salesman_id NUMBER,
  region VARCHAR2(50),
  amount NUMBER
);

📦 Данные: | salesman_id | region | amount | |-------------|------------|--------| | 101 | 'North' | 200 | | 101 | 'North' | NULL | | 102 | 'North' | 150 | | 103 | 'North' | NULL | | 104 | 'South' | 300 | | 105 | 'South' | NULL | | 106 | 'South' | 50 | | 107 | 'South' | NULL | 🎯 Задача 2.0: Вывести salesman_id, чья сумма продаж меньше медианы по региону, и показать ранг продавца внутри региона по сумме продаж, где NULL = 0. ⚠ Подвохи: - MEDIAN() доступен только в Oracle. - Нужно предварительно агрегировать суммы. - Продавцы с только NULL-продажами = 0. - Ранг должен учитывать правильную сортировку и связи с регионом. ✅ Решение: ```sql WITH sales_total AS ( SELECT salesman_id, region, NVL(SUM(amount), 0) AS total_sales FROM sales GROUP BY salesman_id, region ), region_median AS ( SELECT region, MEDIAN(total_sales) AS region_median FROM sales_total GROUP BY region ), ranked AS ( SELECT st.salesman_id, st.region, st.total_sales, r.region_median, RANK() OVER (PARTITION BY st.region ORDER BY st.total_sales DESC) AS sales_rank FROM sales_total st JOIN region_median r ON st.region = r.region ) SELECT * FROM ranked WHERE total_sales < region_median; ``` 🧠 Объяснение: 1. `sales_total`: агрегируем продажи по продавцу, `NULL → 0` 2. `region_median`: считаем **медиану** продаж по каждому региону 3. `ranked`: добавляем `RANK()` по убыванию продаж внутри региона 4. Финальный фильтр: продажи ниже медианы 🔍 Пример вывода: | salesman_id | region | total_sales | region_median | sales_rank | |-------------|--------|-------------|----------------|-------------| | 105 | South | 0 | 50 | 3 | | 107 | South | 0 | 50 | 3 | | 103 | North | 0 | 150 | 3 | 📌 Польза: ✅ Отлично проверяет: - знание оконных функций - работу с медианой - поведение `NULL` в агрегатах - построение CTE-цепочек и аналитики 🔁 Можно расширить: - Добавить ранги *по убыванию и по возрастанию* - Вместо `MEDIAN()` использовать `PERCENTILE_CONT()` - Построить дэшборд: кто всегда "ниже медианы" за месяц @sqlhub

🛠️ История создания “storage-agnostic” message queue Контекст: Работая на Go, автор вдохновился инструментами из Node.js экосистемы (BullMQ, RabbitMQ) и захотел сделать что-то похожее, но с нуля, без зависимостей. Так родилась идея — сначала он создал Gocq (Go Concurrent Queue): простую concurrent-очередь, работающую через каналы. ⚡ Основная проблема Gocq отлично работал в памяти, но не поддерживал устойчивое хранение задач. Автор задумался: а можно ли сделать очередь, не зависящую от конкретного хранилища — так, чтобы её можно было подключить к Redis, SQLite или совсем без них? 🧱 Как это реализовано в VarMQ После рефакторинга Gocq был разделён на два компонента: 1) Worker pool — пул воркеров, обрабатывающих задачи 2) Queue interface — абстракция над очередью, не зависящая от реализации Теперь воркер просто берёт задачи из очереди, не зная, где они хранятся. 🧠 Пример использования • In-memory очередь:

w := varmq.NewVoidWorker(func(data any) {
   // обработка задачи
}, 2)
q := w.BindQueue()

• С SQLite-поддержкой:

import "github.com/goptics/sqliteq"

db := sqliteq.New("test.db")
pq, _ := db.NewQueue("orders")
q := w.WithPersistentQueue(pq)

• С Redis (для распределённой обработки):

import "github.com/goptics/redisq"

rdb := redisq.New("redis://localhost:6379")
pq := rdb.NewDistributedQueue("transactions")
q := w.WithDistributedQueue(pq)

В итоге воркер обрабатывает задачи одинаково — независимо от хранилища. ✅ Почему это круто • Гибкость: адаптеры позволяют легко менять хранилище без правок воркера • Минимальные зависимости: в яд 📌 Читать

Истории, после которых ты захочешь уволиться Ты правда думал, что так и будешь сидеть в найме до пенсии? А потом читаешь пост какого-то чувака из IT и ловишь: “бл*, я тоже так хочу”. В этом канале бывший дата саентист — Глеб Михайлов. Он уволился из Яндекса, послал всё на*** и теперь пишет как есть: – про выгорание, – про деньги, свободу и зашквар, – и как из всего этого лепить свою жизнь. Топ постов канала: 👉 7 лет отсидки (https://t.me/mikhaylovgleb/336) (в офисе) 👉 Страшно – пи***ц (https://t.me/mikhaylovgleb/302) 👉 Робот-пылесос для денег (https://t.me/mikhaylovgleb/347) Подпишись - https://t.me/mikhaylovgleb, если тоже устал терпеть. Тут честно, смешно и немного больно — как в жизни. Реклама

🐘 pgBackRest — надежное решение для резервного копирования PostgreSQL. В отличие от стандартных утилит, pgBackRest предлагает параллельное выполнение операций, поддержку инкрементных бэкапов на уровне блоков и встроенную проверку целостности через контрольные суммы. Особого внимания заслуживает гибкость развертывания: резервные копии можно хранить локально, на удаленных серверах через SSH/TLS или в облачных хранилищах S3/Azure/GCS. Система автоматически управляет ротацией архивов и обеспечивает консистентность данных даже при аварийном завершении работы. 🤖 GitHub @sqlhub

В мире, где данные — это новая валюта, каждый специалист должен уметь работать с ними на высшем уровне. Особенно — аналитики. Сделать уверенный старт в профессии можно на курсе «Аналитик данных» от karpovꓸcourses. Вы узнаете, как наводить порядок в потоке данных, выявлять скрытые связи, превращать хаотичные цифры в понятные факты и точные решения, которые помогают бизнесу двигаться вперед. На курсе есть все, что нужно для эффективной работы с данными: от Python и SQL до BI-инструментов и создания дашбордов. С 12 по 31 мая погружаться в аналитику еще выгоднее. При покупке курса «Аналитик данных» и симулятора A/B-тестов вы получите скидку 10%. А главное, сразу усилите резюме ценными навыками. Реклама. ООО «Карпов Курсы», ИНН: 7811764627, erid: 2VtzqunnpSp

🗂️ BRModelo Web — веб-приложение для проектирования баз данных. Этот open-source проект позволяет создавать ER-диаграммы прямо в браузере с экспортом в SQL-скрипты. Инструмент имеет образовательную направленность. Интерфейс на португальском и английском языках адаптирован для учебных задач: есть подсветка сущностей, автоматическая расстановка связей и валидация схемы. Запустить локальную копию можно через Node.js + MongoDB или Docker-контейнеры. 🤖 GitHub @sqlhub

👣 Stateless Postgres Query Router — это система шардирования для PostgreSQL-кластера, доступная с открытым исходным кодом. Её основной компонент, роутер, анализирует запросы и определяет, на каком конкретном PostgreSQL-кластере следует выполнить транзакцию или запрос. Ключи шардирования могут передаваться в запросе как явно, так и неявно, в виде комментариев. В SPQR реализованы функции транзакционного и сессионного пулинга, автобалансировки шардированных таблиц, а также поддержка всех возможных методов аутентификации, сбора статистики и динамической перезагрузки конфигурации. SPQR поддерживает как запросы к определённому шарду, так и запросы ко всем шардам. В ближайших планах — добавить поддержку двухфазных транзакций и референсных таблиц. Исходный код SPQR распространяется под лицензией PostgreSQL Global Development Group ⚡️ Ссылки: 🟢https://github.com/pg-sharding/spqr 🟢https://pg-sharding.tech/ @sqlhub