Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Introdução ao carregamento de dados

Neste documento, você terá uma visão geral sobre o carregamento de dados no BigQuery.

Visão geral

Há várias maneiras de ingerir dados no BigQuery:

  • Carregar em lote um conjunto de registros de dados.
  • Transmitir registros individuais ou lotes de registros.
  • Use consultas para gerar novos dados e anexar ou substituir os resultados em uma tabela.
  • Use um aplicativo ou serviço de terceiros.

Carregamento em lote

Com o carregamento em lote, os dados de origem são carregados em uma tabela do BigQuery em uma única operação em lote. Por exemplo, a fonte dos dados pode ser um arquivo CSV, um banco de dados externo ou um conjunto de arquivos de registros. Os jobs de extração, transformação e carregamento (ETL) tradicionais se enquadram nessa categoria.

As opções para carregamento em lote no BigQuery incluem:

  • Jobs de carregamento. Carregue dados do Cloud Storage ou de um arquivo local criando um job de carregamento. Os registros podem estar nos formatos Avro, CSV, JSON, ORC ou Parquet.
  • SQL. A instrução SQL LOAD DATA carrega dados de um ou mais arquivos em uma tabela nova ou atual. É possível usar a instrução LOAD DATA para carregar arquivos Avro, CSV, JSON, ORC ou Parquet.
  • Serviço de transferência de dados do BigQuery. Use o serviço de transferência de dados do BigQuery para automatizar o carregamento de dados do Google Software como serviço (SaaS, na sigla em inglês) ou de aplicativos e serviços de terceiros.
  • API BigQuery Storage Write. A API Storage Write permite processar em lote um número arbitrariamente grande de registros e confirmá-los em uma única operação atômica. Se a operação de confirmação falhar, será possível repetir a operação com segurança. Ao contrário dos jobs de carregamento do BigQuery, a API Storage Write não requer a preparação de dados para armazenamento intermediário, como o Cloud Storage.
  • Outros serviços gerenciados. Usar outros serviços gerenciados para exportar dados de um armazenamento de dados externo e importá-los para o BigQuery. Por exemplo, é possível carregar dados das exportações do Firestore.

O carregamento em lote pode ser feito como uma operação única ou em uma programação recorrente. Por exemplo, é possível:

  • É possível executar transferências do serviço de transferência de dados do BigQuery com base em uma programação.
  • É possível usar um serviço de orquestração, como o Cloud Composer, para programar jobs de carregamento.
  • Use um cron job para carregar dados em um cronograma.

Streaming

Com o streaming, você envia continuamente lotes menores de dados em tempo real, portanto, os dados ficam disponíveis para consulta assim que chegam. As opções para streaming no BigQuery incluem:

  • API Storage Write. A API Storage Write é compatível com a ingestão de streaming de alta capacidade com semântica de entrega apenas uma vez.
  • Dataflow. Use o Dataflow com o SDK do Apache Beam para configurar um pipeline de streaming que grava no BigQuery.
  • BigQuery Connector para SAP. O BigQuery Connector para SAP permite a replicação quase em tempo real dos dados do SAP diretamente no BigQuery. Para mais informações, consulte o Guia de planejamento do BigQuery Connector para SAP.

Dados gerados

É possível usar o SQL para gerar dados e armazenar os resultados no BigQuery. As opções para gerar dados incluem:

  • Use instruções de linguagem de manipulação de dados (DML, na sigla em inglês) para executar inserções em massa em uma tabela existente ou armazenar os resultados da consulta em uma nova tabela.

  • Use uma instrução CREATE TABLE ... AS para criar uma nova tabela a partir do resultado de uma consulta.

  • Execute uma consulta e salve os resultados em uma tabela. É possível anexar os resultados a uma tabela existente ou gravar em uma nova tabela. Para mais informações, consulte Como gravar resultados de consulta.

Aplicativos de terceiros

Alguns aplicativos e serviços de terceiros fornecem conectores que podem ingerir dados no BigQuery. Os detalhes de como configurar e gerenciar o pipeline de ingestão dependem do aplicativo. Por exemplo, para carregar dados de fontes externas no armazenamento do BigQuery, use o Carregador de dados da Informatica ou o Data pipelines da Fivetran. Para mais informações, consulte Carregar dados usando um aplicativo de terceiros.

Como escolher um método de ingestão de dados

Veja algumas considerações a serem consideradas ao escolher um método de ingestão de dados.

Origem de dados. A fonte ou o formato dos dados pode determinar se é mais simples de implementar e manter o carregamento em lote. Considere os seguintes pontos:

  • Se o serviço de transferência de dados do BigQuery for compatível com a fonte, a transferência dos dados diretamente para ele será a solução mais simples de implementar.

  • Se os dados vierem do Spark ou do Hadoop, considere usar conectores do BigQuery para simplificar o processamento de dados.

  • Para arquivos locais, considere o carregamento em lote, especialmente se o BigQuery for compatível com o formato do arquivo sem exigir uma etapa de transformação ou limpeza de dados.

  • Para dados do aplicativo, como eventos de aplicativos ou um fluxo de registros, pode ser mais fácil transmitir os dados em tempo real do que implementar carregamento de lote.

Alteração lenta versus dados em constante mudança. Se você precisar ingerir e analisar dados quase em tempo real, considere fazer streaming dos dados. Com o streaming, os dados estarão disponíveis para consulta assim que cada registro chegar. Evite usar instruções DML para enviar um grande número de atualizações ou inserções de linha individuais. Para dados atualizados com frequência, muitas vezes é melhor transmitir um registro de alterações e usar uma visualização para receber os resultados mais recentes. Outra opção é usar o Cloud SQL como banco de dados de processamento de transações on-line (OLTP, na sigla em inglês) e consultas federadas para unir os dados no BigQuery.

Se os dados de origem forem alterados lentamente ou você não precisar de resultados atualizados continuamente, use um job de carregamento. Por exemplo, se você usa os dados para executar um relatório diário ou por hora, os jobs de carregamento podem ser mais baratos e usar menos recursos do sistema.

Outro cenário são os dados que chegam com pouca frequência ou em resposta a um evento. Nesse caso, use o Dataflow para fazer streaming dos dados ou use o Cloud Functions para chamar a API de streaming em resposta a um gatilho.

Confiabilidade da solução: O BigQuery tem um Contrato de nível de serviço (SLA, na sigla em inglês). No entanto, você também precisa considerar a confiabilidade da solução específica que está implementando. Considere os seguintes pontos:

  • Com formatos mal posicionados, como JSON ou CSV, dados inválidos podem falhar em um job de carregamento inteiro. Considere se você precisa de uma etapa de limpeza de dados antes de carregar e como responder a erros. Considere também o uso de um formato fortemente tipado, como Avro, ORC ou Parquet.
  • Os jobs periódicos de carregamento exigem programação usando o Cloud Composer, o cron ou outra ferramenta. O componente de programação pode ser um ponto de falha na solução.
  • Com o streaming, é possível verificar o sucesso de cada registro e relatar um erro rapidamente. Considere gravar mensagens com falha em uma fila de mensagens não processadas para análise e processamento posteriores. Para mais informações sobre erros de streaming do BigQuery, consulte Solução de problemas de inserções de streaming.
  • Os jobs de streaming e carregamento estão sujeitos a cotas. Para informações sobre como lidar com erros de cota, consulte Solução de problemas de erros de cota do BigQuery.
  • As soluções de terceiros podem ser diferentes na configuração, confiabilidade, garantia de pedidos e outros fatores. Portanto, considere essas soluções antes de adotar uma solução.

Latência. Avalie a quantidade de dados carregados e a frequência com que você precisa que os dados estejam disponíveis. O streaming oferece a menor latência de dados disponível para análise. Os jobs de carregamento periódicos têm uma latência maior porque os novos dados só estão disponíveis após a conclusão de cada um deles.

Por padrão, os jobs de carregamento usam um pool compartilhado de slots. Um job de carregamento pode aguardar em um estado pendente até que os slots estejam disponíveis, especialmente se você carregar uma quantidade muito grande de dados. Se isso criar tempos de espera inaceitáveis, você poderá comprar slots dedicados em vez de usar o pool de slots compartilhados. Para mais informações, consulte Introdução às reservas.

O desempenho da consulta para origens de dados externas pode não ser tão alto quanto o desempenho das consultas para dados armazenados no BigQuery. Se a minimização da latência da consulta for importante, recomendamos carregar os dados no BigQuery.

Formato de processamento de dados. Escolha um formato de ingestão de dados com base nos seguintes fatores:

  • Suporte a esquemas. As exportações Avro, ORC, Parquet e Firestore são formatos autodescritivos. O esquema de tabela é criado automaticamente pelo BigQuery com base nos dados de origem. Em dados JSON e CSV, forneça um esquema explícito ou use a detecção automática de esquema.

  • Dados simples ou campos aninhados e repetidos. Avro, CSV, JSON, ORC e Parquet aceitam dados simples. As exportações Avro, JSON, ORC, Parquet e Firestore também são compatíveis com dados que têm campos repetidos e aninhados. Dados aninhados e repetidos são úteis para expressar hierarquia. Campos aninhados e repetidos também reduzem a duplicação ao desnormalizar os dados.

  • Novas linhas incorporadas. Quando você carrega dados de arquivos JSON, as linhas precisam ser delimitadas. No BigQuery, é esperado que arquivos JSON delimitados por nova linha tenham um único registro por linha.

  • Codificação. O BigQuery é compatível com a codificação UTF-8 para dados simples e aninhados ou repetidos. Ele também é compatível com a codificação ISO-8859-1 para dados simples apenas de arquivos CSV.

Como carregar dados desnormalizados, aninhados e repetidos

Muitos desenvolvedores estão acostumados a trabalhar com bancos de dados relacionais e esquemas de dados normalizados. A normalização evita que dados duplicados sejam armazenados e oferece consistência quando os dados são atualizados regularmente.

A desnormalização é uma estratégia comum para aumentar o desempenho de leitura em conjuntos de dados relacionais que foram normalizados anteriormente. A maneira recomendada de desnormalizar dados no BigQuery é usar campos aninhados e repetidos. É melhor usar essa estratégia quando os relacionamentos são hierárquicos e geralmente consultados juntos, como nos relacionamentos pai-filho.

A economia de armazenamento pelo uso de dados normalizados tem menos efeito nos sistemas modernos. Os ganhos de desempenho da desnormalização de dados compensam os aumentos nos custos de armazenamento. As junções exigem coordenação de dados (largura de banda de comunicação). A desnormalização localiza os dados em slots individuais. Dessa forma, a execução pode ser feita em paralelo.

Para manter vínculos enquanto desnormaliza os dados, use campos aninhados e repetidos em vez de nivelar completamente os dados. Quando os dados relacionais estão completamente nivelados, a comunicação de rede (embaralhamento) pode afetar negativamente o desempenho da consulta.

Por exemplo, desnormalizar um esquema de pedidos sem usar campos repetidos e aninhados pode exigir que você agrupe os dados por um campo como order_id (quando há um vínculo de um para muitos). Devido ao embaralhamento envolvido, o agrupamento dos dados é menos eficiente do que a desnormalização dos dados usando campos aninhados e repetidos.

Em algumas circunstâncias, a desnormalização dos dados e o uso de campos aninhados e repetidos não aumentam o desempenho. Evite a desnormalização nestes casos de uso:

  • Você tem um esquema em estrela com dimensões que mudam frequentemente.
  • O BigQuery complementa um sistema de processamento de transações on-line (OLTP, na sigla em inglês) com mutação no nível da linha, mas não pode substituí-lo.

Campos aninhados e repetidos são compatíveis com os seguintes formatos de dados:

  • Avro
  • JSON (delimitado por nova linha)
  • ORC
  • Parquet
  • Exportações do Datastore
  • Exportações do Firestore

Para saber mais sobre como especificar campos repetidos e aninhados no seu esquema quando estiver carregando dados, consulte Como especificar campos repetidos e aninhados.

Como carregar dados de outros serviços do Google

Serviço de transferência de dados do BigQuery

O serviço de transferência de dados do BigQuery automatiza o carregamento de dados no BigQuery a partir destes serviços:

Apps de software como serviço do Google: Provedores de armazenamento em nuvem externos: Data warehouses: Além disso, várias transferências de terceiros estão disponíveis no Google Cloud Marketplace.

Depois de configurar uma transferência de dados, o serviço de transferência de dados do BigQuery programa e gerencia, automaticamente, carregamentos de dados recorrentes do aplicativo de origem para o BigQuery.

Google Analytics 360

Para saber como exportar sua sessão e dados de hits da vista de relatórios do Google Analytics 360 para o BigQuery, consulte Exportação para o BigQuery na Central de Ajuda do Analytics.

Para exemplos de como consultar dados do Analytics no BigQuery, consulte o manual do BigQuery na Ajuda do Analytics.

Dataflow

Com o Dataflow, é possível carregar dados diretamente no BigQuery. Para mais informações sobre como usar o Dataflow para ler e gravar no BigQuery, consulte conector de E/S do BigQuery (em inglês) na documentação do Apache Beam.

Datastream

O Datastream usa a funcionalidade de captura de dados alterados do BigQuery e a API Storage Write para replicar dados e atualizações de esquema de bancos de dados operacionais diretamente no BigQuery. Siga este guia de início rápido para ver um exemplo de replicação de um banco de dados do Cloud SQL para PostgreSQL no BigQuery.

Pub/Sub

O Pub/Sub é um serviço de mensagens que pode ser usado para análises de streaming e pipelines de integração de dados. É possível usar assinaturas do BigQuery para gravar mensagens diretamente em uma tabela existente do BigQuery.

Alternativas ao carregamento de dados

Não é preciso carregar dados antes de executar consultas nas seguintes situações:

Conjuntos de dados públicos
Conjuntos de dados públicos são conjuntos de dados armazenados no BigQuery e compartilhados publicamente. Para mais informações, consulte Conjuntos de dados públicos do BigQuery.
Conjuntos de dados compartilhados
É possível compartilhar conjuntos de dados armazenados no BigQuery. Se alguém tiver compartilhado um conjunto de dados com você, é possível executar consultas nele sem a necessidade de carregar os dados.
Fontes de dados externas
O BigQuery também pode executar consultas em determinadas formas de dados externos, sem carregá-los no armazenamento do BigQuery. Com essa abordagem, é possível aproveitar os recursos analíticos do BigQuery sem mover os dados armazenados em outro lugar. Para saber informações sobre os benefícios e as limitações dessa abordagem, consulte fontes de dados externas.
Arquivos de geração de registros
O Cloud Logging é uma opção para exportar arquivos de registros para o BigQuery. Consulte Configurar e gerenciar coletores para mais informações.

Próximas etapas