Visualização e relatórios para migrações oracle

Este artigo é a quarta parte de uma série de sete partes que fornece orientações sobre como migrar do Oracle para o Azure Synapse Analytics. O foco deste artigo são as melhores práticas para visualização e relatórios.

Access Azure Synapse Analytics using Microsoft and third-party BI tools (Aceder ao Azure Synapse Analytics com ferramentas de BI da Microsoft e de terceiros)

As organizações acedem a armazéns de dados e data marts com uma variedade de ferramentas e aplicações de business intelligence (BI). Alguns exemplos de produtos de BI são:

• Ferramentas do Microsoft BI, como o Power BI.

• Aplicações do Office, como folhas de cálculo do Microsoft Excel.

• Ferramentas de BI de terceiros de diferentes fornecedores.

• Aplicações de análise personalizadas com funcionalidade de ferramenta de BI incorporada.

• Aplicações operacionais que suportam BI a pedido ao executar consultas e relatórios numa plataforma de BI que, por sua vez, consulta dados num armazém de dados ou data mart.

• Ferramentas de desenvolvimento de ciência de dados interativas, como Azure Synapse Blocos de Notas do Spark, Azure Machine Learning, RStudio e Jupyter Notebooks.

Se migrar a visualização e os relatórios como parte da migração do armazém de dados, todas as consultas, relatórios e dashboards existentes gerados pelos produtos de BI têm de ser executados no novo ambiente. Os seus produtos de BI têm de produzir os mesmos resultados em Azure Synapse como fizeram no seu ambiente de armazém de dados legado.

Para obter resultados consistentes após a migração, todas as ferramentas de BI e dependências de aplicações têm de funcionar depois de migrar o esquema e os dados do armazém de dados para Azure Synapse. As dependências incluem aspetos menos visíveis, como acesso e segurança. Quando abordar o acesso e a segurança, certifique-se de que migra:

• Autenticação para que os utilizadores possam iniciar sessão no armazém de dados e nas bases de dados do data mart no Azure Synapse.

• Todos os utilizadores a Azure Synapse.

• Todos os grupos de utilizadores a Azure Synapse.

• Todas as funções a Azure Synapse.

• Todos os privilégios de autorização que regem o controlo de acesso aos Azure Synapse.

• Atribuições de utilizador, função e privilégios para espelhar o que tinha no armazém de dados existente antes da migração. Por exemplo:

  • Privilégios de objetos de base de dados atribuídos a funções
  • Funções atribuídas a grupos de utilizadores
  • Utilizadores atribuídos a grupos de utilizadores e/ou funções

O acesso e a segurança são considerações importantes para o acesso a dados no sistema migrado e são abordadas mais detalhadamente em Segurança, acesso e operações para migrações Oracle.

Dica

Os utilizadores, grupos de utilizadores, funções e atribuições de privilégios de segurança de acesso têm de ser migrados primeiro para que a migração de relatórios e visualizações seja bem-sucedida.

Migre todos os dados necessários para garantir que os relatórios e dashboards que consultam dados no ambiente legado produzem os mesmos resultados em Azure Synapse.

Os utilizadores empresariais esperam uma migração totalmente integrada, sem surpresas que destruam a confiança no sistema migrado no Azure Synapse. Tenha cuidado para aliviar os receios que os seus utilizadores possam ter através de uma boa comunicação. Os seus utilizadores esperam que:

• A estrutura da tabela permanece a mesma quando diretamente referida em consultas.

• Os nomes de tabelas e colunas permanecem os mesmos quando diretamente referidos em consultas. Por exemplo, os campos calculados definidos em colunas nas ferramentas de BI não devem falhar quando os relatórios agregados são produzidos.

• A análise histórica permanece a mesma.

• Os tipos de dados permanecem os mesmos, se possível.

• O comportamento da consulta permanece o mesmo.

• Os controladores ODBC/JDBC são testados para garantir que o comportamento da consulta permanece o mesmo.

Dica

A comunicação e o envolvimento dos utilizadores empresariais são fundamentais para o sucesso.

Se as ferramentas de BI consultarem vistas no armazém de dados subjacente ou na base de dados do data mart, essas vistas continuarão a funcionar após a migração? Algumas vistas poderão não funcionar se existirem extensões de SQL proprietárias específicas do seu DBMS do armazém de dados legado que não têm equivalente em Azure Synapse. Em caso afirmativo, tem de saber mais sobre essas incompatibilidades e encontrar uma forma de as resolver.

Dica

É provável que as vistas e as consultas SQL que utilizam extensões de consulta SQL proprietárias resultem em incompatibilidades que afetam relatórios e dashboards de BI.

Outros problemas, como o comportamento de valores ou variações de NULL tipo de dados nas plataformas DBMS, têm de ser testados para garantir que não existem diferenças ligeiras nos resultados dos cálculos. Minimize esses problemas e siga todos os passos necessários para proteger os utilizadores empresariais de serem afetados pelos mesmos. Consoante o ambiente do armazém de dados legado, as ferramentas de terceiros que podem ajudar a ocultar as diferenças entre os ambientes legados e os novos para que as ferramentas de BI e as aplicações fiquem inalteradas.

Os testes são fundamentais para a visualização e a migração de relatórios. Precisa de um conjunto de testes e dados de teste acordados para executar e executar novamente testes em ambos os ambientes. Um arnês de teste também é útil e alguns são mencionados neste guia. Além disso, é importante envolver os utilizadores empresariais no aspeto de teste da migração para manter a confiança elevada e mantê-los envolvidos e parte do projeto.

Dica

Utilize testes repetíveis para garantir que os relatórios, dashboards e outras visualizações são migrados com êxito.

Pode estar a pensar em mudar de ferramentas de BI, por exemplo, para migrar para o Power BI. A tentação é fazer essas alterações ao mesmo tempo que está a migrar o esquema, os dados, o processamento de ETL e muito mais. No entanto, para minimizar o risco, é melhor migrar para Azure Synapse primeiro e pôr tudo a funcionar antes de efetuar uma maior modernização.

Se as ferramentas de BI existentes forem executadas no local, certifique-se de que podem ligar-se a Azure Synapse através da firewall para que possa executar comparações em ambos os ambientes. Em alternativa, se o fornecedor das suas ferramentas de BI existentes oferecer o produto no Azure, pode experimentá-lo lá. O mesmo se aplica às aplicações em execução no local que incorporaram BI ou chamam o servidor de BI a pedido, por exemplo, ao pedir um "relatório sem cabeça" com dados XML ou JSON.

Há muito em que pensar aqui, então vamos olhar mais de perto.

Utilizar a virtualização de dados para minimizar o impacto da migração em ferramentas e relatórios de BI

Durante a migração, poderá sentir-se tentado a cumprir requisitos de longo prazo, como abrir pedidos empresariais, adicionar dados em falta ou implementar novas funcionalidades. No entanto, tais alterações podem afetar o acesso da ferramenta de BI ao seu armazém de dados, especialmente se a alteração envolver alterações estruturais ao modelo de dados. Se quiser adotar uma técnica de modelação de dados ágil ou implementar alterações estruturais, faça-o após a migração.

Uma forma de minimizar o efeito das alterações de esquema ou de outras alterações estruturais nas ferramentas de BI é introduzir a virtualização de dados entre as ferramentas de BI e o armazém de dados e os data marts. O diagrama seguinte mostra como a virtualização de dados pode ocultar uma migração dos utilizadores.

A virtualização de dados interrompe a dependência entre os utilizadores empresariais que utilizam 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.

Dica

A virtualização de dados permite-lhe proteger os utilizadores empresariais de alterações estruturais durante a migração para que não tenham conhecimento dessas alterações. As alterações estruturais incluem alterações de esquema que otimizam o modelo de dados para Azure Synapse.

Com a virtualização de dados, todas as alterações de esquema efetuadas durante uma migração para Azure Synapse, por exemplo, para otimizar o desempenho, podem ser ocultadas dos utilizadores empresariais porque só têm acesso a tabelas virtuais na camada de virtualização de dados. Além disso, se fizer alterações estruturais, só precisa de atualizar os mapeamentos entre o armazém de dados ou os data marts e quaisquer tabelas virtuais. Com a virtualização de dados, os utilizadores continuam a desconhecer as alterações estruturais. Os parceiros da Microsoft fornecem software de virtualização de dados.

Identificar relatórios de alta prioridade para migrar primeiro

Uma questão fundamental ao migrar os seus relatórios e dashboards existentes para Azure Synapse são os que devem ser migrados primeiro. Vários fatores podem impulsionar essa decisão, tais como:

• Utilização

• Valor de negócio

• Facilidade de migração

• Estratégia de migração de dados

As secções seguintes abordam estes fatores.

Seja qual for a sua decisão, tem de envolver os seus utilizadores empresariais porque produzem os relatórios, dashboards e outras visualizações e tomar decisões empresariais com base nas informações desses itens. Todos beneficiam quando pode:

• Migrar relatórios e dashboards de forma totalmente integrada,
• Migrar relatórios e dashboards com um esforço mínimo e
• Aponte as suas ferramentas de BI para Azure Synapse em vez do seu sistema de armazém de dados legado e obtenha relatórios semelhantes, dashboards e outras visualizações.

Migrar relatórios com base na utilização

A utilização é, muitas vezes, um indicador do valor comercial. Os relatórios e dashboards não utilizados claramente não contribuem para decisões empresariais nem oferecem valor atual. Se não tiver uma forma de descobrir que relatórios e dashboards não são utilizados, pode utilizar uma das várias ferramentas de BI que fornecem estatísticas de utilização.

Se o seu armazém de dados legado estiver em funcionamento há anos, há boas hipóteses de ter centenas, se não milhares, de relatórios existentes. Vale a pena compilar um inventário de relatórios e dashboards e identificar as respetivas estatísticas de utilização e fins comerciais.

Para relatórios não utilizados, determine se os desativa para reduzir o esforço de migração. Uma questão-chave ao decidir se pretende desativar um relatório não utilizado é se o relatório não é utilizado porque as pessoas não sabem que existe, porque não oferece valor comercial ou porque foi substituído por outro relatório.

Migrar relatórios com base no valor comercial

A utilização por si só nem sempre é um bom indicador do valor comercial. Recomendamos que considere até que ponto as informações de um relatório contribuem para o valor comercial. Uma forma de o fazer é avaliar a rentabilidade de todas as decisões empresariais que se baseiam no relatório e na extensão da dependência. No entanto, é pouco provável que essa informação esteja prontamente disponível na maioria das organizações.

Outra forma de avaliar o valor comercial é olhar para o alinhamento de um relatório com a estratégia de negócio. Normalmente, a estratégia de negócio definida pelo seu executivo estabelece objetivos estratégicos de negócio (SBOs), indicadores-chave de desempenho (KPIs), metas de KPI que têm de ser alcançados e quem é responsável por os alcançar. Pode classificar um relatório através do qual os SBOs para os quais o relatório contribui, como a redução de fraudes, melhor envolvimento do cliente e operações empresariais otimizadas. Em seguida, pode dar prioridade à migração dos relatórios e dashboards associados a objetivos de alta prioridade. Desta forma, a migração inicial pode fornecer valor comercial numa área estratégica.

Outra forma de avaliar o valor comercial é classificar relatórios e dashboards como operacionais, táticos ou estratégicos para identificar a que nível empresarial são utilizados. Os SBOs requerem contribuições a todos estes níveis. Ao saber que relatórios e dashboards são utilizados, a que nível e a que objetivos estão associados, pode concentrar a migração inicial no valor empresarial de alta prioridade. Pode utilizar a seguinte tabela de objetivos de estratégia de negócio para avaliar relatórios e dashboards.

Level	Nome do relatório/dashboard	Objetivo comercial	Departamento utilizado	Frequência de utilização	Prioridade empresarial
Estratégicas
Tática
Operacional

As ferramentas de deteção de metadados, como o Azure Catálogo de Dados permitem que os utilizadores empresariais identifiquem e classifiquem origens de dados para enriquecer os metadados dessas origens de dados para ajudar na respetiva deteção e classificação. Pode utilizar os metadados de um relatório ou dashboard para o ajudar a compreender o respetivo valor comercial. Sem estas ferramentas, é provável que compreender o contributo de relatórios e dashboards para o valor empresarial seja uma tarefa morosa, quer esteja ou não a migrar.

Migrar relatórios com base na estratégia de migração de dados

Se a sua estratégia de migração se basear primeiro na migração de data marts, a ordem da migração do data mart afetará os relatórios e dashboards que são migrados primeiro. Se a sua estratégia se basear no valor empresarial, a ordem pela qual migra os data marts para Azure Synapse refletirá as prioridades empresariais. As ferramentas de deteção de metadados podem ajudá-lo a implementar a sua estratégia ao mostrar que tabelas de data mart fornecem dados para os relatórios.

Dica

A sua estratégia de migração de dados afeta os relatórios e visualizações que são migrados primeiro.

Problemas de incompatibilidade de migração que podem afetar relatórios e visualizações

As ferramentas de BI produzem relatórios, dashboards e outras visualizações ao emitir consultas SQL que acedem a tabelas físicas e/ou vistas no seu armazém de dados ou data mart. Quando migra o seu armazém de dados legado para Azure Synapse, vários fatores podem afetar a facilidade de migração de relatórios, dashboards e outras visualizações. Estes fatores incluem:

• Incompatibilidades de esquemas entre os ambientes.

• Incompatibilidades de SQL entre os ambientes.

Incompatibilidades de esquemas

Durante uma migração, as incompatibilidades de esquemas no armazém de dados ou tabelas do data mart que fornecem dados para relatórios, dashboards e outras visualizações podem ser:

• Tipos de tabela não padrão no DBMS do armazém de dados legado que não têm um equivalente em Azure Synapse.

• Tipos de dados no seu DBMS do armazém de dados legado que não têm um equivalente no Azure Synapse.

Na maioria dos casos, existe uma solução para as incompatibilidades. Por exemplo, pode migrar os dados num tipo de tabela não suportado para uma tabela padrão com tipos de dados adequados e indexados ou particionados numa coluna de data/hora. Da mesma forma, poderá ser possível representar tipos de dados não suportados noutro tipo de coluna e efetuar cálculos no Azure Synapse para obter os mesmos resultados.

Dica

As incompatibilidades de esquema incluem tipos de tabela DBMS de armazém legados e tipos de dados que não são suportados no Azure Synapse.

Para identificar os relatórios afetados por incompatibilidades de esquemas, execute consultas no catálogo de sistemas do seu armazém de dados legado para identificar as tabelas com tipos de dados não suportados. Em seguida, pode utilizar metadados da sua ferramenta de BI para identificar os relatórios que acedem aos dados nessas tabelas. Para obter mais informações sobre como identificar incompatibilidades de tipos de objeto, veja Tipos de objetos de base de dados Oracle não suportados.

Dica

Consulte o catálogo de sistema do DBMS do armazém legado para identificar incompatibilidades de esquemas com Azure Synapse.

O efeito das incompatibilidades de esquema em relatórios, dashboards e outras visualizações pode ser menor do que pensa, uma vez que muitas ferramentas de BI não suportam os tipos de dados menos genéricos. Como resultado, o seu armazém de dados legado pode já ter vistas que CAST não suportam tipos de dados para tipos mais genéricos.

Incompatibilidades do SQL

Durante uma migração, é provável que as incompatibilidades do SQL afetem qualquer relatório, dashboard ou outra visualização numa aplicação ou ferramenta que:

• Acede a vistas DBMS do armazém de dados legadas que incluem funções SQL proprietárias que não têm equivalentes em Azure Synapse.

• Emite consultas SQL que incluem funções SQL proprietárias, específicas do dialeto SQL do seu ambiente legado, que não têm equivalente em Azure Synapse.

Avalie o impacto das incompatibilidades de SQL no seu portefólio de relatórios

O seu portefólio de relatórios pode incluir serviços de consulta incorporados, relatórios, dashboards e outras visualizações. Não dependa da documentação associada a esses itens para avaliar o efeito das incompatibilidades do SQL na migração do seu portefólio de relatórios para Azure Synapse. Tem de utilizar uma forma mais precisa de avaliar o efeito das incompatibilidades do SQL.

Utilizar instruções EXPLAIN para encontrar incompatibilidades de SQL

Pode encontrar incompatibilidades de SQL ao rever os registos da atividade recente do SQL no seu armazém de dados Oracle legado. Utilize um script para extrair um conjunto representativo de instruções SQL para um ficheiro. Em seguida, prefixe cada instrução SQL com uma instrução EXPLAIN e execute essas EXPLAIN instruções no Azure Synapse. Todas as instruções SQL que contenham extensões SQL proprietárias não suportadas serão rejeitadas por Azure Synapse quando as EXPLAIN instruções forem executadas. Esta abordagem permite-lhe avaliar a extensão das incompatibilidades do SQL.

Os metadados do DBMS do armazém de dados legado também podem ajudá-lo a identificar vistas incompatíveis. Tal como anteriormente, capture um conjunto representativo de instruções SQL dos registos aplicáveis, prefixe cada instrução SQL com uma instrução EXPLAIN e execute essas EXPLAIN instruções no Azure Synapse para identificar vistas com SQL incompatível.

Dica

Avalie o impacto das incompatibilidades do SQL ao recolher os ficheiros de registo do DBMS e as instruções em execução EXPLAIN .

Testar a migração de relatórios e dashboards para o Azure Synapse Analytics

Um elemento-chave da migração do armazém de dados é testar relatórios e dashboards no Azure Synapse para verificar se a migração funcionou. Defina uma série de testes e um conjunto de resultados necessários para cada teste que irá executar para verificar o êxito. Teste e compare os relatórios e dashboards nos seus sistemas de armazém de dados existentes e migrados para:

• Identifique se as alterações de esquema efetuadas durante a migração afetaram a capacidade de execução de relatórios, resultados de relatórios ou visualizações de relatório correspondentes. Um exemplo de uma alteração de esquema é se mapeou um tipo de dados incompatível para um tipo de dados equivalente suportado no Azure Synapse.

• Verifique se todos os utilizadores estão migrados.

• Verifique se todas as funções são migradas e se os utilizadores estão atribuídos a essas funções.

• Verifique se todos os privilégios de segurança de acesso a dados são migrados para garantir a migração da lista de controlo de acesso (ACL).

• Garanta resultados consistentes para todas as consultas, relatórios e dashboards conhecidos.

• Certifique-se de que a migração de dados e ETL está concluída e sem erros.

• Certifique-se de que a privacidade dos dados é mantida.

• Testar o desempenho e a escalabilidade.

• Testar a funcionalidade analítica.

Dica

Teste e ajuste o desempenho para minimizar os custos de computação.

Para obter informações sobre como migrar utilizadores, grupos de utilizadores, funções e privilégios, veja Segurança, acesso e operações para migrações oracle.

Automatize os testes tanto quanto possível para tornar cada teste repetível e para suportar uma abordagem consistente à avaliação dos resultados dos testes. A automatização funciona bem para relatórios regulares conhecidos e pode ser gerida através de pipelines de Azure Synapse ou Azure Data Factory orquestração. Se já tiver um conjunto de consultas de teste implementadas para testes de regressão, pode utilizar as ferramentas de teste existentes para automatizar os testes pós-migração.

Dica

A melhor prática é criar um conjunto de testes automatizado para tornar os testes repetíveis.

A análise e os relatórios ad hoc são mais desafiantes e requerem a compilação de um conjunto de testes para verificar se os mesmos relatórios e dashboards de antes e depois da migração são consistentes. Se encontrar inconsistências, a sua capacidade de comparar linhagem de metadados nos sistemas originais e migrados durante os testes de migração torna-se crucial. Essa comparação pode realçar diferenças e identificar a origem das inconsistências, quando a deteção por outros meios é difícil.

Dica

Tire partido das ferramentas que comparam a linhagem de metadados para verificar os resultados.

Analisar a linhagem para compreender as dependências entre relatórios, dashboards e dados

A sua compreensão da linhagem é um fator fundamental para a migração bem-sucedida de relatórios e dashboards. A linhagem é metadados que mostram o percurso dos dados migrados para que possa controlar o caminho de um relatório ou dashboard até à origem de dados. A linhagem mostra como os dados viajaram de um ponto para outro, a sua localização no armazém de dados e/ou data mart e os relatórios e dashboards que os utilizam. A linhagem pode ajudá-lo a compreender o que acontece aos dados à medida que percorre diferentes arquivos de dados, como ficheiros e bases de dados, pipelines ETL diferentes e relatórios. Quando os utilizadores empresariais têm acesso à linhagem de dados, melhoram a confiança, incutem confiança e suportam decisões empresariais informadas.

Dica

A sua capacidade de aceder a metadados e linhagem de dados a partir de relatórios até uma origem de dados é fundamental para verificar se os relatórios migrados funcionam corretamente.

Em ambientes de armazém de dados de vários fornecedores, os analistas empresariais em equipas de BI podem mapear a linhagem de dados. Por exemplo, se utilizar fornecedores diferentes para ETL, armazém de dados e relatórios, e cada fornecedor tiver o seu próprio repositório de metadados, descobrir de onde veio um elemento de dados específico num relatório pode ser desafiante e demorado.

Dica

As ferramentas que automatizam a coleção de metadados e mostram linhagem ponto a ponto num ambiente de vários fornecedores são valiosas durante uma migração.

Para migrar de forma totalmente integrada de um armazém de dados legado para Azure Synapse, utilize a linhagem de dados ponto a ponto para provar a migração semelhante quando estiver a comparar os relatórios e dashboards gerados por cada ambiente. Para mostrar o percurso de dados ponto a ponto, terá de capturar e integrar metadados de várias ferramentas. Ter acesso a ferramentas que suportam a deteção de metadados automatizados e a linhagem de dados, ajuda-o a identificar relatórios duplicados ou processos ETL e a encontrar relatórios que dependem de origens de dados obsoletas, questionáveis ou inexistentes. Pode utilizar essas informações para reduzir o número de relatórios e processos ETL que migrar.

Também pode comparar a linhagem ponto a ponto de um relatório no Azure Synapse com a linhagem ponto a ponto do mesmo relatório no seu ambiente legado para verificar se existem diferenças que possam ter ocorrido inadvertidamente durante a migração. Este tipo de comparação é excepcionalmente útil quando precisa de testar e verificar o sucesso da migração.

A visualização da linhagem de dados não só reduz o tempo, o esforço e o erro no processo de migração, como também permite uma migração mais rápida.

Ao utilizar ferramentas automatizadas de deteção de metadados e linhagem de dados que comparam a linhagem, pode verificar se um relatório no Azure Synapse produzido a partir de dados migrados é produzido da mesma forma no seu ambiente legado. Esta capacidade também o ajuda a determinar:

• Que dados têm de ser migrados para garantir a execução bem-sucedida de relatórios e dashboards no Azure Synapse.

• Que transformações foram e devem ser realizadas para garantir uma execução bem-sucedida no Azure Synapse.

• Como reduzir a duplicação de relatórios.

As ferramentas automatizadas de deteção de metadados e linhagem de dados simplificam substancialmente o processo de migração, uma vez que ajudam as empresas a tornarem-se mais conscientes dos seus recursos de dados e a saberem o que precisa de ser migrado para Azure Synapse para alcançar um ambiente de relatório sólido.

Várias ferramentas ETL fornecem capacidade de linhagem ponto a ponto, por isso, verifique se a ferramenta ETL existente tem essa capacidade se planear utilizá-la com Azure Synapse. Azure Synapse pipelines ou Data Factory suportam a capacidade de ver linhagem nos fluxos de mapeamento. Os parceiros da Microsoft também fornecem ferramentas de deteção automatizada de metadados, linhagem de dados e comparação de linhagem.

Migrar camadas semânticas de ferramentas de BI para o Azure Synapse Analytics

Algumas ferramentas de BI têm o que é conhecido como uma camada de metadados semânticos. Essa camada simplifica o acesso dos utilizadores empresariais às estruturas de dados físicas subjacentes num armazém de dados ou numa base de dados do data mart. A camada de metadados semânticos simplifica o acesso ao fornecer objetos de alto nível, como dimensões, medidas, hierarquias, métricas calculadas e associações. Os objetos de alto nível utilizam termos de negócio que são familiares aos analistas empresariais e mapeiam para estruturas de dados físicas no seu armazém de dados ou data mart.

Dica

Algumas ferramentas de BI têm camadas semânticas que simplificam o acesso dos utilizadores empresariais a estruturas de dados físicas no seu armazém de dados ou data mart.

Numa migração de armazém de dados, poderá ser obrigado a alterar nomes de colunas ou tabelas. Por exemplo, o Oracle permite um # caráter em nomes de tabela, mas Azure Synapse só permite # como prefixo de nome de tabela indicar uma tabela temporária. No Oracle, as TABELAS TEMPORÁRIAS não têm necessariamente um "#" no nome, mas no Synapse têm de o fazer. Poderá ter de efetuar algumas reformulações para alterar os mapeamentos de tabelas nesses casos.

Para obter consistência em várias ferramentas de BI, crie uma camada semântica universal com um servidor de virtualização de dados que se encontra entre ferramentas de BI e aplicações e Azure Synapse. No servidor de virtualização de dados, utilize nomes de dados comuns para objetos de alto nível, como dimensões, medidas, hierarquias e associações. Desta forma, configura tudo, incluindo campos calculados, associações e mapeamentos, apenas uma vez em vez de em todas as ferramentas. Em seguida, aponte todas as ferramentas de BI para o servidor de virtualização de dados.

Dica

Utilize a virtualização de dados para criar uma camada semântica comum para garantir a consistência em todas as ferramentas de BI num ambiente Azure Synapse.

Com a virtualização de dados, obtém consistência em todas as ferramentas de BI e interrompe a dependência entre ferramentas de BI e aplicações e as estruturas de dados físicos subjacentes no Azure Synapse. Os parceiros da Microsoft podem ajudá-lo a alcançar a consistência no Azure. O diagrama seguinte mostra como um vocabulário comum no servidor de virtualização de dados permite que várias ferramentas de BI vejam uma camada semântica comum.

Conclusões

Numa migração de armazém de dados lift-and-shift, a maioria dos relatórios, dashboards e outras visualizações devem ser migrados facilmente.

Durante uma migração de um ambiente legado, poderá descobrir que os dados no armazém de dados legado ou nas tabelas de data mart são armazenados em tipos de dados não suportados. Em alternativa, poderá encontrar vistas legadas do armazém de dados que incluem SQL proprietário sem equivalente em Azure Synapse. Em caso afirmativo, terá de resolver esses problemas para garantir uma migração bem-sucedida para Azure Synapse.

Não confie na documentação mantida pelo utilizador para identificar onde estão localizados os problemas. Em vez disso, utilize EXPLAIN instruções porque são uma forma rápida e pragmática de identificar incompatibilidades de SQL. Retrabalhar as instruções SQL incompatíveis para obter funcionalidades equivalentes no Azure Synapse. Além disso, utilize ferramentas automatizadas de deteção de metadados e linhagem para compreender as dependências, localizar relatórios duplicados e identificar relatórios inválidos que dependem de origens de dados obsoletas, questionáveis ou inexistentes. Utilize ferramentas de linhagem para comparar a linhagem para verificar se os relatórios em execução no seu ambiente de armazém de dados legado são produzidos de forma idêntica no Azure Synapse.

Não migre os relatórios que já não utiliza. Os dados de utilização da ferramenta de BI podem ajudá-lo a determinar que relatórios não estão a ser utilizados. Para os relatórios, dashboards e outras visualizações que pretende migrar, migre todos os utilizadores, grupos de utilizadores, funções e privilégios. Se estiver a utilizar o valor empresarial para impulsionar a estratégia de migração de relatórios, associe relatórios a objetivos e prioridades empresariais estratégicos para ajudar a identificar o contributo das informações de relatórios para objetivos específicos. Se estiver a migrar o data mart por data mart, utilize metadados para identificar quais os relatórios que dependem das tabelas e vistas, para que possa tomar uma decisão informada sobre quais os data marts a migrar primeiro.

Dica

Identifique incompatibilidades precocemente para avaliar a extensão do esforço de migração. Migrar os seus utilizadores, funções de grupo e atribuições de privilégios. Migrar apenas os relatórios e visualizações que são utilizados e estão a contribuir para o valor comercial.

As alterações estruturais ao modelo de dados do armazém de dados ou do data mart podem ocorrer durante uma migração. Considere utilizar a virtualização de dados para proteger as ferramentas de BI e as aplicações contra alterações estruturais. Com a virtualização de dados, pode utilizar um vocabulário comum para definir uma camada semântica comum. A camada semântica comum garante nomes de dados comuns consistentes, definições, métricas, hierarquias e associações em todas as ferramentas e aplicações de BI no novo ambiente Azure Synapse.

Passos seguintes

Para saber mais sobre como minimizar os problemas do SQL, veja o próximo artigo desta série: Minimizar problemas de SQL para migrações oracle.