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.
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,
- Um cenário de consulta solicita 2.000 slots, mas há apenas 1.000 disponíveis.
- O BigQuery consome todos os 1.000 slots e coloca os outros 1.000 em fila.
- 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.
- 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.
Slots inativos
É possível que alguns slots fiquem inativos a qualquer momento. Isso inclui:
- Compromissos de slots que não estão alocados para nenhuma reserva.
- 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. Isso significa que um job sempre poderá ser executado enquanto houver capacidade. A capacidade inativa é imediatamente preemptiva para a reserva atribuída original conforme necessário, independentemente da prioridade da consulta que precisa dos recursos. Isso acontece automaticamente em tempo real.
Para evitar esse comportamento e garantir que uma reserva utilize 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 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.
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.
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.