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

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

Acessar o Azure Synapse Analytics usando a Microsoft e ferramentas de BI de terceiros

As organizações acessam data warehouses e data marts usando uma variedade de ferramentas e aplicativos de BI (business intelligence). Alguns exemplos de produtos de BI são:

• Ferramentas do Microsoft BI, como o Power BI.

• Aplicativos do Office, como planilhas do Microsoft Excel.

• Ferramentas de BI de terceiros de diferentes fornecedores.

• Aplicativos de análise personalizados com funcionalidade de ferramenta de BI inserida.

• Aplicativos operacionais que dão suporte ao BI sob demanda executando consultas e relatórios em uma plataforma de BI que, por sua vez, consulta dados em um data warehouse ou data mart.

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

Se você migrar a visualização e os relatórios como parte da migração do data warehouse, todas as consultas, relatórios e dashboards existentes gerados por produtos de BI precisarão ser executados no novo ambiente. Seus produtos de BI devem produzir os mesmos resultados no Azure Synapse como fizeram em seu ambiente de data warehouse herdado.

Para resultados consistentes após a migração, todas as ferramentas de BI e as dependências do aplicativo devem funcionar depois que você migrar o esquema e os dados do data warehouse para o Azure Synapse. As dependências incluem aspectos menos visíveis, como acesso e segurança. Ao abordar o acesso e a segurança, certifique-se de migrar:

• Autenticação para que os usuários possam entrar nos bancos de dados do data warehouse e do data mart no Azure Synapse.

• Todos os usuários do Azure Synapse.

• Todos os grupos de usuários para o Azure Synapse.

• Todas as funções para o Azure Synapse.

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

• As atribuições de usuário, função e privilégio para espelhar o que havia no data warehouse existente antes da migração. Por exemplo:

  • Privilégios de objeto de banco de dados atribuídos a funções
  • Funções atribuídas a grupos de usuários
  • Usuários atribuídos a grupos de usuários 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 discutidos mais detalhadamente em Segurança, acesso e operações para migrações oracle.

Dica

Usuários existentes, grupos de usuários, funções e atribuições de privilégios de segurança de acesso precisam ser migrados primeiro para que a migração de relatórios e visualizações tenha êxito.

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

Os usuários empresariais esperam uma migração perfeita, sem surpresas que destruam sua confiança no sistema migrado no Azure Synapse. Tome cuidado para aliviar qualquer medo que seus usuários possam ter através de uma boa comunicação. Seus usuários esperam que:

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

• Os nomes de tabela e coluna permanecem os mesmos quando referenciados diretamente em consultas. Por exemplo, os campos calculados definidos em colunas em ferramentas de BI não devem falhar quando os relatórios de agregação 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 continua igual.

• Os drivers ODBC/JDBC são testados para garantir que o comportamento da consulta permaneça o mesmo.

Dica

A comunicação e o envolvimento de usuários empresariais são fundamentais para o sucesso.

Se as ferramentas de BI consultarem exibições no data warehouse subjacente ou no banco de dados do data mart, essas exibições ainda funcionarão após a migração? Algumas exibições poderão não funcionar se houver extensões SQL proprietárias específicas para o DBMS do data warehouse herdado que não têm equivalente no Azure Synapse. Nesse caso, você precisa saber sobre essas incompatibilidades e encontrar uma maneira de resolvê-las.

Dica

Exibições e consultas SQL usando extensões de consulta SQL proprietárias provavelmente resultarão em incompatibilidades que afetam relatórios e painéis de BI.

Outros problemas, como o comportamento de valores ou variações de tipo de NULL dados em plataformas DBMS, precisam ser testados para garantir que mesmo pequenas diferenças não existam nos resultados do cálculo. Minimize esses problemas e execute todas as etapas necessárias para proteger os usuários empresariais de serem afetados por eles. Dependendo do ambiente herdado do data warehouse, ferramentas de terceiros que podem ajudar a ocultar as diferenças entre os ambientes herdados e os novos para que as ferramentas e os aplicativos de BI sejam executados inalterados.

O teste é fundamental para visualização e migração de relatório. Você precisa de um conjunto de testes e dados de teste acordados para executar e executar novamente testes em ambos os ambientes. Um cinto de teste também é útil e alguns são mencionados neste guia. Além disso, é importante envolver os usuários empresariais no aspecto de teste da migração para manter a confiança alta e mantê-los envolvidos e fazer parte do projeto.

Dica

Use testes repetíveis para garantir que relatórios, dashboards e outras visualizações migrem com êxito.

Você pode estar pensando em mudar as ferramentas de BI, por exemplo, para migrar para o Power BI. A tentação é fazer essas alterações ao mesmo tempo em que você está migrando seu esquema, dados, processamento de ETL e muito mais. No entanto, para minimizar o risco, é melhor migrar primeiro para o Azure Synapse e fazer com que tudo funcione antes de realizar uma modernização adicional.

Se as ferramentas de BI existentes forem executadas localmente, verifique se elas podem se conectar ao Azure Synapse por meio do firewall para que você possa executar comparações em ambos os ambientes. Como alternativa, se o fornecedor de suas ferramentas de BI existentes oferecer seu produto no Azure, você poderá experimentá-lo lá. O mesmo se aplica a aplicativos em execução local que integram BI ou chamam seu servidor BI sob demanda, por exemplo, solicitando um "relatório sem cabeça" com dados XML ou JSON.

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

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

Durante a migração, você pode ser tentado a atender a requisitos de longo prazo, como abrir solicitações comerciais, adicionar dados ausentes ou implementar novos recursos. No entanto, essas alterações podem afetar o acesso da ferramenta de BI ao data warehouse, especialmente se a alteração envolver alterações estruturais em seu modelo de dados. Se você quiser adotar uma técnica de modelagem de dados ágil ou implementar alterações estruturais, faça isso após a migração.

Uma maneira de minimizar o efeito das alterações de esquema ou outras alterações estruturais em suas ferramentas de BI é introduzir a virtualização de dados entre as ferramentas de BI e seu data warehouse e data marts. O diagrama a seguir mostra como a virtualização de dados pode ocultar uma migração dos usuários.

A virtualização de dados quebra a dependência entre os usuários empresariais que usam ferramentas de BI de autoatendimento e o esquema físico do data warehouse e dos data marts subjacentes que estão sendo migrados.

Dica

A virtualização de dados permite que você proteja os usuários empresariais de alterações estruturais durante a migração para que eles permaneçam inconscientes dessas alterações. As alterações estruturais incluem alterações de esquema que ajustam seu modelo de dados para o Azure Synapse.

Com a virtualização de dados, todas as alterações de esquema feitas durante uma migração para o Azure Synapse, por exemplo, para otimizar o desempenho, podem ser ocultadas dos usuários corporativos porque eles só têm acesso a tabelas virtuais na camada de virtualização de dados. E, se você fizer alterações estruturais, só precisará atualizar os mapeamentos entre o data warehouse ou data marts e quaisquer tabelas virtuais. Com a virtualização de dados, os usuários permanecem sem saber das alterações estruturais. Os parceiros da Microsoft fornecem software de virtualização de dados.

Identificar relatórios de alta prioridade a serem migrados primeiro

Uma pergunta importante ao migrar seus relatórios e dashboards existentes para o Azure Synapse é quais migrar primeiro. Vários fatores podem impulsionar essa decisão, como:

• Uso

• Valor do negócio

• Facilidade de migração

• Estratégia de migração de dados

As seções a seguir discutem esses fatores.

Seja qual for a sua decisão, ela deve envolver os usuários corporativos porque eles produzem os relatórios, dashboards e outras visualizações e tomam decisões de negócios com base em insights desses itens. Todos se beneficiam quando você pode:

• Migrar relatórios e dashboards sem interrupções,
• Migrar relatórios e dashboards com esforço mínimo e
• Aponte suas ferramentas de BI para o Azure Synapse em vez de seu sistema de data warehouse herdado e obtenha relatórios semelhantes, dashboards e outras visualizações.

Migrar relatórios com base no uso

O uso geralmente é um indicador do valor comercial. Relatórios e dashboards não utilizados claramente não contribuem para decisões de negócios ou oferecem valor atual. Se você não tiver uma maneira de descobrir quais relatórios e dashboards não são usados, você pode usar uma das várias ferramentas de BI que fornecem estatísticas de uso.

Se seu warehouse de dados herdado está em execução há muitos anos, há uma grande chance de que existam centenas ou até milhares de relatórios. Vale a pena compilar um inventário de relatórios e dashboards e identificar suas estatísticas de uso e finalidade de negócios.

No caso de relatórios não utilizados, determine se deseja desativá-los para reduzir o esforço de migração. Uma pergunta-chave ao decidir se um relatório não utilizado deve ser desativado é se o relatório não é usado porque as pessoas não sabem que ele existe, porque não oferece nenhum valor comercial ou porque foi substituído por outro relatório.

Migrar relatórios com base no valor comercial

O uso por si só nem sempre é um bom indicador do valor comercial. Talvez você queira considerar até que ponto os insights de um relatório contribuem para o valor dos negócios. Uma maneira de fazer isso é avaliar a rentabilidade de cada decisão empresarial que depende do relatório e da extensão da dependência. No entanto, é improvável que essas informações estejam prontamente disponíveis na maioria das organizações.

Outra maneira de avaliar o valor de negócios é examinar o alinhamento de um relatório com a estratégia de negócios. A estratégia de negócios definida pelo executivo normalmente estabelece objetivos estratégicos de negócios (SBOs), KPIs (indicadores de desempenho importantes), metas de KPI que precisam ser alcançadas e quem é responsável por alcançá-los. Você pode classificar um relatório pelos SBOs aos quais ele contribui, como redução de fraudes, melhor envolvimento do cliente e operações de negócios otimizadas. Em seguida, você pode priorizar para a migração os relatórios e dashboards associados a objetivos de alta prioridade. Dessa forma, a migração inicial pode fornecer valor comercial em uma área estratégica.

Outra maneira de avaliar o valor empresarial é classificar relatórios e dashboards como operacionais, táticos ou estratégicos para identificar em qual nível de negócios eles são usados. Os SBOs exigem contribuições em todos esses níveis. Ao saber quais relatórios e dashboards são usados, em que nível e com quais objetivos eles estão associados, você é capaz de concentrar a migração inicial no valor de negócios de alta prioridade. Você pode usar a tabela de objetivos de estratégia de negócios a seguir para avaliar relatórios e dashboards.

Nível	Nome do relatório/painel	Finalidade comercial	Departamento usado	Frequência de uso	Prioridade de negócios
Estratégico
Tático
Operacional

Ferramentas de descoberta de metadados, como o Catálogo de Dados do Azure , permitem que os usuários empresariais marquem e classifiquem fontes de dados para enriquecer os metadados dessas fontes de dados para ajudar na descoberta e classificação. Você pode usar os metadados de um relatório ou dashboard para ajudá-lo a entender seu valor comercial. Sem essas ferramentas, entender a contribuição de relatórios e dashboards para o valor empresarial provavelmente será uma tarefa demorada, quer você esteja migrando ou não.

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

Se sua estratégia de migração for baseada na migração de data marts primeiro, a ordem de migração do data mart afetará quais relatórios e dashboards são migrados primeiro. Se sua estratégia for baseada no valor de negócios, a ordem na qual você migra os data marts para o Azure Synapse refletirá as prioridades de negócios. As ferramentas de descoberta de metadados podem ajudá-lo a implementar sua estratégia mostrando quais tabelas de data mart fornecem dados para quais relatórios.

Dica

Sua estratégia de migração de dados afeta quais relatórios e visualizações são migrados primeiro.

Questões 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 emitindo consultas SQL que acessam tabelas físicas e/ou exibições em seu data warehouse ou data mart. Quando você migra seu data warehouse herdado para o Azure Synapse, vários fatores podem afetar a facilidade de migração de relatórios, dashboards e outras visualizações. Esses fatores incluem:

• Incompatibilidades de esquema entre os ambientes.

• Incompatibilidades de SQL entre os ambientes.

Incompatibilidades de esquema

Durante uma migração, as incompatibilidades de esquema nas tabelas de data warehouse ou data mart que fornecem dados para relatórios, dashboards e outras visualizações podem ser:

• Tipos de tabela não padrão em seu DBMS de data warehouse herdado que não têm um equivalente no Azure Synapse.

• Tipos de dados em seu DBMS de data warehouse herdado que não têm um equivalente no Azure Synapse.

Na maioria dos casos, há uma solução alternativa para as incompatibilidades. Por exemplo, você pode migrar os dados em um tipo de tabela sem suporte para uma tabela padrão com tipos de dados apropriados e indexados ou particionados em uma coluna de data/hora. Da mesma forma, pode ser possível representar tipos de dados sem suporte em outro tipo de coluna e executar cálculos no Azure Synapse para obter os mesmos resultados.

Dica

As incompatibilidades de esquema incluem tipos de tabela de DBMS do warehouse herdado e tipos de dados sem suporte no Azure Synapse.

Para identificar os relatórios afetados por incompatibilidades de esquema, execute consultas no catálogo do sistema de seu armazém de dados legado para identificar as tabelas com tipos de dados sem suporte. Em seguida, você pode usar metadados de sua ferramenta de BI para identificar os relatórios que acessam dados nessas tabelas. Para obter mais informações sobre como identificar incompatibilidades de tipo de objeto, consulte tipos de objeto de banco de dados Oracle sem suporte.

Dica

Consulte o catálogo do sistema do DBMS do seu warehouse herdado para identificar as incompatibilidades de esquema com o Azure Synapse.

O efeito das incompatibilidades de esquema em relatórios, dashboards e outras visualizações pode ser menor do que você imagina porque muitas ferramentas de BI não dão suporte aos tipos de dados menos genéricos. Como resultado, talvez já haja exibições no seu data warehouse herdado que CAST tipos de dados sem suporte para tipos mais genéricos.

Incompatibilidades do SQL

Durante uma migração, as incompatibilidades do SQL provavelmente afetarão qualquer relatório, painel ou outra visualização em um aplicativo ou ferramenta que:

• Acessa visualizações herdadas de DBMS de data warehouse que incluem funções SQL proprietárias sem equivalente no Azure Synapse.

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

Avaliar o impacto das incompatibilidades do SQL em seu portfólio de relatórios

Seu portfólio de relatórios pode incluir serviços de consulta inseridos, relatórios, dashboards e outras visualizações. Não confie na documentação associada a esses itens para medir o efeito das incompatibilidades do SQL na migração do seu portfólio de relatórios para o Azure Synapse. Você precisa usar uma maneira mais precisa para avaliar o efeito das incompatibilidades do SQL.

Usar instruções EXPLAIN para encontrar incompatibilidades do SQL

Você pode encontrar incompatibilidades de SQL revisando os logs da atividade SQL recente no seu data warehouse Oracle legado. Use um script para extrair um conjunto representativo de instruções SQL para um arquivo. 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 sem suporte serão rejeitadas pelo Azure Synapse quando as EXPLAIN instruções forem executadas. Essa abordagem permite avaliar a extensão das incompatibilidades do SQL.

Os metadados do DBMS do data warehouse herdado também podem ajudar a identificar as exibições incompatíveis. Como antes, capture um conjunto representativo de instruções SQL dos logs aplicáveis, prefixe cada instrução SQL com uma instrução EXPLAIN e execute essas EXPLAIN instruções no Azure Synapse para identificar exibições com SQL incompatível.

Dica

Avalie o impacto das incompatibilidades do SQL extraindo seus arquivos de log do DBMS e executando declarações EXPLAIN.

Testar a migração de relatório e painel para o Azure Synapse Analytics

Um elemento-chave da migração de data warehouse é o teste de 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 você executará para verificar o êxito. Teste e compare os relatórios e dashboards em seus sistemas de data warehouse existentes e migrados para:

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

• Verifique se todos os usuários foram migrados.

• Verifique se todas as funções foram migradas e se os usuários estão atribuídos a essas funções.

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

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

• Verifique se os dados e a migração de ETL estão completos e sem erros.

• Verifique se a privacidade dos dados é mantida.

• Teste 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 usuários, grupos de usuários, funções e privilégios, consulte Segurança, acesso e operações para migrações do Oracle.

Automatize o teste o máximo possível para tornar cada teste repetível e dar suporte a uma abordagem consistente para avaliar os resultados do teste. A automação funciona bem para relatórios regulares conhecidos e pode ser gerenciada por meio das pipelines do Azure Synapse ou da orquestração do Azure Data Factory. Se você já tiver um conjunto de consultas de teste em vigor para testes de regressão, poderá usar as ferramentas de teste existentes para automatizar o teste pós-migração.

Dica

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

A análise e os relatórios ad hoc são mais desafiadores e exigem 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 você encontrar inconsistências, sua capacidade de comparar a linhagem de metadados entre os sistemas originais e migrados durante o teste de migração se tornará crucial. Essa comparação pode destacar diferenças e identificar onde as inconsistências se originaram, quando a detecção por outros meios é difícil.

Dica

Aproveite as ferramentas que comparam a linhagem de metadados para verificar os resultados.

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

Sua compreensão da linhagem é um fator crítico na migração bem-sucedida de relatórios e dashboards. Linhagem é um metadado que mostra o percurso dos dados migrados para que você possa acompanhar seu caminho de um relatório ou painel de controle até a fonte de dados. A linhagem mostra como os dados têm percorrido de ponto a ponto, sua localização no data warehouse e/ou data mart e quais relatórios e dashboards os usam. A linhagem ajuda a entender o que acontece com os dados à medida que passam por diferentes armazenamentos de dados, como arquivos e banco de dados, diferentes pipelines de ETL até sua inserção nos relatórios. Quando os usuários empresariais têm acesso à linhagem de dados, ele melhora a confiança, incute confiança e dá suporte a decisões de negócios informadas.

Dica

Sua capacidade de acessar metadados e linhagem de dados de relatórios até uma fonte de dados é essencial para verificar se os relatórios migrados funcionam corretamente.

Em ambientes de data warehouse de vários fornecedores, os analistas de negócios nas equipes de BI podem mapear a linhagem de dados. Por exemplo, se você usar fornecedores diferentes para ETL, data warehouse e relatórios e cada fornecedor tiver seu próprio repositório de metadados, descobrir de onde veio um elemento de dados específico em um relatório pode ser desafiador e demorado.

Dica

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

Para migrar sem problemas de um data warehouse herdado para o Azure Synapse, use a linhagem de dados de ponta a ponta para comprovar a migração correta ao comparar os relatórios e os painéis gerados por cada ambiente. Para mostrar o percurso de dados de ponta a ponta, você precisará capturar e integrar metadados de várias ferramentas. Ter acesso a ferramentas que dão suporte à descoberta automatizada de metadados e à linhagem de dados, ajuda você a identificar relatórios duplicados ou processos de ETL e a encontrar relatórios que dependem de fontes de dados obsoletas, questionáveis ou inexistentes. Você pode usar essas informações para reduzir o número de relatórios e processos de ETL migrados.

Você também pode comparar a linhagem de ponta a ponta de um relatório no Azure Synapse com a linhagem de ponta a ponta do mesmo relatório em seu ambiente herdado para verificar as diferenças que podem ter ocorrido inadvertidamente durante a migração. Esse tipo de comparação é excepcionalmente útil quando você precisa testar e verificar o sucesso da migração.

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

Ao usar ferramentas automatizadas de descoberta de metadados e rastreamento de linhagem de dados, você pode verificar se um relatório no Azure Synapse, produzido a partir de dados migrados, é gerado da mesma maneira em seu ambiente legadado. Essa funcionalidade também ajuda você a determinar:

• Quais dados precisam ser migrados para garantir a execução bem-sucedida do relatório e do painel no Azure Synapse.

• Quais transformações foram e devem ser executadas para garantir a execução bem-sucedida no Azure Synapse.

• Como reduzir a duplicação do relatório.

As ferramentas automatizadas de descoberta de metadados e linhagem de dados simplificam substancialmente o processo de migração porque ajudam as empresas a se tornarem mais conscientes de seus ativos de dados e a saber o que precisa ser migrado para o Azure Synapse para obter um ambiente de relatório sólido.

Várias ferramentas ETL fornecem funcionalidade de linhagem de ponta a ponta, portanto, verifique se sua ferramenta ETL existente tem essa funcionalidade se você planeja usá-la com o Azure Synapse. Os pipelines do Azure Synapse ou o Data Factory dão suporte à capacidade de exibir a linhagem nos fluxos de mapeamento. Os parceiros da Microsoft também fornecem ferramentas automatizadas de descoberta de metadados, linhagem de dados e comparação de linhagem.

Migrar camadas semânticas de ferramenta 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 do usuário comercial às estruturas de dados físicas subjacentes em um data warehouse ou banco de dados do data mart. A camada de metadados semânticos simplifica o acesso fornecendo objetos de alto nível, como dimensões, medidas, hierarquias, métricas calculadas e junções. Os objetos de alto nível usam termos de negócios que são familiares aos analistas de negócios e mapeiam para as estruturas de dados físicas no data warehouse ou no data mart.

Dica

Algumas ferramentas de BI têm camadas semânticas que simplificam o acesso de usuários empresariais a estruturas de dados físicas em seu data warehouse ou data mart.

Em uma migração de data warehouse, você pode ser forçado a alterar nomes de coluna ou tabela. Por exemplo, o Oracle permite um caractere # em nomes de tabela, mas o Azure Synapse só permite # como prefixo de nome de tabela para indicar uma tabela temporária. No Oracle, as tabelas temporárias não precisam ter um "#" no nome, mas no Synapse elas devem ter. Talvez seja necessário fazer algum retrabalho para alterar mapeamentos de tabela nesses casos.

Para obter consistência em várias ferramentas de BI, crie uma camada semântica universal usando um servidor de virtualização de dados que esteja entre ferramentas de BI e aplicativos e o Azure Synapse. No servidor de virtualização de dados, use nomes de dados comuns para objetos de alto nível, como dimensões, medidas, hierarquias e junções. Dessa forma, você configura tudo, incluindo campos calculados, junçõ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

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

Com a virtualização de dados, você obtém consistência em todas as ferramentas de BI e interrompe a dependência entre ferramentas e aplicativos de BI e as estruturas de dados físicos subjacentes no Azure Synapse. Os parceiros da Microsoft podem ajudá-lo a obter consistência no Azure. O diagrama a seguir 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

Em uma migração lift-and-shift de data warehouse, a maioria dos relatórios, painéis e outras visualizações deve migrar facilmente.

Durante uma migração de um ambiente herdado, você pode descobrir que os dados nas tabelas herdadas do data warehouse ou do data mart são armazenados em tipos de dados sem suporte. Ou você também pode encontrar exibições de data warehouse herdado que incluem um SQL proprietário sem equivalência no Azure Synapse. Nesse caso, você precisará resolver esses problemas para garantir uma migração bem-sucedida para o Azure Synapse.

Não confie na documentação mantida pelo usuário para identificar onde os problemas estão localizados. Em vez disso, use declarações do tipo EXPLAIN porque são uma maneira rápida e pragmática de identificar incompatibilidades do SQL. Retrabalho as instruções SQL incompatíveis para obter funcionalidade equivalente no Azure Synapse. Além disso, use ferramentas automatizadas de descoberta e linhagem de metadados para entender dependências, localizar relatórios duplicados e identificar relatórios inválidos que dependem de fontes de dados obsoletas, questionáveis ou inexistentes. Use as ferramentas de linhagem para comparar a linhagem e verificar se os relatórios executados no ambiente de data warehouse herdado são produzidos de forma idêntica no Azure Synapse.

Não migre relatórios que você não usa mais. Os dados de uso da ferramenta de BI podem ajudá-lo a determinar quais relatórios não estão em uso. Para os relatórios, dashboards e outras visualizações que você deseja migrar, migre todos os usuários, grupos de usuários, funções e privilégios. Se você estiver usando o valor de negócios para impulsionar sua estratégia de migração de relatório, associe relatórios a objetivos estratégicos de negócios e prioridades para ajudar a identificar a contribuição de insights de relatório para objetivos específicos. Se você estiver migrando data mart por data mart, use metadados para identificar quais relatórios dependem de quais tabelas e exibições, para tomar uma decisão informada sobre quais data marts migrar primeiro.

Dica

Identifique incompatibilidades antecipadamente para medir a extensão do esforço de migração. Migre seus usuários, funções de grupo e atribuições de privilégios. Migre apenas os relatórios e visualizações que são usados e estão contribuindo para o valor comercial.

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

Próximas etapas

Para saber mais sobre como minimizar problemas de SQL, consulte o próximo artigo desta série: Minimizando problemas de SQL para migrações do Oracle.