Data Summit 2026: главные тезисы для бизнеса в СНГ

На прошлой неделе в Бостоне прошёл Data Summit 2026 - одна из тех конференций, где собираются люди, которые принимают архитектурные решения, а не продают слайды. Я слежу за ней регулярно, и в этот раз набралось три тезиса, которыми хочется поделиться. Каждый из них касается того, чем занимается WARP.D, и каждый - повод задуматься, прежде чем подписывать смету на новый DWH.

---

1. Стек схлопывается. Но не так, как говорят со сцены

Sanjeev Mohan, бывший VP Research в Gartner, открыл второй день keynote-ом «The Stack Is Collapsing». Звучит драматично, и тезис простой: границы между операционными и аналитическими базами растворяются.

Расшифрую. Последние 20 лет архитектура корпоративных данных выглядела как четырёхтактный двигатель:

• операционная база (где живут транзакции, заказы, документы)
• ETL-процесс (ночной ритуал, во время которого данные куда-то едут и что-то с ними происходит)
• хранилище данных, оно же DWH (где аналитики строят отчёты)
• BI-слой поверх (Power BI, Tableau, Superset)

Это были четыре разных мира с разными командами, технологиями и циклами обновления. Mohan утверждает: AI-нагрузки не готовы ждать, пока ваш ETL доедет до утра, поэтому граница между OLTP и аналитикой растворяется. Подтверждение пришло раньше доклада - в 2025 Snowflake купил PostgreSQL-вендора Crunchy Data за $250M, Databricks купил Neon за $1B.

И вот здесь хочется поспорить с keynote-ом.

Пустить AI или агентов в боевую операционную базу - это способ организовать себе инцидент. Любой DBA, который провёл хоть один разбор полётов после производственного сбоя, знает: незакрытый курсор, неоптимизированный план запроса, лишний JOIN - и боевая система ложится. AI-агенты делают это с приятной скоростью и без угрызений совести. Плюс есть прозаичная вещь - повреждение данных при некорректной записи. На транзакционной базе, которая обслуживает заказы и платежи, право на ошибку измеряется в нулях с большим количеством последствий.

Поэтому ETL и хранилище никуда не денутся. Изменится другое: классический батчевый ETL с ночной выгрузкой действительно умирает, и у него появилась нормальная замена - быстрая репликация с минимальной задержкой. По сути давно забытое старое в новой упаковке: change data capture (CDC), стриминг изменений через Kafka, прилёт в Apache Iceberg или другой lakehouse-формат с задержкой в секунды вместо часов.

И вот в Iceberg уже можно пускать AI, агентов, аналитиков, ad-hoc-запросы и всё что угодно. Это изолированный слой, в котором операционные данные доступны почти в реальном времени, при этом любой запросов-маньяк не положит вам биллинг. Архитектурно красиво: операционная база остаётся святой, аналитический слой постоянно догоняет её, AI работает с актуальной картиной без риска для production.

Что это значит для российского бизнеса: если сейчас проектируется архитектура данных или планируется замена легаси-DWH - закладываться стоит на схему CDC → Kafka → Iceberg → AI/BI, а сценарий «AI прямо в OLTP» оставить в презентациях. Старая идея отделить аналитику от транзакций жива и здорова, просто слой между ними стал в сотни раз быстрее.

---

2. Retrieval - новая дисциплина, потому что DWH меняет смысл существования

Второй тезис от AJ Meyers (Elastic). Здесь нужна короткая остановка на термине.

Retrieval (от англ. «извлечение, поиск») - это слой в AI-системах, который отвечает за то, какие данные предъявить языковой модели перед формированием ответа. Простой пример: сотрудник спрашивает корпоративного бота «можно ли вернуть товар через 45 дней». Чтобы ответить правильно, модель сначала должна найти регламент возвратов и прочитать его. Шаг «найти и прочитать» - это и есть retrieval. Архитектура называется RAG, Retrieval-Augmented Generation - «генерация с подкреплением поиском».

Но прежде чем уйти в технику, стоит остановиться на главном - зачем это вообще понадобилось как отдельная инженерная дисциплина.

Последние 30 лет DWH строилось под одну задачу: дать аналитикам и бизнесу отчёты и дашборды. Архитектура жила в логике «звезды Кимбалла»: факты, измерения, аккуратно собранные витрины, поверх - Power BI или Tableau. Бизнес-пользователь открывал отчёт, смотрел на графики и сам думал. Сводил цифры, делал выводы, формулировал гипотезы, шёл к аналитику с уточнениями. Человеческий ум был последней милей в архитектуре данных.

Сейчас парадигма меняется радикально. Бизнес-пользователь больше не хочет открывать отчёт. Он хочет напрямую спросить: «почему упали продажи в феврале», «какие клиенты в группе риска оттока», «что произошло с маржой по сегменту B в прошлом квартале» - и получить ответ. Не дашборд, не сводную таблицу, а ответ человеческим языком.

И это совсем другая история для архитектуры данных. Аналитической головы между данными и ответом больше нет. Раньше плохой отчёт корректировался опытным аналитиком, теперь между сырыми данными и финальным ответом стоит только AI и слой retrieval. Если retrieval предъявит модели не те документы, не те метрики, не ту версию справочника - пользователь получит уверенный, красиво сформулированный, и при этом неправильный ответ. Без какого-либо предупреждения.

Поэтому retrieval становится новым последним слоем архитектуры, который раньше держал на себе живой человек. И к нему теперь предъявляются те же требования, что когда-то к аналитику: знание, где что лежит, какие метрики что значат, какие данные актуальны, какие источники доверенные, кому что можно показывать.

Технически это означает целый набор инженерных задач:

• правильно нарезать документы и таблицы на куски, которые имеют смысл по отдельности
• построить и поддерживать индексы - векторные, полнотекстовые, графовые
• обеспечить lineage (отслеживание происхождения данных), чтобы можно было ответить, откуда взялось каждое утверждение в ответе AI
• контролировать доступ на уровне строк и колонок - потому что AI не должен отвечать сотруднику склада на вопросы из зарплатной ведомости
• поддерживать актуальность индексов при изменении источников
• и самое сложное - поверх этого построить семантический слой: словарь метрик, измерений, бизнес-определений, к которому AI может обращаться, чтобы понимать вопросы на естественном языке

Всё это - инженерная работа с данными. Не AI-задача и не задача data science. Это новый виток data engineering, и большая часть компаний к нему пока не готова, потому что 30 лет DWH строили под другой сценарий.

И ещё одна важная вещь, о которой редко говорят со сцены. Человеческий мозг не будет слепо доверять ответам AI. Иногда будет, иногда нет, но в важных управленческих вопросах руководитель почти всегда пойдёт проверять. И правильно сделает: цена слепого доверия к AI-ответу при принятии бизнес-решения - это глобальная управленческая ошибка с долгими последствиями. Когда CFO видит цифру в дашборде, он понимает, откуда она пришла. Когда CFO получает абзац текста от AI, у него закономерно возникает вопрос «а откуда это вообще».

Поэтому отчёты и дашборды никуда не денутся. Они становятся слоем верификации: AI даёт быстрый ответ на естественном языке, а дашборд позволяет проверить, что цифры за этим ответом совпадают с реальностью. Эти две модели взаимодействия с данными не заменяют друг друга, они дополняют. И это ещё одно подтверждение того, что качественная обработка данных перед использованием AI - это фундамент всей конструкции, не опциональное украшение. Без надёжного DWH с прозрачной семантикой и lineage никакой AI-интерфейс работать не будет, ни ответ дать корректный, ни верификацию обеспечить.

Практический вывод: компании, которые запустили GenAI-пилоты в 2024-2025, сейчас упираются именно в этот слой. Модель работает, инфраструктура поднята, а ответы получаются плохие или, что хуже, правдоподобные при этом неверные. Причина почти всегда одна - слабый retrieval поверх плохо подготовленного DWH. Сегодня это более востребованная инженерная компетенция, чем «промпт-инжиниринг», которому два года назад учили на каждом углу.

И тут важная новость для тех, кто уже инвестировал в DWH: существующее хранилище никуда не выбрасывается. Оно становится фундаментом нового слоя, и требует серьёзной достройки: семантика, метрики, governance, lineage, retrieval-инфраструктура. Это и есть работа на ближайшие два года для большинства компаний с серьёзными аналитическими нагрузками.

---

3. Bring AI to your data

Третий тезис от Paul O’Neill (EDB, главный коммерческий контрибьютор PostgreSQL). Дословно: «AI приходит к данным, а не данные экспортируются в стороннюю инфраструктуру».

До 2024 года типичный сценарий выглядел так: данные компании загружались в OpenAI или Azure OpenAI, и там обрабатывались. Удобно, но три проблемы: стоимость inference растёт с объёмом, данные покидают периметр, и есть зависимость от внешнего вендора, который завтра может передумать вас обслуживать.

Новая модель - обратная. Языковая модель разворачивается рядом с данными, в инфраструктуре компании. По данным EDB, 97% предприятий в мире планируют построить собственную data + AI платформу в ближайшие 3 года.

Для российского рынка это констатация, а не тренд. Санкционная изоляция уже выгнала большинство компаний из «AI-as-a-service», и вопрос «строить ли своё» обычно сменился на «как». И тут есть хорошая новость: технологически всё стало возможно. Open-source модели (Llama, Qwen, DeepSeek) год назад сравнялись с проприетарными по качеству. Инструменты для self-hosted inference (vLLM, Ollama) перестали быть экспериментом. Можно собрать на своём железе AI-стек, который год назад был возможен только в облаке у hyperscaler-а.

---

Общий вывод

Архитектурные выборы 2026 года определят, кто пройдёт следующую волну с минимальными переписываниями, а кто будет два года догонять. Хорошая новость - выбирать ещё не поздно. Плохая - окно сужается.

В WARP.D мы занимаемся именно этим: проектирование архитектур данных, которые работают здесь, не зависят от санкционно-чувствительных вендоров и готовы к AI-нагрузкам без полной перестройки через два года. SQL Server, PostgreSQL, Apache Kafka, Iceberg, lakehouse-стек на open-source.

Если стоит вопрос архитектуры данных, аудита текущего DWH или подготовки инфраструктуры к AI - пишите. Поговорим без хайпа, маркетингового тумана и фраз вроде «давайте обогатим вашу data fabric с помощью agentic intelligence».

🔗 warpd.ru - каталог услуг, контакты, кейсы

#DataEngineering #DWH #Lakehouse #ИнжинирингДанных #DataArchitecture