Introdução a tabelas externas

Este documento descreve como trabalhar com dados armazenados fora do BigQuery em tabelas externas. Para trabalhar com fontes de dados externas, você também pode usar Conjuntos de dados externos.

As tabelas externas que não são do BigLake permitem consultar dados estruturados em armazenamentos de dados externos. Para consultar uma tabela externa que não seja do BigLake, você precisa ter permissões para a tabela externa e a fonte de dados externa. Por exemplo, para consultar uma tabela externa que não seja do BigLake e que use uma fonte de dados no Cloud Storage, é necessário ter as seguintes permissões:

  • bigquery.tables.getData
  • bigquery.jobs.create
  • storage.buckets.get
  • storage.objects.get

Armazenamentos de dados compatíveis

É possível usar tabelas externas que não sejam do BigLake com os seguintes armazenamentos de dados:

Suporte a tabelas temporárias

É possível consultar uma fonte de dados externa no BigQuery usando uma tabela permanente ou uma temporária. Uma tabela permanente é criada em um conjunto de dados e vinculada à sua fonte de dados externa. Como a tabela é permanente, é possível usar controles de acesso para compartilhá-la com outras pessoas que também têm acesso à fonte de dados externa subjacente e pode consultá-la a qualquer momento.

Ao consultar uma fonte de dados externa usando uma tabela temporária, você envia um comando que inclui uma consulta e cria uma tabela não permanente vinculada a essa fonte. A tabela temporária não é criada em um dos conjuntos de dados do BigQuery. Como ela não fica armazenada de modo permanente em um conjunto de dados, não é possível compartilhá-la com outras pessoas. A consulta a uma fonte de dados externa usando uma tabela temporária é útil quando você quer consultar dados externos apenas uma vez, com um propósito específico, ou executar processos de extração, transformação e carregamento (ETL).

Vários arquivos de origem

Se você criar uma tabela externa que não seja do BigLake com base no Cloud Storage, será possível usar várias fontes de dados externas, desde que essas origens de dados tenham o mesmo esquema. Isso não é compatível com tabelas externas que não sejam do BigLake com base no Bigtable ou no Google Drive.

Limitações

As seguintes limitações se aplicam a tabelas externas:

  • O BigQuery não garante a consistência dos dados para tabelas de dados externas. Alterações nos dados subjacentes durante a execução de uma consulta podem resultar em comportamentos inesperados.
  • O desempenho da consulta em tabelas externas pode ser baixo se comparado ao consultamento de dados em uma tabela padrão do BigQuery. Se a velocidade de consulta for uma prioridade, carregue os dados no BigQuery em vez de configurar uma fonte de dados externa. O desempenho de uma consulta que inclui uma tabela externa depende do tipo de armazenamento externo. Por exemplo, a consulta de dados armazenados no Cloud Storage é mais rápida do que a consulta de dados armazenados no Google Drive. Em geral, o desempenho da consulta em uma tabela externa precisa ser equivalente à leitura dos dados diretamente da fonte.
  • Não é possível modificar tabelas de dados externas com a DML ou outros métodos. Tabelas externas são somente leitura para o BigQuery.
  • Não é possível usar o método de API JSON TableDataList para recuperar dados de tabelas externas. Para mais informações, consulte tabledata.list. Para contornar essa limitação, salve os resultados da consulta em uma tabela de destino. Em seguida, use o método TableDataList na tabela de resultados.
  • Não é possível executar um job do BigQuery que exporte dados a partir de uma tabela externa. Para resolver essa limitação, salve os resultados da consulta em uma tabela de destino. Em seguida, execute um job de exportação na tabela de resultados.
  • Não é possível referenciar uma tabela externa em uma consulta de tabela de caracteres curinga.
  • As tabelas externas não são compatíveis com clustering. Eles são compatíveis com o particionamento de formas limitadas. Para mais detalhes, consulte Como consultar dados particionados externamente.
  • Quando você consulta uma origem de dados externa do Cloud Storage, os resultados não são armazenados em cache. Há suporte para consultas do GoogleSQL no Cloud Storage. Será cobrada cada consulta em uma tabela externa, ainda que a mesma consulta seja enviada diversas vezes. Caso seja necessário enviar repetidamente uma consulta em uma tabela externa que não seja alterada com frequência, convém gravar os resultados da consulta em uma tabela permanente e executar as consultas nessa tabela.
  • O limite é de 16 consultas simultâneas em uma fonte de dados externa do Bigtable.
  • Uma simulação de uma consulta federada que usa uma fonte de dados externa pode relatar um limite inferior de 0 bytes de dados, mesmo que as linhas sejam retornadas. Isso ocorre porque a quantidade de dados processados da tabela externa não pode ser determinada até que a consulta real seja concluída. Executar a consulta federada ainda gera custos para o processamento desses dados.
  • Não é possível usar _object_metadata como nome de coluna em tabelas externas. Ele é reservado para uso interno.
  • O BigQuery não oferece suporte à exibição de estatísticas de armazenamento de tabelas externas.
  • As tabelas externas não são compatíveis com nomes de colunas flexíveis.

Considerações sobre o local

Ao escolher um local para a tabela externa, é necessário considerar o local do conjunto de dados do BigQuery e a origem de dados externa.

Cloud Storage

Ao consultar dados no Cloud Storage usando um BigLake ou uma tabela externa que não é do BigLake, o bucket precisa estar no mesmo local do conjunto de dados do BigQuery que contém a definição da tabela externa. Exemplo:

  • Buckets de região única

    Se o bucket do Cloud Storage estiver na região us-central1 (Iowa), o conjunto de dados do BigQuery precisará estar na região us-central1 (Iowa) ou na multirregião US.

    Se o bucket do Cloud Storage estiver na região europe-west4 (Holanda), o conjunto de dados do BigQuery precisará estar na região europe-west4 (Holanda) ou na multirregião EU.

    Se o bucket do Cloud Storage estiver na região europe-west1 (Bélgica), o conjunto de dados do BigQuery correspondente também precisará estar na região europe-west1 (Bélgica).

  • Buckets birregionais

    Se o bucket do Cloud Storage estiver na região birregional predefinida NAM4 ou em qualquer região birregional configurável que inclua a região us-central1 (Iowa), o conjunto de dados do BigQuery correspondente precisará estar na região us-central1 (Iowa) ou na multirregião US.

    Se o bucket do Cloud Storage estiver na região birregional predefinida EUR4 ou em qualquer região birregional configurável que inclua a região europe-west4 (Holanda), o conjunto de dados do BigQuery correspondente precisará estar na região europe-west4 (Holanda) ou na multirregião EU.

    Se o bucket do Cloud Storage estiver na região dupla predefinida ASIA1, o conjunto de dados do BigQuery correspondente precisará estar na região asia-northeast1 (Tóquio) ou na região asia-northeast2 (Osaka).

    Se o bucket do Cloud Storage usar uma região dupla configurável que inclua as regiões australia-southeast1 (Sydney) e australia-southeast2 (Melbourne), o bucket do BigQuery correspondente precisa estar na região australia-southeast1 (Sydney) ou na região australia-southeast2 (Melbourne).

  • Buckets multirregionais

    O uso de locais de conjuntos de dados multirregionais com buckets multirregionais do Cloud Storage não é recomendado para tabelas externas, porque o desempenho da consulta externa depende da latência mínima e da largura de banda de rede ideal.

    Se o conjunto de dados do BigQuery estiver na multirregião US, o bucket do Cloud Storage correspondente precisará estar na multirregião US, em uma região dupla que inclui us-central1 (Iowa), como a região dupla NAM4 ou em uma região dupla configurável que inclui us-central1.

    Se o conjunto de dados do BigQuery estiver na multirregião EU, o bucket do Cloud Storage correspondente precisará estar na multirregião EU, em uma região dupla que inclui europe-west4 (Holanda), como a região dupla EUR4, ou em uma região dupla configurável que inclui europe-west4.

Para mais informações sobre locais compatíveis do Cloud Storage, consulte Locais de buckets na respectiva documentação.

Bigtable

Quando você consulta dados no Bigtable por uma tabela externa do BigQuery, a instância do Bigtable precisa estar no mesmo local que o conjunto de dados do BigQuery:

  • Região única: se o conjunto de dados do BigQuery estiver na localização regional da Bélgica (europe-west1), a instância correspondente do Bigtable precisará estar na região da Bélgica.
  • Multirregião: como o desempenho da consulta externa depende da latência mínima e da largura de banda de rede ideal, o uso de locais do conjunto de dados multirregional não é recomendado para tabelas externas no Bigtable.

Para mais informações sobre os locais compatíveis com o Bigtable, consulte Locais do Bigtable.

Google Drive

As considerações de local não se aplicam a fontes de dados externas do Google Drive.

Gerenciamento de dados

Desenvolver um plano de gerenciamento de dados:
  • Se você escolher um recurso de armazenamento regional, como um conjunto de dados do BigQuery ou um bucket do Cloud Storage, será necessário desenvolver um plano para gerenciar geograficamente seus dados.

Como mover dados entre locais

Para mover manualmente um conjunto de dados de um local para outro, siga estas etapas:

  1. Exporte os dados das tabelas do BigQuery para um bucket do Cloud Storage no mesmo local que o conjunto de dados ou em um local contido no local do conjunto de dados. Por exemplo, se o conjunto de dados estiver no local multirregional EU, será possível exportar os dados para o local europe-west1 da Bélgica, que faz parte da UE.

    Não há cobrança pela exportação de dados do BigQuery, mas são cobradas taxas pelo armazenamento dos dados exportados no Cloud Storage. As exportações do BigQuery estão sujeitas aos limites de jobs de exportação.

  2. Copie ou mova os dados do bucket do Cloud Storage de exportação para um novo bucket criado no local de destino. Por exemplo, se você estiver movendo os dados da multirregião US para a região asia-northeast1 de Tóquio, será necessário transferi-los para um bucket criado em Tóquio. Para informações sobre como transferir objetos do Cloud Storage, consulte Copiar, renomear e mover objetos na documentação do Cloud Storage.

    A transferência de dados entre regiões gera cobranças de saída de rede no Cloud Storage.

  3. Crie um conjunto de dados do BigQuery no novo local e carregue os dados do bucket do Cloud Storage nele.

    Você não será cobrado pelo carregamento dos dados no BigQuery, mas haverá cobranças pelo armazenamento dos dados no Cloud Storage até que os dados ou o bucket sejam excluídos. Também haverá cobrança pelo armazenamento de dados no BigQuery depois que eles forem carregados. O carregamento de dados no BigQuery está sujeito aos limites de jobs de carregamento.

Também é possível usar o Cloud Composer para mover e copiar grandes conjuntos de dados de maneira programática.

Para mais informações sobre como usar o Cloud Storage para armazenar e mover grandes conjuntos de dados, consulte Como usar o Cloud Storage com Big Data.

Preços

Ao consultar uma tabela externa do BigQuery, você será cobrado pela execução dela e pelos bytes aplicáveis lidos se usar o preço do BigQuery sob demanda (por TiB) ou o consumo de slots se estiver usando o preço de capacidade do BigQuery (por hora de slot).

Se os dados estiverem armazenados em ORC ou Parquet no Cloud Storage, consulte Cálculo do tamanho dos dados.

Você também é cobrado pelo armazenamento dos dados e de qualquer recurso usado pelo aplicativo de origem, sujeito às diretrizes de preços do aplicativo:

  • Para informações sobre preços do Cloud Storage, consulte Preços do Cloud Storage.
  • Para informações sobre os preços do Cloud Bigtable, consulte Preços.
  • Para informações sobre os preços do Drive, consulte Preços.

A seguir