Это эпический вопрос, и есть много соображений. Поскольку вы не упомянули никаких конкретных ограничений по производительности или архитектурным особенностям, я постараюсь предложить лучшие обоснованные предложения.

Первоначальный план использования PyTables в качестве промежуточного слоя между другими вашими элементами и файлами данных выглядит солидным. Однако, одно из конструктивных ограничений, которое не было упомянуто, является одним из наиболее критичных при обработке данных: Какая из этих задач обработки данных может быть выполнена в стиле пакетной обработки и какие задачи обработки данных являются скорее "живым" потоком.

Это различие между "мы точно знаем наши входные и выходные данные и можем просто выполнять обработку" (пакетная обработка) и "мы знаем наши входные данные и то, что должно быть доступно для чего-то еще" (живое исполнение) имеет большое значение для архитектурного вопроса. Глядя на вашу диаграмму, есть несколько отношений, которые подразумевают различные стили обработки.

Кроме того, на вашей диаграмме есть компоненты разных типов, использующие одни и те же символы. Это немного затрудняет анализ ожидаемой производительности и эффективности.

Другое существенное противоречие - это ваша IT-инфраструктура. Есть ли у вас высокоскоростные сетевые системы хранения данных? Если да, то промежуточные файлы становятся блестящим, простым и быстрым способом обмена данными между элементами вашей инфраструктуры для всех нужд пакетной обработки. Вы упомянули о запуске приложения PyTables на том же сервере, на котором работает Java-симулятор. Однако это означает, что сервер будет испытывать нагрузку как при записи, так и при чтении данных. (То есть, на среду моделирования могут влиять потребности несвязанного программного обеспечения, когда они запрашивают данные)

Чтобы ответить на ваши вопросы напрямую:

• PyTables выглядит неплохим совпадением.
• Существует множество способов взаимодействия Python и Java, но рассмотрим метод языкового агностического взаимодействия, так что эти компоненты могут быть изменены позже, если это необходимо. Это так же просто, как найти библиотеки, поддерживающие Java и Python, и попробовать их. API, которое вы выберете для реализации с любой библиотекой, должно быть одинаковым в любом случае. (XML-RPC подойдёт для создания прототипа, так как он есть в стандартной библиотеке, буферы протокола Google или Thrift в Facebook делают хороший выбор для производства. Но не стоит недооценивать, насколько велики и просты могут быть просто "записи в промежуточные файлы", если данные предсказуемы и пакетны.

Чтобы помочь в процессе проектирования все больше и больше наполнять свои потребности:

Легко посмотреть на маленький кусочек головоломки, сделать несколько разумных предположений и перескочить к оценке решения. Но еще лучше смотреть на проблему целостно с четким пониманием ваших ограничений. Могу я предложить этот процесс:

• Создайте две диаграммы вашей текущей архитектуры, физические и логические.
  • На физической диаграмме создайте коробки для каждого физического сервера и диаграмму физических соединений между ними.
    • Не забудьте пометить ресурсы, доступные для каждого сервера, а также тип и ресурсы, доступные для каждого соединения.
    • Включите физическое оборудование, которое не участвует в текущей установке, если это может оказаться полезным. (Если у вас есть доступная SAN, но вы ее не используете, включите ее, если решение может понадобиться.)
  • На логической диаграмме создайте поля для каждого приложения , работающего на вашей текущей архитектуре.
    • Включите соответствующие библиотеки в виде коробок внутри коробок приложения. (Это важно, потому что ваша будущая диаграмма решения в настоящее время имеет PyTables в виде ящика, но это всего лишь библиотека и ничего не может сделать самостоятельно.)
    • Рисование на дисковых ресурсах (таких как HDF5 и CSV файлы) в виде цилиндров.
    • При необходимости подключите приложения со стрелками к другим приложениям и ресурсам. Всегда рисуйте стрелкой из "actor" в "target". Таким образом, если приложение записывает и HDF5-файл, стрелка идет от приложения к файлу. Если приложение читает CSV-файл, стрелка идет от приложения к файлу.
    • Каждая стрелка должна быть помечена механизмом связи. Стрелки без меток показывают связь, но они не показывают что и поэтому не помогут вам принять решение или установить ограничения связи.

После того, как вы закончили с этими диаграммами, сделайте несколько их копий, а затем прямо поверх них начните делать дудлы потоковой передачи данных. С копией диаграммы для каждого приложения "конечной точки", которому нужны ваши исходные данные, начинайте с моделирования и заканчивайте в конечной точке почти сплошной плавной стрелкой. Всякий раз, когда ваша стрелка данных пересекает стрелку коммуникации/протокола, делайте заметки о том, как изменяются данные (если таковые имеются).

На этом этапе, если вы и ваша команда все согласны с тем, что находится на бумаге, то вы объяснили вашу текущую архитектуру таким образом, что она должна быть легко доступна для любого человека. (Здесь не только помощники по стековому переполнению, но и боссы, менеджеры проектов и другие владельцы кошельков)

Чтобы начать планирование вашего решения, посмотрите на диаграммы потока данных и пройдите обратный путь от конечной точки к начальной точке и создайте вложенный список, содержащий все приложения и промежуточные форматы на пути обратно к началу. Затем перечислите требования для каждого приложения. Обязательно укажите:

• Какие форматы данных или методы может использовать это приложение для взаимодействия.
• Какие данные оно на самом деле хочет получить. (Всегда ли это одно и то же или же они меняются по прихоти в зависимости от других требований?)
• Сколько раз они нужны приложению.
• Приблизительно сколько ресурсов нужно приложению.
• Что делает приложение теперь, когда оно не делает это хорошо.
• Что может сделать это приложение сейчас, что поможет, но оно не делает.

Если вы сделаете хорошую работу с этим списком, вы увидите, как это поможет определить, какие протоколы и решения вы выберете. Вы смотрите на ситуации, когда данные пересекают линию связи, и сравниваете список требований для обеих сторон связи.

Вы уже описали одну конкретную ситуацию, когда у вас есть довольно много java кода постобработки, который делает "соединения" по таблицам данных в CSV-файлах, т.е. "делайте сейчас, но не делайте это хорошо". Таким образом, вы смотрите на другую сторону этого взаимодействия, чтобы понять, может ли другая сторона сделать это хорошо. На данный момент другой стороной является CSV-файл, а до этого - симуляция, так что нет ничего, что могло бы сделать это лучше в текущей архитектуре.

Так что вы предложили новое приложение Python, которое использует библиотеку PyTables, чтобы сделать этот процесс лучше. Пока что звучит неплохо! Но в следующей диаграмме вы добавили к "PyTables" кучу других вещей. Теперь мы расширили понимание группы здесь, в StackOverflow, потому что мы не знаем требований этих других приложений. Но если вы составите список требований, как упоминалось выше, вы будете точно знать, что нужно учитывать. Может быть, ваше приложение Python, использующее PyTables для запроса HDF5-файлов, может поддерживать все эти приложения. Возможно, оно будет поддерживать только одно или два из них. Может быть, оно будет предоставлять живой запрос к постпроцессору, но периодически писать промежуточные файлы для других приложений. Мы не можем сказать, но при планировании можно.

Некоторые заключительные указания:

• Сохранить все просто! Враг здесь сложен. Чем сложнее ваше решение, тем сложнее его реализовать и тем больше вероятность неудачи. Используйте наименьшее количество операций, используйте наименьшее количество сложных операций. Иногда только одно приложение для обработки запросов для всех остальных частей вашей архитектуры является самым простым. Иногда приложение для обработки "живых" запросов и отдельное приложение для обработки "пакетных запросов" лучше.
• Сохранить все просто! Это очень важно! Не пишите ничего, что уже можно сделать за вас. (Поэтому промежуточные файлы могут быть настолько велики, что ОС обрабатывает все сложные части). Также Вы упомянули, что реляционная база данных слишком перегружена, но учтите, что реляционная база данных также поставляется с очень выразительным и хорошо известным языком запросов, сетевым протоколом связи, который к ней прилагается, и Вам не нужно ничего разрабатывать, чтобы использовать ее! Какое бы решение вы ни придумали, оно должно быть лучше , чем использование готового решения, которое будет работать, наверняка, очень хорошо, или это не лучшее решение.
• Обращайтесь к документации по физическому уровню часто , чтобы понять использование ресурсов из ваших соображений. Медленное сетевое соединение или слишком много работы на одном сервере может исключать и то, и другое.
• Сохраните эти документы. Независимо от того, что вы решите, документация, которую вы сгенерировали в процессе, является ценной. Вики-темы или отправьте их в файл, чтобы вы могли снова их вырвать, когда тема появится.

А ответ на прямой вопрос "Как заставить Python и Java хорошо играть вместе?" - это просто "использовать языковой метод агностического взаимодействия". Правда в том, что и Python, и Java не важны для решения описываемой проблемы. Что важно, так это данные, которые через него протекают. Все, что может легко и эффективно обмениваться данными, будет просто замечательно.