Entender as reservas

Nesta página, descrevemos como usar as reservas de slots para gerenciar suas cargas de trabalho do BigQuery.

Reservas de slots

No BigQuery, os slots são alocados em pools chamados de reservas. Com as reservas, é possível gerenciar a capacidade e isolar cargas de trabalho de maneiras que façam sentido para sua organização. Por exemplo, é possível criar uma reserva chamada prod para cargas de trabalho de produção e uma reserva separada chamada test para teste, assim, os jobs de teste não competem por recursos com os jobs de produção. Também é possível criar reservas para departamentos diferentes da organização para alocar custos de computação.

As reservas também permitem que os administradores configurem a capacidade de slots com base nas cargas de trabalho atribuídas a eles. Por exemplo, se você tiver cargas de trabalho de nível de produção com restrição de tempo, crie uma reserva com slots de valor de referência adequados. Os slots de valor de referência estão sempre disponíveis e garantem que a reserva tenha capacidade suficiente. No entanto, se você usar reservas de escalonamento automático, a capacidade em uma reserva não será necessariamente reservada. Quando você usa reservas de escalonamento automático, a capacidade é escalonada automaticamente para mais ou para menos com base na demanda. As reservas de escalonamento automático são cobradas por segundo com uma duração mínima de um minuto por padrão. É possível ativar o escalonamento fluido do BigQuery no nível da reserva para faturamento por segundo sem duração mínima. Além disso, os slots inativos podem ser compartilhados entre reservas.

Atribuições de reserva

Para usar os slots alocados em uma reserva, atribua-a a um ou mais projetos, pastas ou organizações. Quando um job em um projeto é executado, ele usa slots da reserva atribuída. Os recursos podem herdar atribuições do pai na Google Cloud hierarquia de recursos. Se um projeto não estiver atribuído a uma reserva, ele vai herdar a atribuição da pasta ou organização pai, se houver.

Os projetos usam a reserva mais específica na hierarquia de recursos a que são atribuídos. Uma atribuição de pasta substitui uma atribuição de organização, e uma atribuição de projeto modifica uma atribuição de pasta.

Se um projeto não tiver uma reserva atribuída ou herdada, o job usará preços sob demanda. Para mais informações sobre como organizar recursos do BigQuery, consulte Introdução à hierarquia de recursos.

Os recursos podem ser atribuídos a None para representar a ausência de uma atividade. Os projetos atribuídos a None sempre usam preços sob demanda. Um caso de uso comum para atribuições None é atribuir uma organização a uma reserva e, em seguida, usar None para remover determinados projetos ou pastas dessa reserva. Para mais informações, consulte Atribuir um projeto a None.

Ao criar uma atribuição, especifique o tipo de job para essa atribuição:

• QUERY: use essa reserva para jobs de consulta não contínuos, incluindo consultas SQL, DDL, DML e BigQuery ML (modelos integrados).

• AUTOMATIC_MATERIALIZED_VIEW_REFRESH: use essa reserva para jobs de atualização automática de visualização materializada.

• BACKGROUND_CHANGE_DATA_CAPTURE: use essa reserva ao optar por usar sua própria reserva para executar os jobs em segundo plano de ingestão de CDC do BigQuery. Reservas BACKGROUND_CHANGE_DATA_CAPTURE não estão disponíveis na edição Standard.

• BACKGROUND_COLUMN_METADATA_INDEX: use essa reserva ao optar por usar sua própria reserva para executar os jobs em segundo plano de armazenamento em cache de metadados do BigLake. Além disso, use essa reserva ao replicar bancos de dados de origem no BigQuery com as operações de aplicação em segundo plano do Datastream. Reservas BACKGROUND_COLUMN_METADATA_INDEX não estão disponíveis na edição Standard.

• BACKGROUND_SEARCH_INDEX_REFRESH: use essa reserva ao optar por usar sua própria reserva para executar os jobs em segundo plano de gerenciamento de índice da Pesquisa do BigQuery. Reservas BACKGROUND_SEARCH_INDEX_REFRESH não estão disponíveis na edição Standard.

• BACKGROUND: use essa reserva ao optar por usar sua própria reserva para replicar bancos de dados de origem no BigQuery com as operações de aplicação em segundo plano do Datastream. Essa reserva também será usada para os jobs descritos por BACKGROUND_CHANGE_DATA_CAPTURE, BACKGROUND_COLUMN_METADATA_INDEX e BACKGROUND_SEARCH_INDEX_REFRESH como substituto se não houver uma reserva mais específica para esses tipos de serviço. Reservas BACKGROUND não estão disponíveis na edição Standard.

• CONTINUOUS: use essa reserva para jobs de consulta contínua.

• ML_EXTERNAL: use essa reserva para consultas CREATE MODEL do BigQuery ML que usam serviços externos ao BigQuery. Para mais informações, consulte Atribuir slots às cargas de trabalho do BigQuery ML. Reservas ML_EXTERNAL não estão disponíveis na edição Standard.

• PIPELINE: use essa reserva para jobs de carregamento e extração.

  Por padrão, os jobs de carregamento e extração são sem custo financeiro e usam um pool compartilhado de slots. O BigQuery não garante a disponibilidade de capacidade para esse pool compartilhado ou a capacidade que você vê. Se você estiver carregando grandes quantidades de dados, seu job poderá aguardar a disponibilidade dos slots.

  Quando os jobs de carregamento e extração são atribuídos a uma reserva, eles perdem o acesso ao pool sem custo financeiro. Monitore a utilização de recursos e os jobs para garantir que as reservas tenham capacidade suficiente para atender aos tempos de duração necessários.

Não é possível alocar slots individuais para atribuições específicas. O programador do BigQuery processa a alocação de slots para jobs usando uma reserva. Para mais informações sobre como os slots são usados, consulte Programação equitativa no BigQuery.

Atribuir reservas de forma flexível

Com o BigQuery, é possível especificar em qual reserva uma consulta deve ser executada durante a execução. Isso dá mais controle sobre a alocação de recursos e evita a criação de projetos desnecessários. Você pode especificar uma reserva no momento da execução usando a CLI, a interface, SQL ou a API, substituindo a atribuição de reserva padrão para seu projeto, pasta ou organização. A reserva atribuída precisa estar na mesma região da consulta que você está executando. Essas atribuições são aceitas em todas as edições.

É preciso ter acesso à reserva para usá-la ao executar a consulta.

Se a edição da reserva atribuída por padrão for Enterprise Plus, ela só poderá ser substituída por uma reserva Enterprise Plus.

Para atribuir reservas de forma flexível, execute uma consulta interativa e especifique a reserva.

Combinar reservas com faturamento sob demanda

É possível usar o faturamento com base em capacidade em uma região e sob demanda em outra. Por padrão, todos os projetos usam o faturamento sob demanda. Em uma região, é possível ativar o faturamento com base em capacidade para um projeto, uma pasta ou uma organização atribuindo-os a uma reserva. Por exemplo, se você adquirir um compromisso de slot na multirregião US e atribuir a organização à reserva padrão, a organização usará o faturamento com base em capacidade na multirregião US, mas permanecerá em faturamento sob demanda em todas as outras regiões.

Dentro de uma região, é possível combinar o faturamento com base em capacidade e sob demanda atribuindo explicitamente os projetos a uma reserva. Qualquer projeto que não esteja atribuído a uma reserva permanecerá no faturamento sob demanda. Também é possível atribuir explicitamente um projeto para usar o faturamento sob demanda atribuindo o ID de reserva none. Isso é útil quando você atribui uma pasta ou organização a uma reserva, mas quer que alguns projetos dentro dessa pasta ou organização usem o faturamento sob demanda. Para mais informações, consulte Atribuir um projeto a "Nenhum".

Projetos com faturamento sob demanda usam uma capacidade separada da capacidade do seu compromisso. Esses projetos não afetam a disponibilidade da capacidade comprometida. Se você consultar dados no buffer de streaming, os jobs on demand não serão cobrados pelos bytes processados do buffer de streaming, mas os jobs executados em uma reserva usarão slots para processar esses bytes.

Como especificar um projeto de administração

Quando você cria compromissos e reservas, eles são associados a um projeto do Google Cloud . Esse projeto gerencia os recursos de reservas do BigQuery e é a principal fonte de faturamento desses recursos. Esse projeto não precisa ser o mesmo que contém seus jobs ou conjuntos de dados do BigQuery.

Como prática recomendada, crie um projeto dedicado para recursos de reservas. Ele é chamado de projeto de administração, porque centraliza o faturamento e o gerenciamento dos compromissos. Dê a este projeto um nome descritivo, como bq-COMPANY_NAME-admin. Em seguida, crie um ou mais projetos separados para armazenar seus jobs do BigQuery.

Apenas projetos no mesmo recurso de Organização que o projeto de administração podem ser atribuídos a uma reserva. Se o projeto de administração não fizer parte de uma Organização, somente ele poderá usar os slots.

O projeto de administração é cobrado pelos slots confirmados. Os projetos que usam esses slots são cobrados pelo armazenamento, mas não pelos slots. É possível comprar mais de um tipo de plano (por exemplo, anual e três anos) e colocar os slots no mesmo projeto de administração.

Observação: depois de criar uma reserva ou um compromisso, não será possível movê-lo para um projeto de administração diferente.

Como prática recomendada, limite o número de projetos de administração. Isso ajuda a simplificar o gerenciamento de faturamento e a alocação de slots. É recomendável um projeto de administração para todas as reservas da sua organização sempre que possível. Organizações complexas podem exigir projetos de administração adicionais para atender requisitos de gerenciamento ou faturamento.

Como usar vários projetos de administração

Em alguns casos, você pode criar mais de um projeto de administração:

• Para separar os custos de várias reservas e compromissos em diferentes unidades organizacionais.
• Para associar um ou mais compromissos de slots a diferentes conjuntos de reservas.

A capacidade de slots inativos não é compartilhada entre reservas em diferentes projetos de administração.

Na página Gerenciamento de carga de trabalho do console do BigQuery Google Cloud , é possível visualizar reservas e compromissos apenas para o projeto administrativo selecionado.

Limites de projetos e políticas de programação

Visualizar

Este recurso está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Para solicitar suporte ou enviar feedback sobre esse recurso, entre em contato com [e-mail].

Os limites de projeto (também conhecidos como políticas de programação) permitem personalizar o comportamento padrão de programação justa definindo limites de uso e simultaneidade para projetos que usam uma reserva. Esses limites impedem que os projetos consumam slots em excesso, mesmo que sejam qualificados para mais capacidade de acordo com a programação justa.

É possível definir limites máximos de projeto como limites padrão no nível da reserva, que se aplicam a qualquer projeto que use essa reserva, a menos que sejam substituídos. Como alternativa, é possível configurar limites de projeto como substituições específicas do projeto para projetos individuais.

Os seguintes tipos de limites de projeto são aceitos:

• Slots máximos:limita o consumo de slots de consultas em execução para o projeto atribuído na reserva. O valor mínimo permitido é 100. Esse não é um limite estrito, mas sim um limite aproximado.

• Simultaneidade máxima:limita o número de consultas simultâneas permitidas para o projeto do cessionário na reserva.

  O limite de simultaneidade é aplicado apenas no momento da admissão da consulta e não faz com que as consultas em execução sejam canceladas. Se você diminuir o limite de simultaneidade abaixo do número atual de consultas em execução, as novas consultas serão colocadas na fila até que um número suficiente de consultas em execução seja concluído.

A alteração dessas configurações tem as seguintes limitações:

• As mudanças levam até um minuto para serem aplicadas.
• Para modificar uma substituição do número máximo de slots por projeto, é necessário iniciar uma nova consulta antes que ela entre em vigor.

Para mais informações sobre como configurar essas políticas, consulte Gerenciar atribuições de carga de trabalho e Gerenciar reservas de carga de trabalho.

Como dimensionar reservas de slots

O BigQuery foi projetado para escalonamento linear com recursos aprimorados. Dependendo da carga de trabalho, a capacidade incremental pode oferecer um desempenho incremental. No entanto, adicionar capacidade também aumenta os custos. Portanto, a escolha do número ideal de slots a serem adquiridos depende dos seus requisitos de desempenho, capacidade e utilidade.

Quando você adiciona slots de referência ou aumenta os limites de escalonamento automático, o programador do BigQuery atribui mais slots a consultas individuais para maximizar o paralelismo. Embora isso reduza o tempo de execução da consulta, a sobrecarga de workers simultâneos pode aumentar o tempo total de slot (total_slot_ms) consumido por uma consulta.

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.

Se a região em que o desempenho é testado tiver slots inativos disponíveis, uma reserva poderá atender ao desempenho com menos slots do que o esperado. Isso ocorre porque a reserva usou os slots inativos para atender aos requisitos de slot da carga de trabalho. Se a disponibilidade de slots inativos diminuir devido a mudanças na carga de trabalho em outras reservas, o desempenho da carga de trabalho poderá ser prejudicado. Portanto, para cargas de trabalho de produção e com prazo determinado, verifique se a reserva é independente em capacidade de slot. Isso impede que as mudanças nos slots inativos afetem diretamente o desempenho do job.

Depois de alocar slots e executar as cargas de trabalho por pelo menos sete dias, use o estimador de slots para analisar o desempenho e modelar o efeito de adicionar ou reduzir slots.

Também é possível examinar o uso atual de slots dos seus projetos com o preço mensal que você escolheu pagar. Cargas de trabalho sob demanda têm um limite flexível de 2.000 slots, mas é importante verificar quantos slots estão sendo usados pelos projetos utilizando visualizações INFORMATION_SCHEMA.JOBS*, o Cloud Logging, a API Jobs ou os registros de auditoria do BigQuery. Para mais informações, consulte Monitorar reservas.

Gerenciar cargas de trabalho usando reservas

É possível usar as reservas do BigQuery para alocar capacidade entre cargas de trabalho, equipes ou departamentos criando outras reservas e atribuindo projetos a elas. Uma reserva é um pool isolado de recursos, com o benefício adicional de poder aproveitar a capacidade ociosa em uma determinada região em toda a organização.

Por exemplo, você pode ter um total de capacidade de compromisso de 1.000 slots e três tipos de cargas de trabalho: ciência de dados ELT e BI.

• É possível criar uma reserva ds com 500 slots e atribuir todos os projetos Google Cloud relevantes à reserva ds.
• É possível criar uma reserva elt com 300 slots e atribuir projetos usados para as cargas de trabalho de ELT à reserva elt.
• É possível criar uma reserva bi com 200 slots e atribuir projetos conectados às ferramentas de BI à reserva bi.

Em vez de particionar a capacidade em tipos de carga de trabalho, é possível criar reservas para equipes ou departamentos individuais. Com o escalonamento automático, é possível isolar cargas de trabalho em várias reservas, oferecendo um gerenciamento mais flexível e granular.

Gerenciar reservas em diferentes regiões

As reservas são recursos regionais. Os slots adquiridos e as reservas criadas em uma região não podem ser usados em outra região. Os projetos, as pastas e as organizações podem ser atribuídos às reservas em uma região e executados sob demanda em outra. Para gerenciar reservas em outra região, mude a região na página Gerenciamento de carga de trabalho do BigQuery:

1. No console do BigQuery, clique em Reservas.
2. Clique no seletor de Local e selecione uma região na qual você queira gerenciar reservas.
3. Depois que uma região for selecionada, será possível comprar slots, criar reservas e atribuir um projeto a uma reserva.

Gerenciar reservas em organizações complexas

As reservas são recursos que podem ser usados em toda a organização. Ao criar reservas, é possível atribuir capacidade a qualquer projeto na mesma organização Google Cloud. A maioria dos usuários do BigQuery usa um único projeto de administração para reservas e compromissos. Esse projeto de administração está associado a uma conta do Cloud Billing, que é cobrada pela capacidade.

No entanto, se você tiver uma organização complexa com várias divisões que gerenciam as próprias faturas, use vários projetos de administração. Os slots inativos só podem ser compartilhados entre reservas criadas no mesmo projeto de administração. É importante conhecer as cotas e os limites para reservas e projetos de administração.

Se você usa várias organizações do Google Cloud , crie pelo menos um projeto de administração para cada uma delas e gerencie as reservas e os compromissos de cada organização no projeto de administração relacionado. Não é possível compartilhar capacidade entre organizações.

Observação: mudar a conta do Cloud Billing vinculada ao projeto não causa inatividade nos compromissos e reservas já existentes. Os slots são vinculados a um projeto ou organização e são independentes da conta do Cloud Billing.

Gerenciar o controle avançado de reservas

As reservas no BigQuery oferecem maior controle sobre como as reservas são usadas e fornecem recursos de segurança adicionais. É possível definir políticas que especificam quais usuários ou grupos podem acessar e usar reservas específicas. Isso garante que os dados e as cargas de trabalho sensíveis sejam isolados e protegidos. Como administrador de reservas, você pode controlar com precisão quais usuários ou contas de serviço (principais) estão autorizados a usar reservas específicas. Para isso, use as condições do IAM aplicadas ao projeto administrativo (onde as reservas são gerenciadas).

Por exemplo, é possível criar uma condição do IAM que conceda a permissão reservations.use a um grupo específico de usuários para todas as reservas com nomes que começam com um determinado prefixo. Isso permite gerenciar o acesso a conjuntos de reservas relacionadas.

Os usuários precisam ter a permissão reservations.use para substituir a reserva padrão do job ou forçar a execução dele sob demanda quando já existe uma atribuição de reserva para o projeto. Os papéis roles/bigquery.resourceAdmin e roles/bigquery.resourceEditor concedem essa permissão. É possível conceder acesso a usuários individuais, grupos ou contas de serviço. Também é possível definir políticas com base em atributos de reservas, como nome, já que as condições do IAM oferecem suporte ao controle de acesso baseado em atributos.

Para conceder condições do IAM em reservas, consulte Controlar o acesso às reservas.

Compromissos de slots

Um compromisso de slots é uma compra de slots por um período especificado. É possível comprar slots em incrementos de 50 slots, até a cota regional de slots. Os compromissos de capacidade são opcionais, mas podem gerar economia de custos para cargas de trabalho estáveis. Os compromissos de slot são usados para cobrir slots de valor de referência nas suas reservas. Qualquer capacidade de slot não utilizada é compartilhada como slots inativos em outras reservas. Os compromissos de slots não se aplicam a slots de escalonamento automático. Para garantir que você receba o preço com desconto para seus slots confirmados, verifique se os compromissos de slot são suficientes para cobrir os slots de base. Não há limite para o número de compromissos que você pode criar. Você recebe cobranças assim que a compra do compromisso é feita. Para informações sobre preços atuais, consulte preços de compromisso de capacidade.

• Compromisso anual. Você compra um compromisso de 365 dias. É possível escolher renovar ou converter para um tipo diferente de plano de compromisso após 365 dias.

• Compromisso de três anos Você compra um compromisso de três anos. É possível escolher renovar ou converter para um tipo diferente de plano de compromisso após 3 anos (1.095 dias).

No final do período de compromisso, ele será renovado com base no plano de renovação selecionado.

Você recebe cobranças mensais por planos de compromisso anuais ou de três anos. No entanto, seu compromisso financeiro é por todo o período e não pode ser cancelado mensalmente. Seu uso é atualizado diariamente no relatório de faturamento, que você pode visualizar a qualquer momento.

Compromissos de slots estão sujeitos à disponibilidade de capacidade. Quando você tenta adquirir compromissos de slots, o sucesso dessa compra não é garantido. No entanto, uma vez que sua compra do compromisso for bem-sucedida, a capacidade estará disponível até que o compromisso expire.

Se você adquirir compromissos de slots antes de criar uma reserva, uma reserva chamada default será criada automaticamente para sua comodidade. A reserva default não tem comportamento especial. É possível criar outras reservas, se necessário, ou usar a reserva padrão.

Recomendamos atribuir um valor de base diferente de zero às suas reservas para ter desempenho e capacidade inicial mais previsíveis. Embora seja possível configurar uma reserva com nenhum slot de base e definir uma capacidade máxima com a intenção de usar recursos de escalonamento automático, a eficácia dessa abordagem depende totalmente de o escalonamento automático estar ativado corretamente e adquirindo slots ativamente. Se o escalonamento automático não estiver funcionando de maneira eficiente para uma reserva de base zero, ele voltará a depender apenas da capacidade de slots ociosos disponível, o que não oferece garantia de desempenho e pode levar a velocidades de consulta imprevisíveis ou reduzidas.

Renovar compromissos

Você seleciona um plano de renovação ao adquirir um compromisso. É possível alterar o plano de renovação de um compromisso a qualquer momento até que ele expire. Os planos de renovação a seguir estão disponíveis:

• Nenhum. Após o término do período do compromisso, ele é removido. As reservas não são afetadas.
• Anual. Após o fim do período do compromisso, ele será renovado por mais um ano.
• Três anos. Após o término do período, o compromisso será renovado por mais três anos.

Para informações sobre como adquirir e renovar compromissos, consulte Criar um compromisso de capacidade.

Por exemplo, se você comprou um compromisso anual às 18h do dia 5 de outubro de 2019, começou a ser cobrado nesse segundo. Seria possível excluir ou renovar o compromisso após as 18h de 4 de outubro de 2020, considerando que 2020 foi um ano bissexto. Você poderia alterar os planos de renovação antes das 18h de 4 de outubro de 2020 da seguinte maneira:

• Se você optar por renovar para um compromisso anual, às 18h do dia 4 de outubro de 2020, seu compromisso será renovado por mais um ano.
• Se você optar por renovar com um compromisso de três anos, às 18h do dia 4 de outubro de 2020, o compromisso será renovado por três anos.

Observação: o processo de renovação pode levar até uma hora após o vencimento do compromisso. Por exemplo, se um compromisso expirar às 18h de 4 de outubro de 2020, o registro do compromisso renovado vai aparecer no sistema entre 18h e 19h do mesmo dia. Não há cobranças sob demanda aplicadas durante esse período de atualização de dados, já que o horário de início efetivo do compromisso criado é 18h.

Expiração do compromisso

Não é possível excluir um compromisso depois de criá-lo. Para excluir um compromisso anual ou de três anos, defina o plano de renovação como NONE. Depois que o compromisso expirar, ele será excluído automaticamente. Para saber mais sobre expiração do compromisso, consulte Expiração do compromisso.

Se você adquiriu um compromisso acidentalmente ou cometeu um erro ao configurá-lo, entre em contato com o Cloud Customer Care para receber ajuda.

Limitações de reserva

• As reservas em uma organização não podem ser compartilhadas com outras organizações.
• É necessário usar reservas e projetos de administração separados para cada organização.
• Cada organização pode ter no máximo 10 projetos de administração com reservas ativas em um único local.
• A capacidade inativa não pode ser compartilhada entre organizações ou entre diferentes projetos de administração em uma única organização.
• A capacidade inativa não pode ser compartilhada entre regiões diferentes.
• Compromissos e reservas são recursos regionais. Compromissos comprados em uma região ou multirregião não podem ser usados para reservas em outras regiões ou multirregiões, mesmo quando o local de região única está localizado no mesmo local que o local multirregional. Por exemplo, não é possível usar um compromisso adquirido na multirregião EU para uma reserva em europe-west4.
• Compromissos e reservas não podem ser movidos de uma região ou multirregião para outra.
• Compromissos comprados em um projeto de administração não podem ser movidos para outro.
• Compromissos comprados com uma edição não podem ser usados com reservas de outra.
• Os slots inativos não são compartilhados entre reservas de diferentes edições.
• Os slots com escalonamento automático não podem ser compartilhados porque reduzir escala vertical de recursos quando não são mais necessários.

Previsibilidade de reservas

Para usar a previsibilidade de reservas, primeiro ative a equitabilidade nas reservas.

Com a previsibilidade de reservas, é possível definir o número máximo absoluto de slots consumidos em uma reserva. O BigQuery oferece slots de referência, slots inativos e slots de escalonamento automático como possíveis recursos de capacidade. Ao criar uma reserva com um tamanho máximo, confirme o número de slots de base e a configuração adequada de escalonamento automático e slots ociosos com base nas suas cargas de trabalho anteriores.

Para ativar a previsibilidade de reservas, defina o valor dos slots máximos e o modo de escalonamento na reserva. O número máximo de slots precisa ser positivo e maior que o número de slots de base atribuídos à reserva. Para saber mais sobre como trabalhar com a previsibilidade de reservas, consulte Criar uma reserva com slots dedicados. Não é possível configurar o valor de autoscale_max_slots ao definir o valor máximo de slots na reserva.

O valor de ignore_idle_slots precisa estar alinhado ao modo de escalonamento. Se o modo de escalonamento for ALL_SLOTS ou IDLE_SLOTS_ONLY, ignore_idle_slots precisará ser "false". Se o modo de escalonamento for AUTOSCALE_ONLY, ignore_idle_slots precisará ser verdadeiro.

É possível configurar as reservas para consumir apenas as seguintes combinações de recursos de capacidade até o máximo definido:

• Slots de base + slots inativos: a capacidade de slots da reserva é maior que zero, e o modo de escalonamento é IDLE_SLOTS_ONLY. A reserva consome o número configurado de slots de base e inativos disponíveis até o número máximo de slots. A reserva pode não atingir o máximo se não houver slots ociosos suficientes disponíveis.

• Slots de base + slots inativos + slots de escalonamento automático: a capacidade de slots da reserva é maior que zero, e o modo de escalonamento é ALL_SLOTS. A reserva primeiro consome o número configurado de slots de base, depois todos os slots inativos disponíveis e, por fim, os slots de escalonamento automático.

• Slots de base + slots de escalonamento automático: a capacidade de slots da reserva é maior que zero, e o modo de escalonamento é AUTOSCALE_ONLY. A reserva primeiro consome os slots de base configurados e depois os de escalonamento automático.

• Slots inativos + slots de escalonamento automático: a capacidade de slots da reserva é zero, e o modo de escalonamento é ALL_SLOTS. A reserva primeiro consome todos os slots inativos disponíveis e depois os de escalonamento automático.

• Slots inativos: a capacidade de slots da reserva é zero, e o modo de escalonamento é IDLE_SLOTS_ONLY. A reserva consome todos os slots inativos disponíveis até o máximo configurado. A reserva pode não atingir o máximo se não houver slots inativos suficientes disponíveis.

O diagrama a seguir mostra as diferentes opções de configuração disponíveis:

No diagrama, as cinco opções de configuração mostram como o BigQuery consome slots até o máximo configurado. As três primeiras opções contêm slots de base, enquanto as outras não têm slots de base configurados.

Limitações

A previsibilidade de reservas está sujeita às seguintes limitações:

• A previsibilidade das reservas só está disponível nas edições Enterprise e Enterprise Plus, a menos que você escolha a opção AUTOSCALE_ONLY.

• A previsibilidade de reservas não é 100% garantida. O uso geral ainda pode exceder o máximo configurado.

A seguir

• Para saber mais sobre como trabalhar com a previsibilidade de reservas, consulte Criar uma reserva com slots dedicados.

Grupos de reserva

Para usar grupos de reserva, primeiro ative a equitabilidade nas reservas.

Os grupos de reserva permitem gerenciar as propriedades de várias reservas, de maneira semelhante à forma como os conjuntos de dados organizam as tabelas.

As reservas com o mesmo grupo de reserva vão compartilhar slots inativos entre si antes de serem disponibilizadas para a organização:

Compartilhamento de slots inativos com grupos de reserva

Os slots inativos são distribuídos de maneira uniforme entre as reservas não agrupadas e os grupos de reservas e, em seguida, de maneira uniforme dentro dos grupos de reservas.

No exemplo a seguir, há três reservas e 1.200 slots ociosos. Sem grupos de reserva, cada reserva tem uma parcela justa de 400 slots inativos. Quando as reservas 1 e 2 são agrupadas, a distribuição de slots inativos muda. Primeiro, os slots inativos são distribuídos igualmente entre o grupo de reservas e a reserva 3 (600 slots inativos para ambos). Em seguida, os 600 slots inativos do grupo de reserva são distribuídos igualmente para as reservas 1 e 2.

Limitações

Os grupos de reserva estão sujeitos às seguintes limitações:

• O compartilhamento de reservas que compartilham um grupo de reservas precisa pertencer ao mesmo projeto e região.

• A imparcialidade baseada em reservas precisa estar ativada no projeto.

• As reservas em um grupo precisam ter a mesma edição.

• Não é possível misturar reservas com e sem configurações de recuperação de desastres gerenciada no mesmo grupo. Todas as reservas no grupo precisam ter a recuperação de desastres configurada ou desativada.

• Se a recuperação de desastres estiver ativada para as reservas em um grupo, todas as reservas precisarão usar o mesmo par de regiões para os locais primário e secundário.

Para saber mais sobre como trabalhar com grupos de reserva, consulte Priorizar slots inativos com grupos de reserva.

Resolver problemas com reservas

Use as informações a seguir para resolver problemas comuns com reservas, como erros ao adicionar slots, por que uma reserva não é usada para um job do BigQuery ou reservas não reconhecidas.

Não é possível adicionar mais slots ao tamanho da reserva

Se você encontrar erros como Failed to allocate slots for reservation in the current system state ou Failed to update reservation: Failed to allocate slots for reservation ao tentar adicionar mais slots à sua reserva, geralmente é um problema temporário. Para reduzir o problema, faça o seguinte:

• Tente novamente com um número menor de slots.
• Se a tentativa com um número menor de slots falhar, aguarde 15 minutos e tente de novo.

Se depois de várias tentativas e 30 minutos de espera você ainda receber o mesmo erro, entre em contato com o Cloud Customer Care.

Não há cota suficiente para concluir esta solicitação

Se a mensagem de erro indicar There is insufficient quota to complete this request, a solicitação excedeu o limite de cota definido para o projeto.

Para resolver esse erro, faça o seguinte:

• Adicione um número menor de slots à reserva para que a solicitação não exceda o limite de cota.
• Solicite um aumento de cota na região correspondente. Para mais informações, consulte Solicitar um aumento de cota.

Reserva não usada pelo BigQuery para executar um job

Há vários cenários em que um job pode ser executado usando preços sob demanda ou um pool de slots compartilhados sem custo financeiro, em vez de usar a reserva que você criou.

A consulta e a reserva estão em regiões diferentes

As reservas são recursos regionais. Uma consulta é executada no mesmo local que as tabelas referenciadas nela.

Se o local de uma tabela não corresponder ao local da reserva, a consulta não usará a reserva e será executada usando preços sob demanda (ou o pool de slots compartilhados sem custo financeiro para jobs de carregamento e exportação em lote qualificados).

Como consultar tabelas do BigQuery Omni

Ao consultar uma tabela do BigQuery Omni, crie a reserva na mesma região da tabela, não em uma região colocada. Se você criar a reserva na região colocalizada do BigQuery, a consulta será executada usando preços sob demanda.

A reserva foi criada, mas o projeto não foi atribuído a ela

Para usar os slots em uma reserva, crie uma atribuição que atribua o projeto, a pasta ou a organização à reserva específica. Verifique se o projeto tem uma atribuição correspondente para a reserva.

Incompatibilidade de tipo de serviço

Selecione o tipo de serviço correto ao criar uma atribuição. Caso contrário, os jobs não vão usar a reserva.

Por exemplo, se você selecionar PIPELINE como o tipo de serviço, todos os jobs de consulta serão executados usando preços on demand. Mude o tipo de atribuição para QUERY para que os jobs de consulta sejam executados usando a reserva.

Consultas de múltiplas instruções

Se você estiver executando consultas de várias instruções, o objeto de job pai não terá uma reserva associada a ele, mesmo que os jobs filhos sejam executados em uma reserva.

Para confirmar se o job realmente usou uma reserva, verifique os metadados do job filho.

Como recuperar resultados armazenados em cache

Quando um job de consulta recupera resultados em cache, o campo de reserva fica vazio porque o BigQuery não realiza cálculos e busca os resultados diretamente da tabela temporária.

Operações de modificação de linha da captura de dados alterados

Se você tiver tabelas de captura de dados alterados (CDC), o BigQuery vai aplicar as modificações de linha pendentes no intervalo max_staleness como jobs em segundo plano que usam o tipo de atribuição BACKGROUND. Se não houver atribuições BACKGROUND, esses jobs vão usar preços sob demanda. Considere criar uma atribuição BACKGROUND para o projeto para evitar custos inesperados sob demanda. É possível identificar esses jobs pela substring queueworker_cdc_background_merge_coalesce no identificador do job.

Tipos de modelo do BigQuery ML que usam serviços externos

Se nenhuma atribuição de reserva com um tipo de serviço ML_EXTERNAL for encontrada no projeto, os jobs de criação de modelos externos serão executados usando preços on demand. A atribuição do tipo de serviço QUERY se aplica a modelos padrão do BigQuery ML e de fatoração de matrizes (que exigem uma reserva da edição Enterprise ou Enterprise Plus), enquanto os modelos externos exigem uma atribuição ML_EXTERNAL. Para mais informações, consulte Atribuir slots às cargas de trabalho do BigQuery.

Reservas não reconhecidas identificadas no projeto

O BigQuery tem reservas que representam um pool de slots compartilhados sem custo financeiro para determinadas operações no BigQuery.

default-pipeline

Por padrão, o carregamento ou a exportação em lote de dados no BigQuery usa um pool de slots compartilhados sem custos financeiros. Ao inspecionar esses jobs de carregamento ou extração, o campo de reserva mostra default-pipeline.

Não há cobranças pelo uso do pool de slots compartilhado. Se você quiser um desempenho consistente e previsível, considere comprar uma reserva de PIPELINE.