Struktur im Staging-Bereich des Data Warehouse

Question

Wir arbeiten an einem Datawarehouse für eine Bank und haben ziemlich genau das Standard-Kimball-Modell von Staging-Tabellen, ein Sternschema und eine ETL verwendet, um die Daten durch den Prozess zu ziehen.

Kimball spricht über die Verwendung der Staging-Bereich für den Import, Reinigung, Verarbeitung und alles, bis Sie bereit sind, die Daten in das Sternschema zu setzen. In der Praxis bedeutet dies in der Regel, dass Daten aus den Quellen in eine Reihe von Tabellen mit wenig oder keiner Modifikation hochgeladen werden, gefolgt von der wahlweisen Übernahme von Daten durch Zwischentabellen, bis sie bereit sind, in das Sternschema zu gehen. Das ist eine Menge Arbeit für eine einzige Entität, keine einzige Verantwortung hier.

Bisherige Systeme Ich habe auf gearbeitet hat, eine Unterscheidung zwischen den verschiedenen Gruppen von Tabellen vorgenommen, soweit aufweist:

• Hochladen von Tabellen: raw Quellsystem Daten, unmodifizierten
• Ablagetische: Zwischenverarbeitung, typisiert und gereinigt
• Lagertische

Sie können diese in separaten Schemas bleiben und dann gelten unterschiedliche Richtlinien für die Archivierung/Backup/Sicherheit usw. Einer der anderen Männer hat sich auf einem Lager gearbeitet, wo es eine StagingInput und einem StagingOutput, ähnliche Geschichte . Das Team als Ganzes hat viel Erfahrung, sowohl im Datawarehouse als auch anderswo.

Trotz allem scheint Kimball und das Internet absolut nichts zu schreiben, was die Staging-Datenbank strukturieren könnte. Man würde vergeben, wenn man glaubt, dass Mr. Kimball uns alle mit der Inszenierung als diesen großen, dunklen, unstrukturierten Datenpool arbeiten lassen würde.

Während es natürlich ziemlich offensichtlich ist, wie man vorgeht, wenn wir dem Staging-Bereich etwas mehr Struktur hinzufügen wollen, scheint es sehr seltsam, dass nichts darüber geschrieben zu sein scheint.

Also, was machen die anderen da draußen? Ist nur dieses große unstrukturierte Chaos inszeniert oder haben die Leute einige interessante Designs?

Answer 1

Ich habe das gleiche Problem erlebt. Wir haben ein großes HR DataWarehouse und ich ziehe Daten aus Systemen im gesamten Unternehmen. Ich habe eine schöne Sammlung von Fact und Dimension Tabellen, aber der Staging Bereich ist ein Durcheinander.Ich kenne keine Standards für das Design von diesem. Ich würde dem gleichen Weg folgen, auf dem Sie sind, und mit einem Standardsatz von Namen aufwarten, um die Dinge in Ordnung zu halten. Ihr Vorschlag ist ziemlich gut für die Benennung. Ich würde weiter damit arbeiten.

Answer 2

Persönlich gehe ich nicht in Schwierigkeiten, in Kimball oder anderswo.

Nach welcher Art von "Struktur" suchen Sie? Welche Art von "Struktur" wird benötigt? Welche Probleme sehen Sie an dem Mangel an "Struktur", den Sie heute haben?

Ich kann Sie mit dem Eindruck verlassen, dass ich nicht viel von Kimball denke. Nicht so - ich habe Kimball nicht gelesen. Ich denke einfach nicht viel daran, die Dinge ohne Grund zu ändern, ohne ein Muster zu haben. Änderung, um einige reale Probleme zu lösen, wäre in Ordnung. Wenn Sie beispielsweise feststellen, dass Sie Staging-Tabellen sichern, weil ein Mangel an Struktur dazu geführt hat, dass die Staging- und Warehouse-Tabellen gleich behandelt wurden, wäre dies ein Grund, die Struktur zu ändern. Aber wenn Sie das vorhatten, sollten Sie Ihre Frage so bearbeiten, dass Sie darauf hinweisen.

Answer 3

In Staging können Unterbereiche vorhanden sein. Genannt staging1, staging2, zum Beispiel.

Staging1 kann direkt aus Datenquellen ohne Transformation abgerufen werden. Und Staging1 speichert nur die neuesten Daten.

Staging2 sorgt dafür, dass die Daten umgewandelt und bereit zum Lager werden. Staging2 behält alle historischen Daten bei.

Answer 4

Nur ein Hinweis, es gibt ein Buch namens "The Data Warehouse ETL Toolkit" von Raph Kimball und Joe Caserta, also hat Mr. Kimball sich etwas Mühe gegeben. :)

Answer 5

Werfen Sie einen Blick auf diesen Beitrag here. Es gibt einen guten Überblick über die Verantwortlichkeiten eines Bereitstellungsbereichs innerhalb einer DW.

Answer 6

Wir arbeiten gerade an einem großen Versicherungs-DWH-Projekt, das leicht kompliziert ist, aber jede der Quellsystemtabellen wird in einem separaten Schema in einer STAGING-Datenbank gespeichert, dann haben wir ETL, das sich bewegt/reinigt/anpasst (MDM) die Daten von der Staging-Datenbank in eine STAGINGCLEAN-Datenbank, dann weitere ETL, die die Daten in eine Kimball-DWH verschiebt.

Die Trennung der Staging- und der StagingClean-Datenbank ist sehr hilfreich bei der Diagnose von Problemen, insbesondere bei der Datenqualität, da wir sowohl die gestaffelten Daten als auch die gereinigte Version verschmutzen, bevor sie in das eigentliche DWH umgewandelt werden.

Answer 7

Was für eine gute Frage.

In der Vergangenheit haben wir _MIRR (für Spiegel) Suffix für nicht transformierte Daten in der Datenbank gelandet, dh. es spiegelt die Quelle wider. Dann verwenden wir _STG für die transformierten Daten aus der Quelle, dann _DW für das Sternschema.

Die Staging-Tabellen hier wären in 3NF. Ich denke, das ist der entscheidende Punkt. Die Daten werden untransformiert und vom nächsten Schritt getrennt gespeichert, in dem wir die Daten vollständig normalisieren, bevor sie dann in unserem Sternschema für die Berichterstellung abgeglichen werden.