On-Demand Health Data Provisioning with Custom Temporary Data Views for Big Data Platforms
Bibliographic record
Abstract
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.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.004 | 0.009 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.005 | 0.006 |
| Open science | 0.003 | 0.005 |
| Research integrity | 0.001 | 0.002 |
| Insufficient payload (model declined to judge) | 0.007 | 0.002 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".