Ceci est la deuxième partie d'une série d'articles sur les systèmes analytiques ().
Aujourd’hui, il ne fait plus aucun doute qu’un traitement minutieux des données et une interprétation minutieuse des résultats peuvent aider presque tout type d’entreprise. À cet égard, les systèmes analytiques sont de plus en plus chargés en paramètres et le nombre de déclencheurs et d'événements utilisateur dans les applications augmente.
Pour cette raison, les entreprises donnent à leurs analystes de plus en plus d’informations brutes à analyser et à transformer en décisions judicieuses. L'importance d'un système d'analyse pour une entreprise ne doit pas être sous-estimée et le système lui-même doit être fiable et stable.
Analystes clients
L'analyse client est un service qu'une entreprise connecte à son site Web ou à son application via le SDK officiel, l'intègre dans sa propre base de code et sélectionne les déclencheurs d'événements. Cette approche présente un inconvénient évident : toutes les données collectées peuvent ne pas être traitées exactement comme vous le souhaiteriez en raison des limitations du service que vous choisissez. Par exemple, sur un système il ne sera pas facile d'exécuter des tâches MapReduce, sur un autre vous ne pourrez pas exécuter votre modèle. Un autre inconvénient sera la facture régulière (impressionnante) des services.
Il existe de nombreuses solutions d'analyse client sur le marché, mais tôt ou tard, les analystes sont confrontés au fait qu'il n'existe pas de service universel adapté à chaque tâche (alors que les prix de tous ces services ne cessent d'augmenter). Dans une telle situation, les entreprises décident souvent de créer leur propre système d’analyse avec tous les paramètres et capacités personnalisés nécessaires.
Analystes de serveurs
L'analyse côté serveur est un service qui peut être déployé au sein d'une entreprise sur ses propres serveurs et (généralement) avec ses propres efforts. Dans ce modèle, tous les événements utilisateur sont stockés sur des serveurs internes, permettant aux développeurs d'essayer différentes bases de données de stockage et de choisir l'architecture la plus pratique. Et même si vous souhaitez toujours utiliser des analyses de clients tiers pour certaines tâches, cela sera toujours possible.
L'analyse côté serveur peut être déployée de deux manières. Premièrement : choisissez des utilitaires open source, déployez-les sur vos machines et développez une logique métier.
Avantages
Moins
Vous pouvez personnaliser tout ce que vous voulez
Ceci est souvent très difficile et nécessite des développeurs distincts
Deuxièmement : prenez les services SaaS (Amazon, Google, Azure) au lieu de les déployer vous-même. Nous parlerons plus en détail du SaaS dans la troisième partie.
Avantages
Moins
Cela peut être moins cher pour des volumes moyens, mais avec une forte croissance, cela deviendra encore trop cher.
Il ne sera pas possible de contrôler tous les paramètres
L'administration est entièrement transférée aux épaules du prestataire de services
On ne sait pas toujours ce qu'il y a à l'intérieur du service (cela peut ne pas être nécessaire)
Comment collecter des analyses de serveur
Si nous voulons abandonner l’utilisation de l’analyse client et créer la nôtre, nous devons tout d’abord réfléchir à l’architecture du nouveau système. Ci-dessous, je vais vous expliquer étape par étape ce que vous devez prendre en compte, pourquoi chaque étape est nécessaire et quels outils vous pouvez utiliser.
1. Réception de données
Tout comme dans le cas de l'analyse client, les analystes de l'entreprise sélectionnent tout d'abord les types d'événements qu'ils souhaitent étudier à l'avenir et les rassemblent dans une liste. Généralement, ces événements se produisent dans un ordre spécifique, appelé « modèle d'événement ».
Imaginez ensuite qu’une application mobile (site Web) compte des utilisateurs réguliers (appareils) et de nombreux serveurs. Pour transférer en toute sécurité les événements des appareils vers les serveurs, une couche intermédiaire est nécessaire. Selon l'architecture, il peut y avoir plusieurs files d'attente d'événements différentes.
- Est , qui est utilisé comme file d'attente pour collecter les événements.
selon en 2014, le créateur d’Apache Kafka a décidé de donner au logiciel le nom de Franz Kafka parce que « c’est un système optimisé pour l’écriture » et parce qu’il aimait les œuvres de Kafka. —
Dans notre exemple, il existe de nombreux producteurs et consommateurs de données (appareils et serveurs), et Kafka permet de les connecter les uns aux autres. Les consommateurs seront décrits plus en détail dans les étapes suivantes, dont ils seront les principaux sujets. Nous ne considérerons désormais que les producteurs de données (événements).
Kafka résume les concepts de file d'attente et de partition ; il est préférable de lire plus spécifiquement à ce sujet ailleurs (par exemple, dans ). Sans entrer dans les détails, imaginons qu'une application mobile soit lancée pour deux OS différents. Ensuite, chaque version crée son propre flux d'événements distinct. Les producteurs envoient des événements à Kafka, ils sont enregistrés dans une file d'attente adaptée.
(image )
Dans le même temps, Kafka vous permet de lire par morceaux et de traiter un flux d'événements par mini-lots. Kafka est un outil très pratique qui s'adapte aux besoins croissants (par exemple, par géolocalisation d'événements).
Habituellement, un seul fragment suffit, mais les choses deviennent plus compliquées lors de la mise à l'échelle (comme c'est toujours le cas). Personne ne voudra probablement utiliser un seul fragment physique en production, car l'architecture doit être tolérante aux pannes. En plus de Kafka, il existe une autre solution bien connue : RabbitMQ. Nous ne l'avons pas utilisé en production comme file d'attente pour l'analyse d'événements (si vous avez une telle expérience, parlez-nous-en dans les commentaires !). Cependant, nous avons utilisé AWS Kinesis.
Avant de passer à l'étape suivante, nous devons mentionner une couche supplémentaire supplémentaire du système : le stockage des journaux bruts. Ce n'est pas une couche obligatoire, mais elle sera utile si quelque chose ne va pas et que les files d'attente d'événements dans Kafka sont réinitialisées. Le stockage des journaux bruts ne nécessite pas de solution complexe et coûteuse : vous pouvez simplement les écrire quelque part dans le bon ordre (même sur un disque dur).
2. Traitement des flux d'événements
Après avoir préparé tous les événements et les avoir placés dans les files d'attente appropriées, nous passons à l'étape de traitement. Ici, je vais vous parler des deux options de traitement les plus courantes.
La première option consiste à activer Spark Streaming dans le système Apache. Tous les produits Apache fonctionnent sur HDFS, un système de fichiers sécurisé avec des répliques de fichiers. Spark Streaming est un outil facile à utiliser qui gère les données en streaming et qui évolue bien. Cependant, cela peut être difficile à maintenir.
Une autre option consiste à créer votre propre gestionnaire d’événements. Pour ce faire, par exemple, vous devez écrire une application Python, la créer dans Docker et vous abonner aux files d'attente de Kafka. Lorsque les déclencheurs arrivent aux gestionnaires du docker, le traitement démarre. Avec cette méthode, vous devez maintenir les applications en cours d’exécution à tout moment.
Supposons que nous ayons choisi l'une des options décrites ci-dessus et passons au traitement lui-même. Les processeurs doivent commencer par vérifier la validité des données, en filtrant les déchets et les événements « interrompus ». Pour la validation, nous utilisons habituellement . Après cela, vous pouvez effectuer un mappage de données : les données provenant de différentes sources sont normalisées et standardisées afin d'être ajoutées à un tableau commun.
3. Base de données
La troisième étape consiste à maintenir des événements normalisés. Lorsque nous travaillons avec un système analytique prêt à l'emploi, nous devrons y accéder souvent, il est donc important de choisir une base de données pratique.
Si les données s'intègrent bien dans un schéma fixe, vous pouvez choisir ou une autre base de données en colonnes. De cette façon, les agrégations fonctionneront très rapidement. L'inconvénient est que le schéma est rigidement fixé et qu'il ne sera donc pas possible d'ajouter des objets arbitraires sans modification (par exemple, lorsqu'un événement non standard se produit). Mais on peut vraiment compter très vite.
Pour les données non structurées, vous pouvez prendre NoSQL, par exemple, . Il fonctionne sur HDFS, se réplique bien, vous pouvez générer de nombreuses instances et est tolérant aux pannes.
Vous pouvez également soulever quelque chose de plus simple, par exemple : . C'est assez lent et pour de petits volumes. Mais le plus c'est que c'est très simple et donc adapté pour débuter.
4. Agrégations
Après avoir soigneusement enregistré tous les événements, nous souhaitons collecter toutes les informations importantes du lot arrivé et mettre à jour la base de données. À l’échelle mondiale, nous souhaitons obtenir des tableaux de bord et des mesures pertinents. Par exemple, collectez un profil utilisateur à partir d'événements et mesurez d'une manière ou d'une autre le comportement. Les événements sont regroupés, collectés et enregistrés à nouveau (dans les tables utilisateur). Dans le même temps, vous pouvez construire un système permettant de connecter également un filtre à l'agrégateur-coordinateur : collecter les utilisateurs uniquement à partir d'un certain type d'événement.
Après cela, si un membre de l’équipe n’a besoin que d’analyses de haut niveau, des systèmes d’analyse externes peuvent être connectés. Vous pouvez reprendre Mixpanel. mais comme c'est assez cher, tous les événements utilisateur n'y sont pas envoyés, mais seulement ce qui est nécessaire. Pour ce faire, nous devons créer un coordinateur qui transférera certains événements bruts ou quelque chose que nous avons nous-mêmes agrégés précédemment vers des systèmes externes, des API ou des plateformes publicitaires.
5. Front-end
Vous devez connecter le frontend au système créé. Un bon exemple est le service , est une interface graphique de base de données qui permet de créer des tableaux de bord. Comment fonctionne l'interaction :
- L'utilisateur effectue une requête SQL.
- En réponse, il reçoit un signe.
- Il crée une « nouvelle visualisation » et obtient un magnifique graphique que vous pouvez enregistrer pour vous-même.
Les visualisations du service se mettent à jour automatiquement, vous pouvez personnaliser et suivre votre surveillance. Redash est gratuit s'il est auto-hébergé, mais en tant que SaaS, il coûtera 50 $ par mois.
Conclusion
Après avoir terminé toutes les étapes ci-dessus, vous créerez vos analyses de serveur. Veuillez noter que ce n'est pas aussi simple que de simplement connecter les analyses client, car tout doit être configuré vous-même. Par conséquent, avant de créer votre propre système, il convient de comparer la nécessité d'un système d'analyse sérieux avec les ressources que vous êtes prêt à lui allouer.
Si vous avez fait le calcul et constaté que les coûts sont trop élevés, dans la partie suivante, j'expliquerai comment créer une version moins chère de l'analyse côté serveur.
Merci d'avoir lu! Je serai heureux de poser des questions dans les commentaires.
Source: habr.com