SAS/ACCESS to Hadoop et les colonnes String (32k string thing)

Si vous avez l’habitude de travailler avec SAS et Hadoop vous avez sans doute été confronté, au moins une fois, au problème des 32K, The «32k string thing» comme vous pourriez le lire sur internet, notamment sur  communities.sas.com. On doit d’ailleurs ce nom à  Jeff Bailey.

Le constat

Vous travaillez avec des données stockées dans un cluster Hadoop, ce qui n’est pas un problème mais plutôt un excellent choix. Vous copiez vos données de ce cluster vers SAS (dans votre work par exemple) et vous vous retrouvez rapidement avec des problèmes d’espace, pouvant aller jusqu’à la saturation de la Work . En effet, après rapatriement et malgré la faible volumétrie de vos données Hadoop, l’espace occupé, côté SAS, est disproportionné. D’ailleurs, si vous prêtez attention au warning présent dans votre journal SAS vous constatez le message suivant : WARNING: SAS/ACCESS assigned this column a length of 32767. If the resulting SAS character variable remains this length, SAS performance is impacted. [Update avril 2019] Il est possible de remplacer le WARNING par un ERROR en suivant les instructions de la note http://support.sas.com/kb/63/952.html

Le problème

L’impact n’est pas négligeable. En effet, l’une des particularités d’Hadoop est de travailler avec des volumétries de données importantes. Si vos données Hadoop contiennent de nombreuses colonne typées String et des nombreuses données, l’espace nécessaire côté SAS peut rapidement devenir problématique. En effet, une table n’occupant que 300 MO peut faire 30 go une fois rapatrié dans SAS. ce point est documenté ici : Issues When Converting Data from Hive to SAS  Au passage, examinons au passage la structure de la table pour vérifier le type de données de notre colonne « à problème » et la « vision » SAS, via une proc content : Nous constatons que notre variable chaine, de type texte, « consomme » 32767 octets : La volumétrie de la table, côté SAS,  est de 520 ko : Avant de continuer, un point rapide s'impose :

• Si la table est créé via SAS , depuis un dataset SAS et via de l'IMPLICIT PASS-THROUGH, les propriétés de table seront bien positionnées côté Hadoop.  Pas de problème 32K
• Si la table est créé via SAS (depuis un dataset SAS et via de l'EXPLICIT PASS-THROUGH, aucune propriété SASFMT ne sera créé côté Hadoop. Problème 32K
• Avec une table créé « en dehors de SAS » (via HUE ou à partir d'un fichier plat), il est nécessaire de faire un ALTER TABLE pour ajouter la propriété de table SASFMT.  Problème 32K

Pour résumer : Si la table Hadoop possède une propriété SASFMT correctement spécifié, l’accès via une proc sql aura pour conséquence une taille de données correcte coté SAS. Vous pourriez être tenté d'utiliser l'option COMPRESS mais si vous travaillez sur votre table (PROC SORT par exemple) SAS peut être amené à decompresser cette table. Ce n'est donc pas une solution.

Comment appliquer l'option SASFMT sur une table existante ?

Pour spécifier une limite pour une colonne STRING individuelle, utiliser une instruction Hive ALTER TABLE limitant la longueur de la colonne. Exemple : Puis vérifions la nouvelle structure de la table : Et pour terminer, vérifions dans SAS : Code : Journal :   Proc content : Le dataset SAS n'occupe maintenant plus que 160 ko contre 520 ko avant l'ajout de la propriété : ATTENTION : Il est important de bien définir la valeur de la propriété SASFMT afin de ne pas obtenir des valeurs tronquées ! Exemple de données avec SASFMT positionnée à 100 :   Exemple de données avec SASFMT positionné à 10 :     Sources et autres documentations : Problem Note 63952: Queries of Hadoop tables return "WARNING: The following column could have a length in SAS of 32767..." and cause performance problems Data Types for Hadoop > Issues When Converting Data from Hive to SAS SAS/ACCESS to Hadoop et les champs STRING : WARNING ou ERROR ?