Der Analystenleitfaden zum Entwerfen eines modernen Data Warehouse

Sie werden also gebeten, ein Data Warehouse für Ihr Unternehmen aufzubauen. Ein Data Warehouse, das effizient, skalierbar und vertrauenswürdig ist. Wenn Ihr Unternehmen ernsthaft damit beginnt, Datenberichterstattung als wichtigen strategischen Vermögenswert für Ihr Unternehmen zu implementieren, wird der Aufbau eines Data Warehouses schließlich im Gespräch sein.

Der Aufbau eines Data Warehouses ist jedoch weder einfach noch trivial. Über 50 Prozent der Data-Warehouse-Projekte haben eine begrenzte Akzeptanz oder werden geradezu scheitern.

Wie sollten Sie anfangen, Ihr Data Warehouse zu entwerfen und aufzubauen? Was sind die Fallstricke und wie sollten Sie sie optimieren? Am wichtigsten, wo soll ich anfangen?

Dieser Beitrag bietet eine allgemeine Anleitung, wie Sie über die Einrichtung Ihres Data Warehouses nachdenken können, um einige häufige Fallstricke zu vermeiden.

Was ist ein Data Warehouse?

Ein modernes Unternehmen hat in der Regel Daten an verschiedenen Orten (Datenquellen) gespeichert. Dies können Daten sein aus:

• Anwendungsdatenbanken: Für Startups ist dies wahrscheinlich ihre Kernproduktanwendung. Für andere Unternehmen kann es ihre Point-of-Sale-Anwendung sein,
• Webanwendungen: Dies können Anwendungen sein, die entweder zur Skalierung eines Unternehmens oder zur Aufrechterhaltung des Geschäftsbetriebs benötigt werden. Beispiele können E-Mail-Marketing-Software wie Mailchimp, Webanalyseanwendungen wie Google Analytics oder Mixpanel oder sogar Buchhaltungssoftware wie Xero und Quickbooks sein.
• Tabellenkalkulationen: Dies kann in Form von Desktop-Tabellenkalkulationen (Excel, CSV) oder Online-Tabellenkalkulationen wie Google Sheets erfolgen. Diese Daten können manuell von jemandem oder durch eine Zapier-Aktivität aktualisiert werden.

Ein Data Warehouse Synchronisieren Sie Daten aus verschiedenen Quellen an einem einzigen Ort für alle Datenberichterstattungsanforderungen.

Es stellt Daten bereit, auf deren Zuverlässigkeit vertraut werden kann, und kann die Abfragebelastung aller Mitarbeiter im Unternehmen bewältigen.

Entwerfen eines Data Warehouse

Lesen Sie auch: Wann sollten Sie ein Data Warehouse erhalten?

So sieht ein typisches Data Warehouse-Setup aus:

Sie entwerfen und erstellen Ihr Data Warehouse basierend auf Ihren Berichtsanforderungen. Nachdem Sie die benötigten Daten identifiziert haben, entwerfen Sie die Daten für den Informationsfluss in Ihr Data Warehouse.

Erstellen Sie ein Schema für jede Datenquelle

Erstellen Sie ein Datenbankschema für jede Datenquelle, die Sie mit Ihrer Datenbank synchronisieren möchten. Mit diesem

1. Können Sie schnell die Datenquelle identifizieren, aus der jede Tabelle stammt. Zukünftige Datenanalysten und Business-Team-Mitglieder, die Ihrem Unternehmen beitreten, können auch schnell lernen, was jede Datenquelle hat.Mit
2. Können Sie jeder Datenquelle bestimmte Berechtigungen (Lesen/Schreiben) zuweisen. Beispielsweise möchte ein Data Engineer einem Junior Analyst möglicherweise nicht erlauben, ein bestimmtes Schema nur zu lesen, aber nicht zu schreiben.

Dies ist besonders hilfreich, wenn die Anzahl der Datenquellen im Laufe der Zeit zunimmt. Schauen Sie sich nur die Anzahl der Quellen an, in denen sich Ihre Daten befinden könnten.

Sie können beispielsweise ein Schema mit den Namen mailchimpxero oder fbads für die E-Mail-Marketing-, Finanz- und Werbedaten einrichten, die Sie aus diesen Anwendungen in Ihr Lager importieren möchten.

Wenn Sie Ihre Kontaktetabelle aus Mailchimp in Ihre Datenbank importieren, können Sie sie
wie folgt abfragen:

SELECT name, email FROM mailchimp.contacts

So erstellen Sie ein Schema

Das Erstellen eines Schemas ist einfach. Sie müssen nur eine Zeile eingeben, um ein neues Schema zu erstellen. In der Tat sind es nur 3 Wörter in Postgres.

CREATE SCHEMA 

Beispiel:

CREATE SCHEMA mailchimp

Hinweis 1: Neue Analysten können ein Datenbankschema verwechseln. Es gibt 2 Schemadefinitionen. Ein Schema kann verwendet werden, um entweder

1. zu beschreiben, wie die Tabellen und Felder in einer Datenbank miteinander verwandt sind, oder
2. Einen Ordner für Datenbanktabellen, genau wie Ordner Ihre Dateien organisieren

Anmerkung 2: MySQL-Datenbanken unterstützen kein Schema, daher möchten Sie möglicherweise eine Namenskonvention verwenden, um die von Ihnen importierten Tabellen zu benennen, z. B. mailchimp_contacts usw. Dies ist einer der Gründe, warum wir unsere Kunden ermutigen, PostgreSQL für ihre Berichtsdatenbank zu verwenden.

Quelldaten in Ihr Data Warehouse verschieben

Der nächste Schritt besteht darin, Ihre Quelldaten in Ihr Data Warehouse zu synchronisieren. Ihre Ingenieure kennen dies möglicherweise als ETL-Skript.

Entwerfen Sie Ihr Importskript mit den folgenden Überlegungen:

1. Entfernen Sie offensichtlich unnötige Spalten. Es ist nicht so schwierig für Sie, sie später hinzuzufügen, wenn Sie feststellen, dass Sie sie benötigen.
2. Benennen Sie Spaltennamen um, um sie beschreibender oder datenbankfreundlicher zu machen (z. B. mit Kleinbuchstaben oder Kamelbuchstaben.
3. Filtert offensichtlich unnötige Datensätze heraus. Dies kann Aufzeichnungen sein, die Ihre internen Benutzer auf Ihrem Produktionssystem testen (manchmal fügen Ihre Benutzer möglicherweise Daten hinzu wie [email protected] oder setzen Sie ihren Vornamen als Tests)
4. Ordnen Sie Datensatzwerte zu, um sie besser lesbar zu machen. Dies erspart Ihren Analysten den Aufwand, sie während des Berichts mit CASE-IFs später umzubenennen). Zum Beispiel können einige Datensätze numerische Schlüssel (1,2,3, 99 usw.) oder abgekürzte Namen speichern, die dem Rest der Organisation möglicherweise nicht bekannt sind. In diesen Fällen möchten Sie diese Schlüssel möglicherweise während des Importvorgangs ihren tatsächlichen Werten zuordnen.
5. Wenden Sie Datenbankindizes auf Ihre Zieltabelle an, nachdem der Import abgeschlossen ist. Hinweis Wir haben in einem früheren Beitrag darüber geschrieben, was Datenbankindizes sind.
6. Fehlerbehandlung: Einrichten von E-Mails//Slack-Warnmeldungen, die an die relevanten Stakeholder (insbesondere Datenanalysten) mit detaillierten Fehlerprotokollen gesendet werden, wenn der Job fehlschlägt. Möglicherweise möchten Sie innerhalb eines bestimmten Zeitraums automatisierte Wiederholungsversuche (oder automatisierte Wiederherstellungsprozesse) einrichten, um die Anzahl der Fehlalarme in diesem Fall zu verringern.

Sollten Sie Ihre Quell- (Roh-)Daten transformieren?

Eine Frage, die uns oft gestellt wird, ist, wie man Datentransformationen anwendet, bevor die Daten in das Warehouse verschoben werden.

über GIPHY

Unser allgemeiner Rat ist, es nicht zu tun. Zumindest nicht am Anfang. Vor allem, wenn dies Ihr erstes Data Warehouse-Projekt ist. Dafür gibt es ein paar Gründe.

ein. Es ist unwahrscheinlich, dass Sie klare Anforderungen an Ihre Datentransformationsanforderungen haben

Selbst wenn Sie „klare Anforderungen“ erhalten, wird sich diese Anforderung wahrscheinlich im Laufe des Projekts ändern oder veraltet sein.

Sie werden keine Zeit damit verbringen wollen, Ihr ETL-Skript basierend auf den Wünschen verschiedener Stakeholder zu verschiedenen Zeitpunkten zu überarbeiten.

Wenn Sie Ihre (nicht transformierten) Quelldaten verschieben, können Sie die Abhängigkeit Ihres ETL-Skripts von den „Geschäftsanforderungen“ trennen.

b. Es ist wahrscheinlich, dass Sie die Quelldaten für andere Fälle benötigen

Stellen Sie sich Ihre Quelldaten als Interaktionsbasis vor, die in mehrere abgeleitete Tabellen abgeleitet werden kann, indem Sie sie entweder entlang verschiedener Dimensionen aggregieren oder mit Tabellen aus anderen Quellen verbinden.

Siehe Beispiel unten, wie Sie die Effektivität der Conversion des Verkäufers verfolgen können.

Wenn Sie Daten transformieren, verlieren Sie Details aus den Quelldaten, die für zukünftige Berichtsanwendungsfälle benötigt werden.

Wenn Sie beispielsweise Umsatzerlöse nach Zeitraum zusammenfassen, gehen Details zu den spezifischen Transaktionsdatensätzen verloren, die ein anderer Benutzer möglicherweise mit anderen Berichten korrelieren muss.

Wenn Sie Ihre nicht transformierten Quelldaten verschieben, können Sie sie flexibel mit anderen Datenquellen kombinieren.

Der Bedarf an Quelldaten wird immer wichtiger, wenn Sie beginnen, wiederverwendbare Datenmodelle zu erstellen, um verschiedene Fragen zu beantworten. Ein Kohortenbericht wird mit einer Reihe von posttransformierten Daten erstellt. Dies wird schwieriger zu tun sein, wenn Sie nicht

c haben. Reduzieren Sie die Belastung Ihrer Quellsysteme

Das Ausführen von Datentransformationen im Quellsystem kann erhebliche Ressourcen beanspruchen, insbesondere wenn Sie über eine Datenbank verfügen, die Kunden auf der ganzen Welt bedient.

Sie sollten es nicht mit lang laufenden Datentransformationsaufträgen überladen, bevor Sie sie verschieben.

Es gibt einige Fälle, in denen es sinnvoll sein kann, Daten vor dem Verschieben zu transformieren, aber diese Fälle sind in der Regel für Unternehmen gedacht, die bereits ein zuverlässiges Data Warehouse eingerichtet haben und es weiter verbessern möchten.

Transformieren Sie Daten, um ein bestimmtes Problem zu lösen

Das Nachdenken darüber, wie Daten transformiert werden, kann komplex sein. Wenn Sie dieses Kontrollkästchen nicht aktivieren, verbringen Sie möglicherweise viel Zeit mit der Optimierung von Daten, die für das Unternehmen keinen Mehrwert bieten.

Planen, Entwerfen und Implementieren von Datentransformationen ohne klares Ergebnis ist eine Lösung, die nach einem Problem sucht.

Eine gute Faustregel ist, mit dem Ende zu beginnen. Datentransformationen sollten nur erstellt werden, um einen praktischen Anwendungsfall oder ein Problem aus Ihrer Berichterstattung zu lösen.Eine gute Möglichkeit, diese praktischen Anwendungsfälle zu finden (und zu priorisieren), besteht darin, die Berichte und Dashboards mit den importierten Daten zu erstellen.

Wenn Ihre Benutzer Probleme mit der Abfrageleistung haben, können Sie die Daten transformieren.

Dies kann durch Berichte verursacht werden, die entweder
(a) verschachtelte Unterabfragen oder benutzerdefinierte Tabellenausdrücke (CTEs)

(b) enthalten Oder mehrere (teure) Verknüpfungen über mehrere Tabellen hinweg aufweisen.

Hier ist die Flexibilität von SQL-basierten Berichten nützlich, um die Probleme zu identifizieren, die durch die Datentransformation behoben werden können.

Es ist für jeden Analysten einfach, die Ursache von Berichten mit langen Abfragen schnell zu identifizieren und ihre Leistung zu optimieren.

Dies geschieht weitgehend durch automatische Voraggregation der Daten. Dies kann mit materialisierten Ansichten erfolgen, in denen Sie Datentransformationsaufträge erstellen können, die entweder:

1. Große Transaktionstabellen aggregieren, um die Abfrageleistung zu beschleunigen.
2. Erstellen Sie abgeleitete Tabellen mit Spalten aus verschiedenen Datenquellen
3. Ersetzen/maskieren Sie sensible Daten für ausgewählte Benutzergruppen.

Eine weitere Empfehlung ist, ein neues Datenbankschema in Ihrem Data Warehouse zu erstellen, in dem Sie Ihre transformierten (oder nachbearbeiteten) Tabellen speichern können.

Wie beim früheren Ansatz, jede Datenquelle nach Schemata zu trennen, kann das Erstellen eines bestimmten Schemas Ihnen helfen, die Liste der abgeleiteten / transformierten Datentabellen zu identifizieren. Dies ist später hilfreich, wenn Sie beginnen, eine Reihe von Datenimporten und Datentransformationsaufträgen nacheinander zu erstellen, wenn Ihre Datenreife zunimmt.

Erstellen Sie Ihre internen Datendokumente

Dies ist wichtig, insbesondere wenn Sie nicht möchten, dass Ihr Data Warehouse eine Blackbox ist, in der nur wenige Ingenieure wissen, wie Sie es verwenden. Wenn Ihre Benutzer es nicht verstehen, können sie es nicht sicher abfragen.

Sie können beginnen, indem Sie ein gemeinsames Dokument erstellen (kann Google Doc sein), das ein gemeinsames Verständnis von beschreibt:

• Tabellen und Spalten in Ihren Quelldaten und wie sie interpretiert werden
• Datendiagramm einschließen, falls vorhanden.
• So lesen Sie Ihre Spalten in Ihren Berichten (Dashboard, Metriken) und alle zugrunde liegenden Annahmen

Aktualisieren Sie dieses Dokument jedes Mal, wenn ein Bericht erstellt (oder aktualisiert) wird, um ein neues Geschäftsverständnis Ihrer Daten widerzuspiegeln.

Wir werden weitere Details zur Erstellung und Strukturierung dieses internen Datendokuments in einem separaten Beitrag veröffentlichen, also achten Sie auf diesen Bereich!

Das war’s!

Wir hoffen, dass dieser Leitfaden hilfreich war! Lassen Sie uns wissen, wie wir Ihnen helfen können, ein zuverlässiges Data Warehouse aufzubauen.