Share via

Réduire les problèmes de SQL pour les migrations Netezza

  • Article

Cet article est la cinquième partie d’une série de sept parties qui fournit des conseils sur la migration de Netezza vers Azure Synapse Analytics. L’objectif de cet article est de fournir les meilleures pratiques pour réduire les problèmes de SQL.

Vue d’ensemble

Caractéristiques des environnements Netezza

Conseil

Netezza a lancé le concept d’« appliance d’entrepôt de données » au début des années 2000.

En 2003, Netezza a initialement publié son produit d’appliance d’entrepôt de données. Cela a réduit le coût d’entrée et amélioré la facilité d’utilisation des techniques de traitement massivement parallèle (MPP) pour permettre le traitement des données à grande échelle plus efficacement que le mainframe existant ou les autres technologies de MPP disponibles à l’époque. Depuis lors, le produit a évolué et possède de nombreuses installations parmi les grandes institutions financières, les télécommunications et les entreprises de vente au détail. L’implémentation d’origine utilisait du matériel propriétaire, y compris des field programmable gate arrays (ou FPGA), et était accessible via une connexion réseau ODBC ou JDBC via TCP/IP.

La plupart des installations Netezza existantes sont locales, de nombreux utilisateurs envisagent donc de migrer certaines ou toutes leurs données Netezza vers Azure Synapse Analytics pour bénéficier des avantages d’un déplacement vers un environnement cloud moderne.

Conseil

De nombreuses installations Netezza existantes sont des entrepôts de données employant un modèle de données dimensionnel.

La technologie Netezza est souvent utilisée pour implémenter un entrepôt de données, prenant en charge des requêtes analytiques complexes sur de grands volumes de données à l’aide de SQL. Les modèles de données dimensionnels (schémas en étoile ou flocons de neige) sont courants, comme l’implémentation de datamarts pour des départements individuels.

Cette combinaison de modèles de données SQL et dimensionnels simplifie la migration vers Azure Synapse, car les concepts de base et les compétences SQL sont transférables. L’approche recommandée consiste à migrer le modèle de données existant tel quel pour réduire les risques et le temps nécessaire. Même si l’intention éventuelle consiste à apporter des modifications au modèle de données (par exemple, en passant à un modèle de coffre de données), effectuez une migration initiale en tant que site, puis apportez des modifications dans l’environnement cloud Azure, tirant parti des performances, de l’extensibilité élastique et des avantages des coûts.

Bien que le langage SQL ait été normalisé, les fournisseurs individuels ont dans certains cas implémenté des extensions propriétaires. Ce document met en évidence les différences potentielles SQL que vous pouvez rencontrer lors de la migration à partir d’un environnement Netezza hérité et fournit des solutions de contournement.

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

Conseil

Automatisez le processus de migration à l’aide des fonctionnalités Azure Data Factory.

Automatiser et orchestrer le processus de migration en utilisant les fonctionnalités de l’environnement Azure. Cette approche minimise également l’impact de la migration sur l’environnement Netezza existant, lequel approche peut-être déjà de sa pleine capacité.

Azure Data Factory est un service d’intégration de données basé sur le cloud qui permet de créer des flux de travail pilotés par les données dans le cloud afin d’orchestrer et d’automatiser le déplacement et la transformation des données. Avec Azure Data Factory, vous pouvez créer et planifier des flux de travail axés sur les données (appelés pipelines) qui peuvent ingérer des données provenant de magasins de données disparates. Il 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.

En créant des métadonnées pour répertorier les tables de données à migrer et leur emplacement, vous pouvez utiliser les services de Data Factory pour gérer et automatiser des parties du processus de migration. Vous pouvez également utiliser Azure Synapse Pipelines.

Différences de DDL SQL entre Netezza et Azure Synapse

Langage de définition de données SQL (DDL)

Conseil

Les commandes SQL DDL CREATE TABLE et CREATE VIEW disposent d’éléments principaux standard, mais sont également utilisés pour définir des options spécifiques à l’implémentation.

La norme ANSI SQL définit la syntaxe de base pour les commandes DDL telles que CREATE TABLE et CREATE VIEW. Ces commandes sont utilisées dans Netezza et Azure Synapse, mais elles ont également été étendues pour permettre la définition de fonctionnalités spécifiques à l’implémentation telles que l’indexation, la distribution de tables et les options de partitionnement.

Les sections suivantes décrivent les options spécifiques à Netezza à prendre en compte lors d’une migration vers Azure Synapse.

Considérations relatives aux tables

Conseil

Utilisez des index existants pour donner une indication des candidats à l’indexation dans l’entrepôt migré.

Lors de la migration de tables entre différentes technologies, seules les données brutes et les métadonnées qui les décrivent sont physiquement déplacées entre les deux environnements. Les autres éléments de base de données du système source, tels que les index et les fichiers de journaux, ne sont pas migrés directement, car ils risquent d’être superflus ou implémentés différemment dans le nouvel environnement cible. Par exemple, l’option TEMPORARY dans la syntaxe CREATE TABLE de Netezza équivaut à préfixer le nom de la table avec un caractère « # » dans Azure Synapse.

Il est important de comprendre où les optimisations des performances, telles que les index, ont été utilisées dans l’environnement source. Cela indique où l’optimisation des performances peut être ajoutée dans le nouvel environnement cible. Par exemple, si des mappages de zone ont été créés dans l’environnement Netezza source, cela peut indiquer qu’un index hors cluster doit être créé dans la base de données Azure Synapse migrée. 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 ».

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

Conseil

Les fonctionnalités propres à Netezza peuvent être remplacées par des fonctionnalités Azure Synapse.

Netezza implémente certains objets de base de données qui ne sont pas directement pris en charge dans Azure Synapse, mais il existe des méthodes permettant d’obtenir les mêmes fonctionnalités dans le nouvel environnement :

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

    • Colonnes INTEGER d’une longueur de 8 octets maximum.
    • Colonnes temporelles. Par exemple, DATE, TIME et TIMESTAMP.
    • Colonnes CHAR faisant partie d’une vue matérialisée et 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 beaucoup de temps, car une analyse complète peut se révéler nécessaire pour obtenir les enregistrements pertinents. L’organisation des enregistrements sur CBT restrictif 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 utilisant le partitionnement ou d’autres index.

  • Vues matérialisées : Netezza prend en charge les vues matérialisées et recommande d’en créer une ou plusieurs sur de grandes tables comportant de nombreuses colonnes dont quelques-unes seulement sont régulièrement utilisées dans les requêtes. Les vues matérialisées sont automatiquement mises à jour 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

Conseil

Évaluez l’impact des types de données non pris en charge dans le cadre de la phase de préparation.

la plupart des types de données Netezza ont un équivalent direct dans Azure Synapse. Le tableau suivant présente ces types de données et l’approche recommandée pour leur mappage.

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

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

Conseil

Utilisez les métadonnées Netezza existantes pour automatiser la génération de DDL CREATE TABLE et CREATE VIEW pour Azure Synapse.

Modifiez des scripts Netezza CREATE TABLE et CREATE VIEW existants pour créer les définitions équivalentes avec des types de données modifiés, si nécessaire, comme décrit ci-dessus. En général, cela implique de supprimer ou de modifier toutes les clauses propres à Netezza, par exemple ORGANIZE ON.

Cependant, toutes les informations qui spécifient les définitions actuelles des tables et des vues au sein de l’environnement Netezza existant sont conservées dans les tables du catalogue système. Il s’agit de la meilleure source pour ces informations, car elles sont toujours à jour et complètes. Veillez à ce que la documentation gérée par l’utilisateur ne soit pas synchronisée avec les définitions actuelles des tables.

Accédez à ces informations à l’aide d’utilitaires comme nz_ddl_table et générez les instructions DDL CREATE TABLE. Modifiez ces instructions pour les tables équivalentes dans Azure Synapse.

Conseil

Des outils et services tiers peuvent automatiser des tâches de mappage de données.

Il existe des partenaires Microsoft qui proposent des outils et des services pour automatiser la migration, y compris le mappage de type de données. En outre, si un outil ETL tiers, comme Informatica ou Talend, est déjà utilisé dans l’environnement Netezza, cet outil peut implémenter toutes les transformations de données requises.

Différences de DML SQL entre Netezza et Azure Synapse

Langage de manipulation de données SQL (DML)

Conseil

Les commandes SQL DML SELECT, INSERT et UPDATE possèdent des éléments principaux standard, mais peuvent également implémenter différentes options de syntaxe.

La norme ANSI SQL définit la syntaxe de base pour les commandes DDL telles que SELECT, INSERT, UPDATE et DELETE. Netezza et Azure Synapse utilisent ces commandes, mais dans certains cas, il existe des différences d’implémentation.

Les sections suivantes décrivent les commandes DML spécifiques à Netezza que vous devez prendre en compte lors d’une migration vers Azure Synapse.

Différences de syntaxe SQL DML

Vous devez être conscient de l’existence de différences en matière de syntaxe DML (SQL Data Manipulation Language) entre Netezza SQL et Azure Synapse lors de la migration :

  • 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, DATEDIFF donne 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

Conseil

Évaluez le nombre et le type d’objets hors données à migrer dans le cadre de la phase de préparation.

Lors de la migration à partir d’un environnement d’entrepôt de données hérité mature, comme Netezza, il existe souvent des éléments autres que des tables et des vues simples qui doivent être migrés vers le nouvel environnement cible. C’est le cas, par exemple, des fonctions, des procédures stockées, des déclencheurs et des séquences.

Dans le cadre de la phase de préparation, créez un inventaire des objets qui doivent être migrés et définissez les méthodes pour les gérer. Attribuez ensuite une allocation appropriée des ressources dans le plan de projet.

Il peut exister des services de l’environnement Azure qui remplacent les fonctionnalités implémentées sous forme de fonctions ou de procédures stockées dans l’environnement Netezza. Dans ce cas, il est souvent plus efficace d’utiliser les services Azure intégrés que de recoder les fonctions Netezza.

Conseil

Les produits et services tiers peuvent automatiser la migration d’éléments autres que des données.

Les partenaires Microsoft offrent des outils et des services qui peuvent automatiser la migration, notamment le mappage des types de données. En outre, si un outil ETL tiers, comme Informatica ou Talend, est déjà utilisé dans l’environnement IBM Netezza, il peut implémenter toutes les transformations de données requises.

Pour plus d’informations sur chacun de ces éléments, consultez les sections suivantes.

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. Lors de la migration vers une autre plateforme de base de données, comme Azure Synapse, des fonctions système communes sont disponibles et peuvent être migrées sans modification. D’autres présentent une syntaxe légèrement différente, mais les modifications requises sont automatisables. Les fonctions système pour lesquelles il n’existe pas d’équivalent, telles que les fonctions arbitraires définies par l’utilisateur, peuvent imposer un recodage à l’aide des langages disponibles dans l’environnement cible. Azure Synapse utilise le langage Transact-SQL bien connu pour implémenter les fonctions définies par l’utilisateur. Les fonctions définies par l’utilisateur dans Netezza sont codées avec le langage nzLua ou C++.

Procédures stockées

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

Azure Synapse Analytics prend également en charge les procédures stockées à l’aide de T-SQL. Par conséquent, si vous devez migrer des procédures stockées, recodez-les en conséquence.

Séquences

dans Netezza, une séquence est un objet de base de données nommé créé à l’aide de CREATE SEQUENCE, qui peut fournir la valeur unique au moyen de la méthode NEXT VALUE FOR. Utilisez-les pour générer des nombres uniques servant de valeurs de clé de substitution pour les valeurs de clé primaire.

Dans Azure Synapse, il n’y a pas de CREATE SEQUENCE. Les séquences sont gérées à l’aide de l’IDENTITÉ pour créer des clés de substitution ou d’une identité managée à l’aide de code SQL pour créer le numéro de séquence suivant dans une série.

Utiliser EXPLAIN pour valider les SQL hérités

Conseil

Utilisez des requêtes réelles à partir des journaux de requêtes système existants pour rechercher des problèmes de migration potentiels.

Capturez des instructions SQL représentatives des journaux de l’historique des requêtes hérités pour évaluer le SQL Netezza hérité à des fins de compatibilité avec Azure Synapse. Préfixez ensuite ces requêtes avec EXPLAIN et, en supposant un modèle de données migré « like for like » dans Azure Synapse avec les mêmes noms de table et de colonne, exécutez ces instructions EXPLAIN dans Azure Synapse. Tout SQL incompatible retourne une erreur. Utilisez ces informations pour déterminer l’ampleur de la tâche de recodage. Cette approche ne nécessite pas que les données soient chargées dans l’environnement Azure, uniquement que les tables et vues appropriées aient été créées.

Mappage IBM Netezza vers T-SQL

Le mappage des types de données IBM Netezza vers T-SQL conforme à Azure Synapse SQL se trouve dans ce tableau :

Type de données IBM Netezza Type de données Azure Synapse SQL
tableau Non pris en charge
bigint bigint
binary large object [(n[K|M|G])] nvarchar [(n|max)]
 blob [(n[K|M|G])] nvarchar [(n|max)]
 byte [(n)] binary [(n)]|varbinary(max)
 byteint SMALLINT
 char varying [(n)] varchar [(n|max)]
character varying [(n)] varchar [(n|max)]
 char [(n)] char [(n)]|varchar(max)
character [(n)] char [(n)]|varchar(max)
 character large object [(n[K|M|G])] varchar [(n|max)
 clob [(n[K|M|G])] varchar [(n|max)
 dataset Non pris en charge 
 Date Date
 dec [(p[,s])] décimal [(p[,s])]
 décimal [(p[,s])] décimal [(p[,s])]
 double précision float(53)
 float [(n)] float [(n)]
 graphic [(n)] nchar [(n)]| varchar(max)
 interval Non pris en charge 
 json [(n)] nvarchar [(n|max)]
 long varchar nvarchar(max)
 long vargraphic nvarchar(max)
 mbb Non pris en charge 
 mbr Non pris en charge 
 number [((p|*)[,s])] numeric [(p[,s])]
 numeric [(p [,s])]  numeric [(p[,s])]
 period Non pris en charge 
 real  real
 SMALLINT SMALLINT
 st_geometry Non pris en charge 
 time time
 time with time zone datetimeoffset
 timestamp  datetime2
 timestamp with time zone datetimeoffset
 varbyte varbinary [(n|max)]
 varchar [(n)]  varchar [(n)]
 vargraphic [(n)] nvarchar [(n|max)]
 varray Non pris en charge 
 Xml Non pris en charge 
 xmltype Non pris en charge 

Résumé

Les installations Netezza héritées existantes sont implémentées de manière à faciliter la migration vers Azure Synapse. Ils utilisent SQL pour les requêtes analytiques sur des volumes de données importants et sont sous une forme quelconque de modèle de données dimensionnel. Ces facteurs font d’eux de bons candidats pour la migration vers Azure Synapse.

Pour réduire la tâche de migration du code SQL réel, suivez ces recommandations :

  • La migration initiale de l’entrepôt de données doit être telle quelle pour réduire les risques et le temps nécessaire, même si l’environnement final éventuel incorporera un modèle de données différent tel que le coffre de données.

  • Comprendre les différences entre l’implémentation de Netezza SQL et Azure Synapse.

  • Utilisez les métadonnées et les journaux de requête de l’implémentation Netezza existante pour évaluer l’impact des différences et planifier une approche d’atténuation.

  • Automatisez le processus dans la mesure du possible pour réduire les erreurs, les risques et le temps de la migration.

  • Envisagez d’utiliser des services et des partenaires Microsoft spécialisés pour simplifier la migration.

Étapes suivantes

Pour en savoir plus sur les outils Microsoft et tiers, consultez l’article suivant de cette série : Outils pour la migration de l’entrepôt de données Netezza vers Azure Synapse Analytics.