Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Calcul d'indicateur Expression

Bonjour,

Ma question porte sur la manière de pouvoir effectuer des calculs avec le champ 'Indicateur_C'.

En effet sur l'ensemble de ma table, la sum(Indicateur_C) me donne 1110 alors que voudrais obtenir 6960.

Je me pose cette question, car aujourd'hui, j'ai une table ".txt" qui possède plus de 700 champs (150 dimensions et 550 faits) et plus de 7 millions de lignes à importer dans QlikView.

Ne pouvant pas charger la table entièrement, je vais devoir optimiser la phase de chargement en créant des clés composites

Par contre, comment retrouver les résultats de mes calculs?

Merci par avance.

Cordialement.

Pour illustrer la problématique voici un script :

DATA: LOAD * INLINE [

    ID, A, B, C

    1, 111, A, 10

    2, 111, A, 1000

    3, 111, A, 100

    4, 111, BB, 100

    5, 111, BB, 10

    6, 111, BB, 100

    7, 111, BB, 1000

    8, 111, BB, 10

    9, 2222, CCC, 1000

    10, 2222, CCC, 100

    11, 2222, CCC, 100

    12, 33, CCC, 10

    13, 33, CCC, 100

    14, 33, CCC, 1000

    15, 33, CCC, 10

    16, 33, CCC, 1000

    17, 33, D, 100

    18, 33, D, 100

    19, 33, D, 10

    20, 33, D, 100

    21, 33, D, 1000

];

A:

LOAD

   distinct A as Libelle_A,

   autonumber(A) as ID_A

RESIDENT

DATA;

B:

LOAD

   distinct B as Libelle_B,

   autonumber(B) as ID_B

RESIDENT

DATA;

C:

LOAD

   distinct C as Indicateur_C,

   autonumber(C) as ID_C

RESIDENT

DATA;

TABLE:

LOAD

autonumber(A) as ID_A,

autonumber(B) as ID_B,

autonumber(C) as ID_C,

ID,

1 as compteur

RESIDENT

DATA;

drop table DATA ;

5 Replies
Not applicable
Author

Bonjour

pourquoi n'est-il pas possible de charger 7 millions de lignes?

Peut-être l'optimisation réside-t-elle dans les champs à charger. Tous sont nécessaires?

sinon le fait de faire un distinct réduit bien évidemment les valeurs à une vision unique alors dans ce cas peut-être vaut-il mieux faire une somme par group by (ce qui limite le volume et conserve les quantités) mais comme je ne connais pas les contraintes du modèle et la nécessité du ID je ne peux pas dire sur quoi le grouper (champ B ?)

cordialement

Christian

Not applicable
Author

Bonjour,

Merci pour votre réponse,

Au départ , le fichier '.txt' possédait plus de 1500 champs...

En échangeant avec les équipes métiers, je me suis rendu compte que l'on avait pas besoin de la totalité des champs.

Effectivement, j'ai donc fais un focus que sur les variables nécessaires à l'analyse.

Par contre, je devrais charger les 7 millions de lignes.

J'avais pensé à la solution du 'group by', malheureusement je perdrais la granularité de mes données.

Il n'est pas possible d'avoir un résultat correspondant à la somme de l'ensemble de Indicateur_C comme si j'avais gardé mon fichier à plat?

Brice-SACCUCCI
Employee
Employee

Bonjour,

je ne comprends pas votre approche des chargements DISTINCT. Vous perdez toute l'information en faisant ça, et il est normal que votre somme ne soit pas totale.

Il ne faut pas chercher à réduire le nombre de valeurs car QlikView utilise une base vectorielle qui ne stocke qu'une seule fois chaque valeur distincte. Même si la valeur "1000" est présente 1000000 fois, elle ne sera stockée qu'une seule fois en mémoire !

Ma solution à votre cas précis, qui ne reflète sûrement pas l'intégralité de votre problème :

Faire un seul LOAD (pas besoin d'avoir plusieurs tables, c'est même moins performant sur de la grosse volumétrie) :

LOAD

   ID,

   A as Libelle_A,

   autonumber(A) as ID_A,

   B as Libelle_B,

   autonumber(B) as ID_B,

   C as Indicateur_C,

   autonumber(C) as ID_C

RESIDENT

DATA;

Pour les sommes, utiliser SUM(Indicateur_X).

Pour le comptage : COUNT(DISTINCT ID). Contrairement à l'idée que s'en font beaucoup de personnes, c'est plus optimal que SUM(Compteur), cf. l'article de notre blog :

http://community.qlik.com/blogs/qlikviewdesignblog/2013/10/22/a-myth-about-countdistinct

Merci,

Brice

Not applicable
Author

Bonjour,

Merci pour ce complément d'information.

Je me suis posé ces questions surtout du fait qu'un seul LOAD à partir du fichier .txt (27Go) pour le transformer directement en .QVD fait saturer mon poste donc la configuration est la suivante:

CPU : Quad 2.67 Ghz Intel Xeon® X5650

Memory : 24576MB

OS Version : Windows 2008 R2

Service Pack : Service Pack 1

En faisant des clés composites pour les dimensions et également pour les faits, je pensais pouvoir réduire mes données.

Par exemple, j'ai certains champs qui sont renseignés par 20 occurrences différentes réparties sur 7 millions de lignes. C'est pour cela que j'utilise le DISTINCT.

J'ai pensé qu'il valait mieux avoir une petite table avec 20 valeurs différentes avec une clé composites que 20 valeurs distinctes répétés X fois sur l'ensemble de mes 7 millions enregistrements.

Je ne suis pas sûr de ma méthode. Pourtant en faisant cela, j'ai réussi à charger l'ensemble de mes données.

Il doit y avoir une autre méthode plus robuste pour répondre à mon problème? Ou sinon demander beaucoup plus de RAM pour charger le tout.

Bien cordialement,

Willy

Brice-SACCUCCI
Employee
Employee

Dans votre cas, la clé est, à mon avis, de réduire le nombre de colonnes. Dans l'idéal, le fichier source ne doit pas contenir de colonnes superflues.

Une seule table avec des valeurs répétées donnera de meilleures performances que plusieurs tables.

La répétition des valeurs n'a aucun impact sur l'empreinte mémoire.

Si possible, cherchez à générer le QVD sur une machine avec plus de mémoire et travaillez sur votre poste directement à partir du QVD. Vous y gagnerez grandement, surtout s'il y a énormément de valeurs redondantes (20 valeurs différentes sur 7 millions de lignes = pouvoir de compression énorme pour QlikView ).

Si ce n'est pas possible, découpez le fichier en plusieurs morceaux et transformez-les 1 par 1 en QVD. Vous pourrez ensuite facilement concaténer les QVD en les chargeant tous dans QlikView et en re-stockant le résultat dans un QVD).

Merci,

Brice