Как METRO перенесла 1 000 сервисов и 50 ТБ данных в российское облако за 3 месяца
🏪 Что за компания
METRO — одна из крупнейших сетей мелкооптовой торговли в мире. В России компания управляет 90+ торговыми центрами в 51 регионе и работает одновременно с B2C- и B2B-сегментами: физлицами, HoReCa, магазинами у дома и офисами.
⚡ Задача
С 2019 года METRO активно переходила на облачную инфраструктуру и разрабатывала cloud-native продукты на мощностях зарубежного провайдера. В конце 2023 года под санкционным давлением встала задача локализации: найти отечественное облако, архитектурно близкое к Google Cloud, и перенести туда весь централизованный ИТ-ландшафт. Это около 20 продуктов и 200 микросервисов — все с минимальными доработками.
В январе 2024 ситуация усложнилась: зарубежный вендор объявил об экстренном отключении корпоративной BI-системы. Сроки сжались до трех месяцев.
☁️ Что сделали
METRO выбрала платформу Cloud.ru Advanced как наиболее близкую по архитектуре к Google Cloud. Команды провайдера и ритейлера параллельно решали две задачи:
в экстренном режиме переносили BI-систему с Teradata/MicroStrategy на Advanced Data Warehouse Service с Apache Airflow и DBT — 50 ТБ данных, 10 000 таблиц и 2 000 скриптов преобразования без остановки процессов;
выполняли плановую локализацию ИТ-ландшафта: перенесли еще около 1 000 сервисов, провайдер дополнительно добавил специализированные сервисы под требования METRO.
🦾 Что получили в итоге
Вся корпоративная отчетность сохранила бесперебойную работу. METRO реализовала первый полноценный проект по SaaS-модели и локализовала ИТ-ландшафт с минимальными доработками благодаря архитектурной близости платформ.
Дополнительно компания одной из первых в России запустила в бою сервис Evolution Managed RAG и GPU-инфраструктуру для внедрения LLM под задачи оптимизации бизнес-процессов.
Приглашаем на бизнес-ужин «Как построить ИИ-платформу: преимущества мультивендорских решений»
Очная закрытая встреча от Selectel, Data Sapience и GlowByte для предпринимателей, руководителей и специалистов по машинному обучению (ML) состоится 9 апреля в 18:00. Будет интересно всем, кто планирует автоматизировать бизнес-процессы с помощью ИИ, и хочет разобраться, с чего начать.
Участники на реальных примерах разберут пошагово, как реализуются проекты по машинному обучению (ML) сегодня, и увидят, как современные инструменты помогают решать важные бизнес-задачи. Мероприятие станет площадкой для нетворкинга и свободного диалога на тему ИИ в бизнесе.
В программе доклады:
«Как внедрить ИИ: от инфраструктуры до выхода в прод. Решение Selectel, Data Sapience и GlowByte»Алексей Рундасов, коммерческий директор, Data Sapience; Александр Тугов, директор ИИ-вертикали, Selectel;
«ИИ в продакшене: как инференс превращает модели в деньги» Владислав Кирпинский, директор по облачной интеграции, Selectel;
«Большой языковой барьер: ИИ-платформы 2026» Михаил Зайцев, директор продукта Kolmogorov AI, Data Sapience;
«GenAI на практике: кейс “Таврос”» Артем Самойлов, директор по информационным технологиям (IT) и цифровой трансформации, группа компаний «Таврос»; Александр Ефимов, директор практики искусственного интеллекта и машинного обучения, GlowByte.
Также в рамках бизнес-ужина пройдет круглый стол о границах возможностей ИИ «Хайп vs Реальность». Эксперты обсудят практические примеры, когда внедрение ИИ действительно оправдано, и ситуации, где компании могут столкнуться с ограничениями. Участники разберут технические барьеры, требования к данным и инфраструктуре, а также бизнес-факторы, влияющие на эффективность и окупаемость ИИ-проектов.
Приглашаем на бизнес-ужин «Как построить ИИ-платформу: преимущества мультивендорских решений»
Очная закрытая встреча от Selectel, Data Sapience и GlowByte для предпринимателей, руководителей и специалистов по машинному обучению (ML) состоится 9 апреля в 18:00. Будет интересно всем, кто планирует автоматизировать бизнес-процессы с помощью ИИ, и хочет разобраться, с чего начать.
Участники на реальных примерах разберут пошагово, как реализуются проекты по машинному обучению (ML) сегодня, и увидят, как современные инструменты помогают решать важные бизнес-задачи. Мероприятие станет площадкой для нетворкинга и свободного диалога на тему ИИ в бизнесе.
В программе доклады:
«Как внедрить ИИ: от инфраструктуры до выхода в прод. Решение Selectel, Data Sapience и GlowByte» Алексей Рундасов, коммерческий директор, Data Sapience; Александр Тугов, директор ИИ-вертикали, Selectel;
«ИИ в продакшене: как инференс превращает модели в деньги» Владислав Кирпинский, директор по облачной интеграции, Selectel;
«Большой языковой барьер: ИИ-платформы 2026» Михаил Зайцев, директор платформы Kolmogorov AI, Data Sapience;
«GenAI на практике: кейс “Таврос”» Артем Самойлов, директор по информационным технологиям (IT) и цифровой трансформации, группа компаний «Таврос»; Александр Ефимов, директор практики искусственного интеллекта и машинного обучения, GlowByte.
Также в рамках бизнес-ужина пройдет круглый стол о границах возможностей ИИ «Хайп vs Реальность». Эксперты обсудят практические примеры, когда внедрение ИИ действительно оправдано, и ситуации, где компании могут столкнуться с ограничениями. Участники разберут технические барьеры, требования к данным и инфраструктуре, а также бизнес-факторы, влияющие на эффективность и окупаемость ИИ-проектов.
Что будет на конференции GoCloud 2026: трек «Данные и аналитика»
GoCloud — ежегодная конференция Cloud.ru про ИИ и облака. В этом году она пройдет в кинотеатре «КАРО 11 Октябрь» на Новом Арбате в Москве. Формат смешанный — можно прийти офлайн или подключиться удаленно. Выступят больше 40 экспертов. Вас ждут 15 демозон, практические сессии, тематические круглые столы и, конечно, вечеринка после.
Один из треков будет посвящен данным и аналитике — разберем, какие инструменты позволяют сделать управление данными эффективным и не переплачивать, также расскажем, куда движутся тренды в 2026 году. Вот что запланировано:
Evolution Data Platform: эволюция платформы данных — куда движется дата-платформа Cloud.ru и что изменилось за год.
Как обрабатывать потоковые данные с помощью Evolution Managed Flink — архитектура, компоненты, сценарии использования.
Evolution Managed ArenadataDB в облаке: что изменилось с момента запуска — обновления, анонсы новых функций и клиентский кейс.
Управляемые базы данных и почему это тоже про машинное обучение — почему все начинается не с моделей, а с инфраструктуры для работы с данными.
Управление Evolution Managed Spark с AI: инновации и эффективность — как ИИ помогает оптимизировать Spark-задачи.
Завершит трек круглый стол «Тренды развития дата-сервисов в 2026 году» — про дата-стратегию, суверенные облака, управление данными и как дата-инженерия становится основой для ИИ в реальных проектах.
Успейте подать свою работу на конкурс BI-дашбордов Data Challenge
Партнер GlowByte компания FanRuan продолжает принимать заявки на первый открытый конкурс BI-дашбордов и визуальной аналитики FineGallery Insight Challenge. Срок подачи - до 31 марта.
FineGallery Insight Challenge – это конкурс для аналитиков, BI-разработчиков и команд, которые работают с данными и создают дашборды.
Цель конкурса – показать, насколько мощной и красивой может быть визуальная аналитика, и дать пользователям пространство для обмена идеями, диагностиками, методами анализа и вдохновляющими примерами решений визуализации.
Как участвовать
1. Создайте аналитическую работу в FineBI или FineReport.
2. Заполните форму подачи, включив:
дашборд,
описание работы по структуре (описана на сайте конкурса),
информацию об авторе.
3. Дождитесь подтверждения участия и ждите результатов.
Призовой фонд
Лучшая бизнес-аналитика – 100 000 руб.
Лучший UX (пользовательский опыт) и визуальный дизайн – 70 000 руб.
Приз зрительских симпатий – 30000 руб.
Все подробности, включая сроки и требования к конкурсным работам – на сайте конкурса.
Как Купер перенес 40 ТБ аналитических данных в облако без остановки процессов
🛒 Что за компания
Купер — сервис доставки из магазинов и ресторанов, работающий в 360 городах России. Аналитическая инфраструктура компании обрабатывает данные для управленческой отчетности и ситуативной аналитики — как внутренней, так и для внешних партнеров.
⚡ Задача
С ростом объемов данных старое решение перестало справляться. Нужно было:
найти управляемую СУБД в облаке аналогичную Greenplum по функциям, с поддержкой подключения к внешним источникам;
провести нагрузочное тестирование на реальных OLAP-запросах до миграции;
перенести 40 ТБ бизнес-критичных данных вместе с контуром разработки, не останавливая аналитические процессы.
☁️ Что сделали
Провайдер предложил Evolution Managed ArenadataDB — управляемую СУБД на базе Greenplum с открытым исходным кодом. Команда во время пилота:
развернула отказоустойчивый кластер и настроила процесс миграции;
подключила PXF-коннекторы к внешним источникам данных;
установила нестандартные JDBC-драйверы и оптимизировала использование памяти для крупных запросов;
настроила автоочистку и автоанализ — механизмы автоматического обслуживания СУБД для устойчивой работы под нагрузкой.
🦾 Что получили в итоге
40 ТБ данных и тестовый контур перенесены без остановки процессов. Инфраструктура работает оперативно: данные за вчера доступны уже на следующий день. Выросла скорость выполнения запросов, появилась гибкость масштабирования и прозрачность мониторинга.
В планах — оптимизация резервного копирования, архивация данных и бесшовная интеграция инструментов ИИ и машинного обучения.
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. Классификация
Задача: определить категорию товара по тексту отзыва. Вывод: категории определены верно. MacBook, монитор, наушники — «Электроника», мышь — «Периферия». Время: ~0.5 секунды на строку.
Тест 5. Перевод
Задача: перевести отзыв с русского на английский. Вывод: качественный перевод даже на модели в один миллиард параметров. Время: ~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 год - год, когда выигрывают те, кто построил экосистему, а не просто внедрил инструмент.
Новая страшилка от Citrini Research: Кризис Интеллекта
Глобальный кризис интеллекта 2028
В этом посте я не буду пересказывать данную статью. Считаю, что важно обратить внимание на последствия ИИ автоматизации, о которой в последнее время так много говорят и проследить за мнением людей.
Мнения людей после прочтения статьи разделились на оптимистичные и пессимистичные:
Оптимисты апеллируют к закону Сэя, который в сущности своей говорит следующее: спрос может подстроиться под любое количество предложения. В таком случае сэкономленные бизнесом деньги перетекут в другие и/или новые сектора экономики.
Пессимисты утверждают, что в случае с ИИ базовый механизм закона Сэя ломается. Роботы и алгоритмы производят товары и услуги, но не формируют потребительский спрос. Разрывается цикл "произвёл → получил деньги → потратил", потому что из него исключается человек. И кризис, описанный в статье, очень близок.
Оба лагеря имеют право на существование, но, если верить оптимистам, с нами не случится ничего плохого, поэтому детальнее рассмотрим противоположный вариант развития событий.
Самое "важное", что пытаются нам сказать авторы статьи и другие медийные личности индустрии: произойдёт переоценка человеческого интеллекта и его влияния на формирование цены продукта или услуги. И далее эта мысль подкрепляется предсказаниями об увольнении офисных клерков, джунов и других начальных и средних позиций.
Однако именно такие люди формируют основу ипотечных займов (да-да, снова кризис вокруг ипотеки). Банки спокойно выдавали кредиты, т.к. стабильный доход и условия жизни гарантируют очень вероятное успешное погашение этого самого кредита.
ИИ меняет ситуацию. Резкие сокращения могут повлечь за собой снежный ком, на конце которого будут частные фонды и банки. Скорее всего они смогут отыграться, а в дураках останутся обычные люди (опять).
Остаётся ответить только на 1 вопрос: Куда человечество в целом хочет прийти через N лет?
В теории, таким должна заниматься ОНН, но что-то в эффективности данной организации на фоне последних событий начинает сомневаться всё больше людей.
Случайно можно наткнуться на мысль, что никто никуда идти и не хочет. Только заработать побольше денег и надуть пузыри до предела. Грустная мысль и, можно сказать, "глупая".
Спасибо, что почитали. Надеюсь, смог натолкнуть вас на интересные мысли. Буду рад вашим вопросам / дополнениям / комментариям.
Задал я сегодня этот вопрос нейронкам и вот что получил. ChatGpt, Qwen3.5-Plus, Алиса: 68 Gemini PRO: В текущем положении (вверх ногами) мы видим число 68. Однако, если перевернуть изображение так, чтобы человек стоял на ногах, настоящий номер на футболке будет читаться как 89. Grok решил что изображение неприличное (видимо сказались скандалы с раздевающими функциями). DeepSeek не нашёл текста на картинке, но видимо искал задачу с текстом.
Интересно было бы позадавать этот вопрос детям, но пока такой возможности нет.
Недавно вышла новая версия dplyr 1.2.0, и она принесла несколько важных обновлений, которые делают работу с данными в R ещё проще и удобнее. Опубликовал видео обзор в котором я рассказываю про самые интересные новинки: новые функции фильтрации filter_out(), when_any() и when_all(), обновлённую систему перекодировки с recode_values(), replace_values() и replace_when(), а также о важных оптимизациях старых функций.
Если вы активно используете dplyr в своих проектах, этот обзор поможет вам быстро понять, как ускорить работу с данными и писать более читаемый код. В видео я показываю реальные примеры и сценарии использования новых функций, чтобы вы могли сразу применять их в своих проектах.
Цифровые двойники и 3D-визуализация: опыт GlowByte и FanRuan
GlowByte и FanRuan провели бизнес-завтрак с промышленными компаниями. Мероприятие было посвящено новым возможностям бизнес-аналитики, которые открывают инструменты FineVis и FineReport.
Эксперты продемонстрировали, как компании переходят от статичных дашбордов к интерактивным цифровым двойникам, которые обновляются в реальном времени и помогают принимать решения быстрее: от таблиц и графиков – к живым цифровым моделям.
Чжан Цзэфэн, Product & R&D Lead FineVis, FanRuan, рассказал:
как развивалась визуализация данных – от первых таблиц до VR/AR и 3D-моделирования,
что такое цифровой двойник и какие уровни зрелости существуют – от L0 до автономных систем L5,
почему 3D-визуализация имеет критичное значение для аналитики,
как применяют компании 3D-моделирование в логистике, производстве, энергетике, умных городах, медицине,
как FineVis и FineReport объединяют визуализацию и аналитику, интегрируя данные из ERP-, MES- и IoT-систем.
Алексей Коломенцов, старший консультант практики Business Intelligence, GlowByte, провел демо, в котором пошагово показал, как с помощью FineVis создать полноценного цифрового двойника – от пустой сцены до живой 3D-модели с данными.
В демо вы увидите:
Интерфейс системы и ключевые инструменты для работы.
Как строить сценарии взаимодействия с моделью.
Создание с нуля примера 3D-анимации.
Подключение реальных данных к объектам и их отображение в режиме реального времени.
Как сделать визуализацию интерактивной и полезной для аналитики.
Друзья, 12 февраля проведём открытый вебинар по следам нашего ESB-исследования в «Кругах Громова».
Если коротко — за последний год мы оценили 18 российских интеграционных платформ по единой методологии: 12 категорий, 1 000 баллов. Такого раньше на рынке не было. Результаты местами предсказуемые, местами — неожиданные.
На вебинаре поговорим:
— Почему компании до сих пор путают Kafka, ESB и data pipeline — и платят за это дважды — 5 классов интеграционных решений: когда какой работает, а когда — категорически нет — Как мы строили матрицу зрелости и кто в итоге получил номинацию — Что планируем исследовать дальше — и как повлиять на приоритеты
Будет живой эфир с интерактивом, не просто «говорящая голова».
Кто работает с интеграциями, выбирает платформу или просто в теме — приходите, будет интересно.
GlowByte разработала методику выбора BI на основе сценарного анализа
Источник: Freepik.com
Практика Business Intelligence GlowByte разработала подробное руководство по сценарному выбору BI с готовой Excel-матрицей для сравнения платформ.
GlowByte выделяет 4 ключевых сценария с разными потребностями и акцентами:
отчеты для руководителя,
self-service,
регламентная отчетность,
исследование данных.
Сценарии в матрице сопровождаются своим набором релевантных критериев, каждый из которых имеет оценку критичности, что позволяет адаптировать расчет под конкретный проект: при изменении критичности пересчитываются все баллы, и BI-платформа получает новую оценку.
ℹ️ Методика учитывает изменения в BI-ландшафте, запрос на адаптивность и гибкость, а также необходимость подстраивать инструмент под задачу, а не наоборот. Исследование содержит детальные чек-листы по каждому сценарию, критерии оценки и примеры расчетов.
Автор рассказывает об опыте работы с новым открытым табличным форматом (OTF) Paimon от разработчиков Apache Flink, представляет практические выводы, которые были сделаны на промышленных средах; а также проводит репрезентативное тестирование, где иллюстрирует ключевые практические сценарии.
Появление open table formats исполнило вековую мечту data-инженеров: совместило эффективность хранения и чтения Apache Parquet с возможностью обновления данных без полной их перезаписи. Достигается это за счет парадигмы Merge-On-Read и «отложенного удаления», когда информация об удалении старых версий записи пишется в deletion-файлы. Для фреймворков потоковой обработки, например Flink, это открывает возможности по обновлению данных прямо в Data Lake в режиме, близком к реальному времени, а для движков пакетной обработки — Spark, Impala, Trino, StarRocks — сокращает расход ресурсов на MERGE новых порций данных в витрины.
В новом выпуске подкаста «В SREду на кухне» обсуждаем суть мониторинга и причины его хронических сбоев. В фокусе — метрики и алерты: как не утонуть в потоке предупреждений, отсеять ложные сигналы и выстроить эффективную систему. Говорим о том, как SRE анализируют графики, какие показатели бизнес считает ключевыми, и развенчиваем миф о том, что «зелёный» статус всегда означает успех.
Ведущие:
Михаил Савин, SRE Community Lead в Авито;
Андрей Волхонский, руководитель юнита System в Центре разработки инфраструктуры Авито;
Евгений Харченко, руководитель отдела по развитию практик в разработке и эксплуатации в Райффайзен Банк.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Процедурное SQL-расширение в Lakehouse-платформе — новые возможности для работы с данными
В блоге технологического партнера GlowByte вышла новая статья. Команда Data Sapience рассказала о реализации процедурного расширения для работы с MPP-движками Lakehouse-платформы данных Data Ocean Nova, которое стало доступным для пользователей.
Ребята рассказывают о возможностях, применимости и сценариях использования процедурного языка в аналитической платформе данных и делятся планами по развитию Data Ocean Nova.
В рамках «Кругов Громова» сейчас запускаем новое исследование — по российским платформам роботизации бизнес‑процессов (RPA). Хотим собрать честный опыт внедрения: что реально автоматизировали, где программные роботы помогают, а где мешают жить.
Если вы участвовали во внедрении RPA, запускаете и поддерживаете программных роботов (RPA‑ботов) в проде или, наоборот, уже обожглись и отказались от платформы — очень нужны ваши ответы. Опрос занимает 5–10 минут, он про практику, а не про маркетинг.
Результаты войдут в открытое исследование по российским RPA‑платформам на russianbi.ru — в духе прошлых исследовательских кругов: с разбором сильных и слабых сторон и типичных граблей.
Если есть история «как у нас роботы пошли не по плану» или, наоборот, показательный успешный кейс — кратко накидайте в комментарии к этому посту, это тоже поможет исследованию.
