java - Python，PyTables，Java-捆绑在一起

Question

简而言之的问题

使Python和Java相互配合的最佳方法是什么？

更详细的解释

我的情况有些复杂。我会尽力用图片和文字来解释。这是当前的系统架构:



我们有一个用Java编写的基于代理的建模仿真。它具有以下选项:在本地写入CSV文件，或通过将Java服务器连接到HDF5文件远程写入。每次模拟运行都会吐出1 GB的数据，而我们进行了数十次模拟。我们需要能够汇总同一场景的多个运行(具有不同的随机种子)，以便查看一些趋势(例如，最小，最大，中位数，均值)。您可以想象，尝试在所有这些CSV文件中四处移动是一场噩梦。每次运行都会生成多个文件，就像我说的那样，其中一些文件非常庞大。这就是我们一直努力转向HDF5解决方案的原因，在该解决方案中，研究的所有数据都存储在一个位置，而不是分散在数十个纯文本文件中。此外，由于它是二进制文件格式，因此与未压缩的CSVS相比，它应该能够节省大量空间。

如图所示，我们对来自模拟的原始输出数据进行的当前后处理也发生在Java中，并读取本地输出生成的CSV文件。该后处理模块使用JFreeChart创建一些与模拟有关的图表。

问题

正如我之前提到的那样，由于我们从仿真中生成越来越多的数据，因此CSV确实是站不住脚的，并且伸缩性也不佳。此外，后处理代码的工作量超出了应做的工作，本质上执行了一个非常贫穷的人的关系数据库的工作(基于外键(唯一的代理ID)跨“表”(csv文件)进行联接) )。在该系统中，也很难以其他方式(例如Prefuse，Processing，JMonkeyEngine)将数据可视化，以使原始数据的某些子集在MatLab或SPSS中运行。

解决方案？

我的小组认为，我们确实需要一种过滤和查询所拥有数据以及执行跨表联接的方法。鉴于这是一次写入，多次读取的情况，我们确实不需要真正的关系数据库的开销；相反，我们只需要一些方法在HDF5文件上放置一个更好的前端即可。我发现了一些关于此的论文，例如描述如何使用XQuery as the query language on HDF5 files的论文，但该论文描述了必须编写一个编译器以将XQuery/XPath转换为本地HDF5调用，这超出了我们的需求。
输入PyTables。它似乎恰好满足了我们的需要(通过Python列表理解或in-kernel (C level) searches提供了两种不同的查询数据方式。

我设想的拟议架构是这样的:


我不确定如何将要查询的python代码与提供HDF5文件的Java代码以及进行数据后处理的Java代码链接在一起。显然，我将要重写许多隐式地执行查询的后处理代码，而是让出色的PyTables更优雅地完成此操作。

Java/Python选项

一个简单的Google搜索为communicating between Java and Python提供了一些选项，但是对于这个话题我还是很陌生，以至于我正在寻找一些对所提议的体系结构的实际专业知识和批评。似乎Python进程应该与Datahose在同一台计算机上运行，​​这样就不必通过网络传输大型.h5文件，而是将其较小得多的经过过滤的 View 传输给客户端。 Pyro似乎是一个有趣的选择-有人有经验吗？

Answer 1

这是一个史诗般的问题，有很多考虑因素。由于您没有提及任何特定的性能或体系结构限制，因此我将尽力提供最全面的建议。

使用PyTables作为其他元素和数据文件之间的中间层的初始计划似乎很可靠。但是，没有提到的一个设计约束是所有数据处理中最关键的约束之一:哪些数据处理任务可以批处理方式完成，哪些数据处理任务更像是实时流。

“我们确切地知道了我们的输入和输出并且可以进行处理”(批处理)和“我们知道我们的输入以及需要其他什么要求的东西”(实时)之间的区别使得所有架构问题都不同了。 。查看您的图，有几种关系暗示着不同的处理方式。

此外，在图上，您具有使用相同符号的不同类型的组件。这使得分析预期的性能和效率有些困难。

另一个重要的约束是您的IT基础架构。您有高速网络可用存储吗？如果这样做，中间文件将成为在基础结构的各个元素之间满足所有批处理需求的一种出色，简单且快速的数据共享方式。您提到在运行Java模拟的同一台服务器上运行PyTables-using-application。但是，这意味着服务器将承受写入和读取数据的负担。 (也就是说，仿真环境在查询数据时可能会受到无关软件的需求的影响。)

要直接回答您的问题:

PyTables看起来很不错。

Python和Java有很多通信方式，但是考虑与语言无关的通信方法，以便以后可以根据需要更改这些组件。这就像找到同时支持Java和Python的库并进行尝试一样简单。无论如何，您选择使用任何库实现的API都应该相同。 (XML-RPC可以很好地用于原型(prototype)制作，因为它在标准库中，Google的Protocol Buffers或Facebook的Thrift都是不错的生产选择。但是，不要低估如果将数据写入中间文件，那么多么伟大和简单？可预测和可批处理的。

为了进一步帮助设计过程并充实您的需求，请执行以下操作:

只看一小部分难题，做出一些合理的假设，然后跳入解决方案评估很容易。但是最好是在清楚了解您的约束的情况下整体地看问题。我可以建议这个过程:

创建当前架构的两个图，物理图和逻辑图。

在物理图上，为每个物理服务器创建一个框，并绘制每个之间的物理连接。

确保标记每个服务器可用的资源以及每个连接可用的类型和资源。

如果可能有用，请包括当前设置中不涉及的物理硬件。 (如果您有可用的SAN，但未使用，请在解决方案可能需要的情况下将其包括在内。)

在逻辑图上，为当前体系结构中运行的每个应用程序创建框。

将相关库作为框包含在应用程序框内。 (这很重要，因为您将来的解决方案图当前将PyTables作为一个盒子，但是它只是一个库，不能独自执行任何操作。)

以圆柱体形式使用磁盘资源(例如HDF5和CSV文件)。

根据需要使用箭头将应用程序连接到其他应用程序和资源。始终从“ Actor ”到“目标”绘制箭头。因此，如果应用程序写入HDF5文件，则它们的箭头将从该应用程序指向该文件。如果应用程序读取CSV文件，则箭头会从该应用程序指向该文件。

每个箭头都必须标记有通信机制。未标记的箭头显示了一种关系，但是没有显示什么关系，因此它们不会帮助您做出决定或传达约束。

完成这些图后，请制作一些副本，然后在它们之上立即开始进行数据流涂鸦。对于需要您原始数据的每个“端点”应用程序，使用该图的副本，从模拟开始，并在终点处以非常稳定的箭头结束。每当您的数据箭头在通信/协议(protocol)箭头之间流动时，请记下数据的变化方式(如果有)。

在这一点上，如果您和您的团队都同意纸上的内容，那么您已经以一种对任何人都应该易于沟通的方式解释了当前的体系结构。 (不仅是堆栈溢出的助手，还包括老板，项目经理和其他钱包持有者。)

要开始计划解决方案，请查看数据流程图，并从端点到起点进行反向操作，并创建一个嵌套列表，其中包含从开始到开始的所有应用程序和中间格式。然后，列出每个应用程序的要求。确保具有以下特点:

此应用程序可以使用哪些数据格式或方法进行通信。

实际需要什么数据。 (这是始终相同还是会根据其他要求而一时改变？)

它多久需要一次。

应用程序大约需要多少资源。

应用程序现在做得不好，所以现在该怎么办。

该应用程序现在可以做什么将有所帮助，但没有成功。

如果您在此列表上做得很好，则可以看到它如何帮助定义您选择的协议(protocol)和解决方案。您查看数据跨越通信线路的情况，并比较通信双方的需求列表。

您已经描述了一种特殊的情况，其中有大量的Java后处理代码正在CSV文件中的数据表上执行“联接”，即“现在执行但执行得不好”。因此，您查看了该通信的另一端，看另一端是否可以做得很好。在这一点上，另一面是CSV文件，在此之前是模拟文件，所以不，在当前体系结构中没有什么可以做得更好。

因此，您已经提出了一个新的Python应用程序，该应用程序使用PyTables库使该过程更好。到目前为止听起来不错!但是在下一张图中，您添加了许多其他与“PyTables”相关的内容。现在，我们在StackOverflow扩展了对该小组的理解，因为我们不了解其他应用程序的需求。但是，如果您像上面提到的那样制作了需求列表，那么您将确切知道要考虑的内容。也许您的使用PyTables来提供对HDF5文件的查询的Python应用程序可以支持所有这些应用程序。也许它只会支持其中的一两个。也许它将向后处理器提供实时查询，但会定期为其他应用程序编写中间文件。我们说不清，但有了计划，您可以做到。

一些最终准则:

保持简单! 这里的敌人是复杂性。解决方案越复杂，解决方案实现就越困难，失败的可能性就越大。使用最少的运算，使用最少的运算。有时，只有一个应用程序可以处理架构中所有其他部分的查询。有时，处理“实时”查询的应用程序和处理“批处理请求”的单独应用程序会更好。

保持简单! 这很重要!不要写任何可以为您完成的事情。 (这就是为什么中间文件如此之大，操作系统可以处理所有困难部分的原因。)此外，您提到关系数据库的开销太大，但是请考虑关系数据库还带有非常有表现力且众所周知的查询语言，与之配套的网络通信协议(protocol)，您无需开发任何内容即可使用它!肯定地说，无论您想出什么解决方案都比使用可以使用的现成解决方案更好，否则这不是最佳解决方案。

经常引用物理层文档，以便您了解注意事项的资源使用情况。较慢的网络链接或在一台服务器上放置过多资源都可能排除其他好的解决方案。

保存这些文档。 不管您做出什么决定，您在过程中生成的文档都很有值(value)。 Wiki-them或将其归档，以便您在主题出现时再次将其淘汰。

而直接问题的答案是:“如何让Python和Java一起玩好？”简直就是“使用与语言无关的交流方法”。事实的真相是，Python和Java对描述问题集都不重要。重要的是流经它的数据。可以轻松有效地共享数据的任何东西都将很好。