Introdução às tabelas em cluster

As tabelas em cluster no BigQuery são tabelas que têm uma ordem de classificação de colunas definida pelo usuário usando colunas em cluster. As tabelas em cluster podem melhorar o desempenho da consulta e reduzir os custos dela.

No BigQuery, uma coluna em cluster é uma propriedade de tabela definida pelo usuário que classifica blocos de armazenamento com base nos valores nas colunas em cluster. Os blocos de armazenamento são dimensionados de modo adaptável com base no tamanho da tabela. A colocation ocorre no nível dos blocos de armazenamento, e não no nível de linhas individuais. Para mais informações sobre colocation nesse contexto, consulte Clustering.

Uma tabela em cluster mantém as propriedades de classificação no contexto de cada operação que a modifica. As consultas que filtram ou agregam pelas colunas em cluster só verificam os blocos relevantes com base nas colunas em cluster, e não em toda a tabela ou na partição da tabela. Como resultado, talvez o BigQuery não consiga estimar com precisão os bytes a serem processados pela consulta ou os custos dela, mas ele tenta reduzir o total de bytes na execução.

Quando você cria uma tabela em cluster usando várias colunas, a ordem das colunas determina quais colunas têm precedência quando o BigQuery classifica e agrupa os dados em blocos de armazenamento. O exemplo a seguir compara o layout do bloco de armazenamento lógico de uma tabela não em cluster com o layout de tabelas em cluster que têm uma ou várias colunas em cluster:

O BigQuery classifica dados em tabelas em cluster para melhorar o desempenho da consulta.

Ao consultar uma tabela em cluster, você não receberá uma estimativa precisa de custo de consulta antes da execução da consulta porque o número de blocos de armazenamento a serem verificados não é conhecido antes da execução da consulta. O custo final é determinado após a conclusão da execução da consulta e é baseado nos blocos de armazenamento específicos que foram verificados.

Quando usar o clustering

Como o clustering aborda como uma tabela é armazenada, ela costuma ser uma boa opção para melhorar o desempenho da consulta. Portanto, sempre considere o clustering devido às seguintes vantagens:

  • Tabelas não particionadas com mais de 64 MB provavelmente se beneficiarão do clustering. Da mesma forma, partições de tabela com mais de 64 MB também podem se beneficiar do clustering. O clustering de tabelas ou partições menores é possível, mas a melhoria de desempenho geralmente é insignificante.
  • Se as consultas geralmente filtrarem colunas específicas, o clustering acelerará as consultas, porque a consulta apenas verifica os blocos que correspondem ao filtro.
  • Se as consultas filtrarem colunas com muitos valores distintos (alta cardinalidade), o clustering acelerará essas consultas fornecendo ao BigQuery metadados detalhados sobre onde conseguir dados de entrada.
  • O clustering permite que os blocos de armazenamento subjacentes da tabela sejam dimensionados de maneira adaptável com base no tamanho da tabela.

Particione a tabela e o clustering. Nessa abordagem, primeiro você segmenta os dados em partições e, em seguida, agrupa os dados em cada partição pelas colunas de clustering. Considere essa abordagem nas seguintes circunstâncias:

  • É necessário ter uma estimativa rigorosa de custo de consulta antes de executar uma consulta. O custo de consultas em tabelas em cluster só pode ser determinado depois que a consulta é executada. O particionamento fornece estimativas de custo de consulta granulares antes de executar uma consulta.
  • Particionar a tabela resulta em um tamanho médio de partição de pelo menos 10 GB. Criar muitas partições pequenas aumenta os metadados da tabela e pode afetar os tempos de acesso aos metadados ao consultar a tabela.
  • Você precisa atualizar continuamente sua tabela, mas ainda quer aproveitar os preços de armazenamento de longo prazo. O particionamento permite que cada partição seja considerada separadamente para qualificação para preços de longo prazo. Se a tabela não estiver particionada, ela não poderá ser editada por 90 dias consecutivos para ser considerada para os preços de longo prazo.

Para mais informações, consulte Combinar tabelas em cluster e particionadas.

Tipos e ordem das colunas do cluster

Nesta seção, descrevemos os tipos de coluna e como a ordem das colunas funciona no clustering de tabelas.

Tipos de coluna de clusters

As colunas de cluster precisam ser de nível superior, não repetidas e que sejam de um dos seguintes tipos:

  • STRING
  • INT64
  • NUMERIC
  • BIGNUMERIC
  • DATE
  • DATETIME
  • TIMESTAMP
  • BOOL
  • GEOGRAPHY

Para mais informações sobre tipos de dados, consulte Tipos de dados do GoogleSQL.

Ordem das colunas do cluster

A ordem das colunas em cluster afeta o desempenho da consulta. Para aproveitar o clustering, a ordem do filtro de consulta precisa corresponder à ordem das colunas em cluster e precisa incluir pelo menos a primeira coluna em cluster.

No exemplo a seguir, a tabela de pedidos é agrupada usando uma ordem de classificação de colunas de Order_Date, Country e Status. Uma consulta que filtra Order_Date e Country é otimizada para clustering, mas uma consulta que filtra apenas Country e Status não está otimizada. Para otimizar os resultados em clustering, é preciso filtrar das colunas em cluster para começar a partir da primeira coluna em cluster.

As consultas em tabelas em cluster precisam incluir colunas em cluster na ordem inicial.

Remoção de blocos

As tabelas em cluster ajudam a reduzir os custos de consulta removendo dados para que não sejam processados pela consulta. Este processo é chamado de remoção de blocos. O BigQuery classifica os dados em uma tabela em cluster com base nos valores atuais nas colunas em cluster e os organiza em blocos.

Quando você executa uma consulta em uma tabela em cluster e a consulta inclui um filtro nas colunas em cluster, o BigQuery usa a expressão de filtro e os metadados do bloco para remover os blocos verificados pela consulta. Isso permite que o BigQuery verifique apenas os blocos relevantes.

Os blocos removidos não são verificados. Somente os blocos verificados são usados para calcular os bytes de dados processados pela consulta. O número de bytes processados por uma consulta em uma tabela em cluster é igual à soma dos bytes lidos em cada coluna referenciada pela consulta nos blocos verificados.

Se uma tabela em cluster for referenciada várias vezes em uma consulta que usa vários filtros, o BigQuery cobra pela verificação das colunas nos blocos apropriados em cada um dos respectivos filtros. Para conferir um exemplo de como a remoção de blocos funciona, consulte Exemplo.

Combinar tabelas em cluster e particionadas

É possível combinar o clustering de tabelas com o particionamento de tabelas para alcançar uma classificação precisa e otimizar ainda mais a consulta.

Em uma tabela particionada, os dados são armazenados em blocos físicos, cada um contendo uma partição de dados. Cada tabela particionada mantém vários metadados sobre as propriedades de classificação em todas as operações que a modificam. Com os metadados, o BigQuery faz uma estimativa mais precisa dos custos de consulta antes de executá-la. No entanto, o particionamento requer que o BigQuery mantenha mais metadados do que com uma tabela não particionada. À medida que o número de partições aumenta, a quantidade de metadados para manter aumenta.

Ao criar uma tabela em cluster e particionada, é possível alcançar uma classificação mais refinada, como mostra o diagrama a seguir:

Comparar tabelas não agrupadas ou particionadas com tabelas em cluster e particionadas.

Exemplo

Temos uma tabela em cluster chamada ClusteredSalesData. A tabela é particionada na coluna timestamp e agrupada pela coluna customer_id. Os dados são organizados no seguinte conjunto de blocos:

Identificador de partição ID do bloco Valor mínimo para customer_id no bloco Valor máximo para customer_id no bloco
20160501 B1 10000 19999
20160501 B2 20000 24999
20160502 B3 15000 17999
20160501 B4 22000 27999

A consulta a seguir é executada na tabela Ela tem um filtro na coluna customer_id.

SELECT
  SUM(totalSale)
FROM
  `mydataset.ClusteredSalesData`
WHERE
  customer_id BETWEEN 20000
  AND 23000
  AND DATE(timestamp) = "2016-05-01"

A consulta anterior envolve as seguintes etapas:

  • verifica as colunas timestamp, customer_id e totalSale nos blocos B2 e B4;
  • remove o bloco B3 devido ao predicado de filtro DATE(timestamp) = "2016-05-01" na coluna de particionamento timestamp;
  • remove a coluna B1 devido ao predicado de filtro customer_id BETWEEN 20000 AND 23000 na coluna de particionamento customer_id.

Reclustering automático

Conforme os dados são adicionados a uma tabela em cluster, os novos dados são organizados em blocos, o que pode criar novos blocos de armazenamento ou atualizar os blocos existentes. A otimização de bloqueio é necessária para um desempenho ideal de consulta e armazenamento, porque novos dados podem não ser agrupados com dados que tenham os mesmos valores de cluster.

Para manter as características de desempenho de uma tabela em cluster, o BigQuery faz o reclustering automático em segundo plano. Em tabelas particionadas, o clustering é mantido para dados no escopo de cada partição.

Limitações

  • Somente o GoogleSQL é compatível com a consulta de tabelas em cluster e com a gravação de resultados de consulta em tabelas em cluster.
  • É possível especificar até quatro colunas de clustering. Se você precisar de mais colunas, combine o clustering com o particionamento.
  • Ao usar colunas com tipo STRING para clustering, o BigQuery usa apenas os primeiros 1.024 caracteres para agrupar os dados. Os valores nas colunas podem ser maiores que 1.024.
  • Se você alterar uma tabela não em cluster atual para que ela seja agrupada, os dados atuais não serão agrupados automaticamente. Apenas novos dados armazenados usando o colunas clusterizadas estão sujeitas ao reclustering automático. Para mais informações sobre reclustering de dados atuais usando uma instrução UPDATE, consulte Modificar a especificação de clustering.

Cotas e limites da tabela em cluster

O BigQuery restringe o uso de recursos compartilhados do Google Cloud por cotas e limites, incluindo limitações em determinadas operações de tabela ou o número de jobs executados em um dia.

Quando você usa o recurso da tabela em cluster com uma tabela particionada, está sujeito aos limites das tabelas particionadas.

As cotas e limites também se aplicam aos diferentes tipos de jobs que podem ser executados em tabelas em cluster. Para informações sobre as cotas de jobs que se aplicam às tabelas, consulte Jobs em "Cotas e limites".

Preços de tabelas em cluster

Quando você cria e usa tabelas em cluster no BigQuery, as cobranças são baseadas na quantidade de dados armazenados nas tabelas e nas consultas de dados executadas. Para mais informações, consulte Preços de armazenamento e Preços de consulta.

Assim como outras operações de tabela do BigQuery, as operações de tabela em cluster aproveitam as operações gratuitas do BigQuery, como carregamento em lote, cópia da tabela, reclustering automático e exportação de dados. Essas operações estão sujeitas a cotas e limites do BigQuery. Para mais informações sobre operações gratuitas, consulte Operações gratuitas.

Para um exemplo detalhado dos preços da tabela em cluster, consulte Estimativa de custos de armazenamento e consulta.

Segurança de tabelas

Para controlar o acesso a tabelas no BigQuery, consulte Introdução aos controles de acesso a tabelas.

A seguir

  • Para saber como criar e usar tabelas em cluster, consulte esta página.
  • Para mais informações sobre como consultar tabelas em cluster, consulte esta página.