Compute sob demanda do ClickHouse

• Execução de consulta sem estado com On-Demand Compute
• Um novo CBO (cost-based optimizer)
• Uma nova execução de consulta distribuída

​

Quando usar o On-Demand Compute

• Consultas ad hoc e analíticas: execute consultas SELECT de uso intensivo de computação em workers adicionais.
• Workloads de leitura não críticas: tire leituras selecionadas do primary service.
• Consultas em lago de dados: consulte dados compatíveis do Apache Iceberg, Delta Lake ou SharedMergeTree em workers adicionais.
• Compute adicional temporário: solicite workers para consultas elegíveis sem redimensionar o primary service.

​

Como funciona

1. Você envia uma consulta SELECT elegível ao seu ClickHouse Cloud service solicitando um número específico de workers. Seu endpoint, sua authentication e sua configuração de RBAC permanecem inalterados
2. Seu cluster então se conecta ao pool e solicita o número especificado de workers
3. Os workers são leased por uma duração de pelo menos 60 segundos; se a consulta durar mais, o lease é renovado automaticamente
4. Os workers recebem a consulta e a executam
5. A resposta é então enviada de volta ao seu client
6. Os workers são apagados.

​

Usando compute sob demanda

​

Settings

​

Exemplo

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)

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

​

Consultas concorrentes

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

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

​

Quando o pool não consegue atender à requisição

​

Monitoring

​

Número de workers alocados

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

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'

​

Regiões disponíveis

​

Preço

​

Limitações

• Apenas consultas SELECT. Os workers não executam consultas INSERT, mutações, DDL nem background operations.
• Formato com suporte. O private preview oferece suporte a Apache Iceberg, Delta Lake e SharedMergeTree.
• Parallel replicas. As parallel replicas devem estar desabilitadas.
• Tamanho do worker. Cada worker tem 8 vCPUs e 32 GiB de memória.
• Limite de workers. Cada consulta pode solicitar até cinco workers durante o private preview.
• Capacidade do pool. A disponibilidade de workers é de melhor esforço. Uma consulta pode receber menos workers do que solicitou. Se nenhum worker estiver disponível, a consulta falha.
• Desempenho. O desempenho varia conforme a consulta. A atribuição de workers, o planejamento distribuído e a transferência dos estágios do plano podem adicionar latência. Alguns formatos de consulta podem apresentar desempenho inferior ao da execução no primary service (suas consultas típicas de menos de um segundo provavelmente terão desempenho melhor no seu cluster)
• Compatibilidade de consultas. O distributed planner não consegue executar remotamente todos os planos de consulta. Consultas sem suporte podem retornar uma exceção SUPPORT_IS_DISABLED.

​

Roadmap

• Eliminar limitações conhecidas (lacunas de SUPPORT_IS_DISABLED)
• Pools com workers de tamanhos diferentes
• Estabilizar o desempenho de consultas em comparação com a execução stateful
• Suporte a background merge
• Precificação
• Calibração do escalonador automático do pool de workers
• Observabilidade integrada
• Permissões dedicadas para o On-Demand Compute
• Expansão de workloads de Data Lake (escrita, compaction, etc…)

​

Segurança

• Um service por worker: um worker é alocado (lease) a um único service durante toda a duração desse lease. Ele nunca é compartilhado por dois services ao mesmo tempo.
• Sem reutilização entre services: quando o lease termina, o worker é destruído e substituído por um novo. Um worker nunca é reatribuído a outro service.
• Sem dados persistentes: os workers não mantêm armazenamento persistente e não sobrevivem ao término de um lease.
• Mesma region do seu service: os workers são executados na mesma region do service que os aloca, seguindo regras rígidas de residência de dados.
• Seus access controls existentes continuam valendo: IP access lists e private endpoints regem o endpoint do seu service exatamente como antes. O On-Demand Compute não adiciona nenhum endpoint para você configurar ou proteger.
• Sua authentication e RBAC existentes: as consultas são executadas com o mesmo USER e os mesmos privileges de qualquer outra consulta no seu service. Os workers não possuem identity nem modelo de permission próprios.

​

Isolamento de rede

• Somente o seu service consegue alcançar os seus workers. O path existe durante o lease atual do worker e apenas para aquele service.
• Workers não atribuídos são inalcançáveis. Um worker aguardando no pool não tem nenhum path de rede de ou para qualquer service até entrar em lease.
• Workers em lease para services diferentes não conseguem se alcançar. Os workers de um mesmo lease trocam entre si estágios do plano e resultados intermediários. Workers de leases diferentes permanecem isolados uns dos outros, mesmo compartilhando um pool.
• O path é removido junto com o worker. Encerrar um lease destrói o worker, o que elimina a única coisa que o tráfego tinha permissão para alcançar.
• O path de request permanece restrito. Seu service acessa o serviço de assignment de workers para fazer lease e renovar workers. Esse path não transporta dados de consulta e se limita à API de assignment.

​

Authentication e autorização internas

• Uma credential por worker: quando workers são cedidos em lease ao seu service, a plataforma emite um token assinado único para cada um deles. Cada token funciona apenas para aquele worker específico e apenas para o seu service.
• De curta duração e vinculados ao lease: os tokens expiram junto com o lease que os originou. Renovar um lease emite tokens novos e, uma vez encerrado o lease, seus tokens deixam de autenticar qualquer coisa.
• Verificados junto à plataforma: o worker valida o token que lhe é apresentado no serviço de identity da plataforma, em vez de confiar em qualquer informação fornecida na request.

​

FAQ