Améliorer le traitement des données d'imagerie cérébrale avec Sea

Ces dernières années, la disponibilité de grands ensembles de Données en Neuroimagerie a considérablement augmenté grâce aux initiatives de données ouvertes. Alors que ces ensembles de données deviennent plus grands, le défi du traitement est passé d'une question de puissance de calcul à celle du transfert de données. Les outils d'analyse actuels ne se sont pas totalement adaptés à ce changement, et beaucoup ont du mal avec les coûts de transfert de grandes quantités de données. Un problème majeur est que les Applications de neuroimagerie existantes doivent souvent être complètement réécrites pour traiter les données efficacement.

Pour aider à gérer les données pour les outils de neuroimagerie, une nouvelle bibliothèque appelée Sea a été créée. Sea intercepte et redirige la façon dont les applications lisent et écrivent des données. Cela aide à réduire le temps passé à transférer des données. Cet article examine comment Sea fonctionne avec trois pipelines de prétraitement populaires : FSL, SPM et AFNI, en utilisant trois ensembles de données en neuroimagerie de tailles différentes. L'objectif est de voir si Sea peut améliorer la performance dans le traitement des données.

#Le défi des grands ensembles de données en neuroimagerie

L'augmentation des données de neuroimagerie accessibles au public apporte de nouveaux défis. Les chercheurs doivent gérer le Stockage et les temps de traitement de manière qui n'étaient pas nécessaires auparavant. Plusieurs outils ont été développés pour aider à mieux gérer les données de neuroimagerie. Par exemple, des méthodes standardisées d'organisation des données, comme les Brain Imaging Data Standards (BIDS), ont été mises en place pour faciliter le partage des ensembles de données. Des outils comme DataLad ont également été créés pour aider à suivre les changements et l'historique des données.

Des avancées récentes ont tenté d'accélérer le traitement en utilisant des méthodes d'apprentissage automatique beaucoup plus rapides que le traitement d'image traditionnel. Cependant, malgré l'existence de divers outils, certains problèmes, notamment ceux liés au transfert de données pendant le traitement, n'ont pas été suffisamment abordés.

Les deux plus grands ensembles de données en neuroimagerie aujourd'hui, le Human Connectome Project (HCP) et le UK Biobank, sont énormes, avec des données atteignant plusieurs pétaoctets. Pour de tels ensembles de données, les chercheurs s'appuient souvent sur un stockage distant parallèle pour le traitement. Bien que ces systèmes de stockage soient évolutifs, ils ne peuvent généralement pas rivaliser avec les Performances des solutions de stockage local, comme les disques à état solide (SSD).

Lors du transfert de grandes quantités de données vers ces systèmes de stockage distants, un surcoût important en temps de traitement peut se produire. Les Big Data en neuroimagerie peuvent se présenter sous deux formes : 1) de très gros fichiers et 2) de nombreux petits fichiers liés à de nombreuses personnes, comme les ensembles de données IRM. La façon dont les données sont organisées pose différents défis pour leur transfert. Alors que les entrées/sorties (I/O) de gros fichiers sont principalement influencées par la vitesse du système de stockage, les I/O de petits fichiers peuvent créer des retards notables.

Pour résoudre les problèmes de performance causés par le transfert de grands ensembles de données, deux stratégies ont été mises en œuvre dans les frameworks Big Data : la localité des données et le calcul en mémoire. Ces deux stratégies visent à réduire les retards dus aux grands transferts en utilisant un stockage local comme zone de stockage temporaire. Bien que ces frameworks puissent être utiles pour les données de neuroimagerie, ils ne sont pas largement utilisés car réécrire les logiciels de neuroimagerie existants pour fonctionner avec ces frameworks nécessite un effort considérable.

Les nouvelles applications de neuroimagerie qui utilisent des moteurs de pipeline populaires ne bénéficient souvent pas d'une meilleure gestion des données. Bien que des outils comme Nipype permettent des techniques de gestion des données, ils ne facilitent pas leur intégration dans les flux de travail. Pour donner aux applications de neuroimagerie des capacités de gestion des données, elles doivent pouvoir interagir avec un système de stockage ou une bibliothèque qui supporte ces approches.

Les chercheurs s'appuient généralement sur deux systèmes principaux pour leurs besoins en stockage et en calcul : les clusters de calcul haute performance (HPC) et le cloud. Le cloud facilite le partage des données et offre un accès à différentes infrastructures, tandis que les clusters HPC sont souvent plus rentables pour accéder à un large éventail de ressources. Les systèmes HPC utilisent des systèmes de fichiers parallèles basés sur le réseau évolutifs pour le stockage, comme Lustre. Bien que ces systèmes offrent de bonnes performances, ils sont partagés entre tous les utilisateurs, ce qui signifie que ceux qui exécutent des applications gourmandes en données peuvent ralentir les performances de tout le monde.

#Amélioration des performances des systèmes de fichiers partagés

Il existe des moyens d'améliorer les performances des systèmes de fichiers partagés, comme limiter la charge de travail des applications gourmandes en données ou utiliser des Burst Buffers. Les Burst Buffers permettent aux utilisateurs de réserver un nœud de calcul pour le stockage ou d'utiliser un stockage local pendant le traitement. Cependant, cela nécessite que les utilisateurs gèrent le transfert de leurs données vers et depuis le Burst Buffer, sauf si un système de fichiers spécial pour les Burst Buffers est installé.

Pour qu'un système de fichiers soit accessible par les utilisateurs HPC, il doit pouvoir se charger sans avoir besoin de droits administratifs. Les applications existantes interagissent généralement avec des systèmes de fichiers basés sur POSIX, donc le nouveau système de fichiers doit suivre des normes similaires. Une méthode pour y parvenir est d'utiliser le truc LDPRELOAD, qui permet d'intercepter certains appels de bibliothèques et de modifier leur comportement. Cette technique a été employée dans divers projets pour créer des systèmes de fichiers légers dans l'espace utilisateur.

#Vue d'ensemble de Sea

Sea est une bibliothèque de gestion des données conçue pour réduire les retards liés au transfert de données. Elle utilise le truc LDPRELOAD pour intercepter les appels au système de fichiers, en particulier ceux liés à l'accès aux fichiers dans la bibliothèque GNU C sur les systèmes Linux. Ce faisant, Sea peut rediriger les appels d'écriture vers un stockage plus rapide chaque fois que c'est possible. Lorsqu'elle intercepte des appels de lecture, Sea peut également choisir de lire à partir d'un emplacement plus rapide si une copie existe là-bas.

Sea détermine quel emplacement de stockage utiliser pour l'écriture sur la base d'un fichier d'initialisation nommé sea.ini. Ce fichier contient des informations sur les emplacements de stockage disponibles et leur ordre de priorité. Il est important de noter que Sea n'est pas un système de fichiers mais un outil léger conçu pour rediriger les fichiers vers des solutions de stockage plus rapides.

Tous les emplacements de stockage que Sea peut utiliser pour rediriger les écritures sont considérés comme des caches. Ces caches peuvent être n'importe quel stockage disponible sur les nœuds de calcul, comme les systèmes de fichiers temporaires dans la mémoire virtuelle ou les disques à état solide. Étant donné que les résultats de neuroimagerie nécessitent souvent un traitement supplémentaire et que les ressources locales HPC ne peuvent être accessibles que pendant un certain temps, Sea permet de déplacer les données vers un stockage partagé à long terme sans perturber les processus en cours. Cela est géré par un fil séparé appelé le "flusher", qui transfère les données des caches vers le stockage permanent.

Les utilisateurs doivent informer Sea des fichiers qui doivent être sauvegardés dans le stockage en utilisant un fichier appelé .seaevictlist. Ce fichier peut inclure des expressions régulières pour spécifier les chemins pour le flushing et l'éviction. Si un fichier apparaît dans les deux listes, Sea déplacera simplement le fichier du stockage local vers le stockage permanent au lieu de le copier.

Sea a également un fil de préfetch basique qui peut transférer des fichiers vers le cache le plus rapide disponible. Les utilisateurs peuvent activer le préfetch en remplissant un fichier appelé .seaprefetchlist à l'aide d'expressions régulières, similaire aux listes de flushing et d'éviction.

Pour interagir avec Sea, un point de montage est créé. Ce point de montage est un répertoire vide qui sert de vue pour tous les fichiers stockés dans Sea. Pour suivre les emplacements des fichiers, Sea duplique la structure de répertoire de chaque emplacement de stockage à travers tous les caches. Il est recommandé de fournir des emplacements de stockage vides pour que Sea optimise les performances, car le clonage de grands répertoires peut prendre du temps.

Sea peut être exécuté directement à l'aide de conteneurs disponibles ou compilé à partir de la source à l'aide d'outils standards. Une fois compilé, il peut être exécuté à l'aide d'un simple script bash.

#Tests de performance de Sea

Pour évaluer les performances de Sea, des tests ont été effectués en utilisant trois ensembles de données de tailles différentes. Trois pipelines de neuroimagerie courants-AFNI, SPM et FSL-ont été utilisés pour traiter ces ensembles de données. Un environnement de test notable était un cluster HPC dédié uniquement à ces expériences.

Des charges de travail simulées d'autres utilisateurs ont été créées pour évaluer les performances de Sea dans des conditions où le système de fichiers partagé est sous stress. Les tests ont montré que Sea offrait des gains de vitesse considérables lorsque la performance de Lustre était réduite par ces charges de travail supplémentaires. Le gain de vitesse le plus important observé était de 32 fois lorsqu'un pipeline spécifique traitait une seule image de l'ensemble de données HCP pendant que plusieurs écrivains actifs étaient occupés.

En moyenne, le pipeline SPM a eu le plus grand gain de vitesse, atteignant une moyenne de 12,6 lors des tests. Le pipeline AFNI a également montré des gains de vitesse, tandis que le pipeline FSL Feat avait les gains les moins significatifs en raison de sa nature gourmande en calcul.

L'ensemble de données HCP a constamment donné les gains de vitesse les plus élevés, probablement parce qu'il a les plus grands fichiers individuels, ce qui le rend plus affecté par les retards lors du flushing vers Lustre. Les résultats ont indiqué qu'à mesure que le travail parallèle augmentait, les gains de vitesse de Sea avaient tendance à diminuer, principalement en raison de l'augmentation des temps d'attente pour les ressources.

#Comparaison avec les performances de référence

Dans des scénarios sans écrivains occupés, les performances de Sea étaient similaires à celles du système de référence. Cependant, lorsque des écrivains occupés étaient actifs, Sea a considérablement amélioré les performances et réduit le temps total nécessaire pour les tâches. Quelques ralentissements mineurs se sont produits lors de l'utilisation de Sea, probablement dus à la lecture initiale des données.

Pour évaluer davantage le surcoût de Sea, elle a été comparée à un scénario où le traitement se produisait entièrement en mémoire. Les résultats ont montré que le surcoût de Sea était minimal, ce qui en fait une option sûre pour les utilisateurs même dans des conditions où la performance était dégradée.

D'autres benchmarks ont été réalisés sur un cluster de production partagé pour voir comment Sea se comporte dans des situations réelles. Ce test a révélé que la performance était variable mais offrait toujours des gains de vitesse notables pour le traitement des données de neuroimagerie.

Dans l'environnement de production, le gain maximal observé était de 11 fois lors des tests avec le pipeline AFNI en traitant des images. Sea s'est avéré utile pour maintenir des performances même lorsque le système de fichiers partagé était fortement utilisé.

#L'importance des gains de vitesse dans le traitement des données

Les résultats ont montré qu'utiliser Sea peut conduire à des gains de vitesse considérables dans le traitement des données IRM fonctionnelles, surtout lorsque l'on traite des charges de travail qui mettent à l'épreuve les ressources partagées. Même dans les cas où les gains de vitesse sont plus faibles, Sea peut aider à gérer le nombre de fichiers créés sur le système de fichiers partagé, ce qui est bénéfique pour les utilisateurs avec des limites strictes.

Sea fonctionne mieux lorsque les tâches impliquent d'écrire des données à un rythme qui dépasse la capacité du cache de pages pour le flushing vers le système de fichiers. Par exemple, exécuter plusieurs instances d'un pipeline particulier peut rapidement remplir le cache disponible, permettant à Sea de démontrer ses avantages.

Cela dit, Sea a ses limites. Elle ne peut pas accélérer les applications qui sont gourmandes en utilisation CPU, comme c'est le cas avec le pipeline FSL Feat. Parfois, un espace de cache suffisant permet de transférer des données vers le système de fichiers sans retards. Dans de telles situations, Sea peut tout de même s'avérer bénéfique en minimisant le nombre de fichiers écrits sur le système partagé.

#Prédiction des performances et des gains de vitesse

Prédire les performances de Sea peut être difficile en raison des conditions variables dans les clusters HPC. Bien que nos tests contrôlés aient pu démontrer des gains de vitesse dans des conditions spécifiques, les résultats peuvent différer en fonction de facteurs externes comme l'utilisation du cluster, les types de charges de travail et les modèles de lecture/écriture.

Dans des scénarios où il y a peu de concurrence pour les ressources, les utilisateurs peuvent obtenir des gains de vitesse de Sea si la performance du système de fichiers partagé est médiocre. Plus une application écrit de données, plus elle est susceptible de bénéficier de Sea, puisque les données qui ne peuvent pas être écrites dans le cache peuvent toujours être dirigées vers un stockage local plus rapide.

La fréquence et la taille des opérations de données jouent également un rôle crucial dans la détermination des performances. Les applications qui écrivent de grandes quantités de données par à-coups ont tendance à bénéficier davantage de Sea que celles qui étalent les écritures uniformément.

#Préfetching, flushing et éviction avec Sea

Sea améliore les performances grâce au préfetching, au flushing et à l'éviction. Le préfetching permet de déplacer les données d'entrée vers la mémoire, ce qui accélère le traitement. Par exemple, lors des tests avec le pipeline SPM, le préfetching a considérablement amélioré la vitesse en chargeant les données en mémoire où elles pouvaient être plus facilement manipulées.

Le flushing et l'éviction ont été envisagés pour des environnements de production mais n'ont pas été utilisés dans les expériences contrôlées. L'hypothèse a été faite que les utilisateurs souhaiteraient avoir accès à toutes les données générées, bien que cela ne soit pas toujours le cas dans les analyses de jeux de données complets.

Des ralentissements avec Sea pourraient survenir si les processus de flushing fonctionnent en parallèle avec les calculs. Dans de grandes analyses, les utilisateurs peuvent ne pas avoir besoin d'accéder à tous les fichiers intermédiaires, ce qui optimiserait l'utilisation du stockage local et réduirait le nombre d'écritures sur les systèmes de fichiers distants.

#Interception des pipelines de neuroimagerie

L'approche d'utiliser LDPRELOAD pour intercepter les appels de bibliothèques s'est révélée efficace pour capturer toutes les actions du système de fichiers des applications testées. Cela signifie que Sea peut fonctionner avec les pipelines de prétraitement en neuroimagerie les plus utilisés de manière fiable.

Bien que Sea n'ait pas été profondément testée avec tous les paramètres possibles, elle a exécuté de nombreux tests d'intégration sur différents systèmes d'exploitation Linux et versions. Le choix d'utiliser l'interception glibc plutôt que des méthodes basées sur le noyau ou alternatives a fourni une solution facile à utiliser tout en maintenant un impact minimal sur les performances.

#Conclusion et directions futures

En conclusion, Sea est une bibliothèque légère conçue pour fournir des capacités essentielles de gestion des données pour les flux de travail de neuroimagerie. Elle a été testée avec succès avec les principales bibliothèques de prétraitement fMRI et a démontré qu'elle pouvait améliorer les performances de manière significative lorsque le transfert de données est une préoccupation.

Des gains de vitesse maximaux de 32 fois ont été observés dans des environnements contrôlés, avec des gains notables dans des environnements de production également. Ces améliorations étaient particulièrement fortes avec des fichiers plus volumineux, tandis que l'extension des temps de calcul et du surcoût provenant d'autres activités d'I/O étaient minimes.

Les futures itérations de Sea pourraient envisager des fonctionnalités supplémentaires pour archiver les sorties et gérer les fichiers sur des systèmes partagés de manière plus efficace. Dans l'ensemble, Sea montre un grand potentiel pour les chercheurs cherchant à améliorer leurs capacités de traitement des données en neuroimagerie.