Introdução a tabelas externas

Nesta página, apresentamos as tabelas externas e apresentamos orientações sobre como consultar dados armazenados fora do BigQuery.

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 os dados, pense no seguinte:

Cloud Storage

É possível interagir com os dados do Cloud Storage usando o BigQuery das seguintes maneiras:

Consultar dados do Cloud Storage

Ao consultar dados no Cloud Storage usando uma tabela do BigLake ou uma tabela externa que não é do BigLake, os dados a serem consultados precisam ser colocados juntos com seu conjunto de dados do BigQuery. Exemplo:

  • Bucket de região única: se o conjunto de dados do BigQuery estiver na região de Varsóvia (europe-central2), o bucket do Cloud Storage correspondente também precisará estar nessa região ou em qualquer região birregional do Cloud Storage que inclua a Varsóvia. Se o conjunto de dados do BigQuery estiver na multirregião US, o bucket do Cloud Storage poderá estar na multirregião US, na região única de Iowa (us-central1) ou em qualquer birregional que inclua Iowa. As consultas de qualquer outra região única vão apresentar falha, mesmo que o bucket esteja em um local contido na multirregião do conjunto de dados. Por exemplo, se as tabelas externas estiverem na multirregião US e o bucket do Cloud Storage estiver em Oregon (us-west1), o job vai apresentar falha.

    Se o conjunto de dados do BigQuery estiver na multirregião EU, o bucket do Cloud Storage poderá estar na multirregião EU, na única região da Bélgica (europe-west1) ou em qualquer birregional que inclui a Bélgica. As consultas de qualquer outra região única vão apresentar falha, mesmo que o bucket esteja em um local contido na multirregião do conjunto de dados. Por exemplo, se as tabelas externas estiverem na multirregião EU e o bucket do Cloud Storage estiver na Varsóvia (europe-central2), o job vai apresentar falha.

  • Bucket birregional: se o conjunto de dados do BigQuery estiver na região de Tóquio (asia-northeast1), o bucket do Cloud Storage correspondente precisará estar nessa região ou em uma região birregional que inclua Tóquio, como a região birregional ASIA1.

    Se o bucket do Cloud Storage estiver na birregião NAM4 ou em qualquer birregião que inclua Iowa (us-central1), o conjunto de dados do BigQuery correspondente pode estar em US ou na multirregião de Iowa (us-central1).

    Se o bucket do Cloud Storage estiver na birregião EUR4 ou em qualquer birregião que inclua a Bélgica (europe-west1), o conjunto de dados do BigQuery correspondente poderá estar na multirregião EU ou na Bélgica (europe-west1).

  • Bucket multirregional: usar 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 região multirregional US, o bucket do Cloud Storage correspondente precisará estar na região multirregional US, em uma região birregional que inclui Iowa (us-central1), como NAM4 ou em uma região birregional personalizada que inclui Iowa (us-central1).

    Se o conjunto de dados do BigQuery estiver no formato EU multirregional, o bucket do Cloud Storage correspondente precisará estar na região multirregional EU, em uma região birregional que inclui a Bélgica (europe-west1), como EUR4 ou em uma região birregional personalizada que inclui a Bélgica.

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

Carregar dados do Cloud Storage

Quando você carrega dados do Cloud Storage usando uma tabela externa do BigLake ou que não seja BigLake, os dados carregados precisam ser colocados no mesmo local do conjunto de dados do BigQuery.

  • É possível carregar dados de um bucket do Cloud Storage localizado em qualquer local se o conjunto de dados do BigQuery estiver localizado na multirregião US.

  • Bucket multirregional: se o bucket do Cloud Storage que você quer carregar estiver localizado em um bucket multirregional, o conjunto de dados do BigQuery poderá estar no mesmo bucket multirregional ou qualquer região única que esteja incluída no mesmo bucket multirregional. Por exemplo, se o bucket do Cloud Storage estiver na região EU, o conjunto de dados do BigQuery poderá estar na multirregião EU ou em qualquer região única em EU.

  • Bucket birregional: se o bucket do Cloud Storage que você quer carregar estiver localizado em um bucket birregional, o conjunto de dados do BigQuery poderá estar localizado em regiões incluídas no bucket birregional ou em uma multirregião que inclui a região birregional. Por exemplo, se o bucket do Cloud Storage estiver localizado na região EUR4, seu conjunto de dados do BigQuery poderá estar localizado na Finlândia (europe-north1) em uma região única, nos Países Baixos (europe-west4) uma região única ou na multirregião EU.

  • Bucket de região única: se o bucket do Cloud Storage que você quer carregar estiver em uma única região, o conjunto de dados do BigQuery poderá estar na mesma região única ou no multirregional que inclui a região única. Por exemplo, se o bucket do Cloud Storage estiver na região da Finlândia (europe-north1), o conjunto de dados do BigQuery poderá estar na Finlândia ou na multirregião EU.

  • Uma exceção é que, se o conjunto de dados do BigQuery estiver localizado na região asia-northeast1, o bucket do Cloud Storage poderá estar localizado na multirregião EU.

Para mais informações, consulte Como carregar dados em lote.

Exportar dados para o Cloud Storage

Colocar os buckets do Cloud Storage para exportar dados:
  • Se o conjunto de dados do BigQuery estiver na multirregião EU, o bucket do Cloud Storage que contém os dados exportados precisará estar na mesma multirregião ou em um local contido na multirregião. Por exemplo, se o conjunto de dados do BigQuery estiver na multirregião EU, o bucket do Cloud Storage poderá estar localizado na região Bélgica europe-west1, que está na UE.

    Se seu conjunto de dados estiver na multirregião US, será possível exportar dados para um bucket do Cloud Storage em qualquer local.

  • Se o conjunto de dados estiver em uma região, o bucket do Cloud Storage precisará estar na mesma região. Por exemplo, se o conjunto de dados estiver na região asia-northeast1 de Tóquio, o bucket do Cloud Storage não poderá estar na multirregião ASIA.

Para mais informações, consulte Como exportar dados de tabelas.

Bigtable

Quando você consultar dados no Bigtable por meio de uma tabela externa do BigQuery, a sua instância do Bigtable precisará estar em 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