Data Analysis

Anomaly Diagnosis

AE Analysis - Multi-Cluster

In a multi-cluster deployment, route report and Ad-hoc queries by global or slave cluster so cluster-selection errors no longer skew the data definition.

IndustriesAll industries

Agent · Skills Live

skill · loadedindustry+100

Run this Skill on my data

User path

step to step

Analysis readyevidence attached

The AE Global Cluster Query Skill is a multi-cluster data-routing capability in ThinkingAI's industry Skill library. In an AE multi-cluster (global/slave) deployment, it helps operations and analysis teams choose the right query scope and cluster routing, avoiding skewed data definitions or empty results from cluster-selection errors, moving from "not knowing which cluster to query" to a precise mode of checking cluster info, choosing the route, then querying. This is ThinkingAI's decade of industry experience, packaged into ready-to-use Skills.

Live walkthrough

AgentSave as AgentExport session

ae-analysis-global

Last week's global revenue report doesn't reconcile with the finance system, and it's way short. I pulled the report data straight from the default cluster. Did I pick the wrong cluster? Re-pull it with the correct metric definitions, and break it out by region while you're at it.

+list_query_clusters lists all query clusters for a sample overseas SLG game DEMO

Current cluster + Southeast Asia slave cluster + North America/Europe slave cluster, GLOBAL access enabled

Locate the original report's data source

The report query had no cluster_query_scope parameter, so it queried only the current cluster by default

+query_report_data --cluster_query_scope GLOBAL re-pulls last week's revenue

Global scope: 408.3 ($10K)

Route by SLAVE to pull revenue and DAU cluster by cluster, cross-check the sum

Compare the gap against the original report's scope, generate a metric-definition correction note

Found why it didn't reconcile: your report only counted the current cluster. Re-pulled at GLOBAL scope, last week's revenue is 408.3 ($10K), a gap of 161.1 ($10K), or 39.5% of the global figure, exactly the combined revenue of the two slave clusters.

1. Your project has three query clusters

Current cluster (the default query scope): with no cluster_query_scope parameter, only this one is queried, which is the source of the gap

Southeast Asia slave cluster and North America/Europe slave cluster: you must explicitly route via SLAVE for these to be queried

The project already has GLOBAL query access, so the global aggregate scope is usable directly, with no need to sum clusters by hand

2. Revenue breakdown at global scope

Cluster	Last week's revenue ($10K)	Revenue share	Weekly avg. DAU (10K)	Payment rate
Current cluster	247.2	60.5%	18.2	3.1%
Southeast Asia slave cluster	121.5	29.8%	15.6	2.2%
North America/Europe slave cluster	39.6	9.7%	3.4	4.0%
GLOBAL total	408.3	100%	37.2	2.8%

← Scroll to see more

Last week's revenue by cluster　Unit: $10K

The Southeast Asia slave cluster contributed nearly a third of revenue (29.8%), and its DAU is close to the current cluster (15.6 vs. 18.2, in 10K), all of which was entirely missing from the original report. The NA/EU cluster is small but has the highest payment rate (4.0%), worth looking at on its own for deep regional analysis.

3. Metric-definition rules to avoid tripping again

Global overview → --cluster_query_scope GLOBAL, aggregates all clusters in one pass

Single-region deep dive → SLAVE + the specified slave cluster, returns only that cluster's data

No parameter → queries only the current cluster by default: fine for single-cluster projects, use with care on multi-cluster projects

Heads-up

One exception you must watch for: SQL ad-hoc models only support the current cluster, not GLOBAL / SLAVE routing. If the report mixes in SQL components, that part is still at current-cluster scope and needs to be flagged separately, otherwise the corrected report will slip back into a metric-definition mismatch.

The GLOBAL scope parameter has been written back into the report query template, so it will produce numbers at global scope automatically starting next week.

On your data

That was a simulated run

Leave your work email and we will run a live walkthrough on your real business data.

The problem

Multi-cluster deployment is the standard architecture for global and overseas products, yet more than 50% of analysis teams stumble on cross-cluster queries: they don't know how many query clusters the project has, don't know the slave cluster names and IDs, and don't know the difference between GLOBAL and SLAVE permissions. After choosing a query scope on instinct, they get empty data, a permission error, or a definition inconsistent with the single cluster. A cross-cluster query averages more than 30 minutes to debug, and the error is often caught only after the data has already been used for a decision.

What it does

Automatic cluster discovery: list all of the project's query clusters (current plus slave) in one click, with names, descriptions, and permission info

Precise route matching: automatically choose GLOBAL / SLAVE / default scope based on user intent, never guessing at disallowed parameters

Clear permission boundaries: check GLOBAL and SLAVE query permissions and tell the user directly about disallowed parameters instead of failing silently

Safe SQL-model isolation: SQL Ad-hoc models support only the current cluster, and cross-cluster SQL queries are automatically excluded to avoid data mix-ups

When to use it

An overseas project that needs to query global aggregated data (all clusters combined)

You need to query a specific slave cluster (such as Southeast Asia or Europe/US) on its own

Unsure how many clusters the project has and need to check cluster info first

A query returns a permission error and you need to confirm the allowed query-scope parameters

You need to distinguish the concepts of "query cluster" and "user cohort" to avoid confusion

In the field

Case

An overseas SLG game · global revenue weekly report correction

The project had a current cluster, a Southeast Asia slave cluster, and a Europe/US slave cluster. Operations originally used only current-cluster data for the global revenue weekly report, missing 30% of revenue from the Southeast Asia cluster. The Skill first ran +list_query_clusters to list all clusters and confirm GLOBAL permission, then used +query_report_data --cluster_query_scope GLOBAL to get global aggregated data, correcting the weekly report to a global definition.

FAQ

What is the difference between a GLOBAL query and a SLAVE query?

A GLOBAL query aggregates data across all clusters, good for a global overview. A SLAVE query returns only the specified slave cluster's data, good for deep regional analysis.