Рабочая архитектура данных для маркетинга и ИИ за 30 дней

Частая ошибка в проектах по данным — пытаться строить «на века». Пока настраивали идеальную систему, менялись продукты и процессы. В результате копятся задержки, появляются дубли и ИИ не опирается на актуальные факты. Я предлагаю другой путь: небольшой и дисциплинированный слой данных, который связывает источники, вводит единый client_id, событийную модель и понятные правила качества. Такой слой поднимается за 30 дней и не требует дорогого корпоративного хранилища.

Сразу уточню: я не веду вас в «модный стек» ради галочки. Классическое корпоративное хранилище данных (ДВХ — база для отчётности из структурированных таблиц) по-прежнему отлично решает свои задачи. Но менять его сложно и дорого масштабировать под все новые кейсы. Минимальная архитектура помогает разгрузить ДВХ и дать маркетингу и ИИ быстрый и недорогой доступ к данным.

Что я собираю вместо «большого DWH»

Опираюсь на подход lakehouse — по сути, это файловое «озеро» с правилами, как у таблиц. Хранение недорогое и растёт вместе с объёмами, а дисциплина остаётся строгой. Главный принцип — разделяем хранение и вычисления. Данные складываются в совместимое с S3 хранилище (S3 — стандартный способ хранить файлы и работать с ними через простой интерфейс), а считать их можно разными движками по запросу. Вы платите за вычисления только тогда, когда они действительно нужны, и не плодите копии под каждую задачу.

Чтобы «озеро» не превратилось в болото, добавляю формат Apache Iceberg (формат таблиц — по сути, «оглавление» с версиями и гарантиями целостности) и каталог метаданных (каталог — «библиотекарь», который знает, где какая таблица и какая у неё схема). Так получается понятный слой данных для аналитики и ИИ, без обязательной миграции в тяжёлое ДВХ.

Не гоните компанию за трендами: под каждую задачу выбираем подходящее решение.

Если у вас уже есть ДВХ и на нём крутится оперативная отчётность, так и оставим. Горячие витрины живут там, где им и должно быть. Холодные и растущие исторические данные уезжают в S3+Iceberg. Это снижает расходы на масштабирование ДВХ и убирает дубли.

Минимальный стек и почему он выгоден

Что входит в «минимум», который даёт результат и не привязывает вас к одному поставщику? Берём только то, что поддерживает бизнес-цели и укладывается в ваши требования к рискам. Список короткий, без экзотики и с понятной экономикой.

• Хранение: S3-совместимое облачное хранилище. В среднем хранение 1 ГБ в S3 оценивают около 2 руб. в месяц, это выгодно для маркетинговых событий, логов и контента. Если облако недопустимо — смотрим на Apache Ozone (S3-совместимое программное хранилище для развёртывания у себя).
• Дисциплина данных: Apache Iceberg как формат таблиц плюс каталог метаданных (например, Hive Metastore или аналоги). Есть версионность, схемы и согласованность, значит, «болота» не будет.
• Вычисления по запросу: SQL-движки уровня Spark или Trino (инструменты, которые читают файлы из S3 и выполняют запросы). Их включаем под задачу и останавливаем, когда простаивают.

Почему это экономично? Совокупная стоимость владения (TCO) состоит из четырёх частей: инфраструктура (хранение и вычисления), лицензии, команда (поддержка и развитие) и цена инцидентов (сколько стоит простой). Разделение хранения и вычислений даёт гибкость: вырос объём — добавили только хранилище, пошла нагрузка — подняли вычисления на период кампании и вернули обратно. Решения от поставщиков экономят время настройки, открытые решения (open source) дают страховку от закрытой экосистемы. Баланс подбираем под вашу политику рисков.

30 дней: что именно делаем

За месяц реально пройти четыре коротких цикла и получить рабочий результат. Идём короткими итерациями. Сразу вводим правила и выпускаем первый кейс.

• Неделя 1 — Цели и инвентаризация. Формулируем бизнес-цель: сквозная воронка и LTV (пожизненная ценность клиента), удержание и RFM (recency, frequency, monetary — давность, частота, сумма покупок), контент-аналитика или быстрый запуск кейсов с ИИ. Собираем список источников: CRM (система управления взаимоотношениями с клиентами — база сделок, клиентов и коммуникаций), сайт, приложения, рекламные кабинеты, офлайн-продажи, справочники. Решаем, что остаётся в текущем ДВХ как «горячее», а что уходит в S3 как «холодное».
• Неделя 2 — Единый client_id и событийная модель. Вводим единый идентификатор клиента (client_id — способ однозначно связать события одного человека из разных каналов). Описываем событийную модель: session_start, view, add_to_cart, purchase, refund, ticket_created и т. п., а также минимальные обязательные поля и схемы. Всё кладём в Iceberg-таблицы, чтобы версии и схемы контролировались автоматически.
• Неделя 3 — Правила качества данных. Настраиваем базовые проверки: дубликаты, пропуски обязательных полей, допустимые диапазоны, свежесть загрузок. Поднимаем каталог метаданных с описаниями таблиц и полей, чтобы аналитики находили нужное за минуты, а не за часы.
• Неделя 4 — Первый результат. Подключаем вычислительный движок по расписанию для обновления витрин. Выпускаем: а) недорогие отчёты из S3 для маркетинга (воронка, ROMI — окупаемость маркетинговых инвестиций — по каналам), б) пилот ИИ-кейса. Например, RAG (подход, при котором модель отвечает на основе ваших документов, а не только своей «памяти») для базы знаний поддержки или ассистента по продукту. Данные и доступы — из того же слоя S3+Iceberg.

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

Риски и как их закрыть в РФ

Где в российских условиях особенно осторожничаю и что делаю, чтобы не порвалось. Облако против собственной инфраструктуры (on-premises): облако даёт гибкие расходы и готовые сервисы резервирования и защиты. Собственная инфраструктура нужна, если регуляторика или политика безопасности запрещают выносить данные. В таком сценарии выбирайте компоненты с открытыми лицензиями уровня Apache — это снижает риск односторонних изменений условий со стороны правообладателя.

Открытые решения и поставщики: открытые решения — это свобода и страховка, поставщики — скорость и поддержка SLA (соглашение об уровне сервиса — формальные сроки реакции и восстановления). Я комбинирую: критичную «дисциплину» (Iceberg и каталог) беру из открытых проектов, а вокруг допускаю сервисы от поставщиков там, где важны время и ответственность за инциденты. Так вы не попадаете в зависимость от одного поставщика и не теряете темп.

ДВХ остаётся в работе. У вас может быть быстрый ДВХ под горячие витрины и платёжные отчёты, а S3+Iceberg станет площадкой для историй, логов и ИИ-кейсов. Такой дуэт чаще всего и даёт ожидаемую экономику: меньше дублирования, масштабирование по потребности и прозрачный TCO.

Если коротко: минимальная архитектура — это про дисциплину данных и простые компоненты, которые окупаются. За 30 дней вы получаете связанный слой событий с единым client_id, понятные правила качества и первый рабочий кейс ИИ или сквозной аналитики. Дальше вы масштабируете по спросу — без «болота» и без перегрева бюджета.

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