Visualisation et création de rapports pour les migrations Oracle

Cet article est le quatrième d’une série en sept parties qui fournit des conseils d’aide sur la migration d’Oracle vers Azure Synapse Analytics. Cet article se concentre sur les bonnes pratiques liées à la visualisation et la création de rapports.

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

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

• Outils décisionnels de Microsoft, comme Power BI.

• Applications Office, comme les feuilles de calcul Microsoft Excel.

• Outils décisionnels tiers de divers fournisseurs.

• Applications d’analytique personnalisée avec fonctionnalités d’outils décisionnels incorporées.

• Les applications opérationnelles qui prennent en charge des données décisionnelles à la demande en appelant des requêtes et des rapports sur une plateforme décisionnelle, qui interrogent à leur tour les données dans un entrepôt de données ou un datamart.

• Outils de développement de science des données interactifs, par exemple Azure Synapse Spark Notebooks, Azure Machine Learning, RStudio et Jupyter Notebook.

Si vous migrez la visualisation et les 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 décisionnels doivent s’exécuter dans le nouvel environnement. Vos produits décisionnels 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é. Quand vous abordez les questions d’accès et de sécurité, assurez-vous de migrer :

• L’authentification pour permettre aux utilisateurs de se connecter aux bases de données d’entrepôt de données et de datamart sur Azure Synapse.

• Tous les utilisateurs vers 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 vers Azure Synapse.

• Les attributions d’utilisateurs, de rôles et de privilèges pour refléter 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 points importants à prendre en considération pour l’accès aux données dans le système migré. Ils sont décrits plus en détail dans Sécurité, accès et opérations pour les migrations Oracle.

Conseil

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

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

Les utilisateurs professionnels s’attendent à une migration transparente, sans surprise, qui ne doit pas détruire leur confiance dans le système migré sur Azure Synapse. Veillez à apaiser les craintes éventuelles de vos utilisateurs grâce à une bonne communication. Vos utilisateurs s’attendent à ce que :

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

• Les noms de table et de colonne 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 décisionnels ne doivent pas échouer lorsque des rapports d’agrégation sont générés.

• L’analyse historique reste la même.

• Les types de données doivent rester identiques dans la mesure du possible.

• Le comportement des requêtes reste le même.

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

Conseil

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

Si les outils décisionnels interrogent les vues dans la base de données de l’entrepôt de données ou de datamart 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 de l’entrepôt de données hérité 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

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 décisionnels.

D’autres problèmes, comme le comportement des valeurs NULL ou des variantes de type de données sur les plateformes SGBD, doivent être testés pour s’assurer que même les 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 d’être affectés par eux. Selon votre environnement d’entrepôt de données hérité, les outils tiers peuvent vous aider à masquer les différences entre les environnements hérités et les nouveaux environnements afin que les outils et applications décisionnels s’exécutent sans être modifiés.

Le test est essentiel pour la migration des visualisations et 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 atelier de test est également utile. Quelques-uns sont mentionnés dans ce guide. Il est également important d’impliquer des utilisateurs professionnels dans l’aspect de test de la migration afin de maintenir leur niveau de confiance élevé et qu’ils soient motivés à rester dans le projet.

Conseil

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

Vous pensez peut-être à changer d’outils décisionnels, par exemple pour migrer vers Power BI. La tentation est de faire tous ces changements ensemble, tout en migrant votre schéma, vos données, le traitement ETL, etc. Toutefois, pour réduire le risque, il est préférable de migrer vers Azure Synapse d’abord et de tout faire fonctionner avant d’entreprendre une modernisation supplémentaire.

Si vos outils décisionnel existants s’exécutent localement, vérifiez qu’ils peuvent se connecter à Azure Synapse via votre pare-feu pour effectuer des comparaisons sur les deux environnements. Sinon, si le fournisseur de vos outils décisionnels existants propose son produit sur Azure, vous pouvez l’essayer. Il en va de même pour les applications s’exécutant localement et qui incorporent du décisionnel, ou qui appellent votre serveur décisionnel à la demande, par exemple, en sollicitant un « rapport brut » avec des données XML ou JSON.

Il faut penser à beaucoup de choses ici, alors passons-les en revue.

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

Pendant 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 des outils décisionnels à votre entrepôt de données, en particulier si le changement implique des modifications structurelles apportées à votre modèle de données. Si vous souhaitez adopter une technique agile de modélisation des données ou mettre en œuvre des changements structurels, faites-le après la migration.

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

La virtualisation des données rompt la dépendance entre les utilisateurs professionnels qui se servent d’outils décisionnels libre-service et le schéma physique de l’entrepôt de données et des datamarts sous-jacents migrés.

Conseil

La virtualisation des données vous permet de protéger les utilisateurs professionnels des changements structurels durant la migration pour qu’ils ne soient pas affectés par les changements apportés. Les changements structurels incluent des modifications de schéma qui ajustent votre modèle de données pour Azure Synapse.

La virtualisation des données permet de masquer aux utilisateurs les changements de schéma effectués lors de la migration vers Azure Synapse (par exemple, pour optimiser les performances), car les utilisateurs accèdent uniquement aux tables virtuelles de la couche de virtualisation des données. Et, si vous apportez des changements structurels, vous devez uniquement mettre à jour les mappages entre l’entrepôt de données ou les datamarts et toutes les tables virtuelles. Avec la virtualisation des données, les utilisateurs ne sont pas conscients des changements structurels. Les partenaires Microsoft fournissent des logiciels de virtualisation de 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 de savoir lesquels migrer en premier. Plusieurs facteurs peuvent conduire à cette décision, par exemple :

• Usage

• Valeur métier

• Facilité de migration

• Stratégie de migration de données

Les sections suivantes traitent de 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 basées sur les insights de ces éléments. Tout le monde en profite lorsque 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
• pointer vos outils décisionnels sur Azure Synapse au lieu de votre système d’entrepôt de données hérité et obtenir des rapports, des tableaux de bord et d’autres visualisations similaires.

Migrer les rapports en fonction de l’utilisation

L’utilisation est souvent un indicateur de la valeur métier. Les rapports et tableaux de bord inutilisés ne contribuent clairement pas 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 outils décisionnels qui fournissent des statistiques d’utilisation.

Si votre entrepôt de données hérité est opérationnel depuis de nombreuses années, il existe de bonnes chances que vous disposiez de centaines, voire de milliers de rapports. Cela vaut la peine de compiler un inventaire des rapports et des tableaux de bord dont vous disposez, et de définir leur objectif métier ainsi que 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é lors de la décision de 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 (il n’offre aucune valeur commerciale) ou parce qu’il a été remplacé par un autre rapport.

Migrer les 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 dans quelle mesure les informations contenues dans un rapport contribuent à la valeur métier. Une façon d’effectuer cela 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 risquent de ne pas ê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 métier définie par votre direction expose généralement les objectifs métier stratégiques (SBO), les indicateurs de performance clés (KPI), les cibles de KPI à atteindre et les personnes responsables de leur mise en œuvre. Vous pouvez classifier un rapport en fonction des SBO auxquels il contribue, comme la réduction de la fraude, l’amélioration de l’engagement des clients et l’optimisation des opérations commerciales. Ensuite, vous pouvez prioriser les rapports et tableaux de bord associés à des objectifs prioritaires pour la migration. De cette façon, la migration initiale peut offrir 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 comme opérationnels, tactiques ou stratégiques pour identifier le niveau métier auquel ils appartiennent. Les SBO nécessitent des contributions à tous ces niveaux. Le fait de savoir quels sont les rapports et tableaux de bord utilisés, à quel niveau et à quels objectifs ils sont associés permet de concentrer la migration initiale sur la valeur métier prioritaire. Vous pouvez utiliser le tableau d’objectifs de stratégie métier suivant pour évaluer les rapports et les tableaux de bord.

Level	Nom du rapport/tableau de bord	Objectif de l’entreprise	Service utilisé	Fréquence d’utilisation	Priorité de l’entreprise
Stratégique
Tactique
En fonctionnement

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

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

Si votre stratégie de migration est basée sur la migration des datamarts en premier, l’ordre de migration des datamarts aura une incidence sur l’ordre de migration des rapports et des tableaux de bord. Si votre stratégie est basée sur la valeur métier, l’ordre dans lequel vous migrez les datamarts vers Azure Synapse va refléter les priorités métier. Les outils de découverte de métadonnées peuvent vous aider à implémenter votre stratégie en montrant les tables datamart qui fournissent des données pour quels rapports.

Conseil

La stratégie de migration de vos données peut également déterminer quels sont les rapports et les visualisations qui sont migrés en premier.

Problèmes d’incompatibilité de migration qui peuvent avoir un effet sur les rapports et les visualisations

Les outils décisionnels génèrent des rapports, des tableaux de bord et d’autres visualisations en envoyant des requêtes SQL qui accèdent à des tables et/ou des vues physiques dans votre entrepôt de données ou votre datamart. 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. Exemples de facteurs :

• 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 les tables de l’entrepôt de données ou des datamarts qui fournissent des données pour les rapports, les tableaux de bord et d’autres visualisations peuvent être :

• Types de table non standard dans votre SGBD d’entrepôt de données hérité qui n’ont pas d’équivalent dans Azure Synapse.

• Types de données dans votre SGBD d’entrepôt de données hérité, 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 vers une table standard avec des types de données appropriés et indexés ou partitionnés sur une colonne Date/Heure. De même, il pourrait ê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

Les incompatibilités de schéma incluent les types de tables de SGBD de l’entrepôt hérité et les types de données non pris en charge sur Azure Synapse.

Pour identifier les rapports impactés par les incompatibilités de schéma, exécutez des requêtes sur le catalogue système de votre entrepôt de données hérité afin d’identifier les tables dont les types de données ne sont pas pris en charge. Vous pouvez ensuite utiliser les métadonnées de votre outil du décisionnel pour identifier les rapports qui accèdent aux données de ces tables. Pour plus d’informations sur l’identification des incompatibilités de types d’objet, consultez Types d’objet de base de données Oracle non pris en charge.

Conseil

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

L’impact des incompatibilités de schéma sur les rapports, les tableaux de bord et d’autres visualisations peut être moindre que ce que vous pensiez, 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é peut déjà avoir des vues qui 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 n’importe quel rapport, tableau de bord ou autre visualisation dans une application ou un outil qui :

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

• Émet des requêtes SQL, qui incluent des fonctions SQL propriétaires propres au dialecte SQL de votre environnement hérité, et 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 appuyez pas sur 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 les incompatibilités SQL

Vous pouvez trouver des incompatibilités SQL en passant en revue les journaux des activités 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. Ajoutez ensuite une instruction SQL avec une instruction EXPLAIN, puis exécutez ces instructions EXPLAIN dans Azure Synapse. Toutes les instructions SQL contenant des extensions SQL propriétaires non prises en charge seront rejetées par Azure Synapse quand les instructions EXPLAIN seront 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 des vues incompatibles. Comme précédemment, capturez un ensemble représentatif d’instructions SQL à partir des journaux concernés, préfixez chaque instruction SQL avec une instruction EXPLAIN et exécutez ces instructions EXPLAIN dans Azure Synapse pour identifier les vues incompatibles avec SQL.

Conseil

Évaluez l’impact des incompatibilités SQL en récupérant les fichiers journaux de votre SGBD et en exécutant des instructions EXPLAIN.

Tester la migration des rapports et tableaux de bord vers Azure Synapse Analytics

Le test des rapports et des tableaux de bord sur Azure Synapse pour vérifier le bon fonctionnement de la migration est un élément clé de la migration d’un entrepôt de données. Définissez une série de tests et un ensemble de résultats obligatoires pour chaque test à exécuter afin d’en vérifier la réussite. Testez et comparez les rapports et les tableaux de bord dans vos systèmes d’entrepôt de données existants et migrés pour :

• Identifier si les modifications de schéma qui ont été apportées lors de la migration ont affecté la capacité des rapports à exécuter, à signaler des résultats ou les visualisations de rapport correspondantes. Un exemple de modification de schéma est le mappage d’un type de données incompatible à un type de données équivalent qui est pris en charge dans Azure Synapse.

• Vérifier que tous les utilisateurs ont été migrés.

• Vérifier que tous les rôles ont été migrés, et que les utilisateurs ont été attribués à ces rôles.

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

• Vérifier la cohérence des résultats pour l’ensemble des requêtes, rapports et tableaux de bord connus.

• Vérifier que la migration des données et la migration ETL (extraction, transformation et chargement) se sont effectuées en totalité et sans erreur.

• Vérifier que la confidentialité des données est respectée.

• Performances de test et scalabilité.

• Fonctionnalité analytique des tests.

Conseil

Testez les performances, puis affinez-les pour réduire les coûts de calcul.

Pour plus d’informations sur la migration des utilisateurs, des groupes d’utilisateurs, des rôles et des 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 permettre une approche cohérente de l’évaluation des résultats des tests. L’automatisation fonctionne bien pour les rapports classiques connus et peut être gérée via l’orchestration des pipelines Azure Synapse ou d’Azure Data Factory. Si vous avez déjà 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 postmigration.

Conseil

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 pré- et post-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

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

Analyser la traçabilité pour comprendre les dépendances entre les rapports, les tableaux de bord et les données

Votre compréhension de la traçabilité est un facteur essentiel dans la réussite de la migration des rapports et des tableaux de bord. La traçabilité est une métadonnée qui montre le parcours des données migrées afin de pouvoir suivre son tracé à partir d’un rapport ou d’un tableau de bord jusqu’à la source de données. La traçabilité montre comment les données sont passées d’un point à l’autre, son emplacement dans l’entrepôt de données et/ou le datamart, ainsi que les rapports et les tableaux de bord qui l’utilisent. La traçabilité vous aide à comprendre ce qui arrive aux données quand elles circulent dans les différents magasins de données (fichiers et bases de données) et les différents pipelines ETL pour arriver jusqu’aux rapports. Si les utilisateurs métier ont accès à la traçabilité des données, cela améliore la confiance et permet de prendre des décisions métier plus éclairées.

Conseil

Votre capacité à accéder aux métadonnées et à la traçabilité des données des rapports jusqu’à la 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 multifournisseurs, les analystes métier des équipes du décisionnel peuvent mapper la traçabilité des données. Par exemple, si vous utilisez différents fournisseurs pour ETL, l’entrepôt de données et la création de rapports, et que chacun a son propre référentiel de métadonnées, il peut être difficile et fastidieux de déterminer la provenance d’un élément de données spécifique dans un rapport.

Conseil

Les outils qui automatisent la collecte de métadonnées et montrent la traçabilité de bout en bout dans un environnement multifournisseur sont précieux pendant une migration.

Pour migrer de manière transparente 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 la fiabilité de la migration au moment de comparer les rapports et les 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 à des outils qui prennent en charge la découverte des métadonnées et la traçabilité des données vous permet d’identifier les rapports ainsi que les processus ETL en double et de trouver les rapports qui reposent sur des sources de données obsolètes, discutables ou même inexistantes. Grâce à ces informations, vous pouvez réduire le nombre de rapports et de processus ETL à migrer.

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 voir si des différences se sont produites par inadvertance durant la migration. Ce type de comparaison est particulièrement utile lorsque vous devez tester et vérifier que la migration a réussi.

La visualisation de la traçabilité des données réduit non seulement le temps, les efforts et les erreurs dans le processus de migration, mais elle permet également d’effectuer plus rapidement la migration.

En utilisant des outils automatisés de découverte de métadonnées et de traçabilité des données qui comparent la traçabilité, vous pouvez vérifier si un rapport est produit à l’aide de données migrées vers Azure Synapse, et s’il est produit de la même manière que dans votre environnement hérité. Cette fonctionnalité vous permet également de déterminer :

• Quelles sont les données à migrer pour garantir une exécution réussie des rapports et des tableaux de bord dans Azure Synapse.

• Quelles transformations ont été et doivent être effectuées pour garantir une exécution réussie 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 en charge la possibilité d’afficher la traçabilité dans les flux de mappage. Les partenaires Microsoft fournissent également des outils automatisés de découverte des métadonnées, de traçabilité des données et de comparaison de la traçabilité.

Migrer des couches sémantiques d’outils décisionnels 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 de la base de données d’un entrepôt de données ou d’un 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. Ces objets de haut niveau utilisent des termes métier familiers aux analystes métier et se mappent aux structures de données physiques dans votre entrepôt de données ou datamart.

Conseil

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

Dans une migration d’entrepôt de données, vous pouvez être obligé de changer les noms de colonnes ou de tables. Par exemple, Oracle accepte le caractère # dans les noms de tables, mais Azure Synapse autorise uniquement # en tant que préfixe de nom de table pour indiquer une table temporaire. Dans Oracle, les tables TEMPORARY n’ont pas nécessairement un « # » dans le nom, mais dans Synapse, cela est obligatoirement le cas. Ainsi, vous devrez peut-être changer les mappages de tables.

Pour assurer la 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 des objets de haut niveau tels que des dimensions, des mesures, des hiérarchies et des 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 le faire dans chaque outil. Ensuite, pointez tous les outils décisionnels sur le serveur de virtualisation des données.

Conseil

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.

La virtualisation de données vous permet d’obtenir une cohérence entre tous les outils décisionnels et de rompre la dépendance entre les outils et les applications décisionnels ainsi que 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 sur le serveur de virtualisation de données permet à plusieurs outils du décisionnel de voir une couche sémantique commune.

Conclusions

Dans une migration d’entrepôt de données lift-and-shift, la plupart des rapports, des tableaux de bord et d’autres visualisations doivent migrer facilement.

Lors d’une migration à partir d’un environnement hérité, vous pouvez constater que les données de l’entrepôt de données hérité ou des tables de datamart 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 héritées qui incluent SQL propriétaire sans équivalent dans Azure Synapse. Dans ce 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 des instructions EXPLAIN, car elles constituent un moyen rapide et pragmatique d’identifier les incompatibilités SQL. Retravailler 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 reposent sur des sources de données obsolètes, douteuses ou inexistantes. Utilisez des outils de traçabilité pour comparer la traçabilité afin de vérifier que les rapports s’exécutant dans votre environnement d’entrepôt de données hérité sont produits à l’identique dans Azure Synapse.

Ne migrez pas les rapports que vous n’utilisez plus. Les données d’utilisation des outils décisionnels permettent de déterminer les rapports qui ne sont pas utilisés. Pour les rapports, tableaux de bord et autres visualisations que vous souhaitez migrer, migrez 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 à des objectifs métier stratégiques et des priorités pour vous aider à identifier la contribution des insights sur les rapports à des objectifs spécifiques. Si vous migrez datamart par datamart, utilisez des métadonnées pour identifier les rapports qui dépendent des tables et vues, afin de prendre une décision éclairée sur les datamarts à migrer en premier.

Conseil

Identifiez les incompatibilités précoces pour évaluer l’étendue 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 contribuant à 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 datamart 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 communs dans tous les outils et applications décisionnels dans le nouvel environnement Azure Synapse.

Étapes suivantes

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