元分析和度量指标

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一起工作时，组织将获得可比较，可验证和经济的数字，而不是"不同的真相"。它是快速分析、正确解决方桉和可扩展增长的基础。