⚡️MySQL 9.7.0 (LTS): Oracle начинает выполнять обещания

21 апреля вышел официальный релиз MySQL 9.7.0 Long Term Support (LTS), и это именно тот случай, когда стоит сказать: Oracle начинает выполнять обещания, о которых мы писали ранее. Ранее эта функциональность была доступна лишь в предварительных сборках, а теперь стала общедоступной в стабильной LTS-ветке.

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

1. Репликация и наблюдаемость (Observability)
* Replication Applier Metrics Component. Расширенная статистика по многопоточному апплаеру: теперь доступны детальные метрики по лагу, пропускной способности и состоянию очередей воркеров.
* Group Replication Flow Control Statistics Component. Мониторинг механизмов контроля потока (flow-control) – можно четко понять, когда кластер начинает «притормаживать» и насколько силен эффект троттлинга.
* Group Replication Resource Manager Component (Automatic Eviction & Rejoin). Более живучий кластер: автоматическое обнаружение нестабильных нод, их исключение (eviction) и возвращение в строй при нормализации состояния.
* Group Replication Primary Election Component (Up-to-date Aware). Улучшенный выбор мастера при фейловере – предпочтение теперь отдается наиболее актуальной реплике.

2. Телеметрия (OpenTelemetry)
В Community Edition появилась нативная интеграция с OpenTelemetry (OTLP). Это важный шаг для DBA и SRE-команд:
* Экспорт логов, метрик и трейсов.
* Компонентная конфигурация.
* Возможность встроить MySQL в централизованные пайплайны мониторинга (Jaeger, Prometheus, Grafana и т.д.).

3. Современная разработка (JSON Duality Views)
Для MySQL Community Server расширены возможности JSON Duality Views – добавлена полноценная поддержка DML-операций, включая автоинкремент. Раньше работали только запросы на чтение, а теперь стало возможным и обновление данных через Duality Views. Это существенно упрощает работу с документно-реляционными сценариями.

4. Производительность запросов
* Hypergraph Optimizer. Продвинутый оптимизатор запросов теперь доступен в Community Edition – улучшенный выбор планов JOIN и обработка сложных запросов.
* Profile-Guided Optimization (PGO). Стандартная сборка оптимизирована на основе реальных профилей нагрузки, что дает дополнительный буст производительности без тюнинга со стороны пользователя.

Также в релизе появилось и несколько приятных дополнений в области безопасности и эксплуатации:
* Поддержка формата хранения PBKDF2 для caching_sha2_password.
* Параметр replica_allow_higher_version_source, позволяющий запретить реплике подключаться к источнику со старшей версией (по умолчанию ON – поведение как раньше). При OFF реплика отвергнет соединение, если версия источника выше, но для LTS-версий одной серии (например, 9.7.x) действует исключение – репликация разрешена независимо от номера патча.
* Поддержка клонирования между последовательными LTS-версиями (выше 9.7.0).

Помимо технических нововведений, Oracle начал выполнять обещания и в части открытого диалога с сообществом. Уже прошли несколько онлайн-конференций, где разработчики, DBA и архитекторы обсуждали векторы развития MySQL, началась публикация общедоступных roadmap-ов, а также Oracle возобновил публикацию внутренних задач – WorkLog-ов, в которых можно отслеживать ход разработки новых функций. А на 26 мая запланирована очная конференция MySQL Contributor Summit. Это событие, ориентированное на глубокую техническую коллаборацию, обсуждение проектов из дорожной карты и возможностей для расширения экосистемы MySQL. Похоже, нас ждет не только новый технологический стек, но и новая эпоха взаимодействия с вендором.

Дайджест статей


📰 Почему Big Data стек небезопасен по своей природе
🔗 https://habr.com/ru/articles/1030842/
💡 Разбор доклада Sheila A. Berta (Black Hat 2021): основные уязвимости Big Data-инфраструктур живут не внутри компонентов, а на стыках. HDFS, Spark, ZooKeeper, ClickHouse — каждый строился под "доверенную среду", и атака превращается в навигацию: ZooKeeper отдаёт карту кластера, Spark/YARN дают исполнение кода, дальше — данные.
Вывод: Attack surface растёт быстрее архитектуры; безопасность отдельных сервисов не работает без единой модели доверия между слоями и регулярной чистки "цифрового мусора" (старые пайплайны, реплики, забытые доступы) — иначе в какой-то момент данных становится больше, чем контроля.

📰 Почему 70% BI-систем не окупаются: 5 фатальных ошибок
🔗 https://habr.com/ru/articles/1027986/
💡 Пять типичных провалов: ожидание "магической кнопки", культ красивых графиков, отсутствие data quality, слепое исполнение запросов вместо диалога с заказчиком, отсутствие версионирования дашбордов.
Вывод: BI — зеркало бизнеса, а не его хирург; окупаемость появляется только при чистых данных, простых дашбордах под конкретный бизнес-вопрос и регламенте на каждый отчёт (владелец, версии, аудит). Без этого получаешь 200 дашбордов "Отчёт_новый_финальный_v15" с расхождениями 20% по одному и тому же KPI.

📰 Управление данными в ERP-проектах на основе DAMA-DMBoK
🔗 https://habr.com/ru/articles/1028864/
💡 Обзор: 11 областей знаний DAMA-DMBoK (от моделирования и качества до руководства и метаданных) ложатся на пирамиду Питера Айкена и фазы ERP-внедрения. Управление данными — отдельный бизнес-процесс уровня закупок и финансов, не разовая активность.
Вывод: DMBoK — рабочая карта для ERP-проектов, но порядок применения важнее охвата: фундамент (моделирование, хранение, качество) → метаданные и архитектура → governance. Попытка начать с governance без чистого слоя 1–2 даёт красивые регламенты на грязных данных.

📰 A "meshy" approach to Data: Enabling 100+ teams to build Data Models (Monzo)
🔗 https://monzo.com/blog/a-meshy-approach-to-data
💡 Monzo перестроил dbt-warehouse (12 000+ моделей, 100+ команд) на трёх принципах: opinionated стандарты, формализованные interfaces между командами, автоматизация в CI вместо ручного gatekeeping. Слои landing → normalised → logical → presentation, межкомандный обмен — только через явно объявленные контракты. Первые результаты — ~40% снижение стоимости warehouse и ~25% ускорение поставки данных в ряде доменов.
Вывод: При масштабе data mesh централизованное владение не работает, но и анархия тоже — выход в том, чтобы перенести "правильность" в инструменты (model-gen из YAML, CI-проверки на unique key, freshness, инкрементальность). Это самый трезвый кейс по data mesh за последний год: не манифест, а архитектура.

📰 DuckLake 1.0: Data Lake Format with SQL Catalog Metadata
🔗 https://www.infoq.com/news/2026/05/ducklake-sql-catalog/
💡 DuckDB Labs выпустили production-ready формат лейкхауса, хранящий метаданные таблиц в SQL-базе, а не россыпью файлов в object storage (как Iceberg/Delta/Hudi). Главные фичи — data inlining (мелкие insert/update/delete пишутся прямо в каталог, без small files), сортировка, bucket-партиционирование, deletion vectors совместимые с Iceberg.
Вывод: Серьёзный challenger Iceberg для команд, которым критичны быстрые мелкие записи и простая операционка; компромисс — SQL-каталог это и сила (скорость), и новая точка отказа (ещё одна БД в архитектуре). Для on-prem и средних объёмов "лейкхаус из коробки" может оказаться дешевле и быстрее всей экосистемы вокруг Iceberg.

Вышел Quack от DuckDB протокол превращающий эту in-process локальную базу данных в серверный вариант. У меня лично и в мыслях не было использовать DuckDB как серверную СУБД, в моем понимании это скорее инструмент доступа к данным (query engine) чем база данных, но у меня свои кейсы, а других свои. Надо подумать как эти новые функции можно применить на практике.

#opensource #rdbms #datatools

Итак, сегодня проходим закон Конвея, выполнение которого я видел в любой организации, где имел опыт разработки ИТ систем :)

Как StarRocks защищает production от перегрузки. Query Queues

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

Представим ситуацию: в кластер одновременно приходит 500 тяжёлых запросов. Resource Groups поделят между ними CPU и память, но сами запросы всё равно продолжат конкурировать друг с другом. В результате всё начинает замедляться: растёт latency, память забивается, появляется риск OOM и каскадной деградации.

В этом случае помогут Query Queues. Это механизм back-pressure: когда нагрузка превышает возможности кластера, лишние запросы встают в очередь со статусом PENDING. Как только ресурсы освобождаются, запрос запускается. Кластер обрабатывает поток порциями ровно настолько, насколько у него хватает ресурсов.

По сути:
1️⃣ Resource Groups отвечают на вопрос: кому сколько ресурсов
2️⃣ Query Queues: кого вообще пускать на выполнение

Запрос уходит в очередь, если превышен любой из порогов:
🔹 число выполняющихся запросов на BE
🔹 использование памяти на BE
🔹 загрузка CPU на BE

Работает это на двух уровнях:
🔹 глобальная очередь, на весь кластер
🔹 очередь внутри Resource Group, отдельно для каждого класса нагрузки

Например, можно ограничить ETL пятью одновременными запросами, а BI-дашборды 50 запросами. Запрос стартует только тогда, когда одновременно свободны и глобальный лимит, и лимит его группы.

При этом StarRocks смотрит на реальную загрузку кластера. Каждый BE регулярно отправляет FE статистику по памяти и числу выполняющихся запросов, а Leader FE собирает единую картину нагрузки по всему кластеру. Без этого разные FE могли бы независимо принять слишком много запросов одновременно.

Примечание. Выше описано поведение Query Queues v1 (с порогами на ресурсы BE). С версии StarRocks 3.3 есть v2 на логических слотах: каждый запрос занимает какое-то их число в зависимости от веса, и в очередь попадают те, для кого слотов сейчас нет. В StarRocks 4.1 v2 включён по умолчанию. Принцип back-pressure общий для обеих моделей.

Ещё пара нюансов:
🔹 Если запрос не помещается в очередь или ждёт слишком долго, он получает явную ошибку, клиент сразу видит отказ.
🔹 Query Queues не ускоряют запросы и не оптимизируют планы, а только регулируют, кого пускать на выполнение прямо сейчас.

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

В следующем посте рассмотрим Pipeline DOP: как StarRocks подстраивает параллелизм запроса под текущую загрузку.

Ставьте 🔥, если материал был полезен.

#StarRocks #Selena #MPP #DataArchitecture #Lakehouse #DataEngineering #starrocks_tutorials

Дайджест статей

📰 RAG в энтерпрайзе: почему демо работает, а прод нет
🔗 https://habr.com/ru/articles/1038670/
📝 О чём: разбор причин, по которым RAG-прототип ломается в проде. Проблемы чанкинга длинных таблиц, эмбеддинги, не знающие корпоративный жаргон, ненадёжность top-k и cosine similarity, парсинг PDF и сканов, проброс ACL в метаданные, multi-hop запросы и сложность оценки качества без ground truth. В конце — набор приёмов: сужение домена, гибрид BM25 + векторный поиск через RRF, вынос структурированных данных в SQL.

📰 The Death of Traditional ETL: How AI Agents Are Rewriting Data Engineering (по метаданным)
🔗 https://medium.com/@arrufus/the-death-of-traditional-etl-...
📝 О чём: статья об использовании ИИ-агентов в data engineering. По доступному фрагменту — сценарий, где при изменении схемы выше по потоку ломается downstream-консьюмер, и агент берёт на себя трассировку lineage и починку джоба.

📰 Как мы построили сквозную аналитику в Power BI
🔗 https://habr.com/ru/articles/1038944/
📝 О чём: кейс интегратора VSL-BI для компании по продаже стройматериалов. Сбор данных из Яндекс.Директ, Google Ads, Яндекс Метрики и Битрикс24 в отдельную аналитическую БД на MySQL, загрузка через Python, объединение продаж и рекламных источников по UTM-меткам, построение модели данных и дашбордов в Power BI с метриками ДРР, CpC, CpL, CR.

📰 OCR для Data Lakehouse: от Apache Tika к Docling
🔗 https://habr.com/ru/companies/diasoft_company/articles/1039044/
📝 О чём: путь команды Диасофт от Apache Tika + Tesseract к собственному сервису парсинга документов на базе docling-serve. Описана гибридная архитектура: лёгкий анализ структуры (Layout, TableFormer, Figure Classifier) локально, тяжёлая VL-модель — за внешним шлюзом Digital Q.GPT по OpenAI-протоколу. Рекурсивная обработка вложений, OCR изображений внутри Office-документов, бенчмарки по скорости, CER и потреблению ресурсов в Kubernetes.

📰 Бизнес-аналитика для сети из 300 аптек
🔗 https://habr.com/ru/companies/w_code/articles/1039952/
📝 О чём: внедрение BI-системы интегратором «Белый код» для аптечной сети поверх «СмартАптеки». Пять витрин — оперативный мониторинг с почасовым обновлением, сводка по сети с KPI и LFL, продажи с цветовой индикацией, остатки с drill-down, финансы. Прогноз продаж на день и месяц с учётом времени последней продажи в каждой точке, отдельный мобильный дашборд.

📰 ИИ в работе с данными: почему без человека пока никак
🔗 https://habr.com/ru/companies/yandex_praktikum/articles/1039950/
📝 О чём: пересказ вебинара Яндекс Практикума о применении ИИ аналитиками и дата-сайентистами. Сценарии использования (борьба с «белым листом», ревью кода, саммари по данным, второе мнение), обзор инструментов (чат-боты, Perplexity, NotebookLM, ИИ-агенты) и ограничения: ИИ не учитывает корнер-кейсы, чувствителен к формулировке запроса и не понимает доменный контекст.

📰 Inside AI Meetup (Wildberries) — записи докладов
🔗 https://habr.com/ru/companies/wildberries/articles/1040624/
📝 О чём: анонс с видеозаписями и презентациями митапа Wildberries & Russ от 20 мая. Доклады по AIOps на платформе KeepHQ, автоматическим guardrails (МФТИ), Discovery-платформе VK, отекстовке видео, поиску вакансий на Avito, ИИ-платформе M2, векторной модерации с 200+ моделями и RAG-ассистенту MWS на QWEN3-8B, BGE-M3 и гибридном поиске Vector + BM25 через RRF.