MétaCan
Menu
← Retour à la cohorte
Enregistrement W7018366350

On-Demand Health Data Provisioning with Custom Temporary Data Views for Big Data Platforms

2023· other· fr· W7018366350 sur OpenAlexfundno aff

Notice bibliographique

RevuePolyPublie (École Polytechnique de Montréal) · 2023
Typeother
Languefr
Domaine
Thématique
Établissements canadiensnon disponible
Organismes subventionnairesCompute Canada
Mots-clésBig dataLineaProvisioningArchitecture
DOInon disponible

Résumé

récupéré en direct d'OpenAlex

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 enseignants

Ni 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.

score de la tête « metaresearch » (Codex)0,004
score de la tête « metaresearch » (Gemma)0,009
Version: metacan-v3-hybrid-931329e0061cStatut de validation: machine_predicted_unvalidated
Catégories candidatesaucune
Catégories consensuellesaucune
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Sans objet · Signal consensuel: aucune
GenreSignal candidat: Méthodes · Signal consensuel: Méthodes
Score de désaccord entre enseignants0,007
Score d'incertitude au seuil0,025

Scores du classifieur distillé par catégorie (deux têtes)

CatégorieCodexGemma
Métarecherche0,0040,009
Méta-épidémiologie (sens strict)0,0010,001
Méta-épidémiologie (sens large)0,0010,001
Bibliométrie0,0010,001
Études des sciences et des technologies0,0010,001
Communication savante0,0050,006
Science ouverte0,0030,005
Intégrité de la recherche0,0010,002
Charge utile insuffisante (le modèle a refusé de juger)0,0070,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.

Tête enseignante Opus0,098
Tête enseignante GPT0,317
Écart entre enseignants0,219 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_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écoule

Classification

machine, non validée

Prédiction automatique; un appel candidat d’une seule source (Gemma direct ou Codex distillé), pas un consensus.

Les modèles n’ont appliqué aucune catégorie : rien dans la taxonomie ne correspondait à ce travail.
Devis d'étudeSans objet
Domainenon disponible
GenreMéthodes

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 ».

En bref

Citations0
Publié2023
Routes d'admission1
Résumé présentoui

Explorer davantage

Même revuePolyPublie (École Polytechnique de Montréal)→Travaux en français237 207→