Хранилище данных — не CDP: скрытые расходы на вычисления, которые никто не заметил

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

Главная цифра: переход с ежедневного на почасовое обновление аудиторий может увеличить вычислительную нагрузку на хранилище в 25 раз, а переход к near real-time — в 50 раз и более. Эти расходы не появляются в счёте CDP. Они отражаются в счёте хранилища — другой команды, другого бюджета и, как правило, другого спора.

Цифры

Значения 25x и 50x — это то, от чего любой CTO должен насторожиться. Как описал Oracle Blogs 30 апреля 2026 года, эти множители описывают, что происходит, когда организация пытается превратить zero-copy или composable CDP в операционный слой для маркетинга в реальном времени. Ежедневно к почасово — это 25x. Почасово к near real-time — 50x и более. И что критически важно: эта вычислительная нагрузка ложится на строку хранилища, а не на счёт CDP-вендора.

Каждый, кто хоть раз объяснял CFO неожиданный счёт за Snowflake или BigQuery, знает, как проходит этот разговор. Команда маркетинга хотела более быстрые триггеры. Команда данных настроила более частые обновления. Хранилище запустило больше виртуальных складов, больше конкурентности, больше циклов autosuspend, которые так и не успевали остановиться. Через шесть месяцев финансы спрашивают, почему затраты на аналитику выросли вдвое, хотя «мы не добавляли новых дашбордов».

Статья, написанная Джейком Спенсером, старшим менеджером по исходящим продуктам Oracle Fusion Marketing, описывает последние 18 месяцев в MarTech и CX как период значительных перемен, когда стратегии AI-агентов, стремление к оптимизации затрат и старые вопросы о владении данными столкнулись одновременно. В центре этих разговоров неизменно оказываются две технологии: озеро данных или хранилище и CDP. Oracle сам, как отмечается в статье, интегрирует Oracle Unity Data Platform с Oracle Autonomous AI Lakehouse для унификации, управления и активации корпоративных данных first-party — так что вендор не утверждает, что хранилище устарело. Совсем наоборот.

Что на самом деле говорят цифры: экономика «просто запроси хранилище» нелинейна. Требования к задержке снижаются, а вычислительные затраты растут по кривой, близкой к экспоненциальной. Если вы внимательно читали документацию Snowflake по размерам хранилищ и масштабированию конкурентности, теоретически это не удивит. На практике большинство команд рассчитывает архитектуру исходя из ежедневного обновления, затем незаметно позволяет менеджерам продукта запрашивать почасовое, потом реальное время — так и не пересчитав цифры.

Что действительно ново

Дискуссия о composable CDP ведётся уже два-три года. Что genuinely отличает этот цикл — появление встроенных AI-агентов в маркетинговых и sales-процессах и профиль задержки, который они требуют. Статья прямо говорит об этом: агентам нужен доступ к предвычисленным профилям за доли секунды. Это не проблема «настройки хранилища». Это проблема «вам нужна другая система».

Суть вот в чём. Аналитические запросы и операционные поиски — это разные типы работы. Хранилище, даже быстрое, оптимизировано для сканирования множества строк ради ответа на вопрос. Слою активации нужно получить один полностью разрешённый профиль за единицы миллисекунд, пока десять тысяч других агентов делают то же самое одновременно. Это можно построить поверх хранилища. Только платить придётся дважды: один раз за вычисления, второй — за инженерные часы, потраченные на то, чтобы всё не рухнуло.

B2B-угол тоже стал острее, чем прежде. Статья указывает на очевидную, но часто игнорируемую истину: в B2B «клиент» — это группа, а не отдельный человек. Это означает иерархии аккаунтов, маппинг групп покупателей, отслеживание взаимодействия с несколькими контактами, согласование продаж и маркетинга — всему этому нужны постоянные структуры данных, а не ad hoc-джойны по сырым таблицам. Если вы когда-либо пытались смоделировать группу покупателей на чистом SQL поверх Bronze-слоя, вы знаете, что именно здесь всё рассыпается.

Ещё один genuinely новый момент — явное признание того, что методов интеграции четыре, а не один. Zero-copy или федеративный запрос. Пакетная загрузка. Потоковая передача в реальном времени. Сохранение предвычисленных профилей. Аргумент не в том, чтобы «выбрать правильный». Аргумент в том, что «вам понадобятся все четыре, применительно к конкретным сценариям использования». Пакетная загрузка подходит, когда актуальность измеряется часами. Потоковая передача в реальном времени необходима для сценариев с задержкой менее секунды. Использование одного паттерна как полной CDP-стратегии — это путь к оптимизации местоположения данных вместо бизнес-результатов.

Что уже учтено для команд данных

Большинство опытных инженеров данных уже знают, что zero-copy отлично подходит для управления и соответствия требованиям. Это уже учтено. Хранение данных внутри хранилища означает, что существующие контроли (доступ, шифрование, резидентность) применяются автоматически, и вы перестаёте спорить о том, какая система хранит каноническую запись о клиенте. Меньше дублирования, меньше затрат на хранение, возможность активировать курированные данные без их репликации — всё реально, всё полезно.

Что, по моему опыту, не учитывается — это разрыв между «мы можем запрашивать хранилище из слоя активации» и «мы должны запрашивать хранилище из слоя активации каждый раз, для каждого решения, в продакшене». Скучная часть, которую никто не хочет моделировать — это конкурентность. Один триггер на странице цен дёшев. Десять тысяч одновременных триггеров в рамках кампании в Чёрную пятницу — это совсем другой зверь, и именно там, под такой нагрузкой, поведение autoscaling хранилища убивает бюджеты.

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

Противоположная точка зрения

Теперь обратная сторона. Есть реальный аргумент в пользу того, что для значительной части организаций подход исключительно на zero-copy вполне приемлем, а предупреждение о 50x-расходах — это история из уст вендора. Если ваши сценарии активации в основном сводятся к почасовым email-рассылкам, еженедельному построению lookalike-аудиторий и ежеквартальному анализу кампаний, вам не нужны предвычисленные профили с задержкой менее секунды. Вам нужно чистое хранилище, хорошо смоделированные mart-таблицы и тонкий слой активации, который вытягивает сегменты по расписанию.

Для таких команд добавление отдельного CDP со своим хранилищем профилей — это дублирование ради красивой архитектурной диаграммы. Счёт за вычисления хранилища при почасовом обновлении на правильно масштабированном кластере с разумным кешированием на практике не будет 25x от ежедневного для любой нагрузки. 25x — это интерпретация наихудшего случая. Команда, которая умело работает с материализацией, инкрементальными моделями и кешированием результатов, может значительно сгладить эту кривую.

Честный вывод: ответ почти целиком зависит от ваших сценариев активации. Именно поэтому рекомендация из статьи — определить от пяти до десяти конкретных сценариев активации перед оценкой CDP-архитектуры — является самым полезным предложением в ней. Триггеры в реальном времени, вовлечённость групп покупателей, прогнозное скоринг лидов, оркестрация кампаний, оповещения продаж: запишите их, укажите требование к задержке и оценку объёма для каждого — и архитектура в значительной мере спроектирует себя сама.

Ключевые выводы

• Переход с ежедневного на почасовое обновление аудиторий может увеличить вычислительную нагрузку хранилища в 25 раз; near real-time — в 50 раз и более, причём счёт приходит на строку хранилища, а не в счёт CDP.
• Zero-copy-архитектуры действительно выигрывают в управлении, соответствии требованиям, снижении дублирования и активации существующих инвестиций, но не справляются с нагрузками AI-агентов с задержкой менее секунды и разрешением идентификаторов в масштабе.
• Существует четыре метода интеграции (zero-copy или федеративный запрос, пакетная загрузка, потоковая передача в реальном времени, сохранение предвычисленных профилей), и зрелые архитектуры используют все четыре применительно к конкретным сценариям.
• B2B-активация требует постоянных структур для иерархий аккаунтов, групп покупателей и отслеживания взаимодействия с несколькими контактами — а не ad hoc-запросов по сырым таблицам.
• Определите от пяти до десяти сценариев активации с явными требованиями к задержке и объёму перед выбором архитектуры; правильный паттерн следует из требований, а не наоборот.

Возвращаясь к резервуару. Никто в здравом уме не будет спорить, что резервуар не нужен. Спор идёт о том, нужна ли вам ещё и напорная магистраль, — и ответ для большинства корпоративных стратегий работы с данными о клиентах в 2026 году: да, нужна. Хранилище и CDP не конкурируют за одну и ту же задачу. Это две части одной водной системы, и инженерное решение состоит в том, какой трубопровод несёт какую нагрузку. Ошибитесь — и счёт придёт туда, куда никто не смотрел.