Cube virtuel - au lieu d'OLAP

Lorsque vous faites le contraire et obtenez la même chose ...

Ayant pour tâche de traitement analytique (calcul / agrégation) des données, vous devez trouver un compromis entre réactivité, rapidité et commodité.

Certains systèmes sont bien indexés et trouvés, d'autres peuvent rapidement calculer et agréger des données, tandis que d'autres sont simples. Quelque part, il est nécessaire d'organiser le préchargement et l'indexation des données avec toutes les difficultés associées, et quelque part l'utilisateur dispose d'une abstraction de son modèle de source et de données agrégées au-dessus des stockages physiques et des bases de données externes ou intégrés utilisés directement pendant les calculs. Dans tous les cas, l'utilisateur, du programmeur à l'analyste, doit faire un travail relativement important, en commençant par préparer des données brutes et compiler des requêtes, des modèles informatiques, pour finir par visualiser le résultat sur des widgets, bien sûr, «Sexy» - beau, réactif et compréhensible - sinon tout le travail accompli ira à l'égout. Et souvent, comme par hasard, en passant par les affres du choix d'une solution, nous remarquons comment une tâche simple et compréhensible à première vue se transforme en un monstre effrayant, inutile de se battre avec les moyens disponibles, et nous devons inventer d'urgence quelque chose - un vélo "avec blackjack et putes" ©. Notre vélo est parti, il fait même un bon tour de bosses et fait face à des obstacles que l'on ne pouvait que deviner auparavant.

Ci-dessous sera décrit un côté du dispositif interne d'origine du "Rubik's Cube" fictif - traitement informatique pour la visualisation interactive des données.

Une tâche simple doit être résolue simplement, et une tâche difficile doit également être simple, mais plus longue ...

Commençant à créer un système avec de petites forces, nous sommes passés du simple au complexe. En créant un constructeur, nous étions convaincus en interne que nous comprenons bien la finalité du système, en luttant simultanément avec le désir de ne pas en faire trop et le désir opposé d'automatiser tout et tout, créant un cadre pour tout. De plus, l'un de nos merveilleux frameworks était prêt et même testé en production - jsBeans. Nous avons donc commencé à développer le prochain système de traitement de données, qui a grandi et qui est maintenant en même temps un produit auto-suffisant - un concepteur et une plate-forme pour développer toute une classe de systèmes de traitement de données. Conditionnellement, dans l'article, nous l'appellerons «Rubik's Cube» afin de se passer de publicité, mais pour décrire des solutions intéressantes, à notre avis.

Cube, tranche, mesure

La tâche principale - disposer d'ensembles de données non liées, y compris des bases de données et des fichiers externes hétérogènes, pour former un modèle multidimensionnel à partir d'éléments interconnectés des données sources et des résultats de leur traitement analytique pour la visualisation sur des tableaux de bord dynamiques et des widgets interconnectés.

Mettez simplement, par exemple, comme un tableau de bord cliquable:

Un tel modèle de données multidimensionnel dans notre système est appelé «Cube» et représente littéralement une collection abstraite d'ensembles de données mutables appelés «Slice», interconnectés par des champs / colonnes de sortie communs (affichés) ou des champs internes appelés «Dimensions» et utilisés pour filtrer et reliant les tranches les unes aux autres.

Une tranche peut être représentée comme une table ou vue virtuelle ( CTE ) avec des paramètres et un corps de requête variable, selon les conditions de filtrage. L'essentiel est que les données de sortie changent, en fonction des conditions de recherche de contexte (à l'intérieur du widget) et du filtre global, qui est construit en sélectionnant des valeurs sur les widgets et en utilisant des fonctions logiques de base (AND / OR / NOT) et des combinaisons.

Le filtre global vous permet de "faire tourner le Rubik's Cube", comme dans la vidéo :

Si le champ de sortie d'une tranche est en même temps une mesure dans une autre tranche, a le même nom, alors les valeurs de ce champ sont perçues par le système comme des «faits» (si nous parlions d' OLAP ), définies sous la forme d'un filtre global qui modifie les ensembles de données d'origine lors des calculs et de l'agrégation . En conséquence, il existe une interaction dynamique de widgets, dans laquelle les valeurs des indicateurs affichés dépendent des éléments et des filtres sélectionnés.

Une tranche est un ensemble de données qui peuvent être modifiées "par des mesures" - initiales ou les résultats de calculs analytiques; caractérisé par des champs / colonnes de sortie, une liste de mesures prises en charge et un ensemble de paramètres avec des valeurs par défaut; décrit par une requête relativement élégante dans un éditeur visuel qui prend en charge le filtrage, le tri, le regroupement / l'agrégation, les intersections (JOIN), les unions (UNION), la récursivité et d'autres manipulations.

Les tranches qui s'utilisent comme sources décrivent la structure interne d'un cube, par exemple:

Exemple de slicer dans l'éditeur:

Une tranche prend en charge à la fois les mesures spécifiées explicitement dans les champs de sortie et hérite des mesures des sources de requête - cela signifie que la sortie de la tranche peut être modifiée même en raison de changements dans d'autres sources de tranches. En d'autres termes, les résultats de la tranche peuvent être filtrés non seulement par les champs de sortie, mais également par les mesures de champs internes des sources, quelque part dans la profondeur de la requête, jusqu'aux tables de base de données primaires.

La structure de la requête est développée et modifiée automatiquement par le système au moment de l'exécution, en fonction du filtre global actuel et des paramètres d'entrée, en les faisant glisser plus profondément dans la requête en fonction du modèle de cube, des mesures déclarées et des tranches.

Un exemple de filtre global simple, littéralement, lorsqu'un utilisateur a validé ou sélectionné des valeurs sur plusieurs widgets:

Le filtre global est stocké dans une requête JSON:

La demande parvient à la source primaire (à la base de données) déjà sous forme préparée, après avoir traversé plusieurs étapes principales:

• Demander l'assemblage, y compris la sélection et l'incorporation de tranches optimales, en tenant compte du filtre global actuel (lorsque le filtre est absent ou simple, vous pouvez sélectionner des tranches simples / rapides; lorsque le filtre est complexe - tranches avec une structure complexe et des mesures supplémentaires);
• Intégrer un filtre global et ajouter des filtres aux corps des requêtes et des sous-requêtes;
• Intégrer des macros et des expressions de requête de modèle;
• Optimisation des requêtes, y compris la suppression des champs et expressions inutilisés;
• Opérations supplémentaires avec la requête pour les spécificités des bases de données primaires (par exemple, si nous parlons de SQL et que la base de données ne contient pas WITH, les requêtes nommées sont intégrées).

Et la dernière étape est la traduction de la demande au format de la source principale, par exemple, en SQL:

Quand les sources sont différentes

En règle générale, tout est simple et clair lorsque vous devez travailler avec un seul entrepôt de données. Mais, lorsqu'il y en a plusieurs et qu'ils sont fondamentalement différents - vous devez appliquer des astuces différentes pour chaque tâche spécifique. Et vous voulez toujours avoir une solution universelle qui soit toujours adaptée, de préférence prête à l'emploi, avec un maximum de modifications mineures. Pour ce faire, une autre abstraction le supplie: sur les entrepôts de données, d'une part, la mise en œuvre de l'harmonisation des formats et des langages de requête, et d'autre part, la garantie de l'interdépendance des données, au moins au niveau des conditions de filtrage supplémentaires dans les requêtes à une source par des valeurs provenant d'une autre.

Pour ce faire, nous avons développé un langage de requête universel, adapté à la fois pour représenter un modèle virtuel de données de cube et pour travailler avec des stockages arbitrairement conditionnels en traduisant la requête dans le format et la langue souhaités. Par une heureuse coïncidence, le langage de requête, initialement destiné à la simple cartographie et au filtrage des données de diverses sources, est facilement devenu un langage de recherche et de traitement de données à part entière qui permet de construire des constructions de calcul du plus simple au plus complexe en plusieurs pages et avec de nombreuses sous-requêtes.

Les sources peuvent être divisées en trois types:

1. fichiers de données à télécharger sur le système;
2. Bases de données prenant en charge le traitement complet des données et d'autres opérations;
3. les stockages qui prennent en charge uniquement l'extraction de données avec ou sans filtrage, y compris divers types de services externes.

Tout est sans ambiguïté avec le premier type - le module d'importation est intégré dans le système, qui analyse différents formats d'entrée et plonge les résultats dans le référentiel. Pour l'importation, un constructeur spécial a également été développé, qui devrait être discuté séparément.

Le deuxième type est celui des bases de données autonomes, pour lesquelles il vous suffit de traduire la requête d'origine dans le format et la langue souhaités de la requête, le dialecte.

Le troisième type nécessite au moins des données de post-traitement. Et tous les types en même temps peuvent également nécessiter un post-traitement - intersections, unions, agrégation et calculs finaux. Cela se produit lorsque le traitement des données dans une base de données doit être effectué en tenant compte des résultats du filtrage dans un autre externe.

L'exemple le plus simple est lorsqu'une recherche floue est effectuée dans une base de données et qu'en sortie, il est nécessaire d'obtenir une agrégation d'indicateurs stockés dans une autre base de données sur un autre serveur, en tenant compte des résultats de la recherche.

Pour implémenter le travail d'un tel schéma, un algorithme simple est implémenté dans notre système - la requête initiale est préparée simultanément par plusieurs interprètes, chacun pouvant soit refuser d'exécuter la requête lorsqu'elle est incompatible, soit renvoyer un itérateur avec des données, soit transformer la requête et lancer le travail de la chaîne de préparation de la requête suivante par un autre interprète . Par conséquent, pour une seule demande, nous obtenons d'un à plusieurs itérateurs paresseux qui forment le même résultat, mais de différentes manières, parmi lesquelles le meilleur est sélectionné (selon divers critères définis par le développeur dans la configuration).

La stratégie de sélection de l'itérateur est spécifiée dans les paramètres de configuration ou de requête. Actuellement, plusieurs stratégies majeures sont prises en charge:

• premier, tout, dernier;
• par type de base de données prioritaire;
• par priorité des chaînes qui formaient les itérateurs;
• par la fonction de pondération de la "pondération de la demande";
• selon le premier résultat - tous les itérateurs sont lancés en parallèle et le premier résultat est attendu, par conséquent, l'itérateur le plus rapide est utilisé, les autres sont fermés.

À la suite d'une telle combinaison pour une demande d'entrée, nous obtenons plusieurs options pour son exécution, à la fois en utilisant différentes sources et avec différentes stratégies d'exécution - en choisissant la base de données principale / cible dans laquelle la partie principale de la demande sera exécutée et l'assemblage final des résultats.

Si le SGBD cible prend en charge la connexion de sources externes, il devient possible de créer un circuit inverse dans lequel le SGBD est connecté à l'API système pour recevoir de petites quantités de données du système, par exemple, pour filtrer de gros volumes "en place". Cette intégration est transparente pour l'utilisateur final et l'analyste - le modèle de cube ne change pas et toutes les opérations sont effectuées automatiquement par le système.

Pour les cas plus complexes, le système implémente un interpréteur de requêtes en mémoire interne sur le remarquable moteur de base de données H2 Embedded, qui permet d'intégrer n'importe quelle base de données prise en charge prête à l'emploi. Littéralement, cela fonctionne comme ceci - la demande est divisée en morceaux par groupes de sources, envoyés pour exécution, après quoi l'assemblage et le traitement final des résultats sont effectués en mémoire, dans H2.

À première vue, un tel schéma d'intégration de données au niveau de l'interpréteur interne semble «difficile», et cela est vrai si vous devez travailler avec de grands volumes de données d'entrée et la nécessité d'effectuer des calculs après intersections et associations d'ensembles de sources externes. En fait, cette circonstance est partiellement nivelée - en même temps, la demande est exécutée par plusieurs gestionnaires dans différentes versions, par conséquent, l'interpréteur n'est utilisé que dans les cas les plus extrêmes, comme solution universelle prête à l'emploi. En fin de compte, toute intégration est limitée par les coûts de transport typiques de préparation, de transmission sur le réseau et de réception de données, et c'est une tâche complètement différente.

Côté technique

Du point de vue technique, dont vous ne pouvez probablement pas vous passer, en abordant ce sujet, le système est également conçu selon le principe - pour faire plus, mais tout simplifier autant que possible.

Le système de traitement des données est implémenté au-dessus du cadre client-serveur jsBeans sous la forme d'un ensemble de modules supplémentaires et de projets d'assemblage spécifiques. jsBeans, à son tour, est implémenté en Java, fonctionne comme un serveur d'applications, en gros est un groupe de Rhino, Jetty et Akka, et comprend également la technologie de bean client-serveur développée par notre équipe, et une riche bibliothèque de composants assemblés sur plusieurs années d'application réussie.

Le Rubik's Cube est complètement et complètement implémenté en JavaScript sous la forme de nombreux js-bins (fichiers * .jsb), dont certains ne fonctionnent que sur le serveur. L'autre partie est sur le client, et le reste est un composant composant, fonctionnant comme un tout distribué, dont les parties interagissent les unes avec les autres, transparentes pour le développeur, mais sous son contrôle. Les bacs Js peuvent avoir différentes stratégies de vie, par exemple, avec ou sans session utilisateur, et bien plus encore. Le bean est isomorphe; il permet au client et au serveur de travailler avec lui comme une instance virtuelle d'une classe régulière. Le bac est décrit par un seul fichier et comprend trois sections - pour les champs et les méthodes s'exécutant sur le client, pour les champs du serveur, ainsi qu'une section de champs synchronisés communs.

Étant donné que l'article s'est déjà révélé verbeux pour ne pas ennuyer les lecteurs, il est temps de procéder à l'achèvement, avec l'intention de décrire bientôt les détails et les solutions architecturales les plus intéressantes dans la mise en œuvre de JsBeans et de nos projets basés sur celui-ci - le sous-système de visualisation construit, les processus analytiques, le concepteur ontologique des sujets, la langue requêtes, importation de données et autre chose ...

Pourquoi

Cela ne s'est jamais produit auparavant, et là encore ...

Au départ, il y avait peu d'ensembles de données primaires. Les sujets et les tâches ont été complètement spécifiés. Il semblerait, pourquoi un tel tourment? La tâche semblait simple, tout le monde voulait obtenir le résultat immédiatement - en particulier lorsque la solution rapide reposait à la surface, et la bonne exigeait de la persévérance et des décisions équilibrées, en respectant la configuration d'origine. Nous sommes allés dans la direction opposée, des solutions complexes et longues aux solutions simples et rapides, sur la voie de la généralisation de problèmes particuliers.

La condition principale est que de nouveaux tableaux de bord doivent être construits rapidement, même si le nouveau domaine et les besoins analytiques sont très différents des précédents. Évidemment, vous ne devinerez même pas la moitié des exigences futures, le système doit être flexible en premier lieu. Affiner la bibliothèque de composants, les algorithmes analytiques, connecter de nouveaux types de sources fait partie intégrante de l'adaptation du système. En d'autres termes, le groupe a fonctionné - les analystes créent des requêtes et des tableaux de bord, et les programmeurs réalisent rapidement de nouveaux besoins pour eux. Et nous, en tant que programmeurs, avons d'abord cherché à simplifier notre travail à l'avenir, en essayant de ne pas nuire à la convivialité.

Et le système a été immédiatement créé universel et adaptatif - nous avons construit un «constructeur par constructeur», développant un cadre au-dessus d'un cadre précédemment créé avec un objectif similaire, mais encore plus général.

La notation des écoles de Moscou sur la base des résultats de l'examen d'État unifié et des olympiades est un exemple de tableau de bord construit de la manière décrite ci-dessus à partir du déchargement du portail de données ouvertes du gouvernement de Moscou.

Cube-Rubik est une plate-forme de base pour le développement de systèmes d'information et d'analyse. Conçu comme une branche et une suite logique de jsBeans. Il comprend tous les modules nécessaires pour résoudre les problèmes de collecte, de traitement, d'analyse (informatique et orientée processus) et de visualisation.

jsBeans est un framework web isomorphe à pile complète qui implémente la technologie JavaScript bean client-serveur, développée avec une licence ouverte comme outil universel. Lors de son utilisation, il a bien fait ses preuves, dans la plupart des cas, s'intégrant idéalement aux tâches qui nous attendent.