Skip to content

Spike: Validate cross-cluster ClickHouse migration for legacy experiment events #36784

Description

@freddyDOTCMS

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

  • Network connectivity from the new CAEM ClickHouse cluster to the old Jitsu cluster on port 9000 is confirmed; if unreachable, the blocker is documented and the Parquet export/import fallback is tested instead
  • At least one customer_id with known experiment events (experiment != '') is successfully inserted into analytics.events on the new cluster using the migration SQL from docs/experiment-data-migration.md
  • All column renames are verified in the migrated rows: tenant, project, experiment_id, running_id, variant, session_id, and all dom_element_* columns contain the expected values
  • After running SYSTEM REFRESH VIEW analytics.session_facts_rmv and SYSTEM REFRESH VIEW analytics.session_facts_latest_rmv, at least one session for the migrated experiment_id appears in session_facts_latest FINAL with the correct experiment_id, running_id, and variant
  • Any issues found (type mismatches, missing fields, pipeline errors) are documented with proposed fixes
  • The spike concludes with a go/no-go recommendation on the remote() 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.events on a Jitsu-based ClickHouse cluster. The new CAEM analytics pipeline uses analytics.events on 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:

-- Runs on the new CAEM cluster — pulls from the old one
INSERT INTO analytics.events ( ... )
SELECT customer_id AS tenant, cluster_id AS project, experiment AS experiment_id, ...
FROM remote('old-infra-host:9000', clickhouse_test_db, events, 'user', 'password')
WHERE customer_id = 'tenant-abc' AND experiment != '';

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

  • Full column mapping and migration steps: docs/experiment-data-migration.md

Activity

  1. moved this from New to Next Sprint in dotCMS - Product Planningon Jul 28, 2026
  2. erickgonzalez commented on Aug 11, 2026

    @erickgonzalez
    Member

    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.events already has experiment_id, running_id, and variant, and that session_facts_latest carries them through the session pipeline. None of those columns exist yet — they are added in #37016 (Sprint 1). The INSERT INTO analytics.events (...) in the migration SQL above cannot run until that lands.

    Note on the referenced doc

    docs/experiment-data-migration.md is not present in dotCMS/core or in dot-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.

  3. moved this from Next Sprint to Next 2-4 Sprints in dotCMS - Product Planningon Sep 8, 2026
  4. moved this from Next 2-4 Sprints to Next Sprint in dotCMS - Product Planningon Sep 8, 2026
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

    Type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions