Слайдер Данные
171 subscribers
67 photos
11 videos
6 files
116 links
Это DuckDB+Polars в режиме Trino c OLAP кубами как надстройка для Excel | Р7 Офис

Объединяйте разные файлы и БД в один запрос и автоматизируйте сбор, трансформацию и аналитику.

Для связи
@datacons
https://data.slider-ai.ru
Download Telegram
Полезный ежегодный обзор баз данных в тексте Databases in 2025: A Year in Review от Andy Pavlov.
Всем кто работает с данными большого объёма будет полезно, вот ключевые выдержки:
1. Доминирование PostgreSQL продолжается. Многие экспериментируют со многими базами данных, но в продакшен всё равно используется PostgreSQL и совместимые с ним и его протоколом аналоги.
2. MCP для каждой СУБД. Похоже что тренд очевиден, MCP прикручивают к каждой СУБД каждый вендор и в этом нет ничего дурного. Больше универсальных интерфейсов полезных и нужных
3. MongoDB против FerretDB. MongoDB активно давит на FerretDB в том что воспроизведение их API и протокола нарушает их права. Такого в области баз данных ранее не было, самое близкое - это разборки Oracle vs Google из-за Java API. Тогда Oracle не удалось убедить суд в том что их права нарушены
4. Поле битвы форматов файлов. Активно идет появление новых стандартов и форматов дата файлов на замену Parquet. Я также не спроста писал про эту тему так часто, там идет сильная конкуренция и интересные технические решения

В оригинальном обзоре много ссылок и других событий
🤡1
🆕 Zhao Song начинает цикл статей о внутреннем устройстве MySQL и PostgreSQL

Чжао Сун запускает серию материалов, в которой на примерах конкретных механизмов показывает, как схожие задачи решаются в двух популярных СУБД. Первая часть посвящена буферному пулу — ключевому компоненту, отвечающему за кэширование данных в памяти.

В заметке детально разбираются:
🔹 Структура хеш-таблиц для поиска страниц
🔹 Алгоритмы вытеснения старых страниц (LRU с оптимизациями в MySQL и clock sweep в PostgreSQL)
🔹 Стратегии фоновой записи грязных страниц (Page Cleaner в MySQL против bgwriter и checkpointer в PostgreSQL)

Автор наглядно показывает, как теоретически одинаковые задачи приводят к разным инженерным решениям из-за выбранных компромиссов. Материал будет полезен всем, кто хочет глубже понять внутреннее устройство этих СУБД.

🔗 Читать: https://kernelmaker.github.io/mysql-vs-pg-bufferpool
Если PostgreSQL занимает важное место в вашей инфре, обратите внимание на новый экстеншен, который сделали в ClickHouse.

Каждый запрос PostgreSQL (SELECT, INSERT, DDL и даже запросы, завершившиеся с ошибкой) фиксируется как событие фиксированного размера с 45 полями: время выполнения, буферный I/O, статистика WAL, CPU, JIT, ошибки и клиентский контекст.

Дальше немного примитивной магии: кольцевой буфер, бэкграунд-стриминг в ClickHouse, и у вас готовая перфоманс-аналитика.

По ссылке прикольная внутрянка: https://lnkd.in/dcwy2g9z.
🤡2
немного здравого смысла от StarRocks 


Best Practice #1. Как выбирать Partition Key, сколько Buckets, и когда Colocate. Часть первая — Партиции

Когда создаешь таблицу в StarRocks, три решения определяют ~80% производительности: партиционирование, бакетирование и colocate group. Ошибся — и запросы начинают читать в десятки раз больше данных, чем нужно. Самое обидное, что часто незаметно, пока не заглянешь в EXPLAIN.

Зачем нужны партиции:
Партиция — это физическое разделение данных. Главная цель — partition pruning. Чтобы запрос с фильтром по ключу партиционирования (например, по времени) мог вообще не трогать старые куски данных. Пример: WHERE dt >= '2025-01-01' → не читаем партиции за 2024.

Какие стратегии (методы) партиционирования есть в StarRocks (OLAP):
🔹Expression partitioning (recommended) — партиции задаются выражением, а создаются и поддерживаются автоматически при загрузке данных.
🔹Range partitioning (Legacy) — классический RANGE, диапазоны задаются явно (VALUES LESS THAN ...), управление партициями чаще руками.
🔹List partitioning (Legacy) — LIST по перечисленным значениям (VALUES IN (...)).
С версии 3.4 StarRocks двигается к унификации вокруг expression-подхода и рекомендуют expression вместо range и list.

В документации отлично описаны лучшие практики по партиционированию (ссылки на документации ru, en). Вычленим только самые важные моменты.

Когда партиции НЕ нужны:
🔹Маленькие dimension/lookup таблицы → чаще проще не партиционировать, а ориентироваться на распределение/бакеты. Примеры таблиц: курсы валют, гео-справочники, таблицы для расшифровки кодов.
🔹Нет стабильного фильтра (например, почти никогда не фильтруете по времени/tenant/ключу данных) → pruning не будет, выигрыш сомнительный. Примеры таблиц: каталог товаров или единый реестр клиентов.

Выбор Partition Key:
1️⃣ Если ~80% запросов с фильтром по времени → начинай со времени: PARTITION BY date_trunc('day', dt)
2️⃣ Если нужна retention/TTL → ключ партиции должен совпадать с тем, по чему вы будете чистить данные.
3️⃣ Осторожно с составным ключом типа tenant_id × day: можно попасть в ситуацию, когда создастся большое число партиций (в документации советуют держать общее число в разумных пределах, иначе страдают FE-метаданные и компакшены).

Гранулярность:
DAY → большинство BI/reporting сценариев.
HOUR → IoT/высокая частота записи, изоляция горячих часов, но очень много партиций.
MONTH → исторические архивы, мало метаданных, но грубее pruning.
Правило: держите партицию не больше 100 GB, и не разгоняйте число таблетов на партицию.

Как проверить, что pruning реально работает:
EXPLAIN SELECT * FROM orders WHERE dt = '2025-06-15';

Ищите что-то вроде partitions=1/365 — читается одна партиция из 365.
Если видите partitions=365/365 — pruning не сработал.
🤡1
Худшие фейлы в DE

Наткнулась на тред в реддите, где обсуждались фейлы на работе. Мне больше всего зашли 2 истории, они такие смешные и страшные одновременно🤯

1️⃣Стриминг писал в то же самое место, откуда и читал. Это все длилось год, поэтому накопилось сотни триллионов миллиардов версий документов. Проблема обнаружилась, только когда к ним пришел AWS и пожаловался на проблемы в своих системах

Неужели за этот год они не заметили, как эти пайплайны работают все медленнее и медленнее, почему такая высокая нагрузка и что в таблицах кучи дублей?

2️⃣DE понизил уровень логирования до DEBUG, и это привело к расходам в 100к долларов за неделю

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

💰 Мы сейчас тоже переходим в эру FinOps. Будем пугать аналитиков, чтобы писали оптимальные запросы 😁

А у вас было что-то супер серьезное?

Ссылка на тред
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from MyDB
🧩 Краткая история «binlog-серверов» в экосистеме MySQL: от первопроходцев к современности

🕳️ Самый первый — MySQL с Blackhole
Обычный MySQL в топологии репликации с движком Blackhole: данные «испаряются», но бинарные логи генерируются и уходят дальше. Гениально просто, но на практике масса проблем:
— Лишние расходы на полноценный СУБД.
— Надо следить, что все таблицы используют Blackhole.
— В старых версиях параллельная репликация работала хуже (к 8.0+ проблема не относится).

👻 MySQL Ripple от Google (архивирован)
Проект 2019 года для разгрузки мастера и надёжного хранения binlog. Сейчас репозиторий в read-only и не поддерживается.

🚂 Kingbus от flike (заброшен)
Амбициозный проект на Go с raft-консенсусом, распределённое хранилище binlog, поддержка гео-репликации. Последние коммиты — 2019 год, разработка не ведётся.

🇨🇳 Canal от Alibaba
Зрелый инструмент для CDC (Change Data Capture): забирает binlog и отправляет в Kafka/RocketMQ и др. Ключевая особенность: ориентирован на китайскую аудиторию — документация на китайском, что создаёт барьер для международного сообщества.

🤔 Почему Percona начала свою реализацию?
1. Промышленная поддержка и понятный роадмап.
2. Облака «из коробки» (AWS S3 и S3-совместимые).
3. Универсальность: не только бэкапы и PITR, но и дешёвая замена промежуточному серверу в каскадной репликации (без проблем Blackhole).
4. Живая разработка: поддержка MySQL 8.0, 8.4, 9.x, CI/CD, REST API в планах.

🏁 Вывод
Эволюция: от «костыля» с Blackhole → экспериментальные Ripple и Kingbus → нишевый Canal. Percona строит универсальный инфраструктурный компонент для MySQL-сообщества: бэкапы binlog, PITR, разгрузка мастера и лёгкая замена промежуточному серверу.

Кстати, в экосистеме PostgreSQL аналогов binlog-сервера до сих пор не изобрели — там есть каскадная репликация и архивация WAL, но «сервера логов» для внешних потребителей тоже не хватает.

👉 Ссылки

▶️ Видео доклада: Binary Log Server - the missing MySQL infrastructure component (Yura Sorokin, Percona)
📄 Слайды доклада
📦 Percona Binary Log Server: GitHub
👻 MySQL Ripple: GitHub (архивирован)
🚂 Kingbus: GitHub (заброшен)
🇨🇳 Canal: GitHub
max_by/min_by

Узнала про прикольные функции, они заменяют оконку/CTE на одно поле

Пример - вывести имя сотрудника с максимальным стажем по каждому департаменту


result = df.groupBy("department").agg(
F.max_by("name", "years")
)


И все! Не надо никаких row_number = 1

В Spark SQL можно еще и фильтр набросить:


spark.sql("""
select
department,
max_by(name, years) filter (where name is not null)
from employees
group by department
""")


А в Trino еще можно собрать массив топ-n в убывающем порядке:


select
department,
max_by(name, years) AS top_employee,
max_by(name, years, 2) AS top_2_employees
from employees
group by department


Аналог в ClickHouse - argMax

@data_engineerette
⁉️Зачем мне эта ваша математика?

«Я в аналитику пришел из Excel, зачем мне эта высшая математика: интегралы, пределы, производные и логарифмы?» - частый вопрос новичков, которые меняют сферу деятельности, давайте разбираться на пальцах и реальных задачах.

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

💡Логарифмы: нужны там, где всё растет слишком быстро
Где встречаются: зарплаты, цены на недвижимость, посещаемость сайта, время в приложении.
Суть: в реальности многие процессы растут не линейно, а экспоненциально, когда вы строите график с огромным разбросом значений, мелкие детали теряются.
Задача: У вас есть 1000 пользователей, которые платят от 100 до 1 000 000 рублей. Если построить обычный график, то 90% людей сгрудятся в одной точке у нуля, и ничего не увидеть.
💡 Решение: Берем логарифм от суммы платежа (log1p в Pandas) и сразу видим распределение: богатые клиенты перестают «зашкаливать», бедные становятся видны. Логарифмическая шкала - это базовая вещь в EDA (разведочном анализе данных).


💡Производные: скорость изменений
Где встречаются: маркетинговые кампании, AB тесты, анализ динамики.
Суть: производная в переводе с математического - это «скорость изменения функции», в аналитике мы постоянно считаем приросты и темпы роста.
Задача: Вы запустили рекламу. Выручка выросла на 10% за месяц. Это круто? А если в прошлом месяце был рост 30%, а в этом всего 10% - это уже проблема. Тут мы смотрим не только на абсолютные значения, но и на их производные.
💡 Решение: Производная в коде - это просто разница между сегодня и вчера, деленная на вчера (pandas .diff() / .shift()). Но понимание, что вы считаете скорость, помогает не тупить и правильно интерпретировать результаты.


💡Пределы и асимптоты: потолок роста
Где встречаются: прогнозирование, оценка насыщения рынка, когортный анализ, предел показывает, к чему стремится процесс, но чего никогда не достигнет.
Задача: Вы считаете Retention (возвращаемость пользователей). Она падает и стабилизируется где-то около 20%. Это и есть предел - точка насыщения, дальше удерживать пользователей можно только качественными изменениями продукта.
💡 Решение: Понимание пределов помогает не строить иллюзий. Если retention уже вышел на плато - никакие скидки и пуш-уведомления не поднимут его выше математического предела.


💡Интегралы: накопленный итог
Где встречаются: LTV (клиентская ценность), когортный анализ, расчеты запасов.
Суть: Интеграл - это площадь под графиком, в аналитике это «накопленный итог» или «суммарный эффект».
Задача: Вы запустили акцию, продажи скачут: сегодня 100, завтра 200, послезавтра 50, чтобы оценить реальный эффект акции, нужно посчитать интеграл - то есть сумму всех продаж за период.
💡 Решение: В SQL это SUM() OVER(ORDER BY date), в математике это называется «определенный интеграл». Когда вы считаете LTV клиента за 12 месяцев, то вы берете интеграл от его платежей по времени.

Коротко и на пальцах:
Если вы умеете в уме переключаться между этими понятиями, вы:
✔️ Не путаете % роста и абсолютный прирост;
✔️ Понимаете, почему логирифмировать распределение зарплат - это ок;
✔️ Можете объяснить бизнесу, почему дальше расти некуда (упретесь в предел);
✔️ Правильно считаете LTV и Retention;

Никто не просит вас брать интегралы в уме или рисовать графики производных от руки, но понимать, что стоит за функциями .log(), .diff() и .cumsum() в Pandas - must have для каждого осознанного аналитика.

А как у вас с математикой?
В комментарии добавлю подборку книг по математике для анализа данных (подходят для разных уровней)🫴.

#аналитика
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Forwarded from MyDB
🐳 MySQL 9.6.0: Глубокая интеграция с контейнерами

Релиз MySQL 9.6.0 (конец января) принес важное улучшение для тех, кто использует контейнеризацию. Появилась серверная переменная container_aware.

Суть изменений:

Ранее MySQL уже умел определять объемы доступной памяти и ядер CPU и использовать эти значения для автоматической подстройки собственных лимитов. Теперь поведение этого кода зависит от нового флага:

🔹 container_aware = ON: Сервер проверяет, запущен ли он в контейнере (cgroup). Если да — он учитывает лимиты контейнера при выделении памяти и настройке всех ресурсозависимых параметров: размер innodb_buffer_pool_size, лимиты для in-memory временных таблиц ( temptable_max_ram ), количество потоков InnoDB ( innodb_read_io_threads, innodb_purge_threads, parallel_read_threads ) и другие. Если лимиты не найдены или сервер запущен не в контейнере — выход с ошибкой.

🔹 container_aware = OFF (по умолчанию): Режим совместимости с предыдущими версиями — сервер игнорирует контейнер и смотрит на ресурсы хоста. При этом в лог пишется предупреждение, если MySQL обнаруживает, что работает в контейнере с ограничениями.

Зачем это нужно: Долгожданная фича для корректной работы MySQL в оркестрации (Kubernetes и т.д.). Позволяет избежать ситуации, когда база данных внутри контейнера думает, что у нее 64 ядра и 512 ГБ RAM, хотя реально выделено только 2 ядра и 4 ГБ. Больше никаких неожиданных OOM и неоптимальных настроек!

Что дальше? В MySQL проведена многолетняя подготовительная работа: большинство серверных параметров уже давно меняются на лету без перезагрузки сервера. Логичным следующим шагом было бы научить MySQL не только учитывать лимиты при старте, но и отслеживать их изменения "на лету". В динамических средах (например, Kubernetes с вертикальным автомасштабированием) лимиты контейнера могут меняться без перезапуска пода — и тогда MySQL мог бы динамически подстраивать buffer_pool_size или количество рабочих потоков без даунтайма.
Forwarded from Visiology Official
Российский BI-рынок в 2025 году: кто 💪 усиливается и почему это важно

Вчера в прямом эфире управляющий партнер Visiology Иван Вахмянин представил исследование «Пульс BI 2026: анализ Business Intelligence в России».

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


По итогам вебинара мы подготовили для вас ключевые выводы в формате карточек. Листайте, чтобы почувствовать пульс BI 🟡

Для тех, кто хочет погрузиться глубже, мы уже загрузили запись эфира на наши площадки VK Видео | Rutube | YouTube

Visiology в мессенджере MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Media is too big
VIEW IN TELEGRAM
Быстрый старт со Слайдер Данные - импорт модели AdventureWorks

Триальный дистрибутив
Forwarded from Клуб CDO
Дайджест статей

📰: Путь в аналитику данных: базовый минимум для старта
Ссылка: https://habr.com/ru/articles/1003704/
Вывод одной строкой: Для успешного входа в аналитику данных необходимо освоить SQL, Python/R, основы статистики и визуализации данных, а также развивать навыки работы с бизнес-задачами и критического мышления, постепенно наращивая экспертизу через практические проекты и непрерывное обучение.


📰: BI-аналитик: стартовый пакет необходимых навыков
Ссылка: https://habr.com/ru/articles/1004298/
Вывод одной строкой: Для успешной работы BI-аналитиком необходимо освоить SQL для работы с базами данных, инструменты визуализации данных (Tableau, Power BI), основы статистики и аналитического мышления, а также развить навыки коммуникации для эффективного представления результатов анализа бизнес-заказчикам.


📰: Как мы улучшили рекомендации для пользователей Авито с помощью трансформенной персонализации
Ссылка: https://habr.com/ru/companies/avito/articles/1004694/
Вывод одной строкой: Трансформерная архитектура с механизмом внимания позволяет значительно повысить качество рекомендательных систем за счет более точного моделирования последовательности действий пользователя и учета долгосрочных зависимостей в его поведении.


📰: Data Mesh, Data Fabric, Lakehouse: разбираем модные термины
Ссылка: https://habr.com/ru/articles/1005062/
Вывод одной строкой: Современные архитектурные подходы Data Mesh, Data Fabric и Lakehouse решают разные задачи управления данными: децентрализацию и демократизацию доступа, интеллектуальную интеграцию разрозненных источников и унификацию аналитических и транзакционных нагрузок соответственно, поэтому выбор конкретного решения должен основываться на организационной структуре компании, существующей инфраструктуре и бизнес-целях.


📰: Data catalog есть, а пользы нет: Частые ошибки внедрения
Ссылка: https://habr.com/ru/articles/1003158/
Вывод одной строкой: Успешное внедрение каталога данных требует не только технической реализации, но и активного вовлечения пользователей, четкого определения процессов управления метаданными и постоянной поддержки культуры работы с данными в организации.