Мета-аналитика и метрики метрик

1) Что такое мета-аналитика

Мета-аналитика — это управление самим измерением: формулами, источниками, свежестью, стабильностью и стоимостью получения метрик. Цель — чтобы каждая метрика была проверяемой единицей знания: воспроизводимой, своевременной, сопоставимой между командами и экономичной.

2) Скелет метрики (Metric Entity Model)

• Идентификатор: `metric_key`, владелец (Product/Data Owner), критичность (Gold/Silver/Bronze).
• Смысл: определение, единицы, агрегация, окна (day/wow/mom/rolling).
• Формула и слой: SQL/DSL, семантический слой (dimensions, filters), допустимые сегменты.
• Источники и линеедж: таблицы, версии, зависимости (фичи/витрины/модели).
• SLO метрики: latency p95, freshness, coverage, accuracy, stability.
• Trust Signals: последние проверки, DQ-статус, CI-тесты формулы.
• Экономика: bytes scanned, cost-per-chart (CPC), cost-per-insight (CPI).
• Контроль доступа: RLS/CLS, чувствительность.
• Версионирование: semver формулы (`ggr@2.3.0`), журнал изменений.

3) «Метрики метрик»: что измерять

Качество и доверие

Accuracy: расхождение с эталоном/бухгалтерией (MAE/APE).
Consistency: совпадение между источниками/дашбордами (каноническая формула).
Freshness: возраст данных vs SLO (сек/мин).
Completeness: доля заполненных сегментов/дат.
Stability: дисперсия/волатильность при неизменных условиях (Levene/variance ratio).
Explainability: наличие формулы/ссылок/CI/диапазонов в карточке.

Производительность и стоимость

Latency p95/p99 расчета/рендера.
Bytes scanned / запрос.
CPC/CPI: стоимость графика/инсайта.
Cache hit-rate и материализации.

Риск и использование

Adoption: доля дашбордов/решений, использующих метрику.
Breakage rate: частота падений тестов/срывов свежести.
Drift score: сдвиг распределений после изменений формулы/источника.
Support load: обращения/инциденты по метрике.

4) Семантический слой и «Metric Store»

Единая грамматика: меры, измерения, фильтры, правила агрегаций и совместимости.
API/Каталог метрик: поиск, карточки, версионирование, lineage-граф.
Промежуточные вычисления: материализации (daily/weekly), канонические вьюхи.
Политика публикации: только из Metric Store в прод-дашборды/AI-визуализацию.

5) Версионирование и совместимость

SemVer для метрик: `MAJOR` — ломающее изменение смысла/агрегаций; `MINOR` — новый разрез/атрибут; `PATCH` — оптимизации без изменения значения.
Deprecation flow: предупреждение, параллельный режим v1/v2, дата выключения, миграционный гайд.
Контрактные тесты: equality/inequality, инварианты (сумма подсегментов = целое).

6) Линеедж и аудит метрик

Upstream: источники, DQ-правила, версии.
Transform: SQL/DBT/нод DAG, проверки совместимости схем.
Downstream: дашборды/модели/отчеты, кто потребляет метрику.
Аудит: кто менял формулу и когда, какой инцидент или релиз повлиял.

7) Наблюдаемость метрик (Metric Observability)

Профили времени: сезонность, календарные эффекты, промо.
Аномалии: STL/ESD/BOCPD; алерты с чувствительностью по критичности.
Чек-гейты: перед релизом — сравнение старой/новой формулы на «золотом» срезе.
Drift-мониторинг: PSI/JS по сегментам; маркеры изменения источника.

8) Экономика метрик и FinOps

Квоты/лимиты: max bytes scanned, время выполнения, off-peak rebuild.
Chargeback: команды платят «виртуально» за тяжелые отчеты.
Кэш/материализации: профили тайлов и TTL.
Оптимизация: колоночные форматы, ZSTD, сортировка/кластеризация, предагрегаты.

9) Управление изменениями (Change Mgmt)

RFC метрики: цель, риск, ожидаемый сдвиг, план отката.
A/B формулы: параллельный расчет и сравнение метрик v1 vs v2.
Коммуникация: changelog в карточке, баннер на связанных дашбордах.
Откат: быстрый переключатель на предыдущую материализацию.

10) Роли

Metric Owner: смысл, формула, релизы, коммуникации.
Data Engineer: надежность пайплайна, производительность.
Analyst/Scientist: валидность и причинная интерпретация.
FinOps: стоимость и квоты.
Compliance/Privacy: доступы, маскирование, отчетность.

11) Антипаттерны

SELECT в формуле метрики.
Две «официальные» формулы одной метрики.
Ручные правки в дашборде вместо изменения в Metric Store.
Без указания окна/базиса сравнения.
Нулевой линеедж и отсутствие владельца.
Скрытые фильтры (разные страны/валюты) → несопоставимые цифры.

12) Дорожная карта внедрения

1. Inventory: список топ-50 метрик, владельцы, критичность, текущие формулы.
2. Metric Store MVP: карточки, SemVer, API, lineage, CI-тесты.
3. Наблюдаемость: freshness/latency/bytes scanned/аномалии, панели SLO.
4. ФинОпс: лимиты, кэш, материализации, отчеты стоимости.
5. Говернанс: RFC/деградации/откаты, деprecation-политика.
6. Масштаб: автоматические «метрики метрик», интеграция с AI-визуализацией/контекстом.

13) Чек-лист метрики (перед публикацией)

• Карточка метрики заполнена (определение, единицы, сегменты, окно).
• Формула версионирована; тесты согласованности/инвариантов зеленые.
• Freshness/Latency SLO заданы и мониторятся.
• DQ-источников зеленые; lineage прозрачен.
• Стоимость запроса в пределах лимитов; кэш/материализация настроены.
• Политики доступа (RLS/CLS) и маскирование применены.
• Коммуникация об изменениях подготовлена; есть план отката.

14) Мини-шаблоны

14.1 Карточка метрики (YAML)

yaml metric:
key: ggr version: 2. 3. 0 owner: "product-data@company"
definition: "Bet amount minus win amount"
unit: "currency"
aggregation: "sum"
window: ["day","wow","mom"]
dims_allowed: ["country","device_os","provider","game"]
lineage:
sources: ["fact_bets","fact_payouts"]
transforms: ["ggr_daily. sql"]
slo:
freshness_s: 600 latency_p95_ms: 1500 accuracy_mae_pct: <=0. 5 finops:
max_bytes_scanned_mb: 2048 cache_ttl_min: 60 access:
sensitivity: "internal"
rls: ["tenant","region"]

14.2 Тесты формулы (dbt-стиль)

sql
-- invariant: GGR = bets - wins select count () as violations from (
select bets - payouts as ggr_calc, ggr from mart_daily
) t where abs(ggr_calc - ggr) > 1e-6;

14.3 Политика алертов метрик

yaml alerts:
- name: ggr_freshness when: freshness_s > 600 severity: high action: [page:oncall-data, degrade:use_last_materialization]
- name: ggr_stability when: variance_ratio_week > 2. 5 severity: medium action: [open:investigation, add:banner_on_dashboards]

14.4 Сравнение версий формулы

sql select dt, country,
ggr_v1, ggr_v2,
(ggr_v2 - ggr_v1) as delta,
100(ggr_v2 - ggr_v1)/nullif(ggr_v1,0) as delta_pct from compare_ggr_v1_v2 order by dt desc, abs(delta_pct) desc limit 100;

14.5 Отчет «метрики метрик» для дашборда

yaml meta_dashboard:
tiles:
- metric: freshness_s target: <=600
- metric: latency_p95_ms target: <=1500
- metric: bytes_scanned_mb target: <=2048
- metric: anomaly_rate_7d target: <=0. 5%
- metric: adoption_rate target: >=80%

15) Итог

Мета-аналитика делает метрики надежными инженерными объектами: у них есть владельцы, версии, SLO, тесты и стоимость. Когда карточки метрик, семантический слой, наблюдаемость и FinOps работают вместе, организация получает сопоставимые, проверяемые и экономичные цифры, а не «разные правды». Это фундамент для быстрой аналитики, корректных решений и масштабируемого роста.