Qlik Community

New to QlikView

Discussion board where members can get started with QlikView.

Announcements
Modernize Your QlikView Deployment webinar, Nov. 3rd. REGISTER
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor

Load-Statement Dynamisch erstellen um Ladezeit zu verringern

Hallo,

ich bin ziemlich neu dabei, habe eine Designer & Developer Schulung hinter mir und versuche mich nun selbst. 🙂

Ich nutze gerade eine QVD die von unserem Dienstleister erstellt worden ist. Diese Datei enthält beim Laden ohne Einschränkung 205.196.927 Zeilen (in meiner jetzigen Test-App). Die Daten werden stetig mehr. In dieser QVD befinden sich auch einige Zeitstempel (zB genaues Datum, nur das Jahr, nur die Kalenderwoche, usw).

Mein Ziel ist es eigentlich, dass ich eine Anzeige darüber erhalte was in den letzten drei vergangenen (also abgeschlossenen) Monaten passiert ist. Alle späteren Belege (Zeilen) möchte ich gar nicht geladen haben. Jedoch soll das natürlich dynamisch erfolgen.

Hat hier jemand einen Tipp für mich zur Einschränkung? Geht das schon direkt im Load-Befehl der genannten QVD?

Labels (1)
6 Replies
Highlighted
Partner
Partner

entweder beim Laden der Daten aus der qvd oder schon von der Datenbank den Zeitraum der zu ladenden Daten einschränken.

Beim laden von einer qvd wäre das

where Datum >= date(monthstart(addmonths(today(),-3))

( and Datum < date(monthstart(today())) falls der aktuelle Monat nicht mitgeladen werden soll.

Bei select auf die Datenbank kommt es auf sen sql-dialekt darauf an wie genau der Sytnax aussieht.

Gruss

Highlighted
MVP & Luminary
MVP & Luminary

Eine Alternative könnte hier sein, nicht mit so einer großen QVD zu hantieren, sondern diese Daten in Monatsscheiben wegzuschreiben - und sich dann die entsprechenden Zeiträume rauszupicken.

Ansonsten kann man, wie schon erwähnt, eine entsprechende where-clause einsetzen, wobei bei einer so großen QVD möglicherweise ein where exists(Datum); besser wäre, da so ein Load (sofern keine weiteren Transformationen vorgenommen werden) "optimized" wäre.

Die benötigten Datumswerte  kann man sich ganz einfach selbst generieren. Hier mal ein Beispiel von mir, dass alle Datumswerte ab 2015 bis gestern generiert:

DatesForExists: load date(42005 + recno() - 1) as [%Datum] autogenerate today() - 1 - 42005 + 1;

- Marcus

Highlighted
Contributor
Contributor

Hallo Marcus,

die Idee mit der Datenmodellierung habe ich schon verfolgt bzw. bin dabei 🙂

Meine Idee war, dass ich die dynamische Formel nun als QVD exportiere. Bei drei abgeschlossenen Monaten belaufen sich die Daten auf ca. 55.000.000 Datensätze. Allerdings werden diese tatsächlich auch benötigt für das eigentliche Ziel der App.

VG

 

Highlighted
MVP & Luminary
MVP & Luminary

Wenn mehrere QVD's auf einmal bzw. innerhalb einer Logik erstellt werden sollen, benötigt man einen Loop, der n Mal die Daten einlädt und dann entsprechend wegschreibt. Hier mal ein ganz simples Beispiel mit 12 Monaten:

for i  1 to 12
   temp: load $(i) as Monat autogenerate 1;
   table: load * from QVD where exists(Monat);
   store table into QVD_&$(i).qvd (qvd);
   drop tables temp, table;
next

Schöne Grüße
Marcus

Highlighted
Contributor
Contributor

Ich habe es nun tatsächlich hinbekommen die genannte QVD von 11,3 GB auf knapp 3 GB zu verkleinern.

Allerdings würde ich jetzt gerne noch eine kleinere erstellen, weil dort noch viele unrelevante Spalten in der Tabelle existieren. Allerdings ist der Store-Befehl in der Schulung nicht angewandt worden daher probiere ich nur herum.

Kannst Du ggf. meinen Fehler sehen?

clipboard_image_0.png

 

Highlighted
MVP & Luminary
MVP & Luminary

Man muss die Daten zuerst einladen und kann sie erst dann speichern, also:

t: load F1 as F10, F2 as F11, ... from file.qvd (qvd);
store t into file2.qvd (qvd);

Man kann hierbei die Felder beim Load umbenennen, in einem folgenden rename-statement oder dann auch beim store-statement.

Alles was man nicht an Felder/Datensätzen braucht sollte man auch nicht einladen und/oder speichern bzw. vielleicht auch in zwei/drei verschiedene, für bestimmte Zwecke spezialisierte Varianten.

Bei der Anzahl der Datensätze sollte man aber auch schauen, was da alles für Daten drin sind. Vorhin war die Rede von Datum, Jahr, Monat usw. - vom Grundsatz her sind das redundate Daten, da sich Jahr und Monat aus dem Datum ableiten lassen und in der Regel eh per Master-Kalender im Datenmodell vorgehalten werden. Das meint grundsätzlich reicht das Datum - ich habe als Ausnahme in vielen meiner Files auch noch die Periode, wie 201910 drin, da hierüber viele inkrementelle Prozesse laufen.

Sofern das Datum auch kein Datum, sondern ein Zeitstempel ist, sollte diese in Datum und Zeit aufgetrennt werden - das aber besser bereits in den Quelldaten, da spreche mal Euren Dienstleister an.

- Marcus