Noções básicas sobre os slots

Um slot do BigQuery é uma CPU virtual usada pelo BigQuery para executar consultas SQL. Durante a execução da consulta, o BigQuery calcula automaticamente quantos slots são necessários, dependendo do tamanho e da complexidade da consulta.

É possível usar um modelo de preços sob demanda ou um modelo de preços com base na capacidade. Ambos usam slots para processamento de dados. Com um modelo baseado em capacidade, você paga por capacidade de processamento de consultas dedicada ou escalonada automaticamente. O modelo baseado em capacidade oferece controle explícito sobre slots e capacidade de análise, enquanto o modelo sob demanda não.

Os clientes no modelo de preços com base na capacidade escolhem explicitamente quantos slots reservar. Suas consultas são executadas dentro dessa capacidade, e você paga por essa capacidade continuamente a cada segundo que ela é implantada. Por exemplo, se você comprar 2.000 slots do BigQuery, suas consultas agregadas serão limitadas a usar 2.000 CPUs virtuais a qualquer momento. Você tem essa capacidade até excluí-la e paga por 2.000 slots até excluí-los.

Os projetos no modelo de preços sob demanda do BigQuery estão sujeitos à cota de slot por projeto com capacidade de burst temporário. A maioria dos usuários no modelo sob demanda considera a capacidade de slot padrão mais do que suficiente. Dependendo da carga de trabalho, o acesso a mais slots melhora o desempenho da consulta. Para verificar quantos slots sua conta usa, confira o monitoramento do BigQuery.

Estimar quantos slots serão comprados

O BigQuery foi projetado para escalonamento linear com recursos aprimorados. Dependendo da carga de trabalho, a capacidade incremental oferecerá benefícios adicionais. Portanto, a escolha do número ideal de slots a serem adquiridos depende dos seus requisitos de desempenho, capacidade e utilidade.

Teste slots de valor de referência e escalonamento automático para determinar a melhor configuração de slots. Por exemplo, você pode testar a carga de trabalho com 500, 1.000, 1.500 e 2.000 slots e observar o impacto no desempenho.

Também é possível examinar o uso atual do slot dos seus projetos com o preço mensal que você escolheu pagar. No momento, cargas de trabalho sob demanda têm um limite de 2.000 slots, mas é importante verificar quantos slots estão sendo usados pelos projetos com visualizações INFORMATION_SCHEMA.JOBS*, o Cloud Logging, a API de jobs ou os registros de auditoria do BigQuery. Para mais informações, consulte Como visualizar os slots disponíveis e os alocados.

Depois de comprar slots e executar as cargas de trabalho por pelo menos sete dias, use o estimador de slot para analisar o desempenho e modelar o efeito de adicionar ou reduzir slots. Para mais informações, consulte Estimar requisitos de capacidade do slot.

Execução de consultas usando slots

Quando o BigQuery executa um job de consulta, ele converte a instrução SQL declarativa em um gráfico de execução desmembrado em uma série de cenários de consulta que, por sua vez, são compostos por conjuntos mais granulares de etapas de execução. O BigQuery aproveita uma arquitetura paralela altamente distribuída para executar essas consultas. Os cenários modelam as unidades de trabalho que muitos workers em potencial podem executar em paralelo. Os estágios se comunicam uns com os outros usando uma arquitetura distribuída de embaralhamento, que é discutida em mais detalhes no Blog do Google Cloud.

A execução da consulta do BigQuery é dinâmica, o que significa que o plano de consulta pode ser modificado enquanto elas estão em andamento. Os cenários que são introduzidos durante a execução de uma consulta costumam ser usados para melhorar a distribuição de dados em todos os workers da consulta.

O BigQuery pode executar vários estágios simultaneamente . O BigQuery pode aproveitar a execução especulativa para acelerar uma consulta, além de poder reparticionar dinamicamente um estágio para atingir o carregamento em paralelo ideal.

Os slots do BigQuery executam unidades de trabalho individuais em cada estágio da consulta. Por exemplo, se o BigQuery determinar que o fator de carregamento em paralelo ideal de um cenário é 10, ele solicitará 10 slots para processar esse cenário.

A consulta do GoogleSQL é um DAG dinâmico

Execução da consulta com economia de recursos de slot

Se uma consulta solicitar mais slots do que o número disponível, o BigQuery coloca unidades de trabalho individuais em fila e espera que os slots fiquem disponíveis. Conforme a execução da consulta avança e libera slots, as unidades de trabalho com filas são selecionadas para execução.

O BigQuery pode solicitar qualquer número de slots para um cenário específico de uma consulta. O número de slots solicitados não está relacionado à quantidade de capacidade adquirida. Ele indica o fator de carregamento em paralelo ideal escolhido pelo BigQuery para cada cenário. As unidades de trabalho são colocadas em fila e executadas conforme os slots ficam disponíveis.

Quando as demandas de consulta excederem os slots confirmados, você não será cobrado por slots adicionais e nem serão cobradas taxas adicionais sob demanda. Suas unidades de trabalho individuais serão enfileiradas.

Por exemplo,

1. Um cenário de consulta solicita 2.000 slots, mas há apenas 1.000 disponíveis.
2. O BigQuery consome todos os 1.000 slots e coloca os outros 1.000 em fila.
3. Na sequência, quando 100 slots terminarem o trabalho, eles selecionarão dinamicamente 100 unidades de trabalho entre as 1.000 unidades de trabalho na fila. 900 unidades de trabalho permanecerão na fila.
4. Posteriormente, quando 500 slots terminarem o trabalho, eles selecionarão dinamicamente 500 unidades de trabalho entre as 900 unidades de trabalho na fila. 400 unidades de trabalho permanecerão na fila.

Os slots do BigQuery são enfileirados quando a demanda excede a disponibilidade

Slots inativos

É possível que alguns slots fiquem inativos a qualquer momento. Isso inclui:

• Compromissos de slots que não estão alocados para nenhum valor de referência.
• Slots que estão alocados para um valor de referência de reserva, mas não estão em uso no momento.

Por padrão, as consultas em execução em uma reserva usam automaticamente slots ociosos de outras reservas no mesmo projeto de administração. O BigQuery aloca imediatamente os slots a uma reserva atribuída quando eles são necessários. Os slots inativos que estavam em uso por outra reserva são rapidamente substituídos. Pode haver um curto período em que o consumo total de slots ultrapassa o máximo especificado em todas as reservas, mas você não vai receber cobranças por esse uso adicional de slots.

Por exemplo, suponha que você tenha a seguinte configuração de reserva:

• project_a é atribuído a reservation_a, que tem 500 slots de valor de referência sem escalonamento automático.
• project_b é atribuído a reservation_b, que tem 100 slots de valor de referência sem escalonamento automático.
• As duas reservas estão no mesmo projeto administrativo e não há outros projetos atribuídos a elas.

Você executa query_b em project_b. Se nenhuma consulta estiver em execução em project_a, query_b terá acesso aos 500 slots inativos de reservation_a. Enquanto query_b ainda estiver em execução, ele poderá usar até 600 slots: 100 slots de valor de referência mais 500 slots inativos.

Enquanto query_b está em execução, suponha que você execute query_a em project_a, que pode usar 500 slots.

• Como você tem 500 slots de valor de referência reservados para project_a, query_a é iniciado imediatamente e recebe 500 slots.
• O número de slots alocados para query_b diminui rapidamente para 100 slots de valor de referência.
• As consultas adicionais executadas em project_b compartilham esses 100 slots. Se as consultas subsequentes não tiverem slots suficientes para iniciar, elas serão enfileiradas até que as consultas em execução sejam concluídas e os slots fiquem disponíveis.

Neste exemplo, se project_b for atribuído a uma reserva sem slots de valor de referência ou escalonamento automático, query_b não terá slots depois que query_a começar a ser executado. O BigQuery pausava query_b até que slots inativos estivessem disponíveis ou a consulta expirasse. Outras consultas em project_b seriam enfileiradas até que slots inativos estivessem disponíveis.

Para garantir que uma reserva use apenas os slots provisionados, defina ignore_idle_slots como true. No entanto, as reservas com ignore_idle_slots definido como true podem compartilhar os slots inativos com outras reservas.

Não é possível compartilhar slots inativos entre as reservas de diferentes edições. É possível compartilhar somente os slots de valor de referência ou slots confirmados. Os slots com escalonamento automático podem estar temporariamente disponíveis, mas não podem ser compartilhados como slots inativos para outras reservas porque podem ser reduzidos.

Enquanto ignore_idle_slots for falso, uma reserva poderá ter uma contagem de slots de 0 e ainda ter acesso a slots não utilizados. Se você usar apenas a reserva default, desative ignore_idle_slots como prática recomendada. Em seguida, é possível atribuir um projeto ou uma pasta a essa reserva, e ela usará apenas slots inativos.

As atribuições do tipo ML_EXTERNAL são uma exceção nos slots usados pelos jobs de criação de modelos externos do BigQuery ML não são preemptivas. Os slots em uma reserva com os tipos de atribuição ML_EXTERNAL e QUERY só estão disponíveis para outros jobs de consulta quando os slots não são ocupados pelos jobs ML_EXTERNAL. Além disso, esses jobs não podem usar slots inativos de outras reservas.

Alocação de slots nas reservas

O BigQuery aloca capacidade de slot em uma única reserva usando um algoritmo chamado programação regular.

O programador do BigQuery impõe o compartilhamento igualitário de slots entre projetos com consultas em execução em uma reserva e, em seguida, nos jobs de um determinado projeto. O programador fornece uma igualdade eventual. Durante períodos curtos, alguns jobs podem receber uma parcela desproporcional de slots, mas o programador corrige isso depois. O objetivo do programador é encontrar um equilíbrio entre a remoção agressiva de tarefas em execução (o que resulta em desperdício de tempo de slot) e ser muito tolerante (o que resulta em jobs com tarefas de longa duração recebendo uma parcela desproporcional o horário do slot).

Se um job importante precisar de mais slots de maneira consistente do que recebe do programador, procure criar uma reserva adicional com um número garantido de slots e atribuir o job a essa reserva.

Uso excessivo de slots

Quando um job retém slots por muito tempo, ele pode receber uma parcela injusta de slots, conforme descrito acima. Para evitar atrasos, outros jobs podem usar slots adicionais, resultando em períodos de uso total de slots acima da capacidade especificada. Qualquer uso excessivo de slots é atribuído apenas aos jobs que recebem mais do que a parte justa.

Os slots em excesso não são cobrados diretamente de você. Em vez disso, os jobs continuam sendo executados e acumulam o uso de slots na cota justa até que todo o uso em excesso seja coberto pela capacidade normal. Os slots em excesso são excluídos do uso de slot informado, exceto algumas estatísticas de execução detalhadas.

Alguns empréstimos preventivos de slots podem ocorrer para reduzir atrasos futuros e oferecer outros benefícios, como a redução da variabilidade de custo de slots e a redução da latência de cauda. O empréstimo de slots é limitado a uma pequena fração da capacidade total de slots.

Programação equitativa no BigQuery

Os slots são distribuídos de forma justa entre os projetos e depois dentro dos jobs do projeto. Isso significa que cada consulta tem acesso igual a todos os slots disponíveis a qualquer momento, e a capacidade é realocada de maneira dinâmica e automática entre as consultas ativas à medida que as demandas de capacidade de cada consulta mudam. As consultas são concluídas e novas consultas são enviadas para execução sob as seguintes condições:

• Sempre que uma nova consulta é enviada, a capacidade é automaticamente realocada entre as consultas em execução. As unidades de trabalho individuais podem ser pausadas, retomadas e enfileiradas sem incidentes à medida que a capacidade disponível aumenta para cada consulta.
• Sempre que uma consulta é concluída, a capacidade consumida por essa consulta fica automaticamente disponível para o uso de todas as outras.
• Sempre que as demandas de capacidade de uma consulta mudam devido a alterações no DAG dinâmico dela, o BigQuery reavalia automaticamente a disponibilidade de capacidade para essa e todas as outras consultas, realocando e pausando os slots conforme necessário.

Programação equitativa no BigQuery

Dependendo da complexidade e do tamanho, uma consulta pode não demandar todos os slots aos quais ela tem direito ou pode exigir mais. Com esse tipo de programação, o BigQuery garante, de modo dinâmico, que todos os slots sejam totalmente utilizados a qualquer momento.