Lorsque vous modifiez la clause ORDER BY ou la liste des champs SELECT dans un déploiement Flink SQL, cette modification peut rompre ou non la compatibilité avec les données d'état existantes. Le maintien de la compatibilité dépend de deux facteurs : l'attribut de temps de tri (proctime ou rowtime) et le type de modification (champs SELECT par rapport aux clés de tri ou à la direction du tri).
Matrice de compatibilité
Utilisez ce tableau pour déterminer si une modification SQL prévue est sûre avant de l'appliquer à un déploiement en cours d'exécution.
| Attribut de temps de tri | Type de modification | Compatibilité de l'état |
|---|---|---|
proctime |
Ajout ou suppression d'un champ dans SELECT |
Compatible |
| Clés de tri (colonnes hors temps) | Ajout ou suppression d'un champ dans SELECT |
Compatible |
rowtime |
Ajout ou suppression d'un champ dans SELECT |
Incompatible |
| Tout | Modification des clés de tri ou de la direction du tri dans ORDER BY |
Incompatible |
« Compatible » signifie que le déploiement peut reprendre à partir d'un point de contrôle (checkpoint) ou d'un point de sauvegarde (savepoint) existant sans retraiter les données historiques. « Incompatible » signifie que le déploiement ne peut pas restaurer l'état précédent et doit être redémarré depuis zéro.
Exemple pratique
Tous les exemples de cette rubrique utilisent la table de base suivante et l'étendent ou la modifient pour illustrer chaque scénario.
-- Base table used throughout this topic
select a, b, c from MyTable order by <sort-expression> asc;Modifications compatibles
Modifier les champs SELECT lors du tri par proctime
L'ajout ou la suppression d'un champ dans SELECT est sans risque lorsque l'expression de tri utilise proctime.
-- Original SQL statement:
select a, b, c from MyTable order by proctime asc;
-- Add field d to SELECT. The deployment remains fully compatible with state data.
select a, b, c, d from MyTable order by proctime asc;Modifier les champs SELECT lors du tri par clés de tri
L'ajout ou la suppression d'un champ dans SELECT est également sans risque lorsque l'expression de tri utilise des clés de tri autres que le temps.
// Original SQL statement:
select a, b, ts from MyTable order by ts asc;
// Remove field ts from SELECT. The deployment remains fully compatible with state data.
select a, b from MyTable order by ts asc;Modifications incompatibles
Les modifications suivantes rompent la compatibilité de l'état, quel que soit l'attribut de temps de tri. Après l'une de ces modifications, le déploiement ne peut pas restaurer l'état précédent.
Modifier les champs SELECT lors du tri par rowtime
Contrairement à proctime, la modification des champs SELECT lors du tri par rowtime rend le déploiement incompatible avec les données d'état.
-- Original SQL statement:
select a, b, c from MyTable order by ts asc;
-- Add field d to SELECT. The deployment becomes incompatible with state data.
select a, b, c, d from MyTable order by ts asc;Modifier les clés de tri ou la direction du tri dans ORDER BY
La modification des clés de tri ou de la direction du tri dans ORDER BY rompt toujours la compatibilité de l'état.
-- Original SQL statement:
select a, b, c from MyTable order by ts asc;
-- Add field a to ORDER BY. The deployment becomes incompatible with state data.
select a, b, c from MyTable order by ts asc, a desc;FAQ
Puis-je ajouter une colonne à SELECT sans rompre l'état ?
Cela dépend de l'attribut de temps de tri. Si le déploiement trie par proctime ou par des clés de tri autres que le temps, l'ajout ou la suppression de champs SELECT est sans risque. S'il trie par rowtime, la même modification rompt la compatibilité de l'état.