Estimar e controlar custos

Nesta página, descrevemos as práticas recomendadas para estimar e controlar custos no BigQuery.

Os principais custos do BigQuery são de computação, usados para processamento de consultas, e de armazenamento, para dados armazenados no BigQuery. O BigQuery oferece dois tipos de modelos de preços para processamento de consultas: sob demanda e com base em capacidade. Cada um deles oferece diferentes práticas recomendadas para controle de custos. Para dados armazenados no BigQuery, os custos dependem do modelo de faturamento de armazenamento configurado para cada conjunto de dados.

Entender os preços de computação do BigQuery

Há diferenças sutis nos preços de computação do BigQuery que afetam o planejamento da capacidade e o controle de custos.

Modelos de preços

Para a computação sob demanda no BigQuery, você recebe cobranças por TiB para consultas do BigQuery.

Como alternativa, para a computação de capacidade no BigQuery, você gera cobranças pelos recursos de computação (slots) usados para processar a consulta. Para usar esse modelo, configure reservas para slots.

As reservas têm os seguintes recursos:

• Eles são alocados em pools de slots e permitem gerenciar a capacidade e isolar cargas de trabalho de maneiras que fazem sentido para sua organização.
• Eles precisam estar em um projeto de administração e estão sujeitos a cotas e limites.

O modelo de preços de capacidade oferece várias edições, que oferecem uma opção de pagamento por uso cobrada em horas de slot. As edições Enterprise e Enterprise Plus também oferecem compromissos de slot opcionais de um ou três anos que podem gerar economia em comparação com a taxa de pagamento por uso.

Você também pode definir reservas de escalonamento automático usando a opção de pagamento por uso. Para ver mais informações, consulte os seguintes tópicos:

• Para comparar modelos de preços, consulte Escolher um modelo.
• Para detalhes sobre preços, consulte Preços de computação sob demanda e Preços de computação de capacidade.

Restringir custos para cada modelo

Ao usar o modelo de preços sob demanda, a única maneira de restringir os custos é configurar cotas diárias no nível do projeto ou do usuário. No entanto, essas cotas impõem um limite máximo que impede os usuários de executar consultas além do limite da cota. Para definir cotas, consulte Criar cotas de consultas personalizadas.

Ao usar o modelo de preços com base em capacidade com reservas de slot, você especifica o número máximo de slots disponíveis para uma reserva. Também é possível comprar compromissos de slots que oferecem preços com desconto por um período determinado.

É possível usar as edições totalmente sob demanda definindo o valor de referência da reserva como 0 e o máximo como uma configuração que atenda às necessidades da sua carga de trabalho. O BigQuery faz o escalonamento automático até o número de slots necessários para sua carga de trabalho, sem exceder o máximo definido. Para mais informações, consulte Gerenciamento de carga de trabalho usando reservas.

Controlar os custos de consulta

Para controlar os custos de consultas individuais, recomendamos que você siga primeiro as práticas recomendadas para otimizar o cálculo de consultas e otimizar o armazenamento.

As seções a seguir descrevem outras práticas recomendadas que podem ser usadas para controlar ainda mais os custos de consulta.

Criar cotas de consultas personalizadas

Prática recomendada:use cotas de consultas diárias personalizadas para limitar a quantidade de dados processados por dia.

Para gerenciar os custos, defina uma cota personalizada que especifique um limite na quantidade de dados processados por dia por projeto ou por usuário. Os usuários não podem executar consultas quando a cota é atingida.

Para definir uma cota personalizada, você precisa de papéis ou permissões específicas. Para definir cotas, consulte Cotas e limites.

Para mais informações, consulte Restringir custos para cada modelo de preços.

Verifique o custo estimado antes de executar uma consulta

Prática recomendada: antes de executar consultas, visualize-as para tentar estimar os custos.

Ao usar o modelo de preços sob demanda, as consultas são cobradas de acordo com o número de bytes lidos. Para estimar custos antes de executar uma consulta:

• Use o validador de consultas no console do Google Cloud .
• Execute uma simulação para consultas.

Usar o validador de consultas

Quando você insere uma consulta no console Google Cloud , o validador de consulta verifica a sintaxe dela e fornece uma estimativa do número de bytes lidos. Esta estimativa pode ser usada para calcular o custo da consulta na calculadora de preços.

• Se a consulta não for válida, o validador de consultas exibirá uma mensagem de erro. Por exemplo:

  Not found: Table myProject:myDataset.myTable was not found in location US

• Se a consulta for válida, o validador de consulta fornecerá uma estimativa do número de bytes necessários para processar a consulta. Exemplo:

  This query will process 623.1 KiB when run.

Executar uma simulação

Para executar uma simulação, faça o seguinte:

bq query \
--use_legacy_sql=false \
--dry_run \
'SELECT
   COUNTRY,
   AIRPORT,
   IATA
 FROM
   `project_id`.dataset.airports
 LIMIT
   1000'
 

Query successfully validated. Assuming the tables are not modified,
running this query will process 10918 bytes of data.

import (
	"context"
	"fmt"
	"io"

	"cloud.google.com/go/bigquery"
)

// queryDryRun demonstrates issuing a dry run query to validate query structure and
// provide an estimate of the bytes scanned.
func queryDryRun(w io.Writer, projectID string) error {
	// projectID := "my-project-id"
	ctx := context.Background()
	client, err := bigquery.NewClient(ctx, projectID)
	if err != nil {
		return fmt.Errorf("bigquery.NewClient: %v", err)
	}
	defer client.Close()

	q := client.Query(`
	SELECT
		name,
		COUNT(*) as name_count
	FROM ` + "`bigquery-public-data.usa_names.usa_1910_2013`" + `
	WHERE state = 'WA'
	GROUP BY name`)
	q.DryRun = true
	// Location must match that of the dataset(s) referenced in the query.
	q.Location = "US"

	job, err := q.Run(ctx)
	if err != nil {
		return err
	}
	// Dry run is not asynchronous, so get the latest status and statistics.
	status := job.LastStatus()
	if err := status.Err(); err != nil {
		return err
	}
	fmt.Fprintf(w, "This query will process %d bytes\n", status.Statistics.TotalBytesProcessed)
	return nil
}

import com.google.cloud.bigquery.BigQuery;
import com.google.cloud.bigquery.BigQueryException;
import com.google.cloud.bigquery.BigQueryOptions;
import com.google.cloud.bigquery.Job;
import com.google.cloud.bigquery.JobInfo;
import com.google.cloud.bigquery.JobStatistics;
import com.google.cloud.bigquery.QueryJobConfiguration;

// Sample to run dry query on the table
public class QueryDryRun {

  public static void runQueryDryRun() {
    String query =
        "SELECT name, COUNT(*) as name_count "
            + "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
            + "WHERE state = 'WA' "
            + "GROUP BY name";
    queryDryRun(query);
  }

  public static void queryDryRun(String query) {
    try {
      // Initialize client that will be used to send requests. This client only needs to be created
      // once, and can be reused for multiple requests.
      BigQuery bigquery = BigQueryOptions.getDefaultInstance().getService();

      QueryJobConfiguration queryConfig =
          QueryJobConfiguration.newBuilder(query).setDryRun(true).setUseQueryCache(false).build();

      Job job = bigquery.create(JobInfo.of(queryConfig));
      JobStatistics.QueryStatistics statistics = job.getStatistics();

      System.out.println(
          "Query dry run performed successfully." + statistics.getTotalBytesProcessed());
    } catch (BigQueryException e) {
      System.out.println("Query not performed \n" + e.toString());
    }
  }
}

// Import the Google Cloud client library
const {BigQuery} = require('@google-cloud/bigquery');
const bigquery = new BigQuery();

async function queryDryRun() {
  // Runs a dry query of the U.S. given names dataset for the state of Texas.

  const query = `SELECT name
    FROM \`bigquery-public-data.usa_names.usa_1910_2013\`
    WHERE state = 'TX'
    LIMIT 100`;

  // For all options, see https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs/query
  const options = {
    query: query,
    // Location must match that of the dataset(s) referenced in the query.
    location: 'US',
    dryRun: true,
  };

  // Run the query as a job
  const [job] = await bigquery.createQueryJob(options);

  // Print the status and statistics
  console.log('Status:');
  console.log(job.metadata.status);
  console.log('\nJob Statistics:');
  console.log(job.metadata.statistics);
}

use Google\Cloud\BigQuery\BigQueryClient;

/** Uncomment and populate these variables in your code */
// $projectId = 'The Google project ID';
// $query = 'SELECT id, view_count FROM `bigquery-public-data.stackoverflow.posts_questions`';

// Construct a BigQuery client object.
$bigQuery = new BigQueryClient([
    'projectId' => $projectId,
]);

// Set job configs
$jobConfig = $bigQuery->query($query);
$jobConfig->useQueryCache(false);
$jobConfig->dryRun(true);

// Extract query results
$queryJob = $bigQuery->startJob($jobConfig);
$info = $queryJob->info();

printf('This query will process %s bytes' . PHP_EOL, $info['statistics']['totalBytesProcessed']);

from google.cloud import bigquery

# Construct a BigQuery client object.
client = bigquery.Client()

job_config = bigquery.QueryJobConfig(dry_run=True, use_query_cache=False)

# Start the query, passing in the extra configuration.
query_job = client.query(
    (
        "SELECT name, COUNT(*) as name_count "
        "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
        "WHERE state = 'WA' "
        "GROUP BY name"
    ),
    job_config=job_config,
)  # Make an API request.

# A dry run query completes immediately.
print("This query will process {} bytes.".format(query_job.total_bytes_processed))

Estimar custos de consulta

Ao usar o modelo de preços sob demanda, é possível estimar o custo de execução de uma consulta calculando o número de bytes processados.

Cálculo do tamanho da consulta sob demanda

Para calcular o número de bytes processados pelos vários tipos de consultas, consulte as seções a seguir:

• Instruções DML
• Instruções DDL
• Tabelas em cluster

Evitar executar consultas para explorar dados de tabelas

Prática recomendada: não faça consultas para explorar ou visualizar dados da tabela.

Se você estiver fazendo testes ou explorando dados, pode usar a opção de visualização da tabela para visualizar dados sem custos financeiros sem afetar suas cotas.

O BigQuery é compatível com as opções de visualização de dados a seguir:

• No console Google Cloud , na página de detalhes da tabela, clique na guia Visualizar para criar amostras dos dados.
• Na ferramenta de linha de comando bq, use o comando bq head e especifique o número de linhas que quer visualizar.
• Na API, use tabledata.list para recuperar os dados da tabela de um conjunto de linhas especificado.
• Evite usar LIMIT em tabelas que não estão em cluster. Para tabelas que não estão em cluster, uma cláusula LIMIT não reduzirá os custos de computação.

Restringir o número de bytes faturados por consulta

Prática recomendada:use a configuração máxima de bytes cobrados para limitar os custos de consulta ao usar o modelo de preços sob demanda.

Você pode limitar o número de bytes cobrados para uma consulta usando a configuração máxima de bytes cobrados. Quando você define o máximo de bytes cobrados, o número de bytes lidos pela consulta é estimado antes da execução da consulta. Se o número de bytes estimados estiver além do limite, a consulta falhará sem gerar cobranças.

Para tabelas em cluster, a estimativa do número de bytes cobrados para uma consulta é um limite superior e pode ser maior que o número real de bytes cobrados depois de executar a consulta. Em alguns casos, se você definir o máximo de bytes cobrados, uma consulta em uma tabela em cluster poderá falhar, mesmo que os bytes reais faturados não excedam a configuração máxima de bytes cobrados.

Se uma consulta falhar devido à configuração máxima de bytes faturados, um erro semelhante a este será retornado:

Error: Query exceeded limit for bytes billed: 1000000. 10485760 or higher required.

Para definir o máximo de bytes cobrados:

  bq query --maximum_bytes_billed=1000000 \
  --use_legacy_sql=false \
  'SELECT
     word
   FROM
     `bigquery-public-data`.samples.shakespeare'

Evite usar LIMIT em tabelas não em cluster

Prática recomendada: para tabelas não em cluster, não use uma cláusula LIMIT como método de controle de custos.

Para tabelas não em cluster, aplicar uma cláusula LIMIT a uma consulta não afeta a quantidade de dados lidos. Você é cobrado pela leitura de todos os bytes em toda a tabela conforme indicado pela consulta, mesmo que ela retorne apenas um subconjunto. Com uma tabela em cluster, uma cláusula LIMIT pode reduzir o número de bytes verificados, porque a verificação é interrompida quando blocos suficientes são verificados para conseguir o resultado. Você receberá cobranças apenas pelos bytes verificados.

Materializar os resultados da consulta em etapas

Prática recomendada: se possível, materialize os resultados da consulta em etapas.

Se você criar uma consulta grande e de vários estágios, cada vez que você a executar, o BigQuery lerá todos os dados exigidos por ela. A cobrança será realizada com base em todos os dados lidos sempre que a consulta for executada.

Em vez disso, divida sua consulta em etapas de modo que cada uma materialize os resultados da consulta, gravando-os em uma tabela de destino. Consultar a tabela de destino menor reduz a quantidade de dados lidos e reduz os custos. O custo de armazenamento de resultados materializados é muito inferior ao custo do processamento de grandes quantidades de dados.

Controlar os custos da carga de trabalho

Nesta seção, descrevemos as práticas recomendadas para controlar custos em uma carga de trabalho. Uma carga de trabalho é um conjunto de consultas relacionadas. Por exemplo, uma carga de trabalho pode ser um pipeline de transformação de dados que é executado diariamente, um conjunto de painéis de controle executados por um grupo de analistas de negócios ou várias consultas ad hoc executadas por um conjunto de cientistas de dados.

Use a Google Cloud calculadora de preços

Prática recomendada:use a calculadora de preços doGoogle Cloud para criar uma estimativa de custo mensal geral para o BigQuery com base na projeção de uso. Em seguida, compare essa estimativa com seus custos reais para identificar áreas de otimização.

Usar reservas e compromissos

Prática recomendada:use reservas e compromissos do BigQuery para controlar custos.

Para mais informações, consulte Restringir custos para cada modelo de preços.

Usar o estimador de slots

Prática recomendada:use o Estimador de slot para estimar o número de slots necessários para suas cargas de trabalho.

O estimador de slot do BigQuery ajuda a gerenciar a capacidade do slot com base em métricas de desempenho histórico.

Além disso, os clientes que usam o modelo de preços sob demanda podem conferir recomendações de dimensionamento para compromissos e reservas de escalonamento automático com performance semelhante ao migrar para o preço baseado em capacidade.

Cancele jobs de longa duração desnecessários

Para liberar capacidade, verifique os jobs de longa duração e confira se eles precisam continuar sendo executados. Caso contrário, cancele as assinaturas.

Conferir custos usando um painel

Prática recomendada:crie um painel para analisar os dados do Cloud Billing e monitore e faça ajustes no uso do BigQuery.

É possível exportar seus dados de faturamento para o BigQuery e visualizá-los em uma ferramenta como o Looker Studio. Para ver um tutorial sobre como criar um painel de faturamento, consulte Visualizar o faturamento do Google Cloud usando o BigQuery e o Looker Studio.

Usar orçamentos e alertas de faturamento

Prática recomendada:use os orçamentos do Cloud Billing para monitorar as cobranças do BigQuery em um só lugar.

Com os orçamentos do Cloud Billing, é possível acompanhar os custos reais em relação aos custos planejados. Depois de definir um valor de orçamento, defina regras de limite de alerta de orçamento que serão usadas para acionar notificações por e-mail. Os e-mails de alerta de orçamento ajudam você a acompanhar os gastos do BigQuery em relação ao orçamento.

Controlar os custos de armazenamento

Use estas práticas recomendadas para otimizar o custo do armazenamento do BigQuery. Também é possível otimizar o armazenamento para melhorar o desempenho das consultas.

Usar armazenamento de longo prazo

Prática recomendada:use os preços de armazenamento de longo prazo para reduzir o custo de dados mais antigos.

Quando você carrega dados no armazenamento do BigQuery, eles estão sujeitos aos Preços de armazenamento do BigQuery. Para dados mais antigos, aproveite automaticamente os preços de armazenamento em longo prazo do BigQuery.

Se você tem uma tabela que não é modificada por 90 dias consecutivos, o preço do armazenamento dessa tabela diminui automaticamente em 50%. Se você tiver uma tabela particionada, cada partição será considerada separadamente para qualificação para preços de longo prazo sujeitos às mesmas regras das tabelas não particionadas.

Configurar o modelo de faturamento do armazenamento

Prática recomendada: otimize o modelo de faturamento do armazenamento com base nos padrões de uso.

O BigQuery oferece suporte ao faturamento de armazenamento usando ou bytes físicos (compactados) ou lógicos (não compactados) ou uma combinação dos dois. O modelo de faturamento do armazenamento configurado para cada conjunto de dados determina o preço do armazenamento, mas não afeta o desempenho das consultas.

É possível usar as visualizações INFORMATION_SCHEMA para determinar o modelo de faturamento do armazenamento que funcione melhor com base nos seus padrões de uso.

Evitar a substituição de tabelas

Prática recomendada:ao usar o modelo de faturamento do armazenamento físico, evite substituir tabelas repetidamente.

Quando você substitui uma tabela, por exemplo, usando o parâmetro --replace em jobs de carregamento em lote ou a instrução SQL TRUNCATE TABLE, os dados substituídos são mantidos durante os períodos de viagem no tempo e de segurança. Se você substituir uma tabela com frequência, vai gerar cobranças extras de armazenamento.

Em vez disso, é possível carregar dados incrementalmente em uma tabela usando o parâmetro WRITE_APPEND em jobs de carregamento, a instrução SQL MERGE ou a API de gravação do Storage.

Reduzir a janela de viagem no tempo

Prática recomendada:com base nos seus requisitos, você pode reduzir a janela de viagem no tempo.

Reduzir a janela de viagem no tempo do valor padrão de sete dias reduz o período de armazenamento dos dados excluídos ou alterados em uma tabela. Você é cobrado pelo armazenamento de viagem no tempo somente quando usar a versão física (compactada) do modelo de faturamento do armazenamento.

A janela de viagem no tempo é definida no nível do conjunto de dados. Também é possível definir a janela de tempo padrão para novos conjuntos de dados usando as configurações.

Usar a validade da tabela para tabelas de destino

Prática recomendada: se você estiver gravando grandes resultados de consulta em uma tabela de destino, use o prazo de validade padrão da tabela para remover os dados quando não forem mais necessários.

Manter grandes conjuntos de resultados armazenados no BigQuery gera um custo. Se você não precisa de acesso permanente aos resultados, use a expiração padrão da tabela para excluir os dados automaticamente para você.

Arquivar dados para o Cloud Storage

Prática recomendada: arquive dados no Cloud Storage.

Mova os dados do BigQuery para o Cloud Storage com base na necessidade comercial de arquivamento. Como prática recomendada, considere os preços de armazenamento de longo prazo e o modelo de faturamento de armazenamento físico antes de exportar dados do BigQuery.

Como resolver discrepâncias de custo e cobranças inesperadas do BigQuery

Siga estas etapas para resolver problemas de cobranças inesperadas ou discrepâncias de custo do BigQuery:

1. Para entender de onde vêm as cobranças do BigQuery ao analisar o relatório do Cloud Billing, a primeira recomendação é agrupar as cobranças por SKU. Assim, é mais fácil observar o uso e as cobranças dos serviços correspondentes do BigQuery.

2. Depois disso, estude os preços das SKUs correspondentes na página de documentação de SKUs ou na página Pricing na interface do Cloud Billing para entender qual recurso é, por exemplo, API BigQuery Storage Read, armazenamento de longo prazo, preços sob demanda, edição Standard.

3. Depois de identificar as SKUs correspondentes, use as visualizações INFORMATION_SCHEMA para identificar os recursos específicos associados a essas cobranças. Por exemplo:

   • Se você receber cobranças pela análise sob demanda, confira os exemplos de visualização INFORMATION_SCHEMA.JOBS para determinar os jobs que geram custos e os usuários que os iniciaram.
   • Se você receber cobranças por SKUs de reserva ou compromisso, consulte as visualizações correspondentes INFORMATION_SCHEMA.RESERVATIONS e INFORMATION_SCHEMA.CAPACITY_COMMITMENTS para identificar as reservas e os compromissos que estão sendo cobrados.
   • Se as cobranças forem de SKUs de armazenamento, consulte os exemplos de visualização INFORMATION_SCHEMA.TABLE_STORAGE para entender quais conjuntos de dados e tabelas estão gerando mais custos.

Considerações importantes sobre a solução de problemas:

• Considere que um período diário no relatório do Cloud Billing começa à meia-noite no horário do Pacífico dos EUA e do Canadá (UTC-8) e observa as mudanças do horário de verão nos Estados Unidos. Ajuste seus cálculos e agregações de dados para corresponder aos mesmos períodos.

• Filtre por projeto se houver vários projetos anexados à conta de faturamento e você quiser analisar as cobranças de um projeto específico.

• Selecione a região correta ao fazer investigações.

Cobranças inesperadas relacionadas a consultas, reservas e compromissos

A solução de problemas de cobranças inesperadas relacionadas à execução de jobs depende da origem delas:

• Se você notar um aumento nos custos de análise sob demanda, isso pode estar relacionado a um aumento no número de jobs iniciados ou à mudança na quantidade de dados que precisam ser processados por jobs. Investigue isso usando a visualização INFORMATION_SCHEMA.JOBS.
• Se houver um aumento nas cobranças por slots comprometidos, investigue isso consultando INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES para saber se novos compromissos foram comprados ou modificados.
• Para aumentos nas cobranças originadas do uso de reservas, analise as mudanças nas reservas registradas em INFORMATION_SCHEMA.RESERVATION_CHANGES. Para corresponder o uso da reserva de escalonamento automático aos dados de faturamento, siga o exemplo de escalonamento automático.

Horas de slot faturadas maiores do que as horas de slot calculadas pela visualização INFORMATION_SCHEMA.JOBS

Ao usar uma reserva de escalonamento automático, o faturamento é calculado de acordo com o número de slots escalonados, não o número de slots usados. O BigQuery faz o escalonamento automático em múltiplos de 50 slots, o que leva ao faturamento do múltiplo mais próximo, mesmo que menos do que a quantidade escalonada automaticamente seja usada. O escalonador automático tem um período mínimo de um minuto antes da redução da escala, o que significa que pelo menos um minuto será cobrado, mesmo que a consulta tenha usado os slots por menos tempo, por exemplo, por apenas 10 segundos do minuto. A maneira correta de estimar as cobranças de uma reserva de escalonamento automático está documentada na página de escalonamento automático de slots. Para mais informações sobre como usar o escalonamento automático de maneira eficiente, consulte as práticas recomendadas de escalonamento automático.

Um cenário semelhante será observado para reservas sem escalonamento automático: o faturamento é calculado de acordo com o número de slots provisionados, não o número de slots usados. Se você quiser estimar as cobranças de uma reserva sem escalonamento automático, consulte diretamente a visualização RESERVATIONS_TIMELINE.

O faturamento é menor que o total de bytes faturados calculado por INFORMATION_SCHEMA.JOBS para projetos que executam consultas sob demanda

Há vários motivos para o faturamento real ser menor que os bytes processados calculados:

• Cada projeto recebe 1 TB de consultas do nível gratuito por mês sem custo extra.
• Os jobs do tipo SCRIPT não foram excluídos do cálculo, o que pode levar à contagem dupla de alguns valores.
• Diferentes tipos de economia aplicados à sua conta do Cloud Billing, como descontos negociados, créditos promocionais e outros. Confira a seção "Economias" do relatório do Cloud Billing. O 1 TB de consultas por mês do nível gratuito também está incluído aqui.

O faturamento é maior do que os bytes processados calculados usando INFORMATION_SCHEMA.JOBS para projetos que executam consultas sob demanda

Se o valor de faturamento for maior do que o valor calculado ao consultar a visualização INFORMATION_SCHEMA.JOBS, isso pode ter sido causado por algumas condições:

• Consultas em tabelas com segurança no nível da linha

  • As consultas em tabelas com segurança no nível da linha não produzem um valor para total_bytes_billed na visualização INFORMATION_SCHEMA.JOBS. Portanto, o faturamento calculado usando total_bytes_billed na visualização INFORMATION_SCHEMA.JOBS será menor do que o valor faturado. Consulte a página Práticas recomendadas de segurança no nível da linha para mais detalhes sobre por que essas informações não estão visíveis.

• Como realizar operações de ML no BigQuery

  • Os preços do BigQuery ML para consultas sob demanda dependem do tipo de modelo que está sendo criado. Algumas dessas operações de modelo são cobradas a uma taxa mais alta do que as consultas não relacionadas a ML. Portanto, se você apenas somar todos os total_billed_bytes do projeto e usar a taxa padrão de preços sob demanda por TB, não terá uma agregação de preços correta. É preciso considerar a diferença de preços por TB.

• Valores de preços incorretos

  • Confirme se os valores corretos de preço por TB estão sendo usados nos cálculos. Escolha a região certa, já que os preços dependem da localização. Consulte a documentação de preços.

A recomendação geral é seguir a maneira recomendada de calcular o uso de jobs sob demanda para faturamento na nossa documentação pública.

Cobrança pelo uso da API BigQuery Reservations mesmo que ela esteja desativada e sem reservas ou compromissos usados

Inspecione a SKU para entender melhor quais serviços são cobrados. Se a SKU faturada for BigQuery Governance SKU, as cobranças serão do Dataplex Universal Catalog. Algumas funcionalidades do Dataplex Universal Catalog acionam a execução de jobs usando o BigQuery. Essas cobranças agora são processadas na SKU correspondente da API BigQuery Reservations. Consulte a documentação Preços do Dataplex Universal Catalog para mais detalhes.

O projeto está atribuído a uma reserva, mas ainda há custos sob demanda da análise do BigQuery

Leia a seção Resolver problemas com reservas para identificar a origem das cobranças de Analysis.

Cobranças inesperadas por slots de pagamento por uso (PAYG) da edição Standard do BigQuery

No relatório do Cloud Billing, aplique um filtro com o rótulo goog-bq-feature-type e o valor BQ_STUDIO_NOTEBOOK. O uso que você vai ver é medido como slots de pagamento conforme o uso na edição Standard do BigQuery. Essas são cobranças pelo uso do notebook do BigQuery Studio. Leia mais sobre os preços dos notebooks do BigQuery Studio.

Cobranças da API BigQuery Reservations que aparecem depois que a API Reservation é desativada

Desativar o BigQuery não interrompe as cobranças de compromisso. Para interromper as cobranças de compromisso, exclua um compromisso. Defina o plano de renovação como NONE, e o compromisso será excluído automaticamente quando expirar.

Cobranças inesperadas de armazenamento

Cenários que podem levar a aumentos na cobrança de armazenamento:

• Aumentos na quantidade de dados armazenados nas suas tabelas. Use a visualização INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE para monitorar a mudança em bytes das suas tabelas.
• Mudar os modelos de faturamento de conjuntos de dados
• Aumentar a janela de viagem no tempo para conjuntos de dados do modelo de faturamento físico
• Modificação de tabelas com dados no armazenamento de longo prazo, fazendo com que elas se tornem armazenamento ativo

A exclusão de tabelas ou conjuntos de dados resultou em custos de armazenamento mais altos do BigQuery

O recurso de viagem no tempo do BigQuery retém os dados excluídos durante a janela de viagem no tempo configurada e mais sete dias para recuperação à prova de falhas. Durante esse período, os dados excluídos nos conjuntos de dados do modelo de faturamento de armazenamento físico contribuem para o custo ativo de armazenamento físico, mesmo que as tabelas não apareçam mais no INFORMATION_SCHEMA.TABLE_STORAGE ou no console. Se os dados da tabela estavam no armazenamento de longo prazo, a exclusão faz com que eles sejam movidos para o armazenamento físico ativo. Isso faz com que o custo correspondente aumente, porque os bytes físicos ativos são cobrados aproximadamente duas vezes mais do que os bytes físicos de longo prazo, de acordo com a página de preços do armazenamento do BigQuery. A abordagem recomendada para minimizar os custos causados pela exclusão de dados em conjuntos de dados do modelo de faturamento de armazenamento físico é reduzir a janela de viagem no tempo para dois dias.

Custos de armazenamento reduzidos sem modificações nos dados

No BigQuery, os usuários pagam pelo armazenamento ativo e de longo prazo. As cobranças de armazenamento ativo incluem qualquer tabela ou partição de tabela que não tenha sido modificada por 90 dias consecutivos, enquanto as cobranças de armazenamento de longo prazo incluem tabelas e partições que não foram modificadas por 90 dias consecutivos. A redução geral do custo de armazenamento pode ser observada quando os dados fazem a transição para o armazenamento de longo prazo, que é cerca de 50% mais barato do que o armazenamento ativo. Leia sobre os preços de armazenamento para mais detalhes.

Os cálculos de armazenamento do INFORMATION_SCHEMA não correspondem ao faturamento

• Use a visualização INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE em vez de INFORMATION_SCHEMA.TABLE_STORAGE. A TABLE_STORAGE_USAGE_TIMELINE fornece dados mais precisos e granulares para calcular corretamente os custos de armazenamento.
• As consultas executadas nas visualizações INFORMATION_SCHEMA não incluem tributos, ajustes e erros de arredondamento. Considere isso ao comparar os dados. Leia mais sobre relatórios no Cloud Billing nesta página.
• Os dados apresentados nas visualizações do INFORMATION_SCHEMA estão em UTC, enquanto os dados do relatório de faturamento são informados no horário do Pacífico dos EUA e do Canadá (UTC-8).

A seguir

• Saiba mais sobre o preço do BigQuery.
• Saiba como otimizar consultas.
• Saiba como otimizar o armazenamento.

• Para saber mais sobre faturamento, alertas e visualização de dados, consulte os seguintes tópicos:

  • Criar, editar ou excluir orçamentos e alertas de orçamento
  • Exportar dados do Cloud Billing para o BigQuery
  • Visualizar os custos com o Looker Studio