Visão geral da transferência de dados e esquemas

Neste documento, abordamos os conceitos e tarefas para a transferência do esquema e dos dados do data warehouse atual para o BigQuery.

A migração de um data warehouse para a nuvem é um processo complexo que exige planejamento, recursos e tempo. Para reduzir a complexidade, o ideal é realizar a migração do data warehouse de maneira gradual e iterativa. Fazer várias iterações de migração de esquema e dados pode melhorar o resultado.

Processo de migração de esquema e dados

No começo da jornada de migração, você tem sistemas upstream que alimentam o data warehouse legado e sistemas downstream que usam esses dados em relatórios, painéis e feeds para outros processos.

Esse fluxo de dados geral é compatível com muitos casos de uso de análise, como demonstrado no diagrama a seguir:

Estado inicial antes da migração.

O estado final da jornada é ter o maior número possível de casos de uso em execução no BigQuery. Desse modo, será possível minimizar o uso do data warehouse legado e, posteriormente, descontinuá-lo gradualmente. Você tem o controle sobre quais casos de uso serão migrados e quando isso acontecerá, priorizando os mais importantes durante a fase de preparação e descoberta da migração.

Transferir esquemas e dados para o BigQuery

Na fase de planejamento da migração, você identifica os casos de uso que quer migrar. Depois, inicia as iterações da migração na fase de execução. Para gerenciar as iterações, enquanto executa o ambiente de análise com o mínimo de interrupções, siga este processo geral:

Transfira as tabelas. Configure e teste os processos downstream.
- Transfira o grupo de tabelas de cada caso de uso para o BigQuery sem realizar qualquer alteração. Para isso, use o serviço de transferência de dados do BigQuery ou outra ferramenta de extração, transformação e carregamento (ETL, na sigla em inglês). Para mais informações sobre essas ferramentas, consulte a seção sobre transferência inicial de dados.
- Configure as versões de teste dos processos downstream para que eles possam fazer leituras nas tabelas do BigQuery.
Essa etapa inicial divide o fluxo de dados. No diagrama a seguir, mostramos o fluxo resultante. Agora, alguns sistemas downstream leem a partir do BigQuery, como mostrado nos fluxos "B". Outros ainda leem a partir do armazenamento de dados legado, como mostrado nos fluxos "A".
Configure alguns processos upstream de teste para gravar dados nas tabelas do BigQuery, e não no data warehouse atual ou além dele.

Após testar, configure seus processos de produção upstream e downstream para que façam leituras e gravações nas tabelas do BigQuery. Esses processos podem se conectar ao BigQuery por meio da API BigQuery e incorporar novos produtos de nuvem, como o Looker Studio e o Dataflow.

Agora, você tem três tipos de fluxos de dados:
1. Atual. Os dados e processos permanecem inalterados e ainda estão centralizados no data warehouse legado.
2. Fluxos transferidos: Os processos upstream alimentam o data warehouse legado. Os dados são transferidos para o BigQuery e depois alimentam os processos downstream.
3. Fluxos totalmente migrados: Os processos upstream e downstream não mais fazem leituras e gravações no data warehouse legado.
  No diagrama abaixo, mostramos um sistema com esses três tipos de fluxos:
Selecione outros casos de uso para migrá-los. Retorne à primeira etapa para iniciar uma nova iteração de execução. Continue a iteração repetindo as etapas até que todos os casos de uso sejam totalmente migrados para o BigQuery. Ao selecionar os casos de uso, convém revisitar aqueles que estão no estado de transferência para migrá-los totalmente. Nos casos de uso que são totalmente migrados, continue o processo de evolução seguindo as diretrizes em Aprimorar o esquema no BigQuery.

Evoluir o esquema no BigQuery

O esquema do data warehouse define como os dados são estruturados e os relacionamentos entre suas entidades de dados. O esquema está no centro do design de dados e influencia muitos processos, tanto upstream quanto downstream.

A migração do data warehouse é uma oportunidade única para evoluir o esquema após transferi-lo para o BigQuery. Nesta seção, você verá orientações sobre como evoluir seu esquema seguindo uma série de etapas. Seguir essas diretrizes ajuda a manter o ambiente de armazenamento de dados em execução durante as alterações do esquema, com o mínimo de interrupções dos processos upstream e downstream.

As etapas nesta seção são aplicáveis à transformação do esquema de um único caso de uso.

Dependendo do quanto você quer evoluir, pare em uma etapa intermediária ou continue até que seu sistema esteja evoluído por completo.

Transferir um caso de uso no estado em que se encontra para o BigQuery.

Antes de prosseguir para os próximos passos, verifique se os processos upstream e downstream do seu caso de uso já estão fazendo leituras e gravações no BigQuery. Porém, também é possível iniciar a partir de um estado intermediário em que apenas o processo downstream está fazendo leituras no BigQuery. Nesse caso, siga apenas as diretrizes relacionadas ao downstream. No diagrama a seguir, ilustramos um caso de uso em que os processos upstream e downstream fazem gravações e leituras nas tabelas do BigQuery.
Aplique otimizações leves.
1. Crie novamente suas tabelas aplicando particionamento e clustering. Nesta tarefa, se preferir, use o método de criar uma tabela a partir do resultado de uma consulta. Para mais detalhes, consulte a discussão e o exemplo de tabelas particionadas, bem como a discussão e o exemplo de tabelas em cluster.
2. Redirecione os processos upstream e downstream para as tabelas novas.
Criar visualizações de fachada.

Se você quiser evoluir ainda mais o esquema além das otimizações leves, crie visualizações de fachada para as tabelas. O padrão de fachada é um método de design que mascara o código ou as estruturas subjacentes para ocultar a complexidade. Nesse caso, as visualizações de fachada escondem as tabelas subjacentes para ocultar a complexidade resultante das alterações nas tabelas, realizadas pelos processos downstream.

As visualizações podem descrever um esquema novo, sem dívida técnica, modelado intencionalmente para novos cenários de transferência e consumo.

Em nível subjacente, as tabelas e a própria definição de consulta de visualização podem ser alteradas. No entanto, as visualizações abstraem essas alterações como detalhes de implementação interna do data warehouse e sempre retornam os mesmos resultados. Essa camada de abstração, composta de visualizações de fachada, isola os sistemas upstream e downstream das alterações durante o tempo que for necessário. As alterações são evidenciadas apenas quando apropriado.
Transformar os processos downstream.

É possível transformar alguns dos processos downstream para que façam leituras nas visualizações de fachada, em vez de nas próprias tabelas. Esses processos já serão beneficiados pelo esquema evoluído. Para eles, fica claro que, em nível subjacente, as visualizações de fachada ainda recebem dados do esquema legado do BigQuery, como mostrado no diagrama a seguir:

Descrevemos primeiro a transformação dos processos downstream. Isso permite demonstrar valor de negócios mais rapidamente, na forma de painéis ou relatórios migrados, do que se você transformasse processos upstream que não são visíveis para as pessoas interessadas sem funções técnicas. No entanto, também é possível iniciar a transformação pelos processos upstream. Qual tarefa terá prioridade dependerá exclusivamente das suas necessidades.
Transforme os processos upstream.

É possível transformar alguns dos processos upstream para que façam gravações no novo esquema. Como as visualizações são somente de leitura, crie tabelas com base no esquema novo e, em seguida, modifique a definição de consulta das visualizações de fachada. Algumas visualizações ainda realizarão consultas no esquema legado, enquanto outras consultarão as tabelas recém-criadas ou farão uma operação UNION do SQL em ambos, como mostrado no diagrama a seguir:

Nesse momento, é possível tirar proveito dos campos aninhados e repetidos ao criar as tabelas novas. Com isso, é possível desnormalizar ainda mais seu modelo e aproveitar diretamente a representação de dados em colunas subjacentes do BigQuery.

Um benefício das visualizações de fachada é que a transformação dos processos downstream pode continuar independentemente das alterações de esquema subjacentes e das ocorridas nos processos upstream.
Evoluir totalmente seu caso de uso.

Por fim, é possível transformar os processos upstream e downstream que faltam. Quando todos já estiverem evoluídos para fazer gravações nas tabelas novas e leituras nas novas visualizações de fachada, modifique as definições de consulta das visualizações de fachada para que deixem de realizar leituras no esquema legado. Assim, será possível desativar, no fluxo de dados, as tabelas do modelo legado. No diagrama a seguir, veja o estado em que as tabelas legadas não são mais usadas.

Se as visualizações de fachada não agregarem campos ou colunas de filtro, uma opção é configurar os processos downstream para que façam leituras nas tabelas evoluídas e, depois, desativar as visualizações de fachada para reduzir a complexidade, como demonstrado pelo diagrama a seguir:

Realizar uma transferência inicial do esquema e dados

Nesta seção, você verá considerações práticas sobre a migração do seu esquema e dados de um data warehouse atual para o BigQuery.

Recomendamos que você transfira o esquema sem qualquer mudança durante as iterações iniciais da migração. Isso oferecerá as seguintes vantagens:

Os data pipelines que alimentam o data warehouse não precisam ser ajustados para um esquema novo.
Você evitará incluir um esquema novo à lista de material de treinamento da sua equipe.
É possível aproveitar as ferramentas automatizadas para executar o esquema e a transferência de dados.

Além disso, as provas de conceito (PoCs, em inglês) e outras atividades de exploração de dados que utilizam recursos da nuvem continuarão sem impedimentos, mesmo com a migração ocorrendo em paralelo.

Escolher um método de transferência

Há várias abordagens possíveis para fazer a transferência inicial.

Para os data warehouses Amazon Redshift e Teradata, é possível usar o serviço de transferência de dados do BigQuery para carregar esquemas e dados diretamente do seu sistema atual para o BigQuery. O Cloud Storage ainda é usado para preparar os dados como parte do processo de migração.
Em qualquer data warehouse, é possível extrair os arquivos que contêm o esquema e os dados, fazer upload deles para o Cloud Storage e usar uma das seguintes opções para carregar o esquema e os dados desses arquivos no BigQuery:

Para mais considerações sobre a escolha de um método de transferência de dados, consulte Como escolher um método de ingestão de dados.

Considerar a transformação de dados

Dependendo do formato de extração de dados e se você quer cortar ou enriquecer seus dados antes de carregá-los no BigQuery, talvez inclua uma etapa para transformar seus dados. É possível transformar os dados no ambiente atual ou no Google Cloud:

Se você transformar os dados no ambiente atual, pense em como a capacidade de computação e as ferramentas disponíveis podem limitar a capacidade de processamento. Além disso, se você estiver enriquecendo os dados durante o processo de transformação, considere se precisa de mais tempo de transferência ou da largura de banda da rede.
Se você transformar os dados no Google Cloud, consulte Carregar dados usando uma ferramenta de ETL para mais informações sobre as opções.

Extrair o esquema e os dados legados em arquivos

Sua plataforma legada provavelmente oferece uma ferramenta para exportar dados para um formato que independe do fornecedor, como o Apache AVRO ou CSV. Para reduzir a complexidade da transferência, recomendamos o uso do AVRO, ORC ou Parquet, onde as informações do esquema são incorporadas aos dados. Se você escolher CSV ou um formato semelhante, simples e delimitado de dados, será necessário especificar o esquema separadamente. O modo de fazer isso depende do método de transferência de dados selecionado. Por exemplo, para o envio em lote, é possível especificar um esquema no momento do carregamento ou permitir a detecção automática do esquema com base no conteúdo do arquivo CSV.

Copie os arquivos da plataforma atual para copiá-los no preparo do armazenamento do ambiente atual.

Fazer upload dos arquivos para o Cloud Storage

A menos que você esteja usando o serviço de transferência de dados do BigQuery para carregar dados diretamente de um data warehouse existente do Amazon Redshift ou Teradata, é necessário fazer upload dos arquivos extraídos para um bucket no Cloud Storage. Dependendo do volume de dados que você estiver transferindo e da largura de banda de rede disponível, escolha uma das opções de transferência a seguir:

Se os dados extraídos estiverem em outro provedor de nuvem, use o serviço de transferência do Cloud Storage.
Se os dados estiverem em um ambiente local ou em uma instalação de colocation com uma boa largura de banda de rede, use a CLI do Google Cloud. A gcloud CLI aceita uploads paralelos com várias linhas de execução, retoma a operação após erros e criptografa o tráfego em trânsito para fins de segurança.
- Se não for possível usar a gcloud CLI, use uma ferramenta de terceiros de um parceiro do Google.
- Se a largura de banda da rede for limitada, será possível usar técnicas de compactação para limitar o tamanho dos dados, ou modificar sua conexão atual com o Google Cloud, para aumentar a largura de banda.
Se você não conseguir largura de banda suficiente, realize a transferência off-line usando um Transfer Appliance.

Ao criar um bucket do Cloud Storage e iniciar a transferência de dados por meio da rede, escolha o local mais próximo do seu data center para minimizar a latência da rede. Se possível, escolha o local do bucket como o mesmo do conjunto de dados do BigQuery.

Para informações detalhadas sobre práticas recomendadas de migração de dados para o Cloud Storage, incluindo estimativa de custos, consulte Estratégias para transferir conjuntos de Big Data.

Carregar o esquema e os dados no BigQuery

Carregue o esquema e os dados no BigQuery usando uma das opções discutidas em Escolher um método de transferência.

Para mais informações sobre carregamentos únicos, consulte Introdução ao carregamento de dados do Cloud Storage na documentação do BigQuery. Para mais informações sobre carregamentos programados em intervalos regulares, consulte Visão geral das transferências do Cloud Storage na documentação do serviço de transferência de dados do BigQuery.

Carregar dados usando uma ferramenta ETL

Se os dados precisarem de mais transformações à medida que vão sendo carregados no BigQuery, use uma das seguintes opções:

Cloud Data Fusion. Esta ferramenta cria graficamente pipelines de dados ETL/ELT totalmente gerenciados usando uma biblioteca de código aberto de transformações e conectores pré-configurados.
Dataflow. Esta ferramenta define e executa transformações de dados complexas e gráficos de enriquecimento usando o modelo do Apache Beam. O Dataflow é sem servidor e totalmente gerenciado pelo Google, oferecendo acesso a uma capacidade de processamento praticamente ilimitada.
Dataproc. Esta ferramenta executa o cluster do Apache Spark e do Apache Hadoop em um serviço de nuvem totalmente gerenciado.
Ferramentas de terceiros. entre em contato com um de nossos parceiros. Eles podem oferecer opções eficazes se você quiser externalizar a criação do pipeline de dados.

No diagrama a seguir, veja o padrão descrito nesta seção. A ferramenta de transferência de dados é a gcloud CLI, e há uma etapa de transformação que usa o Dataflow e grava diretamente no BigQuery, talvez usando o Conector de E/S do Google BigQuery integrado do Apache Beam.

O data warehouse atual copia os dados para o armazenamento temporário no local. A gcloud CLI copia os dados para um bucket do Cloud Storage. O Dataflow faz a leitura do bucket de preparo e transfere os dados para o BigQuery.

Depois de carregar um conjunto de dados inicial, é possível começar a utilizar os recursos avançados do BigQuery.

No entanto, assim como na transferência do esquema, fazer o upload de dados é parte de um processo iterativo. É possível iniciar as iterações subsequentes expandindo a abrangência dos dados a serem transferidos para o BigQuery. Depois, você pode redirecionar seus feeds de dados upstream para o BigQuery para eliminar a necessidade de manter seu data warehouse em execução. Esses tópicos serão explorados na próxima seção.

Validar os dados

Agora que seus dados estão no BigQuery, é possível verificar o sucesso da sua transferência de dados com a Ferramenta de validação de dados (DVT). A DVT é uma ferramenta de Python de código aberto que permite comparar dados de várias origens com seu destino no BigQuery. Especifique a quais agregações você gostaria de executar (por exemplo, contagem, soma, média) e as colunas a que isso se aplica. Para mais informações, consulte Automatizar a validação de dados com DVT.

Iterar na transferência inicial

Nesta seção, você verá como proceder após a transferência de dados inicial, para aproveitar o BigQuery da melhor maneira possível.

Agora, há um subconjunto dos seus dados no BigQuery. Você está se preparando para aumentar a ocupação dos dados a serem usados no BigQuery e, portanto, reduzir a dependência do data warehouse legado.

O método a escolher para realizar as iterações subsequentes depende da importância da atualização de dados frequente para o caso de uso. Se os analistas de dados puderem trabalhar com dados incorporados ao armazenamento de dados em intervalos recorrentes, o ideal é escolher uma opção programada. É possível criar transferências programadas de maneira semelhante à transferência inicial. Para isso, use o serviço de transferência de dados do BigQuery, outras ferramentas de ETL, como o serviço de transferência do Cloud Storage ou implementações de terceiros.

Se você escolher o serviço de transferência de dados do BigQuery, será necessário primeiro decidir quais tabelas serão migradas. Depois, crie um padrão de nome para essas tabelas. Por fim, defina uma programação recorrente para a execução da transferência.

Por outro lado, se seu caso de uso exigir acesso quase instantâneo aos dados novos, será necessário adotar uma abordagem de streaming. Você tem duas opções:

Configurar um pipeline de carga com produtos do Google Cloud. O Google oferece um conjunto de modelos de streaming do Dataflow para facilitar essa tarefa.
Use uma solução de um dos nossos parceiros.

Em curto prazo, o ideal é que sua estratégia para aumentar a abrangência dos seus dados no BigQuery e do uso deles em processos downstream seja voltada para satisfazer os casos de uso mais prioritários, com uma meta de médio prazo de abandonar a fonte de dados legada. Use as iterações iniciais com sabedoria e não gaste muitos recursos aperfeiçoando os pipelines de ingestão do seu armazenamento de dados atual para o BigQuery. Em última análise, será necessário adaptar esses pipelines para não usar o data warehouse atual.

Otimizar o esquema

A simples migração das tabelas para o BigQuery permite que você aproveite os recursos exclusivos. Por exemplo, não é necessário recriar os índices nem embaralhar novamente os blocos de dados (comando vacuum). Além disso também não ocorrerá qualquer período de inatividade ou queda de desempenho por causa dos upgrades de versão.

No entanto, manter o modelo de armazenamento de dados intacto além das iterações iniciais da migração também tem algumas desvantagens:

Os problemas legados e a dívida técnica associados ao esquema permanecerão.
As otimizações de consulta serão limitadas e talvez precisarão ser refeitas se o esquema for atualizado posteriormente.
Você não conseguirá aproveitar completamente outros recursos do BigQuery, como campos aninhados e repetidos, particionamento e clustering.

Ao fazer uma transferência final, recomendamos que você melhore o desempenho do sistema aplicando o particionamento e o clustering às tabelas criadas no esquema.

Particionamento

O BigQuery permite dividir os dados em segmentos, denominados partições, o que torna mais fácil e eficiente gerenciar e consultar os dados. É possível particionar tabelas com base em uma coluna TIMESTAMP ou DATE ou deixar o BigQuery adicionar pseudocolunas para particionar automaticamente os dados durante a ingestão. O desempenho pode ser melhor nas consultas que envolvem partições menores, visto que elas verificam apenas um subconjunto dos dados e reduzem os custos devido ao menor número de bytes lidos.

O particionamento não afeta a estrutura atual das tabelas. Portanto, considere a criação de tabelas particionadas, mesmo que seu esquema não seja modificado.

Cluster

No BigQuery, não são utilizados índices para consultar os dados. O desempenho do BigQuery é otimizado pelo modelo subjacente, técnicas de armazenamento e consulta e pela arquitetura massivamente paralela. Quando você executa uma consulta, mais máquinas são adicionadas de acordo com o volume de dados processados para, simultaneamente, verificar os dados e agregar os resultados. Essa técnica apresenta boa capacidade de escalonamento para conjuntos de dados imensos, ao contrário do que acontece com a recriação de índices.

No entanto, existe margem para mais otimização de consulta usando técnicas como a de clustering. Por meio do clustering, o BigQuery classifica automaticamente os dados com base nos valores de poucas colunas especificadas por você e as coloca em blocos com o tamanho ideal. O desempenho de consulta fica melhor depois de fazer o clustering, em comparação a não fazê-lo. Com o clustering, o BigQuery consegue estimar melhor o custo de executar a consulta. Além disso, colocar as colunas em clusters também elimina as verificações de dados desnecessários e acelera o cálculo das agregações porque os registros de valor semelhante são colocados juntos no mesmo bloco.

Examine suas consultas em busca das colunas frequentemente usadas para filtragem e crie as tabelas com clustering nessas colunas. A técnica de clustering exige tabelas particionadas e também é definida no momento de criação da tabela.

Desnormalização

A migração de dados é um processo iterativo. Portanto, depois de migrar o esquema inicial para a nuvem, realizar as otimizações leves e testar alguns dos principais casos de uso, é hora de explorar os demais recursos que se beneficiem do design subjacente do BigQuery. Esses recursos incluem os campos aninhados e repetidos.

Tradicionalmente, os armazenamento de dados usam os seguintes modelos:

Esquema em estrela: é um modelo desnormalizado, em que uma tabela de fatos coleta métricas, como valor do pedido, desconto e quantidade, junto com um grupo de chaves. Essas chaves pertencem às tabelas de dimensão, como cliente, fornecedor, região etc. Graficamente, o modelo se assemelha a uma estrela com a tabela de fatos no centro, cercada pelas tabelas de dimensão.
Esquema em floco de neve (em inglês): é semelhante ao esquema estrela, mas as tabelas de dimensão são normalizadas, o que dá a ele a aparência de um floco de neve único.

O BigQuery é compatível com ambos os esquemas, mas sua representação nativa não é em nenhum dos dois. Ele usa campos aninhados e repetidos para representar os dados de maneira mais natural. Para mais informações, consulte o exemplo de esquema na documentação do BigQuery.

Alterar o esquema para usar campos aninhados e repetidos é uma opção excelente que apresenta uma grande evolução. Isso reduz o número de mesclagens necessárias para as consultas e alinha o esquema à representação de dados interna do BigQuery. Internamente, o BigQuery organiza os dados usando o modelo Dremel e os armazena em um formato de armazenamento em colunas chamado Capacitor.

Para decidir a melhor abordagem de desnormalização para seu caso, considere as práticas recomendadas para desnormalização no BigQuery, bem como as técnicas para gerenciar mudanças no esquema.

A seguir

Saiba mais sobre as seguintes etapas na migração do armazenamento de dados:

Também é possível aprender sobre a migração de tecnologias específicas do data warehouse para o BigQuery: