📚 Qlik Sense Kurs – Artikel 2 von 28

← Vorheriger Artikel: Daten in Qlik laden – Alle Quellen erklärt
→ Nächster Artikel: JOINs vs KEEPs – Wann was verwenden

Was kann man in 12 Minuten über Load-Strategien lernen?

Nachdem Sie Daten aus externen Quellen geladen haben, beginnt die eigentliche Arbeit: die Transformation. Dieser Guide zeigt Ihnen, wie Sie Daten, die sich bereits im Qlik-Speicher befinden, weiterverarbeiten können.

1. RESIDENT Loads für schrittweise Transformationen einsetzen und so sauberen, wartbaren Code schreiben.
2. PRECEDING Loads für kompakte, verschachtelte Berechnungen verwenden und ihre Grenzen verstehen.
3. Die performance-optimale Strategie für Ihre Datenmenge und Komplexität wählen.

Zeitinvestition: 12 Min Lesen + 1.5 Std Hands-on
Voraussetzung: Grundlagen des Datenladens verstanden
Quick Win: In 10 Minuten einen robusten, mehrstufigen RESIDENT Load implementieren

Wie starte ich meinen ersten RESIDENT Load?

Das Problem: Sie haben rohe Verkaufsdaten geladen. Die Datenformate sind falsch, und es gibt überflüssige Leerzeichen. Sie müssen die Daten bereinigen und dann neue Felder für die Analyse ableiten.

Die Lösung: Ein mehrstufiger Ansatz (Staging) mit RESIDENT. Stellen Sie es sich wie eine Fertigungsstraße vor: Jeder LOAD-Block ist eine Station mit einer spezifischen Aufgabe.

1. Station 1: Die Rohdaten aus der Datei laden.
2. Station 2: Eine bereinigte Version der Daten erstellen, indem Sie aus der Rohdatentabelle lesen (RESIDENT).
3. Station 3: Die bereinigten Daten als Quelle nutzen, um neue Felder (z.B. Jahr, Kategorie) zu berechnen.
4. Aufräumen: Die nicht mehr benötigten Zwischentabellen löschen.

Zuerst laden wir die Rohdaten. Diese Tabelle dient nur als Ausgangspunkt.

RawSales:
LOAD *
FROM [lib://DataFiles/sales_raw.csv]
(txt, utf8, embedded labels, delimiter is ';');

Jetzt beginnt die Transformation. Wir erstellen eine neue Tabelle CleanSales, indem wir aus der bereits geladenen Tabelle RawSales lesen. Hier bereinigen wir Formate und entfernen Leerzeichen.

CleanSales:
LOAD
    OrderID,
    Trim(CustomerName) as CustomerName,
    Date(Date#(OrderDate, 'DD.MM.YYYY')) as OrderDate,
    Num(Replace(Amount, ',', '.'), '#.##') as Amount
RESIDENT RawSales;

Im letzten Schritt lesen wir aus unserer sauberen Tabelle CleanSales und fügen die finale Business-Logik und neue Analysefelder hinzu.

EnrichedSales:
LOAD
    *,
    Year(OrderDate) as OrderYear,
    Month(OrderDate) as OrderMonth,
    If(Amount > 1000, 'High', 'Standard') as OrderCategory
RESIDENT CleanSales;

Um den Speicher zu schonen und das Datenmodell übersichtlich zu halten, löschen wir die Zwischentabellen, die wir nicht mehr benötigen.

DROP TABLES RawSales, CleanSales;

Erklärung:

• RESIDENT: Der Schlüsselbefehl. Er weist Qlik an, Daten nicht aus einer externen Datei, sondern aus einer bereits im Arbeitsspeicher vorhandenen Tabelle zu laden.
• Staging-Ansatz: Jeder Schritt ist logisch getrennt. Das macht das Skript extrem gut lesbar, wartbar und einfach zu debuggen.
• DROP TABLES: Ein essenzieller Befehl, um die «Baugerüste» (Ihre Zwischentabellen) nach getaner Arbeit zu entfernen.

Checkpoint: Existiert in Ihrem Datenmodell nur noch die finale Tabelle EnrichedSales mit allen neuen Feldern? Perfekt!

Welche Load-Strategie für Ihr Projekt?

Die Wahl der richtigen In-Memory-Ladestrategie ist ein Kompromiss zwischen Komplexität, Wartbarkeit und Performance.

Was sind die Load-Strategien: RESIDENT, PRECEDING und INLINE?

Was sind Multi-Step Transformationen in den Load-Strategien?

RESIDENT ist die bevorzugte Methode für alle nicht-trivialen Transformationen. Indem Sie den Prozess in logische Stufen unterteilen, bleibt Ihr Code auch bei hoher Komplexität verständlich.

• Stage 1 (Raw): Laden der Daten «as is» aus der Quelle. Keine Transformationen.
• Stage 2 (Clean): Technische Bereinigung. Hier werden Datentypen korrigiert, Schlüssel standardisiert, Nullwerte behandelt und Qualitäts-Flags gesetzt.
• Stage 3 (Final/Enrich): Anreicherung mit Business-Logik. Hier werden Kennzahlen berechnet, Segmentierungen vorgenommen und Analysefelder erstellt.

Dieses Beispiel zeigt eine typische, robuste ETL-Pipeline.

Raw_CustomerOrders:
LOAD * FROM [lib://DataFiles/customer_orders.csv]
(txt, utf8, embedded labels, delimiter is ';');

Clean_CustomerOrders:
LOAD
    OrderID,
    If(Len(CustomerID) = 0, 'UNKNOWN', CustomerID) as CustomerID,
    Trim(Upper(CustomerName)) as CustomerName,
    Date(Date#(OrderDate, 'DD.MM.YYYY')) as OrderDate,
    If(IsNum(Amount), Num(Amount, '#.##'), 0) as Amount,
    If(Amount > 0, 'Valid', 'Invalid') as QualityFlag
RESIDENT Raw_CustomerOrders
WHERE Not IsNull(OrderID);

Final_CustomerOrders:
LOAD
    *,
    Year(OrderDate) as OrderYear,
    Month(OrderDate) as OrderMonth,
    If(Amount > 1000, 'Premium', 'Standard') as CustomerSegment,
    Amount * 0.19 as VATAmount
RESIDENT Clean_CustomerOrders
WHERE QualityFlag = 'Valid';

DROP TABLES Raw_CustomerOrders, Clean_CustomerOrders;

RESIDENT Best Practices:

• Klare Staging-Stufen: Benennen Sie Ihre Tabellen mit Präfixen (Raw_, Clean_, Final_).
• Früh filtern: Schließen Sie ungültige Daten (WHERE-Klausel) so früh wie möglich aus, um die Performance der nachfolgenden Stufen zu verbessern.
• DROP nicht vergessen: Am Ende darf nur das finale Datenmodell übrig bleiben.

Was sind PRECEDING Loads und wie funktionieren sie?

Wie funktioniert die Bottom-Up Verarbeitung in Load-Strategien?

Ein PRECEDING Load ist eine Kette von LOAD-Anweisungen ohne FROM oder RESIDENT. Die Verarbeitung erfolgt von unten nach oben.

Analogie einer Fabrik:

1. Unterster LOAD (Erdgeschoss): Die Rohmaterialien werden geladen und eine erste Berechnung durchgeführt (z.B. Gesamtumsatz).
2. Mittlerer LOAD (1. Stock): Das Ergebnis aus dem Erdgeschoss wird entgegengenommen und weiterverarbeitet (z.B. laufende Summe berechnen).
3. Oberster LOAD (2. Stock): Das finale Produkt wird aus den Ergebnissen des 1. Stocks erstellt (z.B. prozentualen Anteil berechnen).

Dieses Beispiel berechnet eine laufende Summe (RunningTotal) und deren prozentualen Anteil am Gesamtumsatz.

SalesAnalysis:
LOAD
    OrderID, Amount, RunningTotal,
    RunningTotal / TotalSales as PercentageOfTotal;
LOAD
    OrderID, Amount, TotalSales,
    RangeSum(Above(Amount, 0, RowNo())) as RunningTotal;
LOAD
    OrderID, Amount,
    Sum(TOTAL Amount) as TotalSales
RESIDENT SourceOrders
ORDER BY OrderDate;

PRECEDING ist mächtig, aber gefährlich: Der Code ist zwar kompakt, aber extrem schwer zu debuggen, da man die Zwischenergebnisse der einzelnen Ebenen nicht sehen kann. Verwenden Sie es sparsam und nur, wenn Sie genau wissen, was Sie tun.

Was sind INLINE Loads und wie nutze ich sie für statische Daten und Tests?

Mit INLINE können Sie kleine Tabellen direkt in Ihr Skript schreiben. Es ist perfekt für Daten, die nicht in externen Dateien existieren, aber für das Modell benötigt werden.

Eine Mapping-Tabelle zur Zuordnung von Ländern zu Regionen.

RegionMapping:
MAPPING LOAD * INLINE [
Country, Region
Germany, DACH
Austria, DACH
USA, Americas
];

Eine Konfigurationstabelle, um Parameter an einer zentralen Stelle zu verwalten.

Config:
LOAD * INLINE [
Key, Value
VAT_Rate, 0.19
Sales_Threshold, 1000
];

Testdaten, um Ihre Transformationen schnell zu entwickeln, ohne die komplette Datenmenge laden zu müssen.

TestOrders:
LOAD * INLINE [
OrderID, CustomerID, Amount
T001, C001, 1500.50
T002, C002, 750.25
];

Wie optimiere ich die Performance mit Load-Strategien: RESIDENT, PRECEDING, INLINE?

Wie funktioniert das Memory-Management bei RESIDENT Loads?

Jede RESIDENT-Tabelle belegt zusätzlichen Arbeitsspeicher. Bei großen Datenmengen ist es entscheidend, nicht mehr benötigte Tabellen sofort zu löschen.

Schlecht: Alle Tabellen werden bis zum Ende des Skripts im Speicher gehalten. Dies kann zu einem «Out of memory»-Fehler führen.

RawData: LOAD * FROM source.csv;
CleanData: LOAD * RESIDENT RawData;
EnrichedData: LOAD * RESIDENT CleanData;

Besser: Jede Zwischentabelle wird sofort nach ihrer Verwendung gelöscht. Der Speicher wird freigegeben und kann für den nächsten Schritt genutzt werden.

RawData: LOAD * FROM source.csv;

CleanData: LOAD * RESIDENT RawData;
DROP TABLE RawData;

EnrichedData: LOAD * RESIDENT CleanData;
DROP TABLE CleanData;

Wie funktioniert eine QVD-basierte Staging-Pipeline für große Datenmengen?

Für sehr große Datenmengen (>10 Mio. Zeilen) ist die rein speicherbasierte RESIDENT-Verarbeitung riskant. Die Enterprise-Lösung besteht darin, das Ergebnis jeder Stufe in eine schnelle QVD-Datei zu schreiben. Die nächste Stufe liest dann aus dieser QVD.

Vorteile:

• Minimaler Speicherbedarf: Es ist immer nur eine Tabelle gleichzeitig im Speicher.
• Wiederanlauffähig: Wenn das Skript in Stufe 3 fehlschlägt, können Sie es ab Stufe 3 neu starten, ohne die ersten beiden Stufen erneut ausführen zu müssen.
• Transparenz: Sie können die QVD-Zwischenergebnisse zur Fehlersuche analysieren.

STORE RawData INTO [lib://Staging/01_Raw.qvd] (qvd);
DROP TABLE RawData;

CleanData:
LOAD * FROM [lib://Staging/01_Raw.qvd] (qvd);
STORE CleanData INTO [lib://Staging/02_Clean.qvd] (qvd);
DROP TABLE CleanData;

FinalData:
LOAD * FROM [lib://Staging/02_Clean.qvd] (qvd);

Wie behebe ich Probleme mit Load-Strategien: RESIDENT, PRECEDING oder INLINE?

Was bedeutet die Fehlermeldung „Table not found“ bei RESIDENT?

Problem: Der häufigste Fehler. Er tritt auf, wenn Sie versuchen, von einer Tabelle zu laden, die nicht (mehr) existiert.

Ursachen:

1. Ein Tippfehler im Tabellennamen.
2. Sie haben die Tabelle in einer vorherigen Zeile bereits mit DROP TABLE gelöscht.

Verwenden Sie TRACE, um zu prüfen, welche Tabellen zum Zeitpunkt des Fehlers im Speicher verfügbar sind.

FOR i = 0 to NoOfTables() - 1
    TRACE 'Table $(i): $(TableName($(i)))';
NEXT i

Was sind die nächsten Schritte im Kurs zu Load-Strategien?

Als nächstes: JOINs vs KEEPs – Wann was verwenden

Verwandte Themen:

• Daten in Qlik laden – Alle Quellen erklärt
• Mapping Tables vs JOINs – Performance-Optimierung
• Daten transformieren – String, Math, Date Functions
• QVD-Optimierung – 100x schnellere Loads