Bereinigen Sie dieselben Daten in jedem Qlik Ladeskript erneut?

Dieselben Mapping Loads, String Korrekturen und Deduplizierungen werden in jeder App und jeder QVD Schicht neu geschrieben, und die Kopien laufen auseinander. Die Bereinigung wiederholt sich pro Skript, weil keine integrierte Warehouse Schicht sie einmal erledigt.

Bereinigen Sie dieselben Daten in jedem Qlik Ladeskript erneut?

Die Data Warehouse Automation Plattform, der Datenteams aus vielen Branchen vertrauen

Petr Beles Petr Beles Co-Founder · Veröffentlicht in Lösungen für BI Tool Herausforderungen LinkedIn

Kommt Ihnen das bekannt vor?

  • Dieselbe ApplyMap und Trim Logik steht in mehreren Ladeskripten, und die Kopien stimmen nicht mehr überein.
  • Ein neuer Ländercode in der Quelle bedeutet, die Mapping Tabelle in jeder App anzupassen, die sie nutzt.
  • Zwei Apps zeigen unterschiedliche Kundenzahlen, weil sie dieselbe Quelle unterschiedlich deduplizieren.
  • Niemand weiß sicher, welches Skript die aktuelle Version einer Bereinigungsregel enthält.

Eine App, die Rohdaten bereinigt, ist ein Workaround. Zehn Apps, die dieselben Rohdaten bereinigen, jede ein bisschen anders, sind ein zweites Warehouse, das niemand entworfen hat.

Wo dieselbe Bereinigung erneut geschrieben wird

  • Jede App kopiert das Mapping. Dasselbe MAPPING LOAD und ApplyMap für Länder, Produkt und Kundencodes, eingefügt in jedes Skript, das das Feld braucht.
  • Jede Kopie driftet. Ein Skript trimmt und schreibt groß, ein anderes nicht, ein drittes hat letzten Monat einen neuen Code ergänzt. Dasselbe Feld, unterschiedliche Werte.
  • Jede QVD Schicht wiederholt es. Extract, Transform und QVD Generator Apps bereinigen die Daten, und die nächste App bereinigt sie sicherheitshalber noch einmal.
  • Jede Änderung ist eine Suche. Ein neuer Quellcode muss in jedem Skript gefunden und korrigiert werden, und das übersehene scheitert still.

Eine $(Include) Datei hält den Text identisch. Sie hindert aber keine App daran, selbst zu entscheiden, ob, wann und in welcher Reihenfolge sie ihn verwendet.

Warum es bei Ihnen landet

  • Jede App wurde gebaut, als sie gebraucht wurde, und die Korrekturen aus dem letzten Skript zu kopieren war der schnellste Weg zur Lieferung.
  • Niemand besitzt die Regel, also bemerkt niemand, wenn zwei Skripte anfangen, sich zu widersprechen.
  • Sie können die Skripte angleichen, die Sie pflegen. Dass die Quelle Rohdaten an alle schickt, können Sie nicht verhindern.

Die Arbeit passiert am falschen Ort

  • Quelldaten zu bereinigen ist Warehouse Arbeit. In Qlik wird sie in jedem Ladeskript neu geschrieben, das das Feld berührt.
  • Sie gehört an einen zentralen Ort: ein Data Warehouse oder einen Data Hub, einmal gebaut und von jeder App gelesen.
  • Wenn das teuer klingt, geht die Schätzung vermutlich von handgebauten Pipelines aus. Eine spezialisierte Automatisierungsplattform generiert sie aus einem Modell. Das ändert Kosten und Dauer.

Was sich ändert, wenn das Modell fertig ankommt

Datavault Builder generiert den integrierten, historisierten Vault und die dimensionale Schicht darüber, nativ in der Datenbank, die Sie bereits betreiben, von SQL Server und Azure SQL bis Snowflake oder BigQuery.

  • Jede Bereinigungsregel wird einmal definiert, ein Code Mapping ändert sich also an einer Stelle, nicht in jedem Skript.
  • Duplikate werden bei der Integration aufgelöst, anhand von Business Keys statt per App gefiltert.
  • Historie liegt in Satelliten, kein QVD muss mehr die Version von gestern aufbewahren.
  • Das Ladeskript wird zu einem einfachen LOAD aus bereinigten Tabellen, kurz genug zum Lesen.
  • Lineage zeigt jede Transformation, eine geänderte Regel lässt sich also vor dem Deployment nachverfolgen.

Worum Sie bitten sollten

Nicht “das Transform Skript ist ein Chaos”, sondern:

“Wir bereinigen und mappen dieselben Quellfelder in mehreren QVD Generator Apps, und sie stimmen nicht mehr überein. Kann diese Bereinigung in einer integrierten Warehouse Schicht liegen, damit unsere Apps fertige Dimensionen statt Rohextrakte laden?”

Falls der Aufbau dieser Schicht nach einem Jahr Pipeline Arbeit klingt, geht die Schätzung von Handarbeit aus. Genau diesen Teil generiert Datavault Builder.

Sehen Sie es mit Ihren eigenen Daten

Buchen Sie eine kostenlose Demo und bringen Sie den Report mit, der Ihnen die meisten Probleme macht.

Kostenlose Demo buchen

In drei Schritten zu Zahlen, die aufgehen

  1. Bestehende Logik herauslösen

    Sammeln Sie Berechnungen, Joins und Filter, die heute in Ihren Reports stecken.

  2. An einem Ort zentralisieren

    Die Logik kommt einmal ins Warehouse Modell, und jeder Report liest dieselbe Definition.

  3. Zahlen, die aufgehen

    Jeder Report zeigt dieselbe Zahl, und “Woher kommt diese Zahl” hat eine sichtbare Antwort.

Wie Datavault Builder Ihrem Report ein fertiges Modell liefert

  • Das Modell kommt fertig an

    Datavault Builder generiert Vault und Star Schema so, dass sie nativ in der Datenbank laufen, die Sie bereits haben: SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks oder BigQuery.

  • Die Arbeit verlässt den Report

    Kein Merge, kein Parsen, kein Fuzzy Match. Diese Arbeit ist aus dem Report verschwunden.

  • Quellen kommen integriert an

    Kunden aus ERP, CRM und Webshop werden zu einem Satz konformer Dimensionen zusammengeführt. Der Join passiert einmal im Warehouse, nicht erneut in jedem Report.

  • Historie, die abfragbar ist

    Jede Änderung wird so festgehalten, wie sie eintrifft. Sie können den Stand von damals genauso auswerten wie den von heute, auch wenn das Quellsystem seine eigenen Sätze überschreibt.

  • Jede Zahl hat Lineage

    Die Logik bekommt Lineage. “Woher kommt diese Zahl” hat damit eine sichtbare Antwort.

  • Historisierung im Warehouse

    Historisierung übernimmt das Warehouse als Vault Satelliten, statt sie zu approximieren.

Ausgezeichnet von BARC im Data Fabric Survey 26

Sprechen Sie mit unserem Experten

Zwanzig Minuten mit unserem Sales Director und eine ehrliche Antwort, ob das zu Ihrer Situation passt.

Matt Collett

Matt Collett

Sales Director

Was suchen Sie?

Mit dem Absenden stimmen Sie unserer Datenschutzerklärung.

Weitere Probleme in dieser Serie

  • Zeigen Ihre Qlik Apps und Power BI Reports unterschiedliche Zahlen?

    Weder Qlik noch Power BI liegt falsch. Jedes Tool hat seine eigene Ladelogik, seine eigenen Definitionen und seine eigene Lineage, also wird dieselbe Kennzahl zweimal berechnet und niemand kann sie abgleichen. Die Regeln gehören in ein gesteuertes Warehouse Modell, das beide Tools lesen.

  • Sind Ihre Qlik Set Analysis Ausdrücke zu lang und zu langsam?

    Set Analysis ist präzise für echte Vergleiche. Die meisten langen Ausdrücke in Ihrer App stehen dort, weil das Modell nie Historie, Flags oder eine einheitliche Granularität geliefert hat, und das Diagramm baut sie bei jeder Selektion neu.

  • Erzeugen Ihre Qlik Apps immer wieder synthetische Schlüssel?

    Synthetische Schlüssel und zirkuläre Referenzen sind Qlik, das genau das verknüpft, was es bekommen hat. Sie entstehen, weil die Daten ohne konforme Dimensionen oder echte Schlüssel ankommen, und deshalb muss jede App sie selbst erfinden.