📚OpenEverest: платформа с открытым исходным кодом для автоматизации баз данных
Буквально недавно Percona объявила о том, что их продукт Percona Everest трансформируется в OpenEverest и становится opensource.
К сожалению, в моей среде обитания кубера нет, поэтому мне тяжело рассуждать насколько этот проект будет полезен современным DevOps специалистам. Это прекрасная тема для разработки НИР 😏
Помню с 2020-2023 на кафедре было много тем про Кубнетес. Каждый третий студент искал возможности его "улучшить". Думаю пришла пора вернуть подобные темы в список для защиты 😈
Буквально недавно Percona объявила о том, что их продукт Percona Everest трансформируется в OpenEverest и становится opensource.
OpenEverest — новый открытый проект от Percona, который представляет собой базу управления базами данных на Kubernetes. В ней объясняется, что OpenEverest — это модульная платформа для автоматического развёртывания, масштабирования, резервного копирования и восстановления кластеров БД (PostgreSQL, MySQL, MongoDB и др.) на Kubernetes-инфраструктуре, будь то облако или собственный сервер. Он использует Kubernetes-операторы и CRD, чтобы операции с базами выглядели как обычные, декларативные ресурсы Kubernetes, и цель проекта — уменьшить зависимость от проприетарных баз данных в облаке и упростить DBaaS-опыт
К сожалению, в моей среде обитания кубера нет, поэтому мне тяжело рассуждать насколько этот проект будет полезен современным DevOps специалистам. Это прекрасная тема для разработки НИР 😏
Помню с 2020-2023 на кафедре было много тем про Кубнетес. Каждый третий студент искал возможности его "улучшить". Думаю пришла пора вернуть подобные темы в список для защиты 😈
InfoQ
OpenEverest: Open Source Platform for Database Automation
Percona recently announced OpenEverest, an open-source platform for automated database provisioning and management that supports multiple database technologies. Launched initially as Percona Everest, OpenEverest can be hosted on any Kubernetes infrastructure…
❤1🔥1
📚 Разница между шардингом и секционированием
Опять, клик-бейтное же название статьи, согласитесь? Очень интересно было бы прочесть. Открываю, листаю и на лице... 😐
Хочется почитать про какие-то откровения что ли. А тут, ИИ бы написал интереснее 🤖.
Как пример:
На практике я не видел одновременное использование секционирования и шардирования. Возможно у меня малая насмотренность 👀. Буду повышать уровень 📈
Опять, клик-бейтное же название статьи, согласитесь? Очень интересно было бы прочесть. Открываю, листаю и на лице... 😐
Хочется почитать про какие-то откровения что ли. А тут, ИИ бы написал интереснее 🤖.
Как пример:
Секционирование (partitioning) — это когда у тебя одна база, но ты аккуратно разложил данные по ящикам. Быстрее искать, проще убирать старьё, меньше бардака. Всё по-прежнему живёт на одном сервере, транзакции и JOIN работают как раньше, просто база начинает «дышать свободнее», т.к. при выполнении запросов не надо проверять все ящики.
Шардинг (sharding) — это когда одного шкафа уже мало, и ты начинаешь расставлять ящики по разным комнатам. Даёт настоящее горизонтальное масштабирование и спасает при высоких нагрузках, но появляется новая боль: маршрутизация, кросс-шардовые запросы и вечный вопрос «а куда теперь переехали эти данные?».
Итого: секционирование — это уборка и организация, шардинг — переезд на новую квартиру. Обычно сначала наводят порядок, и только потом начинают "ломать стены".
На практике я не видел одновременное использование секционирования и шардирования. Возможно у меня малая насмотренность 👀. Буду повышать уровень 📈
Астрологи обьявили неделю Redis на этом канале
Почему Redis, а не Valkey, ведь это drop-in клон? Valkey мы очень любим, но кое-чего в Valkey нет. Верятностные структуры — про это мы начинаем серию образовательных постов. Автор серии - Константин Ратвин (МФТИ).
Часть #1. Введение в вероятностные структуры Redis
По мере развития проекта растет не только нагрузка, но и функциональность: появляются рекомендации, промо-механики, антифрод и новые требования к наблюдаемости. Вместе с этим увеличивается поток событий и измерений: значительную его часть начинают занимать клики, оформления заказов, метрики задержек.
И разработчикам, и аналитикам все чаще становятся нужны ответы «прямо сейчас»:
🤩 сколько было уникальных посетителей сегодня?
🤩 что стало трендом за последние минуты?
🤩 не пришло ли событие повторно?
🤩 какой p95/p99 у времени ответа или у времени оформления заказа?
Ответить на эти вопросы, не перегружая систему, позволяет класс техник, который называют вероятностными структурами данных. Они дают быстрый отклик и требуют мало памяти, но допускают небольшую и заранее предсказуемую погрешность.
В больших системах такие расчеты часто выносят в отдельный контур обработки, и это может сильно снижать оперативность как получения данных, так и внесения изменений. Однако Redis позволяет избежать этого усложнения, предлагая решение подобных задач прямо "из коробки”.
Так появились вероятностные структуры (их еще называют sketch-структурами) появились как ответ на практическую проблему: потоки данных растут быстрее, чем бюджет на память и хранение. Решение в том, чтобы хранить не исходные элементы, а их компактное представление, под которым обычно понимают:
🤩 Хеш-отпечатки и битовые/регистровые массивы
Элементы превращаются в несколько хеш-значений и «отмечаются» в битовой матрице/регистрах.
Пример: Bloom filter отмечает позиции битов, HyperLogLog обновляет регистры по «разрядам» хеша.
🤩 Сжатую статистику вместо сырого потока
Хранится не каждое значение, а агрегированное статистическое представление.
Пример: t-digest сохраняет сжатое приближение распределения, чтобы быстро отвечать на запросы вида p95/p99.
Вопросы, на которые способны ответить вероятностные структуры:
🤩 Сколько уникальных? → HyperLogLog
🤩 Видели ли мы это? → Bloom / Cuckoo
🤩 Что в топе? → Top-K
🤩 Сколько раз встречалось? → Count-Min Sketch
🤩 Какие p95/p99? → t-digest
5 разных структур данных - и все доступны в Redis из коробки. В следующих постах разберём каждый из них подробнее.
А всем, кому интересно изучить Redis на практике с автором этого поста, приходите на курс Devhands: Redis и Valkey, от основ к хайлоаду. Старт 10 марта, 6 недель: все необходимые структуры данных, масштабирование c Sentinel, кластерные возможности и многое другое.
🔥 уже используем возможности Redis для observability/аналитики
👍 спасибо, подучил
Почему Redis, а не Valkey, ведь это drop-in клон? Valkey мы очень любим, но кое-чего в Valkey нет. Верятностные структуры — про это мы начинаем серию образовательных постов. Автор серии - Константин Ратвин (МФТИ).
Часть #1. Введение в вероятностные структуры Redis
По мере развития проекта растет не только нагрузка, но и функциональность: появляются рекомендации, промо-механики, антифрод и новые требования к наблюдаемости. Вместе с этим увеличивается поток событий и измерений: значительную его часть начинают занимать клики, оформления заказов, метрики задержек.
И разработчикам, и аналитикам все чаще становятся нужны ответы «прямо сейчас»:
Ответить на эти вопросы, не перегружая систему, позволяет класс техник, который называют вероятностными структурами данных. Они дают быстрый отклик и требуют мало памяти, но допускают небольшую и заранее предсказуемую погрешность.
В больших системах такие расчеты часто выносят в отдельный контур обработки, и это может сильно снижать оперативность как получения данных, так и внесения изменений. Однако Redis позволяет избежать этого усложнения, предлагая решение подобных задач прямо "из коробки”.
Так появились вероятностные структуры (их еще называют sketch-структурами) появились как ответ на практическую проблему: потоки данных растут быстрее, чем бюджет на память и хранение. Решение в том, чтобы хранить не исходные элементы, а их компактное представление, под которым обычно понимают:
Элементы превращаются в несколько хеш-значений и «отмечаются» в битовой матрице/регистрах.
Пример: Bloom filter отмечает позиции битов, HyperLogLog обновляет регистры по «разрядам» хеша.
Хранится не каждое значение, а агрегированное статистическое представление.
Пример: t-digest сохраняет сжатое приближение распределения, чтобы быстро отвечать на запросы вида p95/p99.
Вопросы, на которые способны ответить вероятностные структуры:
5 разных структур данных - и все доступны в Redis из коробки. В следующих постах разберём каждый из них подробнее.
А всем, кому интересно изучить Redis на практике с автором этого поста, приходите на курс Devhands: Redis и Valkey, от основ к хайлоаду. Старт 10 марта, 6 недель: все необходимые структуры данных, масштабирование c Sentinel, кластерные возможности и многое другое.
🔥 уже используем возможности Redis для observability/аналитики
👍 спасибо, подучил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👀3
Украл текст из "соседней беседки". Автор мне разрешил 🤝
Делюсь с вами! 🖐 🍧
Делюсь с вами! 🖐 🍧
Эволюция PostgreSQL: 1986–2025
От исследовательской базы данных до корпоративной и готовой к ИИ платформе
Путь PostgreSQL — одна из самых выдающихся историй успеха в истории баз данных.
Изначально разработанная Майклом Стоунбрейкером в рамках проекта POSTGRES в 1986 году, она развилась из более ранней системы баз данных Ingres в Калифорнийском университете в Беркли. То, что начиналось как академическая исследовательская инициатива, превратилось в одну из самых мощных, расширяемых и готовых для корпоративных открытых баз данных в мире.
Вот краткий обзор его основных этапов:
1986 — Начало проекта POSTGRES (UC Berkeley)
1994 – POSTGRES95 – добавлена поддержка SQL
1996 – версия 6.0 – Переименована в PostgreSQL и Глобальная группа разработки PostgreSQL (PGDG)
2000 – версия 7.0 – улучшения MVCC и WAL
2005 – версия 8.0 – поддержка Windows, PITR, Tablespaces
2008 – версия 8.3 – Полнотекстовый поиск, интегрированный в ядро
2010 – версия 9.0 – Потоковое воспроизведение
2011 – версия 9.1 – Синхронная репликация
2013 – версия 9.3 – Материализированные просмотры, JSON
2016 – версия 9.6 – Параллельный запрос
2017 – версия 10 – Логическая репликация, декларативное разбиение
2018 – версия 11 – Улучшенное разбиение и параллелизм
2019 – версия 12 – Сгенерированные столбцы, РЕИНДЕКС ОДНОВРЕМЕННО
2020 – версия 13 – дедупликация B-дерева, прирост производительности VACUUM
2021 – версия 14 – Параллелизм и улучшения индексации
2022 – версия 15 – команда MERGE, улучшения логической репликации
2023 – версия 16 – Улучшения производительности, мониторинг, логическое декодирование в режиме ожидания
2024 – версия 17 – Высокая доступность, производительность и улучшения VACUUM
2025 – версия 18 – Улучшенная логическая репликация, зрелость экосистемы векторного поиска, ИИ и корпоративный фокус
От академических исследований до поддержки финансовых систем, SaaS-платформ, правительств и рабочих нагрузок, управляемых искусственным интеллектом — PostgreSQL продолжает доказать, почему его часто называют:
«Самая продвинутая в мире реляционная база данных с открытым исходным кодом.»
Как DBA и разработчики, мы стали свидетелями того, как PostgreSQL стал полнофункциональной альтернативой настоящей корпоративной, облачной и поддержкой искусственного интеллекта платформы.
Эволюция продолжается.
❤4
📚 Сообщество MySQL призывает к обсуждению будущего экосистемы
Если кратко, то сообщество MySQL обзавидоволось PostgeSQL 🥲 и хочется так же бурно развиваться как последние. Но... Oracle вставляет палки в колеса и не дает расти🤬. Товарищи предложили создать независимый некоммерческий фонд развития MySQL и передать этому фонду все права на MySQL. Это даст возможность забустить 100500 доработок в проект и потеснить PostgreSQL на пьедестале самого динамично развивающейся OSS СУБД 🥋.
Срок ответа 31 марта. Осталось недолго ждать финальной развязки ✌️.
Если кратко, то сообщество MySQL обзавидоволось PostgeSQL 🥲 и хочется так же бурно развиваться как последние. Но... Oracle вставляет палки в колеса и не дает расти🤬. Товарищи предложили создать независимый некоммерческий фонд развития MySQL и передать этому фонду все права на MySQL. Это даст возможность забустить 100500 доработок в проект и потеснить PostgreSQL на пьедестале самого динамично развивающейся OSS СУБД 🥋.
Срок ответа 31 марта. Осталось недолго ждать финальной развязки ✌️.
BetaNews
MySQL community calls for discussions on the future of the ecosystem
Earlier this month Oracle put out a blog post on how it plans to expand the community edition of MySQL. In response the MySQL community has now published an
😱3
Forwarded from Архитектор Данных
Data Engineer не нужен
А вот правда. Он не приносит видимого результата, единственная его ценность в том что 10 аналитикам комфортнее, если у них есть 1 инженер.
И если раньше это соотношение было 3-5 к 1, то уже сейчас стремится к 10 аналитиков на одного инженера данных.
Появление фреймворков вроде dbt, sql mesh и такого скила как analytics engineer этому способствует. Следующий шаг - распространение класса решений для быстрой GUI-AI наладке ETL и модели данных.
И если до Low-Code пока что далековато, то Low-DE аналитика уже вполне реальность.
А вот правда. Он не приносит видимого результата, единственная его ценность в том что 10 аналитикам комфортнее, если у них есть 1 инженер.
И если раньше это соотношение было 3-5 к 1, то уже сейчас стремится к 10 аналитиков на одного инженера данных.
Появление фреймворков вроде dbt, sql mesh и такого скила как analytics engineer этому способствует. Следующий шаг - распространение класса решений для быстрой GUI-AI наладке ETL и модели данных.
И если до Low-Code пока что далековато, то Low-DE аналитика уже вполне реальность.
Я очень жду профессию из разряда ИИ-психолог. Человек, который на "серьезных щах" будет копаться в обученных моделях и корректировать их поведение. А может такие специалисты уже есть?
С пятницей!
#mems
С пятницей!
#mems
😁8❤1
Наткнулся на статью по проектированию реляционных баз данных, а затем на его видеоролик на ютубе 🎦 .
Весь курс по сути пересказ книги: "Grokking Relational Database Design".
Удовольствие на 6 часов🥱. Нууу, дай думаю всё-таки посмотрю и послушаю 👂. Вдруг что-то интересное скажут. Интересно, чему учат иностранцы других иностранцев 🤺.
В целом, материал хороший, но всё это уже было рассказано 100500 раз. Никаких откровений или нового взгляда. Почему-то автор даже JSON игнорирует в своем курсе 🤔.
Получается, что с одно стороны - это хороший базовый, вводный учебник по проектированию. А с другой, он оторвал от современных реалий 🤯.
Я бы в книгах/курсах по проектированию хотел бы видеть такие темы:
Тогда бы курс выглядел более практичным и полезным .
А как вы думайте❔
Весь курс по сути пересказ книги: "Grokking Relational Database Design".
Удовольствие на 6 часов🥱. Нууу, дай думаю всё-таки посмотрю и послушаю 👂. Вдруг что-то интересное скажут. Интересно, чему учат иностранцы других иностранцев 🤺.
В целом, материал хороший, но всё это уже было рассказано 100500 раз. Никаких откровений или нового взгляда. Почему-то автор даже JSON игнорирует в своем курсе 🤔.
Получается, что с одно стороны - это хороший базовый, вводный учебник по проектированию. А с другой, он оторвал от современных реалий 🤯.
Я бы в книгах/курсах по проектированию хотел бы видеть такие темы:
1. Партиционирование, шардинг
2. Влияние репликаций на модель данных
3. Правила эволюции схемы данных
4. Полуструктурные данные (JSON/XML), гибридное моделирование "в реляционное" vs "в документ".
5. Хотя бы кратенько про моделирование схем для OLAP нагрузок(dimensional modeling: star/snowflake, SCD, витрины/слои)
6. Практики по безопасности/комплаенса на уровне схемы: (row-level security аудит, политики хранения/удаления)
7. Правила проектирования распределенных схем данных
Тогда бы курс выглядел более практичным и полезным .
А как вы думайте❔
freeCodeCamp.org
Learn Relational Database Design
Relational databases are used in many different types of software. We just posted a course on the freeCodeCamp.org YouTube channel that will help you learn relational database design from the ground up. This course covers SQL fundamentals, entity-rel...
❤1👍1
🚶♂️➡️В продолжении темы проектирования схем баз данных.
Недавно была статья на Хабре
25 железных правил проектирования баз данных в PostgreSQL
Она собрала более 95+ лайков и свыше 190 комментов.
На мой взгляд - это успех автора 😎! Если учесть, что это "из песочницы", то еще больший успех 🎰!
Однако, во всех чатах, где я состою, статью откровенно "зас***и" 💩.
Комментарии довольно жесткие 👊.
Примечательно, что опровержения или развернутого комментария "почему какое-то правило не работает" никто не дал 🫤. Ответ на претензию "почему" ответ такой:
Очередной раз ловлю себя на мысли, что надо написать статью или серию статей по проектированию схем данных для современных систем 📝. Причем видимо надо вводить какую-то классификацию этих систем и набор правил под каждую.
Повод посидеть, подумать на тему кому бы делегировать эту задачу? 😎
Есть желающие? 😉
Недавно была статья на Хабре
25 железных правил проектирования баз данных в PostgreSQL
Она собрала более 95+ лайков и свыше 190 комментов.
На мой взгляд - это успех автора 😎! Если учесть, что это "из песочницы", то еще больший успех 🎰!
Однако, во всех чатах, где я состою, статью откровенно "зас***и" 💩.
Написал сплошной бред, который почти никогда не бьется с продакшн системами. Все эти правила валидны для "школьной скамьи" и т.п.
Комментарии довольно жесткие 👊.
Примечательно, что опровержения или развернутого комментария "почему какое-то правило не работает" никто не дал 🫤. Ответ на претензию "почему" ответ такой:
"лень писать", "эти знания за которые люди платят деньги на мастер-классах/воркшопах".Получается забавная проблема 🙁. "Кривая" и откровенно ложная статья набирает огромную популярность у сообщества, а потом мы на проде ловим такое 🔥... от чего челюсть не может встать на место несколько часов 😱.
Очередной раз ловлю себя на мысли, что надо написать статью или серию статей по проектированию схем данных для современных систем 📝. Причем видимо надо вводить какую-то классификацию этих систем и набор правил под каждую.
Повод посидеть, подумать на тему кому бы делегировать эту задачу? 😎
Есть желающие? 😉
❤4
📚Хочу поделиться образовательным сайтом от коллеги, Александра Поломодова.
Довольно интересная история создания этого сайта 😊
Если не вдаваться в подробности, то это электронная вариация его потенциальной книги, которую он прогнал через сервис lovable и в итоге получился сайт.
Для меня и для вас самым интересным и полезным должен стать раздел 8 Базы Данных.
🚧 p.s. всё информация о базах данных там должна подвергаться сомнению!🫤 Автор книги "Путеводитель по базам данных" в комментариях к посту уже изложил своё мнение.
Довольно интересная история создания этого сайта 😊
Если не вдаваться в подробности, то это электронная вариация его потенциальной книги, которую он прогнал через сервис lovable и в итоге получился сайт.
Для меня и для вас самым интересным и полезным должен стать раздел 8 Базы Данных.
🚧 p.s. всё информация о базах данных там должна подвергаться сомнению!🫤 Автор книги "Путеводитель по базам данных" в комментариях к посту уже изложил своё мнение.
System Design Space
System Design Space — Главная, граф знаний, треки и материалы
Главная страница System Design Space: быстрый старт, граф знаний, библиотека материалов, персональные треки и трекинг прогресса.
🔥8❤1
Я часто вижу непонимание в глазах слушателей, когда речь заходит о терминах «структура», «полуструктура» и «неструктурированные данные». Поэтому решил написать короткий пост
Представьте: База данных - это огромный ресторан, а мы - повара, которым нужно быстро находить ингредиенты.
🍏 Структурированные данные — «идеальный холодильник»
Всё разложено по полкам и контейнерам, у каждого продукта своя ячейка и подпись. Нужно "все огурцы за вчера" - открыли нужную полку (таблицу) и мгновенно нашли.
🤔 SQL (PostgreSQL, MySQL и т.д.)
➕ быстрый поиск, строгая логика
➖ менять схему больнее, т.к. нужно перестраивать полки
🍕 Полуструктурированные данные — «коробка с заказом»
Вы заказали пиццу. В коробке лежит сама пицца, пакетик с соусом, перец, салфетки и рекламка. Есть общая логика и ярлыки, но набор и форма могут меняться. Сегодня есть оливки - завтра нет.
Это как JSON/XML, ключи есть, но структура может быть какой угодно.
🤔 NoSQL, JSON/XML/YAML
➕ легко добавлять новые поля
➖ без дисциплины начинается хаос 🪬
📦 Неструктурированные данные — «склад с коробками без подписей»
Это когда на складе ресторана стоит гора коробок и пакетов без нормальных наклеек и сортировки. Внутри может быть что угодно: мешок специй, куча чеков от поставщиков, распечатки меню, записки от шефа, фото блюда, инструкции к оборудованию. Хранилище знает только внешнее (размер/дата), а смысл приходится "доставать" отдельно (поиск, разметка, ML/LLM).
🤔 Data Lakes, облачные хранилища, векторные БД
➕ можно хранить всё
➖ чтобы найти смысл, нужно отдельно индексировать/анализировать
Архитектурные "премудрости" 🧙♂️:
Структура - это дорого строить, но дешево искать.
Неструктура - дешево хранить, но дорого понимать 😏.
Представьте: База данных - это огромный ресторан, а мы - повара, которым нужно быстро находить ингредиенты.
🍏 Структурированные данные — «идеальный холодильник»
Всё разложено по полкам и контейнерам, у каждого продукта своя ячейка и подпись. Нужно "все огурцы за вчера" - открыли нужную полку (таблицу) и мгновенно нашли.
🤔 SQL (PostgreSQL, MySQL и т.д.)
➕ быстрый поиск, строгая логика
➖ менять схему больнее, т.к. нужно перестраивать полки
🍕 Полуструктурированные данные — «коробка с заказом»
Вы заказали пиццу. В коробке лежит сама пицца, пакетик с соусом, перец, салфетки и рекламка. Есть общая логика и ярлыки, но набор и форма могут меняться. Сегодня есть оливки - завтра нет.
Это как JSON/XML, ключи есть, но структура может быть какой угодно.
🤔 NoSQL, JSON/XML/YAML
➕ легко добавлять новые поля
➖ без дисциплины начинается хаос 🪬
📦 Неструктурированные данные — «склад с коробками без подписей»
Это когда на складе ресторана стоит гора коробок и пакетов без нормальных наклеек и сортировки. Внутри может быть что угодно: мешок специй, куча чеков от поставщиков, распечатки меню, записки от шефа, фото блюда, инструкции к оборудованию. Хранилище знает только внешнее (размер/дата), а смысл приходится "доставать" отдельно (поиск, разметка, ML/LLM).
🤔 Data Lakes, облачные хранилища, векторные БД
➕ можно хранить всё
➖ чтобы найти смысл, нужно отдельно индексировать/анализировать
Архитектурные "премудрости" 🧙♂️:
Структура - это дорого строить, но дешево искать.
Неструктура - дешево хранить, но дорого понимать 😏.
🔥12❤7🍾3
Видео вчерашнего стрима с Никитой Кречетовым, Avito:
https://www.youtube.com/watch?v=bJnDkDAoOUw
Некоторое «мясо» по темам интервью (в видео на самом деле ещё больше инсайтов).
Масштаб: ~2700 хранилищ Redis, среди них сотни шардированных инсталляций. Это “внутреннее облако”: продуктовые команды не думают про жизненный цикл БД (создание, окружения, секреты, аккаунты, доступы) — это делает платформенная команда.
Почему исторически не Redis Cluster. Присматривались к Redis Cluster пробовали с Redis 5 → 7, но считали технологию незрелой для больших масштабов, требовалось перепилить компоненты платформы, клиентские библиотеки созрели не сразу.
Выбор Valkey vs KeyDB vs Dragonfly
• Лицензию Redis “закрыли” в марте 2024.
• Valkey: первый стабильный релиз — апрель 2024; форк Redis, бинарно близкий, но вначале было неясно, “взлетит ли” комьюнити.
• Dragonfly не тестировали: не подошла лицензия.
• KeyDB рассматривали всерьёз (развивался с 2019, поддержка/участие Snapchat), интересен master-master / active replication (идея распределять write-нагрузку без шардирования данных) + честная “многопоточность” через несколько event loop (условно “несколько Redis в потоках”), давала выигрыш на 3–4 потоках.
• Но в процессе выяснилось, что KeyDB фактически не поддерживается/не развивается, и примерно в 2025 приняли окончательное решение перейти на Valkey.
Производительность: конкретные цифры
• Оптимальная конфигурация по тестам: 3–4 потока.
• На тестах Valkey 8.x давал: до +50% к максимальному RPS/пропускной способности относительно Redis 7.2.8 (при одинаковом CPU-лимите, “CPU под завязку”), относительно KeyDB — ещё несколько процентов выигрыша.
• Узкое место часто было не CPU, а количество соединений и “пиковые” коннекты: Valkey 8.x держал их более линейно и предсказуемо (за счёт переработки многопоточности).
“Неожиданность” с обновлением версий
• Тестировали на 8.0.2 (стабильно, хороший выигрыш).
• Попробовали обновить часть кластеров на 8.1.0: на синтетике “норм”, но на реальных данных хуже latency (в среднем до ~1.5×), быстро откатились обратно на 8.0.2.
• Реальные паттерны нагрузки сложно воспроизвести на стенде, часть проблем проявляется только в проде.
Почему поверх Cluster построили ещё один “кластер” (sidecar + Raft)
Valkey/Redis Cluster “умный”, но для платформы не хватает критичных функций:
• Авто-учётки/доступы, интеграции с безопасностью.
• Автоматический решардинг при изменении топологии (добавление/удаление узлов).
• Умная поддержка зон доступности (AZ): важно равномерно держать master-ноды по зонам, кластер не умеет “умный фейловер” с учётом AZ.
🔥 спасибо за интересный платформенный кейс
👍 из полей доноситсяналей valkey!
—
Обучение Devhands Redis/Valkey: https://devhands.io/rv
Канал Алексея Рыбака: https://t.me/rybakalexey
Канал Avito Tech: https://t.me/avitotech
Канал Avito Data Tech: https://t.me/avitotech
https://www.youtube.com/watch?v=bJnDkDAoOUw
Некоторое «мясо» по темам интервью (в видео на самом деле ещё больше инсайтов).
Масштаб: ~2700 хранилищ Redis, среди них сотни шардированных инсталляций. Это “внутреннее облако”: продуктовые команды не думают про жизненный цикл БД (создание, окружения, секреты, аккаунты, доступы) — это делает платформенная команда.
Почему исторически не Redis Cluster. Присматривались к Redis Cluster пробовали с Redis 5 → 7, но считали технологию незрелой для больших масштабов, требовалось перепилить компоненты платформы, клиентские библиотеки созрели не сразу.
Выбор Valkey vs KeyDB vs Dragonfly
• Лицензию Redis “закрыли” в марте 2024.
• Valkey: первый стабильный релиз — апрель 2024; форк Redis, бинарно близкий, но вначале было неясно, “взлетит ли” комьюнити.
• Dragonfly не тестировали: не подошла лицензия.
• KeyDB рассматривали всерьёз (развивался с 2019, поддержка/участие Snapchat), интересен master-master / active replication (идея распределять write-нагрузку без шардирования данных) + честная “многопоточность” через несколько event loop (условно “несколько Redis в потоках”), давала выигрыш на 3–4 потоках.
• Но в процессе выяснилось, что KeyDB фактически не поддерживается/не развивается, и примерно в 2025 приняли окончательное решение перейти на Valkey.
Производительность: конкретные цифры
• Оптимальная конфигурация по тестам: 3–4 потока.
• На тестах Valkey 8.x давал: до +50% к максимальному RPS/пропускной способности относительно Redis 7.2.8 (при одинаковом CPU-лимите, “CPU под завязку”), относительно KeyDB — ещё несколько процентов выигрыша.
• Узкое место часто было не CPU, а количество соединений и “пиковые” коннекты: Valkey 8.x держал их более линейно и предсказуемо (за счёт переработки многопоточности).
“Неожиданность” с обновлением версий
• Тестировали на 8.0.2 (стабильно, хороший выигрыш).
• Попробовали обновить часть кластеров на 8.1.0: на синтетике “норм”, но на реальных данных хуже latency (в среднем до ~1.5×), быстро откатились обратно на 8.0.2.
• Реальные паттерны нагрузки сложно воспроизвести на стенде, часть проблем проявляется только в проде.
Почему поверх Cluster построили ещё один “кластер” (sidecar + Raft)
Valkey/Redis Cluster “умный”, но для платформы не хватает критичных функций:
• Авто-учётки/доступы, интеграции с безопасностью.
• Автоматический решардинг при изменении топологии (добавление/удаление узлов).
• Умная поддержка зон доступности (AZ): важно равномерно держать master-ноды по зонам, кластер не умеет “умный фейловер” с учётом AZ.
🔥 спасибо за интересный платформенный кейс
👍 из полей доносится
—
Обучение Devhands Redis/Valkey: https://devhands.io/rv
Канал Алексея Рыбака: https://t.me/rybakalexey
Канал Avito Tech: https://t.me/avitotech
Канал Avito Data Tech: https://t.me/avitotech
👍1🔥1
Книга: «Архитектуры данных: современные решения для любых задач»
Свежий перевод западной литературу Orelly от нашего издательства Питер.
Примечательно, что книгу рецензировали в клубе рецензентов ИТ-литературы ReadITClub.
Судя по сайту данный клуб принадлежи КРОКу и получает дополнительную поддержку от российских издательств технической литературы.
Здорово, что у нас существует подобный клуб 💪! Я до того, как открыл книгу ничего об этом не знал.
❇️ Коротко про книгу.
В ней 288 страниц — надеюсь, прочитаю быстро 😁
Состоит из 4-х частей:
Сегодня — Часть I, в ней 3 главы и 3 ключевые мысли:
1️⃣ Ценность важнее “объёмов”.
Big Data — это не “очень много данных”, а любые данные, которые дают эффект. Автор объясняет 6V: Volume, Variety, Velocity, Veracity, Variability и главное — Value. Остальные V важны ровно настолько, насколько помогают (или мешают) получить ценность.
2️⃣ Универсальной архитектуры нет.
Показывается “ландшафт” подходов: RDW → Data Lake → MDW → Fabric / Lakehouse / Mesh. Выбор зависит от нагрузок, типов данных, SLA, безопасности, доступности и того, как данные будут потребляться (в т.ч. self-service).
3️⃣ Выбор архитектуры — это процесс.
Предлагается ADS (architecture design session): собрать бизнес + ИТ и зафиксировать цели/ограничения (latency, объёмы, HA/DR, источники, ML и т.д.). По опыту: без практики и фасилитатора/ментора такую сессию легко "запороть". Было бы интересно на таких сессиях поприсутвовать...
❇️ Итоговая мысль
Сначала формулируем какую ценность хотим получить и фиксируем реальные требования/ограничения. Затем проводим дизайн-сессию со стейкхолдерами, чтобы осознанно выбрать архитектурный подход согласно задаче.
⚠️ Забавный исторический факт.
Data Lake появились в 2010-х годах. Самые яркие представители это Hadoop, Cloudera, Hortonworks и MapR. Однако, все эти решения (кроме Hadoop) провались в коммерческом плане. Причина банальная, неудобный и сложный инструментарий для извлечения данных (создание отчетов). Последним гвоздем стало то, что все любят SQL, транзакции и так нужный в корпоративной среде аудит.
В 2020-х случился "Ренессанс" с пришествием табличных форматов/транзакционными слоями вроде Delta Lake (и аналогов Iceberg/Hudi). Были добавлены transaction log, операции MERGE/UPDATE/DELETE, контроль схемы и версионирование (time travel). Таким образом, озеро стали гораздо ближе к требованиям BI и аналитики.
Очередное подтверждение того, что от SQL и реляционной теории нам не избавиться никогда 😈😈😈
Свежий перевод западной литературу Orelly от нашего издательства Питер.
Примечательно, что книгу рецензировали в клубе рецензентов ИТ-литературы ReadITClub.
Судя по сайту данный клуб принадлежи КРОКу и получает дополнительную поддержку от российских издательств технической литературы.
Здорово, что у нас существует подобный клуб 💪! Я до того, как открыл книгу ничего об этом не знал.
❇️ Коротко про книгу.
В ней 288 страниц — надеюсь, прочитаю быстро 😁
Состоит из 4-х частей:
Часть I. Основные понятия
Часть II. Общие понятия архитектуры данных
Часть III. Архитектуры данных
Часть IV. Люди, процессы и технологии
Сегодня — Часть I, в ней 3 главы и 3 ключевые мысли:
1️⃣ Ценность важнее “объёмов”.
Big Data — это не “очень много данных”, а любые данные, которые дают эффект. Автор объясняет 6V: Volume, Variety, Velocity, Veracity, Variability и главное — Value. Остальные V важны ровно настолько, насколько помогают (или мешают) получить ценность.
2️⃣ Универсальной архитектуры нет.
Показывается “ландшафт” подходов: RDW → Data Lake → MDW → Fabric / Lakehouse / Mesh. Выбор зависит от нагрузок, типов данных, SLA, безопасности, доступности и того, как данные будут потребляться (в т.ч. self-service).
3️⃣ Выбор архитектуры — это процесс.
Предлагается ADS (architecture design session): собрать бизнес + ИТ и зафиксировать цели/ограничения (latency, объёмы, HA/DR, источники, ML и т.д.). По опыту: без практики и фасилитатора/ментора такую сессию легко "запороть". Было бы интересно на таких сессиях поприсутвовать...
❇️ Итоговая мысль
Сначала формулируем какую ценность хотим получить и фиксируем реальные требования/ограничения. Затем проводим дизайн-сессию со стейкхолдерами, чтобы осознанно выбрать архитектурный подход согласно задаче.
⚠️ Забавный исторический факт.
Data Lake появились в 2010-х годах. Самые яркие представители это Hadoop, Cloudera, Hortonworks и MapR. Однако, все эти решения (кроме Hadoop) провались в коммерческом плане. Причина банальная, неудобный и сложный инструментарий для извлечения данных (создание отчетов). Последним гвоздем стало то, что все любят SQL, транзакции и так нужный в корпоративной среде аудит.
В 2020-х случился "Ренессанс" с пришествием табличных форматов/транзакционными слоями вроде Delta Lake (и аналогов Iceberg/Hudi). Были добавлены transaction log, операции MERGE/UPDATE/DELETE, контроль схемы и версионирование (time travel). Таким образом, озеро стали гораздо ближе к требованиям BI и аналитики.
Очередное подтверждение того, что от SQL и реляционной теории нам не избавиться никогда 😈😈😈
🔥4
📚Продолжим разбор книги, «Архитектуры данных: современные решения для любых задач».
Поговорим про Часть II. Общие понятия архитектуры данных.
Если часть I отвечает на вопрос "зачем нам архитектура", то часть II — это набор базовых кирпичей, из которых потом собираются любые современные платформы данных. Например, где хранить, как обрабатывать, как моделировать и как доставлять данные.
4️⃣ Хранение: RDW и Data Lake — это разные режимы работы
RDW - про управляемую отчётность и "единую версию правды", Data Lake — про гибкость и schema-on-read. На практике все определяют требования, где-то RDW вполне достаточно.
5️⃣ Lake без структуры быстро превращается в swamp → нужны уровни
Озеро надо организовывать слоями (raw → conformed → cleansed и т.д.). Это прямо перекликается с популярной сегодня medallion-логикой (bronze/silver/gold).
Иногда хочется почитать про то как люди превращают "светлую и чистую" идею с озером данных во что-то "мерзкое" и дурно пахнующее с явным юмористическим акцентом😁. Эх, статей по Data Swamp очень мало и почти все скучные...
6️⃣ "Платформа данных" — это не только хранилище
Кроме RDW/Lake нужны вещи, которые в реальных проектах постоянно всплывают: витрины (data marts), ODS для оперативной отчётности, data hub для интеграций, а ещё обязательные процессы вроде MDM, виртуализации и каталогов.
Помнится СУБД Tarantool от VK считает себя платформой данных. Обладает ли она этим свойствами? Надо покопать...
7️⃣ OLTP/OLAP, SMP/MPP, streaming, polyglot persistence
Глава является связующей между "проектирование данных" и архитектурным решением. Разделение транзакционных и аналитических контуров, выбор масштаба (SMP vs MPP), паттерны лямбда/каппа под batch+stream и идея polyglot persistence (под разные типы данных — разные хранилища).
8️⃣ Моделирование никуда не делось — просто стало "прагматичнее"
Реляционная модель, "звезда/снежинка", CDM, Data Vault, Kimball vs Inmon — это не просто академические идеи, а способы договориться, как бизнес будет потреблять данные (особенно в BI).
9️⃣ Ingestion: ETL/ELT — не религия, плюс появился reverse ETL
ETL vs ELT - это баланс под заданные ограничения. Мне очень понравилась идея reverse ETL - возвращать подготовленные данные из хранилища обратно в операционные системы, чтобы данные реально работали "в поле". Очень хочется посмотреть на такой процесс в продакшн среде. Жаль, что сейчас я немного далек от этого.
Реальность как всегда иная 🧪. Исходя из моего опыта, заказчику всегда нужно всё и без ограничений и за недорого. Поэтому запускается процесс гибридизации ежа🦔, ужа🐍 и прочих зверят🦈🐗🦜. В итоге получается "платформа данных", которая уникальна для каждого заказчика 🌈.
Занавес
Поговорим про Часть II. Общие понятия архитектуры данных.
Если часть I отвечает на вопрос "зачем нам архитектура", то часть II — это набор базовых кирпичей, из которых потом собираются любые современные платформы данных. Например, где хранить, как обрабатывать, как моделировать и как доставлять данные.
4️⃣ Хранение: RDW и Data Lake — это разные режимы работы
RDW - про управляемую отчётность и "единую версию правды", Data Lake — про гибкость и schema-on-read. На практике все определяют требования, где-то RDW вполне достаточно.
5️⃣ Lake без структуры быстро превращается в swamp → нужны уровни
Озеро надо организовывать слоями (raw → conformed → cleansed и т.д.). Это прямо перекликается с популярной сегодня medallion-логикой (bronze/silver/gold).
Иногда хочется почитать про то как люди превращают "светлую и чистую" идею с озером данных во что-то "мерзкое" и дурно пахнующее с явным юмористическим акцентом😁. Эх, статей по Data Swamp очень мало и почти все скучные...
6️⃣ "Платформа данных" — это не только хранилище
Кроме RDW/Lake нужны вещи, которые в реальных проектах постоянно всплывают: витрины (data marts), ODS для оперативной отчётности, data hub для интеграций, а ещё обязательные процессы вроде MDM, виртуализации и каталогов.
Помнится СУБД Tarantool от VK считает себя платформой данных. Обладает ли она этим свойствами? Надо покопать...
7️⃣ OLTP/OLAP, SMP/MPP, streaming, polyglot persistence
Глава является связующей между "проектирование данных" и архитектурным решением. Разделение транзакционных и аналитических контуров, выбор масштаба (SMP vs MPP), паттерны лямбда/каппа под batch+stream и идея polyglot persistence (под разные типы данных — разные хранилища).
8️⃣ Моделирование никуда не делось — просто стало "прагматичнее"
Реляционная модель, "звезда/снежинка", CDM, Data Vault, Kimball vs Inmon — это не просто академические идеи, а способы договориться, как бизнес будет потреблять данные (особенно в BI).
9️⃣ Ingestion: ETL/ELT — не религия, плюс появился reverse ETL
ETL vs ELT - это баланс под заданные ограничения. Мне очень понравилась идея reverse ETL - возвращать подготовленные данные из хранилища обратно в операционные системы, чтобы данные реально работали "в поле". Очень хочется посмотреть на такой процесс в продакшн среде. Жаль, что сейчас я немного далек от этого.
Небольшой вывод: без управления данными (качество, безопасность, комплаенс, ответственность) любая архитектура деградирует — особенно озёра и ELT-пайплайны.
Реальность как всегда иная 🧪. Исходя из моего опыта, заказчику всегда нужно всё и без ограничений и за недорого. Поэтому запускается процесс гибридизации ежа🦔, ужа🐍 и прочих зверят🦈🐗🦜. В итоге получается "платформа данных", которая уникальна для каждого заказчика 🌈.
Занавес
📚Продолжим разбор книги, «Архитектуры данных: современные решения для любых задач».
Сегодня про Часть III. Общие понятия архитектуры данных.
Часть III можно представить как дорожную карту эволюции платформы данных: MDW → Data Fabric → Lakehouse → Data Mesh. Главный вывод здесь простой:
🔟 MDW (modern data warehouse) - уровень по умолчанию для большинства компаний: сочетание озера (гибкость, разные типы данных, data science) и warehouse/DWH (управляемый BI, "единственная версия правды"). На практике это компромисс между скоростью внедрения и качеством потребления.
1️⃣1️⃣Data Fabric - эволюция MDW для повышения доступности и безопасности данных. Обычно сюда относят: политики доступа, каталог/метаданные, MDM, виртуализацию, real-time, API.
Идея в том, чтобы данные были не просто "где-то там лежащими", а находимыми, безопасными и пригодными к использованию в масштабе организации. Не надо делать отчеты только для себя любимого, надо думать о других 😊
1️⃣2️⃣Lakehouse - попытка уйти от связки lake + DWH и сделать ставку на одно хранилище: оставить озеро, но добавить таблично-транзакционный слой (Delta Lake / Iceberg / Hudi), чтобы появились нормальные обновления, версионирование, контроль схемы и более предсказуемая эксплуатация.
Да, копий данных меньше, следовательно, контур проще 😉. Но governance и дисциплина никуда не исчезают🤨.
1️⃣3️⃣Data Mesh - это скорее организационная модель, чем технология: домены владеют данными, данные как продукт, self-service платформа и федеративное governance. Похоже чем-то на DevOps, концепция культурны и всё такое. Поэтому трактую ее по принципу: "я так вижу…" 💃👀
По книге: mesh подходит не всем и чаще всего внедряется постепенно (hub-and-spoke), а не "с наскока" в новый мир, минуя предыдущие стадии.
1️⃣4️⃣Практический takeaway: в современных проектах чаще выигрывает гибрид: MDW как основа + "fabric-capabilities" как зрелость, lakehouse - там, где оправдан "single storage", а mesh — только если компания реально готова к DDD и понимает цену изменений.
Сегодня про Часть III. Общие понятия архитектуры данных.
Теперь, когда базовые понятия освоены, можно переходить к мясу 🥩. Цветочки закончились — начинаются ягодки 🙂
Часть III можно представить как дорожную карту эволюции платформы данных: MDW → Data Fabric → Lakehouse → Data Mesh. Главный вывод здесь простой:
Архитектура - это не "выбор раз и навсегда", а наращивание способностей под меняющиеся со временем требования.
🔟 MDW (modern data warehouse) - уровень по умолчанию для большинства компаний: сочетание озера (гибкость, разные типы данных, data science) и warehouse/DWH (управляемый BI, "единственная версия правды"). На практике это компромисс между скоростью внедрения и качеством потребления.
1️⃣1️⃣Data Fabric - эволюция MDW для повышения доступности и безопасности данных. Обычно сюда относят: политики доступа, каталог/метаданные, MDM, виртуализацию, real-time, API.
Идея в том, чтобы данные были не просто "где-то там лежащими", а находимыми, безопасными и пригодными к использованию в масштабе организации. Не надо делать отчеты только для себя любимого, надо думать о других 😊
1️⃣2️⃣Lakehouse - попытка уйти от связки lake + DWH и сделать ставку на одно хранилище: оставить озеро, но добавить таблично-транзакционный слой (Delta Lake / Iceberg / Hudi), чтобы появились нормальные обновления, версионирование, контроль схемы и более предсказуемая эксплуатация.
Да, копий данных меньше, следовательно, контур проще 😉. Но governance и дисциплина никуда не исчезают🤨.
1️⃣3️⃣Data Mesh - это скорее организационная модель, чем технология: домены владеют данными, данные как продукт, self-service платформа и федеративное governance. Похоже чем-то на DevOps, концепция культурны и всё такое. Поэтому трактую ее по принципу: "я так вижу…" 💃👀
По книге: mesh подходит не всем и чаще всего внедряется постепенно (hub-and-spoke), а не "с наскока" в новый мир, минуя предыдущие стадии.
1️⃣4️⃣Практический takeaway: в современных проектах чаще выигрывает гибрид: MDW как основа + "fabric-capabilities" как зрелость, lakehouse - там, где оправдан "single storage", а mesh — только если компания реально готова к DDD и понимает цену изменений.
🔥3
📚Продолжим разбор книги, «Архитектуры данных: современные решения для любых задач».
Наконец-то финальная 😮💨 Часть IV: Люди, процессы и технологии.
1️⃣5️⃣ Люди и процессы - это главный "ускоритель" 🚀 и главный "тормоз" 🌪
Книга честно говорит, платформа данных рушится не из-за отсутствия очередного инструмента, а из-за нестыковки ролей, ожиданий и ответственности. Люди - иррациональные существа. Где-то они помогают проекту, а где-то его саботируют.
Что стоит зафиксировать:
👉 Данные — это продукт. Нужен владелец (product/data owner), понятные пользователи, SLA и критерии “готово”.
👉 Governance — это работа, а не слайд. Качество, доступы, комплаенс и lineage должны быть встроены в процесс, иначе любой lake превращается в swamp.
👉 Итеративность > “идеальный проект”. Прототипы, короткие релизы, постоянная обратная связь от потребителей — иначе получится “витрина в вакууме”.
👉 Знания нельзя “аутсорсить насовсем”. Если команда не забирает экспертизу и ответственность внутрь — проект будет вечной миграцией.
1️⃣6️⃣ Ядро технологий осталось прежним, но обёртка и интерфейс взаимодействия с ним уже другие в 2026.
Логика выбора всё та же. Лучшая технология это та, что закрывает требования заказчика по безопасности, бюджету, компетенциям, latency и юрисдикциям. Но изменились акценты. В 2026 появились новые опорные факторы выбора:
🆕 Open table formats стали нормой. Вопрос чаще звучит не “какой warehouse”, а “какой формат таблиц + какой каталог + какие движки поверх”.
🆕 Каталог/политики - центр архитектуры. Governance всё больше переезжает в “платформенный слой”: единые правила доступа, семантика, контракты данных. Думаю коллеги из Аренадаты моя поддержат.
🆕 AI встраивается прямо в data-платформы. Не только " ML снаружи", но и внутри. Обработка неструктурированных данных, эмбеддинги, RAG-контуры - всё это влияет на выбор, где живут данные и как контролируется доступ.
🆕 Единые платформы (unified analytics) стали сильнее. Особенно там, где важна скорость внедрения и консолидация инструментов (инженерия данных + BI + governance + AI).
❗️Финальный вывод по Части IV❗️
Архитектура данных в 2026 уже не про то, чтобы "выбрать технологии и жить счастливо" 👨👨👦👦. Это про то, чтобы делать платформу как продукт. С пользователями, приоритетами и бесконечными правками 🛞.
Люди и процессы задают направление. Технологии просто помогают ехать быстрее 🏎. Или красиво буксовать 🚜.
А потом приходит реальность и тихо шепчет заклинание 🪄
И в вашем озере данных 🏖 заводятся единороги 🦄, а в бэклоге начинает шевелиться химера из ежа 🦔 и ужа 🐍.
Наконец-то финальная 😮💨 Часть IV: Люди, процессы и технологии.
Этот тот раздел, где становится неловко всем, кто хотел “просто выбрать стек и поехать” 😅
1️⃣5️⃣ Люди и процессы - это главный "ускоритель" 🚀 и главный "тормоз" 🌪
Книга честно говорит, платформа данных рушится не из-за отсутствия очередного инструмента, а из-за нестыковки ролей, ожиданий и ответственности. Люди - иррациональные существа. Где-то они помогают проекту, а где-то его саботируют.
Что стоит зафиксировать:
👉 Данные — это продукт. Нужен владелец (product/data owner), понятные пользователи, SLA и критерии “готово”.
👉 Governance — это работа, а не слайд. Качество, доступы, комплаенс и lineage должны быть встроены в процесс, иначе любой lake превращается в swamp.
👉 Итеративность > “идеальный проект”. Прототипы, короткие релизы, постоянная обратная связь от потребителей — иначе получится “витрина в вакууме”.
👉 Знания нельзя “аутсорсить насовсем”. Если команда не забирает экспертизу и ответственность внутрь — проект будет вечной миграцией.
1️⃣6️⃣ Ядро технологий осталось прежним, но обёртка и интерфейс взаимодействия с ним уже другие в 2026.
Логика выбора всё та же. Лучшая технология это та, что закрывает требования заказчика по безопасности, бюджету, компетенциям, latency и юрисдикциям. Но изменились акценты. В 2026 появились новые опорные факторы выбора:
🆕 Open table formats стали нормой. Вопрос чаще звучит не “какой warehouse”, а “какой формат таблиц + какой каталог + какие движки поверх”.
🆕 Каталог/политики - центр архитектуры. Governance всё больше переезжает в “платформенный слой”: единые правила доступа, семантика, контракты данных. Думаю коллеги из Аренадаты моя поддержат.
🆕 AI встраивается прямо в data-платформы. Не только " ML снаружи", но и внутри. Обработка неструктурированных данных, эмбеддинги, RAG-контуры - всё это влияет на выбор, где живут данные и как контролируется доступ.
🆕 Единые платформы (unified analytics) стали сильнее. Особенно там, где важна скорость внедрения и консолидация инструментов (инженерия данных + BI + governance + AI).
❗️Финальный вывод по Части IV❗️
Архитектура данных в 2026 уже не про то, чтобы "выбрать технологии и жить счастливо" 👨👨👦👦. Это про то, чтобы делать платформу как продукт. С пользователями, приоритетами и бесконечными правками 🛞.
Люди и процессы задают направление. Технологии просто помогают ехать быстрее 🏎. Или красиво буксовать 🚜.
А потом приходит реальность и тихо шепчет заклинание 🪄
“Хочу всё. Без ограничений. И за недорого”.
И в вашем озере данных 🏖 заводятся единороги 🦄, а в бэклоге начинает шевелиться химера из ежа 🦔 и ужа 🐍.
🔥1