Forwarded from Weekly Charts
🌻 Pi Day
Вчера (14 марта) был День числа Пи (3/14). Визуализируем с помощью #R и #ggplot2 первые 1 000 знаков числа Пи. В сердце этой визуализации — математически совершенный узор, который природа миллионы лет использует в подсолнухах и шишках для идеальной упаковки семян (филлотаксис).
Секрет в золотом угле (≈137.5°), который заставляет цифры числа Пи в виде точек занимать всё свободное пространство, не образуя пустых рядов или "швов". Чтобы узор оставался равномерным, используется спираль Ферма и модель Фогеля (r = √i). Квадратный корень удерживает плотность точек одинаковой как в центре, так и на краях, превращая бесконечный цифровой хаос в гармоничный "математический цветок".
Постер Pi Day в формате A4 300 dpi. Код постера на GitHub.
#pi #ggplot2 #R #rstats #dataviz #generative_art
Вчера (14 марта) был День числа Пи (3/14). Визуализируем с помощью #R и #ggplot2 первые 1 000 знаков числа Пи. В сердце этой визуализации — математически совершенный узор, который природа миллионы лет использует в подсолнухах и шишках для идеальной упаковки семян (филлотаксис).
Секрет в золотом угле (≈137.5°), который заставляет цифры числа Пи в виде точек занимать всё свободное пространство, не образуя пустых рядов или "швов". Чтобы узор оставался равномерным, используется спираль Ферма и модель Фогеля (r = √i). Квадратный корень удерживает плотность точек одинаковой как в центре, так и на краях, превращая бесконечный цифровой хаос в гармоничный "математический цветок".
Постер Pi Day в формате A4 300 dpi. Код постера на GitHub.
#pi #ggplot2 #R #rstats #dataviz #generative_art
❤2
Forwarded from Крохмалюк
💡 9 личных наблюдений о маркетинге и росте продуктов, которые хотелось бы знать 5 лет назад
1. Самая большая проблема в компаниях любого размера — специальная или случайная манипуляция с данными. По личным наблюдениям, 80%+ экспериментов в компаниях проводятся криво, а количество честных экспериментов в интернете стремится к нулю.
2. Самый переоценённый источник данных — рыночные исследования. Подробно изучить 10 конкурентов и похожих продуктов >>> псевдонаучные выводы на непонятной выборке.
3. Если доля платного трафика не уменьшается каждый год — вы что-то делаете не так. Абсолюты могут расти, но доля должна падать.
4. 99% продуктов не нужно проводить эксперименты. Мало трафика, нет инфраструктуры, нет процессов, нет экспертизы, слабые гипотезы и т.д. Лучший путь для них: найти того, кто заранее знает, что с большой вероятностью сработает.
5. Продукт без ретеншена и дешевого/бесплатного трафика = продавец на Wildberries. Уважаемо, ничего плохого нет, что-то заработать можно, но на дистанции будете страдать.
6. Нет ничего бесполезнее брейншторма, к которому никто заранее не готовился и пытается придумать решение на ходу.
7. Чем круче growth/маркетинговый канал, тем более стыдно показывать его в паблике.
8. Корреляция ≠ каузация. Все знают разницу в теории (два события идут рядом vs одно вызывает другое), но на практике большая часть продуктовых решений строится именно так: видят совпадение → делают фичу → удивляются, почему не сработало.
9. Стратегически заработок денег почти всегда про счастье пользователя. Тактически почти всегда не про счастье пользователя.
1. Самая большая проблема в компаниях любого размера — специальная или случайная манипуляция с данными. По личным наблюдениям, 80%+ экспериментов в компаниях проводятся криво, а количество честных экспериментов в интернете стремится к нулю.
2. Самый переоценённый источник данных — рыночные исследования. Подробно изучить 10 конкурентов и похожих продуктов >>> псевдонаучные выводы на непонятной выборке.
3. Если доля платного трафика не уменьшается каждый год — вы что-то делаете не так. Абсолюты могут расти, но доля должна падать.
4. 99% продуктов не нужно проводить эксперименты. Мало трафика, нет инфраструктуры, нет процессов, нет экспертизы, слабые гипотезы и т.д. Лучший путь для них: найти того, кто заранее знает, что с большой вероятностью сработает.
5. Продукт без ретеншена и дешевого/бесплатного трафика = продавец на Wildberries. Уважаемо, ничего плохого нет, что-то заработать можно, но на дистанции будете страдать.
6. Нет ничего бесполезнее брейншторма, к которому никто заранее не готовился и пытается придумать решение на ходу.
7. Чем круче growth/маркетинговый канал, тем более стыдно показывать его в паблике.
8. Корреляция ≠ каузация. Все знают разницу в теории (два события идут рядом vs одно вызывает другое), но на практике большая часть продуктовых решений строится именно так: видят совпадение → делают фичу → удивляются, почему не сработало.
9. Стратегически заработок денег почти всегда про счастье пользователя. Тактически почти всегда не про счастье пользователя.
Forwarded from { между скобок } анонсы 📣 (Grisha Skobelev)
Road to Highload
Наткнулся на серию материалов от команды Яндекс 360 про эволюцию их систем и путь к highload. Решил посмотреть, что там внутри.
Гораздо интереснее понять почему архитектура получилась именно такой, какие были ограничения и какие трейдоффы приходилось принимать по дороге. И здорово что можно посмотреть на путь который уже прошла другая big tech компания.
В этой серии как раз пытаются разобрать такие вещи на реальных примерах.
Всего получилось 5 выпусков, и они проходят по довольно базовым, но важным темам серверных систем:
— как сбор требований влияет на архитектуру и надежность системы
— проектирование API и почему ошибки на этом этапе потом дорого исправлять
— как визуализация архитектуры помогает объяснять систему команде
— что происходит, когда начинают расти данные: индексы, консистентность, компромиссы
— интеграции с внешними сервисами и типичные грабли
Мне больше всего зашел выпуск про рост данных. Там как раз обсуждают вещи, с которыми рано или поздно сталкивается почти любой сервис:
индексы, рост таблиц, влияние на производительность и какие решения обычно принимают, когда система начинает упираться в масштаб.
В целом серия получилась довольно практичной. Без «серебряных пуль» и магических архитектур - скорее про реальные проблемы, которые появляются, когда система живет и растет.
Если уже смотрели - интересно услышать ваше мнение.
И заодно поделитесь: какие материалы про highload вы считаете must-watch для инженеров?
Наткнулся на серию материалов от команды Яндекс 360 про эволюцию их систем и путь к highload. Решил посмотреть, что там внутри.
Гораздо интереснее понять почему архитектура получилась именно такой, какие были ограничения и какие трейдоффы приходилось принимать по дороге. И здорово что можно посмотреть на путь который уже прошла другая big tech компания.
В этой серии как раз пытаются разобрать такие вещи на реальных примерах.
Всего получилось 5 выпусков, и они проходят по довольно базовым, но важным темам серверных систем:
— как сбор требований влияет на архитектуру и надежность системы
— проектирование API и почему ошибки на этом этапе потом дорого исправлять
— как визуализация архитектуры помогает объяснять систему команде
— что происходит, когда начинают расти данные: индексы, консистентность, компромиссы
— интеграции с внешними сервисами и типичные грабли
Мне больше всего зашел выпуск про рост данных. Там как раз обсуждают вещи, с которыми рано или поздно сталкивается почти любой сервис:
индексы, рост таблиц, влияние на производительность и какие решения обычно принимают, когда система начинает упираться в масштаб.
В целом серия получилась довольно практичной. Без «серебряных пуль» и магических архитектур - скорее про реальные проблемы, которые появляются, когда система живет и растет.
Если уже смотрели - интересно услышать ваше мнение.
И заодно поделитесь: какие материалы про highload вы считаете must-watch для инженеров?
Яндекс 360. Road to Highload — проект о проектировании сервисов
Рассказываем, как создаём одни из самых крупных облачных сервисов
Forwarded from Клуб CDO
Дайджест статей
📰 Как аналитики данных используют ИИ для решения своих задач
🔗 https://habr.com/ru/companies/yandex_praktikum/articles/1004550/
💡 Вывод: ИИ меняет роль аналитика не в сторону «нажми кнопку — получи инсайт», а в сторону переквалификации: нужно уметь формулировать задачи для агентов и верифицировать их результат. Ключевая компетенция — не SQL, а способность задать правильный вопрос. (по метаданным)
📰 asapBI: архитектура ETL процессов – Trino, Spark, Airflow и прочий зоопарк
🔗 https://habr.com/ru/articles/1011510/
💡 Вывод: Платформа asapBI — попытка решить вечную проблему ETL: 90% трансформаций тривиальны (маппинг полей), но их всё равно пишут руками на SQL. Подход «графический интерфейс для простого, код для сложного» с единой точкой мониторинга и автогенерацией дагов Airflow. Критично: система не создаёт vendor lock — все артефакты работают без неё. Правильный вопрос на фоне прогресса ИИ: а нужны ли вообще моделированные DWH, если можно дать ИИ доступ к Lakehouse напрямую?
📰 Манипулирование данными или как не дать графикам себя обмануть
🔗 https://habr.com/ru/articles/1012236/
💡 Вывод: Каталог из 8 типичных приёмов визуальных манипуляций — от обрезанных осей до выборочного периода. Полезно как чеклист при ревью любого дашборда или отчёта. Ключевой навык для CDO-команды: не только строить визуализации, но и уметь защитить их от манипулятивного использования другими.
📰 Три задачи требований к данным
🔗 https://habr.com/ru/articles/1012406/
💡 Вывод: Автор выделяет три типа требований к данным: изменения в таблицах + маппинг, миграции существующих данных, enum’ы в коде. Главный инсайт: без документированной базы данных в вики (концептуальная схема + бизнес-логика на каждую таблицу) требования неизбежно превращаются в дублирование и устаревание. Физическая модель — не замена концептуальному описанию.
📰 Reference Data Management по-русски: что мы называем НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
💡 Вывод: В российской практике «НСИ» стало зонтиком для RDM + MDM + DQ, хотя международный стандарт (DAMA DMBOK) чётко разделяет эти дисциплины. Ожидание «одна система на всё» — классическая ловушка: чем больше функций, тем выше риск получить продукт, который умеет всё, но плохо. При выборе инструмента важно разделить задачи: ведение справочников ≠ дедубликация ≠ гармонизация форматов.
📰 Data Mesh vs Data Fabric: The Ultimate 2025 Comparison for Enterprise Architects
🔗 https://medium.com/analysts-corner/data-mesh-vs-data-fabric-key-differences-architecture-future-trends-2025-c69287b1ef07
💡 Вывод: Сравнение двух архитектурных подходов к масштабированию работы с данными. Data Mesh — про организационную децентрализацию (domain ownership), Data Fabric — про технологическую унификацию (metadata-driven automation). (по метаданным)
📰 How did Meta modernize their lakehouse?
🔗 https://blog.dataengineerthings.org/how-did-meta-modernize-their-lakehouse-f2fec45af2f4
💡 Вывод: Meta переархитектурила свой Lakehouse, стартовавший с Hive в 2010 году. Статья фокусируется не на компонентах, а на организационных проблемах, которые возникают при масштабировании data-инфраструктуры на 20+ лет. (за пейволом, по метаданным)
📰 Hands-on with an MCP for data quality
🔗 https://medium.com/@mikldd/hands-on-with-an-mcp-for-data-quality-6fe4b9ed52a8
💡 Вывод: MCP (Model Context Protocol) в связке с метаданными о пайплайне (lineage, владельцы, мониторы) даёт AI-агенту возможность: оценить downstream-impact изменения колонки с взвешенным risk assessment, провести root cause analysis инцидента по шагам (lineage → upstream checks → code changes), найти таблицы с недостаточным покрытием тестами и сгенерировать еженедельный DQ-отчёт. Ключевой инсайт: MCP полезен ровно настолько, насколько богаты ваши метаданные.
📰 The Three-Body Problem of Data: Why Analytics, Decisions, & Ops Never Align
🔗 https://medium.com/@community_md101/the-three-body-problem-of-data-why-analytics-decisions-ops-never-align-5b428763b33c
📰 Как аналитики данных используют ИИ для решения своих задач
🔗 https://habr.com/ru/companies/yandex_praktikum/articles/1004550/
💡 Вывод: ИИ меняет роль аналитика не в сторону «нажми кнопку — получи инсайт», а в сторону переквалификации: нужно уметь формулировать задачи для агентов и верифицировать их результат. Ключевая компетенция — не SQL, а способность задать правильный вопрос. (по метаданным)
📰 asapBI: архитектура ETL процессов – Trino, Spark, Airflow и прочий зоопарк
🔗 https://habr.com/ru/articles/1011510/
💡 Вывод: Платформа asapBI — попытка решить вечную проблему ETL: 90% трансформаций тривиальны (маппинг полей), но их всё равно пишут руками на SQL. Подход «графический интерфейс для простого, код для сложного» с единой точкой мониторинга и автогенерацией дагов Airflow. Критично: система не создаёт vendor lock — все артефакты работают без неё. Правильный вопрос на фоне прогресса ИИ: а нужны ли вообще моделированные DWH, если можно дать ИИ доступ к Lakehouse напрямую?
📰 Манипулирование данными или как не дать графикам себя обмануть
🔗 https://habr.com/ru/articles/1012236/
💡 Вывод: Каталог из 8 типичных приёмов визуальных манипуляций — от обрезанных осей до выборочного периода. Полезно как чеклист при ревью любого дашборда или отчёта. Ключевой навык для CDO-команды: не только строить визуализации, но и уметь защитить их от манипулятивного использования другими.
📰 Три задачи требований к данным
🔗 https://habr.com/ru/articles/1012406/
💡 Вывод: Автор выделяет три типа требований к данным: изменения в таблицах + маппинг, миграции существующих данных, enum’ы в коде. Главный инсайт: без документированной базы данных в вики (концептуальная схема + бизнес-логика на каждую таблицу) требования неизбежно превращаются в дублирование и устаревание. Физическая модель — не замена концептуальному описанию.
📰 Reference Data Management по-русски: что мы называем НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
💡 Вывод: В российской практике «НСИ» стало зонтиком для RDM + MDM + DQ, хотя международный стандарт (DAMA DMBOK) чётко разделяет эти дисциплины. Ожидание «одна система на всё» — классическая ловушка: чем больше функций, тем выше риск получить продукт, который умеет всё, но плохо. При выборе инструмента важно разделить задачи: ведение справочников ≠ дедубликация ≠ гармонизация форматов.
📰 Data Mesh vs Data Fabric: The Ultimate 2025 Comparison for Enterprise Architects
🔗 https://medium.com/analysts-corner/data-mesh-vs-data-fabric-key-differences-architecture-future-trends-2025-c69287b1ef07
💡 Вывод: Сравнение двух архитектурных подходов к масштабированию работы с данными. Data Mesh — про организационную децентрализацию (domain ownership), Data Fabric — про технологическую унификацию (metadata-driven automation). (по метаданным)
📰 How did Meta modernize their lakehouse?
🔗 https://blog.dataengineerthings.org/how-did-meta-modernize-their-lakehouse-f2fec45af2f4
💡 Вывод: Meta переархитектурила свой Lakehouse, стартовавший с Hive в 2010 году. Статья фокусируется не на компонентах, а на организационных проблемах, которые возникают при масштабировании data-инфраструктуры на 20+ лет. (за пейволом, по метаданным)
📰 Hands-on with an MCP for data quality
🔗 https://medium.com/@mikldd/hands-on-with-an-mcp-for-data-quality-6fe4b9ed52a8
💡 Вывод: MCP (Model Context Protocol) в связке с метаданными о пайплайне (lineage, владельцы, мониторы) даёт AI-агенту возможность: оценить downstream-impact изменения колонки с взвешенным risk assessment, провести root cause analysis инцидента по шагам (lineage → upstream checks → code changes), найти таблицы с недостаточным покрытием тестами и сгенерировать еженедельный DQ-отчёт. Ключевой инсайт: MCP полезен ровно настолько, насколько богаты ваши метаданные.
📰 The Three-Body Problem of Data: Why Analytics, Decisions, & Ops Never Align
🔗 https://medium.com/@community_md101/the-three-body-problem-of-data-why-analytics-decisions-ops-never-align-5b428763b33c
Хабр
Как аналитики данных используют ИИ для решения своих задач
Нейросети и быстрое развитие ИИ в целом (плюс постепенное распространение ИИ‑агентов в ежедневной работе) меняет подход к работе аналитика данных. Однако действительно ли это...
Forwarded from Если быть точным
В прошлом году мы добавили в каталог «Если быть точным» новый формат данных — parquet. Подробно рассказываем, как с ним работать
Parquet в 2013 году придумали инженеры Twitter и Cloudera. Теперь им пользуются в Google, Amazon и Netflix. С апреля, кроме привычных csv и xlsx, мы публикуем все наборы данных в этом формате.
Главное преимущество parquet — компактность. Например, датасет по онкологии в csv весит 576 мегабайт. Файл excel c теми же данными — 140 мегабайт, а parquet занимает всего 4 мегабайта.
Формат позволяет не загружать весь файл в память — можно читать только нужные столбцы и строки, в том числе напрямую из облачного хранилища, не скачивая сам файл.
Как работать с parquet — читайте на сайте «Если быть точным» или в нашем новом блоге на Хабре.
◾️ Этот гайд впервые вышел в рассылке «Это не показатель» — присоединяйтесь через Tribute или Boosty.
Parquet в 2013 году придумали инженеры Twitter и Cloudera. Теперь им пользуются в Google, Amazon и Netflix. С апреля, кроме привычных csv и xlsx, мы публикуем все наборы данных в этом формате.
Главное преимущество parquet — компактность. Например, датасет по онкологии в csv весит 576 мегабайт. Файл excel c теми же данными — 140 мегабайт, а parquet занимает всего 4 мегабайта.
Формат позволяет не загружать весь файл в память — можно читать только нужные столбцы и строки, в том числе напрямую из облачного хранилища, не скачивая сам файл.
Как работать с parquet — читайте на сайте «Если быть точным» или в нашем новом блоге на Хабре.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Forwarded from Клуб CDO
Дайджест статей
📰 Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения
🔗 https://habr.com/ru/articles/1014098/
💡 Вывод: Инженер пишет собственный OLTP-движок на Rust — с UNDO-log MVCC (как у InnoDB, Oracle, MSSQL), unified storage на БД и fail-closed поведением вместо тихой деградации. Главный тезис: если система под нагрузкой молчит и тянет — она врёт. Предсказуемый отказ с внятным SQLSTATE лучше, чем иллюзия, что «ещё дотянет». Для CDO: пример архитектурных решений на уровне storage engine, которые стоит знать при оценке собственных data-платформ.
📰 Как ML изменит бизнес в 2026 году: прогноз Selectel, GlowByte и Data Sapience
🔗 https://habr.com/ru/companies/selectel/articles/1013862/
💡 Вывод: Маркетинговый по форме, но полезный по структуре обзор корпоративного AI. Зерно: компании переходят от хаотичного использования LLM к централизованным корпоративным порталам с RBAC, квотами и биллингом. Shadow AI становится реальным драйвером создания внутренних GenAI-сред — не из любви к технологиям, а из страха потери контроля над корпоративными данными. AI-агенты в продакшн — это микросервис, которому нужен жизненный цикл, версионирование и CI/CD, а не просто промпт в блокноте.
📰 Как мы подружили DataLens и OpenMetadata: архитектура, код и подводные камни
🔗 https://habr.com/ru/companies/magnit/articles/1015708/
💡 Вывод: Команда DWH Magnit написала ingestion-коннектор DataLens → OpenMetadata с нуля и выложила в открытый доступ. Практический кейс: BI-объекты (дашборды, чарты, датасеты) вытащены в общий граф метаданных с lineage-цепочками. Главный урок — ingestion на реальном объёме немедленно упирается в rate limits и scope management, поэтому operational-параметры (задержки, ретраи, фильтрация коллекций) нужно закладывать в коннектор сразу, не после первого запуска на продовом контуре.
📰 Case for Self-Healing Data Observability in Converged Architectures
🔗 https://moderndata101.substack.com/p/self-healing-data-observability-in
💡 Вывод: Аргумент в пользу ARI-цикла (Anticipate → Remediate → Immunize) как архитектурного слоя качества данных, а не инструментального. Основная мысль: конвергированные платформы убрали швы между системами, но оставили observability в парадигме «оповестить человека» — это незаконченная архитектура. Самовосстанавливающаяся платформа не исключает инженера, а меняет его роль: от дежурного пожарного к проектировщику иммунной системы. Граница «что платформа решает сама, а что эскалирует» — это архитектурное решение, а не настройка порогов.
📰 Reference Data Management по-русски: что мы называем НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
💡 Вывод: Честная разборка терминологии: российское «НСИ» на практике = RDM + часть MDM + немного DQ — исторически потому, что отдельных систем не было, и всё сваливали в одну. Для CDO: смешение задач — это не культурная особенность, а архитектурный риск. Один инструмент «на всё» хорошо звучит на слайде и плохо работает в эксплуатации. Продукт, который претендует закрыть RDM, MDM и DQ одновременно, — кандидат на идиотский индекс.
📰 How Long Until We Call AI Agents Data Products
🔗 https://moderndata101.substack.com/p/data-products-as-ai-agents
💡 Вывод: AI-агент в продакшне соответствует всем критериям data product — пользователи, контракты качества, жизненный цикл, обратная связь. Большинство команд запускают агентов как эксперименты и удивляются, почему они деградируют. Обсервабилити ≠ логирование: каждый retry — это измеримое трение, каждый брошенный диалог — невидимый отток. Единственная работающая обратная связь — ручная аннотация разговоров с последующим маппингом паттернов на тикеты. Не дашборды — решения.
📰 Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения
🔗 https://habr.com/ru/articles/1014098/
💡 Вывод: Инженер пишет собственный OLTP-движок на Rust — с UNDO-log MVCC (как у InnoDB, Oracle, MSSQL), unified storage на БД и fail-closed поведением вместо тихой деградации. Главный тезис: если система под нагрузкой молчит и тянет — она врёт. Предсказуемый отказ с внятным SQLSTATE лучше, чем иллюзия, что «ещё дотянет». Для CDO: пример архитектурных решений на уровне storage engine, которые стоит знать при оценке собственных data-платформ.
📰 Как ML изменит бизнес в 2026 году: прогноз Selectel, GlowByte и Data Sapience
🔗 https://habr.com/ru/companies/selectel/articles/1013862/
💡 Вывод: Маркетинговый по форме, но полезный по структуре обзор корпоративного AI. Зерно: компании переходят от хаотичного использования LLM к централизованным корпоративным порталам с RBAC, квотами и биллингом. Shadow AI становится реальным драйвером создания внутренних GenAI-сред — не из любви к технологиям, а из страха потери контроля над корпоративными данными. AI-агенты в продакшн — это микросервис, которому нужен жизненный цикл, версионирование и CI/CD, а не просто промпт в блокноте.
📰 Как мы подружили DataLens и OpenMetadata: архитектура, код и подводные камни
🔗 https://habr.com/ru/companies/magnit/articles/1015708/
💡 Вывод: Команда DWH Magnit написала ingestion-коннектор DataLens → OpenMetadata с нуля и выложила в открытый доступ. Практический кейс: BI-объекты (дашборды, чарты, датасеты) вытащены в общий граф метаданных с lineage-цепочками. Главный урок — ingestion на реальном объёме немедленно упирается в rate limits и scope management, поэтому operational-параметры (задержки, ретраи, фильтрация коллекций) нужно закладывать в коннектор сразу, не после первого запуска на продовом контуре.
📰 Case for Self-Healing Data Observability in Converged Architectures
🔗 https://moderndata101.substack.com/p/self-healing-data-observability-in
💡 Вывод: Аргумент в пользу ARI-цикла (Anticipate → Remediate → Immunize) как архитектурного слоя качества данных, а не инструментального. Основная мысль: конвергированные платформы убрали швы между системами, но оставили observability в парадигме «оповестить человека» — это незаконченная архитектура. Самовосстанавливающаяся платформа не исключает инженера, а меняет его роль: от дежурного пожарного к проектировщику иммунной системы. Граница «что платформа решает сама, а что эскалирует» — это архитектурное решение, а не настройка порогов.
📰 Reference Data Management по-русски: что мы называем НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
💡 Вывод: Честная разборка терминологии: российское «НСИ» на практике = RDM + часть MDM + немного DQ — исторически потому, что отдельных систем не было, и всё сваливали в одну. Для CDO: смешение задач — это не культурная особенность, а архитектурный риск. Один инструмент «на всё» хорошо звучит на слайде и плохо работает в эксплуатации. Продукт, который претендует закрыть RDM, MDM и DQ одновременно, — кандидат на идиотский индекс.
📰 How Long Until We Call AI Agents Data Products
🔗 https://moderndata101.substack.com/p/data-products-as-ai-agents
💡 Вывод: AI-агент в продакшне соответствует всем критериям data product — пользователи, контракты качества, жизненный цикл, обратная связь. Большинство команд запускают агентов как эксперименты и удивляются, почему они деградируют. Обсервабилити ≠ логирование: каждый retry — это измеримое трение, каждый брошенный диалог — невидимый отток. Единственная работающая обратная связь — ручная аннотация разговоров с последующим маппингом паттернов на тикеты. Не дашборды — решения.
Хабр
Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения
В двух предыдущих статьях я писал о том, почему эксплуатация современных баз данных всё чаще превращается в борьбу не с данными, а со сложностью самой системы: Мы знаем как готовить БД. Но индустрия...
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-летний юбилей проекта, компания анонсировала кардинальные изменения в стратегии взаимодействия с сообществом.…