Ось данных и интеллекта (ось 4) — события, хранилище, пайплайны, машинное обучение, эксперименты
Версия: 1.0 Дата: 25.04.2026 Статус: Готов к обсуждению
Назначение документа
Этот документ — раскрытие четвёртой оси верхнеуровневой архитектуры: ось данных и интеллекта (data and intelligence spine). Он отвечает на вопросы: как платформа захватывает события, как они движутся через пайплайны, где хранятся для аналитики, как используются для обучения моделей машинного обучения, как ставятся эксперименты, и как этот слой связан с другими осями архитектуры.
Главное решение, зафиксированное 25.04.2026: все компоненты этой оси — first-class с нулевого дня архитектуры. Никаких «добавим аналитику потом», «ML на фазе 3», «A/B testing когда понадобится». Архитектурно всё закладывается сейчас; реализация по фазам.
Документ читается после главной архитектурной оси (overview/index.md) и манифеста переосмысления (overview/platform-vision-and-manifest.md).
Главный тезис
Если data infrastructure не закладывается с нуля, попытка добавить машинное обучение через 12 месяцев потребует переписывания event sourcing, retention policies, schema governance, privacy boundaries.
Из этого следует:
- события — первоисточник данных платформы, не побочный продукт;
- хранилище данных (data warehouse) — отдельный класс хранилища от operational и transactional;
- пайплайны (ETL/streaming) — first-class инфраструктура, не batch jobs «на ночь»;
- ML-платформа — стандартизированная инфраструктура с feature store, model registry, model serving, model monitoring;
- A/B testing — framework, не ad-hoc эксперименты в коде.
Пять компонентов оси
Компонент 1. Захват событий (events tracking)
Главный принцип: разделение domain events и analytical events
Платформа имеет два класса событий, которые никогда не смешиваются:
Domain events — события, отражающие изменения каноничной доменной модели:
BookingConfirmed,QuoteCreated,OfferPublished,PropertyUpdated,MappingDecisionApplied,SettlementEventPosted,ReviewCaseCreated.- Источник: каноничные сущности (см. overview/canonical-domain-spine.md).
- Транспорт: event bus (Kafka в Public Cloud).
- Потребители: другие сервисы платформы (S2S consumers); webhook delivery партнёрам; analytical pipelines.
- Замена: работают как источник истины для downstream-логики; используются для replay при изменении логики обработки.
Analytical events — события для аналитики, продуктовых метрик, ML-features:
SearchPerformed,SearchResultClicked,OfferViewed,BookingFunnelStep,UserSignedUp,SessionStarted,PageLoaded.- Источник: пользовательские взаимодействия на поверхностях (Agency, Partner, B2C); внутренние операционные действия.
- Транспорт: отдельный pipeline (event collector → message queue → DWH).
- Потребители: data warehouse, ML feature engineering, A/B testing framework, partner-facing analytics product.
- Замена: работают как наблюдательный материал, не источник истины.
Принципы захвата событий:
- Schema-aware — каждое событие имеет явную схему (JSON Schema, Avro, или эквивалент).
- Versioned — схемы событий версионируются с явной политикой совместимости.
- Governed — изменения схем проходят review и не ломают consumers.
- Privacy-bounded — PII (personally identifiable information) минимизируется в событиях; для требуемых случаев — анонимизация на уровне захвата.
- Tenant-isolated — события несут tenant context; cross-tenant aggregation возможна только через explicit aggregation rules.
Связь с уже существующей моделью событий
В документах второго круга уже зафиксирована первичная таксономия событий:
- reference/initial-event-taxonomy.md;
- reference/eventing-and-queue-baseline.md;
- development/asyncapi-skeletons-and-event-envelopes.md;
- и другие документы фазы 3.
Эти документы покрывают domain events. Раздел analytical events требует дополнительного документа в фазе 4: reference/data-platform-and-events-tracking.md.
Компонент 2. Хранилище данных (data warehouse, DWH)
Главный принцип: отдельный storage class
Хранилище данных — отдельный класс хранилища от operational layer и transactional layer. Разные SLA, разная retention policy, разная privacy boundary, разные queries.
Что хранится в DWH:
- Все analytical events в append-only форме (event log).
- Materialized views — агрегированные представления для типичных queries (daily booking volume, conversion funnel, supplier breakdown, partner usage).
- Snapshots каноничных сущностей — периодические snapshots для historical queries («какие туры были опубликованы 6 месяцев назад»).
- ML feature store — features, derived from events и canonical entities, для использования в model training и serving.
- Experiment data — данные A/B экспериментов: cohort assignment, exposure events, conversion metrics.
Что НЕ хранится в DWH:
- Raw transactional truth (booking events) — это transactional layer, отдельный класс.
- Raw supplier payloads — это supplier trace layer, отдельный класс.
- Operational caches и проекции — rebuildable cache layer.
- Sensitive PII в неанонимизированной форме (только если есть compliance basis).
Технологический baseline:
- Managed ClickHouse у OVHcloud для большинства analytical queries (фаза 3+).
- В фазе 1-2 базовая аналитика возможна через PostgreSQL read replica + materialized views.
Retention policy:
- raw events — retention зависит от категории (некоторые удаляются через 90 дней, другие хранятся долго для compliance);
- materialized views — короче retention (rebuildable);
- ML feature store — retention зависит от модели (training data может требовать долгого retention);
- experiment data — retention равна продолжительности эксперимента + post-analysis window.
Privacy by design
DWH проектируется с принципом privacy by design:
- PII в analytical events анонимизируется на захвате (хешированные user IDs, обобщённая геолокация);
- cross-tenant queries возможны только через явные aggregation rules с минимальным размером группы (k-anonymity);
- PII доступна в DWH только через явные роли с audit trail каждого доступа;
- автоматическое удаление данных по истечении retention period.
Компонент 3. Пайплайны (ETL/streaming)
Двухпутевой подход
Платформа использует гибридный подход: реальное время + пакетная обработка.
Реальное время (streaming pipeline):
- источник: event bus (Kafka);
- обработка: stream processor (Kafka Streams, Apache Flink, или эквивалент);
- назначение: real-time aggregations, real-time ML inference, alerting, real-time dashboards.
Пакетная обработка (batch pipeline):
- источник: change data capture (CDC) из transactional layer + event log из DWH;
- обработка: batch jobs (Apache Spark, Apache Beam, или эквивалент); запускается периодически (часовая, дневная регулярность).
- назначение: heavy aggregations, ML feature engineering, training data preparation, BI reports.
Replay capability как first-class
Платформа обязана уметь повторно воспроизводить события для:
- изменения логики обработки (например, новая нормализация с учётом новых полей);
- восстановления после инцидентов;
- перерасчёта ML features при изменении схемы;
- backfill при подключении новых пайплайнов.
Это означает:
- event log в DWH хранится как append-only, никогда не модифицируется;
- consumer offsets отслеживаются явно;
- replay возможен с любой точки без боли;
- replay-sensitive consumers идемпотентны.
Компонент 4. Платформа машинного обучения (ML platform)
Стандартизированная инфраструктура ML
Платформа использует современный паттерн ML platform с четырьмя главными компонентами:
Компонент 4.1. Feature store
- хранит features (входы для ML-моделей) с consistency между training и serving;
- поддерживает offline features (для training) и online features (для inference);
- features могут быть streaming (computed in real-time) и batch (computed periodically);
- feature versioning — изменение feature не ломает существующие модели.
Технологический baseline: Tecton, Feast или эквивалент в фазе 3+.
Компонент 4.2. Model registry
- хранит trained models с версионированием;
- метаданные модели: training data, hyperparameters, метрики, дата обучения, ответственный data scientist;
- модели проходят approval process перед production deployment;
- rollback к предыдущей версии модели — операционная procedure.
Технологический baseline: MLflow или эквивалент.
Компонент 4.3. Model serving
- inference infrastructure для моделей в production;
- online inference для real-time use cases (search ranking, dynamic pricing, recommendation);
- batch inference для периодических use cases (anomaly detection, partner risk scoring);
- A/B exposure — серверная инфраструктура для одновременного запуска нескольких версий модели.
Технологический baseline: TorchServe, Triton, BentoML или эквивалент в фазе 3+; в фазе 2 — простой API на Go/Python с моделями в памяти.
Компонент 4.4. Model monitoring
- мониторинг production моделей: prediction drift, feature drift, performance metrics, business metrics impact;
- alerting на деградацию модели;
- automatic retraining triggers.
Use cases ML на платформе
Этот раздел перечисляет, где машинное обучение применяется в платформе. Не все use cases реализуются сразу; многие — фаза 3+.
| Use case | Описание | Фаза реализации |
|---|---|---|
| Search ranking | Ранжирование результатов поиска под user intent, conversion потенциал, supplier health | Фаза 2-3 |
| Recommendation | Персонализированные рекомендации в результатах поиска, на product pages | Фаза 3 |
| Dynamic pricing | Динамическое ценообразование услуг платформы (см. overview/platform-as-product.md) на основе реальной нагрузки и elasticity | Фаза 3 |
| Anomaly detection in ingestion | Обнаружение аномалий в supplier data (резкий drop цен, странные характеристики property) | Фаза 2 |
| Partner risk scoring | Оценка риска партнёра по поведению (для clearing limits, fraud prevention) | Фаза 3 |
| Conversion optimization | Оптимизация UX через ML-driven personalization | Фаза 3 |
| Fraud detection | Обнаружение мошеннических бронирований | Фаза 3 |
| Content moderation | Модерация property photos, descriptions для inappropriate content | Фаза 2-3 |
| Demand forecasting | Прогнозирование спроса для capacity planning, marketing | Фаза 4 |
| Tour Builder compatibility scoring | Оценка совместимости компонентов в Tour Builder | Фаза 3 |
| Supplier health prediction | Предсказание операционных проблем поставщиков | Фаза 3-4 |
Компонент 5. A/B тестирование (experimentation framework)
Главный принцип: эксперимент как product capability
A/B testing — не ad-hoc эксперименты в коде, а стандартизированный framework.
Что включает framework:
- Feature flags — управление включением/выключением features per cohort. Технологический baseline: LaunchDarkly, Unleash, или собственная реализация.
- Cohort assignment — детерминированное распределение пользователей по cohorts. Hash-based assignment с явной cohort definition.
- Exposure tracking — захват events «cohort X exposed to variant Y». Не считается «exposed» пока пользователь не увидел вариант.
- Metrics framework — метрики экспериментов: primary metrics (главная цель), secondary metrics (вторичные), guardrail metrics (то, что не должно ухудшиться).
- Statistical significance — расчёт значимости результатов; sample size estimation; sequential testing.
- Experiment lifecycle — фазы эксперимента: design → ramp-up → full exposure → analysis → decision (ship/kill/iterate).
Использование A/B testing на платформе:
- B2C UX experiments — оптимизация conversion на vitrip.store.
- Search ranking experiments — сравнение моделей ranking.
- Pricing experiments — тестирование ценовых вариантов для собственных продуктов и API tiers.
- Recommendation experiments — сравнение моделей recommendation.
- Tour Builder UX experiments — оптимизация workflow композиции.
- Webhook delivery strategy experiments — оптимизация retry policy.
Multi-tenant aspect:
- эксперименты могут быть tenant-scoped (только для определённых tenant) или platform-wide (для всех);
- tenant-scoped эксперименты не должны влиять на других tenant;
- ethics и compliance: эксперименты на B2C-витринах требуют GDPR-compliance (consent на использование cookies для cohort assignment).
Архитектура data flow
Domain events (event bus, Kafka)
↓ (real-time replication)
Data warehouse (event log, append-only)
↑
Analytical events (event collector → DWH)
Canonical entities (transactional layer)
↓ (CDC, change data capture)
Data warehouse (entity snapshots, periodic)
Data warehouse
↓ (ETL/streaming pipelines)
Materialized views, ML feature store
ML feature store
↓ (training pipeline)
Model registry (trained models)
↓ (deployment)
Model serving (online + batch inference)
↓ (predictions)
Domain layer (search ranking, recommendation, dynamic pricing)
+ Tracking events (A/B exposure)
A/B testing framework
↓ (cohort assignment + feature flags)
Surfaces (Agency, Partner, B2C, Tour Builder)
+ Tracking events (exposure capture)
DWH
↓ (BI queries)
Internal analytics (operational dashboards)
+ Partner-facing analytics product (Professional+ tiers)
Privacy boundaries
Главный принцип: privacy by design
Платформа разрабатывается с privacy by design:
- минимизация PII в событиях (только то, что необходимо);
- анонимизация на уровне захвата;
- retention с автоматическим удалением;
- audit trail каждого доступа к PII;
- explicit consent management для B2C-cookies и tracking.
Категории данных по privacy
| Категория | Что включает | Privacy treatment |
|---|---|---|
| Public data | Property содержимое, classifications, geo | Без ограничений |
| Operational data | Search/quote/booking volume, latency metrics | Aggregated публично; raw — internal only |
| Tenant-scoped data | Конкретные booking конкретного партнёра | Видны только tenant; cross-tenant — только aggregated |
| End-customer PII | Имена, паспорта, контактные данные клиентов | Максимально ограниченный доступ; анонимизация в analytical events; retention минимально необходимый |
| Partner sensitive | Margin, commercial terms, partner balance | Internal only + sole partner |
Compliance с GDPR
GDPR-compliance влияет на data ось напрямую:
- Right to access (DSR — Data Subject Request) — клиент может запросить все свои данные. DWH должен поддерживать запросы по subject.
- Right to erasure — клиент может потребовать удаления. DWH должен поддерживать deletion requests со всеми соответствующими analytical events.
- Right to portability — экспорт данных в стандартном формате.
- Purpose limitation — данные используются только для тех целей, для которых были собраны.
- Data minimization — собираем только то, что необходимо.
- Cross-border transfer — для UA↔EU, KZ↔EU необходимы Standard Contractual Clauses.
Полное раскрытие — в reference/compliance-and-legal.md фазы 4.
Связь с другими осями архитектуры
Связь с осью 1 (каноничная доменная)
- Все каноничные сущности генерируют domain events.
- FieldLineage в каноничной модели — основа для data quality monitoring.
- Tracking events наблюдают за поведением вокруг каноничных сущностей.
- ML использует features, derived from canonical entities + events.
Связь с осью 2 (поверхности взаимодействия)
- Каждая поверхность — источник tracking events.
- Самый интенсивный источник — B2C Storefront (high-volume, conversion-critical).
- Partner API tracking events используются для динамической тарификации.
- S2S events — это и domain events, и operational tracking.
Связь с осью 3 (платформа как продукт)
- Usage metering — базовый источник для динамической тарификации (через analytical events).
- Partner-facing analytics product — часть Professional/Enterprise tiers.
- ML — основа для динамического ценообразования и premium ML capabilities как add-ons.
- A/B testing — capability для оптимизации продукта.
Связь с осью 5 (операционная)
- Observability metrics — пересечение с data осью (operational metrics в analytical pipelines).
- Anomaly detection в ingestion — operational use case ML.
- Predictive scaling в operational ось — основан на ML моделях из data оси.
Связь с осью 6 (реализация)
Текущий home-to-go-api:
- Имеет
events_themesschema (DDL выполнен 2026-04-24) — это первая итерация event capture, требует разделения на domain events vs analytical events. - Не имеет полноценного DWH — managed PostgreSQL apivitianadb не предназначен для analytical queries в production-объёме.
- Не имеет ML platform.
- Не имеет A/B testing framework.
Полная карта соответствия — в overview/relation-to-implementation-baseline.md.
Развёртывание оси по фазам
Фаза 1 (Bootstrap, 0-12 мес)
Что развёртывается:
- базовый event capture для domain events (через event bus);
- prototype analytical event collector (можно через PostgreSQL для начала);
- базовая Grafana для operational metrics (managed Grafana бесплатно у OVHcloud);
- скрипты для on-demand аналитики (без полной DWH);
- feature flag system для базовых experiments (можно через config файлы или простую таблицу).
Что НЕ развёртывается:
- managed Kafka (фаза 2);
- managed ClickHouse (фаза 3);
- ML platform (фаза 3);
- полноценный A/B testing framework.
Фаза 2 (Service isolation, 12-24 мес)
Что развёртывается:
- managed Kafka — главный event bus;
- разделение domain events и analytical events;
- managed OpenSearch для search projection;
- базовая DWH в PostgreSQL read replica (или отдельный instance);
- первые ML use cases (anomaly detection в ingestion, search ranking прототип);
- A/B testing framework — базовая реализация.
Фаза 3 (Workload-specific, 24-36 мес)
Что развёртывается:
- managed ClickHouse — production DWH;
- AI Training, AI Deploy, AI Endpoints — production ML platform;
- feature store (Tecton/Feast или собственная реализация);
- model registry (MLflow);
- model serving infrastructure;
- зрелый A/B testing framework;
- partner-facing analytics product (Professional+ tier);
- streaming pipeline на основе Kafka Streams или Flink.
Фаза 4 (Multi-region, 36+ мес)
Что развёртывается:
- multi-region replication DWH;
- multi-region ML model serving;
- federated analytics (cross-region queries);
- advanced ML capabilities как marketplace add-ons;
- compliance-grade audit infrastructure для PII access.
Углубление в документах нижних слоёв
Эта ось верхнего уровня раскрывается детально в документах фазы 4:
| Тема | Документ |
|---|---|
| Data Platform & Events Tracking — полная архитектура | reference/data-platform-and-events-tracking.md |
| ML Platform — feature store, model registry, serving, monitoring | reference/ml-platform.md |
| A/B Testing Platform — framework, metrics, lifecycle | reference/ab-testing-platform.md |
| Analytics & BI — внутренняя аналитика и tenant-facing product | reference/analytics-and-bi.md |
| Notification & Communication — webhooks к партнёрам | reference/notification-and-communication.md |
Уже существующие документы второго круга, релевантные оси:
- reference/initial-event-taxonomy.md;
- reference/eventing-and-queue-baseline.md;
- reference/storage.md;
- reference/api-metering-and-usage-governance.md;
- development/asyncapi-skeletons-and-event-envelopes.md;
- development/initial-event-taxonomy.md;
- и другие документы фазы 3.
Открытые развилки
Развилка 1. Технологический выбор DWH
Managed ClickHouse у OVHcloud — текущая рекомендация. Альтернативы: Snowflake (multi-cloud), BigQuery (GCP), Redshift (AWS). Для OVHcloud-первичной экосистемы ClickHouse оптимален. Эскалируется в фазе 3 при детальной разработке reference/data-platform-and-events-tracking.md.
Развилка 2. Build vs Buy для ML platform
Tecton (commercial) vs Feast (open-source self-hosted) для feature store. MLflow (open-source) для model registry — стандарт. Эскалируется в фазе 3.
Развилка 3. A/B testing framework — собственный или внешний
LaunchDarkly (commercial), Unleash (open-source), собственная реализация. Эскалируется в фазе 2.
Развилка 4. Privacy-preserving ML
Для расширенных ML capabilities (кросс-tenant features, federated learning) — нужны privacy-preserving подходы (differential privacy, homomorphic encryption). Эскалируется в фазе 4.
Связанная документация
- Главная архитектурная ось (overview/index.md)
- Манифест переосмысления (overview/platform-vision-and-manifest.md)
- Архитектурный якорь (overview/architectural-anchor-and-business-model.md)
- Поверхности взаимодействия (overview/layers.md)
- Каноничная доменная ось (overview/canonical-domain-spine.md)
- Платформа как продукт (overview/platform-as-product.md)
- Операционная ось (overview/operational-spine.md)
- Связь с реализацией (overview/relation-to-implementation-baseline.md)
- Граф пересечений архитектурных осей (overview/architectural-axes-and-cross-links.md)
- Дорожная карта инфраструктурного масштабирования (operations/scaling-and-packaging-roadmap.md)
- Initial Event Taxonomy (reference/initial-event-taxonomy.md)
- Eventing And Queue Baseline (reference/eventing-and-queue-baseline.md)
- Storage (reference/storage.md)
- API Metering And Usage Governance (reference/api-metering-and-usage-governance.md)
- Observability Tooling Baseline (operations/observability-tooling-baseline.md)