Introdução às transferências do Armazenamento Blob

Com o serviço de transferência de dados do BigQuery para o Armazenamento de Blobs do Azure, é possível programar e gerenciar automaticamente jobs de carregamento recorrentes do Armazenamento de Blobs do Azure e do Armazenamento de Blobs do Azure (Gen2) para o BigQuery.

Formatos de arquivo compatíveis

Atualmente, o serviço de transferência de dados do BigQuery aceita o carregamento de dados do Blob Storage nos seguintes formatos:

• Valores separados por vírgula (CSV)
• JSON (delimitado por nova linha)
• Avro
• Parquet
• ORC

Tipos de compactação compatíveis

O serviço de transferência de dados do BigQuery para o Blob Storage aceita o carregamento de dados compactados. Os tipos de compactação aceitos pelo serviço de transferência de dados do BigQuery são os mesmos tipos de compactação compatíveis com os jobs de carregamento do BigQuery. Para mais informações, consulte Como carregar dados compactados e descompactados.

Pré-requisitos de transferência

Para carregar dados de uma fonte de dados do Blob Storage, primeiro colete o seguinte:

• O nome da conta, o nome do contêiner e o caminho dos dados (opcional) do Blob Storage para os dados de origem. O campo de caminho de dados é opcional. Ele é usado para combinar prefixos de objeto e extensões de arquivo comuns. Se o caminho de dados for omitido, todos os arquivos do contêiner serão transferidos.
• Um token de assinatura de acesso compartilhado (SAS, na sigla em inglês) do Azure, que concede acesso de leitura à fonte de dados. Para detalhes sobre como criar um token SAS, consulte Assinatura de acesso compartilhado (SAS).

Parametrização do ambiente de execução da transferência

O caminho de dados do Blob Storage e a tabela de destino podem ser parametrizados, o que permite o carregamento de dados a partir de contêineres organizados por data. Os parâmetros usados pelas transferências do Blob Storage são os mesmos usados pelas transferências do Cloud Storage. Para mais detalhes, consulte Parâmetros do ambiente de execução em transferências.

Ingestão de dados para transferências Blob do Azure

É possível especificar como os dados são carregados no BigQuery selecionando uma Preferência de gravação na configuração da transferência ao configurar uma transferência de Blob do Azure.

Há dois tipos de preferências de gravação disponíveis, transferências incrementais e transferências truncadas.

Transferências incrementais

Uma configuração de transferência com uma preferência de gravação APPEND ou WRITE_APPEND, também chamada de transferência incremental, anexa novos dados incrementalmente desde a etapa anterior da transferência para uma tabela de destino do BigQuery. Quando uma configuração de transferência é executada com uma preferência de gravação APPEND, o serviço de transferência de dados do BigQuery filtra os arquivos que foram modificados desde a execução da transferência anterior. Para determinar quando um arquivo é modificado, o serviço de transferência de dados do BigQuery procura uma propriedade de "horário da última modificação" nos metadados do arquivo. Por exemplo, o serviço de transferência de dados do BigQuery analisa a propriedade de carimbo de data/hora updated em um arquivo do Cloud Storage. Se o serviço de transferência de dados do BigQuery encontrar arquivos com um "horário da última modificação" que tenham ocorrido após o carimbo de data/hora da última transferência bem-sucedida, o serviço transferirá esses arquivos em uma transferência incremental.

Para demonstrar como as transferências incrementais funcionam, considere o exemplo de transferência do Cloud Storage a seguir. Um usuário cria um arquivo chamado file_1 em um bucket do Cloud Storage no momento 2023-07-01T00:00Z. O carimbo de data/hora updated para file_1 é o horário em que o arquivo foi criado. Em seguida, o usuário cria uma transferência incremental no bucket do Cloud Storage, programada para ser executada uma vez por dia às 3h, a partir de 01-07-2023.

• Em 2023-07-01T03:00Z, a primeira execução de transferência é iniciada. Como esta é a primeira execução de transferência dessa configuração, o serviço de transferência de dados do BigQuery tenta carregar todos os arquivos que correspondem ao URI de origem na tabela de destino do BigQuery. A execução da transferência é bem-sucedida e o serviço de transferência de dados do BigQuery carrega file_1 na tabela de destino do BigQuery.
• A próxima execução de transferência, em 2023-07-02T03:00Z, não detecta arquivos em que a propriedade de carimbo de data/hora updated é maior que a última execução de transferência bem-sucedida (2023-07-01T03:00Z). A execução da transferência é bem-sucedida sem carregar nenhum dado adicional na tabela de destino do BigQuery.

O exemplo anterior mostra como o serviço de transferência de dados do BigQuery analisa a propriedade de carimbo de data/hora updated do arquivo de origem para determinar se alguma alteração foi feita nos arquivos de origem e transferi-las, caso alguma tenha sido detectada.

Seguindo o mesmo exemplo, suponha que o usuário crie outro arquivo no bucket do Cloud Storage no momento 2023-07-03T00:00Z, chamado file_2. O carimbo de data/hora updated para file_2 é o horário em que o arquivo foi criado.

• A próxima execução de transferência, em 2023-07-03T03:00Z, detecta que file_2 tem um carimbo de data/hora updated maior que a última execução de transferência bem-sucedida (2023-07-01T03:00Z). Suponha que, quando a execução da transferência for iniciada, ela falhe devido a um erro temporário. Neste cenário, file_2 não é carregado na tabela de destino do BigQuery. O último carimbo de data/hora de execução de transferência permanece em 2023-07-01T03:00Z.
• A próxima execução de transferência, em 2023-07-04T03:00Z, detecta que file_2 tem um carimbo de data/hora updated maior que a última execução de transferência bem-sucedida (2023-07-01T03:00Z). Desta vez, a execução da transferência é concluída sem problemas. Portanto, ela carrega file_2 na tabela de destino do BigQuery.
• A próxima execução de transferência, em 2023-07-05T03:00Z, não detecta arquivos em que o carimbo de data/hora updated é maior que a última execução de transferência bem-sucedida (2023-07-04T03:00Z). A execução da transferência é bem-sucedida sem carregar nenhum dado adicional na tabela de destino do BigQuery.

O exemplo anterior mostra que, quando uma transferência falha, nenhum arquivo é transferido para a tabela de destino do BigQuery. Todas as alterações de arquivo 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 geram dados duplicados. No caso de uma transferência com falha, você também pode optar por acionar manualmente uma transferência fora do horário programado regularmente.

Aviso: o serviço de transferência de dados do BigQuery depende da propriedade "horário da última modificação" em cada arquivo de origem para determinar quais arquivos serão transferidos, conforme visto nos exemplos de transferência. A modificação dessas propriedades pode fazer com que a transferência pule determinados arquivos ou carregue o mesmo arquivo várias vezes. Essa propriedade pode ter nomes diferentes em cada sistema de armazenamento aceito pelo serviço de transferência de dados do BigQuery. Por exemplo, os objetos do Cloud Storage chamam essa propriedade de updated.

Transferências truncadas

Uma configuração de transferência com uma preferência de gravação MIRROR ou WRITE_TRUNCATE, também chamada de transferência truncada, substitui os dados na tabela de destino do BigQuery durante cada execução de transferência com dados de todos os arquivos correspondentes ao URI de origem. MIRROR substitui uma nova cópia dos dados na tabela de destino. Se a tabela de destino estiver usando um decorador de partição, a execução da transferência substituirá apenas 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 em um dia não gera dados duplicados. No entanto, se você executar várias configurações de transferência diferentes que afetam a mesma tabela de destino do BigQuery, isso poderá fazer com que o serviço de transferência de dados do BigQuery duplique dados.

Suporte a caracteres curinga no caminho de dados do Blob Storage

É possível selecionar dados de origem separados em vários arquivos especificando um ou mais caracteres curinga de asterisco (*) no caminho de dados.

Mais de um caractere curinga pode ser usado no caminho de dados, mas alguma otimização é possível quando apenas um caractere curinga é usado:

• Há um limite maior no número máximo de arquivos por execução de transferência.
• O caractere curinga abrange os limites do diretório. Por exemplo, o caminho de dados my-folder/*.csv corresponde ao arquivo my-folder/my-subfolder/my-file.csv.

Exemplos de caminho de dados do Blob Storage

Veja a seguir exemplos de caminhos de dados válidos para uma transferência do armazenamento de dados. Os caminhos de dados não começam com /.

Exemplo: arquivo único

Para carregar um único arquivo do Blob Storage no BigQuery, especifique o nome do arquivo do Blob Storage:

my-folder/my-file.csv

Exemplo: todos os arquivos

Para carregar todos os arquivos de um contêiner do Blob Storage no BigQuery, defina o caminho dos dados como um único caractere curinga:

*

Exemplo: arquivos com um prefixo comum

Para carregar todos os arquivos do Blob Storage que compartilham um prefixo comum, especifique o prefixo comum com ou sem um caractere curinga:

my-folder/

ou

my-folder/*

Exemplo: arquivos com um caminho semelhante

Para carregar todos os arquivos do Blob Storage com um caminho semelhante, especifique o prefixo e o sufixo comuns:

my-folder/*.csv

Ao usar apenas um caractere curinga, ele abrange diretórios. Neste exemplo, cada arquivo CSV em my-folder está selecionado, bem como cada arquivo CSV de cada subpasta em my-folder.

Exemplo: caractere curinga no final do caminho

Considere o seguinte caminho de dados:

logs/*

Todos os arquivos a seguir estão selecionados:

logs/logs.csv
logs/system/logs.csv
logs/some-application/system_logs.log
logs/logs_2019_12_12.csv

Exemplo: caractere curinga no início do caminho

Considere o seguinte caminho de dados:

*logs.csv

Todos os arquivos a seguir estão selecionados:

logs.csv
system/logs.csv
some-application/logs.csv

Nenhum dos arquivos a seguir está selecionado:

metadata.csv
system/users.csv
some-application/output.csv

Exemplo: vários caracteres curinga

Ao usar vários caracteres curinga, é possível ter mais controle sobre a seleção de arquivos, mas com limites menores. Ao usar vários caracteres curinga, cada um deles abrange apenas um subdiretório.

Considere o seguinte caminho de dados:

*/*.csv

Os dois arquivos a seguir estão selecionados:

my-folder1/my-file1.csv
my-other-folder2/my-file2.csv

Nenhum dos arquivos a seguir está selecionado:

my-folder1/my-subfolder/my-file3.csv
my-other-folder2/my-subfolder/my-file4.csv

Assinatura de acesso compartilhado (SAS)

O token SAS do Azure é usado para acessar dados do Blob Storage em seu nome. Siga estas etapas para criar um token SAS para a transferência:

1. Crie ou use um usuário existente do Blob Storage para acessar a conta de armazenamento do contêiner do Blob Storage.

2. Crie um token SAS no nível da conta de armazenamento. Para criar um token SAS usando o Portal do Azure, faça o seguinte:

   1. Em Serviços permitidos, selecione Blob.
   2. Em Tipos de recursos permitidos, selecione Contêiner e Objeto.
   3. Em Permissões permitidas, selecione Ler e Lista.
   4. O prazo de validade padrão dos tokens SAS é de oito horas. Defina um prazo de validade que funcione para o cronograma de transferência.
   5. Não especifique endereços IP no campo Endereços IP permitidos.
   6. Em Protocolos permitidos, selecione Somente HTTPS.

   

3. Depois que o token SAS for criado, observe o valor do token SAS retornado. Você precisa desse valor ao configurar transferências.

Restrições de IP

Se você restringir o acesso aos recursos do Azure usando um firewall do Azure Storage, adicione os intervalos de IP usados pelos workers do Serviço de transferência do Cloud Storage à lista de IPs permitidos.

Para adicionar intervalos de IP como IPs permitidos a firewalls do Azure Storage, consulte Restrições de IP.

Considerações de consistência

Um arquivo demora cerca de 10 minutos para ficar disponível para o serviço de transferência de dados do BigQuery depois que ele é adicionado ao contêiner do Blob Storage.

Importante: para reduzir a possibilidade de perder dados, programe as transferências Blob Storage para que ocorram pelo menos 10 minutos depois que os arquivos forem adicionados ao contêiner.

Práticas recomendadas para controlar os custos de saída

As transferências do Blob Storage podem falhar se a tabela de destino não estiver configurada corretamente. Veja as possíveis causas de uma configuração incorreta:

• A tabela de destino não existe.
• O esquema da tabela não está definido.
• O esquema da tabela não é compatível com os dados que estão sendo transferidos.

Para evitar custos extras de saída do Blob Storage, primeiro teste uma transferência com um subconjunto de arquivos pequeno, mas representativo. Verifique se o teste é pequeno tanto em tamanho de dados quanto em contagem de arquivos.

Também é importante observar que a correspondência de prefixo para caminhos de dados acontece antes da transferência dos arquivos do Blob Storage, mas a correspondência de caracteres curinga acontece no Google Cloud. Essa distinção pode aumentar os custos de saída do Blob Storage para arquivos transferidos para o Google Cloud, mas não carregados no BigQuery.

Por exemplo, veja este caminho de dados:

folder/*/subfolder/*.csv

Os dois arquivos a seguir são transferidos para o Google Cloud porque eles têm o prefixo folder/:

folder/any/subfolder/file1.csv
folder/file2.csv

No entanto, apenas o arquivo folder/any/subfolder/file1.csv é carregado no BigQuery, porque corresponde ao caminho de dados completo.

Preços

Para mais informações, consulte Preços do serviço de transferência de dados do BigQuery.

Também é possível gerar custos fora do Google usando esse serviço. Para mais informações, consulte Preços do Blob Storage.

Cotas e limites

O serviço de transferência de dados do BigQuery usa jobs de carregamento para carregar dados do Blob Storage no BigQuery. Todas as cotas e limites do BigQuery em jobs de carregamento se aplicam a transferências recorrentes do Blob Storage, com as seguintes considerações:

Limite	Default
Tamanho máximo por execução de transferência do job de carregamento	15 TB
Número máximo de arquivos por execução de transferência quando o caminho de dados do Blob Storage inclui 0 ou 1 caractere curinga	10.000.000 arquivos
Número máximo de arquivos por execução de transferência quando o caminho de dados do Blob Storage inclui 2 ou mais caracteres curinga	10.000 arquivos

A seguir

• Saiba mais sobre como configurar uma transferência do Blob Storage.
• Saiba mais sobre parâmetros de ambiente de execução em transferências.
• Saiba mais sobre o serviço de transferência de dados do BigQuery.