Gerenciamento de cargas de trabalho usando 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 maneira adequada para sua organização. Por exemplo, é possível criar uma reserva chamada prod para cargas de trabalho de produção e outra reserva chamada test para teste, assim, os jobs de teste não competem por recursos com jobs de produção. Também é possível criar reservas para departamentos diferentes da organização e alocar custos de computação.

Apesar do nome, a capacidade em uma reserva não é necessariamente reservada. Quando você usa reservas de escalonamento automático, a capacidade é aumentada ou reduzida automaticamente com base na demanda. Além disso, os slots inativos podem ser compartilhados entre reservas.

Atribuições de reservas

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 a hierarquia de recursos, consulte Como organizar recursos do BigQuery.

Os recursos podem ser atribuídos a None para representar a ausência de uma atribuição. 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).

• BACKGROUND_CHANGE_DATA_CAPTURE: use essa reserva ao optar por usar sua própria reserva para executar os jobs em segundo plano de captura de dados alterados BigQuery (CDC). 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 um substituto se não houver uma reserva mais específica para esses tipos de job. 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 gratuitos 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. Nesse caso, talvez você queira comprar slots dedicados e atribuir jobs de PIPELINE a eles. Como prática recomendada, crie outra reserva dedicada com Ignorar slots inativos ativado. Para mais informações sobre slots inativos, consulte Slots inativos.

  Quando os jobs de carregamento e extração são atribuídos a uma reserva, eles perdem o acesso ao pool gratuito. Monitore a utilização de recursos e os jobs para garantir que as reservas tenham capacidade suficiente para ter um desempenho melhor do que usar o pool gratuito.

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.

Você precisa ter acesso à reserva para usá-la ao executar a consulta.

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 modelo 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 um faturamento de taxa fixa para um projeto, uma pasta ou uma organização atribuindo-o 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 do seu compromisso.

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 capacidade do console do BigQuery Google Cloud , é possível visualizar reservas e compromissos apenas para o projeto administrativo selecionado.

Dimensionamento de reservas de slots

O BigQuery foi projetado para escalonamento linear com recursos aprimorados. Dependendo da carga de trabalho, a capacidade incremental vai 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.

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.

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 o BigQuery Reservations 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 da possibilidade de utilização da capacidade inativa em toda a organização.

Por exemplo, você pode ter um compromisso de capacidade total 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 relevantes do Google Cloud à 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 entre tipos de carga de trabalho, é possível criar reservas para equipes ou departamentos individuais.

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, é preciso alterar a região na página Gerenciamento de capacidade 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, talvez seja melhor usar vários projetos de administração. Os slots inativos só podem ser compartilhados entre reservas criadas no mesmo projeto de administração. Você precisa conhecer as cotas e os limites para reservas e projetos de administração.

Se você usa várias organizações 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 mais controle sobre como elas são usadas e fornecem recursos de segurança adicionais. Você pode 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 cujos nomes comecem 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 dos jobs. 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 a 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. Compromissos de capacidade são opcionais, mas podem proporcionar uma economia nos custos para cargas de trabalho estáveis. 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 compromissos 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 consultar 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 de compromissos, consulte Expiração do compromisso.

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

Limitações de reservas

• 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.
• 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á no mesmo lugar 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 reduzem a utilização 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 básicos, ociosos e 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 com o 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 AUTSOCALE_ONLY, ignore_idle_slots precisará ser "true".

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

Resolver problemas com reservas

Esta seção foi criada para ajudar a resolver problemas comuns encontrados ao interagir com reservas, como determinar os motivos de uma reserva não ser usada para um job do BigQuery, identificar reservas desconhecidas ou problemas ao adicionar slots.

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 vagas à sua reserva, geralmente isso é um problema temporário. Para minimizar, faça o seguinte:

• Tentar de novo 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 tentar várias vezes e esperar 30 minutos, você ainda receber o mesmo erro, entre em contato com o suporte do BigQuery.

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

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

Para resolver esse erro, faça uma das seguintes opções:

1. Adicione um número menor de slots à reserva para não exceder o limite de cota.
2. Solicite um aumento de cota na região correspondente. Consulte Como pedir 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 recursos sob demanda ou um pool de slots compartilhado gratuito em vez da reserva criada.

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

As reservas são recursos regionais. A consulta é executada no mesmo local das tabelas referenciadas nela.

Se o local de uma tabela não corresponder ao local da reserva, a consulta será executada usando o pool de slots compartilhados e não usará a reserva.

Como consultar tabelas do BigQuery Omni

Ao consultar uma tabela do BigQuery Omni, verifique se a reserva foi criada na mesma região da tabela, não em uma região colocada. Se você criar a reserva na região do BigQuery colocada, a consulta será executada sob demanda.

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

Para usar os slots comprados, crie uma atribuição que associe o projeto à reserva específica. Verifique se o projeto tem uma atribuição correspondente para a reserva.

Incompatibilidade de tipo de job

Selecione o tipo de job correto ao criar uma atribuição. Caso contrário, os jobs serão executados usando o pool de slots compartilhado.

Por exemplo, se você selecionar PIPELINE como o tipo de job, todos os jobs de consulta serão executados sob demanda. 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 principal não terá uma reserva associada, mesmo que os jobs filhos tenham sido executados em uma reserva.

Para confirmar se o job estava usando uma reserva, consulte os metadados do job filho para esclarecimentos.

Como recuperar resultados armazenados em cache

Quando o job de consulta recupera resultados armazenados em cache, o campo de reserva fica vazio porque nenhum cálculo real é realizado e os resultados são buscados diretamente da tabela temporária.

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

Se você tiver tabelas de captura de dados alterados (CDC), o BigQuery vai aplicar 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 de BACKGROUND, elas usarão os preços sob demanda. Considere criar uma atribuição de BACKGROUND para o projeto e evitar custos altos sob demanda. É possível identificar esses jobs com a substring queueworker_cdc_background_merge_coalesce no identificador.

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

Se nenhuma atribuição de reserva com um tipo de job ML_EXTERNAL for encontrada no projeto, o job de consulta será executado usando preços sob demanda. A atribuição de tipo de job QUERY só pode ser usada para modelos do BigQuery ML que não são externos ou de fatoração de matrizes. Leia a documentação Atribuição de reserva para saber mais.

Reservas não reconhecidas identificadas no projeto

Há reservas de propriedade do BigQuery que representam um pool de slots compartilhados gratuitos usados 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 gratuitos. Se você inspecionar esses jobs de carregamento ou extração, a reserva usada será listada como default-pipeline.

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