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

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 працюють разом, організація отримує порівнянні, перевіряються і економічні цифри, а не «різні правди». Це фундамент для швидкої аналітики, коректних рішень і масштабованого зростання.