მეტა-ანალიტიკა და მეტრიკა

1) რა არის მეტა-ანალიტიკა

მეტა-ანალიტიკა არის თავად გაზომვის კონტროლი: ფორმულები, წყაროები, ახალი, სტაბილურობა და მეტრული წარმოების ღირებულება. მიზანია, რომ თითოეული მეტრი იყოს ცოდნის გამოცდილი ერთეული: რეპროდუცირებული, დროული, შედარებული გუნდებსა და ეკონომიკურს შორის.

2) მეტრიკის ჩონჩხი (Metric Entity Model)

• იდენტიფიკატორი: 'metric _ key', მფლობელი (Product/Data Owner), კრიტიკა (Gold/Silver/Bronze).
• მნიშვნელობა: განმარტება, ერთეული, აგრეგაცია, ფანჯრები (დღე/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).
Consistence: დამთხვევა წყაროებს/დაშბორდებს შორის (კანონიკური ფორმულა).
ფრეშნესი: მონაცემთა ასაკი vs SLO (წმ/წთ).
Completeness: შევსებული სეგმენტების/თარიღების პროპორცია.
Stability: დისპერსია/ცვალებადობა უცვლელი პირობებით (Levene/variance ratio).
Explainability: ბარათში ფორმულის/ბმულების/CI/დიაპაზონის არსებობა.

პროდუქტიულობა და ღირებულება

Latency p95/p99 გაანგარიშება/render.
Bytes scanned/მოთხოვნა.
CPC/CPI: გრაფიკის/ინსაიტის ღირებულება.
Cache hit-rate და მატერიალიზაცია.

რისკი და გამოყენება

Adoption: დაშბორდების/გადაწყვეტილებების წილი მეტრიკის გამოყენებით.
Breakage rate: ტესტების/სიახლეების ვარდნის სიხშირე.
Drift score: განაწილების ცვლა ფორმულა/წყაროს შეცვლის შემდეგ.
მხარდაჭერა load: გასაჩივრება/მეტრის ინციდენტები.

4) სემანტიკური ფენა და „მეტრის მაღაზია“

ერთიანი გრამატიკა: ზომები, გაზომვები, ფილტრები, აგრეგაციისა და თავსებადობის წესები.
API/metrick დირექტორია: ძებნა, ბარათები, ვერსიები, ხაზის გრაფიკი.
შუალედური გამოთვლები: მატერიალიზაცია (daily/weekly), კანონიკური თაიგულები.
პუბლიკაციის პოლიტიკა: მხოლოდ Metric Store- დან prod dashboards/AI ვიზუალიზაციამდე.

5) ვერსია და თავსებადობა

SemVer მეტრიკისთვის: 'MAJOR' - მნიშვნელობის/შეკრების დარღვევის ცვლილება; 'MINOR' - ახალი განყოფილება/ატრიბუტი; 'PATCH' - ოპტიმიზაცია მნიშვნელობის შეცვლის გარეშე.
Deprecation flow: გაფრთხილება, პარალელური რეჟიმი v1/v2, გამორთვის თარიღი, მიგრაციის ჰაიდი.
ხელშეკრულების ტესტები: equality/inequality, ინვარიანტები (ქვესექტების ჯამი = მთელი).

6) Lineage და მეტრიკის აუდიტი

Upstream: წყაროები, DQ წესები, ვერსიები.
Transform: SQL/DBT/DAG nod, სქემების თავსებადობის შემოწმება.
Downstream: დაშბორდები/მოდელები/მოხსენებები, რომლებიც მოიხმარენ მეტრს.
აუდიტი: ვინ შეცვალა ფორმულა და როდის, რა ინციდენტმა ან გამოშვებამ იმოქმედა.

7) მეტრიკის დაკვირვება

დროის პროფილები: სეზონურობა, კალენდარული ეფექტები, პრომო.
ანომალიები: 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: payline საიმედოობა, პროდუქტიულობა.
Analyst/Scientist: ნამდვილობა და მიზეზობრივი ინტერპრეტაცია.
FinOps: ღირებულება და კვოტები.
Compliance/Privacy: წვდომა, შენიღბვა, ანგარიშგებები.

11) ანტიპატერები

SELECT მეტრიკის ფორმულაში.
ერთი მეტრის ორი „ოფიციალური“ ფორმულა.
Metric Store- ში ცვლილებების ნაცვლად, Dashboard- ის სახელმძღვანელო რედაქტირება.
ფანჯრის/შედარების საფუძვლის მითითების გარეშე.
ნულოვანი lineague და მფლობელის ნაკლებობა.
ფარული ფილტრები (სხვადასხვა ქვეყნები/ვალუტები) არის შეუდარებელი რიცხვები.

12) გზის განხორციელების რუკა

1. ინოვაცია: ტოპ 50 მეტრიკის სია, მფლობელები, კრიტიკა, მიმდინარე ფორმულები.
2. Metric Store MVP: ბარათები, SemVer, API, ხაზები, CI ტესტები.
3. დაკვირვება: freshness/latence/bytes scanned/ანომალიები, SLO პანელები.
4. FinOps: ლიმიტები, ქეში, მატერიალიზაცია, ღირებულების ანგარიშები.
5. ჰოვერნანსი: RFC/დეგრადაცია/გამოტოვება, რეპლიკაციის პოლიტიკა.
6. მასშტაბი: ავტომატური „მეტრიკის მეტრიკა“, ინტეგრაცია AI ვიზუალიზაციით/კონტექსტით.

13) მეტრიკის სიის სია (გამოქვეყნებამდე)

• მეტრიკის ბარათი ივსება (განმარტება, ერთეულები, სეგმენტები, ფანჯარა).
• ფორმულა განახლებულია; კოორდინაციის/ინვარიანტების ტესტები მწვანეა.
• Freshness/Latency SLO მოცემულია და აკონტროლებს.
• DQ წყაროები მწვანეა; ხაზის გამჭვირვალე.
• მოთხოვნის ღირებულება ლიმიტებში; ქეში/მატერიალიზაცია.
• წვდომის პოლიტიკოსები (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 ერთად მუშაობენ, ორგანიზაცია იღებს შედარებულ, გადამოწმებულ და ეკონომიურ ციფრებს და არა „სხვადასხვა ჭეშმარიტებას“. ეს არის საფუძველი სწრაფი ანალიტიკის, სწორი გადაწყვეტილებებისა და მასშტაბური ზრდისთვის.