Compreenda os espaços

Um slot do BigQuery é uma unidade de computação virtual usada pelo BigQuery para executar consultas SQL, código Python 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 cobrados através do modelo a pedido. Com este modelo, é-lhe cobrado o valor dos dados processados (medidos 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 espaços a sua conta usa, consulte o artigo Monitorize o estado de funcionamento, a utilização de recursos e as tarefas.

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. Escolhe explicitamente a quantidade de ranhuras a usar através de uma reserva. Pode especificar o número de espaços numa reserva como um valor de base que é sempre atribuído ou como um valor de dimensionamento automático que é atribuído quando necessário. As reservas com intervalos de dimensionamento automático dimensionam a respetiva capacidade para dar resposta às exigências da sua carga de trabalho. O BigQuery atribui slots à medida que as cargas de trabalho mudam. As reservas com ranhuras de dimensionamento automático só estão disponíveis com as edições do BigQuery. Isto permite-lhe configurar o número de espaços numa reserva com base no desempenho ou na natureza crítica da carga de trabalho que usa a reserva.

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 composto por uma série de fases de consulta. Por sua vez, as fases são compostas por conjuntos de passos de execução. O BigQuery usa uma arquitetura paralela distribuída para executar consultas. As fases modelam as unidades de trabalho que podem ser executadas em paralelo. Os dados são transmitidos entre as fases através de uma arquitetura de aleatorização distribuída, que é abordada mais detalhadamente nesta Google Cloud publicação no blogue.

A execução de consultas do BigQuery é dinâmica. É possível modificar um plano de consulta enquanto a consulta está a ser processada. A distribuição do trabalho pode ser otimizada para a distribuição de dados à medida que são adicionadas fases. Além disso, a capacidade de execução de uma consulta pode mudar à medida que outras consultas são iniciadas ou terminadas, ou à medida que o escalador automático adiciona espaços a uma 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.

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

Se a carga de trabalho exigir mais espaços do que os disponíveis para a reserva, o tempo de execução da tarefa pode aumentar à medida que as tarefas aguardam que os espaços fiquem disponíveis. Este processo é conhecido como concorrência de espaços. A contenção de espaços pode aumentar se a procura de carga de trabalho for muito superior aos espaços disponíveis para a reserva.

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 programador 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 disponível mais capacidade 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, todas as ranhuras podem ser totalmente usadas 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, suponha que tem a seguinte configuração de reserva:

• Reserva A, que tem 1000 espaços 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. Se usar o dimensionamento automático, a soma dos tamanhos máximos das reservas não pode exceder este limite. 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 espaços inativos de outras reservas na mesma região e projeto de administração. O BigQuery atribui imediatamente slots inativos a uma reserva atribuída quando são necessários. Os espaços livres que estavam a ser usados por outra reserva são rapidamente anulados se a reserva original o exigir. Pode haver um curto período em que o consumo total de espaços excede o máximo que especificou em todas as reservas, mas não lhe é cobrado este consumo de espaços adicional.

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

• O project_a é atribuído ao reservation_a, que tem 500 vagas de base sem redimensionamento automático.
• O project_b está atribuído ao reservation_b, que tem 100 espaços de base sem redimensionamento automático.
• Ambas as reservas estão na mesma região e 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 de base reservados para project_a, query_a começa imediatamente e são-lhe atribuídos 500 horários.
• 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 quantidade de horários de 0 e continuar a ter acesso a horários 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 espaços 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

Nota: tem de ativar a equidade baseada 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 intervalos inativos e, em seguida, os respetivos intervalos são distribuídos de forma equitativa nos respetivos 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 espaços livres disponíveis são distribuídos uniformemente pelos projetos nas reservas.

O gráfico seguinte mostra como os espaços disponíveis 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 slots e o desempenho das consultas.

Evite depender apenas de ranhuras inativas para cargas de trabalho de produção com requisitos de tempo rigorosos. Estas tarefas têm de usar ranhuras de base ou com dimensionamento automático. Recomendamos que use ranhuras inativas para tarefas de prioridade inferior, uma vez que as ranhuras podem ser anuladas 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 de slots em excesso é 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 à sua conta. Em vez disso, as tarefas continuam a ser executadas e a acumular a utilização de ranhuras 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, com exceção de 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 de cauda. A utilização de espaços emprestados está limitada a uma pequena fração da sua capacidade total de espaços.