ch
Feedback
Data Science. SQL hub

Data Science. SQL hub

前往频道在 Telegram

По всем вопросам- @workakkk @itchannels_telegram - 🔥лучшие ит-каналы @ai_machinelearning_big_data - Machine learning @pythonl - Python @pythonlbooks- python книги📚 @datascienceiot - ml книги📚 РКН: https://vk.cc/cIi9vo #VRHSZ

显示更多

📈 Telegram 频道 Data Science. SQL hub 的分析概览

频道 Data Science. SQL hub (@sqlhub) 俄语 语言赛道中的 是活跃参与者。目前社区聚集了 35 848 名订阅者,在 技术与应用 类别中位列第 3 835,并在 俄罗斯 地区排名第 18 129

📊 受众指标与增长动态

невідомо 创建以来,项目保持高速增长,吸引了 35 848 名订阅者。

根据 13 六月, 2026 的最新数据,频道保持稳定运转。过去 30 天订阅人数变化为 -8,过去 24 小时变化为 -11,整体触达仍然可观。

  • 认证状态: 未认证
  • 互动率 (ER): 平均受众互动率为 9.82%。内容发布后 24 小时内通常能获得 4.08% 的反应,占订阅者总量。
  • 帖子覆盖: 每篇帖子平均可获得 3 522 次浏览,首日通常累积 1 461 次浏览。
  • 互动与反馈: 受众积极参与,单帖平均反应数为 13
  • 主题关注点: 内容集中在 sql, индекс, postgres, index, sqlite 等核心主题上。

📝 描述与内容策略

作者将该频道定位为表达主观观点的平台:
По всем вопросам- @workakkk @itchannels_telegram - 🔥лучшие ит-каналы @ai_machinelearning_big_data - Machine learning @pythonl - Python @pythonlbooks- python книги📚 @datascienceiot - ml книги📚 РКН: https://vk.cc/cIi9vo #VRHSZ

凭借高频更新(最新数据采集于 14 六月, 2026),频道始终保持新鲜度与高覆盖。分析显示受众积极互动,使其成为 技术与应用 类别中的关键影响点。

35 848
订阅者
-1124 小时
-317
-830
帖子存档
🧠 SQL-задача с подвохом (Oracle) Тема: оконные функции, группировка, ловушка в агрегатах 📌 Задача: Есть таблица SALES со следующей структурой:

CREATE TABLE SALES (
  ID         NUMBER,
  REGION     VARCHAR2(20),
  SALE_DATE  DATE,
  AMOUNT     NUMBER
);
Пример данных: | ID | REGION | SALE_DATE | AMOUNT | |----|--------|-----------|--------| | 1 | North | 01-JAN-24 | 100 | | 2 | North | 02-JAN-24 | 120 | | 3 | South | 01-JAN-24 | 90 | | 4 | South | 03-JAN-24 | 200 | | 5 | East | 01-JAN-24 | 150 | | 6 | East | 02-JAN-24 | 100 | 🧩 Найти: Для каждого региона — ту дату, в которую была вторая по величине сумма продаж. Если в регионе меньше двух дат — не выводить его вовсе. 🎯 Подвох: - нельзя использовать LIMIT, FETCH FIRST, QUALIFY и подзапросы с ROWNUM напрямую (нужно решение через оконные функции Oracle) - многие пытаются взять MAX(AMOUNT) с OFFSET 1, но в Oracle это не так просто ✅ Ожидаемый результат: | REGION | SALE_DATE | AMOUNT | |--------|-----------|--------| | North | 01-JAN-24 | 100 | | South | 01-JAN-24 | 90 | | East | 02-JAN-24 | 100 | 🔍 Решение: ```sql SELECT REGION, SALE_DATE, AMOUNT FROM ( SELECT REGION, SALE_DATE, AMOUNT, DENSE_RANK() OVER (PARTITION BY REGION ORDER BY AMOUNT DESC) AS rnk, COUNT(DISTINCT SALE_DATE) OVER (PARTITION BY REGION) AS cnt FROM SALES ) WHERE rnk = 2 AND cnt >= 2; ``` 📌 **Объяснение подвоха:** - `DENSE_RANK` гарантирует, что если есть одинаковые суммы, они получат один и тот же ранг - `COUNT(DISTINCT SALE_DATE)` проверяет, что у региона хотя бы две разные даты (иначе регион исключается) - Работает чисто на оконных функциях, без подзапросов с ROWNUM — идеально для Oracle 🧪 Проверь результат и попробуй адаптировать под похожие задачи с TOP-N логикой. @sqlhub

🛢️ SQL-задача с подвохом: GROUP BY и скрытая ловушка Условие: Есть таблица orders: | id | customer_id | amount | status | |-----|-------------|--------|-----------| | 1 | 101 | 200 | completed | | 2 | 102 | 150 | NULL | | 3 | 101 | 300 | completed | | 4 | 103 | NULL | completed | | 5 | 102 | 100 | completed | | 6 | 101 | 250 | NULL | Задача: найти всех клиентов, у которых сумма заказов больше 500. Ты пишешь запрос:

SELECT customer_id, SUM(amount) as total
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 500;
Вопрос: Какие клиенты вернутся? Есть ли тут подвох? Что произойдёт с заказами, где amount или statusNULL? 🔍 Подвох: На первый взгляд запрос правильный: мы группируем по клиентам и суммируем их заказы. Но вот критичные моменты: 1️⃣ Что происходит с NULL в `amount`? В SQL агрегатные функции (например, SUM) игнорируют NULL значения. Это значит: - Заказ id=4 (`amount = NULL`) не участвует в суммировании. - Заказ id=6 (`amount = 250`) участвует, потому что amount не NULL. 2️⃣ Считаем по каждому клиенту: - customer_id=101: - id=1: 200 - id=3: 300 - id=6: 250 Итого: 200 + 300 + 250 = 750 - customer_id=102: - id=2: 150 - id=5: 100 Итого: 150 + 100 = 250 - customer_id=103: - id=4: NULL (игнорируется) Итого: 0 3️⃣ Кто попадёт в результат: Только customer_id=101 (с суммой 750 > 500). --- ✅ Результат: | customer_id | total | |-------------|--------| | 101 | 750 | --- 💥 Подвох #2: Допустим ты случайно написал:

HAVING SUM(amount) IS NOT NULL AND SUM(amount) > 500;
Кажется логичным? А вот нет: SUM всегда возвращает 0 (не NULL), даже если у клиента нет заказов с ненулевой суммой. ➡️ Даже клиент с только NULL значениями (например, customer_id=103) получит SUM(amount) = 0, а не NULL. Это частая ловушка: COUNT, SUM, AVG игнорируют NULL внутри, но результат НЕ NULL (обычно 0 или NULL в зависимости от агрегата). --- 🛠 Что ещё важно: • Если хочешь учитывать только выполненные заказы (status = 'completed'), нужно добавить:

WHERE status = 'completed'
⚠️ Не пиши условие в HAVING для фильтрации строк — лучше фильтровать через WHERE до группировки.Вывод: - ✅ Агрегатные функции типа SUM игнорируют NULL внутри группы. - ✅ SUM возвращает 0, даже если все значения NULL (НЕ NULL, как думают многие). - ✅ HAVING применяется ПОСЛЕ группировки, а WHERE — ДО. - ✅ Ошибки часто возникают, если условие на фильтр пишут в HAVING вместо WHERE. 💡 Бонус-вопрос: Что будет, если заменить SUM(amount) на COUNT(amount) в SELECT и HAVING? И как это повлияет на клиентов с NULL значениями? @sqlhub

🖥 SQL Flow SQL Flow позиционируется как «DuckDB для потоковых данных» — лёгковесный движок stream-обработки, позволяющий опи
🖥 SQL Flow SQL Flow позиционируется как «DuckDB для потоковых данных» — лёгковесный движок stream-обработки, позволяющий описывать весь pipeline единственным языком SQL и служащий компактной альтернативой Apache Flink. 🔍 Ключевые возможности: - Источники (Sources): Kafka, WebSocket-стримы, HTTP-webhooks и др. - Приёмники (Sinks): Kafka, PostgreSQL, локальные и S3-подобные хранилища, любые форматы, которые поддерживает DuckDB (JSON, Parquet, Iceberg и т.д.). - SQL-обработчик (Handler): встраивает DuckDB + Apache Arrow; поддерживает агрегаты, оконные функции, UDF и динамический вывод схемы. - Управление окнами: in-memory tumbling-windows, буферные таблицы. - Наблюдаемость: встроенные Prometheus-метрики (с релиза v0.6.0). 🔗 Архитектура Конвейер описывается YAML-файлом с блоками `source → handler → sink`. Во время выполнения: 1. Source считывает поток (Kafka, WebSocket …). 2. Handler выполняет SQL-логику в DuckDB. 3. Sink сохраняет результаты в выбранное хранилище. ✅ Быстрый старт (≈ 5 минут)

# получить образ
docker pull turbolytics/sql-flow:latest

# тестовая проверка конфигурации
docker run -v $(pwd)/dev:/tmp/conf \
           -v /tmp/sqlflow:/tmp/sqlflow \
           turbolytics/sql-flow:latest \
           dev invoke /tmp/conf/config/examples/basic.agg.yml /tmp/conf/fixtures/simple.json

# запуск против Kafka
docker-compose -f dev/kafka-single.yml up -d      # поднять Kafka

docker run -v $(pwd)/dev:/tmp/conf \
           -e SQLFLOW_KAFKA_BROKERS=host.docker.internal:29092 \
           turbolytics/sql-flow:latest \
           run /tmp/conf/config/examples/basic.agg.mem.yml --max-msgs-to-process=10000
Github @sqlhub

💫 GlueSQL — SQL-движок, превращающий любые данные в полноценную базу данных. Этот инструмент умеет выполнять JOIN между CSV
💫 GlueSQL — SQL-движок, превращающий любые данные в полноценную базу данных. Этот инструмент умеет выполнять JOIN между CSV и MongoDB, работать с Git как с хранилищем данных и даже запускать SQL-запросы прямо в браузере через WebAssembly. Что отличает GlueSQL от классических СУБД? - Поддержка schemaless-данных - Встроенные адаптеры для 10+ форматов - Возможность добавлять свои хранилища через реализацию двух traits на Rust Проект активно развивается: недавно добавили поддержку транзакций в Sled-бэкенде и анонсировали облачную версию. Для теста достаточно cargo add gluesql и уже можно писать SQL-запросы к данным в памяти. 🤖 GitHub @sqlhub

# 🧩 Задача для SQL-аналитиков: "Пропавшие продажи" 📖 Описание задачи У вас есть таблица sales, где хранятся данные о продажах:

CREATE TABLE sales (
    sale_id INT PRIMARY KEY,
    sale_date DATE,
    product_id INT,
    quantity INT,
    price DECIMAL(10,2)
);

INSERT INTO sales (sale_id, sale_date, product_id, quantity, price) VALUES
(1, '2024-01-01', 101, 1, 100.00),
(2, '2024-01-02', 102, 2, 150.00),
-- ...
-- остальные данные
;
Каждый день формируется отчёт, где суммируются продажи по дням:

SELECT sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY sale_date;
Вчера сумма в отчёте была 1,000,000. Сегодня — 980,000, хотя новых записей не удаляли. 📝 Ваша задача: 1. Найти, какие записи "исчезли" из отчёта, если данных в таблице sales фактически не удаляли. 2. Определить, почему эти записи больше не попадают в итоговый запрос. 3. Исправить отчёт, чтобы сумма снова стала 1,000,000. Ограничения: - Таблица не изменилась по количеству строк. - Никто не менял код запроса. - sale_date, quantity, price остались без изменений. Подсказка: возможно, дело в NULL, JOIN или неправильной агрегации. 🕵️ Что проверяет задача: - Знание SQL-агрегации - Понимание NULL и работы SUM - Умение анализировать запросы «не через код», а через их результат - Навык находить «скрытые» ошибки данных (например, sale_date стал NULL) 💡 Решение: При проверке выяснится, что часть записей имеет `sale_date = NULL` (например, кто-то обновил поле sale_date на NULL). Итоговый запрос: ```sql SELECT sale_date, SUM(quantity * price) AS total_sales FROM sales GROUP BY sale_date; ``` не учитывает строки, где `sale_date IS NULL`, потому что GROUP BY игнорирует NULL как отдельную группу (не попадает ни в один существующий `sale_date`). Чтобы увидеть эти записи: ```sql SELECT sale_date, COUNT(*), SUM(quantity * price) FROM sales GROUP BY sale_date; ``` Для восстановления суммы нужно добавить обработку NULL, например: ```sql SELECT COALESCE(sale_date, 'unknown') AS sale_date, SUM(quantity * price) AS total_sales FROM sales GROUP BY COALESCE(sale_date, 'unknown'); ``` ✅ Теперь сумма снова будет 1,000,000, а "пропавшие" продажи попадут в отдельную категорию unknown. 🎯 Эта задача учит: ✅ Всегда думать о данных, а не только о коде ✅ Проверять поля на NULL даже там, где их не ожидаешь ✅ Уметь объяснять ошибки «бизнес-заказчику», а не только исправлять запрос 🔥 Отличная тренировка внимательности и понимания нюансов SQL-агрегации! @sqlhub

📜 История SQL — от лабораторной идеи до «языка данных» № 1 Как появился самый известный язык работы с базами, почему он едва не остался «Сиквелом» и какие любопытные факты о нём редко всплывают в учебниках. 1. Всё началось с таблицы на бумаге - 1970 г. — британский математик Эдгар Ф. Кодд публикует культовую статью *“A Relational Model of Data for Large Shared Data Banks”*. - В ней впервые прозвучала идея: хранить данные в виде связанных таблиц, а не как запутанные иерархии (IMS) или сетевые графы (Codasyl). - Коллеги в IBM скептически называли это «бумагой на буквы», но разрешили сделать прототип, чтобы проверить утопию Кодда на практике. 2. SEQUEL — «английский» запрос к таблицам - 1973–1974 гг. — в лаборатории IBM San José (ныне Almaden) двое молодых исследователей, Дональд Чемберлин и Рэймонд Бойс, берутся за проект System R. - Чтобы обращаться к реляционным таблицам, они придумывают Structured English QUEry Language — SEQUEL. - Ключевая фишка — запросы выглядят почти как английские предложения:

    SELECT name, salary
      FROM employees
     WHERE dept = 'R&D';
    
- В 1974‑м публикуют первую спецификацию; академики критикуют за «слишком поверхностный английский», но программисты в восторге. 3. Почему SEQUEL стал SQL - Торговая марка “SEQUEL” уже принадлежала авиастроительной компании *Hawker Siddeley*. - IBM, опасаясь суда, в 1976 г. официально отказывается от «E» и оставляет SQL (Structured Query Language). - *Небольшая путаница осталась навсегда: кто‑то произносит «эс‑кью‑эл», кто‑то — «сиквел».* 4. Коммерческий взлёт - 1978 | Первая демонстрация System R внутри IBM | показала, что SQL работает быстрее ожиданий | - 1979 | Стартап Relational Software (позже Oracle**) выпускает **Oracle V2 — первый коммерческий SQL‑движок | IBM ещё не успела выйти на рынок - 1981 | IBM выпускает SQL/DS для мейнфреймов | стандарт де‑факто закрепляется - 1983 | Дебют DB2 — теперь SQL есть почти в каждом крупном банке 5. Стандартизация и эволюция - ANSI SQL‑86SQL‑92 (появился `JOIN ... ON`) → SQL:1999 (рекурсия, триггеры) → SQL:2003 (XML) → … → SQL:2023 (JSON, property graphs). - Каждые 3–5 лет комитет добавляет «модные» возможности, но 90 % повседневных запросов всё ещё укладываются в синтаксис 1980‑х. 6. Забавные факты, которые украсят small talk 🍸 1. NULL ≠ 0 и NULL ≠ NULL — «неизвестное значение» нарушает законы логики, за что его зовут *“пятой ногой”* реляционной алгебры. 2. `SELECT *` — наследие печати на станке. Звёздочка означала «все колонки», чтобы не писать их руками в 132‑символьных перфокартах. 3. Команда `GO` в MS SQL Server не принадлежит стандарту SQL — это директива из старого клиента isql. 4. В Oracle долго не было `LIMIT`, а в MySQL — `RIGHT JOIN`. Поэтому админы шутили: «истинный межплатформенный SQL — это `SELECT 1;`». 5. Первый SQL‑вирус — червь *Slammer* (2003) — парализовал интернет за 10 минут через уязвимость в SQL Server 2000. 6. SQL — декларативный язык, но внутри СУБД каждый SELECT превращается в процедурный план. 7. `DROP DATABASE` придумали позже, чем `CREATE`. Сначала удалять целую БД казалось слишком опасным. 7. Почему SQL живёт дольше модных NoSQL‑наследников - Математическая база. Таблицы + операции Кодда образуют алгебру с предсказуемой оптимизацией. - Стандарты и переносимость. Код двадцатилетней давности можно запустить в современной Postgres или MariaDB. - Большая экосистема. От Excel‑плагинов до BigQuery — везде так или иначе поддерживается SQL‑диалект. - Сопротивляемость моде. Каждый «убийца SQL» (MapReduce, GraphQL, документные БД) в итоге добавляет свой адаптер SELECT …. Итог: SQL родился как эксперимент IBM, пережил смену названий и юридические баталии, но в итоге стал «лентой Мёбиуса» мира данных: можно зайти с любой стороны — и всё равно окажешься в FROM.

📕MySQL для администраторов, разработчиков, архитекторов и специалистов баз данных Как грамотно оптимизировать производительн
📕MySQL для администраторов, разработчиков, архитекторов и специалистов баз данных Как грамотно оптимизировать производительность в MySQL и решить возникающие проблемы. 📗 На вебинаре 6 мая в 19:00 разберём: 1. Практические методы оптимизации производительности, диагностику нагрузки и анализ "узких мест" MySQL; 2. Оптимизацию запросов: от простых до сложных. 📘 В результате будете знать всё о настройке ключевых параметров конфигурации, уметь самостоятельно диагностировать и решать проблемы производительности MySQL. 👉 Регистрация и подробности о курсе Базы данных: https://otus.pw/5iMh/?erid=2W5zFGeaQTA Все участники открытого урока получат скидку на курс Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

## 7 полезных приёмов для Oracle SQL Простые советы для Oracle SQL, которые помогут аналитикам данных прокачать свои запросы. 1) Фильтрованные (partial) индексы В Oracle можно создавать индексы только для подмножества строк, чтобы ускорить выборку по популярным условиям.

CREATE INDEX idx_orders_high_value
  ON orders(order_date)
  WHERE total_amount > 1000;
2) Функциональные (function-based) индексы Если фильтруете или джойните по функции, создайте индекс прямо по выражению:

CREATE INDEX idx_orders_year
  ON orders (EXTRACT(YEAR FROM order_date));
3) GROUPING SETS, ROLLUP, CUBE Для одновременной агрегации по нескольким группировкам без UNION ALL:

SELECT region, category, SUM(sales) AS total
FROM sales
GROUP BY ROLLUP (region, category);
4) Материализованные представления с QUERY REWRITE В Oracle можно сделать автоматическую подмену сложного запроса предрасчитанным результатом (материализованным представлением):

CREATE MATERIALIZED VIEW mv_sales_by_month
BUILD IMMEDIATE
REFRESH FAST ON COMMIT
ENABLE QUERY REWRITE
AS
SELECT TRUNC(order_date, 'MM') AS month, SUM(total_amount) AS total
FROM orders
GROUP BY TRUNC(order_date, 'MM');
Теперь запрос SELECT month, SUM(total_amount) FROM orders GROUP BY month; автоматически будет использовать mv_sales_by_month. 5) WITH PL/SQL FUNCTION RESULT CACHE Кэшируйте результат функции, чтобы при одинаковых входных данных не пересчитывать:

CREATE OR REPLACE FUNCTION get_tax_rate(p_region VARCHAR2)
RETURN NUMBER RESULT_CACHE RELIES_ON (tax_table) IS
  v_rate NUMBER;
BEGIN
  SELECT rate INTO v_rate FROM tax_table WHERE region = p_region;
  RETURN v_rate;
END;
6) PARALLEL HINT для ускорения запросов Явно указывайте параллельное выполнение запроса, чтобы задействовать несколько процессов:

SELECT /*+ PARALLEL(orders, 4) */ customer_id, SUM(total_amount)
FROM orders
GROUP BY customer_id;
7) DBMS_STATS.AUTO_SAMPLE_SIZE для сбора статистики Используйте автоматический подбор размера выборки для более точной оптимизации плана выполнения:

EXEC DBMS_STATS.GATHER_TABLE_STATS('HR', 'ORDERS', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE);
Совет: проверяйте планы выполнения через DBMS_XPLAN.DISPLAY_CURSOR, чтобы видеть реальные шаги запроса, а не только предполагаемые. @sqlhub

👣 Небольшой пример как копировать данные между базами данных используя `go`, `pgx`, и `copy` Предположим что у нас есть два
👣 Небольшой пример как копировать данные между базами данных используя `go`, `pgx`, и `copy` Предположим что у нас есть два коннекта к базе (одной или нескольким, это не важно). Далее используя io.Pipe() создаём Reader и Writer, и используя CopyTo() и CopyFrom() переносим данные.
  r, w := io.Pipe()

  doneChan := make(chan struct{}, 1)

  go func() {
      defer close(doneChan)

      _, err := db1.PgConn().CopyTo(ctx, w, `copy table1 to stdin binary`)
      if err != nil {
          slog.Error("error", "error", err)
          return
      }
      _ = w.Close()
      doneChan <- struct{}{}
  }()

  _, err = db2.PgConn().CopyFrom(ctx, r, `copy table1 from stdout binary`)
  _ = r.Close()

  select {
  case <-doneChan:
  case <-ctx.Done():
  }
Вся прелесть тут в том что используем наиболее быстрый способ с точки зрения PostgreSQL. Используя `copy (select * from where ... order by ... limit ...) to stdout `можем регулировать нагрузку на чтение, следить за прогрессом и управлять копированием данных. В качестве Reader может выступать что угодно, хоть файл csv, хоть другая СУБД, но тогда данные придётся дополнительно конвертировать в формат понимаемый PostgreSQL - csv или tsv, и использовать copy ... from stdin (format csv). Нюанс: copy ... from stdin binary , binary обязывает использовать одинаковые типы данных, нельзя будет integer колонку перенести в колонку smallint, если такое требуется, то параметр binary надо опустить. Весь код тут. И ещё немного кода для вдохновения. @Golang_google

🔥 Qwen2.5-Omni-3B — оптимизированная, компактная Omni модель(3B), доступная для запуска на обычных потребительских GPU! 🔋 Э
🔥 Qwen2.5-Omni-3B — оптимизированная, компактная Omni модель(3B), доступная для запуска на обычных потребительских GPU! 🔋 Экономия памяти: по сравнению с 7B-версией модель потребляет на 50 % меньше VRAM при обработке длинного контекста (~25 000 токенов). 📺 Мультимодальные режим: поддержка 30-секундных аудио- и видео«из коробки» на 24 GB видеокартах. 🤖 Высокое качество: модель сохраняет свыше 90 % точности ответов и обеспечивает естественный, стабильный синтез речи на уровне 7B-модели. 🔜 Репозиторий GitHub: https://github.com/QwenLM/Qwen2.5-Omni 🔜Hugging Face: https://huggingface.co/Qwen/Qwen2.5-Omni-3B 🔜ModelScope: https://modelscope.cn/models/Qwen/Qwen2.5-Omni-3B #Qwen #omni #opensource @ai_machinelearning_big_data

Столкнулись с падением производительности базы данных? Не делайте резких движений: вы можете ухудшить ситуацию. Сначала нужно
Столкнулись с падением производительности базы данных? Не делайте резких движений: вы можете ухудшить ситуацию. Сначала нужно верно диагностировать причину проблемы. Возможно вы неправильно выбрали индексы, а быть может дело вообще в самой архитектуре БД – вариантов масса! На открытом вебинаре «Как ускорить работу и повысить надёжность PostgreSQL» вы узнаете: 🎯как обеспечить высокую производительность и отказоустойчивость базы данных 🎯как вовремя выявить деградацию производительности с помощью диагностики Вебинар проведёт Дмитрий Золотов, Kotlin-разработчик в «Яндексе». Приглашаем технических руководителей, админов БД, девопсов и разработчиков. Все участники получат в подарок видеоурок «Безопасность в PostgreSQL: защита данных, управление доступом и аудит» и скидку 7% на любой курс OTUS. 6 мая, 19:00 МСК Бесплатно Записаться - https://otus.pw/sWHl/ Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963. erid: 2W5zFG8vzDn

NotebookLM теперь умеет делать подкасты на русском и других славянских языках Новая функция позволяет превращать документы в аудио — можно генерировать как полезные, так и совсем абсурдные подкасты (пример в посте). Идеально, чтобы слушать вместо чтения, например, во время пробежки. Озвучка на русском немного уступает английской, но звучит достойно. 🎧 Бесплатно, пробуем

Приглашаем студентов на бесплатный студкемп Яндекс Образования и ИТМО по управлению данными Готовы попробовать свои силы в ре
Приглашаем студентов на бесплатный студкемп Яндекс Образования и ИТМО по управлению данными Готовы попробовать свои силы в решении реальных задач? Бесплатный студкемп Яндекса и ИТМО — ваш шанс погрузиться в востребованное IT-направление и открыть новые профессиональные горизонты! Во время интенсива вы изучите принципы микросервисных архитектур, освоите системы распределённого хранения и разберётесь с DataOps и MLOps. А ещё будете участвовать в разработке комплексных пайплайнов: от автоматического сбора до визуализации данных. Студкемп пройдёт с 30 июня по 12 июля в Санкт-Петербурге на базе ИТМО. Приглашают студентов со всей России и каждому, кто пройдёт отбор, оплатят проезд и проживание. Успейте подать заявку до 4 мая.

+3
🖥 Крутая подборка шпаргалок по SQL Внутри — SQL для data analysis; — SQL Joins; — Оконные функции; — Основы SQL. @sqlhub

Стартовал набор в ШАД — успейте подать заявку! Технологии меняют нашу реальность, но за их развитием стоят люди, которые умею
Стартовал набор в ШАД — успейте подать заявку! Технологии меняют нашу реальность, но за их развитием стоят люди, которые умеют находить нестандартные решения. И именно в Школе анализа данных Яндекса готовят таких специалистов! Здесь амбициозные и увлечённые студенты: погружаются в машинное обучение, Data Science и искусственный интеллект; перенимают опыт экспертов из индустрии; учатся решать задачи, стоящие перед ведущими IT-компаниями и исследовательскими центрами. Учёба в ШАДе — это серьёзный вызов даже для тех, кто уже знаком с анализом данных. Поступить непросто, но если вы готовы к интенсивной нагрузке, нестандартным кейсам и полной пересборке своего мышления — это место для вас! За 2 года обучения вы получите инструменты и навыки, которые позволят работать над сложнейшими задачами индустрии, запускать собственные проекты и двигать науку вперёд. Занятия полностью бесплатны и проходят по вечерам. Если в вашем городе нет филиала, можно учиться онлайн. Готовы бросить вызов данности? Тогда подавайте заявку до 4 мая!

🔍 Milvus — масштабируемая высокопроизводительная векторная БД для AI-приложений с нативной интеграцией с Kubernetes. Проект
🔍 Milvus — масштабируемая высокопроизводительная векторная БД для AI-приложений с нативной интеграцией с Kubernetes. Проект написан на Go и C++ и оптимизирован для работы с миллиардами векторов в реальном времени. Помимо классических dense-векторов, Milvus поддерживает sparse-модели для полнотекстового поиска и гибридные запросы. Для локального тестирования есть облегченная версия, устанавливаемая через pip. 🤖 GitHub @sqlhub

🖥 Задача: Анализ пользовательского поведения с аномалиями в SQL ## Условие задачи: Дана таблица user_events со следующей структурой:

CREATE TABLE user_events (
    user_id INT,
    event_time TIMESTAMP,
    event_type VARCHAR(50),
    platform VARCHAR(50)
);
🎯 Каждая строка описывает событие пользователя: - user_id — идентификатор пользователя, - event_time — время события, - event_type — тип события (`login`, purchase, logout, error и т.д.), - platform — платформа (`iOS`, Android, `Web`). Требуется: 1. Найти пользователей, которые: - Выполнили покупку (`purchase`), - Но не заходили в систему (`login`) в течение последних 7 дней перед покупкой. 2. Найти пользователей, у которых: - Более 30% всех событий за последний месяц составляют события типа error. 3. Рассчитать для каждого пользователя: - Среднее время между входом (`login`) и следующим выходом (`logout`). - Если logout отсутствует после login — игнорировать такую сессию. --- ## Дополнительные условия: - Считайте, что данные могут быть объемными: миллионы строк. - Решение должно быть оптимизировано: избегайте подзапросов в подзапросах без индексов, старайтесь минимизировать количество проходов по данным. - Можно использовать оконные функции (`WINDOW FUNCTIONS`) и временные таблицы (`CTE`) для упрощения запросов. - Платформу можно игнорировать в расчетах. --- ## Что оценивается: - Умение использовать оконные функции и агрегаты. - Умение правильно интерпретировать условия задачи в SQL-операции. - Оптимизация запросов под большие объемы данных. - Чистота, читаемость и структурированность кода SQL-запросов. --- Примечание: Эта задача проверяет как технические навыки работы с SQL, так и внимательность к деталям формулировки задачи. Небрежная реализация может дать неверные результаты, особенно на больших данных. 🔥 Подсказки и намёки для решения задачи ## Задание 1: Найти пользователей с покупками без логина за последние 7 дней **Намёк:** - Используйте оконную функцию LAG() или MAX() с фильтрацией событий login. - Для каждой покупки проверяйте, был ли login в пределах 7 дней до события purchase. - Можно применить LEFT JOIN событий login к событиям purchase. ## Задание 2: Найти пользователей с долей ошибок > 30% **Намёк:** - Используйте оконные функции COUNT(*) и SUM(CASE WHEN event_type = 'error' THEN 1 ELSE 0 END). - Постройте долю ошибок на основе всех событий пользователя за последние 30 дней (`WHERE event_time >= CURRENT_DATE - INTERVAL '30 days'`). ## Задание 3: Рассчитать среднее время между login и следующим logout **Намёк:** - Используйте оконную функцию LEAD() для поиска следующего события после login. - Пара login -> logout должна иметь корректный порядок по времени. - Отбрасывайте случаи, где следующего logout нет или это событие другого типа. @sqlhub

⚡️Легкий способ получать свежие обновления и следить за трендами в разработке на вашем языке. Находите свой стек и подписывайтесь: Python: t.me/pythonl Linux: t.me/linuxacademiya Собеседования DS: t.me/machinelearning_interview Нерйросети t.me/ai_machinelearning_big_data C++ t.me/cpluspluc Docker: t.me/DevopsDocker Хакинг: t.me/linuxkalii Devops: t.me/DevOPSitsec Data Science: t.me/data_analysis_ml Javascript: t.me/javascriptv C#: t.me/csharp_ci Java: t.me/javatg Базы данных: t.me/sqlhub Python собеседования: t.me/python_job_interview Мобильная разработка: t.me/mobdevelop Golang: t.me/Golang_google React: t.me/react_tg Rust: t.me/rust_code ИИ: t.me/vistehno PHP: t.me/phpshka Android: t.me/android_its Frontend: t.me/front Big Data: t.me/bigdatai МАТЕМАТИКА: t.me/data_math Kubernets: t.me/kubernetc Разработка игр: https://t.me/gamedev Haskell: t.me/haskell_tg Физика: t.me/fizmat 💼 Папка с вакансиями: t.me/addlist/_zyy_jQ_QUsyM2Vi Папка Go разработчика: t.me/addlist/MUtJEeJSxeY2YTFi Папка Python разработчика: t.me/addlist/eEPya-HF6mkxMGIy Папка ML: https://t.me/addlist/2Ls-snqEeytkMDgy Папка FRONTEND: https://t.me/addlist/mzMMG3RPZhY2M2Iy 😆ИТ-Мемы: t.me/memes_prog 🇬🇧Английский: t.me/english_forprogrammers 🧠ИИ: t.me/vistehno 🎓954ГБ ОПЕНСОРС КУРСОВ: @courses 📕Ит-книги бесплатно: https://t.me/addlist/BkskQciUW_FhNjEy

✔️ Wal-listener — это инструмент для прослушивания логов транзакций PostgreSQL (WAL) и конвертации их в удобный для обработки
✔️ Wal-listener — это инструмент для прослушивания логов транзакций PostgreSQL (WAL) и конвертации их в удобный для обработки формат JSON. Возможности - Прослушивание изменений в PostgreSQL в режиме реального времени. - Поддержка нескольких слотов репликации. - Удобный вывод в формате JSON. - Готов к использованию в качестве сервиса. Пример использования 1. Создаём слот репликации:

   SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');
   
2. Запускаем wal-listener:

   wal-listener --dsn "host=localhost port=5432 user=postgres dbname=test" --slot test_slot
   
3. Получаем JSON-объекты при изменениях в базе данных. https://github.com/ihippik/wal-listener #devops #девопс #PostgreSQL #sql @sqlhub

Нашел лучший сайт для изучения SQL Хороший ресурс для освоения SQL — SQL Academy! Это интерактивная платформа с практическими заданиями от ведущих российских компаний: ВКонтакте, Альфа-Банка, Сбера и других. Здесь найдётся всё, что нужно разработчикам, аналитикам, тестировщикам и студентам, интересующимся базами данных.интересующихся студентов. Попробовать здесь @sqlhub