Réduire les problèmes de SQL pour les migrations Teradata
Cet article est la quatrième partie d’une série de sept parties qui fournit des conseils sur la migration de Teradata vers Azure Synapse Analytics. L’objectif de cet article est de fournir les meilleures pratiques pour réduire les problèmes liés à SQL.
Vue d’ensemble
Caractéristiques des environnements Teradata
Conseil
Teradata a lancé des bases de données SQL à grande échelle à l’aide de MPP dans les années 1980.
En 1984, Teradata a initialement publié son produit de base de données. La société a introduit des techniques de traitement massivement parallèle (MPP) pour permettre le traitement des données à une échelle plus efficace que les technologies mainframe existantes 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 a utilisé du matériel propriétaire et a été attachée aux mainframes, généralement des processeurs IBM ou compatibles avec IBM.
Bien que des annonces plus récentes aient inclus la connectivité réseau et la disponibilité de la pile de technologies Teradata dans le cloud (y compris Azure), la plupart des installations existantes sont locales, et de nombreux utilisateurs envisagent de migrer certaines données Teradata ou toutes leurs données Teradata vers Azure Synapse Analytics pour bénéficier des avantages d’un déplacement vers un environnement cloud moderne.
Conseil
De nombreuses installations Teradata existantes sont des entrepôts de données employant un modèle de données dimensionnel.
La technologie Teradata 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 Teradata hérité et fournit des solutions de contournement.
Utiliser une instance Teradata de machine virtuelle dans le cadre d’une migration
Conseil
Utilisez une machine virtuelle Azure pour créer une instance Teradata temporaire pour accélérer la migration et réduire l’impact sur le système source.
Tirez parti de l’environnement Azure lors de l’exécution d’une migration à partir d’un environnement Teradata local. Azure fournit un stockage cloud abordable ainsi qu’une extensibilité élastique pour créer une instance Teradata au sein d’une machine virtuelle Azure, colocalisés avec l’environnement Azure Synapse cible.
Avec cette approche, il est possible de se servir d’utilitaires Teradata standard tels que Teradata Parallel Data Transporter (ou d’outils de réplication de données tiers tels qu’Attunity Replicate) pour déplacer efficacement le sous-ensemble de tables Teradata à migrer vers l’instance de machine virtuelle, après quoi toutes les tâches de migration peuvent avoir lieu dans l’environnement Azure. Cette approche présente plusieurs avantages :
Après la réplication initiale des données, le système source n’est pas affecté par les tâches de migration.
Les interfaces, outils et utilitaires Teradata familiers sont disponibles dans l’environnement Azure.
Une fois dans l’environnement Azure, il n’y a plus de problèmes potentiels liés à la disponibilité de la bande passante réseau entre le système source local et le système cible dans le cloud.
Des outils tels qu’Azure Data Factory peuvent appeler efficacement des utilitaires tels que Teradata Parallel Transporter pour migrer des données rapidement et facilement.
Le processus de migration est entièrement orchestré et contrôlé dans l’environnement Azure.
Utiliser Azure Data Factory pour implémenter une migration pilotée par les métadonnées
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 Teradata 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 SQL DDL entre Teradata 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 Teradata 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 à Teradata à 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, il n’existe aucun équivalent de l’option MULTISET dans la syntaxe CREATE TABLE de Teradata.
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 un index secondaire non unique (NUSI) a été créé dans l’environnement Teradata source, cela peut indiquer qu’un index non 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 de tables Teradata non pris en charge
Conseil
Les tables standard dans Azure Synapse peuvent prendre en charge les séries chronologiques Teradata migrées et les tables temporelles.
Teradata prend en charge des types de tables spéciaux pour les données de séries chronologiques et temporelles. La syntaxe et certaines des fonctions de ces types de tables ne sont pas directement prises en charge dans Azure Synapse mais il est possible de migrer les données vers une table standard avec des types de données appropriés, ainsi qu’une indexation ou un partitionnement sur la colonne de date/heure.
Teradata implémente la fonctionnalité de requête temporelle via la réécriture de requête pour ajouter des filtres dans une requête temporelle afin de limiter la plage de dates applicable. Si cette fonctionnalité est actuellement utilisée dans l’environnement Teradata source et doit être migrée, ce filtrage supplémentaire doit être ajouté aux requêtes temporelles appropriées.
L’environnement Azure inclut également des fonctionnalités spécifiques pour l’analytique complexe sur les données de série chronologique à grande échelle appelées insights de série chronologique, ce qui est destiné aux applications d’analyse des données IoT et peut être plus approprié pour ce cas d’utilisation.
Types de données Teradata non pris en charge
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 Teradata ont un équivalent direct dans Azure Synapse. Le tableau suivant présente les types de données Teradata qui ne sont pas pris en charge dans Azure Synapse, ainsi que le mappage recommandé. Dans le tableau, le type de colonne Teradata est le type stocké dans le catalogue système (par exemple, dans DBC.ColumnsV).
| Type de colonne Teradata | Type de données Teradata | Type de données Azure Synapse |
|---|---|---|
| ++ | TD_ANYTYPE | Non pris en charge dans Azure Synapse |
| A1 | ARRAY | Non pris en charge dans Azure Synapse |
| AN | ARRAY | Non pris en charge dans Azure Synapse |
| AT | TEMPS | TEMPS |
| BF | BYTE | BINARY |
| BO | BLOB | Le type de données BLOB n’est pas directement pris en charge, mais peut être remplacé par BINARY. |
| BV | VARBYTE | BINARY |
| CF | VARCHAR | CHAR |
| CO | CLOB | Le type de données CLOB n’est pas directement pris en charge, mais peut être remplacé par VARCHAR. |
| CV | VARCHAR | VARCHAR |
| D | DECIMAL | DECIMAL |
| DA | DATE | DATE |
| DH | INTERVAL DAY TO HOUR | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
| DM | INTERVAL DAY TO MINUTE | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
| Source de données | INTERVAL DAY TO SECOND | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
| DT | JEU DE DONNÉES | Le type de données DATASET est pris en charge dans Azure Synapse. |
| DY | INTERVAL DAY | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
| F | FLOAT | FLOAT |
| HM | INTERVAL HOUR TO MINUTE | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
| HR | INTERVAL HOUR | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
| HS | INTERVAL HOUR TO SECOND | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
| I1 | BYTEINT | TINYINT |
| I2 | SMALLINT | SMALLINT |
| I8 | bigint | bigint |
| I | INTEGER | INT |
| JN | JSON | Le type de données JSON n’est pas pris en charge directement dans Azure Synapse, mais les données JSON peuvent être stockées dans un champ VARCHAR. |
| MI | INTERVAL MINUTE | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
| MO | INTERVAL MONTH | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
| MS | INTERVAL MINUTE TO SECOND | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
| N | NUMBER | NUMERIC |
| PD | PERIOD(DATE) | Peut être converti en VARCHAR ou fractionné en deux dates distinctes |
| PM | PÉRIODE (TIMESTAMP AVEC FUSEAU HORAIRE) | Peut être converti en VARCHAR ou divisé en deux horodatages distincts (DATETIMEOFFSET) |
| PS | PERIOD(TIMESTAMP) | Peut être converti en VARCHAR ou divisé en deux horodatages distincts (DATETIMEOFFSET) |
| PT | PERIOD(TIME) | Peut être converti en VARCHAR ou fractionné en deux dates distinctes |
| PZ | PÉRIODE (HEURE AVEC FUSEAU HORAIRE) | Peut être converti en VARCHAR ou fractionné en deux fois, mais WITH TIME ZONE n’est pas pris en charge pour TIME |
| SC | INTERVAL SECOND | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
| SZ | TIMESTAMP WITH TIME ZONE | DATETIMEOFFSET |
| TS | timestamp | DATETIME ou DATETIME2 |
| TZ | TIME WITH TIME ZONE | TIME WITH TIME ZONE n’est pas pris en charge, car TIME est stocké à l’aide de l’heure « wall clock » uniquement sans décalage de fuseau horaire. |
| XM | XML | Le type de données XML n’est pas pris en charge directement dans Azure Synapse, mais les données XML peuvent être stockées dans un champ VARCHAR. |
| YM | INTERVAL YEAR TO MONTH | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
| YR | INTERVAL YEAR | Les types de données INTERVAL ne sont pas pris en charge dans Azure Synapse, mais les calculs de date peuvent être effectués avec les fonctions de comparaison de dates (par exemple, DATEDIFF et DATEADD). |
Utilisez les métadonnées des tables de catalogue Teradata pour déterminer si l’un de ces types de données doit être migré, et autoriser cette migration dans le plan de migration. Par exemple, utilisez une requête SQL telle que celle-ci pour rechercher toutes les occurrences de types de données non pris en charge qui nécessitent une attention.
SELECT
ColumnType, CASE
WHEN ColumnType = '++' THEN 'TD_ANYTYPE'
WHEN ColumnType = 'A1' THEN 'ARRAY' WHEN
ColumnType = 'AN' THEN 'ARRAY' WHEN
ColumnType = 'BO' THEN 'BLOB'
WHEN ColumnType = 'CO' THEN 'CLOB'
WHEN ColumnType = 'DH' THEN 'INTERVAL DAY TO HOUR' WHEN
ColumnType = 'DM' THEN 'INTERVAL DAY TO MINUTE' WHEN
ColumnType = 'DS' THEN 'INTERVAL DAY TO SECOND' WHEN
ColumnType = 'DT' THEN 'DATASET'
WHEN ColumnType = 'DY' THEN 'INTERVAL DAY'
WHEN ColumnType = 'HM' THEN 'INTERVAL HOUR TO MINUTE' WHEN
ColumnType = 'HR' THEN 'INTERVAL HOUR'
WHEN ColumnType = 'HS' THEN 'INTERVAL HOUR TO SECOND' WHEN
ColumnType = 'JN' THEN 'JSON'
WHEN ColumnType = 'MI' THEN 'INTERVAL MINUTE' WHEN
ColumnType = 'MO' THEN 'INTERVAL MONTH'
WHEN ColumnType = 'MS' THEN 'INTERVAL MINUTE TO SECOND' WHEN
ColumnType = 'PD' THEN 'PERIOD(DATE)'
WHEN ColumnType = 'PM' THEN 'PERIOD (TIMESTAMP WITH TIME ZONE)'
WHEN ColumnType = 'PS' THEN 'PERIOD(TIMESTAMP)' WHEN
ColumnType = 'PT' THEN 'PERIOD(TIME)'
WHEN ColumnType = 'PZ' THEN 'PERIOD (TIME WITH TIME ZONE)' WHEN
ColumnType = 'SC' THEN 'INTERVAL SECOND'
WHEN ColumnType = 'SZ' THEN 'TIMESTAMP WITH TIME ZONE' WHEN
ColumnType = 'XM' THEN 'XML'
WHEN ColumnType = 'YM' THEN 'INTERVAL YEAR TO MONTH' WHEN
ColumnType = 'YR' THEN 'INTERVAL YEAR'
END AS Data_Type,
COUNT (*) AS Data_Type_Count FROM
DBC.ColumnsV
WHERE DatabaseName IN ('UserDB1', 'UserDB2', 'UserDB3') -- select databases to be migrated
GROUP BY 1,2
ORDER BY 1;
Conseil
Des outils et services tiers peuvent automatiser des tâches de mappage de données.
Certains 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, tel qu’Informatica ou Talend, est déjà utilisé dans l’environnement Teradata, il peut implémenter toutes les transformations de données requises.
Génération de langage de définition de données (Data Definition Language, DDL)
Conseil
Utilisez les métadonnées Teradata existantes pour automatiser la génération de CREATE TABLE et CREATE VIEW DDL pour Azure Synapse.
Modifiez des scripts Teradata 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 la suppression de clauses supplémentaires spécifiques de Teradata, telles que FALLBACK ou MULTISET.
Toutefois, toutes les informations qui spécifient les définitions actuelles des tables et des vues au sein de l’environnement Teradata 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.
Ces informations sont accessibles par le biais de vues du catalogue, par exemple DBC.ColumnsV, et permettent de générer les instructions DDL CREATE TABLE équivalentes 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, tel qu’Informatica ou Talend, est déjà utilisé dans l’environnement Teradata, il peut implémenter toutes les transformations de données requises.
Différences SQL DML entre Teradata 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. Teradata 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 à Teradata 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 Teradata SQL et Azure Synapse (T-SQL) lors de la migration :
QUALIFY: Teradata prend en charge l’opérateurQUALIFY. Par exemple :SELECT col1 FROM tab1 WHERE col1='XYZ' QUALIFY ROW_NUMBER () OVER (PARTITION by col1 ORDER BY col1) = 1;L’équivalent dans la syntaxe Azure Synapse est le suivant :
SELECT * FROM ( SELECT col1, ROW_NUMBER () OVER (PARTITION by col1 ORDER BY col1) rn FROM tab1 WHERE col1='XYZ' ) WHERE rn = 1;Date arithmétique : Azure Synapse a des opérateurs tels que
DATEADDetDATEDIFFqui peuvent être utilisés sur les champsDATEouDATETIME. Teradata prend en charge la soustraction directe des dates, tels queSELECT DATE1 - DATE2 FROM...En
GROUP BYordinal, fournissez explicitement le nom de colonne T-SQL.LIKE ANY: Teradata prend en charge la syntaxeLIKE ANYtelle que :SELECT * FROM CUSTOMER WHERE POSTCODE LIKE ANY ('CV1%', 'CV2%', 'CV3%');L’équivalent dans la syntaxe Azure Synapse est le suivant :
SELECT * FROM CUSTOMER WHERE (POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE 'CV3%');Selon les paramètres système, les comparaisons de caractères dans Teradata peuvent ignorer la casse par défaut. Dans Azure Synapse, les comparaisons de caractères respectent toujours la casse.
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.
Un moyen de tester les SQL Teradata hérités pour la compatibilité avec Azure Synapse consiste à capturer des instructions SQL représentatives à partir des journaux de requête système hérités, de préfixer ces requêtes avec EXPLAIN et (en supposant un modèle de données « like for like » dans Azure Synapse avec les mêmes noms de table et de colonnes) d’exécuter ces EXPLAIN instructions dans Azure Synapse. Tout SQL incompatible génère une erreur : utilisez ces informations pour déterminer l’échelle 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.
Fonctions, procédures stockées, déclencheurs 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, tel Teradata, 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 Teradata. Dans ce cas, il est souvent plus efficace d’utiliser les services Azure intégrés que de recoder les fonctions Teradata.
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.
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, Teradata prend en charge des fonctions système, ainsi que des fonctions définies par l’utilisateur au sein de 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.
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. À cette fin, Teradata fournit le langage SPL. 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.
Les pools de SQL dédiés de Azure Synapse Analytics prennent é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.
Déclencheurs
Azure Synapse ne prend pas en charge la création de déclencheurs, mais vous pouvez les implémenter dans Azure Data Factory.
Séquences
Les séquences Azure Synapse sont gérées de la même façon que Teradata, en utilisant IDENTITY pour créer des clés de substitution ou une identité managée.
Mappage Teradata vers T-SQL
Ce tableau montre la valeur Teradata en T-SQL conforme au mappage de type de données Azure Synapse SQL :
| Type de données Teradata | Type de données Azure Synapse SQL |
|---|---|
| bigint | bigint |
| bool | bit |
| boolean | bit |
| byteint | TINYINT |
| char [(p)] | char [(p)] |
| char variant [(p)] | varchar [(p)] |
| caractère [(p)] | char [(p)] |
| caractère variant [(p)] | varchar [(p)] |
| Date | Date |
| DATETIME | DATETIME |
| dec [(p[,s])] | décimal [(p[,s])] |
| décimal [(p[,s])] | décimal [(p[,s])] |
| double | float(53) |
| double précision | float(53) |
| float [(p)] | float [(p)] |
| float4 | float(53) |
| float8 | float(53) |
| int | int |
| int1 | TINYINT |
| int2 | SMALLINT |
| int4 | int |
| int8 | bigint |
| entier | entier |
| interval | Non pris en charge |
| char national variant [(p)] | nvarchar [(p)] |
| caractère national [(p)] | nchar [(p)] |
| caractère national variant [(p)] | nvarchar [(p)] |
| nchar [(p)] | nchar [(p)] |
| numérique [(p[,s])] | numérique [(p[,s]) |
| nvarchar [(p)] | nvarchar [(p)] |
| real | real |
| SMALLINT | SMALLINT |
| time | time |
| time with time zone | datetimeoffset |
| time without time zone | time |
| intervalle de temps | Non pris en charge |
| timestamp | datetime2 |
| timetz | datetimeoffset |
| varchar [(p)] | varchar [(p)] |
Récapitulatif
Les installations Teradata 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.
Envisagez d’utiliser une instance Teradata dans une machine virtuelle Azure comme étape intermédiaire dans le cadre du processus de migration.
Comprendre les différences entre l’implémentation de Teradata SQL et Azure Synapse.
Utilisez les métadonnées et les journaux de requête de l’implémentation Teradata 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 Teradata vers Azure Synapse Analytics.