Forwarded from Сообщество Управления Данными
А все решение StarRocks - это и есть будущее, фактически open source snowflake
Forwarded from Клуб CDO
Дайджест статей
📰 The Missing Context Layer for AI Agents Over Business Data
🔗 https://medium.com/wrenai/the-missing-context-layer-for-ai-agents-over-business-data-03849b72f73d
💡 Вывод: Авторы Wren Engine переосмыслили семантический слой как «контекстный движок» для AI-агентов над бизнес-данными — аргумент в пользу того, что проблема NL→SQL не в модели, а в отсутствии правильного контекстного слоя между агентом и данными. (по метаданным — paywall)
📰 SQL Is Quietly Taking Over Data Engineering — Again
🔗 https://medium.com/towards-data-engineering/sql-is-quietly-taking-over-data-engineering-again-1dec44ca2c7d
💡 Вывод: SQL возвращается как де-факто стандарт современной data engineering через dbt, DuckDB, MotherDuck и SQL-first платформы — Python-пайплайны уступают место SQL там, где раньше его считали недостаточным. (по метаданным — paywall)
📰 Data Gravity и отравление выборки
🔗 https://habr.com/ru/companies/otus/articles/1012868/
💡 Вывод: Три системные угрозы ML-проектов — инерция данных (Data Gravity), намеренное и случайное отравление выборки (Data Poisoning по OWASP ML02:2023) и эффект матроса (ложные корреляции) — не решаются ростом объёма данных; решаются они версионированием, статистическим мониторингом и отношением к данным как к инженерному артефакту, а не бесплатному ресурсу.
📰 Лучшие YouTube-каналы по Data и Product Analytics
🔗 https://habr.com/ru/articles/1018610/
💡 Вывод: Подборка каналов (Alex The Analyst, Luke Barousse, Amplitude, Reforge и др.) — материал уровня «начинающий аналитик ищет что посмотреть», для CDO-аудитории ценности почти нет.
📰 Data as Code на практике: ArchDB
🔗 https://habr.com/ru/articles/1018586/
💡 Вывод: ArchDB — open-source DSL для декларативного описания схем БД с модульностью, множественным наследованием шаблонов и контролем версий; практически применим для команд, у которых схема базы живёт в Confluence и устаревает быстрее, чем обновляется — переход с DBML потребует минимальных правок.
📰 BI-аналитика или Excel: где вести аналитику компаниям?
🔗 https://habr.com/ru/articles/1018058/
💡 Вывод: По данным «КОРУС Консалтинг», 43% компаний до сих пор строят аналитику в Excel — статья описывает типичный путь к BI через боль с актуальностью данных, ошибками формул и временны́м долгом на сбор отчётности; реальный кейс — сокращение времени на аналитику с 15–20 до 2–3 часов в неделю через Yandex DataLens с окупаемостью за 4 месяца.
📰 OLAP-кубы в финансах: превращаем бюджетирование в управляемую систему
🔗 https://habr.com/ru/articles/1017470/
💡 Вывод: Статья чётко артикулирует разницу между «личной автоматизацией» (Power Pivot) и корпоративной аналитической инфраструктурой (OLAP): четыре сценария — многоверсионное планирование, консолидация ЦФО, двунаправленное планирование и скользящие прогнозы — реализуемы только на OLAP-платформе, а не в Excel, и именно это меняет роль финансиста с «составителя отчётов» на аналитика.
📰 Как стать аналитиком данных и сколько можно зарабатывать
🔗 https://habr.com/ru/companies/habr_career/articles/1017412/
💡 Вывод: Медианная зарплата дата-аналитика в России — 171 тыс. руб., сеньор получает 283 тыс., лид — 380 тыс.; рынок перегрет кандидатами с сертификатами без практики — по словам руководителя аналитиков Яндекса, рабочий путь в профессию: применять анализ данных там, где уже работаешь, не ждать «правильного» первого места.
📰 ML/AI в системе мониторинга: прогнозирование и предотвращение инцидентов
🔗 https://habr.com/ru/companies/sberbank/articles/1015336/
💡 Вывод: Сбер описывает production-реализацию ML predict-модели с горизонтом 15 минут на инфраструктурных, прикладных и бизнес-метриках — 80% точности достаточно для практического применения, модель обучается на ноутбуке при наличии 5 недель исторических данных, но требует переобучения минимум раз в квартал при изменении инфраструктуры или бизнес-паттернов.
📰 Reference Data Management по-русски: НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
📰 The Missing Context Layer for AI Agents Over Business Data
🔗 https://medium.com/wrenai/the-missing-context-layer-for-ai-agents-over-business-data-03849b72f73d
💡 Вывод: Авторы Wren Engine переосмыслили семантический слой как «контекстный движок» для AI-агентов над бизнес-данными — аргумент в пользу того, что проблема NL→SQL не в модели, а в отсутствии правильного контекстного слоя между агентом и данными. (по метаданным — paywall)
📰 SQL Is Quietly Taking Over Data Engineering — Again
🔗 https://medium.com/towards-data-engineering/sql-is-quietly-taking-over-data-engineering-again-1dec44ca2c7d
💡 Вывод: SQL возвращается как де-факто стандарт современной data engineering через dbt, DuckDB, MotherDuck и SQL-first платформы — Python-пайплайны уступают место SQL там, где раньше его считали недостаточным. (по метаданным — paywall)
📰 Data Gravity и отравление выборки
🔗 https://habr.com/ru/companies/otus/articles/1012868/
💡 Вывод: Три системные угрозы ML-проектов — инерция данных (Data Gravity), намеренное и случайное отравление выборки (Data Poisoning по OWASP ML02:2023) и эффект матроса (ложные корреляции) — не решаются ростом объёма данных; решаются они версионированием, статистическим мониторингом и отношением к данным как к инженерному артефакту, а не бесплатному ресурсу.
📰 Лучшие YouTube-каналы по Data и Product Analytics
🔗 https://habr.com/ru/articles/1018610/
💡 Вывод: Подборка каналов (Alex The Analyst, Luke Barousse, Amplitude, Reforge и др.) — материал уровня «начинающий аналитик ищет что посмотреть», для CDO-аудитории ценности почти нет.
📰 Data as Code на практике: ArchDB
🔗 https://habr.com/ru/articles/1018586/
💡 Вывод: ArchDB — open-source DSL для декларативного описания схем БД с модульностью, множественным наследованием шаблонов и контролем версий; практически применим для команд, у которых схема базы живёт в Confluence и устаревает быстрее, чем обновляется — переход с DBML потребует минимальных правок.
📰 BI-аналитика или Excel: где вести аналитику компаниям?
🔗 https://habr.com/ru/articles/1018058/
💡 Вывод: По данным «КОРУС Консалтинг», 43% компаний до сих пор строят аналитику в Excel — статья описывает типичный путь к BI через боль с актуальностью данных, ошибками формул и временны́м долгом на сбор отчётности; реальный кейс — сокращение времени на аналитику с 15–20 до 2–3 часов в неделю через Yandex DataLens с окупаемостью за 4 месяца.
📰 OLAP-кубы в финансах: превращаем бюджетирование в управляемую систему
🔗 https://habr.com/ru/articles/1017470/
💡 Вывод: Статья чётко артикулирует разницу между «личной автоматизацией» (Power Pivot) и корпоративной аналитической инфраструктурой (OLAP): четыре сценария — многоверсионное планирование, консолидация ЦФО, двунаправленное планирование и скользящие прогнозы — реализуемы только на OLAP-платформе, а не в Excel, и именно это меняет роль финансиста с «составителя отчётов» на аналитика.
📰 Как стать аналитиком данных и сколько можно зарабатывать
🔗 https://habr.com/ru/companies/habr_career/articles/1017412/
💡 Вывод: Медианная зарплата дата-аналитика в России — 171 тыс. руб., сеньор получает 283 тыс., лид — 380 тыс.; рынок перегрет кандидатами с сертификатами без практики — по словам руководителя аналитиков Яндекса, рабочий путь в профессию: применять анализ данных там, где уже работаешь, не ждать «правильного» первого места.
📰 ML/AI в системе мониторинга: прогнозирование и предотвращение инцидентов
🔗 https://habr.com/ru/companies/sberbank/articles/1015336/
💡 Вывод: Сбер описывает production-реализацию ML predict-модели с горизонтом 15 минут на инфраструктурных, прикладных и бизнес-метриках — 80% точности достаточно для практического применения, модель обучается на ноутбуке при наличии 5 недель исторических данных, но требует переобучения минимум раз в квартал при изменении инфраструктуры или бизнес-паттернов.
📰 Reference Data Management по-русски: НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
Medium
The Missing Context Layer for AI Agents Over Business Data
Why we rebuilt Wren Engine from a semantic layer into an open context engine, and what we learned along the way
Слайдер Данные поставляется и для Excel тоже , и это позволяет сократить сроки миграции с PowerQuery | Vba на Р7 офис + Слайдер Данные .
Мы даже часть VBA скриптов можем забрать к себе и превратить их в SQL
Здесь все тоже самое , что сказал выше , но более подробно )
https://habr.com/ru/articles/1020284/
Мы даже часть VBA скриптов можем забрать к себе и превратить их в SQL
Здесь все тоже самое , что сказал выше , но более подробно )
https://habr.com/ru/articles/1020284/
Российские вендоры данных переходят на Lakehouse. Все. Сразу.
За последний год практически каждый крупный российский вендор аналитических данных либо выпустил, либо анонсировал собственное Lakehouse-решение. И все они сошлись на одном: Apache Iceberg + Parquet + S3-совместимое хранилище.
Если ты до сих пор думаешь, что Lakehouse — это что-то из мира Databricks и Snowflake, не имеющее отношения к российской реальности, — пора обновить картину.
Вот что происходит прямо сейчас:
🤩 Arenadata (ADB + ADH) — крупнейший российский игрок в Hadoop-экосистеме — уже не просто поддерживает Iceberg в ADH, а выстраивает полноценную lakehouse-платформу поверх него. В документации прямо написано: «Lakehouse — универсальная платформа данных, объединяющая мощь DWH и гибкость Data Lake». В составе — Spark, Trino, Impala, Iceberg, Kafka с Iceberg Sink Connector для CDC-пайплайнов. Greenplum (ADB) при этом остаётся как движок для классического DWH-слоя.
🤩 DIS Group / Селена — пожалуй, самый агрессивный новичок. Платформа на базе StarRocks Enterprise (партнёрство с китайским вендором), позиционируется как российское Data Lakehouse-решение нового поколения. Поддержка Parquet, ORC, Iceberg, Paimon. ETL через Trino. Хранение на S3 (MinIO, Ceph). Буквально вчера вышла новость о переходе на коммерческое ядро StarRocks Enterprise.
🤩 Postgres Professional / Tengri Data — концептуально смелый ход. Бизнес вокруг PostgreSQL, запускают аналитическую платформу в парадигме Open Lakehouse. Разделение compute и storage, данные на S3, работа с Iceberg и Parquet. Прямо позиционируют себя как альтернативу Greenplum-решениям, которые «больше не развиваются в рамках open source». DuckLake (новый lakehouse-формат от DuckDB) с Iceberg-совместимостью тоже на радаре — его v1.0 вышла буквально на днях, и он использует PostgreSQL как каталог.
🤩 VK Tech / CedrusData — lakehouse-платформа на базе Trino, Iceberg, Spark, Flink. Собственный каталог метаданных CedrusData Catalog с поддержкой Iceberg REST API. Уже используется в продакшене — например, в S7 Airlines. Развивают крупнейшие русскоязычные комьюнити по Trino и Apache Iceberg. Недавно переписали часть ядра Trino на Rust для производительности.
🤩 Yandex Cloud — собирает lakehouse из управляемых сервисов: Object Storage + Iceberg + Managed Spark + Managed Trino + Airflow + ClickHouse для витрин. Уже рассказывают про это на конференциях как про «инженерный стандарт, обеспечивающий предсказуемость витрин и ML-моделей». Совсем недавно проводили митап по Lakehouse.
🤩 CloudRu (бывший SberCloud) — в платформе Evolution есть Managed Trino, Managed Spark, Managed Metastore и Object Storage. Полный набор для сборки lakehouse-архитектуры в облаке.
Что общего у всех этих решений?
🤩 Данные хранятся в открытом формате — Parquet (реже ORC) в объектном S3-хранилище
🤩 Табличный формат — Apache Iceberg — ACID-транзакции, schema evolution, time travel, партиционирование
🤩 Compute отделён от Storage — можно масштабировать независимо
🤩 Несколько движков на одних данных — Spark для ETL, Trino/StarRocks для интерактивных запросов, DuckDB для локальной аналитики
Это и есть Lakehouse — архитектура, на которую переходят вообще все. Свой лейкхаус строят бигтехи: Авито, Т-Банк, Х5, Тинек, Лемана-Леруа.
Greenplum перестал развиваться в open source. Hadoop в чистом виде уходит. Вендоры перестраиваются — и перестраивают требования к специалистам. Parquet, Iceberg, принципы lakehouse-архитектуры — это уже не опционально. Это базовая грамотность data-инженера в 2026 году. Поэтому выходит что:
🤩 Если ты в облаке - будет менеджед Лейкхаус
🤩 Если ты в онпреме/энтерпрайзе - будет вендорский от одного из рос провайдеров
🤩 Если ты сам по себе крутой бигтех - тоже будет Лейкхаус! свой, родной
Хотите поработать с Trino + Iceberg + S3? Есть курс Алексея Белозерского из VK Tech 🔥«Lakehouse для аналитиков и инженеров данных» — живые онлайн-сессии, Iceberg, Trino, PyIceberg, dbt, Airflow, пайплайны на SQL и Python, практика на реальном стеке. Старт 16 апреля. Подробности → devhands.ru/lakehouse
За последний год практически каждый крупный российский вендор аналитических данных либо выпустил, либо анонсировал собственное Lakehouse-решение. И все они сошлись на одном: Apache Iceberg + Parquet + S3-совместимое хранилище.
Если ты до сих пор думаешь, что Lakehouse — это что-то из мира Databricks и Snowflake, не имеющее отношения к российской реальности, — пора обновить картину.
Вот что происходит прямо сейчас:
Что общего у всех этих решений?
Это и есть Lakehouse — архитектура, на которую переходят вообще все. Свой лейкхаус строят бигтехи: Авито, Т-Банк, Х5, Тинек, Лемана-Леруа.
Greenplum перестал развиваться в open source. Hadoop в чистом виде уходит. Вендоры перестраиваются — и перестраивают требования к специалистам. Parquet, Iceberg, принципы lakehouse-архитектуры — это уже не опционально. Это базовая грамотность data-инженера в 2026 году. Поэтому выходит что:
Хотите поработать с Trino + Iceberg + S3? Есть курс Алексея Белозерского из VK Tech 🔥«Lakehouse для аналитиков и инженеров данных» — живые онлайн-сессии, Iceberg, Trino, PyIceberg, dbt, Airflow, пайплайны на SQL и Python, практика на реальном стеке. Старт 16 апреля. Подробности → devhands.ru/lakehouse
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Клуб CDO
Хороший пример того, что для меня является эталоном инженерного решения - просто горизонтальная линия на борту корабля.
Одна простая линия спасла и продолжает спасать огромное количество жизней. И работает в продакшене уже больше полутора веков без единого downtime.
Её придумал Сэмюэл Плимсолл в 1870-х. До него судовладельцы в Британии грузили корабли сверх всякой меры, страховали их на полную стоимость и спокойно ждали, когда очередной «гроб с парусами» пойдёт ко дну вместе с командой. Бизнес-модель работала: страховая выплачивала больше, чем стоил ремонт.
Плимсолл продавил закон. И решение оказалось изумительно простым: на борт каждого судна наносится метка. Если при погрузке линия ушла под воду - перегруз, в море не выпускают. Всё. Ни датчиков, ни инспекторов в каждом порту, ни сложных расчётов водоизмещения для таможни. Любой портовый рабочий, ребёнок, журналист с пристани могут посмотреть и сказать: этот корабль перегружен.
Одна простая линия спасла и продолжает спасать огромное количество жизней. И работает в продакшене уже больше полутора веков без единого downtime.
Её придумал Сэмюэл Плимсолл в 1870-х. До него судовладельцы в Британии грузили корабли сверх всякой меры, страховали их на полную стоимость и спокойно ждали, когда очередной «гроб с парусами» пойдёт ко дну вместе с командой. Бизнес-модель работала: страховая выплачивала больше, чем стоил ремонт.
Плимсолл продавил закон. И решение оказалось изумительно простым: на борт каждого судна наносится метка. Если при погрузке линия ушла под воду - перегруз, в море не выпускают. Всё. Ни датчиков, ни инспекторов в каждом порту, ни сложных расчётов водоизмещения для таможни. Любой портовый рабочий, ребёнок, журналист с пристани могут посмотреть и сказать: этот корабль перегружен.
👍1
Видео того , как мы собираем аналитику из массива в 6 млн строк
https://disk.yandex.ru/i/txrgneSbdpf6TA
https://disk.yandex.ru/i/txrgneSbdpf6TA
Яндекс Диск
7.1. Демонстрация. Решение аналитического кейса.mp4
Посмотреть и скачать с Яндекс Диска
А вы правильно считаете среднее ?
Материал , нашего партнёра Rapeed
https://habr.com/ru/articles/1025328/
Материал , нашего партнёра Rapeed
https://habr.com/ru/articles/1025328/
Хабр
Иллюзия точности метрик: о чем не принято говорить в «высоком обществе» BI-аналитиков
На одном из внедрений аналитической платформы rapeed в крупном банке мы столкнулись с проблемой: данные по среднему времени обработки кредитной заявки у нас и в их исторической BI-системе...
Forwarded from Клуб CDO (Postly Bot)
Давно не слышали про data mesh? Его уже раз пять похоронили. Проблема в том, что проблема, которую он решает, хоронить себя не дала.
Horse Powertrain - бывшее подразделение Volvo Cars. Делают двигатели и трансмиссии. Когда отделились от материнской компании, потеряли доступ к централизованной аналитике. Просто отрезали. И вместо того чтобы воспроизводить ту же централизованную модель с нуля, пошли в data mesh.
Почему этот кейс интереснее очередного доклада из FAANG: это промышленное производство. CAD-системы, тестирование двигателей, ERP, aftermarket. Сотни источников данных, половина из которых - коммерческий софт с вендорным замком. Не самая благодарная среда для архитектурных экспериментов.
Что сделали по факту. Взяли Azure Databricks, нарезали на изолированные workspace-ы по бизнес-доменам. Каждый workspace - автономная единица. Свой админ, свои данные, свои правила доступа через Unity Catalog. Новый workspace разворачивается через CLI и GitHub Actions за 10–15 минут. Без участия платформенной команды.
Data products сделали трёхуровневыми: сырые данные в третьей нормальной форме (для ML и feature store), технические продукты с денормализацией и понятными именами, и бизнес-продукты - плоские таблицы, которые можно подключить к BI без посредников. На каждом уровне CI-проверки: нет описания колонки - не пройдёшь.
Но самое интересное не в технологии. Внедрение шло через инкубационную модель: платформенная команда заходила в продуктовую на 1–2 спринта, строила POC, обучала людей, потом уходила. А давление на adoption шло не через разработчиков, а через OKR менеджмента. Конкретное: «перевести 5 Excel-отчётов на платформу в этом квартале». Не «изучить Databricks», а «перестать тратить 30 часов на один Excel».
Data mesh хоронят те, кто думал, что это про архитектурную диаграмму. А он про ownership, про то, кто отвечает за данные и кто принимает решения о доступе. Технология — просто рельсы. Без менеджерского buy-in и оргструктуры, которая даёт командам реальный контроль, никакой mesh не взлетит. С ними — вполне себе летает. Даже на заводе по производству двигателей.
https://www.infoq.com/presentations/data-mesh-horse-powertrain
Horse Powertrain - бывшее подразделение Volvo Cars. Делают двигатели и трансмиссии. Когда отделились от материнской компании, потеряли доступ к централизованной аналитике. Просто отрезали. И вместо того чтобы воспроизводить ту же централизованную модель с нуля, пошли в data mesh.
Почему этот кейс интереснее очередного доклада из FAANG: это промышленное производство. CAD-системы, тестирование двигателей, ERP, aftermarket. Сотни источников данных, половина из которых - коммерческий софт с вендорным замком. Не самая благодарная среда для архитектурных экспериментов.
Что сделали по факту. Взяли Azure Databricks, нарезали на изолированные workspace-ы по бизнес-доменам. Каждый workspace - автономная единица. Свой админ, свои данные, свои правила доступа через Unity Catalog. Новый workspace разворачивается через CLI и GitHub Actions за 10–15 минут. Без участия платформенной команды.
Data products сделали трёхуровневыми: сырые данные в третьей нормальной форме (для ML и feature store), технические продукты с денормализацией и понятными именами, и бизнес-продукты - плоские таблицы, которые можно подключить к BI без посредников. На каждом уровне CI-проверки: нет описания колонки - не пройдёшь.
Но самое интересное не в технологии. Внедрение шло через инкубационную модель: платформенная команда заходила в продуктовую на 1–2 спринта, строила POC, обучала людей, потом уходила. А давление на adoption шло не через разработчиков, а через OKR менеджмента. Конкретное: «перевести 5 Excel-отчётов на платформу в этом квартале». Не «изучить Databricks», а «перестать тратить 30 часов на один Excel».
Data mesh хоронят те, кто думал, что это про архитектурную диаграмму. А он про ownership, про то, кто отвечает за данные и кто принимает решения о доступе. Технология — просто рельсы. Без менеджерского buy-in и оргструктуры, которая даёт командам реальный контроль, никакой mesh не взлетит. С ними — вполне себе летает. Даже на заводе по производству двигателей.
https://www.infoq.com/presentations/data-mesh-horse-powertrain
InfoQ
Data Mesh in Action: a Journey from Ideation to Implementation
Anurag Kale discusses the transition from centralized data bottlenecks to a decentralized Data Mesh architecture at Horse Powertrain. He explains the four pillars - domain ownership, data as a product, self-serve platforms, and federated governance - to empower…
Forwarded from Джемовый Блог
hermes_agent_practical_guide_nontech_ru.pdf
414.2 KB
Последнее время меня часто просят выступить на различных мероприятиях по теме нейросетей. И самый частый вопрос "я хочу ассистента, который будет работать 24/7 и помогать мне с бизнесом". Ребят, для вас есть решение, которым я сам пользуюсь постоянно - Hermes Agent.
В гайде описано, как настроить его за вечер. Для понимания, что умеет этот монстр:
• Обучается на каждом вашем взаимодействии
• Помнит все
• Переписывает сам себя, чтобы стать лучше
• Ищет в интернете
• Работает в телеграме
• Слушает ваши голосовые сообщения и отвечает голосом
• Создает сайты и ботов
• Пишет посты сразу в группу
• Общается с клиентами
• Мониторит цены
и многое другое
Ставьте лайки и делитесь с друзьями, если вам интересны такие практические гайды по ИИ
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from MyDB
⚡️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.
* Параметр
* Поддержка клонирования между последовательными LTS-версиями (выше 9.7.0).
Помимо технических нововведений, Oracle начал выполнять обещания и в части открытого диалога с сообществом. Уже прошли несколько онлайн-конференций, где разработчики, DBA и архитекторы обсуждали векторы развития MySQL, началась публикация общедоступных roadmap-ов, а также Oracle возобновил публикацию внутренних задач – WorkLog-ов, в которых можно отслеживать ход разработки новых функций. А на 26 мая запланирована очная конференция MySQL Contributor Summit. Это событие, ориентированное на глубокую техническую коллаборацию, обсуждение проектов из дорожной карты и возможностей для расширения экосистемы MySQL. Похоже, нас ждет не только новый технологический стек, но и новая эпоха взаимодействия с вендором.
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. Похоже, нас ждет не только новый технологический стек, но и новая эпоха взаимодействия с вендором.
Telegram
MyDB
🐬 Новая эра MySQL: Oracle открывает коммерческие функции для сообщества
Друзья, отличные новости пришли из блога Oracle MySQL. Отметив в прошлом году 30-летний юбилей проекта, компания анонсировала кардинальные изменения в стратегии взаимодействия с сообществом.…
Друзья, отличные новости пришли из блога Oracle MySQL. Отметив в прошлом году 30-летний юбилей проекта, компания анонсировала кардинальные изменения в стратегии взаимодействия с сообществом.…
Forwarded from Ivan Begtin (Ivan Begtin)
Новая внедрямая база данных SlothDB умеющая читать разного рода дата файлы вроде parquet, csv, json, avro и о которой автор пишет что она быстрее DuckDB.
Что интересно - похоже на зрелый и проработанный проект, не знаю насчет скорости, но точно с очень небольшим футпринтом что особенно критично для умных устройств, мини инсталляций и тд.
Насчет бенчмарков, тут хочется увидеть независимые оценки.
В любом случае появление алттернативы DuckDB которая была бы лучшее/быстрее/мощнее - это хорошо.
Малый футпринт еще важен для применения в веб интерфейсах, поскольку размер кода для WebAssembly существенно меньше (по обещаниям автора).
#opensource #datatools #dataengineering
Что интересно - похоже на зрелый и проработанный проект, не знаю насчет скорости, но точно с очень небольшим футпринтом что особенно критично для умных устройств, мини инсталляций и тд.
Насчет бенчмарков, тут хочется увидеть независимые оценки.
В любом случае появление алттернативы DuckDB которая была бы лучшее/быстрее/мощнее - это хорошо.
Малый футпринт еще важен для применения в веб интерфейсах, поскольку размер кода для WebAssembly существенно меньше (по обещаниям автора).
#opensource #datatools #dataengineering
Forwarded from Клуб CDO
Дайджест статей
📰 Почему 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.
📰 Почему 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.
Хабр
Почему Big Data стек небезопасен по своей природе
Год назад на рандом-кофе мы с коллегой обсуждали так называемую (мной) цифровую экологию и проблемы работы с большими данными, и он мне посоветовал доклад "The Unbelievable Insecurity of the Big Data...
Forwarded from Ivan Begtin (Ivan Begtin)
Вышел Quack от DuckDB протокол превращающий эту in-process локальную базу данных в серверный вариант. У меня лично и в мыслях не было использовать DuckDB как серверную СУБД, в моем понимании это скорее инструмент доступа к данным (query engine) чем база данных, но у меня свои кейсы, а других свои. Надо подумать как эти новые функции можно применить на практике.
#opensource #rdbms #datatools
#opensource #rdbms #datatools
Forwarded from Клуб CDO
Итак, сегодня проходим закон Конвея, выполнение которого я видел в любой организации, где имел опыт разработки ИТ систем :)
Forwarded from Любовь, BI и графики
Манипулировать умеют не только люди...
Но еще и графики! Причём сами данные могут быть абсолютно честными, но достаточно немного изменить масштаб, оси или визуальные акценты, и восприятие цифр уже будет совсем другим.
В карточках собрала 8 приёмов, с помощью которых НЕ нужно (осознанно или нет) манипулировать данными в визуализациях.
🤡 часть примеров взята из личного опыта: например, вторая карточка это реальная просьба на моем первом месте работы в качестве аналитика (подробнее тут)
🤡 предпоследняя карточка - из результатов гомеопатического исследования
🤡 еще несколько - из канала отвратительные графики
А вам приходилось манипулировать данными? По запросу или случайно?
@loving_bi
Но еще и графики! Причём сами данные могут быть абсолютно честными, но достаточно немного изменить масштаб, оси или визуальные акценты, и восприятие цифр уже будет совсем другим.
В карточках собрала 8 приёмов, с помощью которых НЕ нужно (осознанно или нет) манипулировать данными в визуализациях.
А вам приходилось манипулировать данными? По запросу или случайно?
@loving_bi
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🤓1