Noções básicas sobre os slots

Um slot do BigQuery é uma unidade de computação virtual usada pelo BigQuery para executar consultas SQL ou outros tipos de jobs. Durante a execução de uma consulta, o BigQuery determina automaticamente quantos slots são usados por ela. O número de slots usados depende da quantidade de dados processados, da complexidade da consulta e do número de slots disponíveis. Em geral, o acesso a mais slots permite executar mais consultas simultâneas e consultas complexas podem ser executadas mais rapidamente.

Embora todas as consultas usem slots, você tem duas opções de cobrança pelo uso: o modelo de preços sob demanda ou o modelo de preços com base na capacidade.

Por padrão, a cobrança é feita usando o modelo sob demanda. Com esse modelo, você recebe cobranças pela quantidade de dados processados (medidos em TiB) por cada consulta. Os projetos que usam o modelo sob demanda estão sujeitos a limites de slots por projeto e por organização com capacidade de burst temporário. A maioria dos usuários no modelo sob demanda considera os limites de capacidade de slot mais do que suficientes. No entanto, dependendo da sua carga de trabalho, o acesso a mais slots pode melhorar o desempenho da consulta. Para verificar quantos slots sua conta usa, confira o monitoramento do BigQuery.

Com o modelo baseado em capacidade, você paga pela capacidade de slot alocada para suas consultas ao longo do tempo. Esse modelo oferece controle explícito sobre a capacidade total de slots, enquanto o modelo sob demanda não. Você escolhe explicitamente a quantidade de slots a serem usados por uma reserva. É possível especificar a quantidade de slots em uma reserva como um valor de referência que é sempre alocado ou como um valor com escalonamento automático, que é alocado quando necessário.

Execução de consultas usando slots

Quando o BigQuery executa um job de consulta, ele converte a instrução SQL em um plano de execução, desmembrado em uma série de estágios de consulta, que 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 dados são transmitidos entre estágios usando uma arquitetura distribuída de embaralhamento, que é discutida em mais detalhes no blog doGoogle 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. Além disso, a execução de consultas pode ser afetada pela quantidade variável de capacidade disponível à medida que outras consultas são concluídas ou iniciadas, ou quando slots são adicionados à reserva pelo autoescalador.

O BigQuery pode executar vários estágios simultaneamente, usar a execução especulativa para acelerar uma consulta e 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.

Gráfico de execução de consulta de etapas e fases

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

Programação equitativa no BigQuery

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).

A programação justa garante que cada consulta tenha acesso 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.

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

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

• Reserva A, que tem 1.000 slots de valor de referência sem escalonamento automático
• Projetos A e B, que estão atribuídos à sua reserva

Cenário 1: no projeto A, você executa a consulta A (uma consulta simultânea) que exige alto uso de slots. No projeto B, você executa 20 consultas simultâneas. Embora haja um total de 21 consultas usando a reserva A, a distribuição de slots é a seguinte:

• O projeto A recebe 500 slots, e a consulta A é executada com 500 slots.
• O projeto B recebe 500 slots compartilhados entre as 20 consultas.

Cenário 2: no projeto A, você executa a consulta A (uma consulta simultânea) que requer 100 slots para ser executada, e no projeto B você executa 20 consultas simultâneas. Como a consulta A não exige 50% da reserva, a distribuição de slots é a seguinte:

• O projeto A recebe 100 slots, e a consulta A é executada com 100 slots.
• O projeto B recebe 900 slots compartilhados entre as 20 consultas.

Por outro lado, considere a seguinte configuração de reserva:

• Reserva B, que tem 1.000 slots de valor de referência sem escalonamento automático.
• 10 projetos, todos atribuídos à reserva B.

Suponha que os 10 projetos estejam executando consultas com demanda de slots suficiente. Cada projeto vai receber 1/10 do total de slots de reserva (ou 100 slots), independente de quantas consultas estejam sendo executadas em cada projeto.

Cotas e limites de slots

As cotas e os limites de slots fornecem uma proteção para o BigQuery. Diferentes modelos de preços usam diferentes tipos de cota de slot, como segue:

• Modelo de preços sob demanda: você está sujeito a um limite de slot por projeto e organização com capacidade de burst temporário. Dependendo das suas cargas de trabalho, o acesso a mais slots pode melhorar o desempenho da consulta.

• Modelo de preços baseado em capacidade: as cotas e limites de reserva definem o número máximo de slots que podem ser alocados em todas as reservas em um local. Você só é cobrado por suas reservas e compromissos, não pelas cotas. Para mais informações sobre como aumentar a cota de slots, consulte Como solicitar um aumento de cota.

Para verificar quantos slots você está usando, consulte Monitoramento do BigQuery.

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.

Os slots ociosos não são aplicáveis ao usar o modelo de preços sob demanda.

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 slots para 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 exceda o máximo especificado em todas as reservas, mas você não vai receber cobranças por esse uso adicional.

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 ociosos.

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 começa imediatamente e recebe 500 slots.
• O número de slots alocados para query_b diminui rapidamente para 100 slots de valor de referência.
• Outras consultas executadas em project_b compartilham esses 100 slots. Se as consultas subsequentes não tiverem slots suficientes para serem iniciadas, 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 fosse atribuído a uma reserva sem slots de valor de referência ou escalonamento automático, query_b não teria slots depois que query_a começasse 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 ficassem 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 são compartilháveis 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.

Justiça com base em reserva

Observação: é necessário ativar a equidade baseada em reservas antes de criar uma reserva previsível.

Com a justiça baseada em reserva, o BigQuery prioriza e aloca slots ociosos igualmente em todas as reservas no mesmo projeto administrador, independente do número de projetos que executam jobs em cada reserva. Cada reserva recebe uma parte semelhante da capacidade disponível no pool de slots ociosos, e depois os slots são distribuídos de forma justa entre os projetos. Esse recurso só é compatível com as edições Enterprise ou Enterprise Plus.

O gráfico a seguir mostra como os slots ociosos são distribuídos sem a ativação da justiça baseada em reserva:

Neste gráfico, os slots ociosos são compartilhados igualmente entre os projetos.

Sem a ativação da justiça baseada em reserva, os slots ociosos disponíveis são distribuídos igualmente entre os projetos nas reservas.

O gráfico a seguir mostra como os slots ociosos são distribuídos com a justiça baseada em reserva ativada:

Neste gráfico, os slots inativos são compartilhados igualmente entre as reservas, não entre os projetos.

Com a imparcialidade baseada em reserva ativada, os slots ociosos disponíveis são distribuídos igualmente entre as reservas.

Ao ativar a justiça baseada em reserva, analise o consumo de recursos para gerenciar a disponibilidade de slots e o desempenho das consultas.

Evite depender apenas de slots ociosos para cargas de trabalho de produção com requisitos de tempo estritos. Esses jobs devem usar slots de valor de referência ou com escalonamento automático. Recomendamos usar slots ociosos para jobs de prioridade mais baixa, porque eles podem ser preemptivos a qualquer momento.

Uso excessivo de slots

Quando um job retém slots por muito tempo, ele pode receber uma parcela injusta de slots. Para evitar atrasos, o BigQuery permite que outros jobs peguem emprestado 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 excedentes não são cobrados diretamente de você. Em vez disso, os jobs continuam sendo executados e acumulando o uso de slots na proporção adequada até que todo o uso em excesso seja coberto pela capacidade alocada. Os slots em excesso são excluídos do uso de slots informado, exceto em algumas estatísticas detalhadas de execução.

Vale lembrar que alguns empréstimos preemptivos de slots podem ocorrer para reduzir atrasos futuros e oferecer outros benefícios, como variabilidade reduzida de custo de slot e latência de cauda reduzida. O empréstimo de slots é limitado a uma pequena fração da capacidade total de slots.