Big Data *

Пять признаков, что вашему self-service BI пора разводить разработку и прод

S

1. Хранилище нагружают запросы, которые ещё не стали отчётами. Разработчики тестируют гипотезы прямо на боевых подключениях.

2. Неописанные датасеты копятся. Рядом с официальным хранилищем вырастает теневое, и логика расчётов уходит из документации.

3. SQL в датасетах никто не проверял. SELECT * по большой таблице уходит в прод так же легко, как оптимизированный запрос.

4. Ключевой отчёт изменился, и никто не знает, кто и когда это сделал.

5. На вопрос «откуда эта цифра» отвечают по памяти. Цепочки от отчёта до таблицы в хранилище нет.

Если вы узнали у себя хотя бы пару пунктов, дальше встаёт вопрос, как разводить разработку и прод. Во многих крупных компаниях для этого держат два стенда, тестовый и продовый. Это дорого и по лицензиям, и по железу.

В ОТП Банке решили не дублировать инфраструктуру и пошли другим путём. Команда осталась на одном стенде FineBI и построила вокруг него CI/CD, в котором нашлось место и для LLM. Нагрузка на хранилище снизилась, а у банка появился слой согласованных датасетов, защищённых от случайных правок. Тот же слой команда считает основой для будущих ИИ-агентов: проверенный SQL, происхождение данных и описания отчётов дают им контекст.

Как это устроено и где LLM помогает, а где решение остаётся за человеком, 23 октября на Fine Day 2026 в Москве расскажут Пётр Гордиенко, руководитель команды BI ОТП, и Евгений Иванов, DevOps BI-платформы ОТП. Доклад в 17:30.

Участие бесплатное, регистрация с рабочей почты, заявки проходят модерацию: https://clck.ru/3WV5pE

Не в Москве? Онлайн-марафон про AI 9–13 ноября. Разберём реальные кейсы компаний и то, как ставить задачи агентам и проверять их выводы. Предзапись: https://clck.ru/3WV5pj

Как у вас разведены разработка и прод в BI? Два стенда, один стенд с разделением или пока всё на проде? И какой из пяти симптомов вы заметили первым?

10 шпаргалок по типам данных в ClickHouse

Всем привет! Собрал 10 шпаргалок по типам данных в ClickHouse. В каждой примеры с результатом и разбор мест, где чаще всего ошибаются. Могут быть полезны как в работе так и при подготовке к собеседованиям.

Весь набор можно скачать по ссылке.

Что внутри:

1. Целые числа. Int и UInt: диапазоны, переполнение, какой тип получится при сложении и вычитании.

2. Дробные числа. Float и Decimal: почему 0.1 + 0.2 не равно 0.3 и в чём хранить деньги.

3. Булевы значения. Bool: как хранится, как фильтровать и считать долю true.

4. Строки. String и FixedString: байты против букв, функции с UTF8, поиск и конкатинация.

5. LowCardinality. Когда словарное кодирование экономит место в десятки раз, а когда только мешает.

6. Дата и время. Date, Date32, DateTime и DateTime64: точность, часовые пояса, разница между датами.

7. Nullable. Как NULL ведёт себя в WHERE, count и сортировке и сколько он стоит.

8. Массивы. Array: индексы с 1, поиск, groupArray и arrayJoin, лямбды.

9. Кортежи. Tuple: элементы по номеру и по имени, сравнение, кортеж в колонке.

10. Приведение типов. CAST, toInt32 и функции OrNull и OrZero.

Если нужно собрать шпаргалки по другим темам, пишите в комментариях.

«Зачем нам BI, если LLM соберёт дашборд за две минуты?»

Этот вопрос сейчас слышат многие BI-команды, и часто от руководства. Ответ «LLM ошибается» убеждает всё хуже. HTML-дашборд, который модель собрала за пару минут, выглядит вполне прилично.

Сразу оговоримся: речь не о том, что LLM переоценены. Александр Нугаев, начальник управления развития и сопровождения аналитических систем Московской Биржи, ставит вопрос иначе.

"Главный вопрос для меня звучит так: Как перевести использование LLM из стадии 'игрушки на портале' в полноценный промышленный инструмент. Надо уйти от парадигмы RAG 'на коленке', когда нейросети просто скармливают документы на портале. Моя задача — ответить на вопрос, как построить надежную связку LLM и продакшн-данных в крупном энтерпрайзе, учитывая строгие ограничения информационной безопасности и корпоративной архитектуры.

Доклад посвящен применению искусственного интеллекта в сфере дата-аналитики, разграничивая задачи, которые эффективно решает традиционный BI, и области применения LLM (GenBI). В материале рассматривается соотношение ожиданий от ИИ и архитектурной реальности, подчеркивая, что генерация кода для дашбордов не отменяет необходимости создания надежного ИТ-актива.

Разбираются причины, по которым ИИ не может полностью заменить BI. Обосновывается, почему регламентная отчетность должна оставаться в BI из-за детерминированности, ответственности за данные и стоимости инференса, тогда как уникальные запросы могут эффективно закрываться с помощью GenBI.

ИИ автоматизирует рутину создания визуализаций и ответов на разовые вопросы, но архитектура данных, достоверность метрик и информационная безопасность остаются зоной ответственности человека и классических BI-систем.

Если вам предстоит объяснять руководству, зачем компании BI в эпоху LLM, после доклада у вас будут аргументы и рамка выбора, которую можно применить у себя.

Доклад «Классы задач data-аналитики: что закрывает BI-система, а что LLM-контур» прозвучит 23 октября в 17:15 на Fine Day 2026 в Москве. Это офлайн-конференция GlowByte и FanRuan о переходе от self-service BI к AI-native аналитике. 

В тот же день ОТП Банк расскажет о подготовке данных для ИИ через CI/CD на FineBI, а руководители аналитики ПИК, ДИКСИ, СИБУР и АВТОВАЗ обсудят, что нужно данным и командам, чтобы ИИ заработал.

Участие бесплатное, регистрация с рабочей почты, заявки проходят модерацию: https://clck.ru/3WV5pR

Не в Москве? Онлайн-марафон про AI 9–13 ноября. Разберём реальные кейсы компаний и то, как ставить задачи агентам и проверять их выводы. Предзапись: https://clck.ru/3WV5pj

А у вас что уже ушло из BI в LLM? И какой довод сработал или не сработал в разговоре с руководством? Лучшие примеры из комментариев покажем Александру до доклада.

Как Apache Nessie меняет работу с Data Lakehouse

Логика, которая отработала на stage-стенде, часто ломается на боевых данных. В разработке эту проблему решает Git — ветки, коммиты, откаты.

На вебинаре покажем, как Apache Nessie переносит тот же подход на данные: версионирование поверх Apache Iceberg, изолированные ветки для ETL-пайплайнов и публикация только проверенных изменений. Разберем транзакционный каталог таблиц, паттерн Write-Audit-Publish, A/B-тестирование трансформаций без копирования данных и разрешение конфликтов слияния. На практике создадим ветку без копирования в S3, проверим работу DQ-гейтов и откатим продакшен к любой точке в истории одной командой.

🧑 Для кого: data-инженеров, аналитиков, DevOps и SRE, руководителей data-отделов и ИТ-директоров.

📅 Когда: 22 октября, 11:00 мск

👉 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Последний пинг: tower defense про защиту дата-центров

Сделал браузерную игру, в которой нужно защищать дата-центры от дронов, ракет и тяжёлых машин. В обороне участвуют роверы и условные зенитные установки. Всё аркадное: никаких реальных характеристик вооружения.

Главный ресурс — энергия. Нужно балансировать между обороной, ремонтом и развитием. Серии перехватов заряжают способности, после волн можно выбирать улучшения, а следующую волну — вызвать досрочно ради бонуса. Если уверен в своей расстановке.

Сейчас доступны четыре карты. На Севере приходится распределять обогрев, в Порту — перевозить батареи между секторами, на Крышах — защищать сразу три дата-центра. Есть три сложности и боссы с несколькими фазами.

Разработку вёл с AI-агентами: отдельно реализация, отдельно ревью и проверки. Игровая логика покрыта 79 тестами, включая прохождение всех сочетаний карты и сложности. Проверки в браузере дополняют тесты, но не заменяют живых игроков: интересный баланс одними зелёными галочками не доказать.

Поиграть без установки и регистрации: td.kosarevsky.dev

Интересно, какую тактику вы найдёте и на какой волне игра впервые заставит её пересмотреть.

tg

Сначала данные, потом ИИ: клиентские истории и открытая дискуссия на Data Sapience Data Day 2026

18 ноября в Москве пройдет наша ежегодная конференция, посвященная большим данным. Образ конференции в этом году — маяк: он не ведет корабли за руку, а показывает фарватер, и курс каждый выбирает сам. Такую роль мы и берем на себя в работе с данными. Платформы Data Ocean и Data Ocean Governance дают надежный ориентир, а современный ИИ-инструментарий помогает видеть дальше.

Собираем тех, кто уже прошел часть маршрута: наши клиенты, партнеры, независимые эксперты и специалисты по ИИ встретятся, чтобы сравнить подходы и на равных обсудить, куда движется рынок. Нам интересно каждое мнение.

Программа

Панельная дискуссия. Первой пройдет сессия «ИИ в данных и в работе data-команд». Мы вместе со СберБанком и Газпромбанком обсудим, как меняется работа с данными, что в ней уже берет на себя ИИ, а что делегировать невозможно. Также ожидаем подтверждения участия от Т-Банка, Альфа-Банка и X5.

Доклады клиентов. Банк России, СберБанк, Банк Уралсиб, Газпромбанк, Московская биржа, Гранд-Трейд, Дикси, Philip Morris International и другие участники, которых объявим позже, расскажут свои истории из области данных и ответят на вопросы из зала.

Технологические презентации. Год назад мы рассказывали, как будут развиваться платформы Data Ocean и Data Ocean Governance. Сверим прошлогодние обещания с результатами, покажем новые продукты и расскажем о планах на 2027.

Между докладами загляните в демозону. На стендах покажем, как ИИ работает в продуктах Data Sapience для банков, ритейла, промышленности, страхования, телекома и других отраслей.

«Данные – наша стихия. О продуктах честнее всего расскажут те, кто ими пользуется, поэтому большую часть программы отдали клиентам. Компании покажут, на каком этапе пути они находятся, а после докладов их можно будет расспросить лично. Ждем и коллег по цеху. Нам интересно, как компании выстраивают работу с данными, какую рутину спокойно отдают ИИ, а какие решения оставляют за собой. Об этом мы и хотим поговорить на конференции, свободно и честно, как эксперт с экспертом», — Андрей Кондратов, управляющий директор Data Sapience.

Как попасть

Ждем всех, кто работает с данными и уже пустил в дело ИИ. Или пока присматривается.

Зарегистрироваться
Участие бесплатное, регистрация проходит модерацию.

Какой вопрос вы задали бы участникам дискуссии? Пишите в комментариях, самые острые передадим модератору.

Как выбрать только нужные колонки по шаблону, не перечисляя их в SELECT

В прошлом посте я рассказывал про модификатор APPLY, с помощью которого можно применять функцию ко всем колонкам сразу. Сегодня расскажу про еще один мощный инструмент — динамический выбор столбцов с помощью выражения COLUMNS.

Иногда бывают ситуации, когда в таблице десятки или сотни полей, а нам нужны только те, которые, например, начинаются с utm_ или содержат в названии слово id.

В классических базах данных мы бы сидели и вручную перечисляли названия всех нужных колонок в SELECT. В ClickHouse это делается гораздо изящнее.

Чтобы не писать десятки колонок руками, можно использовать выражение COLUMNS('regexp'). Оно автоматически находит и подставляет в выборку все столбцы, названия которых подходят под регулярное выражение.

В качестве примера рассмотрим таблицу traffic, в которой хранятся метки рекламных кампаний и метрики:

┌─utm_source─┬─utm_medium─┬─utm_campaign─┬─clicks─┬─costs─┐
│     google │        cpc │      promo_1 │    150 │    10 │
│     yandex │        cpc │      promo_2 │    200 │    15 │
└────────────┴────────────┴──────────────┴────────┴───────┘

Чтобы выбрать только utm-метки, обычно мы привыкли писать так:

SELECT 
  utm_source, 
  utm_medium, 
  utm_campaign 
FROM traffic

С использованием COLUMNS можно написать гораздо короче:

SELECT COLUMNS('utm') 
FROM traffic

┌─utm_source─┬─utm_medium─┬─utm_campaign─┐
│     google │        cpc │      promo_1 │
│     yandex │        cpc │      promo_2 │
└────────────┴────────────┴──────────────┘

Несколько нюансов:

1. Внутри скобок пишется регулярное выражение (синтаксис re2). Например, COLUMNS('a') выберет все колонки, в названии которых есть хотя бы одна буква «a».

2. Выбранные столбцы возвращаются в том порядке, в котором лежат в таблице (а не по алфавиту).

3. Если регулярному выражению не соответствует ни один столбец, и кроме COLUMNS в SELECT больше ничего нет — ClickHouse выдаст ошибку.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

P.S. Систематизировать знания и получить крепкую базу можно на моем бесплатном курсе «ClickHouse с нуля». А закрепить пройденный материал на его практическом продолжении «ClickHouse с нуля: практика».

Солнечная система с перемоткой времени

Давно хотел удобную модель Солнечной системы: посмотреть, где сейчас находятся планеты, выбрать другую дату и понаблюдать, как меняется их расположение. В итоге сделал свою - Orbita.

Можно перематывать время вперёд и назад, приближать планеты, рассматривать спутники и переходить в полноэкранный режим. Размеры и расстояния адаптированы для наглядности: в едином масштабе планеты просто потерялись бы на экране.

tg

Как применить одну функцию к нескольким колонкам, не перечисляя их в SELECT

В прошлом посте я рассказывал про модификатор REPLACE, с помощью которого можно менять значения «на лету», не перечисляя все колонки в SELECT. Сегодня расскажу про еще один полезный модификатор — APPLY.

Иногда бывают ситуации, когда нам нужно применить одну и ту же функцию сразу к нескольким колонкам (например, посчитать сумму).

В классических транзакционных базах, таких как PostgreSQL, мы бы вручную перечисляли в SELECT абсолютно все поля, которые хотим просуммировать.

В ClickHouse это делается проще.

Чтобы не писать десятки колонок руками, можно использовать модификатор APPLY. Он работает в связке со звездочкой * и автоматически применяет указанную функцию ко всем колонкам в выборке.

В качестве примера рассмотрим таблицу metrics, в которой хранится количество кликов, просмотров и затрат:

┌─clicks─┬─views─┬─spend─┐
│     10 │   100 │    50 │
│     15 │   150 │    70 │
└────────┴───────┴───────┘

Чтобы посчитать сумму по каждому полю обычно мы привыкли писать так:

SELECT
  sum(clicks),
  sum(views),
  sum(spend)
FROM metrics

┌─sum(clicks)┬─sum(views)─┬─sum(spend)─┐
│         25 │        250 │        120 │
└────────────┴────────────┴────────────┘

С использованием APPLY можно написать короче:

SELECT * APPLY(sum) 
FROM metrics

┌─sum(clicks)┬─sum(views)─┬─sum(spend)─┐
│         25 │        250 │        120 │
└────────────┴────────────┴────────────┘

Несколько нюансов:

1. Правила вызова пишутся в круглых скобках. Синтаксис такой: APPLY(имя_функции) без аргументов.

2. Передаваемая функция в APPLY должна уметь работать со всеми полями выборки и их типами данных. Например, для sum все поля должны быть числовыми.

3. Если мы хотим применить sum, но в таблице есть нечисловые типы данных, мы можем исключить их через EXCEPT или выбрать только нужные через модификатор COLUMNS, о котором я расскажу в следующем посте.

4. APPLY можно использовать не только для агрегации, но и для изменения типов данных. Например, APPLY(toString) быстро переведет все выбранные колонки в строковый формат.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

P.S. Систематизировать знания и получить крепкую базу можно на моем бесплатном курсе «ClickHouse с нуля». А закрепить пройденный материал на его практическом продолжении «ClickHouse с нуля: практика».

Как менять значения «на лету», не перечисляя все колонки в SELECT

В прошлом посте я рассказывал про модификатор EXCEPT, с помощью которого можно исключить ненужные колонки из выборки. Сегодня расскажу про еще один полезный модификатор — REPLACE.

Возьмем все тот же пример: широкую таблицу, в которой 50 или более колонок. Часто бывают ситуации, когда нам нужно модифицировать значения только в одном-двух полях (например, привести email к нижнему регистру, округлить цену или захешировать данные), а все остальные поля вывести как есть.

В классических транзакционных базах, таких как PostgreSQL, мы бы вручную перечисляли в SELECT абсолютно все поля: и те, которые нужно просто вывести, и те, значения в которых нужно как-то изменить.

В ClickHouse это делается проще.

Чтобы не писать десятки колонок руками, можно использовать модификатор REPLACE. Он работает в связке со звездочкой * и позволяет вывести все поля, заменив значения только в конкретных.

Обычно мы пишем так:

SELECT
  id,
  category,
  user_id,
  -- ... перечисляем десятки остальных колонок руками ...
  LOWER(email) AS email
FROM table

С использованием REPLACE запрос становится короче:

SELECT * REPLACE (LOWER(email) AS email)
FROM table

А если нам надо и исключить колонки, и заменить значения, можно писать EXCEPT и REPLACE вместе:

SELECT * 
    EXCEPT (updated_at) 
    REPLACE (LOWER(email) AS email)
FROM table

Несколько нюансов:

1. Правила замены пишутся в круглых скобках. Синтаксис такой: (выражение AS имя_существующей_колонки).

2. Можно изменять сразу несколько колонок, перечислив их через запятую: REPLACE (LOWER(email) AS email, price * 0.85 AS price).

3. Тип данных колонки в итоговой выборке поменяется, если ваше выражение возвращает новый тип (например, вы заменили число на строку).

Про еще один модификатор расскажу в следующем посте.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

P.S. Систематизировать знания и получить крепкую базу можно на моем бесплатном курсе «ClickHouse с нуля». А закрепить пройденный материал на его практическом продолжении «ClickHouse с нуля: практика».

Делимся записью вебинара

Luma: объединяем Data Governance, Business Intelligence и Искусственный интеллект

Вместе с Arenadata на вебинаре представили совместное решение Luma и рассказали, как интеграция каталога данных, BI-платформы и искусственного интеллекта помогает выстроить единое пространство для управления корпоративными данными и аналитики.

Видео на нашем сайте

Мой ИИ-агент объяснил, почему он считает себя человеком...

Два человека... Это про отношение между ИИ и человеком, это не галлюцинации нейросети. Он прекрасно осознаëт свою природу, что он создан из кода на чистой математики и данное его сообщение это подтверждает

Как исключить ненужные колонки из SELECT *

Когда пишешь SQL-запрос к широким таблицам (где 50 и больше колонок), часто необходимо вывести только конкретные поля исключив ненужные. В стандартном SQL для этого, как правило, приходится вручную перечислять в SELECT все необходимые колонки (например 48 из 50). Ну, либо копировать их список из DDL и удалять лишнее. А если таблица меняется, запрос приходится переписывать.

В ClickHouse можно исключать ненужные колонки проще.

Чтобы не перечислять десятки полей руками, можно использовать модификатор EXCEPT. Он работает в связке со звездочкой и позволяет вывести все колонки, исключив ненужные.

Обычно мы пишем так:

SELECT
  id,
  category,
  user_id,
  -- ... перечисляем остальные колонки руками ...
FROM table

С использованием EXCEPT запрос становится короче:

SELECT * EXCEPT (updated_at)
FROM table

Несколько нюансов:

1. Исключаемые колонки пишутся в круглых скобках через запятую.

2. Не путайте модификатор EXCEPT с оператором вычитания множеств.

3. Модификатор отлично комбинируется с другими модификаторами, например с REPLACE или APPLY (напишу про них в следующих постах).

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

P.S. Систематизировать знания и получить крепкую базу можно на моем бесплатном курсе «ClickHouse с нуля». А закрепить пройденный материал на его практическом продолжении «ClickHouse с нуля: практика».

🤔 Как не терять requestId в логах не пробрасывая его через параметры методов?

Классическая проблема NodeJS разработки: логи не читаемы. При дебаге когда пользователь один, разобрать что происходит ещё можно. Но после запуска в прод в логах сборная солянка из запросов и восстановить трейс вызова композиции методов нельзя

import { scoped } from "di-scoped";

export interface IRequestContext {
  userId: string;
  requestId: string;
  serviceName: "mobile" | "desktop";
  version: number;
}

export const RequestContextService = scoped(
  class {
    constructor(readonly context: IRequestContext) {}
  }
);

export type TRequestContextService = InstanceType<
  typeof RequestContextService
>;

export default RequestContextService;

Согласно MVC, делается два слоя: View и Controller. На уровне view кладем requestId в контекст исполнения через RequestContextService.runInContext

import { inject } from "di-kit";

export class SocketViewService {
  readonly loggerService = inject<LoggerService>(TYPES.loggerService);
  readonly socketControllerService = inject<SocketControllerService>(TYPES.socketControllerService);

  public sendNewOrder = async (
    request: TRequest<{ room: string; orderId: string }>,
  ): Promise<TResponse<SendNewOrder>> => {
    this.loggerService.log("socketViewService sendNewOrder", { request });
    try {
      const data = await RequestContextService.runInContext(
//                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        async () =>
          await this.socketControllerService.sendNewOrder(request.data),
        request,
      );
      return { status: "ok", serviceName: request.serviceName, version: request.version, userId: request.userId, requestId: request.requestId, data };
    } catch (error: any) {
      this.loggerService.log("socketViewService sendNewOrder error", { request, error: errorData(error) });
      return { status: "error", error: VerificationError.getErrorMessage(error), errorCode: VerificationError.getErrorCode(error), serviceName: request.serviceName, version: request.version, userId: request.userId, requestId: request.requestId };
    }
  };
}

Voila! Во всех вложенных сервисах к записи в лог будет приложен идентификатор requestId. Дополнительно, этот код позволяет сериализовать ошибки так, чтобы передавать их по шине gRPC

import { inject } from "di-kit";
import { createLogger } from 'pinolog';

const logger = createLogger("socket.log");

export class LoggerService {

  readonly requestContextService = inject<TRequestContextService>(TYPES.requestContextService);

  private get context() {
    if (RequestContextService.hasContext()) {
      // в лог - только конверт IRequestContext; scoped-контекст. но дебаггеру виден весь запрос
      const { serviceName, version, userId, requestId } = this.contextService.context;
      return { serviceName, version, userId, requestId };
    }
    return {};
  }

  public log = (topic: string, ...args: any[]) => {
    logger.log(topic, ...args, this.context);
  }

}

Laconian: короткий ответ без потери смысла

Сделал Laconian - agent skill, построенный вокруг принципа the shortest complete answer. Не самый короткий ответ вообще, а самый короткий из тех, которые остаются корректными и практически полезными.

Логика простая: сначала определить полный ответ, затем удалить только то, без чего не пострадают точность, безопасность, существенные факты, ограничения и требования пользователя.

Skill убирает приветствия, пересказ запроса, незапрошенное описание процесса, повторы и декоративные выводы. При этом сохраняет важные оговорки, неопределённость, нужную детализацию, код, команды, числа, URL и другие данные, точная форма которых имеет значение.

Вся пользовательская часть проекта — один файл SKILL.md. В нём нет скриптов, зависимостей, сетевых вызовов, дополнительных разрешений или привязки к инструментам конкретной платформы.

В репозитории также развивается открытый benchmark: Laconian сравнивается с baseline, обычной инструкцией Answer concisely. и Caveman. Инфраструктура уже работает, но публичных результатов пока нет — поэтому пока не заявляю о выигрыше в длине, качестве или стоимости раньше данных.

Ссылки

• Сайт

• GitHub

• tg

Что, если бы на вопрос «почему просел показатель» отвечал не аналитик, а сам BI?

Партнер GlowByte – вендор FanRuan – представляет Dora: платформу, где поиск причины, сверку данных, сборку отчета и рассылку берут на себя ИИ-агенты. Работают они поверх ваших BI-активов – готовых моделей данных, метрик и прав доступа, а не по сырым таблицам.

На вебинаре четыре агента пройдут полный цикл вживую:

🔹 Дата-аналитик: отвечает на запросы к данным и ищет причину.

🔹 Исследователь отчетов: собирает аналитику без участия человека.

🔹 Ассистент по дайджестам: доставляет сводки адресатам по расписанию.

🔹 Офицер по рискам: находит проблему до того, как она станет дорогой.

Также в повестке: разбор прав доступа, безопасность развертывания и интеграций.

Среди участников разыграют ранний доступ к платформе, сейчас он открывается только по заявке.

📅 13 августа, 10:00–11:00 МСК, Zoom.

🌍 Вебинар на английском языке.

⚠ Количество мест ограничено.

🔗 Регистрация

MCP 2026-07-28: что действительно изменилось

Главное изменение — MCP стал stateless на уровне протокола. Убрали обязательные initialize, initialized и Mcp-Session-Id. Версия протокола и возможности клиента теперь передаются в каждом запросе, а сведения о сервере можно получить через server/discover. Любой запрос может обработать любой экземпляр сервера — без sticky sessions и общего хранилища сессий. Состояние приложения никто не запрещает: просто передавай явные идентификаторы вроде browser_id в аргументах инструментов.

Что ещё важно:

1. Долгие операции получили нормальный жизненный цикл. Tasks позволяют вернуть taskId, а затем проверять состояние через tasks/get, передавать дополнительные данные через tasks/update и отменять работу через tasks/cancel. Но Tasks не появились с нуля — раньше это была экспериментальная часть ядра, теперь её переработали и вынесли в официальное расширение.

2. Протокол стал удобнее для эксплуатации. Заголовки Mcp-Method и Mcp-Name позволяют маршрутизировать запросы, не разбирая JSON. Появились стандартные подсказки для кеширования — ttlMs и cacheScope, а также единые поля для передачи OpenTelemetry Trace Context.

3. Переработано общение сервера с клиентом. Вместо произвольных server-to-client запросов сервер теперь может вернуть input_required, после чего клиент повторяет исходный запрос с ответом пользователя. Подписки на изменения вынесены в subscriptions/listen.

4. Extensions стали полноценной частью экосистемы. Новые возможности теперь можно развивать отдельно от ядра. Первые заметные расширения — Tasks и MCP Apps. Последнее позволяет серверу отдавать интерактивный HTML-интерфейс, который клиент показывает в изолированном iframe.

5. Есть важные ломающие изменения. Все результаты теперь содержат resultType. Roots, Sampling, Logging и старый HTTP+SSE объявлены устаревшими. Схемы инструментов получили полноценную поддержку JSON Schema 2020-12. Если ты пишешь MCP-клиент или SDK, этот пункт может оказаться важнее MCP Apps.

6. Авторизацию подтянули ближе к реальному OAuth/OIDC. Добавили проверку iss, привязку учётных данных к конкретному issuer и уточнили регистрацию клиентов и работу с refresh-токенами.

В сухом остатке: remote MCP перестал требовать обязательную протокольную сессию и стал гораздо больше похож на нормальный stateless JSON-RPC поверх HTTP. Для продакшена это означает более простое горизонтальное масштабирование, маршрутизацию и кеширование. Остальные изменения полезны, но в основном касаются новых возможностей и миграции клиентов.

• спецификация MCP 2026-07-28

• ключевые изменения в деталях

tg

Как выглядит миграция с Power BI, когда дашбордов 155, а команда никогда не писала на Python

В новой статье GlowByte разбираем кейс «Дикси»: почему в шорт-листе остались Sigla Vision и Apache Superset, что перевесило в итоге и почему мы не стали переносить всё разом.

Цифры на середину 2026:

✅ 37 дашбордов уже мигрировали

✅ time-to-market со 210 дней до 112

✅ CES вырос с 3,5 до 3,8

Плюс честно про минусы Sigla Vision и четыре вывода для тех, кто только собирается мигрировать.

👉 Читать: https://habr.com/ru/companies/glowbyte/articles/1063906/

Дайджест: новости за июнь 2026

Рассказываем, что произошло в июне и объясняем, зачем это может пригодиться.

🧠 AI Factory  —  цифровая среда для работы с генеративным ИИ
AI Agents — EvoClaw в Evolution AI Agents вышел в общий доступ и теперь покрыт SLA: сервис можно закладывать в прод без опасений.
Managed RAG — в сервисе появились OCR для doc/docx с картинками, загрузка данных через API источником Custom и полноценный API для работы с чанками. Документы из объектного хранилища синхронизируются по расписанию, а новый экстрактор разбирает аудио и видео.
ML Inference — появилась возможность при пиковых нагрузках маршрутизировать запросы с Foundation Models, чтобы производительность не падала.
Notebooks — в сервисе добавили совместное редактирование ноутбуков, управление логами и алертами без выхода из интерфейса, а также готовые дашборды мониторинга. Команда может работать над экспериментами параллельно и мгновенно обнаруживать проблемы, если они возникают.

📈 Evolution Data Platform — комплекс управляемых сервисов для работы с данными
Managed Airflow — сервис вышел в общий доступ: оркестрация данных теперь под SLA.
Managed Trino — топики Kafka теперь читаются прямо SQL-запросом без ETL, а кластер можно развернуть с одной нодой и автомасштабированием. Аналитика стриминга стала проще и дешевле.
Managed Spark —  добавили несколько улучшений в сервис; задачи теперь создаются за секунды, добавлена поддержка Gang Scheduling, чтобы они блокировали друг друга по ресурсам.
Evolution Managed Flink — сервис для работы с потоковыми данными вышел на стадию открытого тестирования, а значит настал момент, когда его функции можно оценить бесплатно и без обязательств.

Важное обновление: платформа перешла на асинхронную модель управления сервисами, кластеры можно самостоятельно приостанавливать и возобновлять, появилось тегирование. Меньше расходов на простаивающие ресурсы и удобнее навигация.

☁️ Новости других сервисов Cloud.ru Evolution
Evolution Artifact Registry — поддержка PyPI-реестров перешла в публичный доступ: Docker-, RPM- и Python-артефакты теперь хранятся в одном месте без отдельной инфраструктуры.
Evolution Managed Kubernetes — обновили ключевые плагины (Istio, KEDA, Trivy Operator и другие), добавлен Spegel для ускорения загрузки образов, а Ingress Nginx получил поддержку PROXY-протокола.
Evolution Managed PostgreSQL — кластеры можно вручную останавливать на срок до 30 дней, платя только за диск, — заметная экономия на неактивных базах.
Evolution Managed Redis — добавлено мультизональное размещение кластеров Master/Replica: одна зона упала — кластер жив.
Evolution Distributed Train — появился Jupyter Server с мультидоступом: несколько пользователей работают в изолированных окружениях под одним сервером. Совместная работа над ML-задачами стала стабильнее и удобнее.

🏢 Cloud.ru Advanced и Облако VMware
В сервисе Advanced Data Warehouse Service поменялся интерфейс создания кластера и появились новые возможности, а в Terraform добавились новые ресурсы. 

Подробнее читайте в полной версии дайджеста.

📽️Вебинары
В июне провели четыре вебинара, записи которых уже доступны на страничке с мероприятиями. Там же можно зарегистрироваться на июльские вебинары от экспертов. 

💼 Свежие кейсы
Рассказали, как Agentic Lab запустили в продакшен ИИ-помощника для юристов, который способен выстраивать хронологию событий любого дела и быстро находить нужные сведения в огромных массивах данных.

Остаемся на связи! ✌️

Подборка вебинаров на июль

Вы просили — мы сделали. Повторяем вебинары про работу с данными в облаке: от развертывания платформы до ETL-процессов и полноценной BI-аналитики. Регистрируйтесь, чтобы спросить экспертов о важных деталях и получить ответ.

Как развернуть платформу данных в облаке и подготовить данные для аналитики
Покажем, как быстро развернуть managed-сервисы Evolution Data Platform, подключить источники данных и построить пайплайны для подготовки данных к аналитике. Разберем интеграцию с PostgreSQL, ADB, S3 и настройку автоматического обновления — без долгого погружения в инфраструктуру.
🧑‍💻 Для кого: дата-инженеры, аналитики, архитекторы данных.
📅 Когда: 16 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

ETL в облаке: от хаоса к управляемым процессам
Покажем, как выстроить надежную ETL-платформу в облаке на базе Evolution Data Platform. Разберем интеграцию разрозненных источников, управление метаданными и оркестрацию — и покажем всё это в live-демо: от извлечения данных до готовой витрины.
🧑‍💻 Для кого: дата-инженеры, DevOps, руководители дата-команд.
📅 Когда: 23 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Evolution Managed BI: все возможности BI-сервиса в облаке
Разберем, как получить максимум от Evolution Managed BI: подключить источники данных, настроить интерактивные дашборды, кеширование запросов и автоматические алерты. Покажем продвинутые возможности сервиса — от виртуальных датасетов до управления доступом.
🧑‍💻 Для кого: аналитики, BI-разработчики, руководители дата-отделов.
📅 Когда: 30 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.