On-Demand Health Data Provisioning with Custom Temporary Data Views for Big Data Platforms
Notice bibliographique
Résumé
RÉSUMÉ: Deux décennies depuis l’introduction des plateformes Big Data, elles restent néanmoins un sujet complexe ayant plusieurs défis encore non résolus. Il y a toujours un manque de consensus concernant la plateforme idéale pour résoudre les problèmes du monde réel. En effet, chaque cas d’utilisation requiert la conception d’une plateforme de donnée spécifique. Aussi, le fait que les données continuent d’augmenter exponentiellement incite les organisations à adopter des techniques de science de données et d’apprentissage machine afin d’explorer leurs données plus efficacement. Cela nécessite d’établir les fondations d’une architecture aidant à traiter un volume important des données variées de façon rapide tout en maintenant la véracité de ces derniers. En effet, les implémentations du type Entrepôt de Données et Lacs de Données sont souvent indispensables pour manipuler un tel volume. Cependant, chaque implémentation peut être réalisée de plus d’une façon. Nous nous penchons tout au long de notre recherche vers ces défis tout en parcourant l’état de l’art de différentes techniques explorées. Ce mémoire cible la partie backend et stockage au sein d’un plus grand projet concernant les plateformes de données libres d’accès et suivant un modèle sur mesure pour le milieu de la santé en collaboration avec la Clinique Médicale Urbaine du Quartier Latin. Nous présentons aussi l’implémentation d’une architecture Lac de Données dans un cas d’utilisation spécifique au domaine de santé. Notre implémentation peut être établie on-premise ou dans une infrastructure infonuagique et est constituée de deux parties. La première consiste en un backend responsable d’effectuer les tâches d’ingestion, stockage, transformation, et transfert de données. Ce backend adresse aussi la problématique qui concerne le type de stockage et les types de bases de données les plus compatibles avec un cas d’utilisation spécifique dans le domaine de la santé. ABSTRACT: Almost two decades have passed since the introduction of Big Data Platforms (BDPs), yet they remain a confusing subject with multiple challenges that are still unaddressed. There is still a lack of consensus on the ideal Data Platform solution for real-world problems, as every use case requires a specific Data Platform design. Moreover, the claim remains true that data keeps increasing exponentially, making organizations more inclined to adopt machine learning and data exploration techniques to tackle their problems. This necessitates laying out the foundations to design an architecture that can store and process structured, semi-structured, and unstructured data. In other words, there is still a need to determine the best way to process a large volume of diverse data at high speed (velocity) while maintaining the veracity of the processed information. Indeed, implementations that use Data Warehouses and Data Lakes are often necessary for manipulating large data volumes. However, each of these can be set up in various ways. We address those issues in our research by defining, classifying, and categorizing state-of-the-art Data Platform architectures and pointing out the critical elements for building a resilient and performant data backend architecture. Our thesis focuses on the backend and storage part of a more significant open-source on-demand Data Platform project for healthcare in collaboration with Clinique Médicale Urbaine du Quartier Latin. We also present our implementation of a Data Lake for a use- case centred around healthcare.
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 machine sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.
Scores du classifieur distillé par catégorie (deux têtes)
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,004 | 0,009 |
| Méta-épidémiologie (sens strict) | 0,001 | 0,001 |
| Méta-épidémiologie (sens large) | 0,001 | 0,001 |
| Bibliométrie | 0,001 | 0,001 |
| Études des sciences et des technologies | 0,001 | 0,001 |
| Communication savante | 0,005 | 0,006 |
| Science ouverte | 0,003 | 0,005 |
| Intégrité de la recherche | 0,001 | 0,002 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,007 | 0,002 |
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 source (Gemma direct ou Codex distillé), 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 ».