Skip to content

asap-tools: feed the sketchdb arm in the ClickHouse runner #874

Closed

Description

@milindsrivastava1997

#868 feeds a sketch-bench workload table live into ClickHouse (dataset.paced_feeder in experiment_run_clickhouse.py), but refuses sketchdb mode. So nothing runs ASAPQuery's SQL arm on a live feed:

  • experiment_run_e2e.py (feat(asap-tools): run sketch-bench workload tables end to end with the paced feeder #841) feeds ASAPQuery, but its query client uses one protocol per server, so it can't send SQL query groups to ASAPQuery's SQL endpoint.
  • experiment_run_clickhouse.py's sketchdb mode sends SQL, but its engine ingests dataset.local_data_file (ingest_json_config), which a fed config doesn't have.
  • sketch_bench_workloads.py writes <stem>/asapquery.sql for this arm, but no config reads it.

Needed

  1. Ingest: in a fed sketchdb mode, start the query engine with remote-write ingest (no ingest_json_config).
  2. Shared feed: one PacedFeederService.start with two sinks, ASAPQuery's ingest (remote write, records as <metric>.<field>) and ClickHouse (which needs the data for forward_unsupported_queries), so both share one --start-ms and seed. Then set_data_start as for the other arms.
  3. Generator: a sketchdb arm config in sketch_bench_workloads.py using asapquery.sql and a prebuilt planner output (--planner saved, feat(planner): --planner saved for SQL #866).

Open question

asapquery.sql has only the structured entries; PromQL entries have no ASAPQuery SQL. An arm with a subset of the queries has different query indices from baseline's, so results can't be matched by index. Either render the PromQL entries as ASAPQuery SQL too, or label results by query text/description instead of index.

Raised in review of #868.

🤖 Generated with Claude Code

Activity

  1. milindsrivastava1997 commented on Oct 15, 2026

    @milindsrivastava1997
    ContributorAuthor

    CloudLab run of the fed sketchdb arm (#899–#901, plus #905): it works end to end.

    Setup: one node (node1). sketch-bench e2e-rate10 multigroup table: 50 structured SQL queries over the http and flows records metrics, fed at the table's rates (100k and 200k records/s). Saved plan: asap/cpu, cheapest (--planner saved --query-language sql). Starting delay 910 s, 600 s of queries (10 rounds, every 60 s).

    Results

    • ASAPQuery answered all 500 sketchdb queries itself (destination=asap, HTTP 200). None were forwarded or unsupported.
    • Feeds ran in full in both modes: 471M rows each, 0 failed requests. The sketchdb feed went to ASAPQuery only.
    • Accuracy against baseline (ClickHouse, exact), per query, over all keys and rounds:
    Queries Median relative error p95 relative error
    38 cardinality (HLL) 0.8–1.4% 1.5–3.2%
    12 p99 latency (DDSketch, α = 0.1) 4.8–6.2% 6.3–9.6%

    Every key matched across modes (0 missing, 0 extra). The p99 errors stay within DDSketch's 10% relative-error bound.

    Caveat on calculate_fidelity: it scores 34 of the 50 queries correctly (MAPE 1.0–1.4% cardinality, 4.9–6.1% p99). The other 16 come out as 0, because nothing is compared. They group by endpoint after a label that sorts after it (e.g. region, endpoint), and ASAPQuery's ClickHouse adapter writes label columns alphabetically while ClickHouse uses SELECT order. That's the limitation noted in #896. The table above uses an offline scorer that reads ASAPQuery's columns alphabetically. A fix would have the adapter emit SELECT order.

    Bugs found on the way (all fixed):

    🤖 Generated with Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions