Évaluation d’Apache Ozone et de son intégration du protocole de consensus RAFT avec la librairie Apache Ratis afin d'obtenir un système distribué fiable et cohérent
Notice bibliographique
Résumé
De nos jours, l’utilisation de systèmes distribués est monnaie courante. Traditionnellement, l’entreprise utilisait l’entrepôt de données (data warehouse), lequel utilisait la méthodologie « schema on write » pour emmagasiner l’information dans une structure de données robuste et optimisée. Par contre, cette rigidité la rendait difficile à modifier comparativement à celle du « schema on read » (Sebaa et al., 2017), telle qu’utilisée dans les lacs de données (data lake), terme inventé en 2010 par James Dixon, fondateur de la compagnie Pentaho. Ce dernier représente un environnement distribué qui permet de stocker et traiter une quantité phénoménale de données brutes non structurées, semi-structurées ou structurées. Ces dernières sont ensuite ingérées massivement et rapidement sans aucun processus de transformation intermédiaire (Extract, Transform and Load) car différentes structures de données seront appliquées uniquement lorsqu’elles seront utilisées (Extract, Load and Transform), pour y effectuer des analyses qui permettront à l’organisation de prendre des décisions éclairées pour assurer sa pé- rennité (Madera & Laurent, 2016). Relativement peu coûteux, ils permettent de relier plusieurs machines entre elles afin de former une grappe (cluster) qui permettra notamment de répartir la charge et de répliquer les données afin d’obtenir un environnement doté de haute disponibilité (Nachiappan, 2020). L’un des problèmes communs est de conserver la cohérence entre les réplications lors d’erreurs ou d’échecs (J.-S. Ahn et al., 2019). Parmi ces systèmes distribués, nous retrouvons un récent projet débuté en 2018 par la Apache Software Foundation (ASF) et nommé Apache Ozone (Ozone), dont la première version officiellement disponible au grand public est parue en septembre 2020 (Ozone, 2023). Ce produit possède plusieurs particularités dont celle de pouvoir gérer efficacement les petits fichiers, contrairement à Apache Hadoop (Hadoop) pour lequel c’est une problématique (Bende & Shedge, 2016), tout en étant hautement extensible (Mehmood et al., 2024). De plus, il intègre un autre logiciel de ASF, Apache Ratis (Ratis), qui est une implémentation Java du protocole de consensus Replicated And Fault Tolerant (RAFT), similaire à Paxos et Viewstamped Replication, basés eux aussi sur l’élection d’un leader (Liu, 2018), permettant la tolérance aux pannes grâce à ses processus de validation, d’entente et de réplication d’une même valeur entre toutes les machines (Ongaro & Ousterhout, 2014), offrant ainsi une excellente redondance. Le choix de RAFT n’est probablement pas le fruit du hasard, car ce dernier a su se forger une solide communauté ayant développé des versions dans une panoplie de langages notamment C++, Python et Java (Howard, 2014) et il est utilisé dans différents systèmes tels que etcd, CockroachDB et neo4j pour ne nommer que ceux-ci. Une chose est certaine, c’est que les pannes font déjà partie du quotidien et que les systèmes doivent être en mesure de les gérer tout en demeurant cohérents. Notre projet de recherche consiste donc à bâtir une infrastructure Ozone afin de pouvoir vérifier la fiabilité et mesurer la cohérence entre les différents noeuds (nodes) composant ce que nous appelons le RAFT cluster. Nous allons utiliser une méthodologie basée sur l’expérience et les simulations afin de produire nos résultats et valider notre hypothèse.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,010 | 0,001 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,001 | 0,000 |
| Bibliométrie | 0,000 | 0,002 |
| Études des sciences et des technologies | 0,001 | 0,000 |
| Communication savante | 0,002 | 0,002 |
| Science ouverte | 0,001 | 0,001 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,002 | 0,001 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».