Compute à la demande ClickHouse

Ajoutez du compute pour vos workloads ClickHouse Cloud sans redimensionner votre primary service. La prise en charge en private preview est limitée à certaines queries.

On-Demand Compute est en private preview. Cette fonctionnalité n’est couverte ni par les SLO ni par les SLA de ClickHouse Cloud, et des limitations connues comme inconnues peuvent s’appliquer. Consultez Limitations.

Inscrivez-vous sur la liste d’attente.

On-Demand Compute est une fonctionnalité de ClickHouse Cloud qui met à disposition de votre cloud service (un tenant) une capacité supplémentaire et instantanée pour les workloads pris en charge, sans avoir à redimensionner ni à provisionner un autre service. Ce travail s’exécute sur des workers ClickHouse situés en dehors du compute propre à votre service. Les workers proviennent d’un pool géré partagé entre les tenants d’une même region, mais chaque worker n’est affecté qu’à un seul tenant à la fois.

Pendant la private preview, On-Demand Compute ne prend en charge que les requêtes SELECT. Vous activez cette option pour une query au moyen de settings au niveau query/session/user, et ClickHouse affecte des workers du pool pour l’exécuter via votre service et votre endpoint existants.

Cela se distingue de la compute-compute separation. Un warehouse fournit du compute dédié et durable via plusieurs services qui partagent les mêmes données. On-Demand Compute fournit des workers temporaires issus d’un pool partagé via votre service existant.

On-Demand Compute s’appuie sur des fonctionnalités entièrement nouvelles :

• L’exécution stateless des queries avec le compute à la demande
• Un nouveau CBO (cost-based optimizer)
• Une nouvelle distributed query execution

​

Quand utiliser le compute à la demande

Pendant la private preview, utilisez le compute à la demande pour les requêtes SELECT éligibles et gourmandes en compute que vous souhaitez exécuter en dehors du compute du primary service :

• Requêtes ad hoc et requêtes analytiques : exécutez des requêtes SELECT gourmandes en compute sur des workers supplémentaires.
• Charges de travail de lecture non critiques : déportez certaines lectures hors du primary service.
• Requêtes sur data lake : interrogez des données Apache Iceberg, Delta Lake ou SharedMergeTree prises en charge sur des workers supplémentaires.
• Compute supplémentaire temporaire : demandez des workers pour les requêtes éligibles sans redimensionner le primary service.

La private preview prend en charge uniquement les requêtes SELECT. Les workers n’exécutent pas de requêtes INSERT, de DDL, de mutations ni d’opérations en arrière-plan.

​

Fonctionnement

1. Vous envoyez une requête SELECT éligible à votre service ClickHouse Cloud en demandant un nombre précis de workers. Votre endpoint, votre authentification et votre configuration RBAC restent inchangés
2. Votre cluster se connecte alors au pool et demande le nombre de workers spécifié
3. Les workers sont loués pour une durée d’au moins 60 secondes ; si la requête dure plus longtemps, le lease est automatiquement renouvelé
4. Les workers reçoivent la requête et l’exécutent
5. La réponse est ensuite renvoyée à votre client
6. Les workers sont effacés.

Pendant la private preview, chaque worker dispose de 8 vCPUs et de 32 GiB de mémoire. Utilisez distributed_plan_workers_num pour spécifier le nombre de workers demandés par la requête.

​

Utilisation du compute à la demande

​

Settings

Utilisez ces paramètres pour commencer à utiliser On-Demand Compute :

Setting	Valeur obligatoire	Objectif
make_distributed_plan	Yes	Active le distributed query plan expérimental. Obligatoire pour On-Demand Compute.
distributed_plan_workers_num	Yes	Nombre de workers à louer pour cette requête. Si la valeur est 0 (valeur par défaut), la requête s’exécute sur votre service, et non sur le pool de workers.
enable_parallel_replicas	Yes (défini à 0)	Les répliques parallèles sont incompatibles avec le distributed plan.
distributed_plan_fallback_to_local_execution	No (0 par défaut)	Paramètre permettant de basculer vers une exécution locale lorsqu’un plan ne peut pas être distribué (ne s’applique qu’avec make_distributed_plan)

Pendant la préversion, définissez ces paramètres au niveau de la requête, ou créez un utilisateur distinct doté de paramètres différents. On voit ainsi immédiatement quels statements utilisent On-Demand Compute.

​

Exemple

Certaines requêtes ne peuvent pas être distribuées aux workers :

SELECT count()
FROM nyctaxi.trips
SETTINGS distributed_plan_fallback_to_local_execution = 0, make_distributed_plan = 1, distributed_plan_workers_num = 5

Query id: c1c96ede-0c4c-414f-b103-f27f0b7d34c7


Elapsed: 0.992 sec.

Received exception from server (version 26.9.1):
Code: 344. DB::Exception: Received from nuqae0jhz5.eu-west-1.aws.clickhouse-staging.com:9440. DB::Exception: make_distributed_plan cannot distribute this query: it contains the step ReadFromPreparedSource which could not execute remotely. (SUPPORT_IS_DISABLED)

Pour que les requêtes basculent vers une exécution locale, vous pouvez utiliser le paramètre distributed_plan_fallback_to_local_execution :

SELECT count()
FROM nyctaxi.trips
SETTINGS distributed_plan_fallback_to_local_execution = 1, make_distributed_plan = 1, distributed_plan_workers_num = 5

Query id: c7b09855-e3c3-40ef-9790-5374e0726f26

   ┌─count()─┐
1. │   21932 │
   └─────────┘

1 row in set. Elapsed: 0.896 sec.

SELECT
    sum(l_extendedprice * l_discount) AS revenue
FROM lineitem
WHERE
    l_shipdate >= DATE '1994-01-01'
    AND l_shipdate < DATE '1994-01-01' + INTERVAL 1 YEAR
    AND l_discount BETWEEN 0.06 - 0.01 AND 0.06 + 0.01
    AND l_quantity < 24
SETTINGS
    make_distributed_plan = 1,
    distributed_plan_workers_num = 5,
    enable_parallel_replicas = 0

Cette requête demande cinq workers. Le nombre de workers alloués par ClickHouse dépend de la limite de l’aperçu privé et de la capacité disponible du pool.

​

Requêtes concurrentes

Les requêtes concurrentes provenant d’un même service ClickHouse Cloud peuvent partager les workers affectés. ClickHouse ne demande des workers supplémentaires que lorsqu’une requête en réclame davantage qu’il n’y en a déjà d’affectés au service.

Par exemple, si deux requêtes concurrentes demandent chacune trois workers, elles peuvent partager ces mêmes trois workers. Si une autre requête en demande cinq, ClickHouse peut utiliser les trois workers déjà affectés et en demander deux de plus au pool.

Voir l’exemple ci-dessous :

SELECT ... SETTINGS make_distributed_plan = 1, distributed_plan_workers_num = 3, ...;
SELECT ... SETTINGS make_distributed_plan = 1, distributed_plan_workers_num = 3, ...;

Elles partagent les trois mêmes workers.

Si une troisième query concurrente demande cinq workers :

SELECT ... SETTINGS make_distributed_plan = 1, distributed_plan_workers_num = 5, ...;

Cette requête s’exécute sur les trois workers existants, auxquels s’ajoutent deux workers nouvellement loués.

​

Lorsque le pool ne peut pas satisfaire la demande

La disponibilité des workers est assurée au mieux (best effort) pendant la private preview. Si le nombre de workers disponibles est inférieur au nombre demandé, la requête s’exécute avec les workers que ClickHouse peut affecter. Par exemple, une demande de cinq workers peut s’exécuter avec trois workers.

Si aucun worker ne peut être alloué, la requête échoue.

Relancez la query. Si le problème persiste, contactez votre account team ClickHouse — le pool de la préversion est peut-être épuisé ou mal dimensionné.

​

Monitoring

Utilisez system.query_log sur votre service pour savoir combien de workers ont été alloués à votre query.

​

Nombre de workers alloués

SELECT
    ProfileEvents['StatelessWorkerRequested'],
    ProfileEvents['StatelessWorkerProvided']
FROM clusterAllReplicas(default, system.query_log)
WHERE query_id = '<YOUR_QUERY_ID>'
  AND type != 'QueryStart';

Définissez log_comment = 'on-demand' (ou un nom de workload) sur les requêtes On-Demand afin de pouvoir les filtrer sans avoir à analyser Settings.

SELECT
    sum(l_extendedprice * l_discount) AS revenue
FROM lineitem
WHERE
    l_shipdate >= DATE '1994-01-01'
    AND l_shipdate < DATE '1994-01-01' + INTERVAL 1 YEAR
    AND l_discount BETWEEN 0.06 - 0.01 AND 0.06 + 0.01
    AND l_quantity < 24
SETTINGS
    make_distributed_plan = 1,
    distributed_plan_workers_num = 5,
    enable_parallel_replicas = 0,
    log_comment = 'on-demand-private-preview'

​

Régions disponibles

On-Demand Compute est régional : les workers s’exécutent dans la même région que votre service.

Cloud	Région	Notes
AWS	us-east-1
AWS	eu-west-1

Si votre région n’apparaît pas dans la liste, demandez-la via la liste d’attente. Nous activerons d’autres régions en fonction de la demande.

​

Tarification

Pendant la private preview, le compute à la demande est gratuit, dans la limite d’un plafond d’utilisation (voir Limitations). Contactez votre account team ClickHouse si vous avez besoin d’un plafond plus élevé.

Une tarification sera introduite à la fin de la preview. Les participants à la preview en seront informés avant que la fonctionnalité ne passe en beta et avant le début de toute facturation.

Le modèle envisagé est le même que celui du compute ClickHouse Cloud : vous payez le compute que vous consommez (le temps de worker loué), et non les données parcourues ou les rows read.

​

Limitations

Les limitations suivantes s’appliquent pendant la private preview. D’autres limitations peuvent s’appliquer. Signalez tout comportement inattendu à ClickHouse Support ou à votre account team.

• Requêtes SELECT uniquement. Les workers n’exécutent ni requêtes INSERT, ni mutations, ni DDL, ni opérations en arrière-plan.
• Format pris en charge. La private preview prend en charge Apache Iceberg, Delta Lake et SharedMergeTree.
• Répliques parallèles. Les répliques parallèles doivent être désactivées.
• Taille des workers. Chaque worker dispose de 8 vCPUs et de 32 GiB de mémoire.
• Limite de workers. Chaque requête peut demander jusqu’à cinq workers pendant la private preview.
• Capacité du pool. La disponibilité des workers est assurée au mieux. Une requête peut obtenir moins de workers que demandé. Si aucun worker n’est disponible, la requête échoue.
• Performance. La performance varie selon la requête. L’attribution des workers, la planification distribuée et le transfert des étapes du plan peuvent ajouter de la latence. Certaines formes de requêtes peuvent être moins performantes qu’une exécution sur le primary service (vos requêtes habituelles de moins d’une seconde seront probablement plus performantes dans votre cluster)
• Compatibilité des requêtes. Le distributed planner ne peut pas exécuter tous les query plans à distance. Les requêtes non prises en charge peuvent renvoyer une exception SUPPORT_IS_DISABLED.

​

Roadmap

L’On-Demand Compute constitue une base. Travaux en cours ou à venir :

• Combler les limitations connues (gaps SUPPORT_IS_DISABLED)
• Pools de workers de tailles différentes
• Stabiliser les query performance par rapport à l’exécution stateful
• Prise en charge des background merge
• Pricing
• Calibrage de l’autoscaler des pools de workers
• Observability intégrée
• Permissions dédiées pour l’On-Demand Compute
• Extension des workload Data Lake (écriture, compaction, etc.)

​

Sécurité

Les workers proviennent d’un pool préchauffé partagé entre les services d’une même region ; une règle est donc non négociable : un worker ne sert qu’un seul service à la fois, et il n’est jamais transféré d’un service à un autre.

Rien ne change dans la façon dont vous accédez à ClickHouse. Les clients continuent de se connecter à votre point de terminaison de service avec votre authentification existante, et votre service est le seul à communiquer avec les workers en votre nom. Les workers n’exposent aucun endpoint aux clients.

• Un seul service par worker : un worker est loué à un service unique pendant toute la durée du lease. Il n’est jamais partagé par deux services simultanément.
• Aucune réutilisation entre services : à la fin d’un lease, le worker est détruit et remplacé par un nouveau. Un worker n’est jamais réaffecté à un autre service.
• Aucune donnée persistante : les workers ne conservent aucun stockage persistant et ne survivent pas à la fin d’un lease.
• Même region que votre service : les workers s’exécutent dans la même region que le service qui les loue, conformément à des règles strictes de résidence des données.
• Vos access controls existants continuent de s’appliquer : les IP access lists et les private endpoints régissent votre point de terminaison de service exactement comme auparavant. On-Demand Compute n’ajoute aucun endpoint à configurer ou à protéger.
• Votre authentification et votre RBAC existants : les queries s’exécutent sous le même USER et avec les mêmes privileges que n’importe quelle autre query sur votre service. Les workers ne disposent d’aucune identity ni d’aucun modèle de permission distinct.

​

Isolation réseau

Tant qu’un worker est loué à votre service, la plateforme autorise le trafic réseau entre ce worker et votre service, et bloque tout le reste. La restriction s’applique au niveau de la couche réseau plutôt que dans le query engine : elle ne dépend donc ni de la query, ni de ses paramètres, ni du plan produit par l’optimizer.

• Seul votre service peut atteindre vos workers. Le chemin n’existe que pour la location en cours du worker, et pour ce seul service.
• Les workers non attribués sont injoignables. Un worker en attente dans le pool n’a aucun chemin réseau vers ou depuis un service tant qu’il n’est pas loué.
• Les workers loués à des services différents ne peuvent pas se joindre entre eux. Les workers d’une même location échangent entre eux des étapes de plan et des résultats intermédiaires. Les workers appartenant à des locations différentes restent isolés les uns des autres, même s’ils partagent un pool.
• Le chemin disparaît avec le worker. Mettre fin à une location détruit le worker, ce qui supprime la seule cible que le trafic était autorisé à atteindre.
• Le chemin des requests reste restreint. Votre service contacte le service d’attribution des workers pour louer et renouveler des workers. Ce chemin ne transporte aucune donnée de query et se limite à l’API d’attribution.

​

Authentification et autorisation internes

L’isolation réseau détermine ce qui peut atteindre un worker. L’authentification détermine ce que l’appelant est autorisé à faire une fois qu’il y accède, et les deux mécanismes s’appliquent indépendamment : un appelant doit satisfaire aux deux.

Chaque connexion entre votre service, le service d’attribution des workers et les workers est authentifiée. Rien n’est considéré comme fiable : tous les identifiants sont émis par la plateforme et distribués pour chaque lease.

• Un identifiant par worker : lorsque des workers sont attribués en lease à votre service, la plateforme émet un token signé unique pour chacun d’eux. Chaque token ne fonctionne que pour ce worker, et uniquement pour votre service.
• De courte durée et lié au lease : les tokens expirent avec le lease qui les a produits. Le renouvellement d’un lease en émet de nouveaux, et une fois le lease terminé, ses tokens n’authentifient plus rien.
• Vérifié auprès de la plateforme : un worker valide le token qui lui est présenté auprès du service d’identité de la plateforme, plutôt que de faire confiance aux éléments fournis dans la requête.

Connexion	Ce qui est authentifié
Votre service → service d’attribution des workers	L’identité de plateforme de votre service, qui détermine les leases sur lesquels il peut agir.
Votre service → un worker qui lui est attribué en lease	Un token signé limité à ce seul worker, pour toute la durée du lease.
Worker → worker au sein d’un même lease	L’identité de plateforme propre à chaque worker, ainsi qu’une vérification confirmant que l’appelant détient toujours un lease actif sur le worker destinataire.

Ces identifiants sont internes à la manière dont ClickHouse Cloud exécute votre query. Ils ne sont jamais exposés à vos clients et n’ont aucun lien avec la façon dont vous vous authentifiez auprès de ClickHouse : les clients continuent de se connecter avec vos identifiants existants, et les privilèges de query restent régis par le RBAC de votre service.

​

FAQ

On-Demand Compute est-il open source ?

Non. Il s’agit d’une architecture ClickHouse Cloud : ClickHouse server (distributed plan), data plane (pool de workers et leases) et control plane. Le paramètre expérimental make_distributed_plan et le CBO existent dans ClickHouse OSS, mais le pool de workers partagé et l’exécution stateless sont réservés à Cloud.

Ai-je besoin d'une version spécifique pour participer à la private preview ?

Oui. La version utilisée pendant la private preview sera un build personnalisé. Des upgrades supplémentaires pourront être nécessaires au cours de la preview.

À quoi ressemblera le pricing ?

Nous n’avons pas encore de pricing public à communiquer. En revanche, la feature est gratuite pendant la private preview. Cela dit, la philosophie tarifaire sera la même que celle de ClickHouse Cloud : facturer le compute consommé, et non les données scannées ou les lignes lues. Les tarifs exacts seront publiés avant la mise en place du pricing.

Puis-je l'utiliser en production ?

Vous pouvez exécuter de vrais workloads, mais il s’agit d’une private preview : il existe des limitations connues et inconnues, et aucun SLO/SLA ne couvre l’availability du pool de workers.

En quoi cela diffère-t-il de l'autoscaling de mon service ?

L’autoscaling modifie le compute affecté à votre primary service. Pendant la private preview, On-Demand Compute donne aux requêtes SELECT éligibles un accès temporaire à des workers issus d’un pool managé, sans modifier la taille du primary service. L’autoscaling gère la capacité continue du service, tandis qu’On-Demand Compute fournit du compute temporaire pour des workloads spécifiques.

Où puis-je poser des questions ?

Adressez-vous à votre account team ; elle vous mettra en relation avec le product manager d’On-Demand Compute.

Où puis-je signaler des bugs ?

Ouvrez un ticket de Support (sévérité 3) ou signalez-le au product manager. Indiquez le query_id, votre Service ID et l’exception complète.

Un autre ClickHouse Cloud service peut-il atteindre les workers qui exécutent ma requête ?

Non. Tant qu’un worker est en lease pour votre service, la plateforme n’autorise le trafic qu’entre ce worker et votre service, et le bloque pour tous les autres services. Les workers non assignés et les workers en lease pour un autre service n’ont aucun chemin réseau vers le vôtre. Voir Isolation réseau.

Un worker est-il réutilisé par un autre service après la fin de ma requête ?

Non. À la fin d’un lease, le worker est détruit puis remplacé par un nouveau, plutôt que transmis au service suivant.

Est-ce disponible dans ClickHouse BYOC ou ClickHouse Private ?

Non. La private preview n’est pas disponible dans ClickHouse BYOC ni dans ClickHouse Private.