Neste documento, descrevemos os princípios e as técnicas para implementar um fluxo de trabalho que pode ser repetido e que ajudará você a integrar as alterações aos seus dados no data warehouse baseado no BigQuery (DWH, na sigla em inglês). Essas alterações podem incluir novos conjuntos de dados, novas fontes de dados ou atualizações e alterações em conjuntos de dados. O documento também descreve uma arquitetura de referência para essa tarefa.
O público-alvo deste documento são os arquitetos e engenheiros de dados que usam o BigQuery como um DWH. Para acompanhar este documento, é necessário conhecer os conceitos básicos de CI/CD ou de práticas semelhantes de gerenciamento do ciclo de vida do aplicativo.
Introdução
A integração e a entrega contínuas (CI/CD) se tornaram uma técnica essencial no ciclo de vida do desenvolvimento de software. A adoção dos princípios de CI/CD permite que as equipes ofereçam software melhor com menos problemas do que ao integrar e implantar recursos manualmente. A CI/CD também pode ser parte de uma estratégia para gerenciamento de dados quando você moderniza o armazenamento em data warehouse.
No entanto, ao trabalhar com um DWH como o BigQuery, há diferenças na implementação da CI/CD em comparação com a implementação da CI/CD no código-fonte. Essas diferenças acontecem, em parte, porque o armazenamento em data warehouse é um sistema com estado inerente para gerenciar os dados subjacentes.
Este documento fornece as seguintes informações:
- Técnicas para implementar uma estratégia de integração contínua (CI) no BigQuery.
- Orientações e métodos que ajudam você a evitar armadilhas.
- Sugestões para recursos do BigQuery que ajudam com CI no BigQuery.
Este documento se concentra na CI, porque a integração tem mais considerações específicas para dados para uma equipe de armazenamento em data warehouse do que a entrega contínua (CD).
Quando usar a CI para um DWH do BigQuery
Neste documento, a integração de dados é uma tarefa que geralmente é executada pela equipe de DWH, o que inclui a incorporação de novos dados no DWH. Essa tarefa pode envolver a incorporação de uma nova fonte de dados no DWH ou a mudança da estrutura de uma tabela que já está dentro do DWH.
A integração de novos dados ao DWH é semelhante à integração de um novo recurso a um software existente. Isso pode gerar bugs e afetar negativamente a experiência do usuário final. Quando você integra dados ao BigQuery, os consumidores downstream dos dados (por exemplo, aplicativos, painéis de BI e usuários individuais) podem enfrentar problemas devido a inconsistências de esquema. Ou os consumidores podem usar dados incorretos que não refletem os dados da fonte original.
A CI para DWH é útil quando você quer fazer o seguinte:
- Descrever os principais pontos na CI de um sistema DWH.
- Projetar e implementar uma estratégia de CI para o ambiente do BigQuery.
- Saiba como usar os recursos do BigQuery para implementar a CI.
Este guia não descreve como gerenciar a CI para produtos que não sejam DWH, incluindo produtos de dados, como Dataflow e Bigtable.
Exemplo
A Example Company é uma grande empresa de varejo que mantém o DWH no BigQuery. No próximo ano, a empresa quer integrar novas fontes de dados ao DWH de empresas que foram adquiridas recentemente pela Example Company. As novas fontes de dados a serem integradas têm esquemas diferentes. No entanto, o DWH precisa manter o esquema atual e fornecer consistência de dados forte e integridade dos dados para que os consumidores de dados downstream não sejam afetados negativamente.
Atualmente, a equipe de DWH da empresa Example Company faz a integração de dados. A integração depende de ter as fontes de dados atuais em um esquema predefinido. Esse fluxo de trabalho envolve processos legados de importação de dados, bancos de dados adquiridos e serviços de aplicativos.
Para atualizar os processos de integração de dados a fim de acomodar as novas fontes de dados, a equipe do DWH precisa reformular a abordagem de integração de dados para atender aos requisitos observados anteriormente, como uma consistência de dados forte. A equipe precisa implementar as alterações de maneira isolada para que as alterações de dados possam ser testadas e medidas antes de serem disponibilizadas aos consumidores downstream.
Depois que a equipe de DWH adota o novo fluxo de trabalho, ela passa por um processo que pode ser repetido. Cada desenvolvedor pode criar um ambiente de desenvolvimento isolado com base nos dados de produção. Usando esses ambientes isolados, os desenvolvedores podem fazer alterações, testá-las, analisá-las e entregar as alterações necessárias ao ambiente de produção. Se as alterações causarem bugs ou problemas imprevistos, elas poderão ser revertidas facilmente.
O que significa integração contínua para um DWH
A integração contínua (CI) é um conjunto de práticas que permite às equipes de desenvolvimento encurtar ciclos de desenvolvimento e encontrar problemas no código mais rapidamente do que com os sistemas manuais. A principal vantagem de adotar uma abordagem de CI é a capacidade de se desenvolver rapidamente, reduzindo os riscos de interferência entre os desenvolvedores. Para alcançar essa meta, é preciso garantir que o processo possa ser reproduzido, permitindo que cada desenvolvedor trabalhe isoladamente de outros desenvolvedores.
Esses princípios também se aplicam quando uma organização precisa integrar dados a uma DWH, com algumas diferenças. No contexto de desenvolvimento típico de software, a CI isola as alterações no código-fonte, que não tem estado. No contexto de CI nos dados, ela integra os dados a um sistema DWH. No entanto, os dados têm estado por definição. Essa diferença tem implicações na forma como a CI se aplica a cenários DWH, conforme descrito neste documento.
Outros cenários que não são abordados neste documento
Embora este documento se concentre em isolar alterações de desenvolvimento do ambiente de produção, ele não abrange os seguintes aspectos da integração de dados:
- Teste de dados: você consegue verificar se os dados estão em conformidade com os requisitos da empresa? Os dados são confiáveis para servir como fonte da verdade? Para aumentar seu nível de confiança nos dados que você está exibindo do DWH, é importante testar os dados. Para testar, é possível executar um conjunto de consultas, declarando que os dados não estão sem valores ou que ela contém valores "ruins".
- Linhagem de dados: você consegue ver alguma tabela no contexto? Por exemplo, é possível ver de onde os dados foram coletados e quais conjuntos de dados foram pré-computados para gerar a tabela? Em arquiteturas DWH modernas, os dados são divididos em vários sistemas que usam diferentes estruturas de dados especializadas. Entre eles estão bancos de dados relacionais, bancos de dados NoSQL e fontes de dados externas. Para entender totalmente os dados que você tem, é preciso acompanhá-los. Você também precisa entender como os dados foram gerados e onde isso ocorreu.
Esses tópicos estão fora do escopo deste guia. No entanto, isso beneficia sua estratégia de dados quando você cria um fluxo de trabalho para sua equipe.
Configuração típica do BigQuery como um DWH
O diagrama a seguir ilustra um design típico de DWH para BigQuery. Ele mostra como os dados de fontes externas são ingeridos no DWH e como os consumidores consomem dados dele.
Os dados começam nas fontes de dados, em que são armazenados em bancos de dados convencionais ou de baixa latência, como bancos de dados SQL OLTP e bancos de dados NoSQL. Um processo programado copia os dados para uma área de preparo.
Os dados são armazenados temporariamente na área de preparo. Se necessário, os dados são transformados para caber em um sistema analítico antes de serem carregados nas tabelas DWH. No diagrama, a área de preparo está dentro do Google Cloud, mas isso não é obrigatório. As transformações podem incluir desnormalização, enriquecimento de determinados conjuntos de dados ou processamento de entradas malformadas (por exemplo, entradas com valores ausentes).
Na área de preparo, os novos dados são carregados nas tabelas DWH. As tabelas podem ser organizadas de maneiras diferentes, dependendo do design do DWH, e geralmente são chamadas de tabelas principais. Alguns exemplos de paradigmas de design de tabela incluem o paradigma de esquema de estrela, o paradigma desnormalizado e agregadores de vários níveis.
Independentemente do design da tabela, essas tabelas salvam dados ao longo do tempo. As tabelas precisam aderir ao esquema e presume-se que tenham a fonte de verdade para todas as finalidades analíticas. Esse papel nas tabelas significa que os dados nelas precisam estar completos, ser consistentes e aderir aos esquemas predefinidos.
Essas tabelas não exibem dados diretamente para os consumidores. Em vez disso, os dados são fornecidos por uma camada de acesso, projetada para encapsular a lógica de negócios que precisa ser aplicada aos dados subjacentes. Exemplos desse tipo de lógica de negócios são o cálculo de uma métrica para cada registro ou a filtragem e agrupamento dos dados.
Os consumidores dos dados podem se conectar e ler os dados da camada de acesso do DWH. Esses consumidores de dados podem incluir sistemas como os seguintes:
- Painéis de business intelligence (BI)
- Blocos de notas de ciência de dados
- Sistemas operacionais que dependem dos dados calculados no DWH
- Usuários humanos para consultas ad hoc
Os consumidores de dados dependem muito do DWH para fornecer esquemas consistentes e na lógica de negócios que o DWH encapsula. Esses esquemas e lógica de negócios podem ser considerados os contratos de nível de serviço (SLAs) da plataforma DWH. Qualquer alteração na lógica de negócios, no esquema ou na completude dos dados pode ter grandes implicações downstream. Devido à natureza em constante mudança das plataformas de dados modernas, a equipe do DWH pode precisar fazer essas mudanças e aderir aos SLAs de maneira rigorosa. Para que a equipe atenda a esses SLAs e mantenha o DWH atualizado, é necessário um fluxo de trabalho que permita a integração de dados, minimizando o atrito que essas mudanças podem criar.
Recursos para integração contínua em um DWH
Como acontece com qualquer outra equipe de desenvolvimento ou TI, a equipe do DWH precisa manter recursos essenciais para as responsabilidades deles. Esses recursos geralmente podem ser divididos nas seguintes categorias:
A base do código para pipelines de dados: esses recursos geralmente consistem em código-fonte em uma linguagem de programação de alto nível, como Python ou Java. Para esses tipos de recursos, os processos de CI/CD são criados usando ferramentas como Git e Jenkins ou com soluções do Google Cloud, como o Cloud Source Repositories e o Cloud Build.
Scripts SQL: esses recursos descrevem a estrutura e a lógica de negócios que são encapsulados no DWH. Nessa categoria, os recursos podem ser divididos nas seguintes subcategorias:
- Linguagem de definição de dados (DDL): esses recursos são usados para definir o esquema de tabelas e visualizações.
- Linguagem de manipulação de dados (DML): esses recursos são usados para manipular dados em uma tabela. Os comandos DML também são usados para criar novas tabelas com base nas atuais.
- Linguagem de controle de dados (DCL, na sigla em inglês): os recursos são usados para controlar
permissões e acesso a tabelas. No BigQuery, é
possível controlar o acesso usando o SQL e a
ferramenta de linha
de comando
bqou a API REST do BigQuery. No entanto, recomendamos que você use o IAM.
Esses recursos, e outros, como scripts do Terraform usados para criar componentes, são mantidos em repositórios de código. Ferramentas como Dataform podem ajudar você a criar um pipeline de CI/CD que valida seus scripts SQL e verifica as regras de validação predefinidas nas tabelas criadas pelos scripts DDL. Essas ferramentas permitem aplicar processos de compilação e teste ao SQL, que, na maioria dos contextos, não tem um ambiente de teste natural.
Além dos recursos associados a ferramentas e processos, o principal recurso para uma equipe de DWH são os dados. Os dados não são rastreáveis por sistemas de rastreamento de recursos, como o Git, desenvolvidos para rastrear o código-fonte. Este documento aborda os problemas associados aos dados de acompanhamento.
Problemas com a integração de dados
Devido à complexidade potencial das relações de tabela dentro de um DWH (por exemplo, em um dos paradigmas de design de tabela mencionados anteriormente), manter o estado de dados de produção isolado de um ambiente de teste é um desafio. As práticas padrão de desenvolvimento de software não podem ser aplicadas ao cenário de integração de dados.
A tabela a seguir resume as diferenças entre as práticas para integrar o código e as práticas para integrar dados.
| Como integrar código | Como integrar dados | |
|---|---|---|
| Desenvolvimento local | O código-fonte é fácil de clonar devido ao tamanho relativamente pequeno. Geralmente, o código se encaixa na maioria das máquinas do usuário final, excluindo casos de monorepo, que têm outras soluções. | A maioria das tabelas em um DWH não se encaixa em uma máquina de desenvolvimento devido ao tamanho. |
| Teste central | Diferentes estados do código-fonte são clonados em um sistema central (um servidor de CI) para passar por testes automatizados. Ter estados diferentes do código permite comparar os resultados entre uma versão estável e uma de desenvolvimento. | Criar estados diferentes dos dados em um ambiente isolado não é uma tarefa simples. A movimentação de dados para fora do DWH é uma operação demorada e que consome muitos recursos. Não é prático fazer isso com a frequência necessária para os testes. |
| Versões anteriores | Durante o processo de lançamento de novas versões de software, é possível rastrear versões anteriores. Se você detectar um problema em uma nova versão, poderá reverter para uma versão segura. | Fazer backups de tabelas dentro do DWH é uma prática padrão, caso você precise reverter. No entanto, é necessário garantir que todas as tabelas afetadas sejam revertidas para o mesmo ponto no tempo. Dessa forma, as tabelas relacionadas serão consistentes entre si. |
Integrar dados a tabelas do BigQuery
O BigQuery tem dois recursos que podem ajudar a projetar um fluxo de trabalho para integração de dados: snapshots de tabelas e clones de tabelas. É possível combinar esses recursos para atingir um fluxo de trabalho que oferece um ambiente de desenvolvimento econômico. Os desenvolvedores podem manipular dados e a respectiva estrutura isoladamente do ambiente de produção e também podem reverter uma mudança, se necessário.
Um snapshot da tabela do BigQuery é uma representação somente leitura de uma tabela (chamada tabela base) em um determinado momento. Da mesma forma, um clone da tabela do BigQuery é uma representação de leitura/gravação de uma tabela em um determinado momento. Em ambos os casos, os custos de armazenamento são minimizados porque apenas as diferenças da tabela base são armazenadas. Os clones de tabela começam a gerar custos quando a tabela base é alterada ou quando eles mudam. Como os snapshots da tabela são somente leitura, eles são cobrados somente quando a tabela base é alterada.
Para mais informações sobre os preços de snapshots e clones de tabelas, consulte Introdução a snapshots de tabelas e Introdução a clones de tabelas.
É possível tirar snapshots e fazer clones de tabelas usando o recurso de viagem no tempo do BigQuery (até sete dias atrás). Esse recurso permite capturar snapshots e fazer clones de várias tabelas ao mesmo tempo, o que torna o ambiente de trabalho e os snapshots consistentes entre si. O uso desse recurso pode ser útil para tabelas que são atualizadas com frequência.
Como usar clones de tabela e snapshots de tabela para permitir o isolamento
Para ilustrar o fluxo de trabalho de integração de CI em um DWH, imagine o cenário a seguir. Você receberá uma tarefa para integrar um novo conjunto de dados ao DWH. A tarefa pode ser criar novas tabelas DWH, atualizar tabelas existentes, alterar a estrutura de tabelas ou qualquer combinação dessas tarefas. O fluxo de trabalho pode ser semelhante à seguinte sequência:
- Identifique as tabelas que podem ser afetadas pelas alterações e as tabelas extras que você quer verificar.
- Você cria um novo conjunto de dados do BigQuery para conter os recursos dessa mudança. Esse conjunto de dados ajuda a isolar as mudanças e separa essa tarefa de outras tarefas em que outros membros da equipe trabalham. O conjunto de dados precisa estar na mesma região que o conjunto de dados de origem. No entanto, é possível separar o projeto do projeto de produção para atender aos requisitos de segurança e faturamento da organização.
Para cada uma das tabelas, você cria um clone e um snapshot no novo conjunto de dados, possivelmente para o mesmo ponto no tempo. Essa abordagem oferece os seguintes benefícios:
- O clone da tabela pode atuar como uma cópia de trabalho em que é possível fazer alterações livremente sem afetar a tabela de produção. É possível criar vários clones de tabela da mesma tabela base para testar diferentes caminhos de integração ao mesmo tempo, com sobrecarga mínima.
- O snapshot pode atuar como um ponto de restauração e referência, em que os dados funcionam antes de qualquer alteração. Esse snapshot permite realizar uma reversão caso um problema seja detectado posteriormente no processo.
Use os clones de tabela para implementar as alterações necessárias nas tabelas. Essa ação resulta em uma versão atualizada dos clones de tabela, que podem ser testados em um conjunto de dados isolado.
Opcionalmente, no final da fase de implementação, será possível apresentar um conjunto de dados para as seguintes tarefas:
- Teste de unidade com uma ferramenta de validação, como Dataform. Os testes de unidade são independentes, o que significa que o recurso é testado isoladamente. Nesse caso, o recurso é a tabela no BigQuery. Os testes de unidade podem verificar se há valores nulos e se todas as strings atendem aos requisitos de tamanho, além de garantir que determinados dados agregados gerem resultados úteis. Os testes de unidade podem incluir qualquer teste de confiança que garanta que a tabela mantenha as regras de negócios da organização.
- Teste de integração com consumidores downstream.
- Peça a opinião de colegas.
Esse fluxo de trabalho permite testar com dados de produção, sem afetar os consumidores downstream.
Antes de mesclar os novos dados no BigQuery, crie outro snapshot. Esse snapshot é útil como outra opção de reversão caso os dados na tabela base sejam alterados.
O processo de mesclagem das mudanças depende do processo que sua organização quer adotar e de quais mudanças são necessárias. Por exemplo, para uma alteração nos scripts SQL, o novo conjunto de dados pode ser acompanhado por uma solicitação de envio para a base do código padrão. Se a alteração estiver limitada a uma alteração nos dados de uma determinada tabela, basta copiar os dados usando os métodos padrão do BigQuery.
É possível usar um script de procedimentos armazenados para encapsular e automatizar as etapas para criar um conjunto de dados e os clones e snapshots. Automatizar essas tarefas reduz o risco de erros humanos. Para ver um exemplo de um script que pode ajudar a automatizar os processos, consulte o repositório CI do utilitário de CLI do BigQuery .do GitHub
Benefícios do uso de clones de tabelas e snapshots de tabelas
Quando você usa o fluxo de trabalho descrito na seção anterior, os desenvolvedores podem trabalhar isoladamente e em paralelo, sem interferir nos colegas. Os desenvolvedores podem testar e revisar as alterações e, se houver um problema, revertê-las. Como você está trabalhando com snapshots tabelas e não com tabelas completas, é possível minimizar os custos e o armazenamento em comparação com o uso de tabelas completas.
Nesta seção, fornecemos mais detalhes sobre como os snapshots e os clones de tabela permitem que os desenvolvedores atinjam esse fluxo de trabalho. O diagrama a seguir mostra como os snapshots e os clones de tabela se relacionam com os dados no conjunto de dados de produção.
No diagrama, o conjunto de dados de produção contém todas as tabelas que estão sendo usadas na produção. Cada desenvolvedor pode criar um conjunto de dados para o próprio ambiente de desenvolvimento. O diagrama mostra dois conjuntos de dados de desenvolvedor, rotulados como Dev Dataset 1 e Dev Dataset 2. Ao usar esses conjuntos de dados, os desenvolvedores podem trabalhar simultaneamente nas mesmas tabelas sem interferir uns com os outros.
Depois de criar um conjunto de dados, os desenvolvedores podem criar clones e snapshots das tabelas em que estão trabalhando. Os clones e snapshots representam os dados em um momento específico. Neste ponto, os desenvolvedores estão livres para alterar os clones da tabela, porque as mudanças não são visíveis na tabela base.
Um desenvolvedor pode analisar os clones de tabela, compará-los ao snapshot e testá-los para compatibilidade com os consumidores downstream. Outros desenvolvedores podem trabalhar com outros clones e snapshots, sem interferência, e sem criar muitas cópias que consomem recursos da tabela base.
Os desenvolvedores podem mesclar as alterações na tabela base e, ao mesmo tempo, manter o snapshot seguro como opção de reversão, se necessário. Esse processo também pode ser repetido para diferentes ambientes, como desenvolvimento, teste e produção.
Alternativas para clones e snapshots de tabelas
Existem alternativas para o uso de clones de tabelas e snapshots de tabelas que permitem ter um resultado semelhante. Esses métodos alternativos costumam ser usados de maneira diferente dos clones e snapshots. É importante entender as diferenças entre esses métodos e onde é possível preferir um método em vez de outro.
Copiar tabelas inteiras em um conjunto de dados diferente
Um método alternativo é usar um conjunto de dados diferente e copiar as tabelas nesse conjunto de dados. Esse método é semelhante ao de uso de clones e snapshots de tabelas, mas você copia o conjunto inteiro de tabelas. Dependendo dos tamanhos dos dados que estão sendo copiados, os custos de armazenamento podem ser altos. Algumas organizações usaram esse método antes que os clones de tabela ficassem disponíveis no BigQuery. No entanto, esse método não apresenta nenhuma vantagem em relação ao uso de clones e snapshots.
Exportar e importar tabelas para o Cloud Storage
Outra forma de fazer isso é mover os dados pelo Cloud Storage. Esse método também é semelhante ao uso de clones e snapshots de tabelas. No entanto, ela inclui a etapa extra de exportação dos dados para um bucket do Cloud Storage. Uma vantagem desse método é que ele oferece um backup extra dos dados. Escolha esse método se quiser um backup para soluções híbridas ou de recuperação de desastres.
Usar o Analytics Hub
Com o Analytics Hub, é possível compartilhar conjuntos de dados externamente e dentro da organização de uma forma projetada para ser segura. Ele oferece muitos recursos que permitem publicar conjuntos de dados para fornecer aos assinantes acesso controlado e somente leitura a eles. No entanto, mesmo que seja possível usar o Analytics Hub para expor conjuntos de dados e implementar alterações, um desenvolvedor ainda precisa criar clones de tabela para trabalhar com as tabelas.
Resumo das opções de integração contínua do DWH
A tabela a seguir resume as diferenças, as vantagens e as possíveis desvantagens entre as opções de integração contínua DWH. O Analytics Hub oferece um conjunto de recursos diferente e, portanto, não é mensurável usando os parâmetros listados na tabela.
| Custos | Reversões | Riscos | |
|---|---|---|---|
| Snapshots e clones de tabela | Mínima. Você paga somente pela diferença entre o snapshot ou o clone e a tabela base. | O snapshot atua como um backup que pode ser revertido, se necessário. | Você controla a quantidade de riscos. Os snapshots podem ser capturados em um momento específico de todas as tabelas, o que reduz inconsistências mesmo se houver uma reversão. |
| Cópia da tabela | Custos maiores do que o uso de snapshots e clones de tabela. Todos os dados estão duplicados. Para ter compatibilidade com reversões, você precisa de várias cópias da mesma tabela. | É possível, mas requer duas cópias de tabela: uma para servir de backup e outra para fazer alterações. | A clonagem é mais difícil de fazer em um momento específico. Se uma reversão for necessária, nem todas as tabelas serão retiradas do mesmo ponto no tempo. |
| Exportar e importar | Custos maiores do que o uso de snapshots e clones de tabela. Os dados estão duplicados. Para ter compatibilidade com a reversão, você precisa de várias cópias da mesma tabela. | Os dados exportados servem como backup. | Os dados exportados não representam uma exportação pontual para várias tabelas. |
A seguir
- Leia sobre snapshots de tabelas do BigQuery em Introdução a snapshots de tabelas.
- Saiba mais sobre a integração contínua para o desenvolvimento de software em Tecnologia de DevOps: integração contínua.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.