Data Science: SQL и Аналитика данных
35.4K subscribers
292 photos
60 videos
1 file
350 links
№ 6205468675

На простом языке: про работу с данными, современные технологии, AI, машинное обучение и, немного, SQL.

Сотрудничество: @niktwix

Менеджер: @Spiral_Yuri
Download Telegram
➡️ Используй EXISTS вместо IN на больших таблицах

-- медленнее
SELECT *
FROM orders o
WHERE o.user_id IN (SELECT id FROM users WHERE active = tr
ue);

-- быстрее
SELECT *
FROM orders o
WHERE EXISTS (
SELECT 1
FROM users u
WHERE u.id = o.user_id AND u.active = true
);


EXISTS останавливается на первом совпадении и не тянет весь подзапрос в память. На больших данных разница может быть кратной.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥 Продвинутый SQL-прием: partial index вместо “универсального” индекса

Если в таблице много строк, но запрос почти всегда смотрит только активные записи, не обязательно индексировать всё.

Например, есть таблица заказов:


SELECT *
FROM orders
WHERE user_id = 42
AND status = 'active';



Обычный индекс:


CREATE INDEX idx_orders_user_status
ON orders(user_id, status);



Работает, но он хранит данные по всем статусам: active, cancelled, archived, failed и так далее.

Если чаще всего нужны только активные заказы, можно сделать partial index:


CREATE INDEX idx_orders_active_user
ON orders(user_id)
WHERE status = 'active';



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


SELECT *
FROM orders
WHERE user_id = 42
AND status = 'active';



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

Особенно полезно для флагов вроде deleted_at IS NULL, status = 'active', is_published = true, processed = false.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
🔥Логическая аналитика с LynxDB

LynxDB — это легковесная система для анализа логов, работающая в одном бинарном файле без зависимостей. Она использует язык запросов Lynx Flow, позволяющий легко обрабатывать данные в виде конвейера.

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

⏺️ Пайплайн-запросы для обработки данных
⏺️ Полнотекстовый поиск и колоночное хранилище
⏺️ Поддержка кластерного режима и материализованных представлений
⏺️ Никакой конфигурации — разумные настройки по умолчанию
⏺️Активная разработка, обратная связь приветствуется

➡️ GitHub: https://github.com/lynxbase/lynxdb

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
Хотите внедрить ИИ в компании? Не начинайте с выбора модели.

Иначе есть риск потратить бюджет, а получить красивые, но бесполезные ответы.

Причина большинства неудачных AI-проектов — не технологии. Проблема в данных: они разрознены, устарели, хранятся в 1С, CRM, Excel и десятках других систем.

На бесплатном вебинаре разберем, как подготовить данные, чтобы корпоративный ИИ действительно помогал бизнесу, а не генерировал «галлюцинации».

Расскажем:
✔️ почему данные важнее модели;
✔️ как автоматизировать получение данных из 1С;
✔️ зачем компании DWH и единый слой корпоративных знаний;
✔️ как выглядит рабочая AI-ready архитектура на реальном примере.

🎁 Всем зарегистрированным — запись вебинара, презентация спикеров, материалы по архитектуре AI-ready и возможность задать вопросы экспертам.

📅 12 августа | 11:00 (МСК)
💻 Онлайн, участие бесплатное.

👉 Зарегистрируйтесь сейчас и узнайте, с чего действительно стоит начинать внедрение корпоративного ИИ.
🔥 Constella: локальная память для файлов, заметок и AI-агентов

Constella — open-source desktop-приложение, которое индексирует локальные файлы и превращает их в единую базу знаний для поиска и AI-агентов.

Данные хранятся на устройстве: LanceDB используется для векторов, SQLite — для метаданных и knowledge graph.

Что умеет:

⏺️ индексировать Obsidian, Documents, Downloads и любые выбранные папки;
⏺️ извлекать текст из PDF, DOCX, Markdown и изображений;
⏺️ строить семантический поиск по локальным данным;
⏺️ автоматически связывать заметки, темы и концепты;
⏺️ работать с локальными и облачными LLM;
⏺️ отдавать базу знаний через MCP в Claude Code;
⏺️ использовать агентов и переиспользуемые workflows.

Схема примерно такая:


Файлы

chunks + embeddings

LanceDB + SQLite

Knowledge Graph

поиск / агенты / MCP


➡️ https://github.com/Constella-OS/constella-desktop

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥Редкий и реально продвинутый SQL-совет: используй логарифмы для произведения вероятностей.

В SQL удобно считать SUM, AVG, COUNT, но почти никто не думает про PRODUCT. А в аналитике он часто нужен: вероятность цепочки событий, retention funnel, скоринговые модели, reliability, ML-фичи.

Проблема: если перемножать много маленьких чисел, например 0.97 * 0.91 * 0.88 * ..., быстро получишь underflow или потерю точности.

Математический трюк:


a * b * c = exp(ln(a) + ln(b) + ln(c))

То есть вместо прямого произведения считаем сумму логарифмов.


SELECT
user_id,
EXP(SUM(LN(probability))) AS total_probability
FROM events
WHERE probability > 0
GROUP BY user_id;


Где это полезно:


SELECT
user_id,
EXP(SUM(LN(conversion_rate))) AS funnel_survival_rate
FROM funnel_steps
GROUP BY user_id;



Это стандартный численный прием из математики, который делает расчет стабильнее.

Особенно полезно, когда у тебя много шагов в воронке, вероятностная модель, риск-скоринг или аналитика событий.

Главное правило: LN(x) работает только для x > 0, поэтому нули нужно обрабатывать отдельно. Например, если хотя бы одна вероятность равна нулю, итоговое произведение тоже будет ноль.


🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥 SQL-совет: `LATERAL` вместо тяжёлого оконного запроса

Нужно получить последнюю операцию каждого пользователя? В PostgreSQL можно не ранжировать всю таблицу через ROW_NUMBER().


SELECT
u.id,
last_order.id,
last_order.created_at
FROM users AS u
LEFT JOIN LATERAL (
SELECT id, created_at
FROM orders
WHERE user_id = u.id
ORDER BY created_at DESC
LIMIT 1
) AS last_order ON true;



LATERAL запускает подзапрос отдельно для каждой строки слева и разрешает обращаться к u.id.

Добавьте индекс:

CREATE INDEX ON orders (user_id, created_at DESC);

Тогда PostgreSQL сможет брать последнюю запись прямо из индекса, не сортируя все заказы пользователя.

Такой приём особенно полезен для задач:

⏺️ последняя операция пользователя;
⏺️ актуальный статус заказа;
⏺️ последнее событие устройства;
⏺️ последние N записей для каждой группы.

Для больших таблиц это часто быстрее и проще, чем оконная функция по всему набору данных.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
➡️ Neo4j без сервера: GraphForge запускает полноценный Cypher прямо внутри Python-скрипта

GraphForge занимает редкую нишу между NetworkX и серверными графовыми БД. Вы получаете встроенный графовый движок на Rust, полный openCypher и хранение проекта в обычной директории.

Что внутри:

⏺️ четыре независимых слоя на Rust: parser → IR → planning → execution;
⏺️ результаты сразу возвращаются как Apache Arrow Table;
⏺️ данные легко передаются в Pandas и Polars;
⏺️ постоянное хранение построено на Parquet;
⏺️ встроены PageRank, Louvain и гибридный текстово-векторный поиск;
⏺️ Python- и Node.js-биндинги работают поверх одного движка.


from graphforge import GraphForge

graph = GraphForge("research/")

result = graph.execute("""
MATCH (a)-[:CITES]->(b)
RETURN a.title, b.title
""")

print(result.to_pandas())



При этом GraphForge честно позиционируется как инструмент исследовательского и notebook-масштаба. Для миллиардных графов, высокой нагрузки и многопользовательского доступа по-прежнему нужна серверная БД.

Python и Node.js доступны сейчас, Swift и Kotlin находятся в планах. Лицензия — Apache 2.0.

https://github.com/CurateLabs/graphforge

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
Как выгодно сдавать анализы? 🧪

Не все знают, что в ИНВИТРО есть простой способ получать бонусы и потом оплачивать ими анализы и исследования до 90%! Ниже 4 лайфхака:

Во-первых. После регистрации в программе лояльности вам начислят 500 бонусов, а в день рождения – ещё 2000 бонусов.

Во-вторых. За анализы после активации начисляют кешбэк 5%. И его можно увеличить – в личном кабинете выбрать до 3 отдельных услуг и получать по ним до 10% бонусами.

В-третьих. Можно также выбрать готовый пакет и получать до 15% бонусами на анализы, которые в него входят. Например, есть «Контроль над весом», «Здоровый желудок» и др. Выбранный пакет можно заменить через 30 дней.

Самое крутое – накопленными бонусами можно оплатить до 90% стоимости следующих услуг. Например, если анализы вышли на 10 000₸, то бонусами можно списать 9000!


В-четвёртых. Подойдите к администратору на кассе и скажите ИНВИТРО26. После этого вам сделают скидку 20% на первую оплату. Работает во всех городах до 15 сентября 2026 года.

Подключить повышенный кешбэк можно 👉 на сайте. Нужно авторизоваться и открыть в личном кабинете раздел «Программа лояльности». 1 бонус = 1₸.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥 В SQLite есть кусок кода, который выглядит «грязно», но оставлен таким специально ради скорости.

Каждый SQL-запрос SQLite сначала компилируется в байткод, а затем выполняется собственной виртуальной машиной VDBE.

Внутри — большой цикл диспетчеризации с почти 200 opcode.

И вот интересный момент: SQLite использует обычные goto, чтобы быстро прыгать между общими ветками выполнения.

➡️ В исходниках прямо написано:

«Код использует неструктурированные goto и выглядит не очень чисто. Но это сделано не из-за плохого стиля, так быстрее».

По замерам разработчиков, такой подход ускоряет sqlite3_step() примерно на 1,5%.

То есть здесь читаемость сознательно пожертвовали ради производительности.

Хорошее напоминание: в системном коде «красивее» не всегда значит «быстрее».

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
➡️ Как SQLite выжимает скорость: байткод, VM и goto

Некрасивый код, который делает SQLite быстрым

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX
Please open Telegram to view this post
VIEW IN TELEGRAM