Introdução às tabelas externas

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

As tabelas externas não BigLake permitem-lhe consultar dados estruturados em armazenamentos de dados externos. Para consultar uma tabela externa que não seja do BigLake, tem de ter autorizações para a tabela externa e a origem de dados externa. Por exemplo, para consultar uma tabela externa que não seja do BigLake e que use uma origem de dados no Cloud Storage, tem de ter as seguintes autorizações:

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

Armazenamentos de dados suportados

Pode usar tabelas externas não BigLake com os seguintes repositórios de dados:

Suporte de tabelas temporárias

Pode consultar uma origem de dados externa no BigQuery através de uma tabela permanente ou de uma tabela temporária. Uma tabela permanente é uma tabela criada num conjunto de dados e associada à sua origem de dados externa. Uma vez que a tabela é permanente, pode usar os controlos de acesso para partilhar a tabela com outras pessoas que também tenham acesso à origem de dados externa subjacente, e pode consultar a tabela em qualquer altura.

Quando consulta uma origem de dados externa através de uma tabela temporária, envia um comando que inclui uma consulta e cria uma tabela não permanente associada à origem de dados externa. Quando usa uma tabela temporária, não cria uma tabela num dos seus conjuntos de dados do BigQuery. Uma vez que a tabela não está armazenada permanentemente num conjunto de dados, não pode ser partilhada com outras pessoas. A consulta de uma origem de dados externa através de uma tabela temporária é útil para consultas únicas e ad hoc sobre dados externos ou para processos de extração, transformação e carregamento (ETL).

Vários ficheiros de origem

Se criar uma tabela externa não BigLake baseada no Cloud Storage, pode usar várias origens de dados externas, desde que essas origens de dados tenham o mesmo esquema. Esta opção não é suportada para tabelas externas não baseadas no BigLake baseadas no Bigtable ou no Google Drive.

Limitações

Aplicam-se as seguintes limitações às tabelas externas:

  • O BigQuery não garante a consistência dos dados para tabelas de dados externas. As alterações aos dados subjacentes enquanto uma consulta está em execução podem resultar num comportamento inesperado.
  • O desempenho das consultas para tabelas externas pode ser lento em comparação com a consulta de dados numa tabela padrão do BigQuery. Se a velocidade de consulta for uma prioridade, carregue os dados para o BigQuery em vez de configurar uma origem de dados externa. O desempenho de uma consulta que inclui uma tabela externa depende do tipo de armazenamento externo. Por exemplo, consultar dados armazenados no Cloud Storage é mais rápido do que consultar dados armazenados no Google Drive. Em geral, o desempenho das consultas de uma tabela externa deve ser equivalente à leitura dos dados diretamente da origem de dados.
  • Não pode modificar tabelas de dados externos através de DML ou outros métodos. As tabelas externas são só de leitura para o BigQuery.
  • Não pode usar o método da API JSON TableDataList para obter dados de tabelas externas. Para mais informações, consulte tabledata.list. Para contornar esta limitação, pode guardar os resultados da consulta numa tabela de destino. Em seguida, pode usar o método TableDataList na tabela de resultados.
  • Não pode executar uma tarefa do BigQuery que exporte dados de uma tabela externa. Para contornar esta limitação, pode guardar os resultados da consulta numa tabela de destino. Em seguida, execute uma tarefa de exportação na tabela de resultados.
  • Não pode copiar uma tabela externa.
  • Não pode fazer referência a uma tabela externa numa consulta de tabela com carateres universais.
  • As tabelas externas não suportam o agrupamento. Suportam a partição de formas limitadas. Para ver detalhes, consulte o artigo Consultar dados particionados externamente.
  • Quando consulta uma origem de dados externa que não seja o Cloud Storage, os resultados não são armazenados em cache. (As consultas GoogleSQL no Cloud Storage são suportadas.) Tem de pagar cada consulta a uma tabela externa, mesmo que emita a mesma consulta várias vezes. Se precisar de emitir repetidamente uma consulta contra uma tabela externa que não muda com frequência, considere escrever os resultados da consulta numa tabela permanente e executar as consultas contra a tabela permanente.
  • Tem um limite de 16 consultas simultâneas a uma origem de dados externa do Bigtable.
  • Uma execução de teste de uma consulta federada que usa uma tabela externa pode comunicar um limite inferior de 0 bytes de dados, mesmo que sejam devolvidas linhas. Isto deve-se ao facto de não ser possível determinar a quantidade de dados processados a partir da tabela externa até a consulta real ser concluída. A execução da consulta federada incorre num custo para o processamento destes dados.
  • Não pode usar _object_metadata como nome de coluna em tabelas externas. Está reservado para utilização interna.
  • O BigQuery não suporta a apresentação de estatísticas de armazenamento de tabelas para tabelas externas.
  • As tabelas externas não suportam nomes de colunas flexíveis.
  • O motor de BI não suporta consultas a tabelas externas.
  • O BigQuery não suporta o Data Boost para o Spanner para ler dados do Bigtable a partir do BigQuery.
  • O BigQuery não suporta janelas de retenção de dados de viagem no tempo ou à prova de falhas para tabelas externas. No entanto, para tabelas externas do Apache Iceberg, pode usar a cláusula FOR SYSTEM_TIME AS OF para aceder a instantâneos que são retidos nos metadados do Iceberg.
  • Aplicam-se todas as limitações específicas do formato:

Considerações sobre a localização

Quando escolhe uma localização para a sua tabela externa, tem de ter em consideração a localização do conjunto de dados do BigQuery e a origem de dados externa.

Cloud Storage

Quando consulta dados no Cloud Storage através de uma BigLake ou de uma tabela externa não pertencente ao BigLake, o contentor tem de estar localizado juntamente com o conjunto de dados do BigQuery que contém a definição da tabela externa. Por exemplo:

  • Recipientes de região única

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

    Se o seu contentor do Cloud Storage estiver na região europe-west4 (Países Baixos), o seu conjunto de dados do BigQuery tem de estar na região europe-west4 (Países Baixos) ou na EU multirregião.

    Se o seu contentor do Cloud Storage estiver na região europe-west1 (Bélgica), o conjunto de dados do BigQuery correspondente também tem de estar na região europe-west1 (Bélgica) ou na EU multirregião.

  • Recipientes de duas regiões

    Se o seu contentor do Cloud Storage estiver na NAM4região dupla predefinida ou em qualquer região dupla configurável que inclua a região us-central1 (Iowa), o conjunto de dados do BigQuery correspondente tem de estar na região us-central1 (Iowa) ou na multirregião US.

    Se o seu contentor do Cloud Storage estiver na EUR4região dupla predefinida ou em qualquer região dupla configurável que inclua a região europe-west4 (Países Baixos), o conjunto de dados do BigQuery correspondente tem de estar na região europe-west4 (Países Baixos) ou na multirregião EU.

    Se o seu contentor do Cloud Storage estiver na ASIA1região dupla predefinida, o conjunto de dados do BigQuery correspondente tem de estar na região asia-northeast1 (Tóquio) ou na região asia-northeast2 (Osaka).

    Se o seu contentor do Cloud Storage usar uma região dupla configurável que inclua a região australia-southeast1 (Sydney) e a região australia-southeast2 (Melbourne), o contentor do BigQuery correspondente tem de estar na região australia-southeast1 (Sydney) ou na região australia-southeast2 (Melbourne).

  • Contentores multirregião

    A utilização de localizações de conjuntos de dados multirregionais com contentores do Cloud Storage multirregionais não é recomendada para tabelas externas, uma vez que o desempenho das consultas externas depende de uma latência mínima e de uma largura de banda de rede ideal.

    Se o seu conjunto de dados do BigQuery estiver na US região múltipla, o contentor do Cloud Storage correspondente tem de estar na US região múltipla, na região única us-central1 (Iowa) ou numa região dupla que inclua us-central1 (Iowa), como a região dupla NAM4, ou numa região dupla configurável que inclua us-central1.

    Se o seu conjunto de dados do BigQuery estiver na EU região múltipla, o contentor do Cloud Storage correspondente tem de estar na EU região múltipla, na região única europe-west1 (Bélgica) ou europe-west4 (Países Baixos), ou numa região dupla que inclua europe-west1 (Bélgica) ou europe-west4 (Países Baixos), como a região dupla EUR4, ou numa região dupla configurável que inclua europe-west1 ou europe-west4.

Para mais informações acerca das localizações do Cloud Storage suportadas, consulte o artigo Localizações dos contentores na documentação do Cloud Storage.

Bigtable

Quando consulta dados no Bigtable através de uma tabela externa do BigQuery, a sua instância do Bigtable tem de estar na mesma localização que o seu conjunto de dados do BigQuery:

  • Região única: se o seu conjunto de dados do BigQuery estiver na localização regional da Bélgica (europe-west1), a instância do Bigtable correspondente tem de estar na região da Bélgica.
  • Várias regiões: uma vez que o desempenho das consultas externas depende de uma latência mínima e de uma largura de banda da rede ideal, não é recomendado usar localizações de conjuntos de dados de várias regiões para tabelas externas no Bigtable.

Para mais informações sobre as localizações do Bigtable suportadas, consulte o artigo Localizações do Bigtable.

Google Drive

As considerações de localização não se aplicam às origens de dados externas do Google Drive.

Mover dados entre localizações

Para mover manualmente um conjunto de dados de uma localização para outra, siga estes passos:

  1. Exporte os dados das tabelas do BigQuery para um contentor do Cloud Storage.

    Não existem cobranças pela exportação de dados do BigQuery, mas incorre em cobranças pelo armazenamento dos dados exportados no Cloud Storage. As exportações do BigQuery estão sujeitas aos limites de tarefas de exportação.

  2. Copie ou mova os dados do contentor do Cloud Storage de exportação para um novo contentor que criou na localização de destino. Por exemplo, se estiver a mover os seus dados da região US multi-região para a região asia-northeast1 de Tóquio, transfere os dados para um contentor que criou em Tóquio. Para obter informações sobre a transferência de objetos do Cloud Storage, consulte o artigo Copie, mude o nome e mova objetos na documentação do Cloud Storage.

    A transferência de dados entre regiões incorre em custos de saída da rede no Cloud Storage.

  3. Crie um novo conjunto de dados do BigQuery na nova localização e, em seguida, carregue os seus dados do contentor do Cloud Storage para o novo conjunto de dados.

    Não lhe é cobrado o carregamento dos dados para o BigQuery, mas incorre em custos pelo armazenamento dos dados no Cloud Storage até eliminar os dados ou o contentor. Também lhe é cobrado o armazenamento dos dados no BigQuery depois de carregados. O carregamento de dados no BigQuery está sujeito aos limites de tarefas de carregamento.

Também pode usar o Cloud Composer para mover e copiar grandes conjuntos de dados de forma programática.

Para mais informações sobre a utilização do Cloud Storage para armazenar e mover grandes conjuntos de dados, consulte o artigo Use o Cloud Storage com big data.

Preços

Quando consulta uma tabela externa a partir do BigQuery, são-lhe cobrados os custos de execução da consulta e os bytes lidos aplicáveis se usar os preços do BigQuery a pedido (por TiB) ou o consumo de slots se usar os preços da capacidade do BigQuery (por hora de slot).

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

Também lhe é cobrado o armazenamento dos dados e quaisquer recursos usados pela aplicação de origem, sujeito às diretrizes de preços da aplicação:

  • Para ver informações sobre os preços do Cloud Storage, consulte os preços do Cloud Storage.
  • Para ver informações sobre os preços do Bigtable, consulte a página Preços.
  • Para ver informações sobre os preços do Drive, consulte a secção Preços.

O que se segue?