Data Step

Eliminación de duplicados en tablas CAS: Por qué fallan sus Hash Tables y cómo solucionarlo

Simon 5 views

Si usted es un experto en SAS© 9, probablemente utiliza las Hash Tables para eliminar eficazmente duplicados de grandes volúmenes de datos sin necesidad de ordenar (PROC SORT). Sin embargo, al migrar este código a SAS© Viya (CAS), puede llevarse una sorpresa desagradable: su tabla de salida aún contiene duplicados.

¿Por qué esta técnica probada falla en la Nube y cuáles son las alternativas eficientes?

La Trampa: Hash Tables y Procesamiento Distribuido

En un entorno SAS© 9 clásico (SMP), el Data Step se ejecuta secuencialmente en un solo procesador. La tabla hash mantiene en memoria las claves únicas vistas desde el principio del archivo.

En CAS (MPP - Massively Parallel Processing), la ejecución es fundamentalmente diferente:

  1. Sus datos se particionan en varios nodos (workers) y threads.

  2. El Data Step se ejecuta en paralelo en cada thread.

  3. Cada thread posee su propia instancia local de la Hash Table.

El problema: Si el duplicado de la clave "A" se encuentra en el Thread 1 y el original está en el Thread 2, sus Hash Tables respectivas no se comunican. Cada thread pensará que tiene una clave única. Resultado: los duplicados persisten en la tabla final consolidada.


Solución 1: El método nativo (Recomendado)

La forma más eficiente de eliminar duplicados en Viya es usar la acción CAS dedicada. Está optimizada para el motor distribuido y gestiona la mezcla de datos (shuffling) necesaria para comparar registros entre nodos.

Utilice la acción deduplication.deduplicate a través de 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;
Ventaja: Máximo rendimiento.

Nota: La opción groupBy define las claves de eliminación de duplicados.

Solución 2: La sorpresa PROC SORT

Contrariamente a las creencias populares, el viejo y fiable PROC SORT con la opción NODUPKEY es muy eficiente en CAS.

El motor CAS intercepta la sintaxis de PROC SORT y la traduce en operaciones distribuidas optimizadas. No devuelve los datos localmente para ordenarlos; todo ocurre en memoria en el clúster.

1 
2PROC SORT
3DATA=casuser.ma_table_source out=casuser.ma_table_dedoublonnee nodupkey;
4 
5BY var_cle1 var_cle2;
6 
7RUN;
8 
Veredicto: Las pruebas muestran que este método es casi tan rápido como la acción deduplicate. A menudo es la mejor opción para migrar código existente sin una reescritura compleja.

Solución 3: El Data Step con BY group

Si insiste en usar un Data Step, debe abandonar la lógica de Hash Table para volver a la lógica secuencial BY + FIRST..

¿Por qué funciona esto sin un ordenamiento previo? En CAS, la instrucción BY fuerza una reorganización de los datos: el controlador asegura que todas las filas con la misma clave BY se envían al mismo hilo (agrupación).

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;
Advertencia: Aunque es funcional, este método implica un movimiento masivo de datos (network shuffle) para agrupar las claves, lo que puede ser menos eficiente que la acción dedicada en volúmenes muy grandes.

Single-threaded: Forzar la ejecución en un solo hilo (/single=yes) resolvería el problema de las Hash Tables, pero anularía el rendimiento al eliminar todo el propósito del procesamiento paralelo de Viya.

En resumen

MétodoRendimientoComplejidadVeredicto
Hash TablesAltaMediaA evitar para eliminar duplicados (riesgo de error lógico en distribuido).
Acción CAS (deduplicate)⭐⭐⭐MediaLo mejor para scripts nativos CASL.
PROC SORT (nodupkey)⭐⭐½BajaIdeal para compatibilidad y simplicidad.
Data Step (By Group)⭐⭐Baja⚠️ Funciona, pero atención al costo de red.