Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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 ;
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
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?
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
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
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