Snowflake потратил $250 млн, Databricks - миллиард. Что они поняли про данные и почему это касается вашего бизнеса

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

В 2025 году произошли две сделки, на которые мало кто обратил внимание за пределами отрасли. Snowflake купил PostgreSQL-вендора Crunchy Data за $250 млн. Databricks купил Neon за миллиард. Обе компании - гиганты аналитических платформ, обе купили разработчиков обычных транзакционных баз данных.

Зачем аналитическим платформам операционные СУБД? Ответ прозвучал на Data Summit 2026 в Бостоне, и он напрямую касается любого бизнеса, который платит за аналитику или собирается платить.

Я 30 лет работаю с корпоративными данными - банки, инвестиционные компании, федеральный ритейл. Разберу три сдвига с конференции через призму денег и рисков, без маркетингового тумана.

Сдвиг первый. Граница между «учётной системой» и «аналитикой» исчезает

Двадцать лет корпоративная аналитика строилась по одной схеме. Есть учётная система, где живут заказы и платежи. Ночью специальный процесс выгружает из неё данные в отдельное хранилище. Утром руководители смотрят отчёты по вчерашнему дню.

Эта схема устраивала всех, пока бизнес был готов ждать до утра. Сейчас не готов. Руководитель хочет видеть картину на сейчас, AI-инструменты хотят работать с живыми данными, и вся индустрия перестраивается под это ожидание. Те самые покупки за $250 млн и миллиард - ставка на то, что операционные данные и аналитика сольются в одну платформу.

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

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

Час простоя учётной системы для среднего ритейлера - сотни тысяч рублей прямых потерь. Для дистрибьютора в сезон - миллионы.

Правильная конструкция выглядит иначе. Между учётной системой и аналитикой ставится изолированный слой, куда изменения прилетают почти мгновенно - задержка в секунды вместо ночной выгрузки. Технологии для этого созрели и доступны в open-source: репликация изменений через Kafka в аналитическое хранилище современного формата. В этот слой можно пускать кого угодно - аналитиков, AI, тяжёлые отчёты. Учётная система при этом остаётся нетронутой.

Вывод для руководителя. Если вам предлагают проект «AI прямо на вашей рабочей базе» - это дешевле на старте и дороже при первой же аварии. Если предлагают классическое хранилище с ночной выгрузкой - вы платите за архитектуру прошлого десятилетия. Спрашивайте про слой быстрой репликации. Его наличие в проекте - маркер того, что подрядчик проектирует на 2026 год, а не на 2015.

Сдвиг второй. Сотрудники начинают спрашивать AI вместо чтения отчётов

Тридцать лет корпоративная аналитика заканчивалась дашбордом. Дальше работала голова человека: руководитель смотрел на графики, сводил цифры, делал выводы.

Сейчас привычка меняется. Сотрудник хочет спросить «почему упали продажи в феврале» и получить ответ обычным языком. Не открывать пять отчётов, а задать вопрос. Это удобно, это уже работает технически, и это несёт риск, о котором почти не говорят.

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

Цена вопроса - качество управленческих решений. Решение о закрытии направления, о смене поставщика, о премировании - принятое на основе красиво изложенной ошибки.

Отсюда два практических следствия.

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

Второе - качество данных перестало быть внутренней темой IT-отдела. Пока аналитику потребляли через отчёты, ошибки в данных были неприятностью. Когда аналитику потребляют через вопросы к AI, ошибки в данных становятся ошибками в решениях. Компании, запустившие AI-пилоты в 2024-2025, упираются сейчас именно сюда: модель работает, ответы плохие. Причина почти всегда не в модели, а в бардаке в данных под ней.

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

Сдвиг третий. AI переезжает к данным, а не данные к AI

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

На конференции прозвучала цифра: 97% предприятий в мире планируют строить собственную платформу данных и AI в ближайшие три года. Не арендовать - строить у себя.

Для российского рынка это даже не тренд, а свершившийся факт. Санкции закрыли доступ к большинству облачных AI-сервисов, и вопрос «строить ли своё» давно превратился в «как строить». Хорошая новость в том, что технологически всё созрело. Открытые языковые модели догнали проприетарные по качеству. Инструменты для запуска AI на собственном железе перестали быть экспериментом. Стек, который два года назад был доступен только в облаке у мировых гигантов, сегодня собирается на своих серверах из open-source компонентов.

Вывод для руководителя. Если подрядчик строит вам AI-решение на зарубежном облачном API - вы получаете зависимость, которая может закончиться в любой момент, плюс счёт, растущий с каждым запросом. Локальный стек дороже на старте и дешевле на горизонте двух лет, при этом данные не покидают компанию.

Что со всем этим делать

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

  1. Аналитика ходит в боевую учётную систему напрямую? Это бомба замедленного действия, закладывайте изолированный слой.
  2. Данные едут в хранилище раз в сутки ночью? Работает, но вы проектируете вчерашний день. Слой быстрой репликации - новый стандарт.
  3. Планируете AI-проект? Сначала аудит качества данных, потом модель. В обратном порядке получите дорогую игрушку с красивыми неправильными ответами.
  4. AI-решение строится на внешнем облачном API? Посчитайте стоимость на горизонте двух лет и риск отключения. Локальная альтернатива созрела.
  5. Вам продают «убийцу дашбордов»? Дашборды остаются - как инструмент проверки AI-ответов. Проектируйте оба контура.

Архитектурные решения этого года определят, кто пройдёт следующую волну спокойно, а кто будет два года переделывать. Окно для выбора ещё открыто.