Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo é a quarta parte de uma série de sete partes que fornece orientação 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.
As organizações acessam data warehouses e data marts usando uma variedade de ferramentas e aplicativos de business intelligence (BI). Alguns exemplos de produtos de BI são:
Ferramentas de Microsoft BI, como o Power BI.
Aplicativos do Office, como planilhas do Microsoft Excel.
Ferramentas de BI de terceiros de diferentes fornecedores.
Aplicações analíticas personalizadas com funcionalidade de ferramenta de BI incorporada.
Aplicativos operacionais que suportam 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 Azure Synapse Spark Notebooks, 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 painéis existentes gerados pelos produtos de BI precisarão ser executados no novo ambiente. Seus produtos de BI devem produzir os mesmos resultados no Azure Synapse que produziram em seu ambiente de data warehouse herdado.
Para obter resultados consistentes após a migração, todas as ferramentas de BI e dependências de aplicativos devem funcionar depois que você migrar o esquema e os dados do data warehouse para o Azure Synapse. As dependências incluem aspetos 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 no data warehouse e nos bancos de dados do data mart no Azure Synapse.
Todos os utilizadores devem aceder ao Azure Synapse.
Todos os grupos de utilizadores no Azure Synapse.
Todas as funções no Azure Synapse.
Todos os privilégios de autorização que regem o controle de acesso ao Azure Synapse.
Atribuições de utilizador, função e privilégio que devem espelhar o que foi configurado no seu 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 discutidas com mais detalhes em Segurança, acesso e operações para migrações Oracle.
Gorjeta
Os usuários, grupos de usuários, funções e atribuições de privilégios de segurança de acesso existentes precisam 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 painéis que consultam dados no ambiente herdado produzam os mesmos resultados no Azure Synapse.
Os usuários corporativos esperarão uma migração perfeita, sem surpresas que destruam sua confiança no sistema migrado no Azure Synapse. Tome cuidado para acalmar quaisquer medos que seus usuários possam ter através de uma boa comunicação. Seus usuários esperarão que:
A estrutura da tabela permanece a mesma quando referida diretamente nas consultas.
Os nomes de tabelas e colunas permanecem os mesmos quando referidos diretamente nas consultas. Por exemplo, campos calculados definidos em colunas em ferramentas de BI não devem falhar quando 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 mantém-se inalterado.
Os drivers ODBC/JDBC são testados para garantir que o comportamento da consulta permaneça o mesmo.
Gorjeta
A comunicação e o envolvimento dos utilizadores empresariais são fundamentais para o sucesso.
Se as ferramentas de BI consultarem visualizaçõ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 podem não funcionar se houver extensões SQL proprietárias específicas para seu DBMS de data warehouse herdado que não tenham equivalente no Azure Synapse. Se sim, você precisa saber sobre essas incompatibilidades e encontrar uma maneira de resolvê-las.
Gorjeta
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 dados em plataformas DBMS, precisam ser testados para garantir que mesmo pequenas diferenças não existam nos resultados do NULL cálculo. Minimize esses problemas e tome todas as medidas necessárias para proteger os utilizadores empresariais de serem afetados por eles. Dependendo do seu ambiente de armazém de dados herdado, ferramentas de terceiros que podem ajudar a ocultar as diferenças entre os ambientes herdados e novos para que as ferramentas e aplicações de BI funcionem inalteradas.
Os testes são essenciais para a visualização e a migração de relatórios. Você 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 usuários corporativos no aspeto de teste da migração para manter a confiança alta e mantê-los envolvidos e parte do projeto.
Gorjeta
Use testes repetíveis para garantir que relatórios, painéis e outras visualizações sejam migrados com êxito.
Você pode estar pensando em alternar 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 para o Azure Synapse primeiro e fazer tudo funcionar antes de realizar uma modernização adicional.
Se suas ferramentas de BI existentes forem executadas localmente, certifique-se de que elas possam 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 executados no local que incorporam BI ou chamam seu servidor de BI sob demanda, por exemplo, solicitando um "relatório sem cabeça" com dados XML ou JSON.
Há muito o que pensar aqui, então vamos dar uma olhada mais de perto.
Durante a migração, você pode ficar tentado a atender a 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 seu data warehouse, especialmente se a alteração envolver alterações estruturais no seu modelo de dados. Se você quiser adotar uma técnica ágil de modelagem de dados ou implementar mudanças estruturais, faça-o após a migração.
Uma maneira de minimizar o efeito de 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 corporativos que utilizam ferramentas de BI de autoatendimento e o esquema físico do data warehouse subjacente e dos data marts que estão sendo migrados.
Gorjeta
A virtualização de dados permite que você proteja os usuários corporativos 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, quaisquer 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 inconscientes das mudanças estruturais. Os parceiros da Microsoft fornecem software de virtualização de dados.
Uma questão-chave ao migrar seus relatórios e painéis existentes para o Azure Synapse é quais migrar primeiro. Vários fatores podem impulsionar essa decisão, tais como:
Utilização
Valor comercial
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 seus usuários de negócios, pois eles produzem os relatórios, painéis e outras visualizações e tomam decisões de negócios com base em insights desses itens. Todos beneficiam quando podem.
- Migre relatórios e painéis sem problemas,
- Migre relatórios e painéis com o mínimo de esforço, e
- Aponte a(s) sua(s) ferramenta(s) de BI para o Azure Synapse em vez do seu sistema de armazém de dados herdado e obtenha relatórios, dashboards e outras visualizações semelhantes.
A utilização é muitas vezes um indicador do valor comercial. Relatórios e painéis 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 painéis não são usados, você pode usar uma das várias ferramentas de BI que fornecem estatísticas de uso.
Se o seu armazém de dados legado está em funcionamento há anos, há uma boa probabilidade de ter centenas, se não milhares, de relatórios existentes. Vale a pena compilar um inventário de relatórios e painéis e identificar seu propósito comercial e estatísticas de uso.
Para relatórios não utilizados, determine se deseja descomissioná-los para reduzir o esforço de migração. Uma questão-chave ao decidir se deve desativar um relatório não utilizado é se o relatório não é usado porque as pessoas não sabem que ele existe, porque não oferece valor comercial ou porque foi substituído por outro relatório.
O uso por si só nem sempre é um bom indicador de valor comercial. Talvez você queira considerar até que ponto os insights de um relatório contribuem para o valor comercial. Uma maneira de fazer isso é avaliar a rentabilidade de cada decisão de negócios que se baseia no relatório e na extensão da confiança. No entanto, é improvável que essas informações estejam prontamente disponíveis na maioria das organizações.
Outra maneira de avaliar o valor do negócio é olhar para o alinhamento de um relatório com a estratégia de negócios. A estratégia de negócios definida pelo seu executivo normalmente estabelece objetivos estratégicos de negócios (SBOs), indicadores-chave de desempenho (KPIs), metas de KPI que precisam ser alcançadas e quem é responsável por alcançá-las. Pode classificar um relatório de acordo com os SBOs a que contribui, como redução de fraudes, melhor envolvimento do cliente e operações comerciais otimizadas. Em seguida, você pode priorizar para migração os relatórios e painéis associados a objetivos de alta prioridade. Desta forma, a migração inicial pode entregar valor de negócio numa área estratégica.
Outra maneira de avaliar o valor do negócio é classificar relatórios e painéis como operacionais, táticos ou estratégicos para identificar em que nível de negócios eles são usados. As SBO exigem contribuições a todos estes níveis. Ao saber quais relatórios e painéis são usados, em que nível e a quais objetivos estão associados, você pode concentrar a migração inicial 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 utilização | Prioridade de negócios |
|---|---|---|---|---|---|
| Estratégico | |||||
| Tático | |||||
| Operacional |
As ferramentas de descoberta de metadados, como o Catálogo de Dados do Azure, permitem que os usuários corporativos 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 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, esteja você migrando ou não.
Se a sua estratégia de migração for baseada na migração dos data marts primeiro, a ordem da migração dos data marts afetará quais relatórios e painéis serão migrados primeiro. Se sua estratégia for baseada no valor comercial, a ordem na qual você migra 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.
Gorjeta
Sua estratégia de migração de dados afeta quais relatórios e visualizações são migrados primeiro.
As ferramentas de BI produzem relatórios, painéis 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, painéis e outras visualizações. Esses fatores incluem:
Incompatibilidades de esquema entre os ambientes.
Incompatibilidades SQL entre os ambientes.
Durante uma migração, as incompatibilidades de esquema no data warehouse ou nas tabelas do data mart que fornecem dados para relatórios, painéis 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.
Gorjeta
As incompatibilidades de esquema incluem tipos de tabela de DBMS de armazém de dados legados e tipos de dados não suportados pelo Azure Synapse.
Para identificar os relatórios afetados por incompatibilidades de esquema, realize consultas no catálogo do sistema da sua antiga base de dados de armazenagem para identificar as tabelas com tipos de dados não suportados. 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.
Gorjeta
Consulte o catálogo do sistema do DBMS do seu armazém de dados legado para identificar incompatibilidades de esquema com o Azure Synapse.
O efeito das incompatibilidades de esquema em relatórios, painéis e outras visualizações pode ser menor do que você imagina porque muitas ferramentas de BI não suportam os tipos de dados menos genéricos. Como resultado, o seu data warehouse herdado pode já ter visualizações que convertem tipos de dados não suportados em tipos mais genéricos.
Durante uma migração, as incompatibilidades SQL provavelmente afetarão qualquer relatório, painel ou outra visualização em um aplicativo ou ferramenta que:
Acede a vistas do DBMS de armazenamento de dados legadas que incluem funções SQL específicas que não têm equivalente para o 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.
Seu portfólio de relatórios pode incluir serviços de consulta incorporados, relatórios, painéis e outras visualizações. Não confie na documentação associada a esses itens para avaliar o efeito das incompatibilidades SQL na migração do seu portfólio de relatórios para o Azure Synapse. Você precisa usar uma maneira mais precisa de avaliar o efeito das incompatibilidades SQL.
Você pode encontrar incompatibilidades SQL ao examinar os logs de 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 EXPLAIN instrução 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 SQL.
Os metadados do DBMS do seu armazém de dados herdado também podem ajudá-lo a identificar vistas incompatíveis. Como antes, capture um conjunto representativo de instruções SQL dos logs aplicáveis, prefixe cada instrução SQL com uma EXPLAIN instrução e execute essas EXPLAIN instruções no Azure Synapse para identificar exibições com SQL incompatível.
Gorjeta
Avalie o impacto das incompatibilidades SQL coletando os arquivos de log do DBMS e executando EXPLAIN comandos.
Um elemento-chave da migração do data warehouse é 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 para cada teste que você executará para verificar o sucesso. Teste e compare os relatórios e painéis em seus sistemas de data warehouse existentes e migrados para:
Identifique se quaisquer alterações de esquema feitas 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 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 foram 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 lista de controle de acesso (ACL).
Garanta resultados consistentes para todas as consultas, relatórios e painéis conhecidos.
Certifique-se de que a migração de dados e ETL esteja completa e livre de erros.
Certifique-se de que a privacidade dos dados é mantida.
Teste o desempenho e a escalabilidade.
Testar a funcionalidade analítica.
Gorjeta
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 Oracle.
Automatize os testes tanto quanto 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 gerida através de orquestração de pipelines no Azure Synapse ou no Azure Data Factory. Se você já tiver um conjunto de consultas de teste para testes de regressão, poderá usar as ferramentas de teste existentes para automatizar os testes pós-migração.
Gorjeta
A prática recomendada é criar um conjunto de testes automatizados para tornar os testes repetíveis.
A análise e a geração de relatórios ad hoc são mais desafiadoras 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 linhagem de metadados entre os sistemas originais e migrados durante os testes de migração se tornará crucial. Essa comparação pode destacar diferenças e identificar onde as inconsistências se originaram, quando a deteção por outros meios é difícil.
Gorjeta
Aproveite as ferramentas que comparam a linhagem de metadados para verificar os resultados.
Sua compreensão da linhagem é um fator crítico na migração bem-sucedida de relatórios e painéis. Linhagem é metadado que mostra o percurso dos dados migrados para que possas mapear o seu caminho de um relatório ou painel até à fonte de dados. Lineage mostra como os dados viajaram de ponto a ponto, sua localização no data warehouse e/ou data mart e quais relatórios e painéis os usam. O Lineage pode ajudá-lo a entender o que acontece com os dados à medida que eles percorrem diferentes armazenamentos de dados, como arquivos e bancos de dados, diferentes pipelines de ETL e relatórios. Quando os usuários corporativos têm acesso à linhagem de dados, isso melhora a confiança, incute confiança e apoia decisões de negócios informadas.
Gorjeta
Sua capacidade de acessar metadados e linhagem de dados de relatórios até uma fonte de dados é fundamental para verificar se os relatórios migrados funcionam corretamente.
Em ambientes de data warehouse de vários fornecedores, os analistas de negócios em 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.
Gorjeta
Ferramentas que automatizam a coleta de metadados e mostram 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 o rastreamento de dados de ponta a ponta para comprovar uma migração equivalente ao compararem os relatórios e painéis gerados por cada ambiente. Para mostrar a jornada de dados de ponta a ponta, você precisará capturar e integrar metadados de várias ferramentas. Ter acesso a ferramentas que suportam a descoberta automatizada de metadados e a linhagem de dados ajuda a identificar relatórios duplicados ou processos 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 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 diferenças que possam 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 da linhagem de dados não só reduz o tempo, o esforço e o erro no processo de migração, mas também permite uma migração mais rápida.
Usando a descoberta automatizada de metadados e ferramentas de linhagem de dados que comparam linhagem, você pode verificar se um relatório no Azure Synapse produzido a partir de dados migrados é produzido da mesma maneira em seu ambiente herdado. Esse recurso também ajuda a determinar:
Quais dados precisam ser migrados para garantir a execução bem-sucedida de relatórios e painéis no Azure Synapse.
Quais transformações foram e devem ser executadas para garantir uma execução bem-sucedida no Azure Synapse.
Como reduzir a duplicação de relatórios.
A descoberta automatizada de metadados e as ferramentas de 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órios sólido.
Várias ferramentas de ETL fornecem capacidade de linhagem de ponta a ponta, portanto, verifique se sua ferramenta de ETL existente tem esse recurso se você planeja usá-la com o Azure Synapse. Os pipelines do Azure Synapse ou o Data Factory dão suporte à capacidade de exibir linhagem em fluxos de mapeamento. Os parceiros da Microsoft também fornecem descoberta automatizada de metadados, linhagem de dados e ferramentas de comparação de linhagem.
Algumas ferramentas de BI têm o que é conhecido como uma camada de metadados semânticos. Essa camada simplifica o acesso do usuário corporativo às estruturas de dados físicas subjacentes em um data warehouse ou banco de dados de 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 estruturas de dados físicas no seu data warehouse ou data mart.
Gorjeta
Algumas ferramentas de BI têm camadas semânticas que simplificam o acesso do usuário de negócios 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 colunas ou tabelas. Por exemplo, o Oracle permite um caractere em nomes de tabela #, mas o Azure Synapse só permite # como um prefixo de nome de tabela para indicar uma tabela temporária. Em Oracle, TABELAS TEMPORÁRIAS não têm necessariamente um "#" no nome, mas em Sinapse devem. Talvez seja necessário fazer algum retrabalho para alterar os 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 fica entre ferramentas e aplicativos de BI 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.
Gorjeta
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 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 vejam uma camada semântica comum.
Em uma migração de data warehouse de elevação e transferência, a maioria dos relatórios, painéis e outras visualizações deve migrar facilmente.
Durante uma migração de um ambiente herdado, pode-se descobrir que os dados no armazém de dados herdado ou nas tabelas do data mart são armazenados em tipos de dados sem suporte. Ou poderá encontrar visões de bases de dados herdadas que incluam SQL proprietário sem equivalente no Azure Synapse. Em caso afirmativo, 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 EXPLAIN instruções, pois são uma forma rápida e pragmática de identificar incompatibilidades SQL. Retrabalhe 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 e verificar se os relatórios em execução num ambiente legado de data warehouse 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, painéis 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 comercial para impulsionar sua estratégia de migração de relatórios, associe relatórios a objetivos e prioridades estratégicas de negócios para ajudar a identificar a contribuição dos insights de relatório para objetivos específicos. Se estiver a migrar um data mart de cada vez, use metadados para identificar quais relatórios dependem de quais tabelas e visões, para que possa tomar uma decisão informada sobre quais data marts migrar primeiro.
Gorjeta
Identificar incompatibilidades precocemente para avaliar a extensão do esforço de migração. Migre seus usuários, funções de grupo e atribuições de privilégio. 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 seu data warehouse ou data mart podem ocorrer durante uma migração. Considere o uso da virtualização de dados para proteger ferramentas e aplicativos de BI contra mudanças 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, definições, métricas, hierarquias e junções de dados comuns consistentes em todas as ferramentas e aplicativos de BI no novo ambiente do Azure Synapse.
Para saber mais sobre como minimizar problemas SQL, consulte o próximo artigo desta série: Minimizando problemas SQL para migrações Oracle.