Data Step

Déduplication de tables CAS : Pourquoi vos Hash Tables échouent et comment corriger le tir

Simon 15 vues

Si vous êtes un expert SAS© 9, vous utilisez probablement les Hash Tables pour dédoublonner efficacement de gros volumes de données sans passer par un tri (PROC SORT). Cependant, en migrant ce code vers SAS© Viya (CAS), vous risquez une mauvaise surprise : votre table de sortie contient encore des doublons.

Pourquoi cette technique éprouvée échoue-t-elle dans le Cloud, et quelles sont les alternatives performantes ?

Le Piège : Hash Tables et Traitement Distribué

Dans un environnement SAS© 9 classique (SMP), le Data Step s'exécute séquentiellement sur un seul processeur. La table de hachage garde en mémoire les clés uniques vues depuis le début du fichier.

Dans CAS (MPP - Massively Parallel Processing), l'exécution est fondamentalement différente :

  1. Vos données sont partitionnées sur plusieurs nœuds (workers) et threads.

  2. Le Data Step s'exécute en parallèle sur chaque thread.

  3. Chaque thread possède sa propre instance locale de la Hash Table.

Le problème : Si le doublon de la clé "A" se trouve sur le Thread 1 et que l'original est sur le Thread 2, leurs Hash Tables respectives ne communiquent pas. Chaque thread pensera avoir une clé unique. Résultat : des doublons persistent dans la table finale consolidée.


Solution 1 : La méthode native (Recommandée)

La façon la plus efficace de dédoublonner dans Viya est d'utiliser l'action CAS dédiée. Elle est optimisée pour le moteur distribué et gère le brassage des données (shuffling) nécessaire pour comparer les enregistrements entre les nœuds.

Utilisez l'action deduplication.deduplicate via PROC CAS :

1PROC CAS;
2 deduplication.deduplicate /
3 TABLE={caslib="casuser", name="ma_table_source", groupBy={"var_cle1", "var_cle2"}}
4 noDuplicateKeys=true
5 casOut={name="ma_table_dedoublonnee", caslib="casuser", replace=true};
6QUIT;
Avantage : Performance maximale.

Note : L'option groupBy définit les clés de déduplication.

Solution 2 : La surprise PROC SORT

Contrairement aux idées reçues, la bonne vieille PROC SORT avec l'option NODUPKEY est très performante dans CAS.

Le moteur CAS intercepte la syntaxe de la PROC SORT et la traduit en opérations distribuées optimisées. Elle ne ramène pas les données en local pour les trier ; tout se passe en mémoire sur le cluster.

1 
2PROC SORT
3DATA=casuser.ma_table_source out=casuser.ma_table_dedoublonnee nodupkey;
4 
5BY var_cle1 var_cle2;
6 
7RUN;
8 
Verdict : Les tests montrent que cette méthode est presque aussi rapide que l'action deduplicate. C'est souvent le meilleur choix pour migrer du code existant sans réécriture complexe.

Solution 3 : Le Data Step avec BY group

Si vous tenez absolument à utiliser un Data Step, vous devez abandonner la logique Hash Table pour revenir à la logique séquentielle BY + FIRST..

Pourquoi cela fonctionne-t-il sans tri préalable ? Dans CAS, l'instruction BY force une réorganisation des données : le contrôleur s'assure que toutes les lignes ayant la même clé BY sont envoyées au même thread (grouping).

1DATA casuser.ma_table_dedoublonnee;
2 SET casuser.ma_table_source;
3 BY var_cle1 var_cle2;
4 IF first.var_cle2; /* Garde la première occurrence */
5RUN;
Attention : Bien que fonctionnelle, cette méthode implique un mouvement massif de données (network shuffle) pour regrouper les clés, ce qui peut être moins performant que l'action dédiée sur de très gros volumes.

Single-threaded : Forcer l'exécution sur un seul thread (/single=yes) résoudrait le problème des Hash Tables, mais tuerait la performance en annulant tout l'intérêt du traitement parallèle de Viya.

En résumé

MéthodePerformanceComplexitéVerdict
Hash TablesÉlevéeMoyenneÀ éviter pour dédoublonner (risque d'erreur logique en distribué).
Action CAS (deduplicate)⭐⭐⭐MoyenneLe Top pour les scripts natifs CASL.
PROC SORT (nodupkey)⭐⭐½FaibleIdéal pour la compatibilité et la simplicité.
Data Step (By Group)⭐⭐Faible⚠️ Fonctionne, mais attention au coût réseau.