Data Science

10 min. lesen

January 26, 2023

Einführung

Willkommen in unserem Blog und zu unserer neuen Tutorial-Serie zum Thema Data Warehousing! In unserer vorherigen Tutorial-Serie haben wir uns auf den Data Engineering-Teil der Erstellung eines Data Warehouse konzentriert.

In dieser Serie erfahren Sie mehr darüber, wie Sie ein Data Warehouse mit einer bestehenden OLTP-Datenbank (Online Transaction Processing) als Ausgangspunkt entwerfen. Seien Sie sich darüber im Klaren, dass das Design von Data Warehouses ein sehr umfangreiches Thema ist und wir unmöglich alle Techniken abdecken können, die es gibt. Dennoch werden wir Ihnen einige der wichtigsten Teile beibringen und Beispiele mit von uns zur Verfügung gestellten artifiziellen Daten anführen.

Die Serie wird aus den folgenden Teilen bestehen:

1. Kernkonzepte: Sternschema, Fakten, Dimensionen, Data Warehouse Design-Prozess, Bus-Matrix

2. Planung: Quellschema, Erstellung von Dimensionstabellen und Faktentabellen, Aufbau der Busmatrix

3. Design: Definieren des Schemas für Dimensionstabellen und Faktentabellen

4. Implementierung: Aufbau der Daten-Pipelines in SQL

Ziel

In dieser Serie werden wir uns hauptsächlich auf die Data Warehousing Prinzipien konzentrieren und versuchen, die anderen Aspekte so weit wie möglich zu vereinfachen. Unsere Zielarchitektur einschließlich des Quellsystems wird also wie folgt aussehen.

Wir verwenden einfach dieselbe Postgres-Datenbank mit zwei verschiedenen Schemata, eines mit unseren operativen Tabellen und eines mit den Tabellen im Star-Schema. Um die Daten aus dem operativen Schema in das Data Warehousing Schema zu übertragen, definieren wir gespeicherte Prozeduren, die von einer SQL-Flasche ausgeführt werden, die als ETL-Pipeline fungiert. Wenn Sie auf der Suche nach einer realistischeren Architektur sind, sollten Sie sich unseren Leitfaden für DataEngineeringauf MS Azure ansehen.

1. Stern-Schema

Sternschemata sind das Kernkonzept des Data Warehouse Designs. Im Gegensatz zu den normalisierten Schemata, die wir für unsere operativen OLTP-Datenbanken verwenden, legen Sternschemata weit weniger Wert auf die Reduzierung von Redundanz und weit mehr Wert auf Leistung und Einfachheit. Man kann es auch so sehen, dass OLTP-Datenbanken sich auf einzelne Einträge konzentrieren und eher auf schnelles Schreiben ausgerichtet sind, während OLAP-Datenbanken (Online Analytical Processing) sich auf Bereiche konzentrieren und eher auf schnelles Lesen ausgerichtet sind.

Um ein schnelles Lesen von Bereichsabfragen zu ermöglichen, organisiert das Sternschema die Tabellen so, dass in der Regel nur zwei Tabellen verbunden werden müssen, um eine Geschäftsfrage zu beantworten. Das ist effektiv, denn Joins sind sehr kostspielige Operationen. Um die Anzahl der Joins gering zu halten, enthält ein Sternschema immer eine Faktentabelle und zwei oder mehr Dimensionstabellen, die über Fremdschlüssel mit der Faktentabelle verbunden sind, aber normalerweise nicht miteinander (Ausnahme: Outrigger-Dimensionen).

1.1. Faktentabellen

Faktentabellen stehen im Zentrum des Sternschemas und sind in der Regel die Abbildung eines Geschäftsprozesses. Sie enthalten viele Metriken, auch Fakten genannt, die für Unternehmensanalysten interessant sind, weil sie Schlüsselfaktoren der Rentabilität sind. Neben den Metriken enthalten Faktentabellen auch Fremdschlüssel zu den Dimensionstabellen. Da sich Faktentabellen mit Prozessen/Aktionen wie Verkäufen, Einkäufen oder Lieferungen befassen, enthalten sie oft sehr viele Zeilen. Um die Größe der Datenbank überschaubar zu halten, werden beschreibende Details über den Prozess meist in Dimensionen extrahiert.

1.2. Maßtabellen

Dimensionstabellen enthalten Daten, die die Informationen über den Prozess anreichern können, typischerweise unter Einbeziehung der W-Fragen. Aus der Sicht eines Unternehmensanalysten werden die Dimensionsattribute hauptsächlich zur Filterung oder Gruppierung des Prozesses verwendet. Im Gegensatz zu Faktentabellen, die Prozesse beschreiben, beschreiben Dimensionstabellen Entitäten, die meist statisch sind, wie Produkte, Geschäfte oder Kunden. Da die Dimensionstabellen in der Regel eine recht überschaubare Anzahl von Zeilen enthalten, werden sie oft mit weiteren Spalten angereichert, um die Abfrage für Geschäftsanalysten komfortabler zu gestalten. Ein gutes Beispiel hierfür ist die Datumsdimension, bei der es möglich ist, viele zusätzliche Attribute wie Feiertag, Wochentag usw. auf der Grundlage des ursprünglichen Wertes zu berechnen. Aufgrund ihrer geringen Größe ist es außerdem möglich, die Dimensionstabellen zwischen den Knoten zu replizieren, wenn Sie verteilte Datenbanken wie AWS Redshift, Azure Synapse oder Google BigQuery verwenden.

2. Data Warehousing Prozess

Der Prozess des Data Warehousing ist ein heikles Thema, da er oft mit der Strategie und den Prozessen des gesamten Unternehmens und damit mehrerer Abteilungen verbunden ist. Aufgrund der vielen Beteiligten, die für den Aufbau eines effizienten und integrierten Data Warehouse erforderlich sind, ist es sehr wichtig, über einen klaren Prozess und ein Tool zu verfügen, um die Bemühungen zu koordinieren und durchzuführen.

2.1. Geschäftsprozess-Schritte

Es gibt einen vierstufigen Prozess, den Sie anwenden sollten, um die riesige Aufgabe des Aufbaus eines Data Warehouse in kleinere, überschaubare Teile zu zerlegen.

a. Geschäftsprozess auswählen

Ein Unternehmen hat viele verschiedene Prozesse wie Beschaffung, Herstellung oder Verkauf. Sowohl die gemessenen Fakten als auch die anwendbaren Dimensionen hängen stark vom Geschäftsprozess ab, so dass es unvermeidlich ist, sich jeweils auf einen Geschäftsprozess zu konzentrieren. Es gibt auch Dimensionen, die auf mehrere Geschäftsprozesse anwendbar sind. Diese Dimensionen sollten als konforme Dimensionen implementiert werden, d.h. sie werden von Faktentabellen gemeinsam genutzt, damit Geschäftsanalysten eine integrierte Analyse entlang der Wertschöpfungskette durchführen können.

b. Deklarieren Sie das Getreide

Die Körnung, mit der der Prozess analysiert wird, hat auch Auswirkungen darauf, welche Dimensionen anwendbar sind. Im Falle eines Einzelhandelsgeschäfts kauft ein Kunde möglicherweise mehrere Produkte in derselben Transaktion. Wenn die Dimension auf der Produktebene liegt, ist es sinnvoll, eine Produktdimensionstabelle mit der Faktentabelle zu verbinden. Dies ist nicht möglich, wenn sich die Struktur auf der Ebene der Transaktion befindet. Da es für das Data Engineering-Team kaum vorhersehbar ist, welche Fragen Geschäftsanalysten mit dem Data Warehouse zu beantworten versuchen werden, sollte man immer eine Faktentabelle auf der granularsten/atomaren Ebene haben. Aggregierte Faktentabellen beschleunigen die Abfragen, aber sie schränken auch die Fragen ein, die mit dem Data Warehouse beantwortet werden können. Sie sollten daher immer das optionale Add-on zur obligatorischen atomaren Faktentabelle sein.

c. Identifizieren Sie die Dimensionen

Wenn es um die Auswahl von Dimensionen geht, besteht der schwierigste Teil in der Regel darin, zu definieren, was als eigenständige Dimension gilt und was in eine andere Dimension integriert werden sollte. Diese Entscheidung ist anwendungsfallspezifisch und sollte je nach dem Ausmaß der Abhängigkeit zwischen den Tabellen getroffen werden. Wenn beispielsweise die angebotenen Produkte stark von der Filiale abhängen, sollten die Filialen und die Produkte in einer Dimension erfasst werden. Wenn die Produkte unabhängig von den Geschäften sind, sollten sie in zwei verschiedenen Dimensionen erfasst werden.

Die Dimensionen sollten in der Regel unabhängig voneinander sein!

Manchmal werden auch Attribute aus verschiedenen Dimensionen in eine Junk-Dimension geworfen, um die Anzahl der Gesamtdimensionen zu reduzieren.

d. Fakten auswählen

Bei den Fakten in der Faktentabelle handelt es sich in der Regel um Metriken, die für den Erfolg des Unternehmens wesentlich sind. Es gibt drei verschiedene Arten von Fakten: additiv, semi-additiv und nicht-additiv. Dieser Typ bestimmt, ob die Fakten noch einen Sinn ergeben, wenn sie im Rahmen einer Aggregation summiert werden. So ist z.B. eine Verkaufsmenge additiv, während eine Kennzahl wie die Umsatzmarge nicht additiv ist. Fakten sollten in einer Eins-zu-Eins-Beziehung zu den Körnern der Faktentabelle stehen. Außerdem sollten die Fakten direkt mit dem beobachtbaren Ereignis, z.B. der Verkaufstransaktion, verknüpft sein.

2.2. Bus-Matrix

Die Bus-Matrix ist ein wesentliches Instrument sowohl für die Planung der Bemühungen als auch für den Aufbau des Data Warehouse. Sie enthält in der Regel eine Zeile für jeden der Geschäftsprozesse, die zu einer Faktentabelle führen werden. Die Spalten enthalten alle Dimensionen, die auf mindestens einen der Geschäftsprozesse anwendbar sind. Jede Zelle wird dann schattiert oder irgendwie markiert, um anzuzeigen, ob die Dimension auf den Prozess anwendbar ist. Das Data Engineering-Team sollte sich immer darauf konzentrieren, das Schema und die Pipeline für einen Prozess nach dem anderen zu erstellen. Dieses Prinzip ermöglicht eine schrittweise Integration neuer Prozesse in die bestehende Infrastruktur und erhöht so die Akzeptanz im Unternehmen, da der Fortschritt sehr schnell sichtbar wird.

Einpacken

In diesem Artikel haben wir die Grundlagen des Data Warehousing kennengelernt. Wir haben das Sternschema mit seinen Fakten- und Dimensionstabellen, den Data Warehousing-Prozess und die Bus-Matrix kennengelernt.

Im nächsten Artikel werden wir das OLTP-Schema vorstellen, das unser Anwendungsfall für die Serie sein wird. Außerdem werden wir den Data Warehousing-Prozess auf unser OLTP-Schema anwenden, um unsere eigene Bus-Matrix zu erstellen. Wir sehen uns in Teil 2, Data Warehousing Leitfaden - Folgen Sie dem DataWarehousingProzess!

Quelle

Wiley: Das Data Warehouse Toolkit

184

Anteile

285

Ansichten