C'est une question épique, et il y a beaucoup de considérations. Étant donné que vous n'avez mentionné aucune contrainte de performance ou d'architecture spécifique, je vais essayer de proposer les meilleures suggestions complètes.
Le plan initial d'utilisation de PyTables comme couche intermédiaire entre vos autres éléments et les fichiers de données semble solide. Cependant, une contrainte de conception qui n'a pas été mentionnée est l'une des plus critiques de tous les traitements de données :lesquelles de ces tâches de traitement de données peuvent être effectuées dans un style de traitement par lots et quelles tâches de traitement de données sont davantage un flux en direct.
Cette différenciation entre "nous connaissons exactement nos entrées et nos sorties et pouvons simplement faire le traitement" (batch) et "nous connaissons nos entrées et ce qui doit être disponible pour que quelque chose d'autre soit demandé" (en direct) fait toute la différence pour une question architecturale . En regardant votre diagramme, il existe plusieurs relations qui impliquent les différents styles de traitement.
De plus, sur votre diagramme, vous avez des composants de différents types utilisant tous les mêmes symboles. Cela complique un peu l'analyse des performances et de l'efficacité attendues.
Une autre contrainte non négligeable est votre infrastructure informatique. Disposez-vous d'un espace de stockage disponible sur un réseau haut débit ? Si vous le faites, les fichiers intermédiaires deviennent un moyen brillant, simple et rapide de partager des données entre les éléments de votre infrastructure pour tous les besoins de traitement par lots. Vous avez mentionné l'exécution de votre application utilisant PyTables sur le même serveur qui exécute la simulation Java. Cependant, cela signifie que le serveur subira une charge à la fois pour l'écriture et la lecture des données. (C'est-à-dire que l'environnement de simulation pourrait être affecté par les besoins de logiciels non liés lorsqu'ils interrogent les données.)
Pour répondre directement à vos questions :
- PyTables ressemble à une bonne correspondance.
- Il existe de nombreuses façons pour Python et Java de communiquer, mais envisagez une méthode de communication indépendante du langage afin que ces composants puissent être modifiés ultérieurement si nécessaire. C'est aussi simple que de trouver des bibliothèques qui prennent en charge à la fois Java et Python et de les essayer. L'API que vous choisissez d'implémenter avec n'importe quelle bibliothèque doit être la même de toute façon. (XML-RPC serait parfait pour le prototypage, car il se trouve dans la bibliothèque standard, les Protocol Buffers de Google ou Thrift de Facebook font de bons choix de production. prévisible et batchable.
Pour vous aider davantage dans le processus de conception et étoffer vos besoins :
Il est facile de regarder un petit morceau du puzzle, de faire des hypothèses raisonnables et de se lancer dans l'évaluation de la solution. Mais il est encore mieux d'examiner le problème de manière globale avec une compréhension claire de vos contraintes. Puis-je suggérer ce processus :
- Créez deux diagrammes de votre architecture actuelle, physique et logique.
- Sur le schéma physique, créez des boîtes pour chaque serveur physique et schématisez les connexions physiques entre chacun.
- Assurez-vous d'étiqueter les ressources disponibles pour chaque serveur et le type et les ressources disponibles pour chaque connexion.
- Incluez le matériel physique qui n'est pas impliqué dans votre configuration actuelle si cela peut être utile. (Si vous disposez d'un SAN, mais que vous ne l'utilisez pas, incluez-le au cas où la solution le souhaiterait.)
- Sur le diagramme logique, créez des cases pour chaque application qui s'exécute dans votre architecture actuelle.
- Inclure les bibliothèques pertinentes sous forme de cases à l'intérieur les boîtes à candidatures. (Ceci est important, car votre futur diagramme de solution contient actuellement PyTables sous forme de boîte, mais ce n'est qu'une bibliothèque et ne peut rien faire par lui-même.)
- Dessinez sur les ressources du disque (comme les fichiers HDF5 et CSV) sous forme de cylindres.
- Connectez les applications avec des flèches à d'autres applications et ressources si nécessaire. Dessinez toujours la flèche de l'"acteur" à la cible". Ainsi, si une application écrit un fichier HDF5, la flèche va de l'application au fichier. Si une application lit un fichier CSV, la flèche va de l'application au fichier.
- Chaque flèche doit être étiquetée avec le mécanisme de communication. Les flèches sans libellé indiquent une relation, mais elles n'indiquent pas quoi relation et ainsi ils ne vous aideront pas à prendre des décisions ou à communiquer des contraintes.
- Sur le schéma physique, créez des boîtes pour chaque serveur physique et schématisez les connexions physiques entre chacun.
Une fois que vous avez terminé ces diagrammes, faites-en quelques copies, puis, juste au-dessus, commencez à faire des griffonnages de flux de données. Avec une copie du diagramme pour chaque application "point final" qui a besoin de vos données d'origine, commencez par la simulation et terminez au point final avec une flèche fluide assez solide. Chaque fois que votre flèche de données traverse une flèche de communication/protocole, notez comment les données changent (le cas échéant).
À ce stade, si vous et votre équipe êtes tous d'accord sur ce qui est écrit, alors vous avez expliqué votre architecture actuelle d'une manière qui devrait être facilement communicable à tout le monde. (Pas seulement les assistants ici sur stackoverflow, mais aussi les patrons, les chefs de projet et les autres détenteurs de bourses.)
Pour commencer à planifier votre solution, examinez vos diagrammes de flux de données et remontez du point de terminaison au point de départ et créez une liste imbriquée contenant chaque application et format intermédiaire sur le chemin du retour au début. Ensuite, listez les exigences pour chaque application. Assurez-vous de mettre :
- Quels formats de données ou méthodes cette application peut-elle utiliser pour communiquer ?
- Quelles données souhaite-t-il réellement ? (Est-ce toujours le même ou change-t-il sur un coup de tête en fonction d'autres exigences ?)
- À quelle fréquence en a-t-il besoin ?
- De combien de ressources approximativement l'application a-t-elle besoin.
- Que fait l'application maintenant qu'elle ne fonctionne pas aussi bien ?
- Que peut faire cette application maintenant qui pourrait aider, mais ce n'est pas le cas ?
Si vous faites du bon travail avec cette liste, vous pouvez voir comment cela vous aidera à définir les protocoles et les solutions que vous choisissez. Vous examinez les situations où les données traversent une ligne de communication et vous comparez la liste des exigences pour les deux côtés de la communication.
Vous avez déjà décrit une situation particulière où vous avez pas mal de code de post-traitement Java qui fait des "jointures" sur des tables de données dans des fichiers CSV, c'est un "faites maintenant mais ne faites pas si bien". Donc, vous regardez l'autre côté de cette communication pour voir si l'autre côté peut bien faire cette chose. À ce stade, l'autre côté est le fichier CSV et avant cela, la simulation, donc non, il n'y a rien qui puisse faire mieux dans l'architecture actuelle.
Vous avez donc proposé une nouvelle application Python qui utilise la bibliothèque PyTables pour améliorer ce processus. Ça sonne bien jusqu'à présent ! Mais dans votre diagramme suivant, vous avez ajouté un tas d'autres choses qui parlent de "PyTables". Maintenant, nous avons dépassé la compréhension du groupe ici à StackOverflow, car nous ne connaissons pas les exigences de ces autres applications. Mais si vous faites la liste des exigences comme mentionné ci-dessus, vous saurez exactement ce qu'il faut considérer. Peut-être que votre application Python utilisant PyTables pour effectuer des requêtes sur les fichiers HDF5 peut prendre en charge toutes ces applications. Peut-être qu'il n'en supportera qu'un ou deux. Peut-être fournira-t-il des requêtes en direct au post-processeur, mais écrira périodiquement des fichiers intermédiaires pour les autres applications. Nous ne pouvons pas le dire, mais avec de la planification, vous pouvez.
Quelques directives finales :
- Simplifiez les choses ! L'ennemi ici est la complexité. Plus votre solution est complexe, plus la solution est difficile à mettre en œuvre et plus elle risque d'échouer. Utilisez les opérations les moins nombreuses, utilisez les opérations les moins complexes. Parfois, une seule application pour gérer les requêtes pour toutes les autres parties de votre architecture est la plus simple. Parfois, une application pour gérer les requêtes "en direct" et une application distincte pour gérer les "requêtes par lots" sont préférables.
- Simplifiez les choses ! C'est un gros problème ! N'écrivez rien qui puisse déjà être fait pour vous. (C'est pourquoi les fichiers intermédiaires peuvent être si géniaux, le système d'exploitation gère toutes les parties difficiles.) De plus, vous mentionnez qu'une base de données relationnelle est trop lourde, mais considérez qu'une base de données relationnelle est également livrée avec une requête très expressive et bien connue langage, le protocole de communication réseau qui va avec, et vous n'avez rien à développer pour l'utiliser ! Quelle que soit la solution que vous proposez, elle doit être meilleure que d'utiliser la solution prête à l'emploi qui fonctionnera, à coup sûr, très bien, ou ce n'est pas la meilleure solution.
- Consultez fréquemment la documentation de votre couche physique afin que vous compreniez l'utilisation des ressources de vos considérations. Un lien réseau lent ou en mettre trop sur un serveur peut exclure de bonnes solutions.
- Enregistrez ces documents. Quoi que vous décidiez, la documentation que vous avez générée au cours du processus est précieuse. Créez-les sur un wiki ou classez-les afin de pouvoir les ressortir lorsque le sujet sera abordé.
Et la réponse à la question directe, "Comment faire en sorte que Python et Java jouent bien ensemble?" est simplement "utiliser une méthode de communication indépendante de la langue". La vérité est que Python et Java ne sont pas importants pour votre ensemble de problèmes de description. Ce qui est important, ce sont les données qui y circulent. Tout ce qui peut facilement et efficacement partager des données ira très bien.
Ne rendez pas cela plus complexe que nécessaire.
Votre processus Java peut simplement générer un sous-processus distinct pour exécuter vos requêtes PyTables. Laissez le système d'exploitation faire ce que les systèmes d'exploitation font le mieux.
Votre application Java peut simplement bifurquer un processus qui a les paramètres nécessaires en tant qu'options de ligne de commande. Ensuite, votre Java peut passer à l'étape suivante pendant que Python s'exécute en arrière-plan.
Cela présente d'énormes avantages en termes de performances simultanées. Votre "backend" Python s'exécute en même temps que votre "frontend" de simulation Java.
