Синхронизация аналитических данных

1) Зачем экосистеме синхронизация аналитики

Сеть объединяет операторов, студии/RGS, аффилиаты, PSP/APM, KYC/AML-провайдеров и медиа. Чтобы видеть единую картину (воронки CR→FTD→ARPU/LTV, RG/комплаенс, SLO транспорта, финансы/RevShare), экосистеме нужна каноническая, своевременная и доказуемая синхронизация данных между цепями и витринами — без «двух истин», с явной историей изменений и контролем стоимости.

2) Онтология и контракты данных

Сущности: `eventId`, `traceId`, `participantId`, `role` (operator/studio/affiliate/psp/kyc/stream), `jurisdiction`, `brandId`, `campaignId`, `apmRouteId`, `gameId`, `tableId`, `currency`, `schemaVersion`, `formulaVersion`.

• `click`, `session_start`, `registration`, `kyc_status`, `deposit`, `ftd`, `bet/spin`, `reward_granted`, `withdrawal`, `postback_sent/received`, `rg_guardrail_hit`, `stream_sli`.

• схемы в Schema Registry (semver, совместимость полей);
• владельцы, окна агрегации, SLA свежести и полноты;
• политика ошибок (nullable/заглушки), справочники (валюты, локали, RTP-профили).

Metric Store: версии формул (GGR/NetRev/CR/ARPU/LTV, K-факторы), их владельцы и дата вступления — формула всегда пинится в отчете.

3) Временные семантики и окна

Event Time vs Processing Time: агрегации должны опираться на время события, а не обработки.
Watermarks: для контроля «поздних» событий; политика доприема (например, T+24h).
Окна: скользящие/календарные, с пересчетом при догрузках.
Задержка как метрика: публикуется `ingest_lag` и `publish_lag` для каждой витрины.

4) Транспорт и режимы синхронизации

1. CDC/стриминг (реал-тайм):

шина событий (EDA), партиционирование по `traceId/participantId`;

«ровно один раз по смыслу» через идемпотентность потребителей и хэши тел;

курируемые топики: сырые события, нормализованные, агрегаты/оракулы.

2. Батч/микробатч:

инкрементальные выгрузки с курсорной пагинацией (временные/лог-курсоры);

форматы: Parquet/Avro с схемой; манифесты партий.

3. API/вебхуки:

`/vN/events` с курсорами и `Idempotency-Key`;

вебхуки подписаны (JWS/HMAC), реестр переигровки, backoff+джиттер.

4. Asset-синк:

справочники/локали/каталоги игр как версионированные бандлы (хэши, TTL).

5) Идемпотентность, дедуп и поздние события

Idempotency-Key и хэш тела на критичных путях (платежи/постбеки).
Дедупликация: окно ±5 минут/по watermark; хранение «виденных» хэшей.
Поздние события: политика upsert/обратного пересчета; changelog витрин.
Exactly-once по бизнес-смыслу: не требуем «магии брокера», требуем идемпотентности потребителей и детерминированности схем.

6) Согласование атрибуции и формул

Атрибуция: правило last eligible touch с окнами по каналам/юрисдикциям, кросс-девайс — только через токены (без сырого ПДн).
Формулы метрик: каждая запись ссылается на `formulaVersion`; MAJOR-изменения публикуются как события `data_formula_change`.
Backfill по правилам: при смене формулы допускается двойная публикация (old/new) в переходный период (frozen-period).

7) Data Quality: SLI/SLO и тесты конформанса

• Свежесть (publish_lag p95),
• Полнота (доля событий vs эталон),
• Уникальность (доля дубликатов),
• Согласованность (валюта/локаль/ID),
• Точность (контрольные суммы/оракулы),
• Линейность времени (поздние события в коридоре).

• publish_lag п95 ≤ 1–5 с (операционные панели), ≤ 15 мин (фин. агрегаты);
• полнота ≥ 99.5% в T+15 мин, ≥ 99.9% в T+24h;
• дубликаты ≤ 0.1‰; расхождение с оракулом ≤ 0.1–0.3%.

Conformance-тесты: схемы, обязательные поля, справочники, подписи вебхуков, курсорные выгрузки без пропусков.

8) Lineage, аудит и оракулы

Lineage: от витрины/дашборда к первичным наборам (схемы/версии/владельцы).
WORM-аудит: неизменяемые журналы схем/формул/ключей/исключений.
Оракулы (подписанные сводки): GGR/NetRev/SLO/RG с `formulaVersion`, `hash(inputs)`, `kid`, `traceId` — источник истины для инвойсов и апелляций.
Пробные «трейс-пакеты»: SLA 60–90 с для P1/P2 инцидентов.

9) Приватность, локализация и безопасность

PII-минимизация: токенизация `playerId`, запрет ПДн в логах/витринах, детокенизация только в сейф-зонах.
Локализация: карты юрисдикций (где храним/обрабатываем классы данных).
Zero Trust: mTLS, короткоживущие токены, egress-allow-list, ротация ключей/JWKS.
ABAC/ReBAC/SoD: доступ «вижу свое и согласованное»; «измеряю ≠ влияю ≠ меняю».

10) Финансовый reconciliation и расчеты

[
NetRev = GGR - BonusCost - Jackpot/PoolShare - PaymentFees - Chargebacks - Tax/Levy - FraudLosses
]

• курсорные выгрузки, «оры» (подписанные агрегаты), контрольные суммы;
• статусы инвойсов, акты расхождений и SLA разбора;
• FX-правила, NET7/14/30, холды и клау-бэки.

11) Управление стоимостью синхронизации

Политики кардинальности: запрет `userId`/сырого URL в лейблах; разрешены `routeId/campaignId`.
Downsampling/roll-ups: 1с→1м→5м; RAW-данные живут коротко, агрегаты — дольше.
Adaptive sampling трассировок: базовый процент + приоритет для ошибок/медленных путей/новых версий.
SLO-first: собираем только то, что поддерживает решения (SLO/финансы/RG).

12) Дашборды синхронизации

Data Sync Overview: publish_lag, completeness, duplicates, late ratio, schema drift, ошибки конформанса.
Attribution Health: своевременность постбеков, окна дедуп, спорные кейсы.
Finance/Oracle: расхождение агрегатов с оракулами, статусы инвойсов.
Jurisdiction Map: локализация/потоки ПДн, соблюдение DPA/DPIA.

13) Операции, инциденты, RCA

Алерты: burn-rate по свежести/полноте, дрейф схем, всплеск дубликатов.
War-room: готовые плейбуки для шины/вебхуков/CDC/витрин; стоп-кнопки для агрегаций/формул.
RCA «без поиска виноватых»: факт→гипотеза→эксперимент→вывод→действие; post-mortem SLO.

14) Анти-паттерны

«Две истины» по метрикам/формулам и датам вступления.
Offset-пагинация истории под нагрузкой (только курсоры).
Сырой ПДн в логах/витринах; отсутствие токенизации.
Зоопарк постбеков без подписей и идемпотентности → дубли/дыры.
Смешение Event/Processing Time в агрегациях.
Нет watermarks и политики поздних событий.
Согласование вручную (Excel/ручные выгрузки) вместо оракулов.
Единые большие таблицы с неограниченной кардинальностью лейблов.

15) Чек-листы

Проектирование

• Онтология, Schema Registry, владельцы, справочники.
• Metric Store с `formulaVersion` и frozen-period для MAJOR.
• Временные семантики (event time, watermarks), политика поздних событий.
• Транспорт: EDA/CDC, API/вебхуки с подписями, курсоры, идемпотентность.
• Data Quality SLI/SLO, conformance-тесты, алерты.
• Privacy/Localization (DPIA/DPA), Zero Trust, ABAC/ReBAC/SoD.
• Оракулы и правила reconciliation.

Запуск

• Песочница и нагрузочные/хаос-прогоны шины/витрин.
• Канареечная синхронизация 1%→5%→25%→50%→100% с guardrails.
• Дашборды publish_lag/completeness/duplicates/drift.
• Документация формул и дат вступления; release-notes `data_formula_change`.

Эксплуатация

• Еженедельный отчет DQ; пересмотр SLO/guardrails.
• Месячные чейнджлоги схем/формул/доступов.
• Регулярный DR/хаос для брокера/ингесторов/витрин.

16) Дорожная карта зрелости

v1 (Foundation): единые схемы, базовый CDC/батч, курсоры, DQ-SLI, ручной reconciliation.
v2 (Integration): watermarks и политика поздних событий, оракулы, дашборды синхронизации, auto-ретраи с джиттером.
v3 (Automation): предиктивный мониторинг свежести/полноты, smart-reconciliation, авто-переиндексация, адаптивный sampling.
v4 (Networked Governance): межцепной обмен оракулами/сигналами качества, DAO-правила формул и прозрачные казначейства.

17) Метрики успеха

Качество данных: publish_lag p95, completeness %, duplicate ‰, late %, schema drift rate.
Единообразие: доля отчетов с зафиксированным `formulaVersion`, число MAJOR без инцидентов.
Финансы: расхождение с оракулами, доля авто-reconciliation, спорность < X%.
Операции: MTTD/MTTR инцидентов синхронизации, доля авто-стопов/роллбеков.
Комплаенс: 0 утечек ПДн, успешные DPIA/DPA-проверки, доступность WORM-логов 100%.
Экономика наблюдаемости: Cost-to-Sync на rps/event, соблюдение кардинальности.

Краткое резюме

Синхронизация аналитических данных — это не копирование таблиц, а протокол доверия и времени: каноника схем и формул, event-time с watermarks, курсоры и идемпотентность, дедуп и поздние события, DQ-SLO и оракулы, приватность и локализация. Следуя этому каркасу, экосистема получает единую, свежую и доказуемую аналитику — основа для быстрых решений, честных расчетов и масштабируемого роста сети.