Data Warehouse-Architektur: Traditionell und Cloud

Hallo Habr! Es wurde viel zum Thema Data Warehouse-Architektur geschrieben, aber es hat sich noch nicht so prägnant und prägnant getroffen wie in einem Artikel, über den ich versehentlich gestolpert bin.

Ich lade Sie ein, diesen Artikel in meiner Übersetzung kennenzulernen. Kommentare und Ergänzungen sind willkommen!


(Bildquelle)

Einführung

Die Architektur von Data Warehouses ändert sich also. In diesem Artikel werden herkömmliche Enterprise Data Warehouses und Cloud-Lösungen mit geringeren Anfangskosten, verbesserter Skalierbarkeit und Leistung verglichen.

Ein Data Warehouse ist ein System, in dem Daten aus verschiedenen Quellen innerhalb eines Unternehmens gesammelt und zur Unterstützung von Managemententscheidungen verwendet werden.

Unternehmen wechseln zunehmend zu Cloud-basierten Data Warehouses anstelle herkömmlicher lokaler Systeme. Cloud-Datenspeicher unterscheiden sich in einigen Punkten von herkömmlichen Speichern:

• Keine Notwendigkeit, physische Ausrüstung zu kaufen;
• Cloud Data Warehouses sind schneller und kostengünstiger zu konfigurieren und zu skalieren.
• Cloud Data Warehouses können komplexe analytische Abfragen normalerweise viel schneller ausführen, da sie eine massive parallele Verarbeitung verwenden.

Traditionelle Data Warehouse-Architektur

Die folgenden Konzepte heben einige der etablierten Designideen und -prinzipien hervor, die zum Erstellen traditioneller Data Warehouses verwendet werden.

Drei-Ebenen-Architektur

Sehr oft hat die traditionelle Data Warehouse-Architektur eine dreistufige Struktur, die aus den folgenden Ebenen besteht:

• Untere Ebene : Diese Ebene enthält den Datenbankserver, mit dem Daten aus vielen verschiedenen Quellen abgerufen werden, z. B. aus Transaktionsdatenbanken, die für Front-End-Anwendungen verwendet werden.
• Mid-Tier : Das Mid-Tier enthält einen OLAP-Server, der die Daten in eine Struktur umwandelt, die für Analysen und komplexe Abfragen besser geeignet ist. Ein OLAP-Server kann auf zwei Arten arbeiten: entweder als erweitertes relationales Datenbankverwaltungssystem, das mehrdimensionale Datenoperationen standardmäßigen relationalen OLAP-Operationen zuordnet, oder als Verwendung eines mehrdimensionalen OLAP-Modells, das mehrdimensionale Daten und Operationen direkt implementiert.
• Oberste Ebene : Die oberste Ebene ist die Client-Ebene. Diese Ebene enthält die Tools, die für die Datenanalyse, Berichterstellung und Datenanalyse auf hoher Ebene verwendet werden.

Kimball vs. Inmon

Zwei Pioniere von Data Warehouses: Bill Inmon und Ralph Kimball bieten unterschiedliche Designansätze.

Der Ansatz von Ralph Kimball basiert auf der Bedeutung von Data Marts, bei denen es sich um Data Warehouses handelt, die bestimmten Unternehmen gehören. Ein Data Warehouse ist einfach eine Kombination verschiedener Data Marts , die die Berichterstellung und Analyse erleichtern. Das auf Kimball basierende Data Warehouse-Projekt verwendet einen Bottom-up-Ansatz.

Der Ansatz von Bill Inmon basiert auf der Tatsache, dass das Data Warehouse eine zentralisierte Speicherung aller Unternehmensdaten ist. Bei diesem Ansatz erstellt die Organisation zunächst ein normalisiertes Data-Warehouse- Modell . Anschließend werden dimensionale Data Marts basierend auf dem Lagermodell erstellt. Dies wird als Top-Down-Data-Warehouse-Ansatz bezeichnet.

Data Warehouse-Modelle

In der traditionellen Architektur gibt es drei allgemeine Modelle für Data Warehouses: virtueller Speicher, Datenpräsentation und Corporate Data Warehouse:

• Ein virtuelles Data Warehouse besteht aus einer Reihe separater Datenbanken, die gemeinsam genutzt werden können, sodass der Benutzer effektiv auf alle Daten zugreifen kann, als wären sie in einem Data Warehouse gespeichert.
• Ein Datenpräsentationsmodell wird verwendet, um bestimmte Geschäftsbereiche zu melden und zu analysieren. In diesem Speichermodell aggregierte Daten aus einer Reihe von Quellsystemen, die sich auf einen bestimmten Geschäftsbereich beziehen, z. B. Vertrieb oder Finanzen.
• Das Data Warehouse-Modell des Unternehmens umfasst das Speichern aggregierter Daten, die sich über das gesamte Unternehmen erstrecken. Dieses Modell betrachtet das Data Warehouse als das Herzstück eines Unternehmensinformationssystems mit integrierten Daten aus allen Geschäftsbereichen.

Stern vs. Schneeflocke

Stern- und Schneeflockenschemata sind zwei Möglichkeiten, um Ihr Data Warehouse zu strukturieren.

Ein Sternschema verfügt über ein zentrales Data Warehouse, das in einer Faktentabelle gespeichert ist. Das Diagramm teilt die Faktentabelle in eine Reihe denormalisierter Dimensionstabellen auf. Die Faktentabelle enthält die aggregierten Daten, die für die Berichterstellung verwendet werden, und die Dimensionstabelle beschreibt die gespeicherten Daten.

Denormalisierte Projekte sind weniger komplex, da die Daten gruppiert sind. Die Faktentabelle verwendet nur einen Link zum Anhängen an jede Dimensionstabelle. Das einfachere sternförmige Design vereinfacht das Schreiben komplexer Abfragen erheblich.


Ein Schneeflockenmuster unterscheidet sich darin, dass es normalisierte Daten verwendet. Normalisierung bedeutet eine effiziente Datenorganisation, sodass alle Datenabhängigkeiten definiert sind und jede Tabelle ein Minimum an Redundanz enthält. Somit werden einzelne Messtabellen in separate Messtabellen gegabelt.

Das Schneeflockenschema benötigt weniger Speicherplatz und sorgt für eine bessere Datenintegrität. Der Hauptnachteil ist die Komplexität der Abfragen, die für den Zugriff auf die Daten erforderlich sind. Jede Abfrage muss mehrere Tabellenverknüpfungen durchlaufen, um die entsprechenden Daten zu erhalten.

ETL vs. ELT

ETL und ELT sind zwei verschiedene Möglichkeiten, Daten in den Speicher zu laden.

ETLs (Extrahieren, Transformieren, Laden) rufen zuerst Daten aus einem Pool von Datenquellen ab. Die Daten werden in einer temporären Staging-Datenbank gespeichert. Anschließend werden Konvertierungsvorgänge ausgeführt, um die Daten zu strukturieren und in eine geeignete Form für das Ziel-Data-Warehouse-System zu transformieren. Anschließend werden die strukturierten Daten in den Speicher geladen und können analysiert werden.


Bei ELT (Extrahieren, Laden, Transformieren) werden Daten sofort nach dem Extrahieren aus den Quelldatenpools geladen. Es gibt keine Zwischendatenbank, was bedeutet, dass Daten sofort in ein einzelnes zentrales Repository hochgeladen werden.
Daten werden zur Verwendung mit Business Intelligence- und Analysetools in ein Data Warehouse-System konvertiert.

Organisatorische Reife

Die Data Warehouse-Struktur des Unternehmens hängt auch von der aktuellen Situation und den aktuellen Anforderungen ab.

Die Grundstruktur ermöglicht es Speicherendbenutzern, direkt auf Zusammenfassungsdaten von Quellsystemen zuzugreifen, Berichte zu erstellen und diese Daten zu analysieren. Diese Struktur ist nützlich für Fälle, in denen Datenquellen aus denselben Arten von Datenbanksystemen stammen.


Die Speicherung mit einem Zwischenbereich ist der nächste logische Schritt in einer Organisation mit heterogenen Datenquellen mit vielen verschiedenen Datentypen und -formaten. Der Staging-Bereich konvertiert die Daten in ein generisches strukturiertes Format, das mithilfe von Analyse- und Berichterstellungstools einfacher anzufordern ist.


Eine Variation der Zwischenstruktur ist das Hinzufügen von Data Marts zum Data Warehouse. Data Marts speichern zusammenfassende Daten zu einem bestimmten Tätigkeitsbereich, wodurch diese Daten für bestimmte Analyseformen leicht zugänglich sind.

Durch Hinzufügen von Data Marts kann ein Finanzanalyst beispielsweise detailliertere Abfragen zu Verkaufsdaten durchführen und das Kundenverhalten vorhersagen. Data Marts erleichtern die Analyse, indem sie Daten speziell auf die Bedürfnisse der Endbenutzer zuschneiden.

Neue Data Warehouse-Architekturen

In den letzten Jahren sind Data Warehouses in die Cloud umgezogen. Neue Cloud-Data-Warehouses halten sich nicht an die traditionelle Architektur und bieten jeweils eine eigene Architektur.

In diesem Abschnitt werden kurz die Architekturen beschrieben, die von den beiden beliebtesten Cloud-Speichern verwendet werden: Amazon Redshift und Google BigQuery.

Amazon Rotverschiebung

Amazon Redshift ist eine Cloud-basierte Ansicht eines herkömmlichen Data Warehouse.

Redshift erfordert, dass Computerressourcen vorbereitet und als Cluster konfiguriert werden, die eine Sammlung von einem oder mehreren Knoten enthalten. Jeder Knoten hat seinen eigenen Prozessor, Speicher und RAM. Leader Node kompiliert die Anforderungen und übergibt sie an die Rechenknoten, die die Anforderungen ausführen.

An jedem Knoten werden Daten in Blöcken gespeichert, die als Slices bezeichnet werden . Redshift verwendet den Spaltenspeicher, dh jeder Datenblock enthält Werte aus einer Spalte in mehreren Zeilen und nicht aus einer Zeile mit Werten aus mehreren Spalten.


Redshift verwendet die MPP-Architektur (Massively Parallel Processing) und unterteilt große Datenmengen in Blöcke, die Slices in jedem Knoten zugewiesen sind. Anforderungen sind schneller, da Rechenknoten Anforderungen in jedem Slice gleichzeitig verarbeiten. Der Leader Node-Knoten kombiniert die Ergebnisse und gibt sie an die Clientanwendung zurück.

Clientanwendungen wie BI und Analysetools können mithilfe der Open-Source-Treiber PostgreSQL JDBC und ODBC direkt eine Verbindung zu Redshift herstellen. Auf diese Weise können Analysten ihre Aufgaben direkt an Redshift-Daten ausführen.

Redshift kann nur strukturierte Daten laden. Sie können Daten mit vorintegrierten Systemen, einschließlich Amazon S3 und DynamoDB, in Redshift laden, indem Sie Daten von einem beliebigen lokalen Host mit einer SSH-Verbindung übertragen oder andere Datenquellen mithilfe der Redshift-API integrieren.

Google Bigquery

Für die BigQuery-Architektur ist kein Server erforderlich. Dies bedeutet, dass Google die Zuweisung von Computerressourcen dynamisch steuert. Daher sind alle Ressourcenverwaltungsentscheidungen für den Benutzer verborgen.

Mit BigQuery können Kunden Daten aus Google Cloud Storage und anderen lesbaren Datenquellen herunterladen. Eine Alternative ist das Streaming von Daten, mit dem Entwickler dem Data Warehouse zeilenweise Daten in Echtzeit hinzufügen können, sobald sie verfügbar sind.

BigQuery verwendet eine Abfrage-Engine namens Dremel, die Milliarden von Datenzeilen in nur wenigen Sekunden scannen kann. Dremel verwendet massiv parallele Abfragen, um Daten im Colossus-Basisdateiverwaltungssystem zu scannen. Colossus verteilt Dateien in Teile von 64 Megabyte unter einer Vielzahl von Rechenressourcen, die als Knoten bezeichnet werden und in Clustern gruppiert sind.
Dremel verwendet eine ähnliche Spaltendatenstruktur wie Redshift. Die Baumarchitektur sendet innerhalb von Sekunden Anforderungen an Tausende von Computern.

Einfache SQL-Befehle werden zum Ausführen von Datenabfragen verwendet.

Panoply

Panoply bietet ein umfassendes Datenmanagement als Service. Die einzigartige selbstoptimierende Architektur nutzt maschinelles Lernen und die Verarbeitung natürlicher Sprachen (NLP), um die Datenübertragung von der Quelle zur Analyse zu modellieren und zu optimieren und die Zeit von den Daten auf Werte so nahe wie möglich zu reduzieren.

Panoply Intelligent Data Infrastructure bietet die folgenden Funktionen:

• Abfrage- und Datenanalyse - Ermittlung der besten Konfiguration für jeden Anwendungsfall, Anpassung im Laufe der Zeit und Erstellung von Indizes, Sortieren von Schlüsseln, Festplattenschlüsseln, Datentypen, Evakuieren und Partitionieren.
• Identifiziert Abfragen, die nicht den Best Practices entsprechen, z. B. verschachtelte Schleifen oder implizite Umwandlungen, und schreibt sie in eine entsprechende Abfrage um, die einen Bruchteil der Ausführungszeit oder Ressourcen erfordert.
• Optimieren Sie die Serverkonfiguration im Laufe der Zeit basierend auf Abfragemustern und lernen Sie, welches Server-Setup am besten funktioniert. Die Plattform wechselt nahtlos zwischen Servertypen und misst die Gesamtleistung.

Jenseits des Cloud-Speichers

Cloud-basiertes Data Warehousing ist eine große Verbesserung gegenüber herkömmlichen Architekturansätzen. Benutzer haben jedoch immer noch eine Reihe von Problemen bei der Konfiguration:

• Das Hochladen von Daten in Cloud-basierte Data Warehouses ist nicht trivial, und große Datenpipelines erfordern Konfiguration, Test und Unterstützung für den ETL-Prozess. Dieser Teil des Prozesses wird normalerweise von Tools von Drittanbietern ausgeführt.
• Aktualisierungen, Einfügungen und Löschungen können komplex sein und müssen sorgfältig durchgeführt werden, um eine Verschlechterung der Abfrageleistung zu vermeiden.
• Halbstrukturierte Daten sind schwer zu verarbeiten - sie müssen in einem relationalen Datenbankformat normalisiert werden, das die Automatisierung großer Datenflüsse erfordert.
• Verschachtelte Strukturen werden in Cloud Data Warehouses normalerweise nicht unterstützt. Sie müssen die verschachtelten Tabellen in Formate konvertieren, die das Data Warehouse versteht.
• Clusteroptimierung . Es gibt verschiedene Optionen zum Konfigurieren eines Redshift-Clusters zum Ausführen Ihrer Workloads. Unterschiedliche Workloads, Datasets oder sogar unterschiedliche Arten von Abfragen erfordern möglicherweise unterschiedliche Konfigurationen. Um eine optimale Leistung zu erzielen, muss die Konfiguration ständig überprüft und gegebenenfalls zusätzlich konfiguriert werden.
• Abfrageoptimierung - Benutzerabfragen folgen möglicherweise nicht den Best Practices und dauern daher viel länger. Sie können mit Benutzern oder automatisierten Clientanwendungen zusammenarbeiten, um Abfragen so zu optimieren, dass das Data Warehouse wie erwartet funktioniert
• Sicherung und Wiederherstellung - Obwohl die Data Warehouse-Anbieter viele Optionen zum Sichern Ihrer Daten bereitstellen, sind sie nicht trivial zu konfigurieren und erfordern Überwachung und Aufmerksamkeit.

Link zum Originaltext: panoply.io/data-warehouse-guide/data-warehouse-architecture-traditional-vs-cloud