Architecture Druid, comment fonctionne-t-elle ?

La donnée qui est importée via les tâches atterrit dans ce qu’on appelle des Datasources, ce sont des éléments analogues aux tables des bases de données traditionnelles. La donnée des Datasources est partitionée en Segments. C’est un set de données groupées par temps. En coulisse, un Segment est un fichier au format colonne où l’index est, par défaut, le timestamp.

Les Dimensions représentent la donnée, et les Metrics sont les informations agrégées dérivées de la donnée.

Le diagramme ci-dessous illustre le cheminement de la donnée, commençant par la source d’entrée jusqu’au Historical Process, le process responsable de répondre aux requêtes.

Le diagramme peut être intimidant à première vue, voici ce qui se passe :

1. 1. Des données arrivent en continu depuis n’importe quelle source. Elles peuvent être préalablement transformées et enrichies.
   2. Une fois que le traitement est terminé, la donnée est envoyée dans la tâche d’indexation temps réel. La tâche conserve la donnée en mode ligne de mémoire et s’il y a une requête qui arrive entre temps, la donnée pourra être interrogée depuis ces nœuds temps réel.
   3. La requête touchera d’abord le Broker Node. Ce Broker Node verra qu’il a de la donnée dans la tâche d’indexation temps réel et il enverra la requête vers la tâche. En réponse, la tâche d’indexation temps réel renverra le résultat au Broker Node et l’évènement sera visible sur le tableau de bord.
   4. Si la donnée est restée dans les tâches d’indexation depuis un moment, les tâches vont créer un format orienté colonne, aussi appelé un Segment Druid. Ces segments seront transférés vers le Deep Storage. (Note : le Deep Storage peut être n’importe quel système de fichiers distribués, il peut être utilisé comme un moyen de backup permanent des Segments de données).
   5. Une fois la donnée présente dans le Deep Storage, elle est ensuite chargée dans les Historical Nodes. Ensuite les tâches d’indexation vont voir les Segments chargés dans les Historical Nodes, ils vont ainsi libérer les Segments qui sont stockés dans leur mémoire. Donc si une requête arrive, les données proviendront des Historical Nodes.
   6. L’architecture Druid exploite les Coordinator Nodes pour gérer où les segments ont besoin d’être chargés. Ils sont responsables de coordonner la donnée à travers les différents Historical Nodes. Les Coordinators Nodes sont également responsables de la gestion de la réplication de la donnée. Il est possible de configurer des règles de chargement de données. Par exemple, on peut établir une règle qui veille à ce que l’équivalent d’un mois de données soit chargé dans les Historical Nodes avec les Coordinator Nodes.
   7. Zookeeper est utilisé pour la communication en interne avec les composants. Il permet également les failovers.
   8. Il y a une dépendance externe sur le Metadata Store. Ça peut être une base de données MySQL ou Postgres. Il permet de stocker la métadonnée des Segments Druid, c’est-à-dire la taille des segments, leur localisation dans le Deep Storage ainsi que le schéma de la donnée.
   9. L’overload remet la tâche d’indexation au Middle-Manager. Ce dernier prend soin de récupérer la donnée à partir de sa source, composant ainsi des Segments de données.
   10. La donnée segmentée est persistée dans le Deep Storage, ensuite une entrée correspondante est créée dans le Metadata Store. Cette entrée garde une trace de la taille des segments, leur localisation dans le Deep Storage ainsi que le schéma de la donnée.
   11. Le coordinator interroge périodiquement le Metadata Store pour voir quelles données ne sont pas encore disponibles et les copie dans le Deep Storage vers un ou plusieurs Historical Processes.
   12. Dans le cas où la donnée vient d’une tâche Streaming, après avoir été segmentée, elle sera déjà interrogeable pendant un court laps de temps, jusqu’à qu’elle soit également copiée dans un Historical Process.

Ré-indexation de la donnée

Comme mentionné un peu plus tôt, les tâches d’indexation batch sont les seules qui peuvent être utilisées pour écraser la donnée déjà ingérée. Ceci peut être effectué pour de la donnée initialement ingérée par le même type de tâche d’indexation, ou par des tâches d’indexation streaming. Les tâches d’indexation Streaming, cependant, ne peuvent pas être utilisées pour écraser de la donnée.

Suppression de la donnée

Pour compléter le cycle de la donnée, nous allons rapidement mentionner que supprimer de la donnée depuis une Datasource implique deux étapes :

1. Marquer la donnée en tant que « unused » (non utilisée)
2. Créer une tâche « kill » (Tuer !) qui cherche de la donnée marquée comme non utilisée, puis la supprime définitivement, même dans le Deep Storage

La fréquence ou la quantité de donnée à supprimer est configurable via le Drop Rules du coordinator.

Interrogation de la donnée

Comme mentionné précédemment, la donnée pouvant être interrogée provient de tâches d’indexation Streaming, ou des Historical processes. Les requêtes proviennent des Brokers, qui identifie quels Historical/Middle-Manager processes possèdent les segments cibles et fusionne ces segments.

Une des raisons pour laquelle l’architecture Druid permet de hautes performances, est la suivante : avant de lire quoi que ce soit, les requêtes passent par trois processes filtre :

• Identification des segments nécessaires ainsi que leur localisation pour être récupérés
• Dans chaque segment, utilisation des indexes pour identifier quels lignes doivent être accédées
• Dans chaque ligne, accès seulement aux colonnes pertinentes aux requêtes

Et maintenant, à quoi ressemble ces requêtes ?

Druid fournit deux méthodes pour interroger la donnée :

• Druid SQL
• Requêtes basées sur JSON

Druid SQL

Druid SQL est la partie SQL intégrée de Druid, elle est basée sur Apache Calcite.

Il n’est pas nécessaire d’apprendre un nouveau langage pour interroger la donnée sur Druid. Ça veut dire, par exemple, que les requêtes SELECT supportent les mots-clés FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, UNION ALL, EXPLAIN PLAN, ainsi que les sous-requêtes.

Dans la documentation de Druid, un dataset Wikipédia est souvent utilisé pour illustrer les exemples, voici à quoi ressemble une requête SQL :

SELECT “page”, COUNT(*) as “count” FROM “wikipedia” GROUP BY 1 ORDER BY “count” DESC

Ici, “wikipedia” se réfère à la DataSource et “page” à la colonne de la DataSource.

Pour effectuer des requêtes plus complexes, les fonctions sont également supportées, comme les fonctions scalaires (ABS, CONCAT, CURRENT_TIMESTAMP, etc…) ainsi que les fonctions d’agrégation (SUM, MIN/MAX, etc…).