Data Warehouse-Staging-Architektur

Dies ist eine Frage zum Data Warehouse-Design. Wir richten ein Data Warehouse für das Gesundheitswesen ein und beginnen mit zwei wichtigen Quellsystemen, die zusammen etwa 20.000 Tabellen und 2 TB Daten enthalten. 1) Es handelt sich um hochdimensionale Daten. 2) Wir werden OLTP-Systeme nicht stark beeinflussen

Wir haben ein inkrementelles Kimball-Design gewählt. Meine Frage ist, ob alle Daten bereitgestellt, dann in Einfügungen / Aktualisierungen sortiert und in das Data Warehouse gestellt werden sollen. Dann würden die Staging-Daten für das nächste inkrementelle Laden gelöscht.

Damit erhalten Sie 1 Kopie der Daten.

Die andere Methode wäre, es schrittweise in das Staging zu laden, es in Einfügungen / Aktualisierungen zu sortieren und im gleichen Format wie die Quellsysteme zu speichern. Dann würden wir Daten aus den Quellsystemen aus der vollständigen Kopie in das Datawarehouse kombinieren.

Dies würde im Wesentlichen 2 Kopien der Daten hinterlassen, eine in Form der Quellsysteme und eine in das eigentliche Datawarehouse geladen.

Was ist die beste Vorgehensweise dafür? Ich dachte ursprünglich, es wäre am besten, nur die Kopie im Data Warehouse zu speichern und die Quelltabellen bei jedem Laden zu löschen.

In diesem Fall müssten Sie jedoch alle abhängigen Quelltabellen neu laden, wenn Sie jemals zu einer vorhandenen Dimension zurückkehren und eine Spalte hinzufügen müssten. Außerdem würden Sie die Geschichte verlieren?

Es scheint wirklich ineffizient zu sein, es zweimal zu speichern. Ich wollte nur ein paar Gedanken zum Design, Ihren Erfahrungen und Best Practices.

Persönlich habe ich Staging-Tabellen zum Extrahieren, Transformieren und dauerhaften Speichern von Daten.

Ob Sie vollständige Exporte oder inkrementelle Ladevorgänge ausführen, hängt davon ab, über welche Tools Sie verfügen, welche Strategie Sie verfolgen und ob Ihr App-Schema und Ihre Daten dies unterstützen. Manchmal kann man volle Exporte nicht vermeiden.

Das Hinzufügen einer Spalte zu einer Dimension ist keine große Sache, aber das Auffüllen historischer Daten kann sehr schwierig oder überhaupt nicht möglich sein. Der Versuch, nachträglich zu rekonstruieren, wie eine App zu einem bestimmten Zeitpunkt aussah, wäre ein großes Unterfangen. Sie würden einen sehr guten Fall brauchen, um das zu rechtfertigen.

Alle Dinge, die Sie erwähnen, sind möglich, aber nur Sie können entscheiden, ob sich die Kosten / Nutzen lohnen.

Im Allgemeinen stellen wir fest, dass ein ODS (Operational Data Store, eine Kopie des Quellsystems) zunächst sehr nützlich ist, um Ihren ETL-Prozess zu überlagern (was sich für Wartung und Fehlerbehebung eignet), aber schließlich für die operative Berichterstellung sehr nützlich wird.

Sie haben auch den Luxus, Indizes hinzufügen und verrückte Abfragen schreiben zu können. dagegen.

Sie können es auch zur Fehlerbehebung verwenden (da Sie eine Kopie der Daten haben, von denen Sie geladen haben, anstatt ein sich bewegendes Ziel in der realen Quelle). Wenn Sie dann Ihre Replikationstools dazu bringen können, alle fünf Minuten Feeds in den ODS zu übertragen, verfügen Sie über eine sehr nützliche Architektur.

Vergessen Sie hier die Ineffizienz. Sie werden auf echte Ineffizienz stoßen, wenn Sie Ihren ETL-Prozess nicht beheben können, weil er in einer Ebene zusammengefasst ist und Sie keine ODS-Ebene haben, von der aus Sie Fehler beheben können.

Dies hängt stark von Ihren Spezifikationen ab. Speicherplatz ist für ein Projekt wie dieses nicht sehr teuer (20K-Tabellen erfordern wahrscheinlich ein viel größeres Entwicklungsbudget).

Denken Sie daran, dass der DWH normalerweise mehr Verlauf als das Quellsystem beibehalten sollte. Wenn Sie also der Meinung sind, dass Sie zurückblicken und eine neue Dimensionsspalte oder eine neue Tatsache hinzufügen möchten, empfiehlt es sich, einen Datentresor zwischen Ihrer Quelle zu erstellen System und Ihre Kimball Data Marts.

Sie erhalten einen dokumentierten und detaillierten Verlauf und mehr Flexibilität auf der Data Mart-Ebene, die sich in der Nähe des Benutzers befinden muss und daher so viel Flexibilität wie möglich erfordert.