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

Este artigo é a quarta parte de uma série de sete partes que oferece diretrizes para fazer a migração do Netezza para o Azure Synapse Analytics. Seu foco é apresentar práticas recomendadas de visualização e geração de relatórios.

Acessar o Azure Synapse Analytics usando ferramentas de BI da Microsoft e 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 de BI da Microsoft, como o Power BI.

• Aplicativos do Office, como as planilhas do Microsoft Excel.

• Ferramentas de BI de terceiros, de diferentes fornecedores.

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

• Aplicativos operacionais com suporte a BI sob demanda com a invocação de 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. Por exemplo, Azure Synapse Spark Notebooks, Azure Machine Learning, RStudio e Jupyter Notebooks.

Se você migrar visualização e relatórios como parte da migração do data warehouse, todas as consultas, os relatórios e painéis 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 e no ambiente herdado do data warehouse.

Para obter 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:

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

• Todos os usuários para o 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

Acesso e 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 do Netezza.

Dica

Os usuários, grupos de usuários, as funções e as atribuições de privilégios de segurança de acesso existentes precisam antes ser migrados, 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 painéis 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. Tenha o cuidado de dissipar qualquer possível receio dos seus usuários, usando uma boa comunicação. Os usuários esperam que:

• A estrutura de tabelas seja a mesma quando referenciada diretamente nas consultas.

• Os nomes de tabelas e colunas 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 são produzidos relatórios agregados.

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

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

• Que o comportamento da consulta continue o mesmo.

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

Dica

A comunicação e o envolvimento do usuário empresarial são críticos para o sucesso.

Se as ferramentas de BI consultarem exibições no data warehouse subjacente ou no banco de dados do data mart, elas continuarão funcionando corretamente após a migração? Alguns modos de exibição talvez não funcionem se houver extensões SQL proprietárias específicas do DBMS do data warehouse herdado sem equivalente no Azure Synapse. Nesse caso, você precisa conhecer essas incompatibilidades e encontrar uma maneira de resolvê-las.

Dica

As exibições e as consultas SQL que usam extensões de consulta SQL proprietárias provavelmente resultarão em incompatibilidades que afetarão os relatórios e os dashboards de BI.

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

Os testes são fundamentais para migração de visualização e relatório. Você precisa de um conjunto de testes e dos mesmos dados de teste para executar e reexecutar testes nos dois ambientes. Um agente de teste também é útil. Veja o nome de alguns adiante, neste guia. Também é importante envolver os usuários empresariais no aspecto de teste da migração, para preservar sua alta confiança e mantê-los integrados ao projeto.

Dica

Use testes repetíveis para garantir que relatórios, dashboards e outras visualizações sejam migrados com sucesso.

Você pode estar pensando em alternar as ferramentas de BI, por exemplo, para migrar para o Power BI. Existe a tentação de fazer todas essas mudanças ao mesmo tempo que a migração do seu esquema, seus dados, processamentos de ETL e outros. No entanto, para minimizar o risco, é melhor fazer a migração para o Azure Synapse primeiro e verificar se tudo está funcionando antes de expandir a modernização.

Se as ferramentas de BI existentes forem executadas localmente, verifique se elas conseguem se conectar ao Azure Synapse pelo firewall para que você possa executar comparações nos dois 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 aos aplicativos executados localmente com BI inserida ou que chamam o seu servidor de BI sob demanda, por exemplo, solicitando um "relatório headless" com dados XML ou JSON.

Há muito o que pensar neste campo; por isso, vejamos mais de perto.

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

Durante a migração, você pode ser tentado a cumprir requisitos de longo prazo, como abrir solicitações de negócios, 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 no 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 forma de minimizar o efeito de alterações de esquema ou estruturais de outro tipo sobre as ferramentas de BI é introduzir a virtualização de dados entre as ferramentas de BI, seu warehouse e os data marts. O diagrama a seguir mostra como a virtualização de dados pode ocultar a 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 proteger usuários empresariais contra mudanças estruturais durante a migração, para que eles não as percebam. 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, as alterações de esquema feitas durante a migração para o Azure Synapse (para otimizar o desempenho, por exemplo) podem ficar ocultas dos usuários empresariais, já que eles acessam apenas 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 os data marts e quaisquer tabelas virtuais. Com a virtualização de dados, os usuários continuam desconhecendo as alterações estruturais. Os parceiros da Microsoft fornecem ótimos softwares de virtualização de dados.

Identificar relatórios de alta prioridade a serem migrados primeiro

Uma pergunta importante ao migrar os relatórios e os painéis existentes para o Azure Synapse é quais deles devem ser migrados primeiro. Vários fatores podem orientar essa decisão, como:

• Uso

• Valor de negócios

• Facilidade de migração

• Estratégia de migração de dados

As seções a seguir discutem esses fatores.

Seja qual for sua decisão, ela deve envolver seus usuários empresariais, pois eles produzem os relatórios, painéis e outras visualizações, além de tomarem decisões de negócios com base em insights fornecidos por esses itens. Todos se beneficiam quando você pode:

• Migrar relatórios e painéis perfeitamente,
• Migrar relatórios e painéis com o mínimo de esforço e
• Apontar suas ferramentas de BI para o Azure Synapse em vez do sistema de data warehouse herdado e obter relatórios, painéis e outras visualizações semelhantes.

Migrar relatórios com base no uso

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

Se seu warehouse de dados herdado estiver 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 dos relatórios e painéis existentes e definir suas estatísticas de uso e a finalidade comercial de cada um.

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 ele não é usado porque as pessoas desconhecem sua existência, não oferece valor comercial ou foi substituído por outro.

Migrar relatórios com base no valor comercial

O uso por si só nem sempre é um bom indicador de valor comercial. Talvez você queira considerar até que ponto os insights fornecidos por um relatório contribuem para o valor comercial. Uma maneira de fazer isso é avaliar a rentabilidade de cada decisão empresarial que dependa do relatório e da extensão dessa 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 comercial é examinar o alinhamento de um relatório com a estratégia de negócios. Uma estratégia de negócios definida por seu executivo normalmente estabelece SBOs (objetivos estratégicos de negócios), KPIs (indicadores-chave de desempenho), metas de KPI que precisam ser alcançadas e quem é responsável por alcançá-las. Você pode classificar um relatório considerando para quais SBOs ele contribui, como redução de fraudes, melhor participação do cliente e operações comerciais otimizadas. Em seguida, pode priorizar para a migração os relatórios e painéis associados a objetivos de alta prioridade. Dessa forma, a migração inicial pode entregar valor comercial em uma área estratégica.

Outra maneira de avaliar o valor comercial é classificar relatórios e painéis 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. Saber quais relatórios e painéis são usados, o nível em que isso ocorre e a quais objetivos estão associados ajuda a concentrar a migração no valor comercial no valor comercial de alta prioridade. Você pode usar a tabela de objetivos de estratégia de negócios a seguir para avaliar relatórios e painéis.

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

Ferramentas de descoberta de metadados como o Catálogo de Dados do Azure permitem que usuários empresariais marquem e classifiquem fontes de dados para enriquecer os metadados dessas fontes de dados e ajudar na descoberta e classificação. Você pode usar os metadados de um relatório ou painel para ajudá-lo a entender seu valor comercial. Sem essas ferramentas, entender a contribuição de relatórios e painéis para o valor comercial 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 tiver como base a migração de data marts em primeiro lugar, a ordem dessa migração afetará quais relatórios e painéis serão migrados primeiro. Se sua estratégia tiver como base o valor comercial, a ordem de migração dos data marts para o Azure Synapse refletirá as prioridades comerciais. As ferramentas de descoberta de metadados podem ajudar a implementar sua estratégia mostrando quais tabelas de data mart fornecem dados para quais relatórios.

Dica

A estratégia de migração de dados afeta quais relatórios e visualizações 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, painéis e outras visualizações pela emissão de consultas SQL que acessam tabelas físicas e/ou exibições no seu warehouse de dados ou data mart. Quando você migra o data warehouse herdado para o Azure Synapse, vários fatores podem afetar a facilidade de migração de relatórios, painéis 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, painéis e outras visualizações podem ser:

• Tipos de tabela não padrão no DBMS do data warehouse herdado sem equivalente no Azure Synapse.

• Tipos de dados no DBMS do data warehouse herdado sem equivalente no Azure Synapse.

Na maioria dos casos, há uma solução alternativa para as incompatibilidades. Por exemplo, os dados em tipos de tabela sem suporte podem ser migrados 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 realizar cálculos no Azure Synapse para atingir o mesmo resultado.

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 relatórios e visualizações afetados por incompatibilidades de esquema, execute consultas no catálogo do sistema do seu data warehouse herdado para identificar tabelas com tipos de dados sem suporte. Em seguida, você pode usar metadados da 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 Netezza sem suporte.

Dica

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

O efeito de incompatibilidades de esquema sobre relatórios, painéis e outras visualizações pode ser menor do que você pensa, pois muitas ferramentas de BI não oferecem 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 de SQL

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

• Acessa exibições de DBMS de warehouse de dados herdadas que incluem funções SQL proprietárias que não têm equivalente no Azure Synapse.

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

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

Seu portfólio de relatórios pode incluir serviços de consulta inseridos, relatórios, painéis e outras visualizações. Não confie na documentação associada a esses itens para medir o efeito das incompatibilidades de 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 de SQL.

Usar instruções EXPLAIN para encontrar incompatibilidades de SQL

Você pode encontrar as incompatibilidades de SQL consultando a tabela do sistema _v_qryhist para ver a atividade recente do SQL no data warehouse herdado do Netezza. Para saber mais, confira a Tabela do histórico de consultas. 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 as instruções EXPLAIN no Azure Synapse. Quaisquer instruções SQL que contenham extensões SQL proprietárias sem suporte serão rejeitadas pelo Azure Synapse quando as instruções EXPLAINforem executadas. Essa abordagem permite avaliar a extensão das incompatibilidades de SQL.

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

Dica

Meça o impacto de incompatibilidades de SQL coletando seus arquivos de log do DBMS e executando EXPLAIN instruções.

Testar a migração de relatórios e painéis para o Azure Synapse Analytics

Um elemento-chave na migração de warehouse de dados é o teste de relatórios e painéis no Azure Synapse para verificar se a migração funcionou. Defina uma série de testes e um conjunto de resultados necessários em cada teste que precise ser executado a fim de verificar o êxito. Teste e compare os relatórios e painéis com seus sistemas de data warehouse existentes e migrados para:

• Identificar se as alterações de esquema feitas durante a migração afetaram a capacidade de execução, os resultados ou visualizações de relatórios 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.

• Verificar se todos os usuários foram migrados.

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

• Verificar 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).

• Garantir resultados consistentes em todos os relatórios, painéis e consultas conhecidos.

• Verificar se a migração de dados e de ETL foi concluída e não contém erros.

• Verificar se a privacidade dos dados foi 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 usuários, grupos de usuários, funções e privilégios, consulte Segurança, acesso e operações para migrações do Netezza.

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

Dica

Uma 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 painéis 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 original e migrado 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 for difícil.

Dica

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

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

Sua compreensão sobre linhagem é um fator crítico na migração bem-sucedida de relatórios e painéis. Linhagem são metadados que mostram o percurso dos dados migrados para que você possa acompanhar seu caminho de um relatório ou painel até a fonte de dados. A linhagem mostra como ocorreu o percurso ponto a ponto dos dados, sua localização no data warehouse e/ou no data mart e quais relatórios e painéis usar. Ela 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. Se os usuários empresariais tiverem acesso à linhagem de dados, isso aumentará a confiança e apoiará decisões comerciais mais bem informadas.

Dica

Ter acesso a metadados e linhagem de dados de relatórios em todo o percurso de volta até a fonte de dados é crítico para verificar se os relatórios migrados funcionam corretamente.

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

Dica

Ferramentas que automatizam a coleta de metadados e mostram a linhagem de ponta a ponta em um ambiente de vários fornecedores são valiosas em 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 relatórios e 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 suportem descoberta automatizada de metadados e linhagem de dados permitirá que você identifique relatórios e processos ETL duplicados, além de relatórios que dependam de fontes de dados obsoletas, questionáveis ou inexistentes. Com essas informações, você pode reduzir o número de relatórios e processos de ETL migrados.

Pode também comparar a linhagem de ponta a ponta de um relatório no Azure Synapse com a do mesmo relatório no seu ambiente herdado, para ver se há alguma diferença ocorrida 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 da linhagem de dados não apenas reduz tempo, esforço e erros no processo de migração, mas também permite uma execução mais rápida desse processo.

Aproveitando as ferramentas automatizadas de descoberta de metadados e linhagem de dados que podem comparar linhagens, você pode verificar se um relatório produzido no Azure Synapse com base em dados migrados é gerado da mesma forma no seu ambiente herdado. Esse tipo de funcionalidade também ajuda a determinar:

• Quais dados precisam ser migrados para garantir o sucesso da execução do relatório e do painel no Azure Synapse.

• Quais transformações foram e devem ser executadas para garantir o sucesso da execução no Azure Synapse.

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

Ferramentas automatizadas de descoberta de metadados e linhagem de dados simplificam substancialmente o processo de migração, pois ajudam as empresas a se tornarem mais conscientes quanto aos seus ativos de dados e saberem o que precisa ser migrado para o Azure Synapse para alcançar um ambiente sólido de geração de relatórios.

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

Migrar as camadas semânticas da ferramenta de BI para o Azure Synapse Analytics

Algumas ferramentas de BI têm o que é conhecido como camada semântica de metadados. 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 mapeados para as estruturas de dados físicas no data warehouse ou banco de dados do data mart.

Dica

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

Em uma migração de data warehouse, as alterações nos nomes das colunas ou tabelas podem ser impostas a você. Por exemplo, no IBM Netezza, os nomes de tabela podem ter um "#". No Azure Synapse, o "#" só é permitido como prefixo de um nome de tabela para indicar uma tabela temporária. No IBM Netezza, as tabelas temporárias não têm necessariamente um "#" no nome, mas no Synapse elas devem ter. Nesses casos, talvez seja necessário um retrabalho para alterar os mapeamentos de tabela.

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. Assim você configura tudo, inclusive campos calculados, junções e mapeamentos, apenas uma vez, e não em cada ferramenta. 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 que garanta a consistência de todas as ferramentas de BI em um ambiente do Azure Synapse.

Assim você obtém consistência em todas as ferramentas de BI e, ao mesmo tempo, quebra a dependência entre ferramentas e aplicativos de BI e as estruturas de dados físicas 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 acessem 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. Pode também encontrar exibições de data warehouse herdadas que incluem SQL proprietário sem equivalente 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 a localização de problemas. Em vez disso, use instruções EXPLAIN, pois elas são uma maneira rápida e pragmática de identificar incompatibilidades do SQL. Retrabalhe as instruções SQL incompatíveis para obter a 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 dependam de fontes de dados obsoletas, questionáveis ou inexistentes. Algumas dessas ferramentas ajudam a comparar a linhagem para verificar se os relatórios executados no seu 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 ajudar a determinar quais não estão em uso. Migre todos os usuários, grupos de usuários, funções e privilégios dos relatórios, dashboards e outras visualizações que você queira migrar. Se você estiver usando valor comercial para orientar sua estratégia de migração de relatórios, associe-os a prioridades e objetivos de negócios estratégicos, para melhor identificar a contribuição de insights fornecidos por esses relatórios 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 poder 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 as atribuições de usuários, funções de grupo e privilégios. Migre apenas os relatórios e as visualizações que são usados e contribuem para o valor comercial.

Podem ocorrer alterações estruturais no modelo de dados do data warehouse ou data mart 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 a consistência de nomes de dados comuns, definições, métricas, hierarquias e junções 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, confira o próximo artigo nesta série: Como minimizar problemas de SQL nas migrações do Netezza.