Planear a migração de um armazém de dados

Uma migração de armazém de dados é um desafio para qualquer empresa. Para executá-lo bem e evitar quaisquer surpresas indesejáveis e custos não planeados, tem de pesquisar cuidadosamente o desafio, mitigar o risco e planear a sua migração para garantir que está o mais pronto possível. A um nível elevado, o seu plano deve abranger os principais passos do processo de migração do armazém de dados e quaisquer tarefas dentro dos mesmos. Os principais passos do processo são:

• Preparação da pré-migração
• Estratégia de migração e execução
• Pós-migração

Por exemplo, a preparação inclui elementos como preparar a sua equipa de migração do armazém de dados em termos de preparação de competências e familiarização tecnológica. Também inclui a configuração de um laboratório de prova de conceito, a compreensão de como irá gerir ambientes de teste e de produção, obter autorização adequada para migrar os seus dados e um sistema de produção fora da firewall empresarial e configurar software de migração no seu datacenter para permitir que a migração prossiga.

Para que a migração de um armazém de dados prossiga sem problemas, o seu plano deve estabelecer uma compreensão clara de:

• O seu caso de negócio, incluindo os respetivos fatores, benefícios comerciais e riscos.
• Funções e responsabilidades da equipa de migração.
• O conjunto de competências e a preparação necessários para ativar a migração com êxito.
• Orçamento atribuído para a migração completa.
• A sua estratégia de migração.
• Como pode evitar riscos no projeto de migração para evitar atrasos ou reformulação.
• O seu sistema de armazém de dados existente, a respetiva arquitetura, esquema, volumes de dados, fluxos de dados, segurança e dependências operacionais.
• Diferenças entre o DBMS do armazém de dados no local existente e Azure Synapse, como tipos de dados, funções SQL, lógica e outras considerações.
• O que tem de ser migrado e as prioridades.
• As tarefas de migração, abordagens, encomendas e prazos.
• Como irá controlar a migração.
• Como evitar a interrupção do utilizador durante a migração.
• O que precisa de fazer no local para evitar atrasos e ativar a migração.
• Ferramentas para ativar a migração segura de esquemas, dados e processamento de ETL para o Azure.
• Alterações de estrutura do modelo de dados necessárias durante e após a migração.
• Quaisquer alterações à tecnologia de pré-migração ou pós-migração e como minimizar a reformulação.
• Descontinuação da tecnologia pós-migração.
• Como irá implementar testes e garantias de qualidade para provar o sucesso.
• Os pontos de verificação para avaliar o progresso e permitir a tomada de decisões.
• O seu plano de contingência e pontos de reversão no caso de as coisas correrem mal.

Para obter este entendimento, temos de preparar e iniciar atividades específicas antes de qualquer migração começar. Vamos ver o que isso implica mais detalhadamente.

Preparação da pré-migração

Existem vários aspetos que devem ser resolvidos antes mesmo de iniciar uma migração do armazém de dados.

Funções-chave numa equipa de migração do armazém de dados

As principais funções num projeto de migração incluem:

• Proprietário do negócio
• Gestor de projetos (com experiência de metodologia ágil, como Scrum)
• Coordenador do projeto
• Engenheiro de cloud
• Administrador da base de dados (DBMS e Azure Synapse do armazém de dados existente)
• Modeladores de dados
• Programadores de ETL
• Especialista em virtualização de dados (possivelmente um administrador de bases de dados)
• Engenheiro de testes
• Analistas empresariais (para ajudar a testar consultas, relatórios e análises de ferramentas de BI)

Além disso, a equipa precisa do suporte da sua equipa de infraestrutura no local.

Competências e formação para preparar a equipa para migração

No que diz respeito às competências, a experiência é importante numa migração de armazém de dados. Por conseguinte, certifique-se de que os membros adequados da sua equipa de migração são preparados nos princípios fundamentais da cloud do Azure, armazenamento de Blobs do Azure, Azure Data Lake Storage, Azure Data Box, ExpressRoute, gestão de identidades do Azure, Azure Data Factory e Azure Synapse. É provável que os modeladores de dados precisem de ajustar os modelos de dados do Microsoft Azure Synapse assim que ocorrer a migração do seu armazém de dados existente.

Avaliar o armazém de dados existente

Outra parte da preparação para migrar é a necessidade de uma avaliação completa do seu armazém de dados existente para compreender totalmente a arquitetura, os arquivos de dados, o esquema, a lógica de negócio, os fluxos de dados, a funcionalidade DBMS utilizada, a operação do armazém e as dependências. Quanto mais compreensão se ganhar aqui, melhor. Um conhecimento detalhado de como o sistema funciona ajuda a comunicar e a cobrir todas as bases.

O objetivo da avaliação não é apenas garantir uma compreensão detalhada da configuração atual em toda a equipa de migração, mas também compreender os pontos fortes e fracos na configuração atual. Assim, o resultado de uma avaliação do seu armazém de dados atual pode afetar a sua estratégia de migração em termos de lift-and-shift versus algo mais amplo. Por exemplo, se o resultado de uma avaliação for o facto de o seu armazém de dados estar em fim de vida, é evidente que a estratégia seria mais uma migração de dados para um armazém de dados recentemente concebido no Azure Synapse em comparação com uma abordagem lift-and-shift.

Preparação no local para a migração de dados

Além de preparar e preparar a sua equipa de migração para o seu ambiente de destino e avaliar a sua configuração atual, é igualmente importante que defina também as coisas no local, uma vez que os armazéns de dados de produção tendem a ser fortemente controlados por procedimentos de TI e processos de aprovação. Para evitar atrasos, certifique-se de que as suas equipas de operações e infraestrutura de datacenter estão prontas para migrar os seus dados, esquemas, tarefas ETL, etc., para a cloud do Azure. A migração de dados pode ocorrer através de:

• AzCopy para o armazenamento de Blobs do Azure.
• Microsoft Azure ExpressRoute para transferir dados comprimidos diretamente para o Azure.
• Exportação de ficheiros para o Azure Data Box.

Os principais fatores que influenciam qual destas opções está selecionada são o tamanho do volume de dados (em terabytes) e a velocidade de rede (em Mbps). É necessário um cálculo para determinar quanto tempo demoraria a migrar os dados através da rede, tendo em conta que os dados podem ser comprimidos no seu armazém de dados e ficar descomprimidos quando os exportar. Esta situação pode atrasar a transferência de dados. Recomprima dados através do Gzip ao mover dados por qualquer um dos métodos acima. O PolyBase pode processar dados Gzipped diretamente. É provável que os grandes volumes de dados sejam migrados através do Azure Data Box se demorar demasiado tempo a mover os dados.

Além disso, para Azure Data Factory controlar a execução das exportações dos dados existentes do armazém de dados do Azure, o software de run-time de integração autoalojado tem de ser instalado no seu datacenter para permitir que a migração prossiga. Tendo em conta estes requisitos se for necessária uma aprovação formal para tornar isto possível, iniciar os processos de aprovação adequados mais cedo para permitir que isto aconteça ajudará a evitar atrasos.

Preparação do Azure para migração de dados e esquemas

Em termos de preparação do lado do Azure, a importação de dados terá de ser gerida através do Microsoft Azure ExpressRoute ou do Microsoft Azure Data Box. Azure Data Factory pipelines são uma forma ideal de carregar os seus dados para o armazenamento de Blobs do Azure e, em seguida, carregar a partir daí para Azure Synapse com o PolyBase. Por conseguinte, é necessária preparação do lado do Azure para desenvolver esse pipeline.

A alternativa é utilizar a ferramenta ETL existente no Azure se suportar Azure Synapse, o que significa configurar a ferramenta no Azure a partir de Azure Marketplace e preparar um pipeline para importar os seus dados e carregá-los para o armazenamento de Blobs do Azure.

Definir uma estratégia de migração

Objetivos de migração

Em qualquer estratégia, tem de haver um conjunto de objetivos ou objetivos que devem ser definidos para indicar sucesso. Os objectivos podem então ser definidos para atingir estes objectivos e as pessoas responsáveis por alcançá-los. Os exemplos de objetivos de migração e métricas correspondentes para definir destinos num projeto de migração de armazém de dados na cloud são apresentados na tabela abaixo:

Tipos de exemplos de objetivos e métricas:

Melhorar o desempenho geral

• Desempenho da migração de dados
• Desempenho do ELT
• Desempenho do carregamento de dados
• Desempenho de consultas complexo
• Número de utilizadores simultâneos

Executar a um custo mais baixo

• Custo da computação por carga de trabalho, por exemplo, número de horas de computação x custo por hora para:
  • Relatórios padrão
  • Consultas ad hoc
  • Processamento do Batch ELT
• Custo de armazenamento (teste, tabelas de produção, índices, espaço temporário)

Operar com melhor disponibilidade e níveis de serviço

• Contratos de nível de serviço
• Elevada disponibilidade

Melhorar de forma produtiva

• Tarefas automatizadas e reduzidas na contagem de cabeças administrativas

Por conseguinte, uma migração bem-sucedida do armazém de dados pode ser interpretada como um armazém de dados que é executado de forma mais rápida ou rápida e a um custo mais baixo do que o sistema legado do qual migrou. Atribuir os proprietários destes objetivos cria responsabilidade para os alcançar. Também garante que os testes num laboratório de prova de conceito (conforme definido na secção de risco definido neste guia) serão considerados com êxito se os testes identificarem formas de alcançar os objetivos.

Abordagem de migração

Tem várias opções estratégicas para migrar o armazém de dados existente para Azure Synapse:

• Levante e mude o seu armazém de dados existente tal como está.
• Simplifique o armazém de dados existente e, em seguida, migre-o.
• Reestruture completamente o armazém de dados no Azure Synapse e migre os seus dados.

As conclusões da avaliação do armazém de dados existente devem influenciar significativamente a sua estratégia. Um bom resultado de avaliação pode recomendar uma estratégia de lift-and-shift. Um resultado medíocre devido a uma classificação de agilidade baixa pode indicar que a simplificação é necessária antes da migração. Um mau resultado pode indicar que é necessária uma reformulação completa.

O lift-and-shift deixa a sua arquitetura tal como está, tentando minimizar o trabalho na movimentação do sistema existente. Se a ferramenta ETL existente já suportar Azure Synapse, poderá conseguir alterar o destino com um esforço mínimo. No entanto, haverá diferenças nos tipos de tabela, tipos de dados, funções SQL, vistas, lógica de negócio de procedimento armazenado, etc. Estas diferenças e formas de as contornar são detalhadas em documentos de nível inferior nesta série de migração.

Simplificar o armazém de dados existente antes da migração tem a ver com a redução da complexidade para facilitar a migração. Pode incluir:

• Remover ou arquivar tabelas não utilizadas antes de migrar para evitar a migração de dados que não são utilizados.
• Converter data marts físicos em data marts virtuais com software de virtualização de dados para reduzir o que tem de migrar. A conversão também melhora a agilidade e reduz o custo total de propriedade, pelo que pode ser considerada modernização durante a migração.

Também pode simplificar primeiro e, em seguida, levantar e deslocar o que resta.

Âmbito da migração

Seja qual for a estratégia que escolher, deve definir claramente o âmbito da migração, o que será migrado e se irá migrar incrementalmente ou todos de uma só vez. Um exemplo de migração incremental é migrar primeiro os seus data marts, seguido do seu armazém de dados. Esta abordagem permitir-lhe-ia concentrar-se em áreas empresariais de alta prioridade, permitindo ao mesmo tempo que a sua equipa criasse conhecimentos incrementais à medida que cada mercado é migrado individualmente, antes de migrar o próprio armazém de dados.

Definir o que tem de ser migrado

Faça um inventário de tudo o que precisa de ser migrado. Isto inclui esquemas, dados, processos ETL (pipelines), privilégios de autorização, utilizadores, camadas de acesso semântico de ferramentas de BI e aplicações analíticas. Uma compreensão detalhada do que está envolvido na migração do inventário é fornecida em cada um dos artigos de migração de nível inferior nesta série. As ligações para estas ligações são apresentadas abaixo.

• Considerações de desempenho, conceção e migração de esquemas.
• Migração de dados, processamento etl e carregamento.
• Aceder a operações de segurança e armazém de dados.
• Migração de visualização e relatórios.
• Minimizar o impacto dos problemas do SQL.
• Ferramentas de terceiros para o ajudar na migração do armazém de dados.

Se não tiver a certeza sobre a melhor abordagem, realize testes num laboratório de prova de conceito para identificar técnicas ideais. Para obter mais informações, veja a secção sobre a eliminação do risco do projeto de migração do armazém de dados.

Controlo de migração

A migração do armazém de dados para Azure Synapse envolve tarefas que têm de ser realizadas:

• No local, como a exportação de dados.
• Na rede, como a transferência de dados.
• Na cloud do Azure, como a transformação de dados, a integração e a carga.

O problema é que a gestão destas tarefas pode ser complicada se todos os scripts e utilitários estiverem a ser desenvolvidos, testados e executados de forma independente em ambientes no local e do Azure. Adiciona complexidade especialmente se o controlo de versões, a gestão de testes e a execução da migração não forem coordenadas.

Deve evitar estas complexidades e controlá-las a partir de um local comum através de um repositório de controlo de origem para gerir a mudança do desenvolvimento para o teste e produção. A execução da migração envolverá tarefas que têm de ser executadas no local, na rede e no Azure. Uma vez que Azure Synapse é o ambiente de destino, controlar a execução da migração do Azure simplifica a gestão. Utilize Azure Data Factory para criar um pipeline de controlo de migração para controlar a execução no local e no Azure. Isto introduz a automatização e minimiza os erros. O Data Factory torna-se uma ferramenta de orquestração de migração e não apenas uma ferramenta de integração de dados empresariais.

Outras opções para controlar a migração disponível a partir de parceiros da Microsoft em execução no Azure incluem ferramentas de automatização do armazém de dados para tentar automatizar a migração. Por exemplo, fornecedores como WhereScape e Attunity. A maioria destas ferramentas de automatização destina-se a uma abordagem lift-and-shift para a migração. Mesmo assim, podem existir alguns aspetos que podem não ser suportados por tais ferramentas, por exemplo, procedimentos armazenados. Estes produtos e vários outros são detalhados num guia separado dedicado a ferramentas de terceiros para o ajudar a migrar para Azure Synapse.

Teste de migração

A primeira coisa que precisa para testar é definir uma série de testes e um conjunto de resultados necessários para cada teste que precisa de ser executado para verificar e indicar o êxito. É importante garantir que todos os aspetos são testados e comparados entre os seus sistemas existentes e migrados, incluindo:

• Esquema
• Tipos de dados convertidos sempre que necessário
• Utilizar o esquema definido pelo utilizador no Azure Synapse para distinguir entre o armazém de dados e as tabelas do data mart
• Utilizadores
• Funções e atribuições de utilizadores a essas funções
• Privilégios de segurança de acesso a dados
• Privacidade e conformidade dos dados
• Privilégios que regem as capacidades de administração
• Qualidade e integridade dos dados
• O processamento ETL que preenche Azure Synapse no armazém de dados e do armazém de dados para quaisquer data marts, incluindo testes
• Todas as linhas estão corretas em todas as tabelas, incluindo o histórico
• Processamento de dimensões em constante alteração
• Alterar o processamento da captura de dados
• Cálculos e agregações que utilizam funções que podem ser diferentes entre sistemas
• Resultados de todas as consultas, relatórios e dashboards conhecidos
• Desempenho e escalabilidade
• Funcionalidade analítica
• Custos no novo ambiente pay as you go

Automatize o máximo possível os testes, tornando cada teste repetível e permitindo uma abordagem consistente para avaliar os resultados. Se os relatórios e os dashboards forem inconsistentes, a capacidade de comparar a linhagem de metadados entre sistemas originais e migrados é valiosa durante os testes de migração, uma vez que pode realçar as diferenças e identificar onde ocorreram quando não são fáceis de detetar.

A melhor forma de o fazer de forma segura é criar funções, atribuir privilégios de acesso a funções e, em seguida, anexar utilizadores a funções. Para aceder ao seu armazém de dados recentemente migrado, configure um processo automatizado para criar novos utilizadores e atribuir funções. Faça o mesmo para remover utilizadores das funções.

Comunique a transferência a todos os utilizadores para que saibam o que está a mudar e o que esperar.

Anular o risco do projeto de migração do armazém de dados

Outro fator crítico na migração do armazém de dados é a eliminação do risco do projeto para maximizar a probabilidade de êxito. Existem vários procedimentos que podem ser feitos para anular o risco de migração de um armazém de dados. Estas incluem:

• Estabelecer um laboratório de prova de conceito para permitir que a sua equipa experimente, realize testes, compreenda quaisquer problemas e identifique correções e otimizações que ajudem a validar abordagens de migração, melhorar o desempenho e reduzir os custos. Também ajuda a estabelecer formas de automatizar tarefas, utilizar ferramentas incorporadas e criar modelos para capturar melhores práticas, aprender com a experiência e controlar as lições aprendidas. É uma forma inestimável de mitigar o risco e aumentar as suas hipóteses de sucesso. Além disso, pode atribuir proprietários a testes responsáveis por alcançar objetivos e destinos de migração conforme definido na sua estratégia de migração.
• Introduza a virtualização de dados entre as ferramentas de BI e o armazém de dados e os data marts. Introduza a transparência dos utilizadores através da virtualização de dados para reduzir o risco numa migração de armazém de dados e oculte a migração dos utilizadores através das ferramentas de BI de virtualização de dados, conforme mostrado no diagrama seguinte.

O objetivo é interromper a dependência entre os utilizadores empresariais através de ferramentas de BI self-service e o esquema físico do armazém de dados subjacente e dos data marts que estão a ser migrados. Ao introduzir a virtualização de dados, todas as alternâncias de esquema efetuadas durante o armazém de dados e a migração do data mart para Azure Synapse (por exemplo, para otimizar o desempenho) podem ser ocultadas dos utilizadores empresariais porque só acedem a tabelas virtuais na camada de virtualização de dados. Se forem necessárias alterações estruturais, apenas os mapeamentos entre o armazém de dados ou os data marts e quaisquer tabelas virtuais teriam de ser alterados para que os utilizadores não soubessem dessas alterações e não soubessem da migração.

• Procure arquivar quaisquer tabelas existentes identificadas como nunca utilizadas antes da migração do armazém de dados, uma vez que há poucas tabelas de migração que não são utilizadas. Uma forma possível de o fazer é arquivar os dados não utilizados no armazenamento de Blobs do Azure ou Azure Data Lake Storage e criar tabelas externas no Azure Synapse a esses dados para que ainda estejam online.
• Considere a possibilidade de introduzir uma máquina virtual (VM) no Azure com uma versão de desenvolvimento (normalmente gratuita) do DBMS do armazém de dados legado existente em execução nesta VM. Isto permite-lhe mover rapidamente o esquema do armazém de dados existente para a VM e movê-lo para Azure Synapse enquanto trabalha inteiramente na cloud do Azure.
• Definir a ordem de migração e as dependências.
• Certifique-se de que as suas equipas de infraestrutura e operações estão prontas para a migração dos seus dados o mais cedo possível para o projeto de migração.
• Identifique as diferenças na funcionalidade DBMS e onde a lógica de negócio proprietária pode tornar-se um problema. Por exemplo, é pouco provável que a utilização de procedimentos armazenados para o processamento de ELT seja migrada facilmente e não contenha linhagem de metadados, uma vez que as transformações são enterradas no código.
• Considere uma estratégia para migrar os data marts primeiro seguido pelo armazém de dados que é a origem para os data marts. A razão para tal é que permite a migração incremental, torna-a mais gerível e é possível priorizar a migração com base nas necessidades empresariais.
• Tendo em conta a possibilidade de utilizar a virtualização de dados para simplificar a arquitetura atual do armazém de dados antes de migrar, por exemplo, para substituir os data marts por data marts virtuais para que possa eliminar arquivos de dados físicos e tarefas ETL para data marts sem perder qualquer funcionalidade antes da migração. Ao fazê-lo, reduziria o número de arquivos de dados a migrar, reduziria as cópias de dados, reduziria o custo total de propriedade e melhoraria a agilidade. Isto requer mudar de mercados de dados físicos para virtuais antes de migrar o armazém de dados. Em muitos aspectos, pode considerar este passo de modernização do armazém de dados antes da migração.

Passos seguintes

Para obter mais informações sobre migrações de armazéns de dados, participe num workshop de modernização do armazém de dados da cloud virtual no Azure a partir da Informatica.