Introdução às transferências do Cloud Storage

O Serviço de transferência de dados do BigQuery para o Cloud Storage permite-lhe agendar carregamentos de dados recorrentes de contentores do Cloud Storage para o BigQuery. O caminho para os dados armazenados no Cloud Storage e a tabela de destino podem ser ambos parametrizados, o que lhe permite carregar dados de contentores do Cloud Storage organizados por data.

Formatos de ficheiros suportados

Atualmente, o Serviço de transferência de dados do BigQuery suporta o carregamento de dados do Cloud Storage num dos seguintes formatos:

  • Valores separados por vírgulas (.csv)
  • JSON (delimitado por newline)
  • Avro
  • Parquet
  • ORC

Tipos de compressão suportados

O Serviço de transferência de dados do BigQuery para o Cloud Storage suporta o carregamento de dados comprimidos. Os tipos de compressão suportados pelo Serviço de transferência de dados do BigQuery são os mesmos que os tipos de compressão suportados pelas tarefas de carregamento do BigQuery. Para mais informações, consulte o artigo Carregar dados comprimidos e não comprimidos.

Carregamento de dados para transferências do Cloud Storage

Pode especificar como os dados são carregados no BigQuery selecionando uma preferência de escrita na configuração da transferência quando configura uma transferência do Cloud Storage.

Estão disponíveis dois tipos de preferências de gravação: transferências incrementais e transferências truncadas.

Transferências incrementais

Uma configuração de transferência com uma preferência de escrita APPEND ou WRITE_APPEND, também denominada transferência incremental, anexa incrementalmente novos dados desde a transferência bem-sucedida anterior para uma tabela de destino do BigQuery. Quando uma configuração de transferência é executada com uma preferência de escrita APPEND, o Serviço de transferência de dados do BigQuery filtra os ficheiros que foram modificados desde a execução de transferência bem-sucedida anterior. Para determinar quando um ficheiro é modificado, o serviço de transferência de dados do BigQuery analisa os metadados do ficheiro para uma propriedade de "hora da última modificação". Por exemplo, o Serviço de transferência de dados do BigQuery analisa a propriedade de data/hora updated num ficheiro do Cloud Storage. Se o Serviço de transferência de dados do BigQuery encontrar ficheiros com uma "data/hora da última modificação" que tenha ocorrido após a data/hora da última transferência bem-sucedida, o Serviço de transferência de dados do BigQuery transfere esses ficheiros numa transferência incremental.

Para demonstrar como funcionam as transferências incrementais, considere o seguinte exemplo de transferência do Cloud Storage. Um utilizador cria um ficheiro num contentor do Cloud Storage a 01/07/2023 às 00:00 UTC com o nome file_1. A data/hora updated de file_1 é a hora em que o ficheiro foi criado. Em seguida, o utilizador cria uma transferência incremental a partir do contentor do Cloud Storage, agendada para ser executada uma vez por dia às 03:00 UTC, a partir de 01/07/2023 às 03:00 UTC.

  • A 2023-07-01T03:00Z, é iniciada a primeira execução da transferência. Como esta é a primeira execução de transferência para esta configuração, o Serviço de transferência de dados do BigQuery tenta carregar todos os ficheiros que correspondem ao URI de origem para a tabela do BigQuery de destino. A execução da transferência é bem-sucedida e o Serviço de transferência de dados do BigQuery carrega file_1 com êxito para a tabela do BigQuery de destino.
  • A próxima execução da transferência, a 02/07/2023 às 03:00 UTC, não deteta ficheiros em que a propriedade de data/hora updated seja superior à da última execução da transferência bem-sucedida (01/07/2023 às 03:00 UTC). A execução da transferência é bem-sucedida sem carregar dados adicionais para a tabela do BigQuery de destino.

O exemplo anterior mostra como o Serviço de transferência de dados do BigQuery analisa a propriedade de data/hora do ficheiro de origem para determinar se foram feitas alterações aos ficheiros de origem e transferir essas alterações, se forem detetadas.updated

Seguindo o mesmo exemplo, suponhamos que o utilizador cria outro ficheiro no contentor do Cloud Storage às 2023-07-03T00:00Z, denominado file_2. A data/hora updated de file_2 é a hora em que o ficheiro foi criado.

  • A próxima execução da transferência, a 03-07-2023 às 03:00 Z, deteta que file_2 tem uma data/hora updated superior à da última execução da transferência bem-sucedida (01-07-2023 às 03:00 Z). Suponhamos que, quando a execução da transferência é iniciada, falha devido a um erro temporário. Neste cenário, file_2 não é carregado na tabela do BigQuery de destino. A data/hora da última execução de transferência bem-sucedida permanece em 2023-07-01T03:00Z.
  • A próxima execução da transferência, a 04/07/2023 às 03:00 Z, deteta que file_2 tem uma data/hora updated superior à da última execução da transferência bem-sucedida (01/07/2023 às 03:00 Z). Desta vez, a execução da transferência é concluída sem problemas, pelo que carrega file_2 com êxito para a tabela de destino do BigQuery.
  • A próxima execução da transferência, a 05/07/2023 às 03:00 UTC, não deteta ficheiros em que a data/hora updated seja posterior à da última execução da transferência bem-sucedida (04/07/2023 às 03:00 UTC). A execução da transferência é bem-sucedida sem carregar dados adicionais para a tabela do BigQuery de destino.

O exemplo anterior mostra que, quando uma transferência falha, não são transferidos ficheiros para a tabela de destino do BigQuery. Todas as alterações aos ficheiros são transferidas na próxima execução de transferência bem-sucedida. As transferências bem-sucedidas subsequentes após uma transferência com falha não causam dados duplicados. No caso de uma transferência falhada, também pode optar por acionar manualmente uma transferência fora da hora agendada regularmente.

Transferências truncadas

Uma configuração de transferência com uma preferência de escrita MIRROR ou WRITE_TRUNCATE, também denominada transferência truncada, substitui os dados na tabela de destino do BigQuery durante cada execução de transferência com dados de todos os ficheiros que correspondem ao URI de origem. MIRROR substitui uma nova cópia dos dados na tabela de destino. Se a tabela de destino estiver a usar um decorador de partição, a execução da transferência apenas substitui os dados na partição especificada. Uma tabela de destino com um decorador de partição tem o formato my_table${run_date}, por exemplo, my_table$20230809.

A repetição das mesmas transferências incrementais ou truncadas num dia não causa dados duplicados. No entanto, se executar várias configurações de transferência diferentes que afetem a mesma tabela de destino do BigQuery, isto pode fazer com que o Serviço de transferência de dados do BigQuery duplique os dados.

Caminho do recurso do Cloud Storage

Para carregar dados de uma origem de dados do Cloud Storage, tem de indicar o caminho para os dados.

O caminho de recurso do Cloud Storage contém o nome do contentor e o objeto (nome do ficheiro). Por exemplo, se o contentor do Cloud Storage se chamar mybucket e o ficheiro de dados se chamar myfile.csv, o caminho do recurso seria gs://mybucket/myfile.csv.

O BigQuery não suporta caminhos de recursos do Cloud Storage que incluam várias barras invertidas consecutivas após a barra invertida dupla inicial. Os nomes de objetos do Cloud Storage podem conter vários carateres de barra (/) consecutivos. No entanto, o BigQuery converte várias barras invertidas consecutivas numa única barra invertida. Por exemplo, o seguinte caminho do recurso, embora seja válido no Cloud Storage, não funciona no BigQuery: gs://bucket/my//object//name.

Para obter o caminho do recurso do Cloud Storage:

  1. Abra a consola do Cloud Storage.

    Consola do Cloud Storage

  2. Procure a localização do objeto (ficheiro) que contém os dados de origem.

  3. Clique no nome do objeto.

    É apresentada a página Detalhes do objeto.

  4. Copie o valor fornecido no campo URI gsutil, que começa com gs://.

Compatibilidade com carateres universais para caminhos de recursos do Cloud Storage

Se os seus dados do Cloud Storage estiverem separados em vários ficheiros que partilham um nome base comum, pode usar um caráter universal no caminho do recurso quando carregar os dados.

Para adicionar um caráter universal ao caminho do recurso do Cloud Storage, acrescente um asterisco (*) ao nome base. Por exemplo, se tiver dois ficheiros denominados fed-sample000001.csv e fed-sample000002.csv, o caminho do recurso seria gs://mybucket/fed-sample*. Em seguida, pode usar este caráter universal na Google Cloud consola ou na CLI Google Cloud.

Pode usar vários carateres universais para objetos (nomes de ficheiros) em contentores. O caráter universal pode aparecer em qualquer lugar no nome do objeto.

Os carateres universais não expandem um diretório num gs://bucket/. Por exemplo, o comando gs://bucket/dir/* encontra ficheiros no diretório dir, mas não encontra ficheiros no subdiretório gs://bucket/dir/subdir/.

Também não pode fazer a correspondência com prefixos sem carateres universais. Por exemplo, gs://bucket/dir não corresponde a gs://bucket/dir/file.csv nem a gs://bucket/file.csv

No entanto, pode usar vários carateres universais para nomes de ficheiros em contentores. Por exemplo, gs://bucket/dir/*/*.csv corresponde a gs://bucket/dir/subdir/file.csv.

Para ver exemplos de compatibilidade com carateres universais em combinação com nomes de tabelas parametrizados, consulte Parâmetros de tempo de execução em transferências.

Considerações sobre a localização

O contentor do Cloud Storage tem de estar numa região ou numa região múltipla que seja compatível com a região ou a região múltipla do conjunto de dados de destino no BigQuery.

  • Se o seu conjunto de dados do BigQuery estiver numa multirregião, o contentor do Cloud Storage que contém os dados que está a transferir tem de estar na mesma multirregião ou numa localização contida na multirregião. Por exemplo, se o seu conjunto de dados do BigQuery estiver na região múltipla, o contentor do Cloud Storage pode estar localizado na região da Bélgica, que se encontra na UE.EUeurope-west1
  • Se o seu conjunto de dados estiver numa única região, o contentor do Cloud Storage tem de estar na mesma região. Por exemplo, se o seu conjunto de dados estiver na região de asia-northeast1 Tóquio, o seu contentor do Cloud Storage não pode estar na ASIA multirregião.

Para ver informações detalhadas sobre transferências e regiões, consulte o artigo Localizações e transferências de conjuntos de dados.

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

Preços

  • Aplicam-se as quotas e os limites padrão do BigQuery nas tarefas de carregamento.

  • Após a transferência dos dados para o BigQuery, aplicam-se os preços padrão de armazenamento e consultas do BigQuery.

  • Os dados não são eliminados automaticamente do seu contentor do Cloud Storage depois de serem carregados para o BigQuery, a menos que indique a eliminação quando configurar a transferência. Consulte o artigo Configurar uma transferência do Cloud Storage.

  • Consulte a nossa página de preços de transferências para ver detalhes.

Quotas e limites

O Serviço de transferência de dados do BigQuery usa tarefas de carregamento para carregar dados do Cloud Storage para o BigQuery.

Todas as quotas e limites do BigQuery nas tarefas de carregamento aplicam-se às tarefas de carregamento recorrentes do Cloud Storage, com as seguintes considerações adicionais:

Valor Limite
Tamanho máximo por execução de transferência de tarefa de carregamento 15 TB
Número máximo de ficheiros por execução de transferência 10 000 ficheiros

O que se segue?