元分析和度量指標

1）什麼是元分析師

元分析是對度量本身的控制：公式，來源，新鮮度，穩定性和獲得度量的成本。目標是確保每個指標都是可驗證的知識單位：可復制，及時，團隊之間可比且經濟。

2）度量標準骨架（Metric Entity Model）

• ID： 「metric_key」,所有者（產品/數據所有者）,臨界值（Gold/Silver/Bronze）。
• 含義：定義、單位、聚合、窗口（day/wow/mom/rolling）。
• 公式和層：SQL/DSL，語義層（dimensions，filters），有效段。
• Source and Lyneage：表格、版本、依賴性（fichi/Sharters/Model）。
• SLO метрики: latency p95, freshness, coverage, accuracy, stability.
• 信托信號：最新檢查，DQ狀態，公式CI測試。
• 經濟學：bytes scanned, cost-per-chart （CPC）, cost-per-insight （CPI）。
• 訪問控制：RLS/CLS,靈敏度。
• 轉化：semver公式（'ggr@2.3.0'），更改日誌。

3）「度量指標」： 測量什麼

質量和信任

Accuracy：與基準/會計（MAE/APE）的差異。
一致性：源/dashbords之間的匹配（規範公式）。
新生：數據年齡vs SLO（秒/分鐘）。
完成：已完成的段/日期的比例。
穩定性：不變條件下的方差/波動（Levene/variance ratio）。
Explainability：卡中存在公式/引用/CI/範圍。

性能和成本

Latency p95/p99計算/渲染。
字節掃描/查詢。
CPC/CPI：圖形/洞察力的成本。
Cache命中率和實現。

風險和使用

Adoption：使用度量的行列板/解決方案的比例。
突破率：測試跌倒/新鮮度中斷的頻率。
Drift score：公式/源更改後的分布偏移。
支持加載：按指標處理/事件。

4）語義層和「Metric Store」

單一語法：度量，度量，過濾器，聚合和兼容性規則。
API/指標目錄：搜索、卡片、轉換、線性圖。
中間計算：實現（每日/每周），規範的vyuhi。
發布策略：僅從Metric Store到prod-dashbords/AI渲染。

5）轉化與兼容性

用於度量的SemVer：「MAJOR」是含義/聚合的突破性變化；「MINOR」是新的切口/屬性；「PATCH」是不更改值的優化。

分離流： 警告,並行v1/v2,關閉日期,遷移海德.

合同測試：equality/inequality，不變量（子分段總和=整數）。

6）Lynedge和審計指標

上遊：來源，DQ規則，版本。
Transform： SQL/DBT/nod DAG、電路兼容性檢查。
Downstream：消耗度量的行車記錄/模型/報告。
審計：誰改變了公式，什麼時候，什麼事件或發布受到影響。

7）可觀察度量（Metric Observability）

時間簡介：季節性，日歷效果，促銷。
異常：STL/ESD/BOCPD；具有臨界靈敏度的異構體。
支票門：在發布之前-比較「黃金」切片上的舊/新公式。
漂移監控：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：含義，公式，發行版，通信。
數據工程師：pipline可靠性,性能。
分析師/科學家：有效性和因果解釋。
FinOps：成本和配額。
Compliance/Privacy：可用性、掩碼、報告。

11）反模式

度量公式中的SELECT。
一個度量的兩個「官方」公式。
在dashboard中手動編輯而不是Metric Store的更改。
未指定窗口/比較基礎。
零位數和主人缺席。
隱藏的過濾器（不同的國家/貨幣）→不可比數字。

12）實施路線圖

1.Inventory：前50名指標列表，所有者，關鍵性，當前公式。
2.Metric Store MVP：卡片，SemVer，API，線性，CI測試。
3.可觀察性：freshness/latency/bytes掃描/異常，SLO面板。
4.FinOps：限制、緩存、實現、價值報告。
5.Hovernans： RFC/降解/回滾,取消策略。
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 Alert策略指標

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 dashboard的「度量指標」報告

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一起工作時，組織將獲得可比較，可驗證和經濟的數字，而不是「不同的真相」。它是快速分析、正確解決方案和可擴展增長的基礎。