Visão geral: migrar armazenamentos de dados para o BigQuery

Neste documento, falamos sobre os conceitos gerais que se aplicam a qualquer tecnologia de armazenamento em data warehouse e descrevemos um framework que pode ser usado para organizar e estruturar sua migração para o BigQuery.

Terminologia

Usamos a seguinte terminologia para falar sobre a migração de data warehouse:

Caso de uso
Um caso de uso consiste em todos os conjuntos de dados, processamento de dados e interações de sistema e usuário necessários para conseguir valor comercial, como o rastreamento de volumes de vendas de um produto ao longo do tempo. Em armazenamento de dados, o caso de uso geralmente consiste nos itens a seguir:
  • Pipelines de dados que ingerem dados brutos de várias origens de dados, como o banco de dados de gestão de relacionamento com o cliente (CRM, na sigla em inglês).
  • Os dados localizados no armazenamento de dados.
  • Scripts e procedimentos para manipular, além de processar e analisar os dados.
  • Um aplicativo comercial que lê ou interage com os dados.
Carga de trabalho
Um conjunto de casos de uso que estão conectados e têm dependências compartilhadas. Por exemplo, um caso de uso pode ter os relacionamentos e as dependências a seguir:
  • O relatório de compras pode ser independente e útil para entender os gastos e solicitar descontos.
  • Os relatórios de vendas podem ser independentes e são úteis para o planejamento de campanhas de marketing.
  • Os relatórios de lucros e perdas, no entanto, dependem de compras e vendas e são úteis para determinar o valor da empresa.
Aplicativo comercial
Um sistema com que os usuários finais interagem. Por exemplo, um relatório visual ou painel. Um aplicativo comercial também pode assumir a forma de um pipeline de dados operacionais ou ciclo de feedback. Por exemplo, após o cálculo ou a previsão das alterações de preço do produto, um pipeline de dados operacionais poderá atualizar os preços do produto novo em um banco de dados transacional.
Processo upstream
Os sistemas de origem e os pipelines de dados que carregam dados no armazenamento de dados.
Processo downstream
Os scripts, procedimentos e aplicativos comerciais usados para processar, consultar e visualizar os dados no armazenamento de dados.
Migração de transferência
Uma estratégia de migração que visa colocar o caso de uso em funcionamento para o usuário final no novo ambiente o mais rápido possível ou para tirar proveito da capacidade extra disponível no novo ambiente. Os casos de uso são transferidos por meio das etapas a seguir:
  • cópia e sincronização do esquema e dos dados do armazenamento de dados legado
  • Migração dos scripts, procedimentos e aplicativos comerciais downstream

A transferência de migração pode aumentar a complexidade e o trabalho envolvido na migração de pipelines de dados.

Migração completa
Uma abordagem de migração é como uma migração de transferência, porém, em vez de copiar e sincronizar o esquema e os dados, você configura a migração para ingerir dados diretamente no novo data warehouse em nuvem dos sistemas de origem upstream. Em outras palavras, os pipelines de dados necessários para o caso de uso também são migrados.
Armazenamento de dados empresarial (EDW, na sigla em inglês)
Um armazenamento de dados que consiste não apenas em um banco de dados analítico, mas também em vários componentes e procedimentos analíticos críticos, como pipelines de dados, consultas e aplicativos comerciais necessários para atender às cargas de trabalho da organização.
Armazenamento de dados na nuvem (CDW, na sigla em inglês)
Um armazenamento de dados que tem as mesmas características de um EDW, mas é executado em um serviço totalmente gerenciado na nuvem (neste caso, o BigQuery).
Pipeline de dados
Um processo que conecta sistemas de dados por meio de uma série de funções e tarefas que realizam vários tipos de transformação de dados. Para detalhes, consulte O que é um pipeline de dados? nesta série.

Por que migrar para o BigQuery?

Nas últimas décadas, as organizações dominaram a ciência do armazenamento de dados. Elas aplicam cada vez mais análises descritivas a grandes quantidades de dados armazenados, ganhando insights sobre as principais operações comerciais. O Business Intelligence (BI) convencional, focado em consultas, relatórios e processamento analítico on-line (em inglês), pode ter sido um diferencial no passado, elevando ou arruinando uma empresa, mas agora isso não é suficiente.

Hoje, as organizações precisam entender eventos anteriores usando análises descritivas. Elas também precisam de uma análise preditiva (em inglês), que geralmente usa machine learning (ML) para extrair padrões de dados e fazer afirmações probabilísticas sobre o futuro. O objetivo final é desenvolver análises prescritivas que combinem lições do passado com previsões do futuro para nortear automaticamente ações em tempo real.

As práticas tradicionais de armazenamento de dados capturam dados brutos de várias fontes, que geralmente são sistemas de processamento de transações on-line (OLTP, na sigla em inglês). Em seguida, um subconjunto de dados é extraído em lotes, transformado com base em um esquema definido e carregado no armazenamento de dados. Como os armazenamentos de dados tradicionais capturam um subconjunto de dados em lotes e armazenam dados com base em esquemas rígidos, eles não são adequados para manipular análises em tempo real ou responder a consultas espontâneas. Em parte, o Google projetou o BigQuery em resposta a essas limitações inerentes.

As ideias inovadoras costumam ser desaceleradas pelo tamanho e pela complexidade da organização de TI que implementa e mantém esses armazenamentos de dados tradicionais. A criação de uma arquitetura de armazenamento de dados escalonável, altamente disponível e segura pode levar anos e investimentos substanciais. O BigQuery oferece uma tecnologia de software como serviço (SaaS, na sigla em inglês) sofisticada que pode ser usada para operações de armazenamento de dados sem servidor. Desse modo, você se dedica a melhorar seu negócio principal e delega ao Google Cloud a manutenção da infraestrutura e o desenvolvimento da plataforma.

O BigQuery oferece acesso a armazenamento de dados estruturados, processamento e análises escalonáveis, flexíveis e econômicos. Essas características são essenciais para os clientes quando os volumes de dados crescem exponencialmente, a fim de disponibilizar os recursos de armazenamento e processamento conforme necessário e retirar valor desses dados. Além disso, para organizações que estão começando com a análise de Big Data e machine learning e querem evitar as complexidades potenciais dos sistemas de Big Data locais, o BigQuery permite testar os serviços gerenciados mediante pagamento por utilização.

Com o BigQuery, é possível encontrar respostas para problemas que antes não tinham solução, aplicar machine learning para descobrir padrões de dados emergentes e testar novas hipóteses. Como resultado, você tem insights oportunos sobre o desempenho dos negócios, o que permite modificar processos para conseguir resultados melhores. Além disso, a experiência do usuário final é muitas vezes enriquecida com insights relevantes extraídos da análise de big data, conforme explicaremos mais adiante nesta série.

O que e como migrar: o framework da migração

Realizar uma migração pode ser um empreendimento complexo e demorado. Portanto, recomendamos aderir a uma estrutura para organizar e estruturar o trabalho de migração em fases:

  1. Preparar e descobrir: prepare-se para sua migração com a descoberta de cargas de trabalho e casos de uso.
  2. Planejar: priorize casos de uso, defina medidas de sucesso e planeje sua migração.
  3. Executar: itera as etapas da migração, da avaliação à validação.

Preparar e descobrir

Na fase inicial, o foco está na preparação e na descoberta. Trata-se de oferecer a você e às partes interessadas uma oportunidade inicial de descobrir os casos de uso atuais e levantar preocupações iniciais. É importante ressaltar que você também realiza uma análise inicial sobre os benefícios esperados. Isso inclui ganhos de desempenho (por exemplo, concorrência aprimorada) e reduções no custo total de propriedade (TCO, na sigla em inglês). Essa fase é crucial para ajudar a estabelecer o valor da migração.

Um armazenamento de dados normalmente aceita uma ampla variedade de casos de uso e tem um grande número de partes interessadas, de analistas de dados a tomadores de decisão de negócios. Recomendamos que você envolva representantes desses grupos para entender bem quais casos de uso existem, se esses casos têm bom desempenho e se as partes interessadas estão planejando casos de uso novos.

O processo da fase de descoberta consiste nas seguintes tarefas:

  1. Examine a proposta de valor do BigQuery e compare-a à do seu armazenamento de dados legado.
  2. Realize uma análise inicial do TCO.
  3. Estabeleça quais casos de uso são afetados pela migração.
  4. Modele as características dos conjuntos de dados e pipelines de dados subjacentes que você quer migrar para identificar dependências.

Para conseguir insights sobre os casos de uso, desenvolva um questionário para coletar informações de especialistas no assunto (SMEs, na sigla em inglês), usuários finais e partes interessadas. O questionário precisa reunir as seguintes informações:

  • Qual é o objetivo do caso de uso? Qual é o valor comercial?
  • Quais são os requisitos não funcionais? Atualização de dados, uso simultâneo e assim por diante.
  • O caso de uso faz parte de uma carga de trabalho maior? Ele depende de outros casos de uso?
  • Quais conjuntos de dados, tabelas e esquemas sustentam o caso de uso?
  • O que você sabe sobre os pipelines de dados que alimentam esses conjuntos de dados?
  • Quais ferramentas, relatórios e painéis de BI são usados atualmente?
  • Quais são os requisitos técnicos atuais sobre necessidades operacionais, desempenho, autenticação e largura de banda da rede?

O diagrama a seguir mostra uma arquitetura legada de alto nível antes da migração. Nele, ilustramos o catálogo de fontes de dados disponíveis, pipelines de dados legados, loops de feedback e pipelines operacionais legados e relatórios e painéis do BI legados que são acessados pelos usuários finais.

Armazém de dados legado, mostrando fontes de dados (Vendas, Marketing, Manufatura, Orçamentação etc.) que alimentam o armazenamento de dados. Relatórios e painéis de BI são processos downstream.

Plano

A fase de planejamento consiste em pegar a entrada da fase de preparação e descoberta, avaliar essa entrada e usá-la para planejar a migração. Essa fase pode ser dividida nas seguintes tarefas:

  1. Catalogar e priorizar casos de uso

    Recomendamos que você divida o processo de migração em iterações. Você cataloga casos de uso novos e atuais e atribui a eles uma prioridade. Para mais detalhes, consulte as seções Migrar usando uma abordagem iterativa e Priorizar casos de uso deste documento.

  2. Definir medidas de sucesso

    É útil definir medidas claras de sucesso, como indicadores principais de desempenho (KPIs, na sigla em inglês), antes da migração (link em inglês). Suas medidas permitirão avaliar o sucesso da migração a cada iteração. Isso, por sua vez, permite fazer melhorias no processo de migração em iterações posteriores.

  3. Criar uma definição de "concluído"

    Com migrações complexas, não é necessariamente óbvio quando você termina de migrar um determinado caso de uso. Portanto, é preciso descrever uma definição formal do estado final pretendido. Essa definição precisa ser genérica o suficiente para que possa ser aplicada a todos os casos de uso que você queira migrar. A definição precisa atuar como um conjunto de critérios mínimos para que você considere o caso de uso a ser totalmente migrado. Essa definição geralmente inclui pontos de verificação para garantir que o caso de uso tenha sido integrado, testado e documentado.

  4. Projetar e propor uma prova de conceito (POC, na sigla em inglês), um estado de curto prazo e um estado final ideal

    Depois de priorizar seus casos de uso, comece a pensar neles durante todo o período da migração. Considere a primeira migração de caso de uso como uma prova de conceito (PoC, na sigla em inglês) para validar a abordagem de migração inicial. Considere o que é possível nas primeiras semanas ou meses como o estado de curto prazo. Como seus planos de migração afetarão os usuários? Eles terão uma solução híbrida ou será possível migrar uma carga de trabalho inteira primeiro para um subconjunto de usuários?

  5. Criar estimativas de tempo e custo

    Para garantir um projeto de migração bem-sucedido, é importante produzir estimativas de tempo realistas. Para conseguir isso, envolva-se com todas as partes interessadas relevantes para conversar sobre a disponibilidade deles e concordar com o nível de envolvimento deles ao longo do projeto. Isso ajudará a estimar os custos de mão de obra com mais precisão. Para estimar os custos relacionados ao consumo de recursos projetados na nuvem, consulte Como estimar custos de armazenamento e consulta e Introdução ao controle de custos no BigQuery na documentação do BigQuery.

  6. Identificar e envolver um parceiro de migração

    A documentação do BigQuery descreve muitas ferramentas e recursos que podem ser usados para realizar a migração. No entanto, pode ser um desafio realizar uma migração grande e complexa por conta própria, se você não tem experiência anterior ou não conta com todo o conhecimento técnico necessário em sua organização. Portanto, recomendamos que você identifique e envolva um parceiro de migração desde o início. Para mais detalhes, consulte nossos programas de parceiros globais e serviços de consultoria.

Migrar usando uma abordagem iterativa

Ao migrar uma grande operação de armazenamento de dados para a nuvem, é uma boa ideia adotar uma abordagem iterativa. Portanto, recomendamos que você faça a transição para o BigQuery em iterações. Dividir o esforço de migração em iterações facilita o processo geral, reduz riscos e oferece oportunidades de aprendizado e aprimoramento após cada iteração.

Uma iteração consiste em todo o trabalho necessário para transferir ou migrar totalmente um ou mais casos de uso relacionados dentro de um período limitado. Pense em uma iteração como um ciclo de sprint na metodologia ágil, consistindo em uma ou mais histórias de usuário.

Por conveniência e facilidade de rastreamento, considere associar um caso de uso individual a uma ou mais histórias de usuário. Por exemplo, considere a seguinte história de usuário: "como analista de preços, quero analisar as alterações de preços de produtos no último ano para poder calcular preços futuros".

Confira como pode ser o caso de uso correspondente:

  • Ingestão de dados de um banco de dados transacional que armazena produtos e preços.
  • Transformação dos dados em uma única série temporal para cada produto e inserção dos valores ausentes.
  • Armazenamento dos resultados em uma ou mais tabelas no armazenamento de dados.
  • Disponibilização dos resultados por meio de um notebook Python (o aplicativo comercial).

O valor comercial deste caso de uso é auxiliar a análise de preços.

Como na maioria dos casos de uso, esse provavelmente auxiliará várias histórias de usuário.

Um caso de uso transferido provavelmente será seguido por uma iteração subsequente para migrá-lo de modo completo. Caso contrário, talvez ainda exista uma dependência do armazenamento de dados legado e atual, porque os dados são copiados a partir daí. A migração completa subsequente é o delta entre a transferência e uma migração completa que não foi precedida por uma transferência. Em outras palavras, a migração dos pipelines de dados para extrair, transformar e carregar os dados no armazenamento de dados.

Priorizar casos de uso

O início ou o término de cada migração depende das suas necessidades de negócio específicas. A decisão da ordem na qual você migra os casos de uso é importante, porque o sucesso inicial durante uma migração é crucial para continuar no caminho da adoção da nuvem. Ter uma falha no estágio inicial pode se tornar um sério revés no processo geral da migração. É possível que você tenha os benefícios do Google Cloud e do BigQuery, mas o processamento de todos os conjuntos de dados e pipelines de dados que foram criados ou gerenciados em seu armazenamento de dados legado para diferentes casos de uso pode ser complicado e demorado.

Mesmo sem haver uma resposta única para todos os casos, há práticas recomendadas que podem ser usadas durante a avaliação de aplicativos comerciais e casos de uso locais. Esse tipo de planejamento inicial pode facilitar o processo de migração e toda a transição para o BigQuery.

As seções a seguir exploram possíveis abordagens para priorizar casos de uso.

Abordagem: explorar as oportunidades atuais

Observe as oportunidades atuais que podem ajudar você a maximizar o retorno do investimento de um caso de uso específico. Essa abordagem é especialmente útil se você estiver sob pressão para justificar o valor comercial da migração para a nuvem. Ela também oferece a oportunidade de reunir pontos de dados adicionais para ajudar a avaliar o custo total da migração.

Confira aqui alguns exemplos de perguntas a serem feitas para ajudar a identificar quais casos de uso priorizar:

  • O caso de uso consiste em conjuntos de dados ou pipelines de dados atualmente limitados pelo armazenamento de dados empresarial legado?
  • Seu armazenamento de dados empresarial atual exige uma atualização de hardware ou você está antecipando a necessidade de expandir seu hardware? Nesse caso, pode ser atraente transferir casos de uso para o BigQuery mais cedo ou mais tarde.

A identificação de oportunidades de migração pode criar algumas vitórias rápidas que geram benefícios tangíveis e imediatos para os usuários e os negócios.

Abordagem: migrar primeiro as cargas de trabalho analíticas

Migre as cargas de trabalho de processamento analítico on-line OLAP antes das cargas de trabalho de processamento de transações on-line (OLTP). Um armazenamento de dados geralmente é o único local da organização em que você tem todos os dados para criar uma visão global e única das operações da organização. Portanto, é comum que as organizações tenham alguns pipelines de dados que retornam aos sistemas transacionais para atualizar o status ou acionar processos. Por exemplo, para comprar mais produtos quando o estoque de um produto está baixo. As cargas de trabalho OLTP tendem a ser mais complexas e ter contratos de nível de serviço (SLAs, na sigla em inglês) e requisitos operacionais mais rigorosos que as cargas de trabalho OLAP. Portanto, também é mais fácil migrar as cargas de trabalho OLAP primeiro.

Abordagem: foco na experiência do usuário

Identifique oportunidades para aprimorar a experiência do usuário migrando conjuntos de dados específicos e permitindo novos tipos de análises avançadas. Por exemplo, uma maneira de aprimorar a experiência do usuário é com a análise em tempo real. Crie experiências do usuário sofisticadas em torno de um fluxo de dados em tempo real quando elas são fundidas com dados históricos. Exemplo:

  • um funcionário de back-office que recebeu alerta de estoque baixo do app para dispositivos móveis
  • uma cliente on-line que se beneficiaria caso fosse avisada que a próxima compra de um dólar a colocaria em um nível acima no programa de recompensas
  • Uma enfermeira que seria notificada sobre os sinais vitais de um paciente no smartwatch dela, possibilitando que ela tome o melhor curso de ação, além de ter o histórico de tratamento do paciente disponível no tablet dela.

Também é possível aprimorar a experiência do usuário com análises preditivas e prescritivas. Para isso, é possível usar modelos pré-treinados do BigQuery ML, do Vertex AI AutoML tabular ou do Google para análise de imagens, análise de vídeos, reconhecimento de fala, linguagem natural e tradução. Outra opção é exibir seu modelo treinado de maneira personalizada usando a Vertex AI para casos de uso adaptados às suas necessidades de negócios. Isso pode envolver as opções a seguir:

  • A recomendação de um produto com base nas tendências de mercado e no comportamento de compra do usuário.
  • previsão de um atraso no voo
  • detecção de atividades fraudulentas
  • sinalização de conteúdo inadequado
  • Outras ideias inovadoras que podem diferenciar seu aplicativo da concorrência.
Abordagem: priorizar casos de uso de risco menor

Há várias perguntas que a TI pode fazer para ajudar a avaliar quais casos de uso são os menos arriscados para migrar, o que faz deles os mais atraentes nas fases iniciais da migração. Por exemplo:

  • Qual é a criticidade comercial deste caso de uso?
  • Um grande número de funcionários ou clientes depende do caso de uso?
  • Qual é o ambiente de destino (por exemplo, desenvolvimento ou produção) do caso de uso?
  • Qual é o entendimento da nossa equipe de TI sobre o caso de uso?
  • Quantas dependências e integrações tem o caso de uso?
  • Nossa equipe de TI conta com uma documentação adequada, atualizada e completa para o caso de uso?
  • Quais são os requisitos operacionais (SLAs) para o caso de uso?
  • Quais são os requisitos de conformidade legais ou governamentais para o caso de uso?
  • Quais são as sensibilidades de latência e inatividade para acessar o conjunto de dados subjacente?
  • Há proprietários de linhas de negócios ansiosos e dispostos a migrar os casos de uso de modo antecipado?

Analisar esta lista de perguntas pode ajudar você a classificar conjuntos e pipelines de dados do menor risco para o maior. Os ativos de risco baixo precisam ser migrados primeiro, e os de risco maior precisam vir depois.

Executar

Depois de coletar informações sobre os sistemas legados e criar um backlog priorizado de casos de uso, agrupe os casos de uso em cargas de trabalho e prossiga com a migração nas iterações.

Uma iteração pode consistir em um único caso de uso, alguns casos de uso separados ou vários casos de uso pertencentes a uma única carga de trabalho. A escolha de uma dessas opções para a iteração depende da interconectividade dos casos de uso, das dependências compartilhadas e dos recursos disponíveis para a realização do trabalho.

Normalmente, uma migração contém as etapas a seguir:

Processo de migração em sete etapas.

Esses níveis são descritos em mais detalhes nas seções a seguir. Talvez não seja necessário executar todas essas etapas em cada iteração. Por exemplo, em uma iteração, você pode optar por copiar alguns dados do seu armazenamento de dados legado para o BigQuery. Por outro lado, em uma iteração subsequente, é possível se concentrar em modificar o pipeline de ingestão oriunda de uma fonte de dados original diretamente para o BigQuery.

1. Configuração e governança de dados

A configuração é o trabalho básico necessário para permitir a execução dos casos de uso no Google Cloud. A configuração pode incluir a definição dos projetos do Google Cloud, da rede, da nuvem privada virtual (VPC, na sigla em inglês) e da governança de dados. Isso também inclui desenvolver um bom entendimento de onde você está hoje em dia, o que funciona e o que não funciona. Isso ajuda a entender os requisitos do esforço de migração. Use o recurso de avaliação de migração do BigQuery para ajudar você nessa etapa.

A governança de dados é uma abordagem baseada em princípios para gerenciar dados durante o ciclo de vida, desde a aquisição até o uso e o descarte. Seu programa de governança de dados descreve claramente políticas, procedimentos, responsabilidades e controles relacionados às atividades de dados. Esse programa ajuda a garantir que as informações sejam coletadas, mantidas, usadas e disseminadas de maneira a atender à integridade dos dados e às necessidades de segurança da organização. Também ajuda a capacitar seus funcionários a descobrir e usar os dados com todo o potencial deles.

No documento de governança de dados, você entende a governança de dados e os controles necessários durante a migração de seu data warehouse local para o BigQuery.

2. Migrar esquema e dados

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

Na documentação de esquema e transferência de dados, fornecemos informações abrangentes sobre como mover seus dados para o BigQuery e recomendações para atualizar seu esquema para aproveitar ao máximo os recursos do BigQuery.

3. Traduzir consultas

Use a tradução SQL em lote para migrar os códigos SQL em massa ou a tradução de SQL interativo para traduzir consultas ad-hoc.

Alguns armazenamento de dados herdados incluem extensões para o padrão SQL para ativar a funcionalidade do produto. O BigQuery não aceita essas extensões proprietárias; o produto está em conformidade com o padrão ANSI/ISO SQL:2011. Isso significa que algumas consultas ainda poderão precisar de refatoração manual se os tradutores de SQL não puderem interpretá-las.

4. Migrar aplicativos comerciais

Os aplicativos comerciais podem assumir várias formas, de painéis a aplicativos personalizados e pipelines de dados operacionais que fornecem loops de feedback a sistemas transacionais.

Para saber mais sobre as opções de análise ao trabalhar com o BigQuery, consulte a Visão geral da análise do BigQuery. Este tópico apresenta uma visão geral das ferramentas de análise e relatórios que você pode usar para receber insights interessantes dos seus dados.

Na seção sobre ciclos de feedback, no documento de pipeline de dados, descrevemos como é possível usar um pipeline de dados para criar um ciclo de feedback a fim de provisionar sistemas upstream.

5. Migrar pipelines de dados

No documento de pipelines de dados, apresentamos procedimentos, padrões e tecnologias para migrar seus pipelines de dados legados para o Google Cloud. Com esse documento, você entende o que é um pipeline de dados, os procedimentos e padrões que ele pode empregar e as tecnologias e opções de migração que estão disponíveis para uma migração de data warehouse maior.

6. Otimizar o desempenho

O BigQuery processa dados com eficiência para conjuntos de dados pequenos e em escala de petabytes. Com a ajuda do BigQuery, seus jobs de análise terão um bom desempenho sem modificação no seu armazenamento de dados recém-migrado. Se você achar que, em determinadas circunstâncias, o desempenho da consulta não atende às suas expectativas, consulte Introdução à otimização do desempenho da consulta para conferir orientações.

7. Verificar e validar

No final de cada iteração, valide se a migração de casos de uso foi bem-sucedida, verificando os itens a seguir:

  • Os dados e o esquema foram totalmente migrados.
  • As preocupações de governança de dados foram totalmente atendidas e testadas.
  • A automação e os procedimentos de manutenção e monitoramento foram estabelecidos.
  • As consultas foram convertidas corretamente.
  • Os pipelines de dados migrados funcionam conforme o esperado.
  • Os aplicativos comerciais foram configurados corretamente para acessar as consultas e os dados migrados.

É possível começar a usar a ferramenta de validação de dados, uma ferramenta de CLI do Python de código aberto, que compara os dados dos ambientes de origem e de destino para garantir que eles sejam correspondentes. Ele é compatível com vários tipos de conexão, além de funcionalidade de validação de vários níveis.

Também é uma boa ideia medir o impacto da migração de casos de uso. Por exemplo, em termos de melhoria de desempenho, redução de custos ou ativação de novas oportunidades técnicas ou comerciais. Em seguida, é possível quantificar com mais precisão o valor do retorno do investimento e comparar o valor com seus critérios de sucesso para a iteração.

Após a validação da iteração, é possível liberar o caso de uso migrado para produção e conceder aos usuários acesso a conjuntos de dados e aplicativos comerciais migrados.

Por fim, faça anotações e documente as lições aprendidas com essa iteração para que seja possível aplicá-las na próxima iteração e acelerar a migração.

Como resumir o esforço de migração

Durante a migração, você executa o armazenamento de dados legado e o BigQuery, conforme detalhado neste documento. Na arquitetura de referência no diagrama a seguir, destacamos que os dois armazenamentos de dados oferecem funcionalidade e caminhos semelhantes. Ambos podem ingerir dos sistemas de origem, integrar-se aos aplicativos comerciais e fornecer o acesso necessário ao usuário. É importante ressaltar que o diagrama também destaca que os dados são sincronizados do seu armazenamento de dados para o BigQuery. Isso permite que os casos de uso sejam transferidos durante toda a duração do esforço de migração.

Resumo do processo de migração.

Supondo que sua intenção seja migrar completamente do seu armazenamento de dados para o BigQuery, o estado final da migração será semelhante a este:

Estado final da migração, mostrando várias origens de dados sendo inseridas no BigQuery, que é a origem da análise de dados.

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: