Discussion :

[Seabirds]

Bonjour a toutes et a tous !

J'ai un programme C++ qui simule tout un tas de données pour tout un tas de paramétrages différents (milliers/millions). Derrière, les sorties (données simulées et paramétrage associé) sont récupérées et transformées par d'autre programmes le long d'un pipeline. J'aimerais stocker les données intermédiaires de manière a pouvoir relancer seulement certaines parties du pipeline. Comment faire ça de manière efficace ?

Utiliser une convention de nommage des fichiers générés est la première idée qui me saute au cerveau, mais je me doute que depuis le temps que ce genre de problème existe il y a des solutions plus efficaces Je me demandais si les bases de données en étaient une. Je me tâtais a utiliser SQLITE dans le programme C++ et l'enrobage Python du pipeline.

Que me conseilleriez vous ?

En vous remerciant d'avance,

Bien amicalement,

[bacelar]

Question trop vague (en termes de nombres de paramètres qui influencent un choix précis).

Comme les choix sont fonction de bon nombre de facteur, il est prudent d'avoir une architecture évolutive qui s'adapte aux différents facteurs.

Un truc relou avec les fichiers, c'est que c'est pas transactionnel "de base", un fichier par encore entièrement écrit, un processus zombi qui a verrouillé le fichier avant de se bloquer, etc...

Vous utilisez quoi pour votre pipeline ? vous utilisez des outils d'orchestration des processus ? des framework de workflow ? ...

En base de données, il y a à boire et à manger. On ne travaille pas avec une base relationnelle comme avec une base documentaire NoSQL, etc...

[Seabirds]

Hum oui vu le délai de réponse je me doutais bien que ce message était en dehors de clous. Sorry

Vous utilisez quoi pour votre pipeline ? vous utilisez des outils d'orchestration des processus ? des framework de workflow ? ...

Un script python ...

Dans le temps, j'ai commence a utiliser sqlite3 pour stocker les résultats la dedans. Bon ça doit être l’équivalent d'un gros tableau pas très beau, mais ça avait l'air simple et plus propre que le trifouillage de dossier/fichiers.

[bacelar]

>Un script python ...

Wouais, bof-bof.
Pour la "scalabilité" et la robustesse, etc..., il y aura beaucoup de travail.

SQLite a plein d'avantages mais il a aussi les inconvénients de ses avantages, comme les accès multiples en écriture impossible, etc...

>Bon ça doit être l’équivalent d'un gros tableau pas très beau
C'est un peu beaucoup réducteur.

SQLite, et les bases de données relationnelles ont comme principe fondamentale DES tables composées de lignes, toutes du même format, reliées entre elles par des relations (utilisation de clés primaires/clé étrangères).
Chaque table a un format de ligne potentiellement différent, mais chaque ligne qui la constitue a le même format (nombre de colonnes et type de contenu de chaque colonne).

Pour d'autres types de base de données (bases objets, base key/value, base document, voire les antiquités comme les bases "frame" ont une structuration beaucoup moins strictes).

Le fait d'utiliser une base de données a forcément un coup par rapport à l'utilisation de "simple fichier" dans un système de fichier "classique" (transactionnalité des lectures/écritures, gestion des index, etc...).
Il existe aussi des systèmes de fichier ayant des fonctionnalités très spécifiques à certaines tâches, comme HDFS pour l'utilisation dans le cadre de l'algorithme Hadoop (calcul répartie, redondant, sur très forte volumétrie), etc...

J'ai l'impression que vos données ne seront pas si structurées pour qu'elles s'insèrent facilement dans un schéma de base de données relationnelles.

Il faudrait bien plus caractériser vos besoins pour mieux vous conseiller.

[Seabirds]

Mes excuses pour le retard de reponse, j'ai ete bien occupe ! Merci bacelar de tes reponses !

>Un script python ...
Wouais, bof-bof.
Pour la "scalabilité" et la robustesse, etc..., il y aura beaucoup de travail.

Aie oui je me doute, l’éternel problème en recherche étant qu'on est bien plus soucieux des délais de publication que de la scalabilité et robustesse des pipelines ... et bien qu’étant le premier a défendre le taff de dev a la première occasion venue, j'avoue que c'est difficile de compromiser entre perspectives de carrière et qualité du code, les comites de sélection de mon domaine ne comprenant déjà pas l’intérêt du développement informatique
Python ou R était plus ou moins inévitable cote traitement des données. Si il y a moyen d'isoler la partie pipeline et d'utiliser des outils adéquats, soit

>Bon ça doit être l’équivalent d'un gros tableau pas très beau
C'est un peu beaucoup réducteur.

Merci au passage pour votre résumé des BdD

Il faudrait bien plus caractériser vos besoins pour mieux vous conseiller.

Ok, bon alors allons y pour la description ...

J'ai écrit un programme C++ toto qui prend en entrée une trentaine d'options (je suis en train d'en faire un fichier de configuration). Ces options définissent un contexte de simulation de population dans un paysage, et un plan d’échantillonnage de données (répartition spatiale en clusters, nombres de clusters, taille d’échantillon etc).

Pour un plan d’échantillonnage testé:

• une dizaine d’arbres aléatoires (en fait des généalogies) sont construits en ayant pour feuille les individus de ces échantillons (arbres au format Newick, environt une centaine de feuilles)
• des informations relatives au plan d’échantillonnage sont résumés dans une string dite IMAP (quelle feuille de l'arbre appartenait a quel cluster spatial)
• une caractéristique centrale du plan d’échantillonnage (coordonnées géographique du cluster) est sauvegardée (actuellement dans la base de donnes sqlite)

Le programme teste une centaine de plans d’échantillonnage différent, et pour chaque plan enregistre les arbres correspondants et les strings IMAP.

Les arbres sont ensuite passes a une librairie python A qui permet de simuler des séquences génétiques le long des branches des généalogies. Cette librairie nécessite une poigne de paramètres (longueur des séquences, facteur d’échelle pour recalibrer les longueur des branches des arbres etc ...)

Les séquences simulées sont ensuite passées a un programme C++ B qui est censé deviner si une ou deux espèces animales se cachent derrière ces données. Ce programme prend un paquet de paramètres en entrée donnés via un fichier de configuration (string IMAP, ou certains paramètres dépendant de la valeurs des paramètres du programme toto) et file un sacré paquet d'info en output. La probabilité de détecter une seule espèce est extraite de la sortie.

Le reste du pipeline consiste a faire joujou avec de la visualisation de données pour décrire comment cette probabilité varie avec les caractéristiques des plans d’échantillonnage ou les paramètres des simulations.


Pour l'instant j'enregistre très naïvement toutes les sorties des programmes dans une table sqlite que j’agrandis au fur et a mesure que j'avance dans le pipeline. Le code Python qui wrap tout ça est terriblement sale et complètement intriqué a la bibliothèque A, au traitement des sorties de B, et un bout de la visualisation se fait carrément sous R parce je ne suis pas parvenu a installer les dépendances geospatiales en python.

Ça m'aurait semblé plus simple a intégrer si j'avais pu avoir accès a des librairies C++ plutôt qu'une bibliothèque Python A et un programme C++ boite-noire B, mais au moins ils ont le mérite d’exister et de m’économiser du code Mais du coup ca pose un problème de dépendances

Ces précisions sont-elles suffisantes ?

[bacelar]

Ok, c'est un peu plus clair, mais pas très synthétique.
Si c'était synthétique, je pense que vous n'auriez pas besoin de nous.

Vous avez déjà un énorme avantage, vous avez un truc qui fonction.
Il est donc plus prudent de partir de votre solution plutôt que de repartir from scratch.
Le fait qu'il y ait plusieurs technologie/langage est loin d'être un inconvénient, surtout si tout est déjà opérationnel.
Il faut toujours prendre l'outil le plus adapté au besoin ( et les connaissances préalables sont un critère non négligeable dans cette évaluation).
Mélanger les technologies demande plus de pré-requis et peut demander plus de travail pour la mise au point, mais si la solution est déjà fonctionnelle, vous avez déjà passé ce cap.

Il ne faut pas faire de modification ou évolution "dans l'absolu" aveuglément, il faut avoir des axes d'amélioration pour pouvoir évaluer si des modifications sont bénéfiques ou contre-productives selon ces axes et faire des compromis en conscience.

Votre processus complet semble assez complexe, et dans ces cas-là, un informaticien a tendance à découper le traitement en tranche, comme vous l'avez fait, mais aussi en rendant ces tranches les plus indépendantes possibles, et là, je suis pas sûr que ce que vous faites.

Dans des processus aussi complexes, il y a de très grandes chances que les besoins évoluent au cours du projet, que des choix de conceptions doivent s'adapter à des environnements différents, etc...
En rendant ces tranches indépendantes, il est très facile de les faire évoluer et de les adapter aux environnements.
En rendant paramétrable le format/canal/mécanisme d'entrées et de sorties de chacune des étapes permet de rendre le pipeline très flexible.
Comme vous n'avez pas été très loquace sur les mécanismes de communication entre les étapes mais que cela semble l'origine de votre question, je pense que l'on tombe encore sur la réponse "ça dépend".
Mais en rendant les étapes indépendantes, vous n'avez pas à choisir "une" solution mais vous devez choisir la meilleure solution entre chaque étape en fonction des caractéristiques de l'étape en aval.
C'est pour cela qu'il faudrait rendre le format/canal/mécanisme de sortie de chaque étape paramétrable pour que vous choisissiez ce format au moment des choix de la construction du pipe, qui intervient APRÈS la construction des différentes étapes, indépendamment les unes des autres (utilisation d'entrée de Tests Unitaires et de bouchons/mock/etc...).
Cela peut entrainer l'ajout d'étapes de transformation de données, mais cela est souvent des étapes qui font gagner de la performance et/ou de la souplesse et/ou de la robustesse.

Si vous avez pris la peine de mettre en place des tests unitaires de chaque étape, vous devez déjà avoir l'infrastructure qui permet le paramétrage des canaux/formats d'entrée et de sortie de ces étapes.
Sinon, c'est mal.

Si c'est pas le cas, je pense que c'est l'un des axes prioritaires : rendre votre pipeline "testable" en rendant chaque étape testable.
Cela permettra ensuite de simplifier radicalement le code Python "de wrapping" qui ne devrait pas faire autre chose que l'orchestration des étapes.
Avec des étapes bien indépendantes, vous pourrez choisir les mécanismes d'orchestration bien plus perfectionnés et plus simple à maintenir qu'un script Python qui mélange trop de fonctionnalités en même temps.

Si je résume votre solution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Fichier de configuration de "PROG. toto"    |            |arbres aléatoires                     |                    |                    |               |
                                            |"PROG. toto"|une string dite IMAP                  | librairie python A |                    |               |
Paramètres en ligne commande de "PROG. toto"|            |                                      |(à rendre autonome) |séquences simulées  |               |
------------------------------------------------------------------------------------------------|                    |                    |programme C++ B|un sacré paquet d'info en output........
longueur des séquences, facteur d’échelle pour recalibrer les longueur des branches des arbres  |                    |                    |               |
------------------------------------------------------------------------------------------------------------------------------------------|               |
                                                     un paquet de paramètres en entrée donnés via un fichier de configuration (string IMAP|               |
                                                        , ou certains paramètres dépendant de la valeurs des paramètres du programme toto)|               |

La représentation que j'ai choisie est assez bof mais on manque d'information pour faire plus précis.
Il faut distinguer comme "input", ce qui tient du paramétrage de l'outil lui-même (et indépendant du reste du pipeline), de ce qui est lié aux informations venant de l'amont.
Pour la seconde catégorie, il faut que ces informations viennent dans un seul canal.
Que le "Programme C++ B" ait des paramètres en entré dépendant de paramètres du "programme toto" est un vrai problème, les informations nécessaires à ce programme devrait venir "dans la bande", dans les informations envoyé par l'étape directement en amont et pas 3 étapes avant.

Les "COS" (les trucs boites noires), doivent être encadrés par des étapes "custom" qui permettent de remettre leurs canaux de communications en entré et en sortie "paramétrables".
Cela permettra de ne pas faire dépendre le reste du processus de leurs spécificités et de les rendre "testable" avec les mêmes outils que le reste.

Donc l'usage de fichier ou de base de données est à évaluer pour CHAQUE passage d'étape.
Mais, de plus, comme on devrait mettre en place des Tests Unitaires, il doit être possible de facilement configurer chaque étape pour qu'il prenne comme entré possible un jeu de fichiers pour grandement faciliter/accélérer la mise en œuvre de ces TU. Et la sortie de l'étape devrait être soit "mocable" soit être de simples fichiers textes "comparables" aux résultats attendus.

Donc le choix entre fichiers et DataBase n'en est pas un. Des fichiers au minimum (avec des formats différents si nécessaire) pour la testabilité (donc des versions éditables avec un simple NotePad) et ajouter la possibilité des DataBase pour les endroits où cela a un intérêt.

Si vous faites une synthèse de chaque étapes avec ce qui est de la configuration "interne", des données nécessaires en entré, les possibilités de format/canaux de sortie et les axes d'améliorations prioritaires, on pourrait peut-être vous conseiller comment et où étendre/flexibiliser le pipeline.