Este documento descreve os princípios e as técnicas para implementar um fluxo de trabalho repetível que ajuda a integrar alterações de dados no seu data warehouse (DWH) baseado no BigQuery. Estas alterações podem incluir novos conjuntos de dados, novas origens de dados ou atualizações e alterações a conjuntos de dados existentes. O documento também descreve uma arquitetura de referência para esta tarefa.
O público-alvo deste documento são arquitetos de software e dados, bem como engenheiros de dados que usam o BigQuery como um DWH. Este documento pressupõe que conhece os conceitos básicos de CI/CD ou práticas de gestão do ciclo de vida de aplicações semelhantes.
Introdução
A integração contínua e a entrega contínua (CI/CD) tornaram-se uma técnica essencial no ciclo de vida de desenvolvimento de software. A adoção dos princípios de CI/CD permite que as equipas forneçam melhor software com menos problemas do que através da integração de funcionalidades e da respetiva implementação manual. A CI/CD também pode fazer parte de uma estratégia de gestão de dados quando moderniza o seu armazenamento de dados.
No entanto, quando trabalha com um DWH, como o BigQuery, existem diferenças na forma como implementa a CI/CD em comparação com a implementação da CI/CD no código fonte. Estas diferenças devem-se, em parte, ao facto de o armazenamento de dados ser um sistema inerentemente com estado para gerir 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 a evitar erros.
- Sugestões de funcionalidades do BigQuery que ajudam com a IC no BigQuery.
Este documento centra-se na CI, porque a integração tem considerações mais específicas dos dados para uma equipa de armazenamento de dados do que a implementação contínua (CD).
Quando usar a CI para um DWH do BigQuery
Neste documento, a integração de dados é uma tarefa que é normalmente realizada pela equipa do AHD, que inclui a incorporação de novos dados no AHD. Esta tarefa pode envolver a incorporação de uma nova origem de dados no AAD ou a alteração da estrutura de uma tabela que já se encontra no AAD.
A integração de novos dados no AHD é uma tarefa semelhante à integração de uma nova funcionalidade no software existente. Pode introduzir erros e afetar negativamente a experiência do utilizador final. Quando integra dados no BigQuery, os consumidores a jusante dos dados (por exemplo, aplicações, painéis de controlo de Business Intelligence e utilizadores individuais) podem ter problemas devido a incompatibilidades de esquemas. Em alternativa, os consumidores podem usar dados incorretos que não refletem os dados da origem de dados original.
A CI para o AAD é útil quando quer fazer o seguinte:
- Descreva os pontos principais na CI para um sistema DWH.
- Crie e implemente uma estratégia de CI para o seu ambiente do BigQuery.
- Saiba como usar as funcionalidades do BigQuery para implementar a CI.
Este guia não descreve como gerir a CI para produtos não DWH, incluindo produtos de dados como o Dataflow e o Bigtable.
Cenário de exemplo
A Example Company é uma grande empresa de retalho que mantém o respetivo AAM no BigQuery. No próximo ano, a empresa quer integrar novas origens de dados no respetivo AHD de empresas que foram adquiridas recentemente pela Example Company. As novas origens de dados a integrar têm esquemas diferentes. No entanto, o AAD tem de manter o esquema existente e fornecer uma forte consistência e integridade dos dados para que os consumidores de dados a jusante não sejam afetados negativamente.
Atualmente, a equipa do DWH da Example Company realiza a integração de dados. A integração baseia-se na existência das origens de dados num esquema predefinido. Este fluxo de trabalho envolve processos de importação de dados antigos, bases de dados adquiridas e serviços de aplicações.
Para atualizar os respetivos processos de integração de dados de forma a acomodar as novas origens de dados, a equipa do AAD tem de reformular a respetiva abordagem à integração de dados para agir em conformidade com os requisitos indicados anteriormente, como uma forte consistência dos dados. A equipa tem de implementar as alterações de forma isolada para que as alterações aos dados possam ser testadas e medidas antes de os dados serem disponibilizados aos consumidores a jusante.
Depois de a equipa do AAD adotar o novo fluxo de trabalho, a equipa tem um processo repetível. Cada programador pode criar um ambiente de desenvolvimento isolado que se baseia em dados de produção. Usando estes ambientes isolados, os programadores podem, em seguida, fazer alterações, testá-las, revê-las e fornecer as alterações necessárias ao ambiente de produção. Se as alterações causarem erros ou problemas imprevistos, podem ser facilmente revertidas.
O que significa a integração contínua para um DWH
A integração contínua (CI) é um conjunto de práticas que permite às equipas de desenvolvimento encurtar os 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 desenvolver rapidamente, reduzindo os riscos de interferência entre os programadores. Este objetivo é alcançado garantindo que o processo é repetível, ao mesmo tempo que permite que cada programador trabalhe isoladamente de outros programadores.
Estes princípios também se aplicam quando uma organização tem de integrar dados num DWH, com algumas diferenças. No contexto do desenvolvimento de software típico, a IC isola as alterações ao código-fonte, que não tem estado. No contexto da IC nos dados, a IC integra dados num sistema de AHD. No entanto, os dados são com estado por definição. Esta diferença tem implicações na forma como a CI se aplica aos cenários de DWH, conforme descrito neste documento.
Cenários adicionais não abordados neste documento
Embora este documento se foque em isolar as alterações de desenvolvimento do ambiente de produção, não aborda os seguintes aspetos da integração de dados:
- Testes de dados: consegue verificar se os dados que tem estão em conformidade com os requisitos da empresa? Os dados são fiáveis para servirem de fonte de verdade? Para aumentar o seu nível de confiança nos dados que está a publicar a partir do seu AAD, é importante testar os dados. Para testar, pode executar um conjunto de consultas, afirmando que os dados não têm valores em falta ou afirmando que contêm valores "incorretos".
- Origem dos dados: consegue ver qualquer tabela no respetivo contexto? Por exemplo, consegue ver a origem dos dados e que conjuntos de dados foram pré-calculados para gerar a tabela? Nas arquiteturas de DWH modernas, os dados são divididos em muitos sistemas que usam estruturas de dados diferentes e especializadas. Estas incluem bases de dados relacionais, bases de dados NoSQL e origens de dados externas. Para compreender totalmente os dados que tem, tem de monitorizar esses dados. Também tem de compreender como os dados foram gerados e a partir de onde foram gerados.
Estes tópicos estão fora do âmbito deste guia. No entanto, é vantajoso para a sua estratégia de dados planear estes tópicos quando estiver a criar um fluxo de trabalho para a sua equipa.
Configuração típica do BigQuery como um AAD
O diagrama seguinte ilustra uma estrutura de DWH típica para o BigQuery. Mostra como os dados de origens externas são carregados no AHD e como os consumidores usam os dados do AHD.
Os dados começam nas origens de dados, onde se encontram em bases de dados transacionais ou de baixa latência convencionais, como bases de dados SQL OLTP e bases de dados NoSQL. Um processo agendado copia os dados para uma área temporária.
Os dados são armazenados temporariamente na área de preparação. Se necessário, os dados são transformados para se ajustarem a um sistema de análise antes de serem carregados nas tabelas do AAD. (Neste diagrama, a área de preparação está dentro de Google Cloud, mas não tem de ser.) As transformações podem incluir a desnormalização, o enriquecimento de determinados conjuntos de dados ou o processamento de entradas com erros de formatação (por exemplo, entradas com valores em falta).
A partir da área de preparação, os novos dados são carregados nas tabelas do DWH. As tabelas podem estar organizadas de diferentes formas, consoante a estrutura do AHD, e são normalmente denominadas tabelas principais. Alguns exemplos de paradigmas de design de tabelas incluem o paradigma de esquema em estrela, o paradigma desnormalizado e agregações de vários níveis.
Independentemente do design da tabela, estas tabelas guardam dados ao longo do tempo. As tabelas têm de cumprir o esquema e presumem-se que contêm a fonte de informações verdadeiras para todos os fins analíticos. Esta função para as tabelas significa que os dados nestas tabelas têm de estar completos, ser consistentes e cumprir os esquemas predefinidos.
Estas tabelas não apresentam dados diretamente aos consumidores. Em alternativa, os dados são servidos através de uma camada de acesso, concebida para encapsular a lógica empresarial que tem de ser aplicada aos dados subjacentes. Exemplos deste tipo de lógica empresarial: calcular uma métrica para cada registo ou filtrar e agrupar os dados.
Os consumidores dos dados podem ligar-se e ler dados da camada de acesso do AAD. Estes consumidores de dados podem incluir sistemas como os seguintes:
- Painéis de controlo de Business Intelligence (BI)
- Notebooks de ciência de dados
- Sistemas operacionais que dependem de dados calculados no DWH
- Utilizadores humanos para consultas ad hoc
Os consumidores de dados dependem fortemente do AAD para fornecer esquemas consistentes e da lógica empresarial que o AAD encapsula. Estes esquemas e lógica empresarial podem ser considerados os contratos de nível de serviço (SLAs) da plataforma de DWH. Qualquer alteração à lógica empresarial, ao esquema ou à integridade dos dados pode ter grandes implicações a jusante. Dada a natureza em constante mudança das plataformas de dados modernas, a equipa do DWH pode ter de fazer essas alterações, ao mesmo tempo que cumpre rigorosamente os SLAs. Para que a equipa cumpra estes SLAs e também mantenha o AAD atualizado, precisa de um fluxo de trabalho que permita a integração de dados, minimizando o atrito que estas alterações possam criar.
Recursos para integração contínua num AAD
Tal como qualquer outra equipa de desenvolvimento ou TI, a equipa do AAD tem de manter recursos essenciais para as suas responsabilidades. Normalmente, estes recursos podem ser divididos nas seguintes categorias:
A base de código para pipelines de dados: normalmente, estes recursos consistem em código-fonte numa 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 através de ferramentas como o Git e o Jenkins, ou através de soluções como o Cloud Source Repositories e o Cloud Build.Google Cloud
Scripts SQL: estes recursos descrevem a estrutura e a lógica empresarial que estão encapsuladas no DWH. Nesta categoria, os recursos podem ser divididos nas seguintes subcategorias:
- Linguagem de definição de dados (LDD): estes recursos são usados para definir o esquema de tabelas e vistas.
- Linguagem de manipulação de dados (DML): estes recursos são usados para manipular dados numa tabela. Os comandos DML também são usados para criar novas tabelas com base em tabelas existentes.
- Linguagem de controlo de dados (DCL): estes recursos são usados para controlar as autorizações e o acesso às tabelas. No BigQuery, pode controlar o acesso através de SQL e da ferramenta de linha de comandos
bqou da API REST do BigQuery. No entanto, recomendamos que use o IAM.
Estes recursos, e outros, como scripts do Terraform, que são usados para criar componentes, são mantidos em repositórios de código. As ferramentas como o Dataform podem ajudar a criar um pipeline de CI/CD que valide os seus scripts SQL e verifique as regras de validação predefinidas em tabelas criadas por scripts DDL. Estas ferramentas permitem-lhe aplicar processos de compilação e teste para SQL, que, na maioria dos contextos, não tem um ambiente de teste natural.
Além dos recursos associados a ferramentas e processos, o recurso principal de uma equipa de AAD são os dados. Os dados não são rastreáveis através de sistemas de rastreio de recursos, como o Git, que foi concebido para rastrear o código-fonte. Este documento aborda os problemas associados aos dados de acompanhamento.
Problemas com a integração de dados
Devido à potencial complexidade das relações entre tabelas num AAD (por exemplo, num dos paradigmas de design de tabelas mencionados anteriormente), manter o estado dos dados de produção isolado de um ambiente de testes é um desafio. Não é possível aplicar práticas padrão na programação de software ao cenário de integração de dados.
A tabela seguinte resume as diferenças entre as práticas de integração de código e as práticas de integração de dados.
| Integrar código | Integrar dados | |
|---|---|---|
| Desenvolvimento local | O código-fonte é facilmente clonável devido ao seu tamanho relativamente pequeno. Geralmente, o código adapta-se à maioria das máquinas de utilizadores finais (exceto nos casos de monorepos, que têm outras soluções). | A maioria das tabelas num AAD não cabe numa máquina de desenvolvimento devido ao respetivo tamanho. |
| Testes centrais | Os diferentes estados do código fonte são clonados num sistema central (um servidor de CI) para serem submetidos a testes automáticos. Ter diferentes estados do código permite-lhe comparar os resultados entre uma versão estável e uma versão de desenvolvimento. | Criar diferentes estados dos dados num ambiente isolado não é simples. A movimentação de dados para fora do AHD é uma operação que requer muitos recursos e tempo. Não é prático fazê-lo com a frequência necessária para os testes. |
| Versões anteriores | Durante o processo de lançamento de novas versões de software, pode acompanhar as versões anteriores. Se detetar um problema num novo lançamento, pode reverter para uma versão segura. | Fazer cópias de segurança das tabelas no DWH é uma prática padrão caso tenha de reverter. No entanto, tem de garantir que todas as tabelas afetadas são revertidas para o mesmo ponto no tempo. Desta forma, as tabelas relacionadas são consistentes entre si. |
Integre dados em tabelas do BigQuery
O BigQuery tem duas funcionalidades que podem ajudar a criar um fluxo de trabalho para a integração de dados: cópias instantâneas de tabelas e clones de tabelas. Pode combinar estas funcionalidades para alcançar um fluxo de trabalho que lhe ofereça um ambiente de desenvolvimento económico. Os programadores podem manipular os dados e a respetiva estrutura isoladamente do ambiente de produção e podem reverter uma alteração, se necessário.
Uma cópia instantânea de uma tabela do BigQuery é uma representação só de leitura de uma tabela (denominada tabela base) num determinado momento. Da mesma forma, um clone de tabela do BigQuery é uma representação de leitura/escrita de uma tabela num determinado momento. Em ambos os casos, os custos de armazenamento são minimizados porque apenas são armazenadas as diferenças da tabela base. Os clones de tabelas começam a incorrer em custos quando a tabela base muda ou quando os clones de tabelas mudam. Como as cópias instantâneas de tabelas são só de leitura, incorrem em custos apenas quando a tabela base muda.
Para mais informações sobre os preços das imagens instantâneas e dos clones de tabelas, consulte os artigos Introdução às imagens instantâneas de tabelas e Introdução aos clones de tabelas.
Pode tirar instantâneos e clonar tabelas através da funcionalidade de viagem no tempo do BigQuery (até sete dias no passado). Esta funcionalidade permite-lhe capturar instantâneos e clones de várias tabelas no mesmo momento, o que torna o seu ambiente de trabalho e os instantâneos consistentes entre si. A utilização desta funcionalidade pode ser útil para tabelas que são atualizadas com frequência.
Como usar clones de tabelas e instantâneos de tabelas para permitir o isolamento
Para ilustrar o fluxo de trabalho de integração para a CI num AAD, imagine o seguinte cenário. É-lhe atribuída a tarefa de integrar um novo conjunto de dados no AHD. A tarefa pode ser criar novas tabelas de DWH, atualizar tabelas existentes, alterar a estrutura das tabelas ou qualquer combinação destas tarefas. O fluxo de trabalho pode ter o seguinte aspeto:
- Identifica as tabelas que podem ser afetadas pelas alterações e as tabelas adicionais que pode querer verificar.
- Criar um novo conjunto de dados do BigQuery para conter os recursos desta alteração. Este conjunto de dados ajuda a isolar as alterações e separa esta tarefa de outras tarefas nas quais outros membros da equipa trabalham. O conjunto de dados tem de estar na mesma região que o conjunto de dados de origem. No entanto, o projeto pode ser separado do projeto de produção para ajudar com os requisitos de segurança e faturação da sua organização.
Para cada uma das tabelas, cria um clone e uma captura de ecrã no novo conjunto de dados, potencialmente para o mesmo ponto no tempo. Esta abordagem oferece as seguintes vantagens:
- O clone da tabela pode funcionar como uma cópia de trabalho onde pode fazer alterações livremente sem afetar a tabela de produção. Pode criar vários clones de tabelas da mesma tabela base para testar diferentes caminhos de integração em simultâneo, com uma sobrecarga mínima.
- O instantâneo pode funcionar como um ponto de restauro e referência, um ponto em que se sabe que os dados funcionavam antes de qualquer alteração. Esta imagem instantânea permite-lhe reverter a implementação caso seja detetado um problema mais tarde no processo.
Usa os clones de tabelas para implementar as alterações necessárias para as tabelas. Esta ação resulta numa versão atualizada dos clones de tabelas, que pode testar num conjunto de dados isolado.
Opcionalmente, no final da fase de implementação, pode apresentar um conjunto de dados que pode ser usado para as seguintes tarefas:
- Testes unitários com uma ferramenta de validação como o Dataform. Os testes unitários são autónomos, o que significa que o recurso é testado em isolamento. Neste caso, o recurso é a tabela no BigQuery. Os testes unitários podem verificar a existência de valores nulos, podem verificar se todas as strings cumprem os requisitos de comprimento e podem garantir que determinados dados agregados produzem resultados úteis. Os testes unitários podem incluir qualquer teste de confiança que garanta que a tabela mantém as regras empresariais da organização.
- Testes de integração com consumidores a jusante.
- Revisão por pares.
Este fluxo de trabalho permite-lhe testar com dados de produção sem afetar os consumidores a jusante.
Antes de unir os novos dados no BigQuery, pode criar outra imagem instantânea. Este instantâneo é útil como outra opção de reversão caso os dados na tabela base tenham sido alterados.
O processo de união das alterações depende do processo que a sua organização quer adotar e das alterações necessárias. Por exemplo, para uma alteração nos scripts SQL, o novo conjunto de dados pode ser acompanhado de um pedido de obtenção para a base de código padrão. Se a alteração se limitar a uma alteração nos dados numa determinada tabela, pode simplesmente copiar os dados através dos métodos padrão do BigQuery.
Pode usar um script de procedimentos armazenados para encapsular e automatizar os passos de criação de um conjunto de dados e de criação dos clones e das imagens instantâneas. A automatização destas tarefas reduz o risco de erro humano. Para ver um exemplo de um script que pode ajudar a automatizar os processos, consulte o repositório do GitHub do utilitário CLI de CI para dados no BigQuery.
Vantagens da utilização de clones e instantâneos de tabelas
Quando usa o fluxo de trabalho descrito na secção anterior, os programadores podem trabalhar isoladamente e em paralelo, sem interferir com os seus colegas. Os programadores podem testar e rever as alterações e, se houver um problema, reverter as alterações. Como está a trabalhar com instantâneos de tabelas e não com tabelas completas, pode minimizar os custos e o armazenamento em comparação com o trabalho com tabelas completas.
Esta secção fornece mais detalhes sobre como as imagens instantâneas e os clones de tabelas permitem aos programadores alcançar este fluxo de trabalho. O diagrama seguinte mostra a relação entre as cópias instantâneas e os clones de tabelas 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 a ser usadas na produção. Cada programador pode criar um conjunto de dados para o seu próprio ambiente de desenvolvimento. O diagrama mostra dois conjuntos de dados de programador, que estão etiquetados como Dev Dataset 1 e Dev Dataset 2. Ao usar estes conjuntos de dados de programador, os programadores podem trabalhar em simultâneo nas mesmas tabelas sem interferir uns com os outros.
Depois de os programadores criarem um conjunto de dados, podem criar clones e instantâneos das tabelas em que estão a trabalhar. Os clones e os instantâneos representam os dados num determinado momento. Neste ponto, os programadores podem alterar os clones da tabela, porque as alterações não são visíveis na tabela base.
Um programador pode rever os clones de tabelas, compará-los com a captura instantânea e testá-los quanto à compatibilidade com os consumidores a jusante. Outros programadores podem trabalhar com outros clones e instantâneos, sem interferências e sem criar demasiadas cópias da tabela base que consomem recursos.
Os programadores podem unir as alterações à tabela base, mantendo a cópia instantânea segura como opção de reversão, se necessário. Este processo também pode ser repetido para diferentes ambientes, como desenvolvimento, teste e produção.
Alternativas a clones de tabelas e instantâneos de tabelas
Existem alternativas à utilização de clones e instantâneos de tabelas que lhe permitem alcançar um resultado semelhante. Normalmente, estes métodos alternativos são usados de forma diferente dos clones e das capturas instantâneas. É importante compreender as diferenças entre estes métodos e em que situações pode preferir um método em vez do outro.
Copie tabelas inteiras para um conjunto de dados diferente
Um método alternativo é usar um conjunto de dados diferente e copiar as tabelas para esse conjunto de dados. A utilização deste método é semelhante à utilização de clones e instantâneos de tabelas, mas copia o conjunto completo de tabelas. Consoante os tamanhos dos dados que estão a ser copiados, os custos de armazenamento podem ser elevados. Algumas organizações usaram este método antes de os clones de tabelas ficarem disponíveis no BigQuery. No entanto, este método não apresenta vantagens em relação à utilização de clones e capturas de ecrã.
Exporte e importe tabelas para o Cloud Storage
Outro método alternativo é mover os dados através do Cloud Storage. Este método também é semelhante à utilização de clones de tabelas e instantâneos de tabelas. No entanto, inclui o passo adicional de exportar os dados para um contentor do Cloud Storage. Uma vantagem deste método é que lhe dá uma cópia de segurança adicional dos seus dados. Pode escolher este método se quiser uma cópia de segurança para recuperação de desastres ou soluções híbridas.
Use a partilha do BigQuery
A partilha do BigQuery (anteriormente Analytics Hub) permite-lhe partilhar conjuntos de dados dentro e fora da organização de uma forma concebida para ser segura. Oferece muitas funcionalidades que lhe permitem publicar conjuntos de dados para fornecer aos subscritores acesso controlado e só de leitura a esses conjuntos de dados. No entanto, apesar de poder usar a partilha para expor conjuntos de dados de modo a implementar alterações, um programador tem de criar clones de tabelas para trabalhar com as tabelas.
Resumo das opções de integração contínua do DWH
A tabela seguinte resume as diferenças, as vantagens e as potenciais desvantagens entre as opções de integração contínua do DWH. (A partilha oferece um conjunto de funcionalidades diferente e, por isso, não é mensurável através dos parâmetros indicados na tabela.)
| Custos | Reversões | Riscos | |
|---|---|---|---|
| Instantâneos e clones de tabelas | Minimalista. Só paga a diferença entre a imagem instantânea ou o clone e a tabela base. | O instantâneo funciona como uma cópia de segurança para reverter, se necessário. | Controla o nível de risco. As capturas instantâneas podem ser feitas num determinado momento para todas as tabelas, o que reduz as inconsistências, mesmo que haja uma reversão. |
| Cópia de tabelas | Custos mais elevados do que a utilização de instantâneos e clones de tabelas. A totalidade dos dados é duplicada. Para suportar reversões, precisa de várias cópias da mesma tabela. | Possível, mas requer duas cópias da tabela: uma cópia para servir como cópia de segurança e uma cópia para trabalhar e fazer alterações. | É mais difícil clonar um ponto no tempo. Se for necessário reverter, nem todas as tabelas são retiradas do mesmo ponto no tempo. |
| Exporte e importe | Custos mais elevados do que a utilização de instantâneos e clones de tabelas. Os dados estão duplicados. Para suportar a reversão, precisa de várias cópias da mesma tabela. | Os dados exportados servem como cópia de segurança. | Os dados exportados não são uma exportação num determinado momento para várias tabelas. |
O que se segue?
- Leia acerca das cópias instantâneas de tabelas do BigQuery em Introdução às cópias instantâneas de tabelas.
- Saiba mais sobre a integração contínua para o desenvolvimento de software em DevOps tech: Continuous integration.
- Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.