Skip to content

docs: comparison ASAP vs. Databricks Pantheon + Hydra - #291

Merged
zzylol merged 1 commit into
mainfrom
docs/asap-vs-databricks-comparison
May 6, 2026
Merged

zzylol merged 1 commit into
mainfrom
docs/asap-vs-databricks-comparison

Conversation

@zzylol

@zzylol zzylol commented May 6, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds docs/comparison-asap-vs-databricks-pantheon-hydra.md — an architectural side-by-side between the Databricks 2026-04-29 blog post on their internal monitoring stack (Pantheon Thanos fork + Telegraf aggregation + Hydra Spark/Delta lakehouse, at 10T samples/day, 5B active series, 70 regions) and ASAP.

What's in it

  • Pantheon + Hydra architecture summary (storage tiers, aggregation pipeline, scale numbers)
  • ASAP architecture summary (brief — links Design.tex / paper for detail)
  • Side-by-side comparison table on 9 axes (where summarisation runs / what it means / wire format / approximation visibility / tier topology / raw retention / cardinality control / query languages / deployment shape)
  • Scale-gap table (orders of magnitude, with honest framing)
  • Where ASAP claims novelty (sketches at any tier with stage-allocator, bounded-error API contract, workload-driven controller planning, single PromQL surface over multiple internal tiers)
  • Where Databricks is decisively ahead (operational scale, federated multi-region, production cost evidence, always-on raw retention)
  • Synthesis suggestions
  • Paper-framing language ready to drop into §RelatedWork
  • Open question on JSONL cold-fallback deprecation in favour of an always-archive Gorilla-S3 tier (mirrors Hydra's always-streaming pattern)

Why merge to main

The Databricks blog is the most relevant industrial data point on the same problem space. Capturing the comparison now (a) informs the paper's §RelatedWork framing, (b) documents an architectural decision (the JSONL deprecation) we're tracking separately, and (c) gives reviewers a cleaner story than "we are different from Databricks because reasons".

Test plan

  • Doc renders cleanly (markdown only, no code)
  • Cited blog URL is correct
  • Internal cross-refs (Design.tex, design-gorilla-s3-cold-engine.md) point to existing files

🤖 Generated with Claude Code

The Databricks 2026-04-29 blog post on their internal monitoring stack
(Pantheon + Hydra at 10T samples/day, 5B series, 70 regions) is a real-
world data point worth comparing to ASAP's design choices.

This doc captures:
- Pantheon (Thanos fork) + Telegraf aggregation pipeline + Hydra
  (Spark + Delta Lake) summary
- Side-by-side architectural comparison
- Where ASAP claims novelty (sketches at any tier, bounded-error
  contract, workload-driven planning, single PromQL surface over
  multiple internal tiers)
- Where Databricks is decisively ahead (operational scale, federated
  multi-region, production cost evidence, always-on raw retention)
- Synthesis suggestions for both directions
- Paper-framing language for §RelatedWork
- Open question on JSONL cold-fallback deprecation in favour of an
  always-archive Gorilla-S3 tier (mirrors Hydra's always-streaming
  pattern)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@zzylol
zzylol merged commit 7b50e51 into main May 6, 2026
@zzylol
zzylol deleted the docs/asap-vs-databricks-comparison branch May 9, 2026 18:00
zzylol added a commit that referenced this pull request May 18, 2026
…ave queries + stale bucket key (#394)

Four orthogonal fixes that together make the multinode harness validate
the post-#290/#291/#292 sum-by-zone wave end-to-end on the ASAP arm.

1. run_demo.sh::backend_up() now brings up an asap-controller container
   on node2 alongside asap-backend, mirroring the singlenode
   docker-compose base.yml. Post-Phase-9 the controller and backend are
   two binaries in the same asap/query-backend:dev image but distinct
   processes; without the standalone controller the backend stays on
   the static DDSketch-only fallback (no Sum/Topk roles) and the
   wave queries silently return empty. Started after the backend so the
   startup pre-pop replan_all tick has a live POST target
   (CONTROLLER_BACKEND_ENDPOINT=http://backend:9091/api/v1/streaming-config,
   full URL form matching backend_client::BackendClient::new contract).
   Stale CONTROLLER_* env vars on the backend container removed; they
   were pre-Phase-9 carry-over the backend never reads. topology.env's
   "controller in-process" comment updated to reflect separate-container
   reality.

2. scripts/run_demo.sh:387 had `--endpoint`; the actual metricsql_replay.py
   arg is `--target`. Replay was silently failing argparse and the
   exception path returned 0 successes. Fixed.

3. queries-e2e.json extended with the wave's 3 marquee queries:
   `sum by (zone) (http_requests_total)`,
   `sum by (zone) (rate(http_requests_total[5m]))`,
   `topk(5, sum by (zone) (rate(http_requests_total[5m])))`.

4. agent yamls (mvp-multinode + mvp-singlenode) still set
   `bucket: asap-gorilla`, but PR #388 deleted the Bucket field from
   gorillas3processor/config.go (only `tsdb_bucket` remains). Result:
   agent crash-loop with `'gorillas3' ... '' has invalid keys: bucket`.
   Line removed from both yamls; comment references #388.

## Validation (sync + arm asap, ASAP arm)

- replay.jsonl: 384 success lines (was 0 pre-fix); all 3 wave queries
  show success: `sum by (zone) (http_requests_total)` (128),
  `sum by (zone) (rate(http_requests_total[5m]))` (128),
  `topk(5, sum by (zone) (rate(http_requests_total[5m])))` (128).

- Controller logs confirm typed-stage-split JSON POST succeeded for
  each (metric, role) pair: top_endpoint_qps/topk,
  request_size_bytes/quantile, http_requests_total/sum, etc. — all
  hitting http://backend:9091/api/v1/streaming-config with 2xx.

- Agent logs: clean startup, no crash-loop, all 7 gorillas3 pipeline
  instances (raw_passthrough, ddsketch_path, hll_path, kll_path,
  countminsketch_path, countsketch_path) starting with
  `tsdb_bucket: asap-gorilla-tsdb` (no `bucket:` field). TSDB blocks
  written.

- Manual probe against http://10.10.1.3:9091/api/v1/query, all returning
  `data_source: asap_query`:
  * `sum by (zone) (http_requests_total)` →
    z0:981128625, z1:981127610, z2:981127004, z3:981125787
  * `sum by (zone) (rate(http_requests_total[5m]))` →
    z0:4798703.10, z1:4798695.49, z2:4798690.49, z3:4798680.18
  * `topk(5, sum by (zone) (rate(http_requests_total[5m])))` →
    same 4 zones (only 4 exist; topk(5) returns all)
  * `quantile_over_time(0.99, http_requests_total_latency_ms[5m])` →
    empty (the multinode producer only emits http_requests_total, no
    _latency_ms; pre-existing harness gap, orthogonal to this PR).

- Teardown clean.

## Out-of-scope follow-up

Controller startup replan_all races the backend's /api/v1/streaming-config
handler bind: the first POST burst races the route registration and
some pushes get 404'd; subsequent OpAMP-on-connect re-fire makes the
plan converge anyway. Lives in ASAPQuery-backend, not addressed here.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant