Слайдер Данные
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
В Spark 4.1 появлся ... Airflow

В документации версии Spark 4.1-Preview появились так называемые Spark Declarative Pipelines (SDP)

На борту:

1️⃣ Несколько видов датасетов: Материализованные, Стриминговые, Временные
2️⃣ Пайплайн как объект. Описывается через YAML файл с SQL, Python кодом и необходимыми конфигами Спарка. Также объявляется каталог (Hive, Iceberg), с которым можно взаимодействовать и в который складывать результаты.
3️⃣ Команда spark-pipelines init с интерфейлом и аргементами как у Spark Submit. Отдельная команда spark-pipelines run.


Удобство

Пример нового кода на PySpark, который читает Kafka топик и складывает данные в таблицу в каталоге. По сути это декларативное описание (не как-сделать, а что-сделать) а-ля DAG.

from pyspark import pipelines as sdp

@sdp.table
def ingestion_st():
return (
spark.readStream.format("kafka")
.option("kafka.bootstrap.servers", "localhost:9092")
.option("subscribe", "orders")
.load()
)


К объявленной таким способом таблице можно обращаться дальше по пайплайну.

На SQL и того проще

CREATE STREAMING TABLE basic_st
AS SELECT * FROM STREAM samples.nyctaxi.trips;



Или пример с несколькими синками

-- create a streaming table
CREATE STREAMING TABLE customers_us;

-- add the first append flow
CREATE FLOW append1
AS INSERT INTO customers_us
SELECT * FROM STREAM(customers_us_west);

-- add the second append flow
CREATE FLOW append2
AS INSERT INTO customers_us
SELECT * FROM STREAM(customers_us_east);


Осталось разобраться, как в этом всем провязаны семантики доставки (exactly-once, at-least-once), и куда это все полетит при смене схемы источника (Dead Letter). И понять, как устроить мониторинги и алерты работающих или сломавшихся пайплайнов.

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

Насладиться примерами можно в офф доке превью версии
Please open Telegram to view this post
VIEW IN TELEGRAM
Ехал метастор через метастор, видит метастор в метасторе метастор...

Одни очень большие ребята рассказали, что активно смотрят на Apache Gravitino. Плохого же не посоветуют, вот и я решил посмотреть.

А получается у нас на руках каталог каталогов, через который можно управлять метаданными во всем своем зоопарке. Имея на руках HDFS+Spark, StarRocks, Vertica (jdbc) и MySQL, можно из одного места раскатывать миграшки, управлять доступами и даже работать (если есть коннектор). Интересно как реализован линейдж, но мне кажется, что это не совсем тема каталога.

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

Подумал, что можно наконец выкинуть из стека Apache Ranger, но нет - это только прослойка для него.

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

Видите пльзу для себя, затеялись бы внедрять? :)
deruiter_Astronomer_Final.pdf
28 MB
Data Pipelines with Apache Airflow
Orchestration for Data and AI Second Edition 2026

Второе издание (скачено с сайта astronomer бесплатно)
😁1
Монументальная статья от Cedrus Data про движок DataFusion, но не в Спарке, как Comet, а в Trino. Их движок на Rust назван Oxide.

Утянул главный спойлер - Тест производительности.

Но вы прочитайте всю статью, там интересно.
Forwarded from MyDB
🔥 Alibaba представила open-source интеграцию DuckDB — AP-движок для аналитических запросов прямо в MySQL

Крупнейший китайский облачный вендор Alibaba открыл исходный код глубокой интеграции аналитической СУБД DuckDB в AliSQL (форк MySQL). Это позволяет запускать аналитические запросы (OLAP) в тысячи раз быстрее, чем на InnoDB, с полным сохранением MySQL-синтаксиса.

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

🛠 Как это работает:

DuckDB встроен как плагинный storage-движок в архитектуру MySQL. Аналитические реплики синхронизируются через бинарный лог (binlog), что обеспечивает согласованность данных и отказоустойчивость. Под капотом реализованы оптимизации:
- Пакетное выполнение транзакций
- Поддержка DDL через INPLACE / INSTANT или COPY - механизмы
- Многопоточная конвертация таблиц

📊 Производительность:

На тестах TPC-H SF100 DuckDB показал впечатляющие результаты — общее время выполнения 22 запросов:
DuckDB: 15.31 сек (в 1648 раз быстрее!)
InnoDB: 25 234.31 сек

🌐 Исходный код и документация:

Решение полностью открыто и доступно в репозитории AliSQL. Сообщество может изучать, использовать и развивать эту интеграцию.

👉 Репозиторий и подробная документация

#OpenSource #AliSQL #DuckDB #MySQL #OLAP #Database #Analytics #Alibaba #GitHub
Forwarded from LEFT JOIN
СУБД made in China
Пополнение в копилку необычных СУБД — AliSQL от Alibaba Group, которая владеет известным китайским маркетплейсом. Это форк от MySQL со всевозможными улучшениями производительности и стабильности. Полный список поддерживаемых фич в официальной документации выглядит очень внушительно.

🔵На Githab отдельно подсветили то, что AliSQL использует аналитическую DuckDB в качестве подсистемы хранения и поддерживает векторный поиск. За счет этого подходит для аналитических задач и работы с ИИ.
🔵В роадмапе — оптимизация DDL, RTP и репликации.

В Alibaba Group AliSQL использовали для своих внутренних нужд, но в конце 2025 поделились исходным кодом. Так что вы можете стать контрибьютором или просто потестить, как она работает.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from MyDB
🚀 Новые игроки в мире storage-движков для MySQL и MariaDB

В конце прошлого года на сцене storage-движков для MySQL и MariaDB появились новые претенденты: TideDB и его SQL-оболочка TideSQL.

🔍 Что это такое?
Это полностью самостоятельная реализация LSM-дерева, созданная с нуля. TideDB не является форком или модификацией RocksDB, а представляет собой независимый проект, цель которого — предложить альтернативную, более эффективную архитектуру хранения данных.

Ключевые отличия от RocksDB и MyRocks
Главное архитектурное преимущество TideDB — его оптимизация для работы в режиме строгой гарантированной записи (sync), где каждая операция подтверждается сбросом на диск. В этом сценарии он показывает значительный прирост:
Случайная запись: производительность на 22% выше, чем у актуальной версии RocksDB.
Эффективность хранения: использование дискового пространства в 10+ раз ниже за счет глубокой переработки процессов компрессии.
Работа с «горячими» данными: скорость итераций по ключам с неравномерным распределением (Zipfian) в 6 раз выше.

📊 Текущий статус
RocksDB/MyRocks — это устоявшийся промышленный стандарт с огромной экосистемой, интеграцией в MySQL (MyRocks) и проверенной надёжностью. RocksDB — эталонный встраиваемый key-value storage на основе LSM-дерева. Его сила — высокая производительность на быстрых накопителях (SSD) и гибкость. Он стал основой для многих распределенных баз данных.
TideDB/TideSQL — это свежий, амбициозный проект, который предлагает лучшую производительность в специфических, но критически важных сценариях. Это потенциальный выбор для систем, где предельно важны задержки гарантированной записи и плотность хранения данных.

🔗 Ссылки
• Официальный сайт проекта с описанием, документацией и последними релизами: tidesdb.com
Бенчмарки от разработчиков, сравнивающие производительность TidesDB, RocksDB и LMDB: ссылка на статью
Бенчмарк TideSQL против InnoDB в MariaDBMariaDB: Benchmark Analysis on TideSQL v1.0.0 & InnoDB
Forwarded from LEFT JOIN
Нестандартные способы оптимизировать PostgreSQL
Стандартные вы и так знаете — переписать запросы, добавить индексы, пройтись по базе VACUUM’ом. Но есть и менее очевидные подходы, которые могут дать прирост производительности. Принесли вам шпаргалку с 3 такими приемами (с примерами), которые особенно пригодятся в аналитике.

У автора все написано подробно, ниже — главное, чтобы понять, стоит ли читать целиком.

1️⃣Использовать constraint_exclusion, чтобы PostgreSQL не читал всю таблицу, если запрос заведомо не может вернуть данные.
Допустим, у вас есть столбец, в котором указан тарифный план, на который подписан каждый пользователь — free или pro. Если аналитик опечатается в запросе и напишет SELECT * FROM users WHERE plan = 'Pro', то он получит 0 результатов, но PostreSQL все равно старательно пройдется по всей таблице и потратит время. Чтобы он так не делал, нужно настроить параметр constraint_exclusion, чтобы он не пропускал такие запросы.

2️⃣ Создавать функциональные индексы.
Например, если у вас есть данные о дате и времени, когда была совершена продажа. Если в компании дела идут хорошо, то продаж будет много, а значит надо это дело как-то оптимизировать.

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

3️⃣ Использовать хеш-индексы для длинных строк.
Если нужно хранить уникальные длинные строки (например, URL), обычный индекс может разрастись до неприличных размеров. В таком случае можно использовать хеш-индекс, который хранит не сами значения, а короткие хеш-значения.
Please open Telegram to view this post
VIEW IN TELEGRAM
🌭1
Forwarded from MyDB
🚨 Исправлена извечная проблема MySQL! В выпущенном 9.6 внешние ключи стали «видимыми» и полноправными.

MySQL 9.6, релиз которого состоялся в конце января, устраняет давний архитектурный недостаток: каскадные операции внешних ключей ( ON DELETE/UPDATE CASCADE ) теперь выполняются на уровне SQL-движка, а не скрытно внутри InnoDB.

Чем это было плохо раньше? Было две ключевые проблемы:
🔴 Скрытые изменения: Каскадные удаления/обновления не попадали в бинарные логи. Это приводило к расхождению данных в гетерогенных средах (например, если на репликах использовались движки, отличные от InnoDB). Системы CDC и аналитики теряли часть данных.
🔴 Триггеры не работали: Триггеры, созданные на дочерних таблицах, не вызывались при каскадных операциях, так как они происходили в обход SQL-слоя. Это ломало бизнес-логику приложений.

Что изменилось в MySQL 9.6:
Полная видимость: Все каскадные изменения теперь видны, логируются и точно реплицируются, в том числе в гетерогенных топологиях.
Надежность: Триггеры будут отрабатывать корректно (это следующий шаг на roadmap).
Безопасное обновление: Для плавного перехода введена переменная innodb_native_foreign_keys. По умолчанию она имеет значение FALSE (новое поведение), но её можно установить в TRUE, чтобы временно вернуть старое поведение InnoDB. Обратите внимание, что эта переменная считается устаревшей с момента выпуска и будет удалена в будущем.
Основа для будущего: Поддержка FK в других движках и новые возможности.
Без потерь в скорости: Производительность осталась на уровне прежней реализации.

Это долгожданное и фундаментальное улучшение для всех, кто строит отказоустойчивые и согласованные системы на MySQL.

👉 Подробный разбор от инженера Oracle: https://blogs.oracle.com/mysql/no-more-hidden-changes-how-mysql-9-6-transforms-foreign-key-management
Forwarded from MyDB
🎭 «В Computer Science есть только две сложные вещи: инвалидация кэша, придумывание имён и ошибки на единицу.»

Благодаря ReadySet теперь можно беспокоиться только о придумывании имён.

🧠 Это не очередной Redis. Это технология, которая переворачивает то, как мы кэшируем SQL

ReadySet — проект с корнями в MIT CSAIL (докторская Аланы Марзоев, соавтора Noria). Вместо того чтобы мучиться с TTL, писать костыли для инвалидации или сносить кэш целиком при каждом UPDATE, ReadySet делает гениально простую вещь: подключается к репликационному стриму MySQL и обновляет кэшированные результаты запросов построчно, инкрементально, в реальном времени.

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

🐬 MySQL — родная стихия ReadySet

Хотя формально поддерживается и PostgreSQL, именно с MySQL ReadySet раскрывается полностью: binlog, снапшоты, мгновенное отслеживание изменений. Это не обёртка, а полноценный SQL-прокси, который понимает JOIN'ы, GROUP BY и подзапросы, превращая их в миллисекундные lookup'ы без единой строки кода в приложении.

📊 Независимые бенчмарки подтверждают: ReadySet с MySQL — это другой порядок чисел

Тест 1. AWS RDS MySQL + ReadySet (март 2025)
Рональд Брэдфорд, эксперт по MySQL и экс-консультант MySQL AB, провёл серию тестов с реальной базой IMDb (20 ГБ в InnoDB). Результаты говорят сами за себя:

- Транзакции в секунду: RDS MySQL (8 vCPU) — 5.2k, ReadySet (4 vCPU) — 17.2k (рост в 3.3 раза)
- Среднее время отклика: RDS — 12.2 мс, ReadySet — 0.93 мс (ускорение в 13 раз)
- Время отклика (95-й перцентиль): RDS — 21.9 мс, ReadySet — 1.3 мс (ускорение в 17 раз)
- При 16 потоках на 8 vCPU ReadySet выдал 19.5k транзакций/сек (3.75×) со средним временем отклика 0.82 мс (15×)

Тест 2. Вертикальное масштабирование против горизонтального с ReadySet
Инженеры ReadySet сравнили апгрейд инстанса MySQL с добавлением кэширующего слоя:

- Вертикальное масштабирование: удвоение ресурсов (t2.2xlarge за $134.61/мес) → +14% QPS
- ReadySet: базовый MySQL (t2.xlarge) + ReadySet на t2.medium ($84.17/мес) → +250% QPS
- Cost efficiency: стоимость за 1 QPS у ReadySet — $0.036, у вертикального масштабирования — $0.128 (ReadySet в 3.6 раза эффективнее)

Тест 3. perf stat: холодный кэш, тёплый кэш, ReadySet
Детальный анализ на уровне CPU и системных вызовов:

- Холодный кэш (диск): 10.44 сек, 181M циклов CPU
- Тёплый кэш (InnoDB): 5.40 сек, 149M циклов
- ReadySet: 0.12 сек, 113M циклов — ускорение в 45 раз против тёплого кэша, 43% меньше инструкций CPU

🇷🇺 Но вот что удивительно: в российском IT про ReadySet почти никто не знает

На «Хабре» — ноль публикаций. Ноль обзоров, ноль кейсов, даже переводов нет. При том что технология существует с 2021 года.

Видимо, все слишком заняты выбором между Redis, KeyDB, Dragonfly и Valkey — и сравнением их TTL-стратегий в сорок восьмой раз.

📚 Что почитать:

1. AWS RDS MySQL + ReadySet: независимый бенчмарк (март 2025)
Рональд Брэдфорд, эксперт по MySQL, детально разбирает нагрузочное тестирование с IMDb dataset. Цифры, графики, воспроизводимый код.

2. Вертикальное масштабирование MySQL vs горизонтальное с ReadySet
Сравнение T2.xlarge → T2.2xlarge против добавления ReadySet. Стоимость, QPS, ROI.

3. Когда оптимизации запросов уже недостаточно: MySQL под нагрузкой
Глубокий системный анализ с perf stat: холодный диск, InnoDB Buffer Pool, ReadySet.

4. InfoQ — доклад CEO ReadySet «Улучшение пользовательского опыта с помощью потоковой обработки данных»
Глубочайший разбор того, как работают dataflow-графы и почему частичная материализация убивает проблему инвалидации на корню.

5. GitHub репозиторий
9.7к коммитов, Rust, активный контрибьютинг, BSL-лицензия с конвертацией в Apache 2.0.
🔥2😁1
🐬 Новая эра MySQL: Oracle открывает коммерческие функции для сообщества

Друзья, отличные новости пришли из блога Oracle MySQL. Отметив в прошлом году 30-летний юбилей проекта, компания анонсировала кардинальные изменения в стратегии взаимодействия с сообществом.

Главное из анонса:
🚀 Функции Enterprise-версии переходят в Community Edition. Ранее платные возможности теперь будут доступны всем. Уже реализован перенос обработки внешних ключей из InnoDB в SQL-движок, о котором мы рассказывал совсем недавно.

🛠 Прозрачность и Roadmap. Oracle обещает публиковать дорожную карту развития, проводить вебинары с командой разработки и продуктовыми менеджерами, а также принимать Worklog'и от сообщества.

🔮 Что ждет в ближайших релизах (к апрелю 2026):
*   Векторные функции для AI (косинусное сходство, евклидово расстояние)
*   PGO-оптимизированные сборки Community Edition
*   Гиперграфовый оптимизатор запросов
*   Поддержка OpenTelemetry для observability
*   Улучшения в многопоточной репликации
*   Продвинутая HA/DR аналитика
*   Улучшения для JSON duality views – достаточно интересной функции, о которой мы скоро обязательно расскажем

Это лишь то, что запланировано к апрелю 2026 года. У Oracle уже есть и дальнейшие планы по развитию MySQL Community Edition – о них обещают объявить дополнительно.

Это действительно важный шаг для MySQL. Подробности и комментарии community-менеджера — в официальном блоге.

👉 Читать полностью: https://blogs.oracle.com/mysql/new-era-of-mysql-community-engagement
👉 Видео-ролик, посвящённый 30-летию MySQL: https://www.youtube.com/watch?v=SqbV2JjnbhA
Полезный ежегодный обзор баз данных в тексте 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