Каковы недостатки использования файлов .Rdata по сравнению с HDF5 или netCDF?

Ответ 1

Вот несколько ответов:

• Обилие опций Во-первых, проблема актуальна, но ваш список вариантов немного более узкий, чем должен быть. HDF5/netCDF4 - отличный вариант и хорошо работает с Python, Matlab и многими другими системами. HDF5 превосходит хранилище пиренейского пива во многих отношениях - проверьте PyTables, и вы, скорее всего, увидите хорошие ускорения. У Matlab раньше были (и могут быть) некоторые проблемы с тем, как большие массивы ячеек (или, может быть, struct) хранятся в HDF5. Это не то, что он не может этого сделать, но что это было ужасно ужасно. Это проблема Matlab, а не HDF5. Хотя это отличный выбор, вы также можете подумать о том, адекватен ли HDF5: подумайте, есть ли у вас очень большие файлы и вы можете воспользоваться запатентованной кодировкой, либо для скорости доступа, либо для сжатия. Не слишком сложно делать необработанное двоичное хранилище на любом языке, и вы можете легко создать что-то вроде хранилища файлов bigmemory (то есть скорость доступа). Фактически, вы даже можете использовать файлы bigmemory на других языках - это действительно очень простой формат. HDF5, безусловно, является хорошей отправной точкой, но нет единого универсального решения для хранения и доступа к данным, особенно когда вы попадаете в очень большие наборы данных. (Для меньших наборов данных вы также можете посмотреть Буферы протоколов или другие форматы сериализации, Dirk сделал RProtoBuf для доступа к ним в R.) Для сжатия см. Следующее предложение.

• Размер. Как отметил Дирк, форматы файлов могут быть описаны как нейтральные приложения и приложения. Другая ось - независимая от домена (или не владеющая доменом) или зависящая от домена (domain-smart;-)) хранилище. Если у вас есть какие-то знания о том, как будут возникать ваши данные, особенно любая информация, которая может быть использована при сжатии, вы можете создать лучший формат, чем все, что могут сделать стандартные компрессоры. Это требует немного работы. Альтернативные компрессоры, чем gzip и bzip, также позволяют анализировать большие объемы данных и разрабатывать соответствующие словари сжатия, чтобы вы могли получить гораздо лучшее сжатие, которое было бы с .Rdat файлами. Для многих типов наборов данных сохранение дельта между разными строками в таблице является лучшим вариантом - это может привести к значительно большей сжимаемости (например, может появиться много 0), но только вы знаете, будет ли это работать для ваших данных.

• Скорость и доступ. Rdat не поддерживает произвольный доступ. Он не имеет встроенной поддержки параллельного ввода-вывода (хотя вы можете сериализовать параллельное хранилище ввода-вывода, если хотите). Есть много вещей, которые можно сделать здесь, чтобы улучшить ситуацию, но это тысяча режет, чтобы приклеить материал к. Rdat снова и снова, вместо того, чтобы просто переключиться на другой механизм хранения и выпустить скорость и проблемы с доступом. (Это не просто преимущество HDF5: я часто использовал многоядерные функции для параллелизации других методов ввода-вывода, таких как bigmemory.)

• Возможности обновления У R нет очень приятного способа добавления объектов в файл .Rdat. По-моему, это не дает никаких "зрителей", чтобы пользователи могли визуально проверять или искать через коллекцию файлов .Rdat. Это, по моему мнению, не предлагает встроенного ведение записей в архивах объектов в файле. (Я делаю это с помощью отдельного объекта в файле, который записывает версии сценариев, которые генерируют объекты, но я буду передавать их на SQLite в будущую итерацию.) HDF5 имеет все это. (Кроме того, случайный доступ влияет на обновление файлов данных .Rdat, вам нужно сохранить весь объект.)

• Коммунальная поддержкаХотя я защищал ваш собственный формат, то есть для экстремальных размеров данных. Наличие библиотек, построенных для многих языков, очень полезно для уменьшения трения обмена данными. Для большинства простых наборов данных (и в большинстве случаев простой - довольно сложный) или от умеренных до довольно больших наборов данных, HDF5 - хороший формат. Конечно, есть способы победить его на специализированных системах. Тем не менее, это хороший стандарт, и это будет означать, что менее затратные усилия будут потрачены на поддержку либо фирменного, либо специфичного для приложения формата. Я видел, как организации придерживались формата в течение многих лет после использования приложения, которое генерировало данные, только потому, что было написано столько кода для загрузки и сохранения в этом формате приложения, и данные GB или TB были уже сохранены в его формате ( это может быть вы и R когда-нибудь, но это возникло из другого статистического набора, который начинается с буквы "S" и заканчивается буквой "S";-)). Это очень серьезное трение для будущей работы. Если вы пользуетесь широко распространенным стандартным форматом, вы можете гораздо лучше переносить его и другие распространенные стандарты: очень вероятно, что кто-то еще решил решить ту же проблему. Попробуйте - если вы сейчас делаете конвертер, но на самом деле не конвертируете его для использования, по крайней мере, вы создали инструмент, который другие могли бы забрать и использовать, если наступит время, когда необходимо перейти в другой формат данных.

• Память В файлах .Rdat для доступа к объектам необходимо load или attach его. Большую часть времени, люди load файла. Ну, если файл очень большой, там много ОЗУ. Таким образом, один из них немного умнее в использовании attach или разделяет объекты на несколько файлов. Это довольно неприятно для доступа к небольшим частям объекта. С этой целью я использую картографирование памяти. HDF5 позволяет осуществлять произвольный доступ к частям файла, поэтому вам не нужно загружать все свои данные, чтобы получить доступ к небольшой части. Это просто часть того, как все работает. Таким образом, даже внутри R есть лучшие варианты, чем просто файлы .Rdat.

• Скрипты для преобразования. Что касается вашего вопроса о написании script - да, вы можете написать script, который загружает объекты и сохраняет их в HDF5. Тем не менее, не обязательно делать это на огромном наборе гетерогенных файлов, если у вас нет хорошего понимания того, что будет создано. Я не мог начать создавать это для своих собственных наборов данных: в нем слишком много одноразовых объектов, и создание массивной файловой библиотеки HDF5 было бы смешно. Лучше подумать об этом, как о запуске базы данных: что вы хотите сохранить, как вы ее сохраните, и как она будет представлена ​​и доступна?

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

Короче говоря, даже если вы остаетесь в R, вам рекомендуется изучить другие возможные форматы хранения, особенно для больших, растущих наборов данных. Если вам нужно обмениваться данными с другими или, по крайней мере, предоставлять доступ для чтения или записи, тогда вам будут рекомендованы другие форматы. Нет причин тратить свое время на чтение читателей/писателей на других языках - это просто данные не код.:) Сосредоточьте свой код на том, как манипулировать данными разумными способами, а не тратить время на работу с хранилищем - другие люди уже очень хорошо справились с этим.

Ответ 2

(двоичные) форматы файлов представлены в двух основных вариантах:

• нейтральный для приложений, поддерживаемый публичными библиотеками и API (и как netCDF, так и HDF5 попадают в этот лагерь), что облегчает обмен данными между различными программами и приложениями при условии, что они расширены добавлением -на пакетах с использованием API

• специальные приложения, предназначенные только для работы с одной программой, хотя и более эффективно: вот что .RData делает

Поскольку R является открытым исходным кодом, вы можете повторно создать формат RData из ваших файлов Matlab: ничто не мешает вам писать правильный файл mex. Возможно, кто-то уже сделал это. Нет никакой технической причины не попробовать, но другой маршрут может быть проще, если оба приложения предназначены для совместного использования данных, поддерживающих формат в равной степени.

Для того, что стоит, еще в начале/середине 1990-х годов, я написал свой собственный код C для написания файлов моделирования в двоичном формате, используемом Octave (который я использовал, затем нарезал данные). Возможность сделать это с открытым исходным кодом - большой плюс.

Ответ 3

Я думаю, что могу ответить на некоторые из них, но не на все эти вопросы.

• Ну, кто-то, кто их задумает, может, вероятно, прочитать файл .Rdata напрямую, но это тяжелая работа и не очень большая польза. Поэтому я сомневаюсь, что Матлаб сделал это. Как вы могли бы вспомнить, R может читать различные другие системные форматы именно потому, что кто-то прилагал много усилий для этого.

• Для текстовых форматов csv выглядит довольно "стандартным", но для двоичных форматов я не знаю - и csv не является хорошим стандартом при этом - он сильно меняется, как обрабатываются (особенно) даты и кавычки (и конечно, он работает только для таблиц данных).

• Конечно!

Пример:

for(f in list.files(".", pattern="\\.Rdata$") {
    e <- new.env()
    load(f, e)       # load all values into environment e
    x <- as.list(e)

    #saveInOtherFormat(x, file=sub("\\.Rdata$", ".Other", f))
}

Ответ 4

Точка 2 неверна: бинарные файлы .RData переносятся на платформах оборудования и ОС. Чтобы процитировать страницу справки: save:

Все платформы R используют представление XDR (bigendian) C int и удваивают в двоичных файлах save-d, и они переносимы для всех платформ R.

Точка 1 является функцией того, что представляют данные, и какие другие программы могут быть полезны для данных. Если ваша база кода использует save() для записи указанных объектов, которые являются файлами данных или матрицами, вы можете легко написать небольшую функцию save2hdf(), чтобы записать их как двоичные файлы hdf или ncdf, а затем использовать sed, чтобы изменить все вхождения save (to save2hdf (в вашей кодовой базе. По крайней мере, ncdf будет иметь производительность при чтении, но не так уж и плохо. Если ваш код использует сохранение объектов, таких как списки разнородных объектов, вы, вероятно, не сможете использовать ncdf или hdf без больших транзакцию перекодировки для выделения отдельных компонентных объектов.

Также обратите внимание, что netCDF 4 все еще проблематично в R.