Une idée reçue persiste chez les utilisateurs historiques de SAS© confrontés au Big Data : "Pour analyser mes données Hadoop avec SAS©, je dois d'abord les extraire de HDFS, les convertir en tables SAS© locales, et ensuite lancer mes PROC SQL."
Cette approche (ETL classique) est non seulement inefficace, mais elle annule le principal avantage d'Hadoop : le traitement parallèle distribué. Si vous déplacez des pétaoctets de données vers un serveur SAS© unique (Compute Server), vous créez un goulot d'étranglement massif.
La réponse moderne (depuis SAS© 9.4) repose sur le principe du "In-Database Processing" : déplacer le code vers les données, et non l'inverse. Voici les trois technologies clés pour intégrer SAS© et Hadoop sans perdre la parallélisation.
1. PROC FEDSQL : Le SQL Nouvelle Génération
Si vous êtes habitué à PROC SQL, vous savez qu'elle a des limites en environnement distribué. Elle a souvent tendance à rapatrier les données pour effectuer les jointures ou les tris en local (sur le serveur SAS©).
La solution : PROC FEDSQL
Introduite avec SAS© 9.4, FedSQL est une implémentation propriétaire de la norme ANSI SQL:1999, conçue spécifiquement pour le traitement "Scalable".
Fonctionnement : FedSQL agit comme un traducteur intelligent. Lorsqu'il cible Hadoop (via Hive ou Impala), il tente de traduire votre requête en dialecte natif (HiveQL ou Impala SQL) et de l'exécuter directement sur le cluster.
Avantage : Les jointures, filtres et agrégations sont exécutés par les nœuds Hadoop en parallèle. Seul le résultat final (souvent petit) est renvoyé à SAS©.
Connectivité : Supporte Hive, HAWQ, et Impala.
2. Le Langage DS2 et le "Code Accelerator"
Le DATA Step classique de SAS© est séquentiel et monothread (il traite une ligne après l'autre sur un seul processeur). Il est donc incompatible avec la nature distribuée d'Hadoop.
La solution : Le langage DS2
DS2 est le successeur multithread du Data Step. Il inclut des concepts de programmation orientée objet et un typage fort, mais surtout, il est conçu pour l'exécution parallèle.
SAS© In-Database Code Accelerator : C'est le composant magique. Il permet de prendre un programme DS2 écrit dans votre interface SAS©, et de l'envoyer ("push") pour qu'il s'exécute à l'intérieur des nœuds de données Hadoop (sous forme de tâches MapReduce ou via Spark selon les versions).
Data Program & Thread Program : Le programme de données et les threads de traitement tournent en parallèle sur chaque nœud du cluster, exploitant toute la puissance CPU disponible sur votre infrastructure Big Data.
3. SAS© SPD Engine (SPDE) sur HDFS
Parfois, vous avez besoin de la structure physique d'une table SAS© (indexation, compression, métadonnées précises) mais vous voulez stocker ces données sur le système de fichiers distribué (HDFS) pour la fiabilité et la vitesse I/O.
La solution : Scalable Performance Data Engine (SPDE)
Le moteur SPDE permet de stocker des tables au format SAS© directement sur HDFS.
Il partitionne les données (fichiers de données .dpf, fichiers d'index .hbx, métadonnées .mdf).
Cela permet à SAS© de lire et écrire en parallèle depuis plusieurs nœuds, offrant des débits d'I/O bien supérieurs à un stockage disque classique, tout en gardant les données "accessibles" comme si elles étaient locales.
Ne faites pas d'ETL massif vers SAS©. Utilisez FedSQL et DS2 pour pousser la logique de traitement vers le cluster. Vous conserverez ainsi l'avantage du parallélisme Hadoop tout en codant depuis votre environnement SAS© familier.
