Repository navigation
Spike: Validate cross-cluster ClickHouse migration for legacy experiment events #36784
Description
Activity
- addeddotCMS : ExperimentsAnalytics Umbrella: Experiments FeatureAnalytics Umbrella: Experiments FeatureType : Spikea time boxed issue to answer question(s)a time boxed issue to answer question(s)
on Jul 28, 2026 - added a parent issue
on Jul 28, 2026 Scope note — absorbs the decision half of Part 1's data-migration criterion
#37020 was opened during Sprint 1 planning and closed as a duplicate of this issue. This spike's go/no-go recommendation is the epic's Part 1 acceptance criterion ("Decided and documented whether existing experiment data migrates from the old pipeline").
Adding the pieces that were in #37020 and are not yet covered here — the business half of the decision, as opposed to the technical feasibility this spike already scopes well:
- Affected customer list confirmed (Lennox and MLH per the implementation plan, plus any others), including whether any of them have an experiment running right now — that materially changes the impact of a no-go
- If no-go: what happens to in-flight experiments at cutover is stated — stopped, allowed to finish on the old pipeline, or restarted on the new one
- If no-go: an upgrade-note requirement is filed against Part 4 docs covering what existing experiment owners lose
- Either way, the epic's Part 1 checkbox in Experiments: A/B Testing v2 #36763 is ticked and points at this spike's conclusion
⚠ Blocked by #37016
This spike's acceptance criteria assume
analytics.eventsalready hasexperiment_id,running_id, andvariant, and thatsession_facts_latestcarries them through the session pipeline. None of those columns exist yet — they are added in #37016 (Sprint 1). TheINSERT INTO analytics.events (...)in the migration SQL above cannot run until that lands.Note on the referenced doc
docs/experiment-data-migration.mdis not present indotCMS/coreor indot-ca-event-manager/docs/as of 2026-08-11. If it exists only locally, worth pushing it — the column mapping is the substance of this spike and reviewers cannot check the approach without it.- moved this from Next Sprint to Next 2-4 Sprints in dotCMS - Product Planning
on Sep 8, 2026 - moved this from Next 2-4 Sprints to Next Sprint in dotCMS - Product Planning
on Sep 8, 2026 - removed a parent issue
on Sep 21, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsNext Sprint
Note: This template is intended for Engineering team use.
Research Question
Can ClickHouse's
remote()table function reliably migrate legacy experiment events from the Jitsu-based ClickHouse cluster (clickhouse_test_db.events) to the new CAEM analytics cluster (analytics.events) — with correct column renames and full session pipeline processing — such that experiment goal metrics become queryable via the CAEM endpoints?Timebox
8h
Acceptance Criteria
customer_idwith known experiment events (experiment != '') is successfully inserted intoanalytics.eventson the new cluster using the migration SQL fromdocs/experiment-data-migration.mdtenant,project,experiment_id,running_id,variant,session_id, and alldom_element_*columns contain the expected valuesSYSTEM REFRESH VIEW analytics.session_facts_rmvandSYSTEM REFRESH VIEW analytics.session_facts_latest_rmv, at least one session for the migratedexperiment_idappears insession_facts_latest FINALwith the correctexperiment_id,running_id, andvariantremote()approach; if go, includes an estimated migration time once the full dataset size is established (size discovery is part of the spike)Context
The old experiment infrastructure stores analytics events in
clickhouse_test_db.eventson a Jitsu-based ClickHouse cluster. The new CAEM analytics pipeline usesanalytics.eventson a separate ClickHouse instance. Before building the full migration, we need to validate the proposed approach end-to-end on a small sample.The migration uses ClickHouse's built-in
remote()table function — no intermediate files needed:After insertion, the session pipeline (
session_states_mv,session_facts_rmv,session_facts_latest_rmv) must process the migrated events so experiment goal metrics become queryable. The main prerequisite is network connectivity between the two clusters on port 9000. If that is blocked, the fallback is a Parquet export/import path.Links
docs/experiment-data-migration.md