Conception et performances pour les migrations Netezza

Cet article est la première partie d’une série de sept parties qui fournit des conseils sur la migration de Netezza vers Azure Synapse Analytics. Cet article est consacré aux meilleures pratiques pour la conception et les performances.

Vue d’ensemble

Compte tenu de la fin du support d’IBM, de nombreux utilisateurs existants des systèmes d’entrepôt de données Netezza souhaitent tirer parti des innovations qu’offrent les environnements cloud modernes. Les environnements cloud IaaS (Infrastructure as a Service) et PaaS (Platform-as-a-Service) vous permettent de déléguer des tâches telles que la maintenance de l’infrastructure et le développement de plateforme au fournisseur cloud.

Conseil

Plus qu’une base de données, l’environnement Azure inclut un ensemble complet de fonctionnalités et d’outils.

Netezza et Azure Synapse Analytics sont dans les deux cas des bases de données SQL conçues pour utiliser des techniques de traitement massivement parallèle (MPP, Massively Parallel Processing), lesquelles permettent d’obtenir des performances de requête élevées sur d’énormes volumes de données. Il y a toutefois quelques différences d’approche fondamentales entre les deux :

• Les systèmes Netezza hérités sont souvent installés localement et utilisent du matériel propriétaire, tandis qu’Azure Synapse est basé sur le cloud et utilise les ressources de stockage et de calcul d’Azure.

• La mise à niveau d’une configuration Netezza constitue une tâche majeure impliquant du matériel physique supplémentaire et une reconfiguration potentiellement laborieuse de la base de données, ou un vidage et un rechargement. Étant donné que les ressources de stockage et de calcul sont séparées dans l’environnement Azure et qu’elles disposent d’une capacité de mise à l’échelle, il est facile de les mettre à l’échelle vers le haut et vers le bas.

• Vous pouvez suspendre ou redimensionner Azure Synapse en fonction des besoins afin de réduire la consommation des ressources et par là-même, le coût.

Microsoft Azure est un environnement cloud disponible dans le monde entier, hautement sécurisé et scalable, qui comprend Azure Synapse et un écosystème d’outils et de capacités qui le complètent. Le diagramme suivant récapitule l’écosystème Azure Synapse.

Azure Synapse offre d’excellentes performances de bases de données relationnelles en utilisant des techniques telles que le traitement MPP et plusieurs niveaux de mise en cache automatisée pour les données fréquemment utilisées. Vous pouvez constater les résultats de ces techniques dans des benchmarks indépendants, comme celui récemment réalisé par GigaOm, qui compare Azure Synapse à d’autres offres populaires d’entrepôt de données dans le cloud. Les clients qui migrent vers l’environnement Azure Synapse voient de nombreux avantages, notamment :

• Amélioration des performances et du rapport prix/performance.

• Une plus grande souplesse et un temps de valorisation plus court.

• Déploiement de serveur et d’applications plus rapide.

• Scalabilité élastique : payez uniquement pour l’utilisation réelle.

• Amélioration de la conformité/sécurité.

• Réduction des coûts de stockage et de récupération d’urgence.

• Réduction du coût total de possession, meilleur contrôle des coûts et dépenses opérationnelles (OPEX) simplifiées.

Pour optimiser ces avantages, migrez les données et applications nouvelles ou existantes vers la plateforme Azure Synapse. Dans de nombreuses organisations, la migration comprend la migration d’un entrepôt de données existant à partir d’une plateforme sur site existante telle que Netezza vers Azure Synapse. En général, le processus de migration comprend les étapes suivantes :

    Préparation 🡆

• Définissez l’étendue de ce qui doit être migré.

• Créez un inventaire des données et processus pour la migration.

• Définissez les modifications de modèle de données (le cas échéant).

• Définissez le mécanisme d’extraction de données sources.

• Identifiez les outils et fonctionnalités Azure (et tiers) à utiliser.

• Formez le personnel à un stade précoce sur la nouvelle plateforme.

• Configurez la plateforme cible Azure.

    Migration 🡆

• Commencez par une migration simple et à petite échelle.

• Automatisez autant que possible.

• Utilisez les outils et fonctionnalités Azure intégrés pour réduire l’effort de migration.

• Migrez les métadonnées des tables et des vues.

• Migrez les données historique à conserver.

• Migrez ou refactorisez les procédures stockées et les processus métier.

• Migrer ou refactoriser les processus de charge incrémentielle ETL/ELT

    Tâches de post-migration

• Surveillez et documenter toutes les étapes du processus.

• Servez-vous de l’expérience acquise pour créer un modèle en vue de futures migrations.

• Remaniez le modèle de données si nécessaire, en exploitant les performances et la scalabilité de la nouvelle plateforme.

• Testez les applications et les outils de requête.

• Évaluez et optimisez les performances des requêtes.

Cet article fournit des informations générales et des instructions relatives à l’optimisation des performances lors de la migration d’un entrepôt de données d’un environnement Netezza existant vers Azure Synapse. L’objectif de l’optimisation des performances est d’obtenir les mêmes performances d’entrepôt de données dans Azure Synapse après la migration du schéma.

Remarques relatives à la conception

Étendue de la migration

Quand vous préparez la migration à partir d’un environnement Netezza, tenez compte des choix de migration suivants.

Choisir la charge de travail pour la migration initiale

Généralement, les environnements Netezza hérités ont évolué au fil du temps pour englober plusieurs domaines thématiques et charges de travail mixtes. Quand vous décidez de commencer un projet de migration, choisissez un domaine qui pourra :

• Prouver la viabilité de la migration vers Azure Synapse en tirant rapidement parti des avantages du nouvel environnement.

• Permettre à votre personnel technique interne d’acquérir une expérience adaptée aux processus et aux outils qu’il utilisera lors de la migration d’autres domaines.

• Créer un modèle pour d’autres migrations propre à l’environnement Netezza source et aux outils et processus déjà en place.

Un bon candidat pour une migration initiale à partir d’un environnement Netezza prend en charge les éléments précédents et :

• Implémente une charge de travail BI/Analytics plutôt qu’une charge de travail OLTP (Online Transaction Processing).

• Possède un modèle de données, par exemple un schéma en étoile ou en flocons qui peut être migré avec un minimum de modifications.

Conseil

Créez un inventaire des objets à migrer et documentez le processus de migration.

Le volume de données migrées dans la migration initiale doit être suffisamment important pour illustrer les fonctionnalités et les avantages de l’environnement Azure Synapse, mais pas trop volumineux pour illustrer rapidement la valeur. La valeur typique se situe dans la plage de 1 à 10 téraoctets.

Pour votre projet de migration initial, réduisez le risque, l’effort et le temps de migration afin de pouvoir rapidement voir les avantages de l’environnement cloud Azure. Les approches de migration progressive et lift-and-shift limitent l’étendue de la migration initiale aux magasins de données et ne traitent pas des aspects de migration plus larges tels que la migration ETL et la migration des données historiques. Toutefois, vous pouvez traiter ces aspects dans les phases ultérieures du projet une fois que la couche de magasin de données migrée est répliquée avec les données et les processus de génération requis.

Migration lift-and-shift et approche par phase

En règle générale, il existe deux types de migration, quel que soit l’objectif et l’étendue de la migration planifiée : le lift-and-shift en l’état et une approche par phases qui incorpore les modifications.

Migration lift-and-shift

Dans la migration lift-and-shift, le modèle de données existant, par exemple le schéma en étoile, est migré sans modifications vers la nouvelle plateforme Azure Synapse. Cette approche réduit les risques et la durée de la migration en diminuant le travail nécessaire pour profiter pleinement des avantages du passage à l’environnement cloud Azure. La migration lift-and-shift est adaptée à ces scénarios :

• Vous disposez d’un environnement Netezza existant avec un seul magasin de données à migrer ou
• Vous disposez d’un environnement Netezza existant avec des données qui se trouvent déjà dans un schéma en étoile ou en flocon bien conçu, ou
• Vous êtes sous pression, du point de vue de la planification, mais aussi du point de vue financier, pour passer à un environnement cloud moderne.

Conseil

La migration lift-and-shift est un bon point de départ, même si les phases suivantes implémentent des modifications apportées au modèle de données.

Approche par phases qui incorpore les modifications

Si un entrepôt de données hérité a évolué sur une longue période, vous devrez peut-être le reconcevoir pour maintenir les niveaux de performances requis. Vous devrez peut-être également le retravailler pour prendre en charge de nouvelles données telles que celles de l’Internet des objets (IoT). Dans le cadre du processus de retravail, migrez vers Azure Synapse pour profiter des avantages d’un environnement cloud scalable. La migration peut aussi inclure un changement dans le modèle de données sous-jacent, par exemple un déplacement d’un modèle Inmon vers un coffre de données.

Microsoft recommande de déplacer le modèle de données existant tel quel vers Azure et d’exploiter les performances et la flexibilité de l’environnement Azure pour appliquer les modifications de réingénierie. De cette façon, vous bénéficiez des fonctionnalités d’Azure pour apporter les modifications sans affecter le système source existant.

Implémentation d’une migration pilotée par les métadonnées avec Azure Data Factory

Vous pouvez automatiser et orchestrer le processus de migration en utilisant les fonctionnalités de l’environnement Azure. Cette approche permet de réduire l’impact sur les performances dans l’environnement Netezza existant, qui est peut-être déjà près de sa pleine capacité.

Azure Data Factory est un service d’intégration de données basé sur le cloud qui vous permet de créer des flux de travail orientés données dans le cloud pour orchestrer et automatiser le déplacement des données et la transformation des données. Vous pouvez utiliser Azure Data Factory pour créer et planifier des workflows pilotés par les données (les pipelines) qui ingèrent des données provenant de différents magasins de données. Data Factory peut traiter et transformer les données à l’aide de services de calcul tels que Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics et Azure Machine Learning.

Lorsque vous envisagez d’utiliser Data Factory pour gérer le processus de migration, créez des métadonnées qui répertorient toutes les tables de données à migrer et leur emplacement.

Différences de conception entre Netezza et Azure Synapse

Comme mentionné précédemment, il existe quelques différences de base dans l’approche entre les bases de données Netezza et Azure Synapse Analytics et ces différences sont abordées ci-dessous.

Plusieurs bases de données ou une seule base de données et des schémas

L’environnement Netezza contient souvent plusieurs bases de données distinctes. Par exemple, il peut y avoir des bases de données distinctes pour : l’ingestion des données et les tables intermédiaires, les tables d’entrepôt de base et les magasins de données (parfois appelés couche sémantique). Les processus de pipeline ETL ou ELT peuvent implémenter des jointures entre bases de données et déplacer des données entre les différentes bases de données.

Par contre, l’environnement Azure Synapse contient une seule base de données et utilise des schémas pour séparer les tables en groupes séparés logiquement. Nous vous recommandons d’utiliser une série de schémas dans la base de données Azure Synapse cible pour imiter toutes les bases de données séparées qui sont migrées à partir de l’environnement Netezza. Si l’environnement Netezza utilise déjà des schémas, il se peut que vous deviez employer une nouvelle convention d’affectation de noms pour déplacer les tables et vues Netezza existantes vers le nouvel environnement. Par exemple, vous pouvez concaténer le noms de table et de schéma Netezza existants dans le nouveau nom de table Azure Synapse, puis utiliser les noms de schéma dans le nouvel environnement pour conserver les noms initiaux des bases de données séparées. Si le nommage de consolidation de schéma comporte des points, Azure Synapse Spark peut rencontrer des problèmes. Bien que vous puissiez utiliser des vues SQL sur les tables sous-jacentes pour maintenir les structures logiques, cette approche présente certains inconvénients :

• Les vues dans Azure Synapse étant en lecture seule, toutes les mises à jour des données doivent avoir lieu sur les tables de base sous-jacentes.

• S’il y a déjà une ou plusieurs couches de vues, l’ajout d’une couche supplémentaire de vues peut affecter les performances et la prise en charge, car les problèmes de vues imbriquées sont difficiles à résoudre.

Conseil

Combinez plusieurs bases de données en une seule dans Azure Synapse et utilisez des noms de schémas pour créer une séparation logique des tables.

Considérations relatives aux tables

Lorsque vous migrez des tables entre différents environnements, seules les données brutes et les métadonnées qui les décrivent physiquement sont migrées. Les autres éléments de base de données du système source, tels que les index, ne sont généralement pas migrés, car ils peuvent être inutiles ou implémentés différemment dans le nouvel environnement.

Les optimisations des performances dans l’environnement source, telles que les index, indiquent où vous pouvez ajouter l’optimisation des performances dans le nouvel environnement. Par exemple, si des requêtes dans l’environnement Netezza source utilisent fréquemment des mappages de zone, cela suggère qu’un index hors cluster doit être créé dans Azure Synapse. D’autres techniques d’optimisation des performances natives, telles que la réplication de table, peuvent être plus applicables qu’une création d’index « like for like ».

Conseil

Les index existants marquent les candidats à l’indexation dans l’entrepôt migré.

Types d’objets de base de données Netezza non pris en charge

Les fonctionnalités propres à Netezza peuvent souvent être remplacées par des fonctionnalités Azure Synapse. Toutefois, certains objets de base de données Netezza ne sont pas directement pris en charge dans Azure Synapse. La liste suivante d’objets de base de données Netezza non pris en charge explique comment obtenir une fonctionnalité équivalente dans Azure Synapse.

• Mappages de zone : dans Netezza, les mappages de zone sont automatiquement créés et gérés pour les types de colonnes suivants, et utilisés au moment de la requête pour limiter la quantité de données à analyser :

  • Colonnes INTEGER d’une longueur de 8 octets maximum.
  • Colonnes temporelles, par exemple, DATE, TIME et TIMESTAMP.
  • Colonnes CHAR si elles font partie d’une vue matérialisée et sont mentionnées dans la clause ORDER BY.

  Vous pouvez déterminer quelles colonnes ont des mappages de zone à l’aide de l’utilitaire nz_zonemap, qui fait partie de la boîte à outils NZ. Azure Synapse n’inclut pas les mappages de zone, mais vous pouvez obtenir des résultats similaires avec d’autres types d’index définis par l’utilisateur et/ou avec le partitionnement.

• Tables de base en cluster : dans Netezza, les tables de base en cluster sont généralement utilisées pour la table de faits, qui peut comporter des milliards d’enregistrements. L’analyse d’une table aussi volumineuse prend un temps considérable, car une analyse complète peut se révéler nécessaire pour obtenir les enregistrements pertinents. L’organisation des enregistrements sur des CBT restrictives permet à Netezza de regrouper les enregistrements dans des partitions identiques ou proches. Ce processus crée également des mappages de zone qui améliorent les performances en réduisant la quantité de données à analyser.

  Dans Azure Synapse, un effet similaire peut être obtenu en partitionnant et/ou en utilisant d’autres index.

• Vues matérialisées : Netezza prend en charge les vues matérialisées et recommande l’utilisation d’une ou plusieurs vues matérialisées pour les grandes tables comportant de nombreuses colonnes si quelques colonnes seulement sont régulièrement utilisées dans les requêtes. Les vues matérialisées sont automatiquement actualisées par le système après la modification de données dans la table de base.

  Azure Synapse prend en charge les vues matérialisées, avec les mêmes fonctionnalités que Netezza.

Mappage de type de données Netezza

la plupart des types de données Netezza ont un équivalent direct dans Azure Synapse. Le tableau suivant montre l’approche recommandée pour mapper les types de données Netezza vers Azure Synapse.

Netezza Data Type	Type de données Azure Synapse
bigint	bigint
BINARY VARYING(n)	VARBINARY(n)
BOOLEAN	BIT
BYTEINT	TINYINT
CHARACTER VARYING(n)	VARCHAR(n)
CHARACTER(n)	CHAR(n)
DATE	DATE(date)
DECIMAL(p,s)	DECIMAL(p,s)
DOUBLE PRECISION	FLOAT
FLOAT(n)	FLOAT(n)
INTEGER	INT
INTERVAL	Les types de données INTERVAL ne sont pas pris en charge directement dans Azure Synapse, mais peuvent être calculés à l’aide de fonctions temporelles comme DATEDIFF
MONEY	MONEY
NATIONAL CHARACTER VARYING(n)	NVARCHAR(n)
NATIONAL CHARACTER(n)	NCHAR(n)
NUMERIC(p,s)	NUMERIC(p,s)
real	RÉEL
SMALLINT	SMALLINT
ST_GEOMETRY(n)	Les types de données spatiales comme ST_GEOMETRY ne sont pas pris en charge actuellement dans Azure Synapse, mais les données peuvent être stockées en tant que VARCHAR ou VARBINARY.
TEMPS	TEMPS
TIME WITH TIME ZONE	DATETIMEOFFSET
timestamp	DATETIME

Conseil

Évaluez le nombre et le type de types de données non pris en charge pendant la phase de préparation de la migration.

Des fournisseurs tiers proposent des outils et services permettant d’automatiser la migration, dont le mappage de type de données. Si un outil ETL tiers est déjà utilisé dans l’environnement Netezza, utilisez cet outil pour implémenter toutes les transformations de données requises.

Différences de syntaxe SQL DML

Il existe des différences de syntaxe SQL DML entre Netezza SQL et Azure Synapse T-SQL. Ces différences sont abordées en détail dans Réduction des problèmes SQL pour les migrations Netezza.

• STRPOS : dans Netezza, la fonction STRPOS retourne la position d’une sous-chaîne à l’intérieur d’une chaîne. La fonction équivalente dans Azure Synapse est CHARINDEX avec l’ordre des arguments inversé. Par exemple, SELECT STRPOS('abcdef','def')... dans Netezza équivaut à SELECT CHARINDEX('def','abcdef')... dans Azure Synapse.

• AGE : Netezza prend en charge l’opérateur AGE pour donner l’intervalle entre deux valeurs temporelles, comme des horodatages ou des dates, par exemple : SELECT AGE('23-03-1956','01-01-2019') FROM.... Dans Azure Synapse, utilisez DATEDIFF pour obtenir l’intervalle, par exemple : SELECT DATEDIFF(day, '1956-03-26','2019-01-01') FROM.... Notez la séquence de représentation de date.

• NOW(): Netezza utilise NOW() pour représenter CURRENT_TIMESTAMP dans Azure Synapse.

Fonctions, procédures stockées et séquences

Quand vous migrez un entrepôt de données à partir d’un environnement hérité mature comme Netezza, vous devez la plupart du temps migrer d’autres éléments que des tables et vues simples. Vérifiez si les outils dans l’environnement Azure peuvent remplacer les fonctionnalités des fonctions, des procédures stockées et des séquences, car il est généralement plus efficace d’utiliser des outils Azure intégrés que de recoder ces éléments pour Azure Synapse.

Dans le cadre de votre phase de préparation, créez un inventaire des objets qui doivent être migrés, définissez une méthode pour les gérer et allouez les ressources appropriées dans votre plan de migration.

Les partenaire d’intégration de données proposent des outils et des services qui automatisent la migration des fonctions, des procédures stockées et des séquences.

Les sections suivantes décrivent plus en détail la migration des fonctions, des procédures stockées et des séquences.

Fonctions

Comme la plupart des produits de base de données, Netezza prend en charge les fonctions système et les fonctions définies par l’utilisateur dans l’implémentation SQL. Lorsque vous migrez une plateforme de base de données héritée vers Azure Synapse, les fonctions système courantes peuvent généralement être migrées sans modification. D’autres présentent une syntaxe légèrement différente, mais les modifications requises sont automatisables.

Pour les fonctions système Netezza ou les fonctions arbitraires définies par l’utilisateur qui n’ont pas d’équivalent dans Azure Synapse, recodez ces fonctions avec un langage d’environnement cible. Les fonctions définies par l’utilisateur dans Netezza sont codées avec le langage nzLua ou C++. Azure Synapse utilise le langage Transact-SQL pour implémenter les fonctions définies par l’utilisateur.

Procédures stockées

La plupart des produits de base de données modernes offrent la possibilité de stocker des procédures. Netezza fournit le langage NZPLSQL, basé sur Postgres PL/pgSQL, à cette fin. Une procédure stockée contient généralement les instructions SQL et la logique procédurale et peut retourner des données ou un état.

Azure Synapse prend en charge les procédures stockées à l’aide de T-SQL. Vous devez donc recoder toutes les procédures stockées migrées dans ce langage.

Séquences

Dans Netezza, une séquence est un objet de base de données nommé créé avec CREATE SEQUENCE. Une séquence fournit des valeurs numériques uniques via la méthode NEXT VALUE FOR. Vous pouvez utiliser les nombres uniques générés en tant que valeurs de clé de substitution pour les clés primaires.

Azure Synapse n’implémente pas CREATE SEQUENCE, mais vous pouvez implémenter des séquences avec des colonnes IDENTITY ou du code SQL qui génère le numéro de séquence suivant dans une série.

Extraction de métadonnées et de données à partir d’un environnement Netezza

Génération de langage de définition de données (Data Definition Language, DDL)

La norme ANSI SQL définit la syntaxe de base pour les commandes DDL (Data Definition Language). Certaines commandes DDL, telles que CREATE TABLE et CREATE VIEW, sont communes à Netezza et Azure Synapse, mais ont été étendues pour fournir des fonctionnalités spécifiques à l’implémentation.

Vous pouvez modifier les scripts Netezza CREATE TABLE et CREATE VIEW existants pour obtenir les mêmes définitions dans Azure Synapse. Pour ce faire, vous devrez peut-être utiliser des types de données modifiés et supprimer ou modifier des clauses spécifiques à Netezza, telles que ORGANIZE ON.

Dans l’environnement Netezza, les tables de catalogue système spécifient la définition actuelle de la table et de la vue. Contrairement à la documentation gérée par l’utilisateur, les informations du catalogue système sont toujours complètes et synchronisées avec les définitions de table actuelles. En recourant à des utilitaires comme nz_ddl_table, vous pouvez accéder aux informations du catalogue système pour générer des instructions DDL CREATE TABLE qui créent des tables équivalentes dans Azure Synapse.

Vous pouvez également utiliser des outils de migration tiers et des outils ETL qui traitent les informations du catalogue système pour obtenir des résultats similaires.

Extraction de données à partir de Netezza

Vous pouvez extraire des données de table brutes de tables Netezza vers des fichiers délimités plats, tels que des fichiers CSV, avec des utilitaires Netezza standard tels que nzsql et nzunload, ou par le biais de tables externes. Ensuite, vous pouvez compresser les fichiers délimités plats avec gzip et charger les fichiers compressés sur Stockage Blob Azure avec AzCopy ou des outils de transport de données Azure comme Azure Data Box.

Extrayez les données des tables aussi efficacement que possible. Utilisez l’approche des tables externes, car il s’agit de la méthode d’extraction la plus rapide. Effectuez plusieurs extractions de données en parallèle afin d’optimiser le débit. L’instruction SQL suivante effectue une extraction par le biais d’une table externe :

CREATE EXTERNAL TABLE '/tmp/export_tab1.csv' USING (DELIM ',') AS SELECT * from <TABLENAME>;

Si une bande passante réseau suffisante est disponible, vous pouvez extraire les données d’un système Netezza local directement dans des tables Azure Synapse ou dans le stockage de données d’objet blob Azure. Pour ce faire, utilisez des processus Data Factory ou des produits de migration de données ou ETL tiers.

Conseil

Utilisez des tables externes Netezza pour effectuer l’extraction de données la plus efficace.

Les fichiers de données extraits doivent contenir du texte délimité au format CSV, ORC (Optimized Row Columnar) ou Parquet.

Pour plus d’informations sur la migration des données et l’extraction, la transformation et le chargement à partir d’un environnement Netezza, consultez Migration des données, extraction, transformation et chargement pour les migrations Netezza.

Recommandations en matière de performances pour les migrations Netezza

L’objectif de l’optimisation des performances est de même ou de meilleures performances d’entrepôt de données après la migration vers Azure Synapse.

Similitudes dans les concepts de l’approche du réglage des performances

De nombreux concepts de réglage des performances pour les bases de données Netezza sont vrais pour les bases de données Azure Synapse. Par exemple :

• Recourir à la distribution des données pour colocaliser les données à joindre sur le même nœud de traitement

• Utiliser le plus petit type de données pour une colonne donnée afin d’économiser l’espace de stockage et d’accélérer le traitement des requêtes

• Faire en sorte que les colonnes à joindre ont le même type de données afin d’optimiser le traitement des jointures et de réduire le besoin de transformations de données

• Pour que l’optimiseur puisse produire le meilleur plan d’exécution possible, s’assurer que les statistiques sont à jour

• Monitorer les performances avec des fonctionnalités de base de données intégrées pour s’assurer que les ressources sont utilisées efficacement

Conseil

Hiérarchisez les options de paramétrage dans Azure Synapse au début d’une migration.

Différences dans l’approche du réglage des performances

Cette section détaille les différences d’implémentation du réglage du niveau de performance entre Netezza et Azure Synapse.

Options de distribution de données

Pour les performances, Azure Synapse a été conçu avec une architecture à plusieurs nœuds et utilise un traitement parallèle. Pour optimiser les performances des tables, vous pouvez définir une option de distribution de données dans les instructions CREATE TABLE en utilisant DISTRIBUTION dans Azure Synapse et DISTRIBUTE ON dans Netezza.

Contrairement à Netezza, Azure Synapse prend en charge les jointures locales entre une petite table et une grande table via la réplication de la petite table. Par exemple, prenons une petite table de dimension et une table de faits volumineuse dans un modèle de schéma en étoile. Azure Synapse pouvez répliquer la plus petite table de dimension sur tous les nœuds pour garantir que la valeur de n’importe quelle clé de jointure pour la table volumineuse a une ligne de dimension correspondante disponible localement. La surcharge de la réplication de table de dimension est relativement faible pour une petite table de dimension. Pour les tables de dimensions volumineuses, l’approche par distribution de hachage est plus appropriée. Pour plus d’informations sur les options de distribution de données, consultez Conseils de conception pour l’utilisation de tables répliquées et Conseils sur la conception de tables distribuées.

Indexation des données

Azure Synapse prend en charge plusieurs options d’indexation définissables par l’utilisateur qui ont un fonctionnement et une utilisation différents par rapport aux mappages de zone gérés par le système dans Netezza. Pour plus d’informations sur les différentes options d’indexation dans Azure Synapse, consultez Index sur les tables de pool SQL dédiées.

Les mappages de zone gérés par le système existants dans un environnement Netezza source peuvent fournir des indications utiles sur la façon dont les données sont utilisées et sur les colonnes candidates à l’indexation dans l’environnement Azure Synapse.

Partitionnement des données

Dans un entrepôt de données d’entreprise, les tables de faits peuvent contenir des milliards de lignes. Le partitionnement constitue un moyen d’optimiser la maintenance et les performances d’interrogation de ces tables en les fractionnant en parties séparées afin de réduire la quantité de données traitées. Dans Azure Synapse, l’instruction CREATE TABLE définit la spécification du partitionnement d’une table.

Vous ne pouvez utiliser qu’un seul champ par table pour le partitionnement. Ce champ est souvent un champ de date, car de nombreuses requêtes sont filtrées par date ou plage de dates. Vous avez la possibilité de changer le partitionnement d’une table après le chargement initial en recréant la table avec la nouvelle distribution. Pour cela, vous utilisez l’instruction CREATE TABLE AS (ou CTAS). Pour une présentation détaillée du partitionnement dans Azure Synapse, consultez Partitionnement de tables dans un pool SQL dédié.

Statistiques de table de données

Assurez-vous que les statistiques sur les tables de données sont à jour en créant une étape statistiques pour les travaux ETL/ELT.

PolyBase ou COPY INTO pour le chargement des données

PolyBase prend en charge le chargement efficace de grandes quantités de données dans un entrepôt de données à l’aide de flux de chargement parallèles. Pour plus d’informations, consultez Stratégie de chargement des données PolyBase.

COPY INTO prend également en charge l’ingestion de données à haut débit et les opérations suivantes :

• Extraction de données à partir de tous les fichiers dans un dossier et ses sous-dossiers.

• Extraction de données à partir de plusieurs emplacements dans le même compte de stockage. Vous pouvez spécifier plusieurs emplacements à l’aide de chemins séparés par des virgules.

• Azure Data Lake Storage (ADLS) et Stockage Blob Azure.

• Formats de fichier CSV, PARQUET et ORC.

Gestion des charges de travail

L’exécution de charges de travail mixtes peut poser des problèmes de ressources sur les systèmes chargés. Un schéma de gestion des charges de travail réussi gère efficacement les ressources, garantit une utilisation hautement efficace des ressources et optimise le retour sur investissement (ROI). La classification de la charge de travail, l’importance de la charge de travail et l’isolation de la charge de travail donnent plus de contrôle sur la façon dont la charge de travail utilise les ressources système.

Le guide de gestion des charges de travail décrit les techniques permettant d’analyser la charge de travail, de gérer et de superviser l’importance de la charge de travail ainsi que les étapes de conversion d’une classe de ressources en groupe de charge de travail. Utilisez le Portail Azure et les requêtes T-SQL sur les DMV pour surveiller la charge de travail pour vous assurer que les ressources applicables sont utilisées efficacement.

Étapes suivantes

Pour découvrir ETL et le chargement pour la migration de Netezza, consultez l’article suivant de cette série : Migration des données, ETL et chargement pour les migrations de Netezza.