Compreenda os espaços

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

Embora todas as consultas usem espaços, tem duas opções para a forma como lhe é cobrado o uso: o modelo de preços a pedido ou o modelo de preços baseado na capacidade.

Por predefinição, os custos são calculados com base no modelo a pedido. Com este modelo, é-lhe cobrado o volume de dados processados (medido em TiB) por cada consulta. Os projetos que usam o modelo a pedido estão sujeitos a limites de capacidade por projeto e por organização com capacidade de picos transitórios. A maioria dos utilizadores no modelo a pedido considera os limites de capacidade dos espaços mais do que suficientes. No entanto, consoante a sua carga de trabalho, o acesso a mais espaços pode melhorar o desempenho das consultas. Para verificar quantos slots a sua conta usa, consulte o artigo Monitorização do BigQuery.

Com o modelo baseado na capacidade, paga pela capacidade de slots atribuída às suas consultas ao longo do tempo. Este modelo dá-lhe controlo explícito sobre a capacidade total de espaços, ao contrário do modelo a pedido. Escolhe explicitamente a quantidade de ranhuras a usar através de uma reserva. Pode especificar a quantidade de espaços numa reserva como uma quantidade de base que é sempre atribuída ou como uma quantidade com dimensionamento automático, que é atribuída quando necessário.

Execução de consultas através de espaços

Quando o BigQuery executa uma tarefa de consulta, converte a declaração SQL num plano de execução, dividido numa série de fases de consulta, que, por sua vez, são compostas por conjuntos mais detalhados de passos de execução. O BigQuery usa uma arquitetura paralela fortemente distribuída para executar estas consultas, e as fases modelam as unidades de trabalho que muitos potenciais trabalhadores podem executar em paralelo. Os dados são transmitidos entre as fases através de uma arquitetura de mistura distribuída rápida, que é abordada mais detalhadamente no Google Cloud blogue.

A execução de consultas do BigQuery é dinâmica, o que significa que o plano de consulta pode ser modificado enquanto uma consulta está em curso. As fases introduzidas durante a execução de uma consulta são frequentemente usadas para melhorar a distribuição de dados entre os trabalhadores de consultas. Além disso, a execução de consultas pode ser afetada pela alteração da quantidade de capacidade disponível à medida que outras consultas são concluídas ou começam a ser executadas, ou quando o escalador automático adiciona espaços à reserva.

O BigQuery pode executar várias fases em simultâneo, usar a execução especulativa para acelerar uma consulta e reparticionar dinamicamente uma fase para alcançar uma paralelização ideal.

Os slots do BigQuery executam unidades de trabalho individuais em cada fase da consulta. Por exemplo, se o BigQuery determinar que o fator de paralelização ideal de uma fase é 10, pede 10 slots para processar essa fase.

Gráfico de execução de consultas de fases e passos

Economia de recursos de slots

Se uma consulta necessitar de mais slots do que os que estão disponíveis, o BigQuery coloca em fila de espera as unidades de trabalho individuais e aguarda que os slots fiquem disponíveis. À medida que é feito progresso na execução da consulta e que os slots ficam disponíveis, estas unidades de tarefas em fila de espera são recolhidas dinamicamente para execução.

O BigQuery pode pedir qualquer número de slots para uma fase específica de uma consulta. O número de slots pedidos não está relacionado com a quantidade de capacidade que compra, mas sim com uma indicação do fator de paralelização mais otimizado escolhido pelo BigQuery para essa fase. As unidades de trabalho são colocadas em fila de espera e executadas à medida que os slots ficam disponíveis.

Quando as exigências de consultas excedem os espaços aos quais se comprometeu, não lhe são cobrados espaços adicionais nem tarifas a pedido adicionais. As suas unidades de trabalho individuais são colocadas em fila.

Por exemplo,

1. Uma fase de consulta pede 2000 espaços, mas apenas estão disponíveis 1000.
2. O BigQuery consome todos os 1000 slots e coloca os outros 1000 slots em fila.
3. Posteriormente, se 100 espaços terminarem o respetivo trabalho, selecionam dinamicamente 100 unidades de trabalho das 1000 unidades de trabalho em fila. 900 unidades de trabalho em fila de espera permanecem.
4. Posteriormente, se 500 espaços terminarem o trabalho, selecionam dinamicamente 500 unidades de trabalho das 900 unidades de trabalho em fila. Restam 400 unidades de trabalho em fila.

Slots do BigQuery em fila se a procura exceder a disponibilidade

Agendamento justo no BigQuery

O BigQuery atribui capacidade de slots numa única reserva através de um algoritmo denominado agendamento justo.

O agendador do BigQuery aplica a partilha igual de slots entre projetos com consultas em execução numa reserva e, em seguida, entre tarefas de um determinado projeto. O agendador oferece equidade eventual. Durante períodos curtos, algumas tarefas podem receber uma quota desproporcionada de espaços, mas o agendador acaba por corrigir esta situação. O objetivo do programador é encontrar um equilíbrio entre desalojar agressivamente as tarefas em execução (o que resulta no desperdício de tempo de intervalo) e ser demasiado tolerante (o que resulta em trabalhos com tarefas de execução prolongada a receberem uma quota desproporcionada do tempo de intervalo).

O agendamento justo garante que todas as consultas têm acesso a todas as vagas disponíveis em qualquer altura e que a capacidade é realocada de forma dinâmica e automática entre as consultas ativas à medida que as exigências de capacidade de cada consulta mudam. As consultas são concluídas e são enviadas novas consultas para execução nas seguintes condições:

• Sempre que é enviada uma nova consulta, a capacidade é automaticamente reatribuída às consultas em execução. As unidades de trabalho individuais podem ser pausadas, retomadas e colocadas em fila de forma elegante à medida que fica mais capacidade disponível para cada consulta.
• Sempre que uma consulta é concluída, a capacidade consumida por essa consulta fica automaticamente disponível para utilização imediata por todas as outras consultas.
• Sempre que as exigências de capacidade de uma consulta mudam devido a alterações no DAG dinâmico da consulta, o BigQuery reavalia automaticamente a disponibilidade de capacidade para esta e todas as outras consultas, reatribuindo e pausando as posições, conforme necessário.

Agendamento justo no BigQuery

Consoante a complexidade e o tamanho, uma consulta pode não precisar de todos os espaços aos quais tem direito ou pode precisar de mais. O BigQuery garante dinamicamente que, com um planeamento justo, todos os espaços podem ser totalmente usados em qualquer momento.

Se um trabalho importante precisar sempre de mais espaços do que os que recebe do agendador, considere criar uma reserva adicional com o número necessário de espaços e atribuir o trabalho a essa reserva.

Como exemplo de agendamento justo, suponhamos que tem a seguinte configuração de reserva:

• Reserva A, que tem 1000 vagas de base sem escalabilidade automática
• Projeto A e projeto B, que estão atribuídos à sua reserva

Cenário 1: no projeto A, executa a consulta A (uma consulta simultânea) que requer uma elevada utilização de slots e, no projeto B, executa 20 consultas simultâneas. Embora haja um total de 21 consultas que estão a usar a reserva A, a distribuição de horários disponíveis é a seguinte:

• O projeto A recebe 500 espaços e a consulta A é executada com 500 espaços.
• O projeto B recebe 500 espaços que são partilhados entre as suas 20 consultas.

Cenário 2: no projeto A, executa a consulta A (uma consulta simultânea) que requer 100 espaços para execução e, no projeto B, executa 20 consultas simultâneas. Uma vez que a consulta A não requer 50% da reserva, a distribuição de ranhuras é a seguinte:

• O projeto A recebe 100 espaços e a consulta A é executada com 100 espaços.
• O projeto B recebe 900 vagas que são partilhadas entre as suas 20 consultas.

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

• A reserva B, que tem 1000 espaços de base sem dimensionamento automático.
• 10 projetos, todos atribuídos à reserva B.

Suponha que os 10 projetos estão a executar consultas que têm procura de espaços suficiente. Nesse caso, cada projeto recebe 1/10 do total de espaços de reserva (ou 100 espaços), independentemente do número de consultas que estão a ser executadas em cada projeto.

Quotas e limites de espaços

As quotas e os limites de slots oferecem uma salvaguarda para o BigQuery. Os diferentes modelos de preços usam diferentes tipos de quotas de espaços, da seguinte forma:

• Modelo de preços a pedido: está sujeito a um limite de espaços por projeto e organização com capacidade de picos transitórios. Consoante as suas cargas de trabalho, o acesso a mais espaços pode melhorar o desempenho das consultas.

• Modelo de preços baseado na capacidade: as quotas e os limites de reservas definem o número máximo de horários disponíveis que pode atribuir a todas as reservas numa localização. Só lhe são cobradas as reservas e os compromissos, não as quotas. Para informações sobre como aumentar a quota de espaços, consulte o artigo Pedir um aumento da quota.

Para verificar quantos slots está a usar, consulte o artigo Monitorização do BigQuery.

Espaços inativos

Em qualquer altura, algumas ranhuras podem estar inativas. Isto pode incluir:

• Compromissos de slots que não estão atribuídos a nenhuma base de referência de reserva.
• Slots que estão alocados a uma base de referência de reserva, mas não estão a ser usados.

Os espaços inativos não são aplicáveis quando usa o modelo de preços a pedido.

Por predefinição, as consultas executadas numa reserva usam automaticamente as vagas inativas de outras reservas no mesmo projeto de administração. O BigQuery atribui imediatamente slots a uma reserva atribuída quando são necessários. As ranhuras inativas que estavam a ser usadas por outra reserva são rapidamente preemptivas. Pode haver um curto período em que o consumo total de espaços exceda o máximo especificado em todas as reservas, mas não lhe é cobrado este consumo adicional de espaços.

Por exemplo, suponhamos que tem a seguinte configuração de reserva:

• O project_a está atribuído a reservation_a, que tem 500 vagas de base sem redimensionamento automático.
• project_b está atribuído a reservation_b, que tem 100 espaços base sem escala automática.
• Ambas as reservas estão no mesmo projeto administrativo e não existem outros projetos atribuídos a estas reservas.

Corre query_b em project_b. Se não estiver a ser executada nenhuma consulta em project_a, então query_b tem acesso aos 500 espaços inativos de reservation_a. Enquanto o query_b ainda estiver em execução, pode usar até 600 espaços: 100 espaços de base mais 500 espaços inativos.

Enquanto o query_b está em execução, suponhamos que executa o query_a no project_a que pode usar 500 espaços.

• Uma vez que tem 500 horários disponíveis de base reservados para project_a, query_a começa imediatamente e são-lhe atribuídos 500 horários disponíveis.
• O número de espaços atribuídos a query_b diminui rapidamente para 100 espaços de referência.
• As consultas adicionais executadas em project_b partilham essas 100 posições. Se as consultas subsequentes não tiverem espaços suficientes para começar, são colocadas em fila de espera até que as consultas em execução sejam concluídas e os espaços fiquem disponíveis.

Neste exemplo, se project_b foi atribuído a uma reserva sem intervalos de tempo de base nem escalamento automático, query_b não teria intervalos de tempo após o início da execução de query_a. O BigQuery pausa a consulta query_b até que os slots inativos fiquem disponíveis ou o tempo limite da consulta seja atingido. As consultas adicionais em project_b são colocadas em fila de espera até que estejam disponíveis vagas.

Para garantir que uma reserva usa apenas os respetivos espaços aprovisionados, defina ignore_idle_slots como true. No entanto, as reservas com ignore_idle_slots definido como true podem partilhar os respetivos horários disponíveis com outras reservas.

Não pode partilhar espaços disponíveis entre reservas de diferentes edições. Só pode partilhar os espaços base ou os espaços comprometidos. Os horários com ajuste automático podem estar temporariamente disponíveis, mas não são partilháveis como horários inativos para outras reservas, porque podem ser reduzidos.

Enquanto ignore_idle_slots for falso, uma reserva pode ter uma contagem de horários disponíveis de 0 e continuar a ter acesso a horários disponíveis não usados. Se usar apenas a defaultreserva, desative ignore_idle_slots como prática recomendada. Em seguida, pode atribuir um projeto ou uma pasta a essa reserva, e esta só vai usar espaços disponíveis.

As atribuições do tipo ML_EXTERNAL são uma exceção, uma vez que os slots usados por tarefas de criação de modelos externos do BigQuery ML não são preemptíveis. Os horários disponíveis numa reserva com os tipos de atribuição ML_EXTERNAL e QUERY só estão disponíveis para outros trabalhos de consulta quando não estão ocupados pelos trabalhos ML_EXTERNAL. Além disso, estas tarefas não podem usar espaços livres de outras reservas.

Equidade com base em reservas

Pré-visualização

Este produto ou funcionalidade está sujeito aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. Os produtos e as funcionalidades pré-GA estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

Nota: tem de ativar a equidade com base em reservas antes de poder criar uma reserva previsível.

Com a equidade baseada em reservas, o BigQuery prioriza e atribui slots inativos de forma igual em todas as reservas no mesmo projeto de administrador, independentemente do número de projetos que executam tarefas em cada reserva. Cada reserva recebe uma quota semelhante da capacidade disponível no conjunto de ranhuras inativas e, em seguida, as respetivas ranhuras são distribuídas de forma justa nos seus projetos. Esta funcionalidade só é suportada nas edições Enterprise ou Enterprise Plus.

O gráfico seguinte mostra como os espaços inativos são distribuídos sem a equidade baseada em reservas ativada:

Neste gráfico, os espaços inativos são partilhados igualmente entre os projetos.

Sem a equidade baseada em reservas ativada, os slots inativos disponíveis são distribuídos uniformemente pelos projetos nas reservas.

O gráfico seguinte mostra como os espaços ociosos são distribuídos com a equidade baseada em reservas ativada:

Neste gráfico, os espaços inativos são partilhados igualmente entre as reservas e não entre os projetos.

Com a equidade baseada em reservas ativada, os horários disponíveis inativos são distribuídos igualmente pelas reservas.

Quando ativa a equidade baseada em reservas, reveja o consumo de recursos para gerir a disponibilidade de espaços e o desempenho das consultas.

Evite depender apenas de ranhuras inativas para cargas de trabalho de produção com requisitos de tempo rigorosos. Estes trabalhos devem usar ranhuras de base ou com dimensionamento automático. Recomendamos a utilização de espaços livres para tarefas de prioridade inferior, uma vez que os espaços podem ser anulados em qualquer altura.

Utilização excessiva de slots

Quando uma tarefa retém posições durante demasiado tempo, pode receber uma quota injusta de posições. Para evitar atrasos, o BigQuery permite que outras tarefas peçam emprestados slots adicionais, o que resulta em períodos de utilização total de slots acima da capacidade de slots especificada. A utilização excessiva de ranhuras é atribuída apenas às tarefas que recebem mais do que a sua quota-parte.

Os espaços em excesso não são faturados diretamente. Em alternativa, as tarefas continuam a ser executadas e a acumular a utilização de slots na sua quota-parte até que toda a utilização excessiva seja coberta pela capacidade atribuída. Os espaços em excesso são excluídos da utilização de espaços comunicada, exceto em determinadas estatísticas de execução detalhadas.

Tenha em atenção que pode ocorrer algum empréstimo preventivo de espaços para reduzir atrasos futuros e oferecer outras vantagens, como a redução da variabilidade do custo dos espaços e a redução da latência da cauda. A utilização de espaços emprestados está limitada a uma pequena fração da sua capacidade total de espaços.