Dieser Artikel ist eine vereinfachte Illustration des Produkts. Es soll Analysten unterstützen, um zu sehen, welche Einheit die Rolle erfüllt. Wir empfehlen Ihnen, unsere Dokumentationen einzusehen. Dort finden Sie ausführliche Informationen, die in diesem Artikel beschrieben werden.
DPU (Data Processing Unit) ist der Verwalter eines Clusters. Wenn die DPU als Verarbeitungs-Server agiert, generiert diese abzufragende Datensätze auf dem lokalen temp.db (Karteninhaber).
Die DPU nimmt ebenfalls die Rolle als Abfrageserver an, wo sie als zentraler Anknüpfungspunkt von einer Clientanwendung zu anderen DPUs agiert.
Um die Arbeitsbelastung des primären Servers zu erleichtern, können einige Aufgaben an zusätzliche FSUs delegiert werden. Wir werden die Indexierung von dekodierten Daten (Normalisierung), den Export von Datensätzen (Segmentexport) und die Konvertierung von unverarbeiteten Protokolldateien (Transformieren) kurz behandeln.
Für einen kleinen Cluster reicht ein FSU häufig aus, um alle Verwaltungsaufgaben zu erfüllen. Beim Vergrößern des Clusters kann der primäre Server überlastet werden. Adobe empfiehlt die Verwendung einer zusätzlichen FSU, um einen Engpass zu vermeiden.
Hinweis:
Für andere FSU-Aufgaben (Protokollierungsserver, Quelllisten-Server und Dateiserver) und Komponenten (Sensor und Repeater), wenden Sie sich bitte „hier“ an unsere Dokumentation.
DPUs wissen zuerst einmal nicht, wo verschiedene Materialien zu finden sind oder wie sie verarbeitet werden. Durch Synchronisierung werden die Anweisungen, das Schema und die Ressourcenkarte vom primären Server (FSU) abgerufen.
Mithilfe der synchronisierten Anweisungen und Karte findet jeder DPU die Protokolldateien und beginnt mit der Dekodierung.
Wenn ein entschlüsseltes Ereignis zu einem vorhandenen Besucher gehört, wird es an die entsprechenden Karten angehängt. Wenn es zu einem Besucher auf einem anderen DPU gehört, wird er weitergeleitet. Wenn das Ereignis zu keinem vorhandenen Besucher gehört, wird eine neue Karte erstellt.
Besucher werden gleichmäßig auf alle DPUs verteilt. Zum Beispiel: Auf einem 10-DPU-Cluster mit 5 Millionen Besuchern verwaltet jeder DPU die Daten von 500,000 Besuchern. Da jedoch jeder Besucher eine unterschiedliche Datengröße hat, ist die Größe von „temp.db“ nicht auf allen DPUs gleich (Obwohl sie in der Regel nah beinander liegen)
Während jedes DPU die Eingabe ausführt, werden die Dimensionselemente gleichzeitig auf dem Normaliserungsserver indiziert.
Schließlich ist der Datensatz für Analysten bereit. Für eine detaillierte Analyse werden mehrere Abfragen ausgeführt, was von einer Frage zur anderen führt. Für dies wird am besten der Data Workbench-Client verwendet.
Zunächst stellt der Data Workbench-Client eine Verbindung zu einem primären Server her und einer der DPUs wird als Abfrageserver zugewiesen.
Die Clientanwendung ist jetzt „Online“ mit dem Datensetprofil. Ab diesem Zeitpunkt wird dieser DPU zu einem Kontakt für diesen Client.
Der Client sendet Abfragezeichenfolgen an den Server. Nachdem die Abfrage empfangen wurde, leitet der Abfrageserver die gleiche Anforderung an andere DPUs weiter. Außerdem wird die Abfrage anhand ihres eigenen „temp.db“ (Kartenhalter) ausgeführt und das Ergebnis wird zusammen mit anderen DPUs an den Client zurückgegeben.
Auf der Client-Seite werden Abfrageergebnisse in verschiedene Visualisierungen übersetzt, wenn sie im Strom ankommen. Der fertige Arbeitsbereich kann auch als Vorlage für den Berichtsserver gespeichert werden.
Der Berichtsserver automatisiert die Fragendurchführungen. Zu einem bestimmten Zeitpunkt wird ein Bericht von dem primären Server abgerufen und ausgeführt und dann über verschiedene Methoden wie E-Mails bereitgestellt.
Bestimmte Segmente des Datensatzes können als abgegrenzte Textdateien exportiert werden. Basierend auf der Exportdefinitionsdatei (*.export) filtert jeder DPU seine Daten aus und sendet sie an den Segment-Export-Server.
Exportierte Daten aus DPUs werden in eine Datei auf dem „Segment-Export-Server“ kombiniert und auf einen bestimmten Standort hochgeladen. Die Datei wird in der Regel in verschiedene Analyseinstrumente von Drittanbietern oder benutzerdefinierte Anwendungen für die weitere Analyse importiert.
Hinweis:
Ebenso wie die Rolle des Normaliserungsservers, kann eine FSU die primäre Rolle sowohl als auch die Segment-Export-Rolle in einem kleinen Cluster einnehmen. Da es jedoch einen Stapel großer Datenübertragungen erfordert, kann der Segmenten-Export die Ressourcen von FSU leicht überlasten.
FSU kann als Konvertierungsserver agieren. Im Gegensatz zum Segmentenexport, welcher einen Datensatz zu Text exportiert, ist „Transformieren“ eine einfache Text-zu-Text-Konvertierung. Es werden ebenfalls eine oder mehrere Arten von Texteingaben und deren Zusammenführung in eine Daten benötigt, wie z. B. Sensor-Daten (.vsl), Protokolldateien, XML-Dateien und ODBC-Daten (Text). Es wird häufig verwendet, um die Rohdaten vor der Zuführung zu einem Datensatz vorzuverarbeiten.
Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.