Blogs

Startseite / Blogs / F/A: Arbeiten mit dem High Volume Data Warehouse in Centerprise

Inhaltsverzeichnis
Die automatisierte, Kein Code Datenstapel

Erfahren Sie, wie Astera Data Stack kann die Datenverwaltung Ihres Unternehmens vereinfachen und rationalisieren.

Q / A: Arbeiten mit dem High Volume Data Warehouse in Centerprise

October 17th, 2022

Der erste in unserem Centerprise Best Practices-Webinar-Reihe diskutiert die Funktionen von Centerprise das macht es zur idealen Integrationslösung für das High Volume Data Warehouse. Zu den Themen gehören Datenqualität (Profilerstellung, Qualitätsmessungen und Validierung), Übersetzen von Daten in ein Sternschema (Beibehalten von Fremdschlüsselbeziehungen und Kardinalität bei sich langsam ändernden Dimensionen) und Leistung, einschließlich Abfragen von Daten mit datenbankinternen Verknüpfungen und Zwischenspeicherung. Wir haben die Fragen und Antworten unten gepostet, die sich mit einigen interessanten Themen befassen.

Bewältigen Sie große Datenmengen mit einem Data Warehouse.

F: Kann Data Profiling alleine stehen?

A: Ja, absolut. Genau das geschieht im unten gezeigten Beispiel für die Bestellanalyse. Wenn Sie sich die Ziele ansehen, schreibe ich nicht in ein Data Warehouse oder verschiebe keine Daten. Alles, was ich tue, ist das Erstellen von Berichten. Ja, Sie können diese Informationen als eigenständige Arbeit verwenden. In diesem Fall sammle ich Informationen zu diesem speziellen Schema

F: Können wir eine Reihe von Datenqualitätsregeln gruppieren und in mehreren Flows verwenden?

A: ja Wie unten gezeigt, können Sie mehrere Regeln erstellen und diese zu einer sinnvollen Komponente machen, indem Sie sie einfach per Drag & Drop in das Projekt ziehen. Sie können sehen, dass diese Datenprüfungskomponente dann zu einem ausgegrauten Feld wird und jetzt als Referenz dient. Wenn ich nun einen anderen Fluss habe, kann ich diese Datenprüfung verwenden, da sie als Referenz dient. Es ist eine sehr gute Praxis, dass Sie jedes Mal, wenn Sie etwas wiederverwendbar machen können, dies tun sollten. Sie werden sich in Zukunft danken.

F: Erläutern Sie, wie der Persistent Lookup Cache die Leistung verbessert

A: In dem folgenden Beispiel, das die Dimensionsproduktsuche verwendet, wird dies immer wieder verwendet, sodass Sie diese Dimensionstabelle nicht jedes Mal laden müssen. Sie können sehen, wo diese Dimensionstabelle Hunderttausende von Zeilen enthalten kann. Wenn Sie also jede einzelne Faktentabelle laden, müssen Sie alle Daten für eine Suche laden, die gesamte Verarbeitung, alle Daten Daten, die bei der Migration übertragen werden. wird nur in Lookups verbraucht werden. Also statt jetzt in Centerprise Sie können den Persistent Lookup Cache verwenden. Centerprise verfügt über eine integrierte Datenbank, in der diese Informationen gespeichert werden, die auf der Festplatte gespeichert sind, sodass Sie sich nicht um die Speicherbelegung kümmern müssen. Jedes Mal, wenn eine Suche dieses Label verwendet, wird dieser Cache abgerufen, anstatt eine Reise in die Datenbank durchzuführen. Der Zugriff auf die Datenbank ist ohnehin teuer, und immer und immer wieder zu einer sehr großen Tabelle zu recherchieren und alle Datensätze abzurufen, ist äußerst teuer und kann Ihren Prozess tatsächlich zum Erliegen bringen. Ich empfehle, den persistenten Cache immer dann zu verwenden, wenn Sie die Möglichkeit haben, dies zu tun.

F: Was sind die häufigsten Ursachen für Leistungsprobleme beim Laden von Data Warehouses, mit denen Benutzer konfrontiert sind? Centerprise?

A: Die häufigste Ursache für Leistungsprobleme mit Centerprise, wie bei jedem Datenintegration Programm, ist Datenvolumen – zu viele Lookups, insbesondere zu viele Lookups in einer Spalte. Im Beispiel unten sehen Sie, dass in der Faktentabelle alle Schlüssel eine Art Suche benötigen, und wenn Sie beispielsweise 10 Suchen direkt vor der Dimensionstabelle haben, muss jede dieser Suchen abgeschlossen werden, bevor der Datensatz eingefügt werden kann in eine Faktentabelle. Viele ineffiziente Suchen verlangsamen also den Datenfluss erheblich.

Ein zweites Problem, das die Leistung beeinträchtigen kann, ist die erste Abfrage. Die Lösung dieses Problems besteht darin, diese Abfragen zu parametrisieren. Dies kann auf verschiedene Arten erfolgen. Erstens können Sie Variablen verwenden, die von außen gesteuert werden. Wenn Sie beispielsweise über einen Workflow verfügen, der alle Ihre Datenflüsse auslöst, können Sie diesen Workflow für Datensätze für einen begrenzten Zeitraum festlegen, beispielsweise für eine Woche. Dadurch wird die Datenmenge, die zwischen der Quellendatenbank und Centerprise.

Eine dritte Option ist der Verwendung von Variablen sehr ähnlich, verwendet jedoch stattdessen eine inkrementelle Last basierend auf Überwachungsfeldern. Wenn Sie ein Feld haben, von dem Sie wissen, dass es bei jeder Änderung garantiert geändert wird, können Sie den Änderungsdatumskopf im Überwachungsfeld verwenden, wie im folgenden Beispiel gezeigt, und diese Informationen werden in einer Datei gespeichert.

Dann wird der Datenfluss zu einem späteren Zeitpunkt ausgeführt, dh er wird diese Datei abrufen und im Grunde dasselbe tun, wie Sie es in Ihrer "where-Klausel" definiert haben, dies wird jedoch automatisch in dieser "wo" -Datei ausgeführt. Der Vorteil ist, dass Sie die Variablen nicht nachverfolgen müssen. Der Nachteil ist, dass Sie jetzt eine inkrementelle Datei für jedes Objekt haben, aus dem Sie laden. Dies bringt den Punkt auf, dass Sie sogar möchten, dass die Quellen gemeinsam genutzte Aktionen sind. Auf diese Weise müssen Sie sie und ihre Prüffelder nicht mehr definieren.

F: Verwendet Constraint-Based Write automatisch die Reihenfolge des Schreibens

A: Ja, das stimmt. Es ist egal, in wie viele Tabellen Sie schreiben, solange sich diese in derselben Datenbank befinden. Sie wählen "Use-Constraint-Based Write" und wissen, in welcher Reihenfolge geschrieben werden soll. Es weiß, dass es zuerst den Kunden und dann den Kundenauftrag schreiben muss - es kümmert sich um die Reihenfolge der Vorgänge, die es für Sie schreibt.

F: Wie vergleicht der Diff Processor die Aufwärtsleistung?

A: Der Diff-Prozessor ist viel schneller als das Aufwachen. Upsert löst eine weitere Abfrage aus, um festzustellen, ob die Informationen vorhanden sind oder nicht, während der Diff-Prozessor alle Datensätze in Bündeln an das Zielsystem sendet. Sie werden dann in eine temporäre Tabelle geschrieben und verbunden. Dieser Vergleich findet auf der Datenbankseite statt auf der Seite statt Centerprise Seite, so dass große Blöcke auf der Datenbankseite vorbereitet werden, anstatt eine separate Abfrage zu verwenden, um herauszufinden, ob eine Einfügung oder Aktualisierung erforderlich ist. Grundsätzlich führt upsert jeweils einen Datensatz durch und Diff Processor vergleicht in Stapeln. Wir haben festgestellt, dass es um Größenordnungen schneller ist.

F: Unterstützen Sie das schnelle Laden von Teradata?

A: Ja, sowohl Fast Load als auch Multi Load werden unterstützt Teradata. Schnellladen wird automatisch verwendet, wenn Sie in eine leere Tabelle schreiben.

 

Sie können auch mögen
Datenfilterung: Ein umfassender Leitfaden zu Techniken, Vorteilen und Best Practices 
Erleben Sie codefreie Konnektivität zu CRMs mit Astera CAPI-Anschlüsse
Top-Data-Governance-Tools für 2024
In Anbetracht Astera Für Ihre Datenverwaltungsanforderungen?

Stellen Sie eine codefreie Konnektivität mit Ihren Unternehmensanwendungen, Datenbanken und Cloud-Anwendungen her, um alle Ihre Daten zu integrieren.

Lassen Sie uns jetzt eine Verbindung herstellen!
Lass uns verbinden