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 в ближайший год - пройдитесь по нему до подписания сметы.
- Аналитика ходит в боевую учётную систему напрямую? Это бомба замедленного действия, закладывайте изолированный слой.
- Данные едут в хранилище раз в сутки ночью? Работает, но вы проектируете вчерашний день. Слой быстрой репликации - новый стандарт.
- Планируете AI-проект? Сначала аудит качества данных, потом модель. В обратном порядке получите дорогую игрушку с красивыми неправильными ответами.
- AI-решение строится на внешнем облачном API? Посчитайте стоимость на горизонте двух лет и риск отключения. Локальная альтернатива созрела.
- Вам продают «убийцу дашбордов»? Дашборды остаются - как инструмент проверки AI-ответов. Проектируйте оба контура.
Архитектурные решения этого года определят, кто пройдёт следующую волну спокойно, а кто будет два года переделывать. Окно для выбора ещё открыто.