Articles avec le tag ‘optimisation’

Limiter les étapes DATA

Dans la série optimisation et tuyaux, voici le premier d’une série de conseil pour l’optimisation de vos programme SAS.

Pour des raisons de simplification et de méconnaissance du produit SAS, nous avons tous débuté en créant une multitude d’étape data inutiles. Ces étapes sont coûteuses aussi bien en terme de CPU qu’en terme d’I/O (accès disques entrée/sorties ou Input/Output).

Quand une table est d’une grande volumétrie, essayez de ne la lire qu’une seule fois et de créer toutes les tables dépendantes en un seul passage, vous gagnerez toutes les lectures successives de cette table SAS.

/* ****************************************** */
/* Site : http://www.formations-sas.fr - 2009 */
/*                                            */
/* Tuyaux - Performances, Optimisation SAS    */
/* GAIN : CPU - IO                            */
/*                                            */
/* Auteur : Pascal MAUBERT                    */
/* ****************************************** */

/* ACCEPTABLE */
data tablea;
 set db.master;
 if flag1;
run;

data tableb;
 set db.master;
 if flag1 and age < 21;
run;

data tablec;
 set db.master;
 if flag1 and age >= 21;
run;

/* PLUS EFFICACE */
data tablea tableb tablec;
 set db.master;
 if flag1 then do;
    output tablea;
    if age < 21 then output tableb;
    else             output tablec;
 end;

run;

/* ****************************************** */
/* Site : http://www.formations-sas.fr - 2009 */
/* Auteur : Pascal MAUBERT                    */
/* ****************************************** */

SAS Optimisation Transaction Ajout et Mise à jour

Avant propos

Cet article à pour de présenter une démarche d’optimisation pour un traitement de type Transaction pour l’ajout ou la mise à jour de données SAS.

Ce genre de problématique étant récurrent, il m’a semblé utile de vous fournir l’exemple détaillé ci-dessous.

Cet exemple se base sur des faits réels rencontrés lors d’une mission d’optimisation pour le compte du client « La Redoute », lors de mon passage au service Consulting de chez SAS Institute. Le chiffres fournis sont approximatifs et n’engage en rien la responsabilité de qui que ce soit.

Problème :

Redoute : 25 000 000 de lignes de commandes par jour et un temps de traitement sous SAS MVS avoisinant les 22 heures.

Bien sur, panique et demande d’intervention pour un audit d’optimisation.

Étude cynématique : par téléphone, par courrier et par internet réception des lignes de commande stockées dans DB2. La nuit Unload DB2 vers un fichier plat pour incorporation dans SAS. Lecture des lignes de commandes, tentative de mise à jour de la base SAS avec les lignes de commandes et en cas de rejet ajout de celles-ci dans la base SAS. Temps de traitement abominable.

Synthèse des Solutions

Deux cas se présentent :

1. On connait sous DB2 la nature de la transaction « ligne de commande » ajout ou modification
2. On ne la connait pas

Dans ces deux cas une solution performante existe.

La première la plus simple, ne sera pas détaillé dans cet article, simplement on transmet issu de DB2 dans l’unload une variable de type flag avec A pour ajout et M pour mise à jour. Sous SAS on éclate le fichier en deux tables SAS une pour les ajouts qui seront traités par la PROC APPEND et l’autre pour les mises à jour qui seront traités avec une étape DATA / MERGE.

Pour le deuxième cas un peu plus pointu, voici ci-dessous un exemple de programme Lire la suite de cette entrée »