Обилие вариантов Во-первых, проблема актуальна, но ваш список вариантов немного более узок, чем должен быть. HDF5 / netCDF4 является отличным вариантом и хорошо работает с Python, Matlab и многими другими системами. HDF5 превосходит хранилище рассола Python во многих отношениях - посмотрите PyTables, и вы, скорее всего, увидите хорошие ускорения. Раньше у Matlab были (и могут быть еще) некоторые проблемы с тем, как большие массивы ячеек (или, возможно, структура) хранятся в HDF5. Дело не в том, что он не может этого сделать, а в том, что это было ужасно медленно. Это проблема Матлаба, а не HDF5. Несмотря на то, что это отличный выбор, вы также можете подумать, подходит ли HDF5: подумайте, есть ли у вас очень большие файлы, и вы могли бы воспользоваться проприетарной кодировкой, либо для скорости доступа, либо для сжатия. Нетрудно создать сырое двоичное хранилище на любом языке, и вы можете легко спроектировать что-то вроде хранилища файлов bigmemory (то есть скорость доступа). На самом деле, вы даже можете использовать bigmemory файлы на других языках - это действительно очень простой формат. HDF5, безусловно, является хорошей отправной точкой, но не существует единого универсального решения для хранения и доступа к данным, , особенно , когда кто-то получает очень большие наборы данных. (Для небольших наборов данных вы также можете взглянуть на буферы протокола или другие форматы сериализации; Дирк сделал RProtoBuf для доступа к ним в R.) Для сжатия см. Следующее предложение.
Размер Как уже упоминал Дирк, форматы файлов можно описать как независимые от приложения и зависящие от приложения. Другая ось - это независимое от домена (или не учитывающее домен) или зависящее от домена (domain-smart ;-)) хранилище. Если у вас есть некоторые знания о том, как будут возникать ваши данные, особенно любая информация, которая может быть использована для сжатия, вы сможете создать лучший формат, чем все, что могут делать стандартные компрессоры. Это займет немного работы. Альтернативные компрессоры, кроме gzip и bzip, также позволяют анализировать большие объемы данных и разрабатывать соответствующие «словари» сжатия, чтобы вы могли получить намного лучшее сжатие, чем с файлами .Rdat. Для многих видов наборов данных лучше хранить дельту между различными строками в таблице - это может привести к гораздо большей сжимаемости (например, может появиться множество нулей), но только вы знаете, сработает ли это для ваших данных.
Скорость и доступ .Rdat не поддерживает произвольный доступ. Он не имеет встроенной поддержки параллельного ввода-вывода (хотя вы можете сериализовать в параллельное хранилище ввода-вывода, если хотите). Есть много вещей, которые можно сделать здесь, чтобы улучшить вещи, но это тысячи шагов, чтобы склеивать вещи на .Rdat снова и снова, а не просто переключаться на другой механизм хранения и устранять проблемы со скоростью и доступом. (Это не просто преимущество HDF5: я часто использовал многоядерные функции для распараллеливания других методов ввода-вывода, таких как bigmemory.)
Возможности обновления R не имеет очень приятного способа добавления объектов в файл .Rdat. Насколько мне известно, он не предлагает никаких «Зрителей», чтобы пользователи могли визуально просматривать или искать в коллекции файлов .Rdat. Насколько мне известно, он не предлагает никаких встроенных средств контроля версий объектов в файле. (Я делаю это с помощью отдельного объекта в файле, который записывает версии сценариев, сгенерировавших объекты, но я передам это на SQLite в следующей итерации.) HDF5 имеет все это. (Также произвольный доступ влияет на обновление данных - файлы .Rdat, вам нужно сохранить весь объект.)
Коммунальная поддержка Несмотря на то, что я отстаивал свой собственный формат, он предназначен для экстремальных размеров данных.Наличие библиотек, созданных для многих языков, очень помогает уменьшить трения при обмене данными.Для большинства простых наборов данных (а простой все еще означает «довольно сложный» в большинстве случаев) или средних или довольно больших наборов данных, HDF5 является хорошим форматом.Конечно, есть способы победить в специализированных системах.Тем не менее, это хороший стандарт, и он будет означать, что меньше организационных усилий будет потрачено на поддержку собственного формата или формата приложения.Я видел, как организации в течение многих лет придерживались формата, в котором использовалось приложение, генерирующее данные, только потому, что было написано так много кода для загрузки и сохранения в формате этого приложения, а ГБ или ТБ данных уже были сохранены в его формате (это может быть когда-нибудь вы & R, но это произошло из другого статистического набора, который начинается с буквы "S" и заканчивается буквой "S" ;-)).Это очень серьезное трение для будущей работы.Если вы используете широко распространенный стандартный формат, вы можете с гораздо большей легкостью переносить его на другие распространенные стандарты: очень вероятно, что кто-то другой решил заняться той же проблемой.Попробуйте - если вы сейчас делаете конвертер, но на самом деле не конвертируете его для использования, по крайней мере, вы создали инструмент, который другие могли бы подобрать и использовать, если придет время, когда необходимо перейти к другому формату данных.
Память Для файлов .Rdat вам необходимо load или attach, чтобы получить доступ к объектам.Большую часть времени люди load файл.Ну, если файл очень большой, там много оперативной памяти.Таким образом, либо кто-то немного умнее использует attach, либо разделяет объекты на несколько файлов.Это довольно неприятно для доступа к маленьким частям объекта.Для этого я использую отображение памяти.HDF5 обеспечивает произвольный доступ к частям файла, поэтому вам не нужно загружать все свои данные только для доступа к небольшой части.Это просто часть того, как все работает.Так что даже в R есть лучшие варианты, чем просто файлы .Rdat.
Скрипты для конвертации Что касается вашего вопроса о написании скрипта - да, вы можетенаписать скрипт, который загружает объекты и сохраняет их в HDF5.Однако не обязательно делать это на огромном наборе разнородных файлов, если у вас нет хорошего понимания того, что будет создано.Я не мог начать проектировать это для моих собственных наборов данных: там слишком много одноразовых объектов, и создание массивной библиотеки файлов HDF5 было бы нелепым.Лучше думать об этом, как о запуске базы данных: что вы хотите хранить, как вы будете хранить ее и как она будет представлена и доступна?
Как только вы получите свои данныеИмея план конверсии, вы можете использовать такие инструменты, как Hadoop или даже основные многоядерные функции, чтобы развернуть свою программу конвертации и сделать это как можно быстрее.