Dieses Dokument soll neue Administratoren und Analysten unterstützen, die gerade mit dem Training für Adobe Analytics Data Workbench fertig sind. Nachdem Sie diesen Artikel gelesen haben, sollten Sie sich bei der Problembehebung oder Durchführung von detaillierten Analysen besser vorstellen können, wie diese Software funktioniert.
Datenspeicherungsmodell für Data Workbench
Herkömmliche Architekturen wie relationale Datenbanken organisieren Daten in Tabellen, die durch Schlüssel miteinander verbunden sind. Umgekehrt verwendet die Data Workbench-Komponente in Adobe Analytics einen grundlegend anderen Prozess, der als „Rad“-Architektur bezeichnet wird. In diesem Artikel wird beschrieben, wie die Rad-Architektur im Vergleich zu herkömmlichen Architekturen funktioniert, und ihre Stärken und Schwächen werden identifiziert.
Was ist Rad-Architektur?
Betrachten Sie die Besucherdaten Ihrer Website wie Taschen, die am Flughafen auf einem Gepäckausgabeband zirkulieren. In diesem Beispiel besteht das Ziel darin, Taschen mit einer ähnlichen Farbe zu zählen, wenn sie vor Ihnen auftauchen.
Um die zirkulierenden Taschen abzufragen, können Sie die erste Tasche identifizieren und dann die nachfolgenden Taschen, die sich vor Ihnen bewegen, zählen.
Jedes Mal, wenn eine passende Tasche vorbei kommt, identifizieren Sie sie und listen die verschiedenen Typen auf. Dies ermöglicht es Ihnen, alle Taschen zu zählen und sie gemäß des Typs zusammenzufassen.
Wenn sich die erste Tasche wieder vor Ihnen befindet, wissen Sie, dass sie die gesamte Runde abgeschlossen hat. An diesem Punkt können Sie das Auflisten beenden und die Ergebnisse berichten.
Wenn auch andere Leute Ergebnisse abfragen müssen, können sie zu dem Rad gehen und die Taschen für genau eine Umrundung ansehen, beginnend mit derselben oder unterschiedlichen Umdrehungen des Rads. Dieses Ausgabeband oder Datenrad dreht sich immer weiter und eine Abfrage kann jederzeit beginnen und fortgesetzt werden, bis eine einzelne Umrundung abgeschlossen ist.
Außerdem gewährleistet Data Workbench, dass die Taschen auf dem Band in vollständig zufälliger Reihenfolge sind. (Die Fluglinien machen ihre Sache diesbezüglich ebenfalls gut.) Deshalb kann eine Abfrage von Umlaufdaten als zufällige Momentaufnahme der gesamten Daten gesehen werden, sodass Abfragen durch Ableiten des Ergebnisses auf die gesamten Population sehr schnell ungefähre Antworten errechnen können.
Bei 50 Datenstücken funktioniert dies möglicherweise nicht so gut. Aber mit Millionen oder Milliarden von Datenstücken, kann eine sehr genaue Schätzung der endgültigen Aufstellung fast unverzüglich extrahiert werden.
Ausführen detaillierter Abfragen
Lassen Sie uns diesen Vergleich weiter ausführen. Für genauere analytische Abfragen nehmen wir alle Dinge aus der Tasche (aber sortieren sie weiterhin in Gruppen je Reisender). Der Inhalt besteht aus kleiner Tasche, einer noch kleineren Organisiertasche und einzelnen Dingen.
Nun da der Abfragende direkt auf den Inhalt zugreifen kann, werden detailliertere Abfragen wie „Wie viele Reisende haben eine blaue Flasche dabei?“ kann erstellt werden.
Hierarchiestruktur in der Tasche
Lassen Sie uns den Gepäckvergleich zurück zu Besucherdaten für Analytics übersetzen: Eine Tasche für jeden Reisenden stellt alle Daten für einen Besucher dar, das Namensschildchen als Besucher-ID, kleine Taschen stellen einen Besuch dar, Organisiertaschen Treffer und einzelne Dinge Ereignisse.
Auf dem Data Workbench Client kann diese Struktur als Schemadiagramm beschrieben werden. Eine Beschreibung des Schemadiagramms finden Sie hier.
Der Vorgang Daten gemäß dieser Architektur zu organisieren wird „Log Processing“ genannt. Dies muss immer stattfinden, wenn sich die hierarchische Struktur erheblich ändert. Auch wenn dieser Vorgang Zeit braucht, am Ende haben Sie einen Datensatz, der für sehr schnelle analytische Abfragen optimiert ist.
Relationale Tabellen in der Gepäckanalogie
Vor der Beschreibung, wie sich das Datenrad von Tabellen unterscheidet, lassen Sie uns zuerst betrachten, wie der Gepäckvergleich für einen herkömmlichen Ansatz aussehen würde. In einer relationalen Datenbank würden Daten vielen Regalen mit Taschen darauf ähneln. Mit dieser traditionellen Architektur können Sie schnell eine neue Tasche einfügen oder eine bestimmte Tasche herausnehmen.
Für eine detailliertere Analyse müssen die Daten in den einzelnen Taschen extrahiert werden und in separate Regale wie dieses standardisiert werden.
In diesem Setup muss der Abfragende externe Schlüssel auflösen, um alle Dinge auf allen vier Regalen miteinander zu verknüpfen.
Aufwandsfaktor für analytische Abfragen
Wenn eine Abfrage für eine bestimmte Einheit vorgesehen ist, kann die relationale Datenbank die Abfrage sehr schnell abschließen. Beispielsweise eine Abfrage wie „Wie viele Ereignisse hat Herr Taro Adobe ausgelöst?“ würde von dem Abfragenden verlangen, nach einer Aufzeichnung in der Besuchertabelle, mehreren in der Besuchstabelle und weiteren Aufzeichnungen in den Treffer- und Ereignistabellen zu gucken. Es wäre auch eine Zählung der Ereignisse nötig. Es sind teure Schritte für die Datenbank, diese externen Schlüssel zu verwenden, aber es für eine Person zu tun, ist dennoch praktisch.
Eine analytische Abfrage ist jedoch offener und erfordert eine Antwort auf die Frage: „Wie viele Benutzer lösen wie viele Ereignisse pro Sitzung aus?“ Dazu ist eine Abfrage über viele Aufzeichnungen erforderlich, wobei der Abfragende die teuren Schritte für alle Benutzer wiederholt. Wenn Sie Millionen oder Milliarden Besucher haben, wird dies folglich schnell unpraktisch.
Durch die Verwendung von Datenrädern werden die Daten der einzelnen Besucher in einer einzigen Tasche organisiert, sodass der Abfragende jede Tasche auf einmal auswerten und zur nächsten übergehen kann, wodurch das Rad auf einen Schlag eine Abfrage fertigstellen kann. Deshalb ist Rad-Architektur besser für analytische Abfragen geeignet.
Der OLAP-Cube
Um die Geschwindigkeit von analytischen Abfragen zu verbessern, baut typische Business Intelligence (BI) auf eine mehrdimensionale Struktur mit vorausberechneten Zusammenfassungsdaten, die als OLAP-Cube bezeichnet wird. Durch Abfragen dieser Zusammenfassungen wird die Antwortzeit einiger Anwendungen deutlich kürzer, führt jedoch zu Problemen mit erweiterten Abfragen.
Als Beispiel, ein Unternehmen hat Kunden in 50 verschiedenen Staaten, 1000 Produktlinien und 10 Milliarden Transaktionen pro Jahr. Die Daten werden durch die Verwendung von dreidimensionalen Cubes basierend auf Stunde, Produkt und Staat gespeichert. Dies erfordert Vorausberechnungen von 1,2 Millionen Cubes.
In dieser Architektur kann die analytische Abfrage „Wie viele Produkte haben wir pro Stunde in jedem Staat verkauft?“ kann sehr schnell beantwortet werden, indem man sich eine Zusammenfassung der Cubes anschaut. Dies ist eine riesige Verbesserung gegenüber standardmäßigen Tabellenabfragen mit externen Verweisen.
Erhöhen der Granularität und Skalierung
Eine detailliertere Abfrage wie „Wie viele Produkte haben wir pro Minute in jedem Staat verkauft?“ erfordert jedoch für den OLAP-Cube Vorausberechnungen, die mit 60 multipliziert werden. Das Hinzufügen neuer Produkte, die Erweiterung der Anzahl an Ländern oder das Einführen neuer Dimensionen (basierend auf Größe, Geschlecht, Material usw.) verursachen, dass die OLAP-Cube-Zusammenfassung den Stapel exponentiell multipliziert.
Während der Stapel Cubes wächst, vergrößert sich die Aufwandszeit für Vorausberechnungen und Datenaktualisierungen und zwingt den Analysten Datensätze abzufragen, die häufig Tage hinterher sind. Dieser Transaktionsaufwand und das exponentielle Wachstum der Daten aller Tabellen erhöhen die Latenz und schränken analytische Abfragen, die OLAP-Cube-Architektur verwenden, erheblich ein.
Im Gegensatz dazu führt eine gleichwertige Erhöhung der Granularität auf dem Rad zu einem kleineren stufenweisen Wachstum.
Darüber hinaus werden, ohne Vorausberechnungsaufwand, neu hinzugefügte Daten kurz nach dem Eintreffen verfügbar. So können Analysten beinahe in Echtzeit abfragen. Im nächsten Artikel erfahren Sie mehr über die Verarbeitung in Echtzeit.
Abfragen von tatsächlichen Daten vs. Zusammenfassung der tatsächlichen Daten
Selbst wenn eine Organisation die enorme Kapazität hat, die Zusammenfassung fast in Echtzeit zu aktualisieren, sollte ein weiterer Faktor beachtet werden: Eine Abfrage des OLAP-Cube ist eine Abfrage der Datenzusammenfassung, wodurch sie weniger granulös und von Natur aus verlustreicher ist. Umgekehrt werden Abfrageergebnisse am Rad direkt aus den verarbeiteten Daten berechnet.
Zusammenfassung:
Wie in diesem Dokument beschrieben, kann die Funktionsweise von Adobe Analytics Data Workbench am besten als auf einem Rad platzierte Besucherdaten beschrieben werden, nicht als verbundene lineare Tabellen oder Regale. Es eignet sich besser, um für analytische Abfragen große Mengen an Daten zu untersuchen.
Die Kenntnis der inneren Funktionsweise dieses Datenbankmodells hilft Ihnen, die Vorteile zu Ihren Gunsten zu nutzen.