Visualisation et création de rapports pour les migrations Oracle

Cet article fait partie quatre d’une série de sept parties qui fournit des conseils sur la migration d’Oracle vers Azure Synapse Analytics. L’objectif de cet article est de bonnes pratiques pour la visualisation et la création de rapports.

Accéder à Azure Synapse Analytics à l’aide de Microsoft et d’outils décisionnels tiers

Les organisations accèdent aux entrepôts de données et aux entrepôts de données à l’aide d’une gamme d’outils et d’applications décisionnels. Voici quelques exemples de produits pour le décisionnel :

• Outils Microsoft BI, tels que Power BI.

• Applications Office, telles que des feuilles de calcul Microsoft Excel.

• Outils d'intelligence décisionnelle tiers de différents fournisseurs.

• Applications d’analyse personnalisées avec fonctionnalités d’outil BI incorporées.

• Applications opérationnelles soutenant la BI à la demande en exécutant des requêtes et des rapports sur une plateforme BI qui interroge à son tour les données dans un entrepôt de données ou un magasin de données.

• Outils de développement de science des données interactifs, tels qu’Azure Synapse Spark Notebooks, Azure Machine Learning, RStudio et Jupyter Notebooks.

Si vous migrez la visualisation et la création de rapports dans le cadre de la migration de votre entrepôt de données, toutes les requêtes, rapports et tableaux de bord existants générés par les produits BI doivent s’exécuter dans le nouvel environnement. Vos produits BI doivent produire les mêmes résultats sur Azure Synapse que dans votre environnement d’entrepôt de données hérité.

Pour obtenir des résultats cohérents après la migration, tous les outils décisionnels et les dépendances d’application doivent fonctionner une fois que vous avez migré votre schéma et vos données d’entrepôt de données vers Azure Synapse. Les dépendances incluent des aspects moins visibles, tels que l’accès et la sécurité. Lorsque vous traitez l’accès et la sécurité, vérifiez que vous migrez :

• Authentification afin que les utilisateurs puissent se connecter aux bases de données de l’entrepôt de données et des magasins de données sur Azure Synapse.

• Tous les utilisateurs d’Azure Synapse.

• Tous les groupes d’utilisateurs vers Azure Synapse.

• Tous les rôles vers Azure Synapse.

• Tous les privilèges d’autorisation régissant le contrôle d’accès à Azure Synapse.

• Attributions d’utilisateurs, de rôle et de privilèges pour mettre en miroir ce que vous aviez dans votre entrepôt de données existant avant la migration. Par exemple:

  • Privilèges d’objet de base de données attribués aux rôles
  • Rôles attribués aux groupes d’utilisateurs
  • Utilisateurs affectés à des groupes d’utilisateurs et/ou à des rôles

L’accès et la sécurité sont des considérations importantes pour l’accès aux données dans le système migré et sont abordés plus en détail dans sécurité, accès et opérations pour les migrations Oracle.

Conseil / Astuce

Les utilisateurs existants, les groupes d’utilisateurs, les rôles et les affectations de privilèges de sécurité d’accès doivent d’abord être migrés pour la migration des rapports et des visualisations pour réussir.

Migrez toutes les données requises pour vous assurer que les rapports et les tableaux de bord qui interrogent les données dans l’environnement hérité produisent les mêmes résultats dans Azure Synapse.

Les utilisateurs professionnels s'attendront à une migration transparente, sans surprises, qui ne détruisent pas leur confiance dans le système migré sur Azure Synapse. Prenez soin d’apaiser toutes les craintes que vos utilisateurs pourraient avoir par le biais d’une bonne communication. Vos utilisateurs s’attendent à ce que :

• La structure de table reste la même lorsqu’elle est directement référencée dans les requêtes.

• Les noms de tables et de colonnes restent identiques lorsqu’ils sont directement référencés dans les requêtes. Par exemple, les champs calculés définis sur les colonnes dans les outils BI ne doivent pas échouer lorsque les rapports d’agrégation sont générés.

• L’analyse historique reste la même.

• Les types de données restent les mêmes, si possible.

• Le comportement de la requête SQL reste le même.

• Les pilotes ODBC/JDBC sont testés pour s’assurer que le comportement de requête reste le même.

Conseil / Astuce

La communication et l’implication des utilisateurs professionnels sont essentielles au succès.

Si les outils décisionnels interrogent des vues dans l’entrepôt de données ou la base de données data mart sous-jacente, ces vues fonctionneront-elles toujours après la migration ? Certaines vues peuvent ne pas fonctionner s’il existe des extensions SQL propriétaires spécifiques à votre SGBD d’entrepôt de données héritée qui n’ont pas d’équivalent dans Azure Synapse. Si c’est le cas, vous devez connaître ces incompatibilités et trouver un moyen de les résoudre.

Conseil / Astuce

Les vues et les requêtes SQL utilisant des extensions de requête SQL propriétaires sont susceptibles d’entraîner des incompatibilités qui affectent les rapports et les tableaux de bord BI.

D’autres problèmes, comme le comportement des valeurs ou des variantes de type de NULL données sur les plateformes SGBD, doivent être testés pour s’assurer que même de légères différences n’existent pas dans les résultats de calcul. Réduisez ces problèmes et prenez toutes les mesures nécessaires pour protéger les utilisateurs professionnels de leur impact. En fonction de votre environnement d’entrepôt de données hérité, les outils tiers qui peuvent aider à masquer les différences entre les environnements hérités et les nouveaux environnements afin que les outils décisionnels et les applications s’exécutent sans modification.

Les tests sont essentiels à la visualisation et à la migration de rapports. Vous avez besoin d’une suite de tests et de données de test acceptées pour exécuter et réexécuter des tests dans les deux environnements. Un harnais de test est également utile, et quelques-uns sont mentionnés dans ce guide. En outre, il est important d’impliquer les utilisateurs professionnels dans l’aspect de test de la migration afin de maintenir la confiance élevée et de les maintenir engagés et partie du projet.

Conseil / Astuce

Utilisez des tests reproductibles pour garantir la migration des rapports, des tableaux de bord et d’autres visualisations.

Vous pensez peut-être à changer d’outils décisionnels, par exemple pour migrer vers Power BI. La tentation est d’apporter ces modifications en même temps que vous migrez votre schéma, vos données, le traitement ETL, etc. Toutefois, pour réduire les risques, il est préférable de migrer vers Azure Synapse d’abord et d’obtenir tout ce qui fonctionne avant d’entreprendre une modernisation supplémentaire.

Si vos outils décisionnels existants s’exécutent localement, assurez-vous qu’ils peuvent se connecter à Azure Synapse via votre pare-feu pour pouvoir exécuter des comparaisons avec les deux environnements. Sinon, si le fournisseur de vos outils décisionnels existants propose leur produit sur Azure, vous pouvez l’essayer. La même chose s’applique aux applications qui s’exécutent localement qui incorporent bi ou appellent votre serveur BI à la demande, par exemple en demandant un « rapport sans tête » avec des données XML ou JSON.

Il y a beaucoup à penser ici, donc examinons de plus près.

Utiliser la virtualisation des données pour réduire l’impact de la migration sur les outils et rapports décisionnels

Lors de la migration, vous pouvez être tenté de répondre à des exigences à long terme telles que l’ouverture de demandes métier, l’ajout de données manquantes ou l’implémentation de nouvelles fonctionnalités. Toutefois, ces modifications peuvent affecter l’accès aux outils décisionnels à votre entrepôt de données, en particulier si la modification implique des modifications structurelles apportées à votre modèle de données. Si vous souhaitez adopter une technique de modélisation des données agile ou implémenter des modifications structurelles, procédez ainsi après la migration.

L’une des façons de réduire l’effet des modifications de schéma ou d’autres modifications structurelles sur vos outils décisionnels consiste à introduire la virtualisation des données entre les outils décisionnels et votre entrepôt de données et vos entrepôts de données. Le diagramme suivant montre comment la virtualisation des données peut masquer une migration des utilisateurs.

La virtualisation des données interrompt la dépendance entre les utilisateurs professionnels qui utilisent des outils décisionnels en libre-service et le schéma physique de l’entrepôt de données et des data marts sous-jacents en cours de migration.

Conseil / Astuce

La virtualisation des données vous permet de protéger les utilisateurs professionnels des changements structurels lors de la migration afin qu’ils ne sachent pas ces modifications. Les modifications structurelles incluent des modifications de schéma qui ajustent votre modèle de données pour Azure Synapse.

Avec la virtualisation des données, toutes les modifications de schéma apportées lors d’une migration vers Azure Synapse, par exemple pour optimiser les performances, peuvent être masquées des utilisateurs professionnels, car ils n’ont accès qu’aux tables virtuelles dans la couche de virtualisation des données. Et, si vous apportez des modifications structurelles, vous devez uniquement mettre à jour les mappages entre l’entrepôt de données ou les magasins de données et toutes les tables virtuelles. Avec la virtualisation des données, les utilisateurs ne connaissent pas les changements structurels. Les partenaires Microsoft fournissent des logiciels de virtualisation des données.

Identifier les rapports de haute priorité à migrer en premier

Une question clé lors de la migration de vos rapports et tableaux de bord existants vers Azure Synapse est celle à migrer en premier. Plusieurs facteurs peuvent conduire à cette décision, par exemple :

• Utilisation

• Valeur commerciale

• Facilité de migration

• Stratégie de migration des données

Les sections suivantes décrivent ces facteurs.

Quelle que soit votre décision, elle doit impliquer vos utilisateurs professionnels, car ils produisent les rapports, les tableaux de bord et d’autres visualisations, et prennent des décisions métier en fonction des insights de ces éléments. Tout le monde en profite quand vous pouvez :

• Migrer des rapports et des tableaux de bord en toute transparence,
• Migrer des rapports et des tableaux de bord avec un effort minimal et
• Pointez vos outils décisionnels sur Azure Synapse au lieu de votre système d’entrepôt de données hérité et obtenez des rapports, des tableaux de bord et d’autres visualisations similaires.

Migrer des rapports en fonction de l’utilisation

L’utilisation est souvent un indicateur de valeur métier. Les rapports et tableaux de bord inutilisés ne contribuent pas clairement aux décisions d’entreprise ou n’offrent pas de valeur actuelle. Si vous n’avez pas de moyen de déterminer quels rapports et tableaux de bord ne sont pas utilisés, vous pouvez utiliser l’un des plusieurs outils décisionnels qui fournissent des statistiques d’utilisation.

Si votre entrepôt de données hérité a été opérationnel depuis des années, il y a de bonnes chances que vous ayez des centaines, voire des milliers, de rapports en existence. Il vaut la peine de compiler un inventaire des rapports et des tableaux de bord et d’identifier leur objectif métier et leurs statistiques d’utilisation.

Pour les rapports inutilisés, déterminez s’il faut les désactiver pour réduire votre effort de migration. Une question clé lorsque vous décidez s’il faut désactiver un rapport inutilisé est de savoir si le rapport n’est pas utilisé parce que les gens ne savent pas qu’il existe, parce qu’il n’offre aucune valeur métier ou parce qu’il a été remplacé par un autre rapport.

Migrer des rapports en fonction de la valeur métier

L’utilisation seule n’est pas toujours un bon indicateur de valeur métier. Vous pouvez envisager la mesure dans laquelle les insights d’un rapport contribuent à la valeur métier. Une façon de procéder consiste à évaluer la rentabilité de chaque décision d’entreprise qui s’appuie sur le rapport et l’étendue de la dépendance. Toutefois, ces informations sont peu susceptibles d’être facilement disponibles dans la plupart des organisations.

Une autre façon d’évaluer la valeur métier consiste à examiner l’alignement d’un rapport avec la stratégie métier. La stratégie d’entreprise définie par votre cadre établit généralement des objectifs stratégiques (SBO), des indicateurs de performance clés (KPI), des objectifs de kPI qui doivent être atteints et qui est responsable de leur réalisation. Vous pouvez classer un rapport en fonction des SBO auxquels il contribue, par exemple la réduction des fraudes, l'amélioration de l'engagement client, et l'optimisation des opérations commerciales. Ensuite, vous pouvez hiérarchiser la migration des rapports et tableaux de bord associés à des objectifs à priorité élevée. De cette façon, la migration initiale peut fournir une valeur métier dans un domaine stratégique.

Une autre façon d’évaluer la valeur métier consiste à classer les rapports et les tableaux de bord en tant que rapports opérationnels, tactiques ou stratégiques pour identifier le niveau métier utilisé. Les SBO nécessitent des contributions à tous ces niveaux. En sachant quels rapports et tableaux de bord sont utilisés, à quel niveau et quels objectifs ils sont associés, vous pouvez concentrer la migration initiale sur la valeur métier à priorité élevée. Vous pouvez utiliser le tableau d’objectif de stratégie métier suivant pour évaluer les rapports et les tableaux de bord.

Niveau	Rapport / nom du tableau de bord	Objectif commercial	Service utilisé	Fréquence d’utilisation	Priorité métier
Stratégique
Tactique
En fonctionnement

Les outils de découverte de métadonnées comme Azure Data Catalog permettent aux utilisateurs professionnels de baliser et de noter les sources de données pour enrichir les métadonnées de ces sources de données afin d’aider à la découverte et à la classification. Vous pouvez utiliser les métadonnées d’un rapport ou d’un tableau de bord pour vous aider à comprendre sa valeur métier. Sans ces outils, la compréhension de la contribution des rapports et des tableaux de bord à la valeur métier est susceptible d’être une tâche fastidieuse, que vous migrez ou non.

Migrer des rapports en fonction de la stratégie de migration de données

Si votre stratégie de migration est basée sur la migration des data marts en premier, l’ordre de migration de data mart affecte d’abord les rapports et tableaux de bord qui sont migrés. Si votre stratégie est basée sur la valeur métier, l’ordre dans lequel vous migrez des data marts vers Azure Synapse reflète les priorités métier. Les outils de découverte des métadonnées peuvent vous aider à implémenter votre stratégie en montrant les tables de data mart qui fournissent des données pour quels rapports.

Conseil / Astuce

Votre stratégie de migration de données affecte les rapports et les visualisations qui sont migrés en premier.

Problèmes d’incompatibilité de migration qui peuvent affecter les rapports et les visualisations

Les outils décisionnels produisent des rapports, des tableaux de bord et d’autres visualisations en émettant des requêtes SQL qui accèdent à des tables physiques et/ou des vues dans votre entrepôt de données ou votre entrepôt de données. Lorsque vous migrez votre entrepôt de données hérité vers Azure Synapse, plusieurs facteurs peuvent affecter la facilité de migration des rapports, des tableaux de bord et d’autres visualisations. Ces facteurs sont les suivants :

• Incompatibilités de schéma entre les environnements.

• Incompatibilités SQL entre les environnements.

Incompatibilités de schéma

Lors d’une migration, les incompatibilités de schéma dans l’entrepôt de données ou les tables data mart qui fournissent des données pour les rapports, les tableaux de bord et d’autres visualisations peuvent être :

• Types de tables non conventionnels dans votre SGBD de l’entrepôt de données existant qui n’ont pas d’équivalent dans Azure Synapse.

• Types de données dans votre ancien entrepôt de données SGBD qui n’ont pas d’équivalent dans Azure Synapse.

Dans la plupart des cas, il existe une solution de contournement aux incompatibilités. Par exemple, vous pouvez migrer les données d’un type de table non pris en charge dans une table standard avec les types de données appropriés et indexés ou partitionnés sur une colonne de date/heure. De même, il peut être possible de représenter des types de données non pris en charge dans un autre type de colonne et d’effectuer des calculs dans Azure Synapse pour obtenir les mêmes résultats.

Conseil / Astuce

Les incompatibilités de schéma incluent les types de tables DBMS d’entrepôt hérités et les types de données qui ne sont pas pris en charge sur Azure Synapse.

Pour identifier les rapports affectés par des incompatibilités de schéma, exécutez des requêtes sur le catalogue système de votre entrepôt de données hérité pour identifier les tables avec des types de données non pris en charge. Ensuite, vous pouvez utiliser des métadonnées de votre outil BI pour identifier les rapports qui accèdent aux données de ces tableaux. Pour plus d’informations sur l’identification des incompatibilités de type d’objet, consultez Types d’objets de base de données Oracle non pris en charge.

Conseil / Astuce

Interrogez le catalogue système de votre DBMS d’entrepôt hérité pour identifier les incompatibilités de schéma avec Azure Synapse.

L’effet des incompatibilités de schéma sur les rapports, les tableaux de bord et d’autres visualisations peut être inférieur à ce que vous pensez, car de nombreux outils décisionnels ne prennent pas en charge les types de données moins génériques. Ainsi, votre entrepôt de données hérité dispose peut-être déjà de vues qui effectuent un CAST des types de données non pris en charge en types plus génériques.

Incompatibilités SQL

Lors d’une migration, les incompatibilités SQL sont susceptibles d’affecter tout rapport, tableau de bord ou autre visualisation dans une application ou un outil qui :

• Accède aux vues du SGBD d’entrepôt de données hérité qui incluent des fonctions SQL propriétaires n’ayant pas d’équivalent dans Azure Synapse.

• Émet des requêtes SQL qui incluent des fonctions SQL propriétaires, spécifiques au dialecte SQL de votre environnement hérité, qui n’ont pas d’équivalent dans Azure Synapse.

Évaluer l’impact des incompatibilités SQL sur votre portefeuille de rapports

Votre portefeuille de rapports peut inclure des services de requête incorporés, des rapports, des tableaux de bord et d’autres visualisations. Ne vous fiez pas à la documentation associée à ces éléments pour évaluer l’effet des incompatibilités SQL sur la migration de votre portefeuille de rapports vers Azure Synapse. Vous devez utiliser un moyen plus précis d’évaluer l’effet des incompatibilités SQL.

Utiliser des instructions EXPLAIN pour rechercher des incompatibilités SQL

Vous trouverez des incompatibilités SQL en examinant les journaux d’activité SQL récentes dans votre entrepôt de données Oracle hérité. Utilisez un script pour extraire un ensemble représentatif d’instructions SQL dans un fichier. Ensuite, préfixez chaque instruction SQL avec une EXPLAIN instruction et exécutez ces EXPLAIN instructions dans Azure Synapse. Toutes les instructions SQL contenant des extensions SQL non prises en charge propriétaires sont rejetées par Azure Synapse lorsque les EXPLAIN instructions sont exécutées. Cette approche vous permet d’évaluer l’étendue des incompatibilités SQL.

Les métadonnées de votre SGBD d’entrepôt de données hérité peuvent également vous aider à identifier les vues incompatibles. Comme précédemment, capturez un ensemble représentatif d’instructions SQL à partir des journaux d’activité applicables, préfixez chaque instruction SQL avec une EXPLAIN instruction et exécutez ces EXPLAIN instructions dans Azure Synapse pour identifier les vues avec sql incompatible.

Conseil / Astuce

Évaluez l’impact des incompatibilités SQL en collectant vos fichiers journaux DBMS et en exécutant des instructions EXPLAIN.

Tester la migration de rapport et de tableau de bord vers Azure Synapse Analytics

Un élément clé de la migration de l’entrepôt de données teste les rapports et les tableaux de bord dans Azure Synapse pour vérifier que la migration a fonctionné. Définissez une série de tests et un ensemble de résultats requis pour chaque test que vous allez exécuter pour vérifier la réussite. Testez et comparez les rapports et tableaux de bord sur vos systèmes d’entrepôt de données existants et migrés vers :

• Identifiez si des modifications de schéma effectuées pendant la migration ont affecté la capacité des rapports à exécuter, à générer des résultats de rapport ou aux visualisations de rapport correspondantes. Un exemple de modification de schéma est que vous avez mappé un type de données incompatible à un type de données équivalent pris en charge dans Azure Synapse.

• Vérifiez que tous les utilisateurs sont migrés.

• Vérifiez que tous les rôles sont migrés et que les utilisateurs sont affectés à ces rôles.

• Vérifiez que tous les privilèges de sécurité d’accès aux données sont migrés pour garantir la migration de la liste de contrôle d’accès (ACL).

• Assurez-vous des résultats cohérents pour toutes les requêtes, rapports et tableaux de bord connus.

• Vérifiez que les données et la migration ETL sont complètes et sans erreur.

• Assurez-vous que la confidentialité des données est maintenue.

• Testez les performances et l’extensibilité.

• Tester la fonctionnalité analytique.

Conseil / Astuce

Testez et ajustez les performances pour réduire les coûts de calcul.

Pour plus d’informations sur la migration d’utilisateurs, de groupes d’utilisateurs, de rôles et de privilèges, consultez Sécurité, accès et opérations pour les migrations Oracle.

Automatisez les tests autant que possible pour rendre chaque test reproductible et prendre en charge une approche cohérente pour évaluer les résultats des tests. L'automatisation fonctionne bien pour les rapports réguliers bien définis et peut être gérée via des pipelines Azure Synapse ou l’orchestration Azure Data Factory. Si vous disposez déjà d’une suite de requêtes de test en place pour les tests de régression, vous pouvez utiliser les outils de test existants pour automatiser les tests post-migration.

Conseil / Astuce

La meilleure pratique consiste à créer une suite de tests automatisée pour rendre les tests reproductibles.

L’analyse et les rapports ad hoc sont plus difficiles et nécessitent la compilation d’un ensemble de tests pour vérifier que les mêmes rapports et tableaux de bord avant et après la migration sont cohérents. Si vous trouvez des incohérences, votre capacité à comparer la traçabilité des métadonnées entre les systèmes d’origine et migrés pendant les tests de migration devient cruciale. Cette comparaison peut mettre en évidence les différences et identifier l’origine des incohérences, lorsque la détection par d’autres moyens est difficile.

Conseil / Astuce

Tirez parti des outils qui comparent la traçabilité des métadonnées pour vérifier les résultats.

Analyser le lignage pour comprendre les dépendances entre les rapports, les tableaux de bord et les données

Comprendre le lignage est un facteur essentiel dans la réussite de la migration des rapports et des tableaux de bord. La lignée est des métadonnées qui indiquent le parcours des données migrées afin que vous puissiez retracer leur chemin depuis la source de données jusqu'à un rapport ou un tableau de bord. La lignée des données montre comment les données ont parcouru d'un point à un autre, leur emplacement dans l’entrepôt de données et/ou le magasin de données, et quels rapports et tableaux de bord les utilisent. La traçabilité peut vous aider à comprendre ce qui arrive aux données au fur et à mesure qu’elles transitent par différents magasins de données, tels que des fichiers et des bases de données, des pipelines ETL différents et dans des rapports. Lorsque les utilisateurs professionnels ont accès à la traçabilité des données, ils améliorent la confiance, inculquent la confiance et prennent en charge les décisions métier éclairées.

Conseil / Astuce

Votre capacité à accéder aux métadonnées et à la lignée des données, depuis les rapports jusqu'à leur source de données, est essentielle pour vérifier que les rapports migrés fonctionnent correctement.

Dans les environnements d’entrepôt de données multi-fournisseurs, les analystes métiers dans les équipes BI peuvent établir la traçabilité des données. Par exemple, si vous utilisez différents fournisseurs pour l’ETL, l’entrepôt de données et la création de rapports, et que chaque fournisseur possède son propre référentiel de métadonnées, alors déterminer l’origine d’un élément de données spécifique dans un rapport peut être difficile et chronophage.

Conseil / Astuce

Les outils qui automatisent la collection de métadonnées et affichent la traçabilité de bout en bout dans un environnement multi-fournisseur sont utiles lors d’une migration.

Pour migrer en toute transparence à partir d’un entrepôt de données hérité vers Azure Synapse, utilisez la traçabilité des données de bout en bout pour prouver une migration semblable à celle-ci lorsque vous comparez les rapports et tableaux de bord générés par chaque environnement. Pour afficher le parcours de données de bout en bout, vous devez capturer et intégrer des métadonnées à partir de plusieurs outils. L’accès aux outils qui prennent en charge la découverte automatisée des métadonnées et la traçabilité des données vous permet d’identifier les rapports en double ou les processus ETL et de trouver des rapports qui s’appuient sur des sources de données obsolètes, discutables ou inexistantes. Vous pouvez utiliser ces informations pour réduire le nombre de rapports et de processus ETL que vous migrez.

Vous pouvez également comparer la traçabilité de bout en bout d’un rapport dans Azure Synapse à la traçabilité de bout en bout du même rapport dans votre environnement hérité pour vérifier les différences qui peuvent avoir eu lieu par inadvertance pendant la migration. Ce type de comparaison est exceptionnellement utile lorsque vous devez tester et vérifier la réussite de la migration.

La visualisation de traçabilité des données réduit non seulement le temps, l’effort et l’erreur dans le processus de migration, mais permet également une migration plus rapide.

En utilisant des outils automatisés de découverte des métadonnées et de traçabilité des données qui comparent la traçabilité, vous pouvez vérifier qu’un rapport dans Azure Synapse produit à partir de données migrées est généré de la même façon dans votre environnement hérité. Cette fonctionnalité vous aide également à déterminer :

• Quelles données doivent être migrées pour garantir la réussite de l’exécution du rapport et du tableau de bord dans Azure Synapse.

• Quelles transformations ont été et doivent être effectuées pour garantir la réussite de l’exécution dans Azure Synapse.

• Comment réduire la duplication des rapports.

Les outils automatisés de découverte des métadonnées et de traçabilité des données simplifient considérablement le processus de migration, car ils aident les entreprises à mieux connaître leurs ressources de données et à savoir ce qui doit être migré vers Azure Synapse pour obtenir un environnement de création de rapports solide.

Plusieurs outils ETL fournissent une fonctionnalité de traçabilité de bout en bout. Vérifiez donc si votre outil ETL existant dispose de cette fonctionnalité si vous envisagez de l’utiliser avec Azure Synapse. Les pipelines Azure Synapse ou Data Factory prennent tous deux en charge la possibilité d’afficher la traçabilité dans les flux de mappage. Les partenaires Microsoft fournissent également des outils de découverte automatisée de métadonnées, de traçabilité des données et de comparaison de lignées.

Migrer des couches sémantiques de l’outil BI vers Azure Synapse Analytics

Certains outils décisionnels ont ce qu’on appelle une couche de métadonnées sémantiques. Cette couche simplifie l’accès des utilisateurs professionnels aux structures de données physiques sous-jacentes d’un entrepôt de données ou d’une base de données data mart. La couche de métadonnées sémantiques simplifie l’accès en fournissant des objets de haut niveau, tels que des dimensions, des mesures, des hiérarchies, des métriques calculées et des jointures. Les objets de niveau supérieur utilisent des termes métiers familiers aux analystes métiers et sont associés aux structures de données physiques de votre entrepôt de données ou de votre data mart.

Conseil / Astuce

Certains outils décisionnels ont des couches sémantiques qui simplifient l’accès des utilisateurs professionnels aux structures de données physiques dans votre entrepôt de données ou votre entrepôt de données.

Dans une migration d’entrepôt de données, vous pouvez être obligé de modifier les noms de colonnes ou de tables. Par exemple, Oracle autorise un caractère dans les # noms de tables, mais Azure Synapse autorise # uniquement comme préfixe de nom de table pour indiquer une table temporaire. Dans Oracle, LES TABLES TEMPORAIREs n’ont pas nécessairement de « # » dans le nom, mais dans Synapse, elles doivent. Vous devrez peut-être modifier les mappages de tables dans ce cas.

Pour obtenir une cohérence entre plusieurs outils décisionnels, créez une couche sémantique universelle à l’aide d’un serveur de virtualisation des données qui se trouve entre les outils et applications décisionnels et Azure Synapse. Dans le serveur de virtualisation des données, utilisez des noms de données courants pour les objets de haut niveau, tels que les dimensions, les mesures, les hiérarchies et les jointures. De cette façon, vous configurez tout, y compris les champs calculés, les jointures et les mappages, une seule fois au lieu de chaque outil. Ensuite, pointez tous les outils décisionnels sur le serveur de virtualisation des données.

Conseil / Astuce

Utilisez la virtualisation des données pour créer une couche sémantique commune pour garantir la cohérence entre tous les outils décisionnels dans un environnement Azure Synapse.

Avec la virtualisation des données, vous bénéficiez d’une cohérence entre tous les outils décisionnels et brisez la dépendance entre les outils et applications décisionnels et les structures de données physiques sous-jacentes dans Azure Synapse. Les partenaires Microsoft peuvent vous aider à assurer la cohérence dans Azure. Le diagramme suivant montre comment un vocabulaire courant dans le serveur de virtualisation des données permet à plusieurs outils bi de voir une couche sémantique commune.

Conclusions

Dans une migration de type « lift-and-shift » d’un entrepôt de données, la plupart des rapports, des tableaux de bord et des autres visualisations devraient se transférer facilement.

Lors d’une migration à partir d’un environnement hérité, vous pouvez trouver que les données de l’entrepôt de données hérité ou des tables de data mart sont stockées dans des types de données non pris en charge. Vous pouvez également trouver des vues d’entrepôt de données anciens qui comprennent du SQL propriétaire sans équivalent dans Azure Synapse. Si c’est le cas, vous devez résoudre ces problèmes pour garantir une migration réussie vers Azure Synapse.

Ne vous fiez pas à la documentation gérée par l’utilisateur pour identifier l’emplacement des problèmes. Utilisez plutôt les instructions EXPLAIN car elles constituent un moyen rapide et pragmatique d’identifier les incompatibilités SQL. Remaniez les instructions SQL incompatibles pour obtenir des fonctionnalités équivalentes dans Azure Synapse. Utilisez également des outils automatisés de découverte et de traçabilité des métadonnées pour comprendre les dépendances, rechercher des rapports en double et identifier des rapports non valides qui s’appuient sur des sources de données obsolètes, douteuses ou inexistantes. Utilisez des outils de traçabilité pour comparer les lignées afin de vérifier que les rapports exécutés dans votre ancien entrepôt de données sont générés de manière identique dans Azure Synapse.

Ne migrez pas les rapports que vous n’utilisez plus. Les données d’utilisation des outils décisionnels peuvent vous aider à déterminer les rapports qui ne sont pas utilisés. Pour les rapports, tableaux de bord et autres visualisations que vous souhaitez migrer, migrer tous les utilisateurs, groupes d’utilisateurs, rôles et privilèges. Si vous utilisez la valeur métier pour favoriser votre stratégie de migration de rapports, associez des rapports aux objectifs et priorités stratégiques pour vous aider à identifier la contribution des insights de rapport à des objectifs spécifiques. Si vous migrez un datamarts par un datamarts, utilisez les métadonnées pour identifier les rapports qui dépendent des tables et des vues, afin de pouvoir prendre une décision éclairée sur les datamarts à migrer en premier.

Conseil / Astuce

Identifiez les incompatibilités précoces pour évaluer l’ampleur de l’effort de migration. Migrez vos utilisateurs, rôles de groupe et affectations de privilèges. Migrez uniquement les rapports et les visualisations utilisés et contribuent à la valeur métier.

Les modifications structurelles apportées au modèle de données de votre entrepôt de données ou de votre entrepôt de données peuvent se produire pendant une migration. Envisagez d’utiliser la virtualisation des données pour protéger les outils et applications décisionnels des changements structurels. Avec la virtualisation des données, vous pouvez utiliser un vocabulaire commun pour définir une couche sémantique commune. La couche sémantique commune garantit des noms de données, des définitions, des métriques, des hiérarchies et des jointures cohérentes dans tous les outils et applications BI dans le nouvel environnement Azure Synapse.

Étapes suivantes

Pour en savoir plus sur la réduction des problèmes SQL, consultez l’article suivant de cette série : Réduction des problèmes SQL pour les migrations Oracle.