feat(asap-tools): label query sets and skew fits for cluster traces

[zzylol]

Summary

Adds asap-tools/dataset-analysis/, which covers two tasks:

1. Label query sets: PromQL queries, with their exact group-by labels, for three traces:
   • Google ClusterData 2011
   • Alibaba microservices v2022
   • Datadog BOOM
2. Skew fits: for each query, a lower bound, a maximum-likelihood fit and an upper bound of the skew parameter.
   • Queries that aggregate over keys (the group-by labels) get a discrete Zipf θ, weighted by row count and by value sum.
   • Queries that aggregate over values get a power-law tail α. It is fitted with powerlaw, the method of Clauset, Shalizi & Newman, and compared against lognormal and exponential fits.
   • lower/upper are the min/max of per-window MLEs; mle is the fit on all the data.
   • Windows are 5 min for Google, 1 min for Alibaba, and 20 equal chunks per series for BOOM.

results/skew_summary.csv (59 rows) is the handoff to the sketch-bench saturation study.

Data

fetch_data.sh downloads a fixed sample:

• Google: task_usage and task_events part-00000, plus all of job_events.
• Alibaba v2022: NodeMetrics_0, MSMetrics_0, and 10 consecutive CallGraph and MCRRT shards (30 min). These are read straight from tar.gz.
• BOOM: 20 sampled series plus the taxonomy.

A full run takes about 4.5 min with 48 workers.

Key θ (lower / mle / upper), count-weighted; value-weighted in brackets

Query	θ
Google sum by (user) (cpu_rate)	1.22 / 1.24 / 1.28 [1.25 / 1.30 / 1.42]
Google sum by (user, priority)	1.23 / 1.25 / 1.28 [1.27 / 1.32 / 1.44]
Google sum by (priority)	1.03 / 1.10 / 1.17 [1.44 / 1.61 / 1.75]
Google sum by (job_id)	1.11 / 1.10 / 1.14
Google sum by (scheduling_class)	0.41 / 0.58 / 0.76
Google sum by (machine_id) (uniform baseline)	0.23 / 0.21 / 0.25
Alibaba MSRTMCR by (msname)	1.34 / 1.54 / 1.90 [1.03 / 1.11 / 1.31]
Alibaba MSRTMCR by (nodeid)	1.07 / 1.13 / 1.23
CallGraph count by (rpctype)	1.26 / 1.32 / 1.39
CallGraph count by (um) / by (dm)	1.11 / 1.15 / 1.13, 1.10 / 1.13 / 1.11
CallGraph count by (service, um, dm)	0.91 / 0.98 / 0.93
MSMetrics sum by (msname)	0.83 (the same in every window)
NodeMetrics by (nodeid) (uniform baseline)	≈0

Known issues (why this is a draft)

• mle can fall outside [lower, upper]. For most CallGraph queries, the fit on all 30 minutes is steeper than the fit on any single minute: pooling adds rare keys to the tail and more mass to the heavy keys. So mle is not bracketed by the window bounds. The definition of the bounds needs a decision.
• Value α is not ready to use as-is.
  • Fits use up to 5,000 sampled values, and the tail must keep at least 100 values, so α describes roughly the top ≥2% of values.
  • The Google fits lose to lognormal.
  • For BOOM, power_law_ok is a majority vote over variates while R and p are medians. As a result ds-671-10S and ds-1840-D show ok=True with absurd α.
• powerlaw is pinned to 1.5. Version 2.0 caps α at 3 by default and falls back to a slow numerical fit.
• BOOM: the tags were removed and each variate was z-scored. So there is no key θ for BOOM, and α is fitted per variate on x - min(x).
• The um/dm labels include the placeholder values UNKNOWN and USER, which are counted as ordinary keys.

Also changed

.github/workflows/python.yml gets a test-dataset-analysis job (black, isort, flake8, mypy, unittest), path-filtered to this directory.

Validation

• black, isort, flake8, mypy and shellcheck pass.
• 18 unit tests pass. They cover Zipf θ recovery within ±0.05, Pareto α recovery within ±5%, the bounds logic, and failure paths.

Citations

• Google ClusterData 2011 traces (2025)
• Luo et al., "The Power of Prediction: Microservice Auto Scaling via Workload Learning", SoCC 2022
• Cohen et al., "This Time is Different: An Observability Perspective on Time Series Foundation Models", arXiv 2505.14766

🤖 Generated with Claude Code