Gestion des types de données

Lorsque vous modifiez le type de données ou la taille de type de données d'une colonne, cela peut avoir des conséquences sur les tâches qui utilisent le jeu de données.

Les types de données et les conversions supportés varient selon la plateforme cible. Pour obtenir la documentation spécifique à votre plateforme cible, consultez Configuration des connexions aux cibles.

Comprendre l'impact de la modification d'un type de données

Il existe deux cas d'utilisation courants pour la modification de la taille du type de données ou le passage à un type de données différent :

• Une ingestion de données qui ne tiendra pas dans le type de données actuel.
• Le besoin d'une plus grande exactitude numérique. Par exemple, le remplacement de SMALLINT par DECIMAL (p,s).

Dans la plupart des cas, la modification d'un type de données entraînera une opération ALTER TABLE, empêchant ainsi toute perte de données. Par exemple, si le type de données précédent était STRING (25) et si le nouveau type de données est STRING (50), les données de la colonne avec le nouveau type de données seront mises à jour sans aucun problème. En revanche, dans certains cas, la modification d'un type de données entraînera l'exclusion et la recréation du tableau. Par exemple, si le type de données précédent d'une colonne est NUMBER et si vous le remplacez par DATE, le tableau est ignoré et recréé, car il n'est pas possible de convertir des nombres en dates. De même, si la plateforme cible (comme Databricks) ne supporte pas les opérations ALTER TABLE, le tableau sera ignoré et recréé.

Dans certains cas, il est théoriquement possible d'altérer un tableau, mais, en raison de la complexité sous-jacente, la tâche de données ignorera et recréera le tableau. Pour finir, dans certains cas, la perte de données potentielle et non la perte de données réelle déclenchera une opération d'abandon et de recréation. Par exemple, si vous remplacez STRING(25) par STRING(1), il se produira une perte de données si les données ingérées ne tiennent pas dans STRING(1). Cependant, il est possible que STRING(25) contienne toujours un seul caractère. Par conséquent, dans la pratique, il ne se produira aucune perte de données, mais le tableau sera tout de même ignoré et recréé en raison d'une perte de données potentielle.

Modifications apportées aux types de données qui nécessitent que le tableau soit ignoré et recréé, quelle que soit la plateforme cible

La modification des types de données suivants entraînera l'abandon et la recréation du tableau :

• BYTES
• BLOB
• CLOB
• NCLOB

Plateformes cibles qui supportent les modifications apportées à la taille de type de données sans ignorer et recréer le tableau

Si vous utilisez Snowflake, Google BigQuery, Amazon Redshift, Microsoft SQL Server et Azure Synapse Analytics, vous pouvez modifier la taille de certains types de données sans entraîner l'abandon et la recréation du tableau. Le tableau suivant répertorie les types de données supportés pour chacune des plateformes susmentionnées.

Plateformes cibles qui supportent le remplacement des types de données par STRING sans ignorer et recréer le tableau

Lors du déplacement de données vers Microsoft SQL Server et Azure Synapse Analytics, vous pouvez remplacer les types de données suivants par STRING sans entraîner l'abandon et la recréation du tableau :

• BOOLEAN
• DATE
• TIME
• DATETIME
• INT1
• INT2
• INT4
• INT8
• REAL4
• REAL8
• UINT1
• UINT2
• UNIT4
• UNIT8
• NUMERIC
• WSTRING (supporté avec Azure Synapse Analytics uniquement)

Gestion des données JSON

Qlik a lancé le support du type de données JSON en 2025. Le support du type de données JSON n'est pas disponible dans les tâches créées avant le lancement. Dans les nouvelles tâches, les colonnes contenant des données JSON seront converties dans le type de données spécifié pour la plateforme cible. Data Movement gateway 2024.11.78 ou une version supérieure est requis pour découvrir le type de données JSON dans les tâches de dépôt temporaire si vous utilisez une passerelle client-managed.

Lorsque les données JSON sont converties, ces nouvelles règles de transformation globales peuvent être créées.

• QLIK__PARSE_TO_JSON

  Cette règle est créée dans les projets Snowflake dans lesquels le dépôt temporaire charge des données pour les déposer temporairement dans un lac. La règle est ajoutée à la tâche de stockage après le dépôt temporaire pour analyser toutes les colonnes JSON en JSON dans Snowflake.

• QLIK__JSON_AS_VARCHAR

  Cette règle est créée dans les projets Snowflake dans lesquels les données sont déposées temporairement dans Snowflake et le stockage crée des tables Iceberg gérées par Snowflake. La règle convertit JSON en Varchar, car Iceberg ne supporte pas le type Variant.

Gestion des données JSON existantes dans les tâches créées avant le lancement du support du type de données JSON

• Si vous avez des tâches existantes avec des données JSON, VARIANT ou SUPER sur la plateforme de données converties en un autre type de données, par exemple BLOB, vous pouvez envisager de convertir les colonnes dans le type de données utilisé pour JSON sur la plateforme cible. Vous pouvez effectuer cette opération à l'aide d'une règle de transformation. Cela peut s'avérer nécessaire si vous devez utiliser de nouvelles colonnes avec des colonnes existantes dans des tâches en aval.

• Une autre option consiste à convertir les colonnes de la nouvelle tâche dans le même type de données que celui utilisé dans les types de données existants afin de maintenir la rétrocompatibilité.