Как Купер перенес 40 ТБ аналитических данных в облако без остановки процессов
🛒 Что за компания
Купер — сервис доставки из магазинов и ресторанов, работающий в 360 городах России. Аналитическая инфраструктура компании обрабатывает данные для управленческой отчетности и ситуативной аналитики — как внутренней, так и для внешних партнеров.
⚡ Задача
С ростом объемов данных старое решение перестало справляться. Нужно было:
найти управляемую СУБД в облаке аналогичную Greenplum по функциям, с поддержкой подключения к внешним источникам;
провести нагрузочное тестирование на реальных OLAP-запросах до миграции;
перенести 40 ТБ бизнес-критичных данных вместе с контуром разработки, не останавливая аналитические процессы.
☁️ Что сделали
Провайдер предложил Evolution Managed ArenadataDB — управляемую СУБД на базе Greenplum с открытым исходным кодом. Команда во время пилота:
развернула отказоустойчивый кластер и настроила процесс миграции;
подключила PXF-коннекторы к внешним источникам данных;
установила нестандартные JDBC-драйверы и оптимизировала использование памяти для крупных запросов;
настроила автоочистку и автоанализ — механизмы автоматического обслуживания СУБД для устойчивой работы под нагрузкой.
🦾 Что получили в итоге
40 ТБ данных и тестовый контур перенесены без остановки процессов. Инфраструктура работает оперативно: данные за вчера доступны уже на следующий день. Выросла скорость выполнения запросов, появилась гибкость масштабирования и прозрачность мониторинга.
В планах — оптимизация резервного копирования, архивация данных и бесшовная интеграция инструментов ИИ и машинного обучения.
Неудобные вопросы про бэкап PostgreSQL: открытый разбор на вебинаре
Вокруг бэкапа PostgreSQL легко создать иллюзию, что все уже решено. Достаточно добавить в текст WAL, PITR, пару слов про консистентность и назвать агент «умным». Проблема в том, что в проде такие формулировки мало что гарантируют.
Можно ли вообще считать решение PostgreSQL-aware, если оно не живет внутри логики самой СУБД? Где проходит граница между нативными механизмами PostgreSQL и внешней платформой? Что происходит, если не доехал WAL-сегмент, не завершился post-script или восстанавливать нужно не весь инстанс, а один объект?
Из таких вопросов и вырос отдельный вебинар про PostgreSQL в Акуре, в формате открытого инженерного разбора: что здесь должна делать сама СУБД, что имеет смысл выносить во внешний слой, где начинаются реальные эксплуатационные проблемы и какие ограничения в таком подходе нельзя замалчивать.
План такой:
• отдельно пройтись по WAL, PITR и консистентности;
• обсудить, где файловый агент уместен, а где уже нет;
• разобрать сценарии с ошибками pre/post-скриптов;
• поговорить про восстановление в безопасную локацию и ручной recovery;
• отдельно затронуть вопрос масштаба: почему на двух базах хватает shell-скриптов, а на пятидесяти уже начинается совсем другая жизнь.
26 марта 2026, 11:00 (МСК) Регистрация по ссылке. Приносите в комментарии вопросы, которые особенно хочется поднять в эфире.
ai_query() в StarRocks 4.1: вызываем LLM прямо из SQL. Разбор результатов тестов.
Зачем это нужно аналитику и как вписывается в архитектуру, я описал в своем Telegram-канале Selena (powered by StarRocks). Здесь — технические детали и результаты тестирования.
Архитектура StarRocks 4.x: два направления интеграции с языковыми моделями
На схеме два потока данных между языковой моделью и базой данных:
Синий (вверху) — LLM → База через MCP (4.0). Пользователь задаёт вопрос на обычном языке. Агент сам формулирует SQL-запрос, отправляет его в StarRocks через MCP-протокол и возвращает ответ. Об этом я также подробно писал в нашем сообществе.
Зелёный (внизу) — База → LLM через ai_query() (4.1). Аналитик пишет SELECT с вызовом ai_query(). StarRocks на каждом сервере кластера отправляет запрос к языковой модели и возвращает её ответ как обычную текстовую колонку.
В версии 4.0 появилось первое направление, в 4.1 — второе. Полный цикл.
Что такое ai_query()
Функция принимает два аргумента: текстовый промпт и JSON с параметрами модели. Возвращает текстовую колонку — результат можно фильтровать, группировать и соединять с другими таблицами.
Обязательные параметры: model (название модели) и api_key (ключ доступа). Дополнительно можно указать адрес сервера модели, температуру, максимальную длину ответа и таймаут.
Функция работает с любым сервисом, совместимым с протоколом OpenAI: это и сам OpenAI, и локальные модели через Ollama, и DeepSeek, и vLLM.
Как тестировали:
Функция планируется к релизу в версии 4.1. Когда пришло время её проверить, привычный способ — развернуть готовый образ в Docker — не сработал. В образе обнаружился небольшой баг: функция была скомпилирована и лежала внутри сервера, но сервер о ней не знал. Исправление заняло одну строку в исходном коде. Но чтобы её применить, пришлось собирать BE из исходников.
Среда тестирования: виртуальная машина (8 CPU, 32 ГБ RAM), StarRocks 4.1.0-rc01 (собранный из исходников), языковая модель Ollama gemma3:1b (работает локально на процессоре). Тестовые данные — шесть отзывов о товарах.
Тест 1. Анализ тональности
Задача: определить, позитивный отзыв или негативный.
(SQL код по каждому тестированию я напишу в комментариях)
Вывод: четыре из шести точных.
Модель на один миллиард параметров делает бинарную классификацию — не различает нейтральные отзывы. Я, кстати, попробовал и с большими параметрами и с меньшим квантованием, насколько смог выдержать мой сервер, результат локальных моделей в этой задаче не очень.
Время: ~три секунды на шесть строк.
Не тот объем данных, чтобы экстраполировать на большие продакшн системы, но я тестировал не производительность, а работоспособность.
Тест 2. Суммаризация
Задача: сжать отзыв в одно предложение.
Вывод: адекватные резюме на русском языке. Длину ответа стоит контролировать параметром max_tokens.
Время: ~одна секунда на строку.
Тест 3. Извлечение характеристик
Задача: вытащить из текста ключевые свойства товара.
Вывод: характеристики извлекаются
Время: ~1 секунда на строку.
Тест 4. Классификация
Задача: определить категорию товара по тексту отзыва.
Вывод: качественный перевод даже на модели в один миллиард параметров.
Время: ~1 секунда на строку.
Ограничения:
Нельзя задать роль модели (нет системного промпта) — только сообщение от пользователя
Нет повторных попыток при ошибке — если сервис модели вернул ошибку, это сразу ошибка SQL-запроса
Кеш хранится на каждом сервере отдельно и теряется при перезапуске
Итого:
ai_query() — простая обёртка над протоколом языковых моделей с кешем и дедупликацией. Не революция, но именно такие простые интеграции оказываются самыми полезными.
В документации StarRocks появились release notes для 4.1 с пометкой RC (release candidate) — это предварительная версия перед финальным релизом. Посмотреть, куда движется проект, самое время. Я изучил release notes, связанные issues и PR, и выбрал четыре самых значимых изменения.
Актуальные версии на сегодня: Stable — 3.5.14, Latest — 4.0.6.
1. Автоматическое управление распределением данных
Раньше при создании таблицы в shared-data кластере нужно было вручную выбирать ключ распределения и рассчитывать количество бакетов. Если ошибся — часть узлов перегружена, а часть простаивает, и исправление требует пересоздания таблицы.
В 4.1 для shared-data кластеров появляется range-based распределение: таблеты содержат метаданные диапазонов ключей, и система сама следит за их размером — автоматически разделяет слишком большие или объединяет недоиспользуемые. Без изменения схемы и без перезагрузки данных.
До 4.1 StarRocks мог только читать данные из Iceberg и добавлять новые (INSERT). Удалять было нельзя. А это серьёзное ограничение: удаление персональных данных по требованиям регуляторов, исправление ошибочных записей, очистка устаревших данных — всё приходилось делать через Spark или Trino.
Теперь DELETE FROM (механизм Iceberg position delete) работает напрямую из StarRocks. При этом delete-файлы совместимы с другими движками — Spark, Trino и Flink корректно их прочитают. StarRocks становится ещё более полноценным SQL-движком для Iceberg: SELECT + INSERT + DELETE. Issue #66944 (https://github.com/StarRocks/starrocks/issues/66944)
3. Рекурсивные CTE (WITH RECURSIVE)
Одна из самых запрашиваемых фич — сообщество просило с 2023 года. Рекурсивные CTE позволяют писать запросы, которые ссылаются сами на себя — это нужно для обхода иерархий (оргструктуры, категории товаров, вложенные комментарии), заполнения пропусков во временных рядах и графовых задач. Если вы мигрируете с PostgreSQL, MySQL или Trino — больше не нужно переписывать рекурсивные запросы. PR #65932 (https://github.com/StarRocks/starrocks/pull/65932)
4. Инкрементальное обновление Materialized Views на Iceberg
До 4.1 materialized views на Iceberg-таблицах обновлялись полным пересчётом — даже если в источнике добавилось несколько строк. Теперь StarRocks умеет обновлять MV инкрементально — обрабатывается только новая порция данных. Особенно заметно на append-heavy сценариях: логи, события, IoT-данные. Ограничение первой версии — работает только с таблицами, в которые данные добавляются, но не обновляются. Issue #61789 (https://github.com/StarRocks/starrocks/issues/61789)
Что ещё интересного:
Полнотекстовый поиск в shared-data кластерах (inverted index, beta)
Таблеты до 100 ГБ
Меньше мелких файлов, проще эксплуатация
Поддержка Iceberg V3 и тип VARIANT для полуструктурированных данных
ai_query()
вызов LLM-моделей прямо из SQL-запроса
sum_map() — нативная агрегация MAP по ключам
Мониторинг потоков FE через SQL без внешних инструментов
Больше постов про StarRocks и Lakehouse — в Telegram-канале @starrocks_selena
Привет, Хабр! У нас в ОТП Банке есть целое профессиональное сообщество про Data Governance. Мы генерим в нем много полезной информации, поэтому решили, что нашим читателям тоже можем быть интересно. Наш первый пост – про конференцию «Качество данных».
CDO – это не про технологии. Это про культуру.
Сегодня Chief Data Officer – это не просто руководитель данных. Это архитектор культурных изменений. Задача CDO: менять парадигму мышления организации: от работы «по ощущениям» к системной ответственности за данные и их качество.
Реальный срок построения Data Governance: 1–3 года.
Если на входе понятная структура данных: 1–2 года.
Если хаос, миграции и несистемность: 2–3 года.
Это подтверждает: построение экосистемы данных – не быстрый проект, а трансформация. И именно она позволяет перейти к проактивному качеству данных и Data-Driven управлению. Хайп вокруг AI показал главное - без качества данных ничего не работает. Многие компании попробовали внедрять AI и Data-Driven подходы, но столкнулись с реальностью: без управляемых, понятных и качественных данных результат не достигается.
Тренд 2026 года: фокус на качестве данных как фундаменте всех инициатив.
Методология + технология + коллаборация. Только вместе.
Один из ключевых выводов: ни стандарты без инструментов, ни инструменты без вовлечённых людей не работают. Качество данных «by design» возможно только тогда, когда: есть понятная методология, есть поддерживающая технология, и есть встроенная коллаборация через процессы Data Governance. Именно экосистема делает качество устойчивым.
Институт Data Owner и Data Steward – критический фактор успеха.
Важно не просто внедрить инструмент, а:
🪐назначить владельцев,
🪐выстроить прозрачную ответственность,
🪐дать удобный процесс работы с инцидентами качества,
🪐встроить мониторинг в операционные процессы команд.
Успех приходит тогда, когда Data Governance не выглядит как «дополнительная нагрузка сверху», а становится частью ежедневной работы с понятной пользой и измеримым результатом. Формальное назначение владельцев – это только начало.
Многие компании сталкиваются с трудностями в прозрачности и реальной вовлечённости владельцев данных. Но даже базовое, формальное закрепление ответственности создаёт фундамент, на котором можно строить зрелую систему качества. Именно этот фундамент позволяет переходить от описаний в глоссарии к реальной ответственности за качество и его исправление.
Главный вывод конференции:
Качество данных - это не функция IT. Это организационная зрелость. И 2026 год - год, когда выигрывают те, кто построил экосистему, а не просто внедрил инструмент.
Как крупнейший брокер перенес 200 серверов и 100 ТБ данных в российское облако без потерь и неожиданностей
💼 Что за компания
«Ренессанс Брокер» — один из крупнейших профессиональных участников российского рынка ценных бумаг. Сфера деятельности брокера строго регламентирована, а IT-инфраструктура в компании как кровеносная система: любой простой, даже измеряемый минутами, может привести к финансовым потерям и ущербу деловой репутации. Наиболее критический сценарий для IT-инфраструктуры — отказ или перегрузка торгового сервера или шлюза, обеспечивающего связь с биржей.
🕵️ Задача
Перенести критически важные бэк-офисные системы из иностранного облака в российское, соблюсти требования по SLA, RTO, RPO и обеспечить производительность ключевых компонентов инфраструктуры на аналогичном или лучшем уровне. Например, в случае инцидента время на восстановление работы критических систем должно стремиться к нулю. При этом для баз данных брокер требовал RPO, равное нулю, ведь потеря даже одной транзакции недопустима.
«Ренессанс Брокер» переносил системы с известными нагрузками, поэтому опирался на конкретные цифры производительности базы данных и сети:
для транзакционных запросов должно сохраниться среднее время отклика,
задержка между критически связанными компонентами внутри облака должна оставаться минимальной,
задержка доступа до новых облачных ресурсов должна быть сопоставима или меньше предыдущей.
👨💻 Решение
На пилотном этапе брокер сосредоточился на тестировании фундаментальных сервисов Cloud.ru Advanced: виртуальных машин, блочного хранилища и объектного хранилища стандартного и холодного класса хранения. Тестирование подтвердило, что инфраструктура Cloud.ru соответствует текущим требованиям к производительности. Это стало одним из аргументов для принятия решения о начале полномасштабной миграции, так как позволило гарантировать бизнесу отсутствие ухудшения в работе критически важных приложений и баз данных.
Сроки миграции в облако Cloud.ru были спланированы и реализованы в два этапа. На приоритетную миграцию закладывали 2–3 месяца. Второй этап по плану должен был занять около 6 месяцев: за это время надо было не просто перенести системы, но и архитектурно их усовершенствовать, например, переехать на новую версию ПО или изменить стек с одной СУБД на другую, включая критически важное разделение зарубежной и российской инфраструктур для соответствия новым регуляторным и законодательным требованиям.
📈 Результаты
Миграция полностью уложилась в запланированный срок. Все сервисы, включая 200 серверов и 100 ТБ данных, были перенесены с минимальным временем простоя. Изменения затронули практически всех сотрудников компании. Для них переход был максимально прозрачным и свелся в основном к смене адресов для подключения: они продолжили работать с уже знакомыми системами, но уже в новой среде.
Снижение совокупной стоимости владения (TCO) облачной инфраструктурой стало для «Ренессанс Брокера» одним из самых значимых количественных результатов миграции. Клиент достиг этого снижения за счет более прозрачной и предсказуемой модели ценообразования, что позволяет эффективнее управлять бюджетом и избегать неожиданных затрат.
Другой важный результат — сохранение и укрепление высокого уровня SLA в новой среде: брокер обеспечил выполнение строгих требований к доступности и полную сохранность данных.
Коллеги, 03.02.2026, три дня назад я провёл вебинар, посвящённый полиглотности СУБД - умению работать с диалектами PostgreSQL, Oracle и Microsoft в контексте импортозамещения.
Меня зовут Жуйков Андрей, и если будет время - буду рад, если посмотрите запись 👀
«Импортозамещение СУБД по-новому: интеллектуальный подход к замене MS SQL и Oracle»
🔹 Установка и первый запуск Digital Q.DataBase • развёртывание Digital Q.DataBase в Docker-контейнере • установка и настройка Digital Q.DataBase на Ubuntu 24.04 • архитектура, ключевые преимущества и типовые сценарии использования в российских компаниях
🔹 Новые возможности Digital Q.DataBase для импортозамещения • инструменты, упрощающие миграцию с MS SQL и Oracle • как сократить риски и сроки перехода без переписывания приложений
🔹 Практика внедрения и реальные кейсы • Владимир Авсеев показал, как система «Босс-Кадровик», изначально заточенная под MS SQL, успешно работает на Digital Q.DataBase • Анастасия Коршунова (отдел разработки) продемонстрировала примеры успешной интеграции Digital Q.DataBase с 1С и Delphi-приложениями
🔹 Ответы на вопросы • практические нюансы миграции и эксплуатации • ответы на вопросы из реальных проектов от разработчиков Digital Q.DataBase и команды «Босс-Кадровик»
Хочу поделиться записью моего последнего вебинара - в преддверии следующего. Буду рад всем, кто посмотрит.
📘 Часть 1. Теория и философия Digital Q.DataBase Разбираем фундаментальные вопросы: • Как Digital Q.DataBase объединяет три SQL-диалекта (T-SQL, PL/SQL, PL/pgSQL) в одном ядре? • Как продукт обеспечивает простоту и высокую скорость миграции? • Что входит в базовый состав коробочной версии?
🛠 Часть 2. Практика: установка и работа с диалектами • скачиваем и устанавливаем Digital Q.DataBase, • получаем документацию, • выполняем практику по SQL-диалектам на демостендах.
Да, это тот самый момент, когда теория превращается в конкретику - и вы сами видите, как работает гибридная архитектура продукта.
В современном мире быть в курсе новостей об искусственном интеллекте — это уже не роскошь для энтузиастов, а базовое требование для сохранения личной и профессиональной адекватности. ИИ перестал быть технологией будущего; он активно формирует настоящее, и непонимание его трендов делает человека уязвимым.
Главная проблема — риск стать нерелевантным. ИИ кардинально меняет рынок труда, автоматизируя не только рутину, но и сложные творческие задачи. Профессии трансформируются со скоростью, не оставляющей времени на постепенную адаптацию. Тот, кто не следит за этими изменениями, не сможет вовремя перестроить свои навыки, рискуя оказаться за бортом.
Не менее важно, что ИИ радикально меняет информационное пространство. Интернет наполняется синтетическим контентом: от статей до "очевидных" видеодоказательств. Без понимания, как работают и в чем слабы эти технологии, теряется способность критически оценивать информацию, отличать факты от искусно сфабрикованных манипуляций. И наконец, игнорируя новости об ИИ, человек добровольно отказывается от огромных возможностей для улучшения повседневной жизни — от интеллектуальных помощников, экономящих время, до персональных репетиторов и инструментов для творчества.
Топ YouTube-каналов: ИИ, бренд и результат
Если смотреть на цифровой ландшафт сегодня, то три выбранных канала идеально иллюстрируют три главных вектора успеха: технологический прорыв, силу личности и прикладной результат. Вот как они расположились в рейтинге.
Топ - Realmikemozg — Флагман новой эры
Этот канал — абсолютный феномен и заслуженный лидер списка. Realmikemozg представляет собой не просто канал, а полноценную виртуальную контент-фабрику. Его специфика — это направление «AI Slop»: бесконечный поток коротких, сюрреалистичных и зачастую абсурдных видео, на 100% сгенерированных искусственным интеллектом. Здесь нет одного лица — есть сам алгоритм как автор. Канал демонстрирует, как технологии меняют само понятие творчества, оптимизируя производство вирального контента под алгоритмы платформ. Его ценность — в демонстрации пределов возможного и в формировании новой digital-эстетики.
Топ 2 - Art.senatorov — Бизнес и личность
Второе место занимает канал Art.senatorov, основанный предпринимателем Артемом Сенаторовым. Это уже «человечная» сторона digital-мира. Канал посвящен практическим аспектам построения личного бренда, ведения социальных сетей и предпринимательства. Артем делится проверенными стратегиями, кейсами и лайфхаками, основанными на собственном опыте. Его контент — это мост между теорией и практикой, источник вдохновения и конкретных инструкций для тех, кто хочет создать что-то осязаемое в интернете, опираясь на свою экспертизу и харизму.
Топ 3 - Pavel_korovkin — Системный результат
Замыкает тройку канал Pavel_korovkin Павла Коровкина, который фокусируется на фундаментальных бизнес-задачах: digital-маркетинге, привлечении клиентов и увеличении продаж. Это канал-инструмент. Павел разбирает конкретные схемы, стратегии работы с трафиком и рекламными инструментами, делая упор на измеримый финансовый результат. Его контент — это концентрация прикладного знания для маркетологов и владельцев бизнеса, которые ищут не вдохновение, а четкие рецепты для роста прибыли.
Краткая суть
Таким образом, ваш топ охватывает ключевые этапы цифровой эволюции: Realmikemozg олицетворяет будущее с доминированием ИИ, Art.senatorov показывает силу человеческого капитала и личного бренда здесь и сейчас, а Pavel_korovkin обеспечивает системный подход, превращающий и то, и другое в деньги. Вместе они составляют полную картину современного контент-мира.
Процедурное SQL-расширение в Lakehouse-платформе — новые возможности для работы с данными
В блоге технологического партнера GlowByte вышла новая статья. Команда Data Sapience рассказала о реализации процедурного расширения для работы с MPP-движками Lakehouse-платформы данных Data Ocean Nova, которое стало доступным для пользователей.
Ребята рассказывают о возможностях, применимости и сценариях использования процедурного языка в аналитической платформе данных и делятся планами по развитию Data Ocean Nova.
Открываем доступ по запросу к Yandex Managed Service for Sharded PostgreSQL — сервису на базе технологии SPQR для горизонтального масштабирования PostgreSQL
PostgreSQL по умолчанию не имеет нативной поддержки горизонтального масштабирования — и это вызывает сложности при достижении пределов единственного экземпляра Postgres. В качестве решения часто используют разделение таблиц по ключам и установку рядом с приложением координатора, который знает, на какой шард направить запрос.
Однако у такого подхода множество недостатков: сложность миграций, проблемы с масштабированием метаданных и балансировкой и не только.
Сегодня мы открываем доступ по запросу к управляемому сервису Yandex Managed Service for Sharded PostgreSQL. Новый инструмент создан на базе SPQR (Stateless Postgres Query Router) — это опенсорс‑решение для горизонтального масштабирования PostgreSQL, которое разработано инженерами из команды платформы данных Yandex Cloud и оптимизировано под OLTP‑нагрузки и плавные миграции.
Управляемый сервис на основе SPQR позволит клиентам облачной платформы Yandex Cloud ускорить обработку миллионов транзакций: так, с Sharded PostgreSQL банки и компании из сферы электронной коммерции могут запускать новые ИТ‑продукты в 3–4 раза быстрее. Надёжность технологии шардированного PostgreSQL проверена на проектах Яндекса.
Команда активно развивает технологии PostgreSQL: каждый год в релиз базы данных попадает множество доработок от контрибьюторов из Yandex Cloud:
Инкрементальное улучшение любой популярной технологии зачастую имеет негативные последствия. Построить что‑то новое, ничего не сломав, бывает трудно и в чистом поле, а ядро PostgreSQL в этом смысле — лабиринт с граблями.
Но большинство незавершённых проектов создают инфраструктуру для того, чтобы какие‑то другие проекты могли завершиться и причинить пользу.
Андрей Бородин, руководитель команды разработки СУБД с открытым исходным кодом Yandex Cloud, Major Contributor PostgreSQL
Поиск партнёра для совместной инженерной проверки идей (не найм)
Сразу обозначу границы, чтобы не тратить время друг друга.
Я не ищу работу, не нанимаю, не продаю услуги и не собираю команду. Интересует формат равного партнёрского взаимодействия на уровне мышления и проверки гипотез.
Контекст
Мой бэкграунд - backend / инфраструктура / системы. Умею проектировать и собирать техническую часть, доводить до рабочего состояния, автоматизировать, поддерживать.
При этом хорошо вижу ограничение соло-режима: без внешнего критического взгляда идеи либо не проходят реальную проверку, либо остаются умственными конструкциями.
Что именно ищу
Ищу одного человека, с которым можно:
разбирать идеи без романтизации
проверять гипотезы на реализуемость и смысл
делать небольшие, ограниченные по времени и объёму пробы (MVP / прототип / концепт)
Речь не про «стартап мечты», а про инженерный подход к неопределённости.
Кого не ищу
менторов и гуру
инвесторов
людей, ожидающих «готовый проект»
мотивационные разговоры без действия
Формат
асинхронная переписка
созвон 45–60 минут
если не совпали по подходу - спокойно расходимся
Без обязательств, без разговоров про доли, без долгих ожиданий.
Почему сейчас
Инструментов и ресурсов стало достаточно, чтобы проверять идеи быстро и дёшево. Интересно найти человека, которому близка аккуратная инвестиция времени и внимания - с пониманием, что результат не гарантирован.
Новый курс «Платформа Tantor 6.x» на «Астра Знания»!
Мы подготовили новый курс «Платформа Tantor 6.х», посвященный новым функциям платформы управления любыми Postgres-like СУБД и возможностям, доступным DBA после выхода обновления. Размещен курс на платформе «Астра Знания». Он сочетает структурированный теоретический материал и практические задания, которые помогают закрепить приобретенные знания и навыки.
В программе: ▪️архитектура Платформы и ее возможности ▪️интеграция и работа со Swagger UI ▪️инструменты мониторинга, конфигурирования и обслуживания PostgreSQL ▪️браузер БД ▪️анонимайзер ▪️работа с уведомлениями
Самое сложное — это изменить сознание человека, а не процесс
Николай Шевцов, Chief Data Officer (CDO) ОТП Банка, принял участие в CNews Forum 2025, где рассказал о практическом опыте внедрения и трансформации системы управления данными (Data Governance) в рамках банковских процессов.
В своем выступлении Николай представил анализ практического опыта построения сквозной системы управления данными (Data Governance) и акцентировал внимание на важности эффективного контроля качества данных, а также внедрения инновационных технологий для бизнеса.
«Самое сложное — это изменить сознание человека, а не процесс», – сказал Николай подчеркивая, что успешная трансформация в области управления данными требует не только технологических изменений, но и глубокой перестройки корпоративной культуры.
Он указал, что основная проблема в управлении данными заключается в хаосе и утрате экспертизы при переходе между различными хранилищами данных.
«Со временем любое хранилище становится собранием хаоса. Мы столкнулись с этим, когда три года назад осуществляли переход с одного хранилища на другое», – рассказал Николай, отметив, что эта ситуация характерна для многих банков.
Он также акцентировал внимание на важности наличия единого источника правды для данных и прозрачности процессов. По его словам, потеря ключевых метаданных и знаний влечет за собой значительные дополнительные затраты на перевнедрение, а также приводит к снижению качества бизнес-процессов.
«Когда мы говорим о данных как о важной объектной модели, крайне важно, чтобы бизнес и ИТ говорили на одном языке. Это позволяет нам не только контролировать качество данных, но и существенно улучшать эффективность внутренних процессов», – добавил Николай.
Особое внимание Николай уделил внедрению автоматических проверок качества данных в ОТП Банке. По его словам, такие технологии помогают не только ускорить процессы, но и значительно повысить точность и достоверность информации, что ведет к значительным финансовым сбережениям. «Экономия, достигнутая благодаря автоматизации проверок качества данных, составила сотни миллионов рублей за два года», – сообщил он.
Николай также рассказал о внедрении сквозной системы управления данными (Data Governance) в ОТП Банке, которая позволяет эффективно управлять данными, интегрировать их с различными системами и обеспечивать прозрачность на всех уровнях. По его словам, такая система критически важна для обеспечения качественного анализа и использования данных в принятии решений.
Важнейшим элементом трансформации является обучение сотрудников на всех уровнях, включая руководство. «Мы постоянно обучаем наших сотрудников, чтобы каждый, от аналитиков до членов правления, понимал значение качественных данных и их влияние на бизнес», – отметил Николай.
В завершение Николай подчеркнул, что интеграция современных технологий и оптимизация IT-ландшафта открывают новые горизонты для развития ОТП Банка. Он заверил, что банк продолжает совершенствовать свою цифровую платформу, адаптируя её под нужды бизнеса и создавая более эффективную инфраструктуру.
Приглашаем на вебинар «Платформа Tantor 6.1. Умный центр администрирования СУБД на основе PostgreSQL».
Управляете парком PostgreSQL-совместимых СУБД и хотите сократить рутину и повысить надёжность? 11 декабря в 11:00 наши эксперты представят актуальный релиз Платформы Tantor 6.1. Платформа Tantor — интеллектуальный центр управления базами данных, который берет на себя массу актуальных задач DBA. На вебинаре покажем, как платформа решает ключевые из них:
Автоматизация вместо рутины: умные алерты, подсказки и встроенный ИИ-ассистент для помощи в повседневной работе;
Безопасность под контролем: централизованный аудит и визуальное управление настройками доступа (pg_hba, pg_ident);
Оптимизация «одной кнопкой»: анализ конфигураций, подбор оптимальных настроек под нагрузку и их групповое применение;
Всё на виду: наглядная топология кластеров, пространств и тенантов;
Лёгкое масштабирование: создание кластеров Tantor XData за пару кликов.
В финале — эксклюзивный анонс: дорожная карта развития Платформы Tantor на 2026 год.
Кому будет полезно: DBA, архитекторам, DevOps-инженерам и руководителям ИТ-направлений, которые работают с БД на основе PostgreSQL.
Как оптимизировать бюджет на интеграции в 2026 году: практики и инструменты для DATAREON
11 декабря в 12:00 проведём практический вебинар для ИТ-директоров и архитекторов, которые хотят сократить стоимость интеграций на DATAREON и избавиться от рутинных трудозатрат.
Чаще всего для интеграций, особенно на предприятиях с большим количеством 1С, мы используем DATAREON Platform. Удобный 1С-коннектор, широкое распространение и доступная стоимость лицензий делают его одним из самых популярных решений для интеграционных задач.
Однако цена лицензии — лишь часть картины: важную роль играет также стоимость внедрения и дальнейшего сопровождения.
Сколько на самом деле стоит интеграционный проект?
Какие существуют реальные способы снизить расходы без потери качества?
Об этом мы поговорим на вебинаре.
Что покажем на вебинаре
Технический директор ИТ-интегратора «Белый код» Сергей Скирдин разберёт реальные кейсы и продемонстрирует, какие технические решения ускоряют работу и снижают стоимость интеграционного проекта:
Использование API DATAREON для создания типов данных.
Генерация обработчиков 1С.
Отладка обработчиков и функций без боли.
Использование формата Enterprise Data как основы для интеграции типовых объектов 1С
Заглянем в будущее — покажем, как с помощью ИИ-агента можно дорабатывать интеграционный проект в DATAREON.
Какой эффект получит бизнес
✔ Снижение стоимости интеграций. Автоматизация процессов уменьшает объём ручной работы и бюджет проекта. ✔ Быстрый запуск интеграций. Готовые инструменты ускоряют разработку и ввод в эксплуатацию. ✔ Масштабируемость интеграций. Единые стандарты позволяют быстро подключать новые системы без усложнения архитектуры.
Кому будет полезно
Руководителям, которые выбирают подрядчика для внедрения интеграционной шины и хотят объективно оценить подходы и стоимость.
Архитекторам перерабатывающим технологию замены существующего интеграционного решения на DATAREON Platform
Компаниям с большим количеством систем на 1С и активными интеграционными задачами, которые хотят выстроить оптимальную архитектуру и ускорить ввод в эксплуатацию новых интеграционных потоков.
📈 MariaDB 11.8, векторные БД и курс на миграцию с Oracle: Итоги MariaDB Meetup в Тель-Авиве
Я и Монти Видениус
Вчера мне посчастливилось побывать на MariaDB Meetup с участием самого Майкла «Монти» Видениуса в Тель-Авиве. Это событие стало не только ценной возможностью услышать о стратегических и технических планах развития MariaDB, но и позволило укрепить партнерские связи между проектом и нашей образовательной платформой.
Делюсь ключевыми тезисами и анонсами с митапа, которые будут интересны всем, кто работает с базами данных и Open Source.
1. Стратегический вектор: Open Source и миграция с Oracle
Майкл Видениус в своем докладе однозначно обозначил стратегию MariaDB: курс на безоговорочную победу открытого кода над проприетарными гигантами. Основной акцент был сделан на преимуществах миграции с Oracle на MariaDB.
Преимущества и миграция:
Экономическая эффективность: Монти открыто говорил о несопоставимой стоимости использования и владения MariaDB по сравнению с Oracle, что является критическим фактором для многих корпоративных пользователей.
Совместимость синтаксиса: MariaDB активно развивает режим совместимости с Oracle (Oracle Compatibility Mode), который значительно упрощает процесс перехода, позволяя использовать привычный синтаксис SQL. Это резко снижает затраты времени и ресурсов на переписывание существующего кода.
Производительность MariaDB 11.8: Были продемонстрированы тесты, подтверждающие рост производительности более чем в 2,5 раза по сравнению с предыдущими версиями за счет архитектурных улучшений.
2. MariaDB, AI и Векторные базы данных
Сергей Голубчик представил глубокий технический обзор поддержки векторного типа данных в последних версиях MariaDB. Это важнейший шаг, который ставит MariaDB в один ряд с современными решениями, адаптированными для задач искусственного интеллекта.
Векторный тип данных (Векторная БД): Встроенная поддержка векторов позволяет использовать MariaDB как полноценную векторную базу данных, что критически важно для работы с embeddings, семантическим поиском и RAG-системами (Retrieval-Augmented Generation).
Производительность и точность (Tradeoff): Сергей Голубчик подробно остановился на ключевом вопросе производительности векторных операций и компромиссе между скоростью поиска и точностью (performance vs. precision of search). Он продемонстрировал, как тонкая настройка конфигурации и индексов (например, использование HNSW-индексов) позволяет добиться наилучшего баланса, обеспечивая высокую скорость без существенной потери точности результатов.
3. Видение будущего и сотрудничество
Анна Видениус (CEO MariaDB Foundation) представила стратегический обзор развития проекта, подчеркнув фокус на стабильности, высокой производительности и укреплении позиции MariaDB в корпоративном сегменте.
🤝 Новые горизонты: Планы сотрудничества с sqlize.online
Самой продуктивной частью митапа стало личное общение с Майклом и Анной Видениус, которое вылилось в конкретные договоренности:
Расширение поддержки версий: Платформа sqlize.online расширит поддержку MariaDB до трех актуальных версий, включая последнюю — MariaDB 11.8 — с акцентом на тестирование ее векторных возможностей.
Новый учебный контент: На sqltest.online будет запущен новый набор практических заданий, разработанных совместно с командой MariaDB, для глубокого освоения последних функций и особенностей этой СУБД.
Это сотрудничество поможет ускорить процесс обучения и внедрения инноваций MariaDB среди разработчиков и аналитиков.
❓ Дискуссия: Готовы ли вы использовать векторы в MariaDB?
MariaDB смело интегрирует технологии будущего, делая ставку на миграцию и ИИ.
Уважаемые читатели Хабра, вопрос к вам:
Как вы относитесь к появлению нативной поддержки векторного типа данных в MariaDB? Готовы ли вы использовать эту функцию в своих новых проектах и рассматривать MariaDB как альтернативу специализированным векторным базам данных?
PostgreSQL на 4 ТБ, Patroni на две столицы и 16 000 фур в реалтайме: как мы «перевозили» CARGO.RUN
Привет, Хабр! Представьте ситуацию: один логист управляет 80 машинами одновременно. Маршруты, топливо, простои — все в реальном времени. Остановись сервер — бизнес сразу теряет деньги, а на перевозчиков сваливается хаос.
Именно таков мир, в котором работает команда CARGO.RUN — SaaS-платформа, которая автоматизирует грузоперевозки для топ-игроков рынка. Мы подготовили кейс о том, как помогли CARGO.RUN мигрировать к нам в Selectel. Внутри — настоящий технический детектив и архитектурный дзен.
Базы данных — почему для PostgreSQL с расширениями PostGIS и Timescale (а это 4 ТБ «горячих» данных!) выбрали именно выделенные серверы, а не облако.
Отказоустойчивость — как развернули кластер Patroni, физически разнесенный между дата-центрами в Москве и Санкт-Петербурге, чтобы пережить падение целого региона.
Оркестрация — переход от Docker Swarm к Managed Kubernetes для микросервисов, когда в штате всего три DevOps-инженера.
IaC — как Terraform и GitOps помогли навести порядок и сделать инфраструктуру прозрачной.
Результат миграции — рост производительности логистов в 2,5 раза и сокращение порожнего пробега фур на 53%.
«Тантор Лабс» активно поддерживает российское сообщество открытой СУБД PostgreSQL. Наши специалисты уже много раз выступали спикерами на официальных комьюнити-мероприятиях PG BootCamp Russia, проводили лекции и мастер-классы.
Делимся с вами подборкой наших выступлений, темы которых можно условно разделить на несколько ключевых направлений.
Внутренности PostgreSQL и оптимизация ядра — для тех, кто хочет понимать СУБД «под капотом»
Кстати, на весенний PG BootCamp Russia 2026, который пройдет в Москве, открыт прием заявок на выступления! Это отличный шанс поделиться знаниями с одним из самых сильных профессиональных сообществ.
