Cluster pour Data Workbench

Cet article est une illustration simplifiée du produit. Il est destiné à aider les analystes à visualiser quelle entité remplit quel rôle.  Les lecteurs sont encouragés à consulter nos documentations pour obtenir des informations détaillées sur ce qui est couvert dans cet article.

Acteurs clés

Auparavant, nous avons discuté de la manière dont les données des visiteurs individuels sont construites ici, et de la manière dont les données des visiteurs forment le jeu de données ici.  Nous revenons plus loin et regardons l’ensemble du cluster dans cet article.

DPU - Jeu de données conservateur -

DPU (Data Processing Unit) est le dépositaire d’un cluster. Lorsque vous jouez le rôle de Processing Server, le DPU génère un ensemble de données interrogeable sur temp.db local (porte-carte).

DPU joue également le rôle de Query Server où elle agit comme un point de contact unique entre une application client et les autres DPU.

FSU en tant que serveur primaire - Coordinateur de jeu de données -

Une équipe de serveurs a besoin d’un superviseur et un FSU (File Server Unit) remplit ce rôle en tant que serveur primaire.  Il stocke une copie principale de l’architecture (schéma) du jeu de données, des configurations et des paramètres de performance.  Le serveur primaire est également appelé Synch Server.

FSU pour les rôles non primaires

Pour alléger la charge de travail du serveur primaire, certains rôles peuvent être délégués à des FSU supplémentaires.  Nous traiterons brièvement de l’indexation des données décodées (normalisation), de l’exportation d’un ensemble de données (exportation de segment) et de la conversion des fichiers journaux bruts (transformation).

Pour un petit cluster, une FSU est souvent suffisante pour remplir tous les rôles de gestion. À mesure que votre cluster se développe, Primary Server peut être dépassé.  Adobe recommande l’utilisation d’une FSU supplémentaire si elle devient le goulot d’étranglement.

Remarque :

Pour les autres rôles FSU (serveur de journalisation, serveur de liste de sources et serveur de fichiers) et les composants (capteur et répéteur), consultez notre documentation ici.

Client

Le Data Workbench Client est l’application frontale. Les analystes l’utilisent pour exécuter une requête sur son serveur de requêtes, un architecte l’utilise pour configurer le schéma sur le serveur primaire et l’administrateur l’utilise pour gérer différents serveurs.

Report Server

Report Server automatise la fonctionnalité de création de rapports de l’application client. Il exécute des requêtes à partir d’un jeu de rapports et fournit la sortie via différents canaux.

Construire un jeu de données interrogeable

Synchronisation - Instructions de partage -

Au début, les DPU ne savent pas où trouver du matériel ou comment les traiter.  Grâce à la synchronisation, ils vont récupérer les instructions, le schéma et la carte des ressources du serveur primaire (FSU).

Les instructions sont maintenant fournies, mais le porte-carte est toujours vide.

Processus de journal - Processus de journal - Dataset de construction -

En utilisant les instructions et la carte synchronisées, chaque DPU trouve les fichiers journaux et commence à les décoder. 

Si un événement décodé appartient à un visiteur existant, il est ajouté à ses cartes.  S’il s’agit d’un visiteur sur un autre DPU, il est transféré.  Enfin, si l’événement n’appartient à aucun visiteur existant, une nouvelle carte est créée.

Les visiteurs sont répartis de manière égale entre tous les DPU.  Par exemple, sur un cluster de 10 DPU avec 5 millions de visiteurs, chaque DPU détient des données pour 500 000 visiteurs.  Cependant, comme chaque visiteur a une taille de données différente, la taille de temp.db ne sera pas la même pour tous les DPU (même si elles ont tendance à être très proches).

Normalisation - Indexation des données décodées -

Au fur et à mesure que chaque DPU traite l’entrée, les éléments de dimension sont indexés simultanément sur le serveur de normalisation.

En règle générale, un FSU remplit le rôle du serveur primaire et du serveur de normalisation.

Une fois le processus de journalisation terminé, nous aurons un jeu de données interrogeable.

Analyse interactive avec le client de Data Workbench

Enfin, le jeu de données est prêt pour les analystes.  Pour une analyse approfondie, une série de requêtes est exécutée au fur et à mesure qu’une question en amène une autre, et il est préférable d’utiliser le client de Data Workbench.

    1. Affectez le serveur de requête

Tout d’abord, le client de Data Workbench se connecte à un serveur primaire et l’un des DPU sera affecté à son serveur de requêtes.

L’application cliente est maintenant "en ligne" avec le profil de jeu de données.  À partir de ce moment, ce DPU devient un point de contact pour ce client.

    2. Requêtes d’exécution

Le client enverra la chaîne de requête à son serveur de requête.  Une fois la requête reçue, Query Server transmet la même demande aux autres DPU.  Il exécute également la requête sur son propre temp.db (titulaire de la carte) et renvoie le résultat au client avec les résultats des autres DPU.

De retour du côté du client, les résultats de la requête seront traduits sous différentes formes de visualisations au fur et à mesure de leur diffusion.  L’espace de travail terminé peut également être enregistré en tant que modèle pour Report Server.

Rapport planifié avec Report Server

Report Server automatise les exécutions de requêtes.   À un moment donné, il récupère un ensemble de rapports sur le serveur primaire et les exécute, puis les transmet par le biais de diverses méthodes, telles que les e-mails.

Exportation d’un jeu de données avec exportation de segment

Des segments spécifiques du jeu de données peuvent être exportés en tant que fichiers texte délimités. Basé sur le fichier de définition d’exportation (*.export), chaque DPU filtre son partage de données et les envoie au serveur d’exportation de segment.

Les données exportées des DPU sont regroupées dans un fichier sur le Segment Export Server et téléchargées sur un emplacement spécifié.  Le fichier est généralement importé dans divers outils d’analyse tiers ou applications personnalisées pour une analyse ultérieure.

Remarque :

Tout comme le rôle du serveur de normalisation, un FSU peut remplir le rôle d’exportation primaire et segment sur un petit cluster.  Cependant, comme il implique un lot de transmissions de données volumineuses, l’exportation de segments peut facilement affecter les ressources de FSU.

Conversion de sources de journal avec Transform

FSU peut fonctionner comme un Transform Server.  Contrairement aux exportations de segments (exportation de jeux de données en texte), Transform est une simple conversion de texte en texte.  Il prend également un ou plusieurs types d’entrées de texte et les fusionne en un seul fichier texte tel que Sensor données (.vsl), fichiers journaux, fichiers XML et données ODBC (texte).  Il est souvent utilisé pour prétraiter les données brutes avant de les alimenter dans un jeu de données.

Comme vous le voyez, les opérations Transform Server (FSU) peuvent être exécutées sans jeu de données ou DPU.  Pour cette raison, le serveur Transform s’exécute souvent indépendamment.

 Adobe

Recevez de l’aide plus rapidement et plus facilement

Nouvel utilisateur ?