Was lernst Du über die Three-Stage-Architektur in Qlik?

Nach diesem Guide kannst Du:

1. Three-Stage-Architecture systematisch implementieren (Trennwandprinzip).
2. Die QVD-Strategie für jeden Layer (Staging, Transform, Model) optimieren.
3. Quality Gates und Data Quality Checks an der logisch richtigen Stelle platzieren.
4. Die Wartbarkeit Deiner Qlik-Anwendungen drastisch verbessern.

Zeitinvestment: 25 Min Lesen + 4 Std Hands-on
Quick Win: In 30 Minuten hast Du erste Layer strukturiert und die Abhängigkeiten klar getrennt.

Was ist das Prinzip der Separation of Concerns in der Three-Stage-Architektur?

Was sind die drei Stages und ihre Verantwortlichkeiten in Qlik?

Was ist die Staging Layer (Raw Extract) in der Three-Stage-Architektur?

Der Staging Layer ist das Tor zu den Quelldaten. Sein Hauptziel ist Geschwindigkeit und Sicherung.

//============================================
// STAGING LAYER: Rohdatensicherung
// Input: Datenbank/API/Filesystem | Output: STG_*.qvd
//============================================

STG_Sales:
LOAD
    OrderID,
    CustomerID,
    OrderDate, // Datum wird als Zahl geladen
    Amount
FROM; // Datenquelle

// Speichern: Schneller QVD Cache (Basis für Incremental Loading)
STORE STG_Sales INTO (qvd);
DROP TABLE STG_Sales;

Zentrale Regeln in Stage 1:

• 1:1 Mapping: Keine Berechnungen, keine `Date()`, `Year()` oder `If()`-Statements. Daten werden exakt so geladen, wie sie aus der Quelle kommen.
• Geschwindigkeit: Nach dem Initial Load erfolgt der Zugriff auf die Daten nur noch über die QVDs. Dies ist die Grundlage für maximale Ladeperformance.
• Checks: Hier finden nur strukturelle Quality Checks statt (Row Count, Dateizugriff).

Was ist die Transform Layer (Business Logic) in der Three-Stage-Architektur?

Dies ist das Herzstück des ETL-Prozesses, in dem die Daten in ein analytisches Format umgewandelt werden.

//============================================
// TRANSFORM LAYER: Business Logic
// Input: STG_*.qvd | Output: TRF_*.qvd
//============================================

TRF_Sales:
LOAD
    OrderID,
    CustomerID,
    // Datentransformationen: Hier werden Datumswerte formatiert
    Date(OrderDate) as OrderDate,
    Year(OrderDate) as Year,
    // Logik: Berechnung von Flags (Flag-based Modeling)
    If(Amount > $(vHighValueThreshold), 1, 0) as IsHighValue,
    // Quality Flags
    If(IsNull(CustomerID) OR Len(Trim(CustomerID)) = 0, 1, 0) as DQ_MissingCustomer

FROM (qvd); // Lade von Stage 1 QVD

// Speichern: Transformed QVD (Basis für das finale Modell)
STORE TRF_Sales INTO (qvd);
DROP TABLE TRF_Sales;

Zentrale Regeln in Stage 2:

• **Standardisierung:** Alle Datumsformate, Währungen und numerischen Felder werden hier vereinheitlicht.
• **Business Logic:** Alle komplexen `If()`, Feldkategorisierungen und Setzungen von **Quality Flags** (`DQ_MissingCustomer`) finden hier statt.
• **Unabhängigkeit:** Dieser Layer lädt **ausschließlich** von den `STG_*.qvd` Dateien.

Wie funktioniert die Model Layer (Dimensional Model) in der Three-Stage-Architektur?

Der Model Layer, oft als das finale Qlik Sense App-Skript ausgeführt, ist ausschließlich für das Erstellen des analytisch optimierten Datenmodells (typischerweise Star Schema) zuständig.

//============================================
// MODEL LAYER: Finales dimensionales Modell
// Input: TRF_*.qvd | Output: App-Memory
//============================================

// FACTS TABLE: Nur valide Daten laden und Felder auswählen
Facts_Sales:
LOAD
    OrderID,
    CustomerID,
    ProductID,
    Amount,
    IsHighValue
FROM (qvd)
WHERE DQ_MissingCustomer = 0 // Filtere fehlerhafte Daten
  AND DQ_InvalidAmount = 0;

// DIMENSIONS
Dim_Customer:
LOAD
    CustomerID,
    CustomerName,
    Country
FROM (qvd);

Zentrale Regeln in Stage 3:

• **Optimized Loads:** Es werden keine Transformationen mehr vorgenommen. Dies ermöglicht Optimized QVD Loads, was die Ladezeiten massiv reduziert.
• **Quality Filtering:** Hier wird die finale Datenselektion vorgenommen, indem fehlerhafte Records mittels der in Stage 2 erzeugten Quality Flags aussortiert werden.
• **Modell-Hygiene:** Hier liegt der Fokus auf der Vermeidung von Synthetic Keys und der korrekten Verknüpfung der Tabellen.

Wie sollte die Folder-Struktur und Naming Conventions gestaltet werden?

Eine klare Ordnerstruktur und Benennung ist essenziell für die Wartbarkeit des Three-Stage-Ansatzes.

QlikProject/
│
├── Source/         // Quelldateien (Stage 1 Input)
│
├── QVD/
│   ├── Staging/    // STG_*.qvd (Stage 1 Output / Stage 2 Input)
│   └── Transform/  // TRF_*.qvd (Stage 2 Output / Stage 3 Input)
│
└── Apps/           // QVF Applikationen (Stage 3 Skript)

Naming Conventions:

Welche Performance- und Wartungsvorteile bietet die Three-Stage-Architektur in Qlik?

Die Architektur bringt massive Vorteile in der Produktion:

✓ Stabilität: Wenn sich die Quelldatenbank ändert (Stage 1), muss nur der Staging Layer angepasst und neu geladen werden. Stage 2 und 3 können die Transformation mit den gesicherten `STG_*.qvd` Dateien fortsetzen.

✓ Effizienz: Fehlerhafte Transformationen (Stage 2) erfordern keine erneute, langsame Datenbankabfrage, da die Rohdaten bereits im schnellen QVD-Cache (Stage 1) liegen. Dies beschleunigt das Debugging enorm.

✓ Wiederverwendung: Die `TRF_*.qvd` Dateien (Stage 2 Output) können als zentrale, bereinigte Datenquelle für Dutzende von finalen Qlik-Apps dienen. Ein `TRF_Customer.qvd` muss nur einmal transformiert werden, kann aber von jeder App geladen werden.

Wie optimiere ich QVD pro Layer in der Three-Stage-Architektur?

Die Performance im Model Layer hängt stark davon ab, wie die `TRF_*.qvd` Dateien geladen werden:

Wie funktioniert das Model: Optimized Load (100x schneller) in der Qlik-Architektur?

Da der Model Layer keine Transformationen oder Berechnungen durchführt, sollte er QVDs immer im *Optimized Mode* laden.

// Optimized QVD load (sehr schnell!)
Dim_Customer:
LOAD CustomerID, CustomerName
FROM (qvd); 
// Funktioniert nur, wenn keine Berechnungen oder Transformationen in dieser LOAD-Anweisung stehen.

Wenn Sie im Model Layer Transformationen benötigen (z.B. eine Berechnung mit `If()`), wird der Load **Non-Optimized** und damit viel langsamer. Das Ziel ist es, solche Operationen in Stage 2 zu halten.

Was sind Quality Gates pro Layer in der Three-Stage-Architektur?

Dank der klaren Trennung können Quality Gates exakt dort platziert werden, wo sie am meisten Sinn machen:

// STAGING: Strukturelle Checks und Error Recovery
CALL CheckFileExists('SourceSales.csv');
CALL CheckRowCount('STG_Sales', 1000); // Siehe Error Handling

// TRANSFORM: Business Rules und Datenbereinigung
CALL CheckQuality('TRF_Sales', 'DQ_MissingCustomer'); // Siehe Data Quality Gates
CALL CalculateQualityScore('TRF_Sales');

// MODEL: Modell-Hygiene
CALL CheckOrphanedRecords('Facts_Sales', 'CustomerID');
CALL CheckSyntheticKeys; // Prüft auf Datenmodell-Probleme

Was sind die Best Practices für die Three-Stage-Architektur in Qlik?

✓ Layer Separation:

• [ ] Staging = Raw Extract (kein `Date()`, `If()`).
• [ ] Transform = Business Logic und Quality Flags.
• [ ] Model = Star Schema, Optimized Loads.

✓ Naming & Structure:

• [ ] Konsistente Verwendung der Prefixes `STG_`, `TRF_`, `Facts_`, `Dim_`.
• [ ] Separate QVD-Ordner (`/Staging/` und `/Transform/`).

✓ Dependencies (Abhängigkeiten):

• [ ] **Niemals** eine «Skip-Layer» Dependency (z.B. Model lädt direkt von der Quell-CSV oder von `STG_*.qvd`).
• [ ] `TRF_` darf nur von `STG_` laden. `Model` darf nur von `TRF_` laden.

Wie kann ich bei der Three-Stage-Architektur in Qlik Probleme beheben?

Was sind die nächsten Schritte in der Three-Stage-Architektur in Qlik?

Die Three-Stage-Architektur ist die Basis für alle skalierbaren Qlik-Lösungen! Als nächstes vertiefen wir uns in die Details:

1. Datensicherheit: Die Zugriffsbeschränkung auf die App-Ebene. Lese dazu den nächsten Artikel: Section Access.

2. Performance Tuning: Erfahre, wie man die QVD-Optimierung maximiert und welche weiteren Performance-Strategien (wie Best Practices) man im Three-Stage-Modell anwendet.