Systèmes d'analyse de serveur

Il s'agit de la deuxième partie d'une série d'articles sur les systèmes analytiques ( lien vers la partie 1 ).



Aujourd'hui, il ne fait aucun doute qu'un traitement précis des données et une interprétation des résultats peuvent aider presque tous les types d'entreprises. À cet égard, les systèmes analytiques sont de plus en plus chargés de paramètres, le nombre de déclencheurs et d'événements utilisateur dans les applications augmente.

Pour cette raison, les entreprises fournissent de plus en plus à leurs analystes des informations «brutes» pour analyse et en font les bonnes décisions. 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 durable.

Analyse client

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 ne peuvent pas être entièrement traitées comme vous le souhaitez, en raison des limites de tout service sélectionné. Par exemple, dans un système, il ne sera pas facile d'exécuter des tâches MapReduce, dans un autre, vous ne pourrez pas exécuter votre modèle. Un autre inconvénient sera une facture de services régulière (impressionnante).
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'y a pas de service universel adapté à chaque tâche (alors que les prix de tous ces services sont en constante augmentation). Dans cette situation, les entreprises décident souvent de créer leur propre système d'analyse avec tous les paramètres et fonctionnalités personnalisés nécessaires.

Analyse du serveur

L'analyse de serveur est un service qui peut être déployé en interne dans une entreprise sur ses propres serveurs et (généralement) par ses propres efforts. Dans ce modèle, tous les événements utilisateur sont stockés sur des serveurs internes, ce qui permet aux développeurs d'essayer différentes bases de données pour le stockage et de choisir l'architecture la plus pratique. Et même si vous souhaitez toujours utiliser des analyses client tierces pour certaines tâches, cela sera toujours possible.
L'analyse du serveur peut être déployée de deux manières. Tout d'abord: sélectionnez des utilitaires open source, déployez-les sur vos machines et développez la logique métier.

Avantages	Inconvénients
Vous pouvez personnaliser n'importe quoi	Souvent, c'est très difficile et des développeurs individuels sont nécessaires

Deuxièmement: prenez les services SaaS (Amazon, Google, Azure) au lieu de le déployer vous-même. À propos du SaaS plus en détail, nous le dirons dans la troisième partie.

Avantages	Inconvénients
Il peut être moins cher sur des volumes moyens, mais avec une croissance importante, il deviendra toujours trop cher	Impossible 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 qui se trouve à l'intérieur du service (il peut ne pas être nécessaire)

Comment collecter des analyses de serveur

Si nous voulons éviter d'utiliser l'analyse client et assembler la nôtre, nous devons tout d'abord réfléchir à l'architecture du nouveau système. Ci-dessous, je vais vous dire étape par étape ce qu'il faut considérer, pourquoi chacune des étapes est nécessaire et quels outils vous pouvez utiliser.

1. Acquisition de données

Tout comme dans le cas de l'analyse client, tout d'abord, les analystes de l'entreprise choisissent les types d'événements qu'ils souhaitent étudier à l'avenir et les rassemblent dans une liste. Habituellement, ces événements se déroulent dans un certain ordre, appelé «modèle d'événement».

Imaginez ensuite qu'une application mobile (site Web) a des utilisateurs réguliers (appareils) et de nombreux serveurs. Pour transférer en toute sécurité des événements des appareils vers les serveurs, une couche intermédiaire est nécessaire. Selon l'architecture, plusieurs files d'attente d'événements différentes peuvent se produire.

Apache Kafka est une file d'attente pub / sub qui est utilisée comme file d'attente pour la collecte d'événements.

Selon un article sur Kvor en 2014, le créateur d'Apache Kafka a décidé de nommer le logiciel d'après Franz Kafka parce que "c'est un système optimisé pour l'enregistrement" et parce qu'il aimait les œuvres de Kafka. - Wikipédia

Dans notre exemple, il existe de nombreux producteurs de données et leurs consommateurs (appareils et serveurs), et Kafka aide à les connecter les uns aux autres. Les consommateurs seront décrits plus en détail dans les prochaines étapes, où ils seront les principaux acteurs. Nous allons maintenant considérer uniquement les producteurs de données (événements).

Kafka encapsule les concepts de file d'attente et de partition; plus précisément, il est préférable de le lire ailleurs (par exemple, dans la documentation ). Sans entrer dans les détails, imaginez 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 appropriée.

(photo d'ici )

En même temps, Kafka vous permet de lire en morceaux et de traiter le flux d'événements avec des mini-chauves-souris. Kafka est un outil très pratique qui s'adapte bien aux besoins croissants (par exemple, par géolocalisation d'événements).

Habituellement, un fragment suffit, mais les choses deviennent plus difficiles en raison de la mise à l'échelle (comme toujours). 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, ils ont utilisé AWS Kinesis.

Avant de passer à l'étape suivante, nous devons mentionner une autre couche supplémentaire du système - le stockage des journaux bruts. Ce n'est pas une couche obligatoire, mais cela sera utile si quelque chose se passe mal 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 compliquée et coûteuse; vous pouvez simplement les enregistrer 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 des files d'attente appropriées, nous passons à l'étape de traitement. Ici, je vais parler des deux options de traitement les plus courantes.

La première option consiste à activer Spark Streaming sur un système Apache. Tous les produits Apache vivent dans HDFS, un système de fichiers de réplique de fichiers sécurisé. Spark Streaming est un outil facile à utiliser qui traite les données en streaming et évolue bien. Cependant, cela peut être un peu difficile à entretenir.

Une autre option consiste à créer votre propre gestionnaire d'événements. Pour ce faire, par exemple, vous devez écrire une application Python, la construire dans le menu fixe et vous abonner à la file d'attente Kafka. Lorsque les déclencheurs arrivent sur les gestionnaires du docker, le traitement démarre. Avec cette méthode, vous devez continuer à exécuter des applications en permanence.

Supposons que nous avons choisi l'une des options décrites ci-dessus et procédons au traitement lui-même. Les processeurs doivent commencer par vérifier la validité des données, filtrer les ordures et les événements "cassés". Pour la validation, nous utilisons généralement Cerberus . Après cela, vous pouvez faire un mappage de données: les données de différentes sources sont normalisées et normalisées pour être ajoutées à l'étiquette générale.

3. Base de données

La troisième étape consiste à maintenir les événements normalisés. Lorsque vous travaillez avec un système analytique prêt à l'emploi, nous devrons souvent les contacter, 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 Clickhouse ou une autre base de données de colonnes. Les agrégations fonctionneront donc très rapidement. L'inconvénient est que le schéma est fixé de manière rigide et que le pliage d'objets arbitraires sans raffinement échouera (par exemple, lorsqu'un événement non standard se produit). Mais vous pouvez compter très rapidement.

Pour les données non structurées, vous pouvez prendre NoSQL, par exemple, Apache Cassandra . Il fonctionne sur HDFS, est bien répliqué, vous pouvez déclencher de nombreuses instances, tolérant aux pannes.

Vous pouvez choisir quelque chose de plus simple, par exemple, MongoDB . C'est assez lent et pour de petits volumes. Mais le plus, c'est qu'il est très simple et donc adapté au démarrage.

4. Agrégations

Après avoir soigneusement sauvegardé tous les événements, nous voulons collecter toutes les informations importantes du lot qui est venu et mettre à jour la base de données. À l'échelle mondiale, nous voulons obtenir des tableaux de bord et des mesures pertinents. Par exemple, à partir d'événements pour collecter un profil utilisateur et mesurer en quelque sorte le comportement. Les événements sont agrégés, collectés et enregistrés à nouveau (déjà dans les tables utilisateur). Dans le même temps, vous pouvez créer le système de manière à connecter également un filtre à l'agrégateur-coordinateur: collecter les utilisateurs uniquement à partir d'un certain type d'événements.

Après cela, si un membre de l'équipe n'a besoin que d'analyses de haut niveau, vous pouvez connecter des systèmes d'analyse externes. Vous pouvez reprendre Mixpanel. mais comme c'est assez cher, il n'y envoie pas tous les événements utilisateur, mais seulement ce qui est nécessaire. Pour ce faire, vous devez créer un coordinateur qui transmettra certains événements bruts ou quelque chose que nous avons nous-mêmes agrégés précédemment à des systèmes externes, des API ou des plateformes publicitaires.

5. Frontend

Vous devez connecter le frontend au système créé. Un bon exemple est le service de redash , une interface graphique pour les bases de données qui aide à créer des panneaux. Comment fonctionne l'interaction:

1. L'utilisateur fait une requête SQL.
2. En réponse, reçoit une tablette.
3. Pour elle, elle crée une «nouvelle visualisation» et obtient un bel horaire qui peut déjà être sauvegardé pour elle-même.

Les visualisations dans le service sont mises à jour automatiquement, vous pouvez configurer et suivre votre surveillance. Redash est gratuit, en cas d'auto-hébergement, et comment le SaaS coûtera 50 $ par mois.

Conclusion

Après avoir effectué toutes les étapes ci-dessus, vous allez créer votre analyse de serveur. Veuillez noter que ce n'est pas un moyen aussi simple que de simplement connecter l'analyse client, car tout doit être configuré indépendamment. 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 consacrer.
Si vous avez tout calculé et que les coûts sont trop élevés, dans la partie suivante, je parlerai de la façon de créer une version moins chère de l'analyse de serveur.

Merci d'avoir lu! Je serai heureux de questions dans les commentaires.