27

現在 .Rdata ファイルをエクスポートしているソフトウェアを変更して、HDF5 や netCDF などの「プラットフォームに依存しないバイナリ形式」でエクスポートするように依頼されました。次の 2 つの理由が挙げられました。

  1. Rdata ファイルは R でのみ読み取ることができます
  2. バイナリ情報の保存方法は、オペレーティング システムやアーキテクチャによって異なります

また、 「R Data import export manual」では、HDF5 と netCDF については説明されていますが、Rdata ファイルについては説明されていません。

R-help に関する議論では、.Rdata ファイルはプラットフォームに依存しないことが示唆されています。

質問:

  1. これらの懸念はどの程度有効ですか？
    • たとえば、Matlab は R を呼び出さずに .Rdata を読み取ることができますか?
  2. この点で、他の形式は .Rdata ファイルよりも便利ですか?
  3. プログラム自体への変更を最小限に抑えて、すべての .Rdata ファイルの .hdf5 類似物を作成するスクリプトを作成することは可能でしょうか?
4

4 に答える 4

28

さまざまな答えがあります。

  1. 豊富なオプションまず、懸念は有効ですが、選択肢のリストは本来よりも少し狭くなっています。HDF5 / netCDF4は優れたオプションであり、Python、Matlab、および他の多くのシステムでうまく機能します。HDF5は、多くの点でPythonのピクルスストレージよりも優れています。PyTablesを確認すると、かなりのスピードアップが見られるでしょう。Matlabは、HDF5に格納される大きなセル（または構造体）配列にいくつかの問題を抱えていました（そしてまだ抱えている可能性があります）。それができないということではなく、ひどく遅いということです。これはMatlabの問題であり、HDF5の問題ではありません。これらは優れた選択肢ですが、HDF5が適切かどうかも検討してください。非常に大きなファイルがあり、アクセス速度または圧縮のいずれかで独自のエンコーディングの恩恵を受けることができるかどうかを検討してください。それ'bigmemory（つまり、アクセス速度）。bigmemory実際、他の言語のファイルを使用することもできます。これは非常に単純な形式です。HDF5は確かに良い出発点ですが、特に非常に大きなデータセットに到達する場合、データの保存とアクセスのための1つの普遍的なソリューションはありません。（小さいデータセットの場合は、プロトコルバッファまたは他のシリアル化形式も確認できます。DirkはRProtoBufRでこれらにアクセスしました。）圧縮については、次の提案を参照してください。

  2. サイズDirkが述べたように、ファイル形式はアプリケーションに依存せず、アプリケーションに依存するものとして説明できます。もう1つの軸は、ドメインに依存しない（またはドメインに依存しない）またはドメインに依存する（domain-smart ;-)）ストレージです。データがどのように発生するか、特に圧縮に使用できる情報についてある程度の知識がある場合は、標準のコンプレッサーが実行できるものよりも優れた形式を構築できる可能性があります。これには少し手間がかかります。gzipやbzipに代わるコンプレッサーを使用すると、大量のデータを分析して適切な圧縮「辞書」を作成できるため、.Rdatファイルよりもはるかに優れた圧縮を実現できます。多くの種類のデータセットでは、テーブル内の異なる行間のデルタを格納する方が適切なオプションです。これにより、圧縮率が大幅に向上する可能性があります（たとえば、多数の0が表示される場合があります）。

  3. 速度とアクセス .Rdatはランダムアクセスをサポートしていません。パラレルI/Oのサポートは組み込まれていません（ただし、必要に応じて、パラレルI / Oストレージにシリアル化できます）。物事を改善するためにここでできることはたくさんありますが、別のストレージメカニズムに切り替えて速度とアクセスの問題を吹き飛ばすのではなく、.Rdatに何度も何度も接着するのは1000カットです。（これはHDF5の利点だけではありません。マルチコア関数を頻繁に使用して、などの他のI / Oメソッドを並列化しましbigmemoryた。）

  4. 更新機能Rには、オブジェクトを.Rdatファイルに追加するための非常に優れた方法がありません。私の知る限り、ユーザーが.Rdatファイルのコレクションを視覚的に検査または検索できるようにする「ビューアー」は提供されていません。私の知る限り、ファイル内のオブジェクトの組み込みのバージョン管理は提供していません。（これは、オブジェクトを生成したスクリプトのバージョンを記録するファイル内の別のオブジェクトを介して行いますが、将来の反復でSQLiteにアウトソーシングします。）HDF5にはこれらすべてがあります。（また、ランダムアクセスはデータの更新に影響します-.Rdatファイル、オブジェクト全体を保存する必要があります。）

  5. 共同サポート私はあなた自身のフォーマットを提唱しましたが、それは極端なデータサイズのためのものです。多くの言語用にライブラリを構築することは、データ交換の摩擦を減らすのに非常に役立ちます。ほとんどの単純なデータセット（およびほとんどの場合、単純は依然として「かなり複雑」を意味します）または中程度からかなり大きなデータセットの場合、HDF5が適切な形式です。確かに、特殊なシステムでそれを打ち負かす方法があります。それでも、これは優れた標準であり、独自の形式またはアプリケーション固有の形式をサポートするために費やされる組織的な労力が少なくなることを意味します。データを生成したアプリケーションを使用してから何年もの間、組織がそのフォーマットに固執しているのを見てきました。そのアプリケーションのフォーマットでロードおよび保存するために大量のコードが記述されており、GBまたはTBのデータがすでにそのフォーマットで保存されているからです（これはいつかあなたとRかもしれません、しかし、これは、文字「S」で始まり、文字「S」で終わる別の統計スイートから生じました;-)）。これは、将来の作業にとって非常に深刻な摩擦です。広く普及している標準フォーマットを使用すると、それと他の広く普及している標準との間ではるかに簡単に移植できます。他の誰かが同じ問題に取り組むことを決定した可能性が非常に高いです。試してみてください-今すぐコンバーターを実行しますが、実際に使用するために変換しない場合は、少なくとも、別のデータ形式に移動する必要があるときに他の人が手に取って使用できるツールを作成しました。そうすれば、それと他の広く普及している標準との間ではるかに簡単に移植できます。他の誰かが同じ問題に取り組むことを決定した可能性が非常に高いです。試してみてください-今すぐコンバーターを実行しますが、実際に使用するために変換しない場合は、少なくとも、別のデータ形式に移動する必要があるときに他の人が手に取って使用できるツールを作成しました。そうすれば、それと他の広く普及している標準との間ではるかに簡単に移植できます。他の誰かが同じ問題に取り組むことを決定した可能性が非常に高いです。試してみてください-今すぐコンバーターを実行しますが、実際に使用するために変換しない場合は、少なくとも、別のデータ形式に移動する必要があるときに他の人が手に取って使用できるツールを作成しました。

  6. メモリ.Rdatファイルでは、オブジェクトにアクセスするために、loadまたはそれを実行する必要があります。attachほとんどの場合、人々loadはファイルです。ファイルが非常に大きい場合は、RAMが大量に使用されます。したがって、どちらかがオブジェクトの使用について少し賢いか、attachオブジェクトを複数のファイルに分割します。これは、オブジェクトの小さな部分にアクセスするのに非常に厄介です。そのために、メモリマッピングを使用します。HDF5では、ファイルの一部にランダムアクセスできるため、小さな部分にアクセスするためだけにすべてのデータをロードする必要はありません。それは物事が機能する方法のほんの一部です。したがって、R内でも、.Rdatファイルよりも優れたオプションがあります。

  7. 変換用のスクリプトスクリプトの記述に関する質問については、はい、オブジェクトをロードしてHDF5に保存するスクリプトを記述できます。ただし、何が作成されるかを十分に理解していない限り、異種ファイルの膨大なセットに対してこれを行うことは必ずしも賢明ではありません。自分のデータセット用にこれを設計し始めることはできませんでした。そこには1回限りのオブジェクトが多すぎて、大規模なHDF5ファイルライブラリを作成するのはばかげています。データベースを開始するようなものと考える方がよいでしょう。何を保存し、どのように保存し、どのように表現してアクセスするのでしょうか。

データ変換計画を立てたら、Hadoopなどのツールや基本的なマルチコア機能を使用して変換プログラムを解き放ち、これを可能な限り迅速に実行できます。

つまり、Rにとどまっている場合でも、特に大規模で増大するデータセットの場合は、他の可能なストレージ形式を検討することをお勧めします。他のユーザーとデータを共有する必要がある場合、または少なくとも読み取りまたは書き込みアクセスを提供する必要がある場合は、他の形式をお勧めします。他の言語のリーダー/ライターの保守に時間を費やす理由はありません。コードではなくデータにすぎません。:)ストレージの作業に時間を費やすのではなく、賢明な方法でデータを操作する方法にコードを集中させます。他の人々はすでにそれについて非常に優れた仕事をしています。

于 2011-10-25T14:02:22.637 に答える
9

(バイナリ) ファイル形式には、次の 2 つの基本的な種類があります。

  • APIを使用してアドオン パッケージで拡張されている場合、さまざまなプログラムやアプリケーション間でのデータ交換を容易にする、パブリック ライブラリと API によってサポートされるアプリケーション ニュートラル(および netCDF と HDF5 の両方がこのキャンプに分類されます)

  • より効率的ではありますが、1 つのプログラムでのみ動作するように設計されたアプリケーション固有のもの: それが .RData の機能です。

R はオープンソースであるため、Matlab ファイルから RData の形式を再作成できます。適切な mex ファイルを作成することを妨げるものは何もありません。たぶん、誰かがすでにそれを行っているかもしれません。試してはいけない技術的な理由はありませんが、データを共有する両方のアプリケーションが同じようにフォーマットをサポートしている場合は、別のルートの方が簡単かもしれません。

価値があるのは、1990 年代の初めから中頃に、Octave で使用されるバイナリ形式でシミュレーション ファイルを書き込むための独自の C コードを作成したことです (これを使用してからデータをスライスしました)。オープンソース ソフトウェアでこれを実行できることは、大きな利点です。

于 2011-10-20T17:37:16.793 に答える
5

これらの質問の一部にはお答えできると思いますが、すべてではありません。

  1. まあ、気になる人なら誰でもおそらく.Rdataファイルを直接読み取ることができますが、それは大変な作業であり、あまりメリットがありません. したがって、Matlab がそれを行ったとは思えません。覚えているかもしれませんが、R は他のさまざまなシステム形式を読み取ることができます。

  2. テキスト形式のcsvはかなり「標準」のようですが、バイナリ形式の場合はわかりません-そしてcsvはその点では適切な標準ではありません-(特に)日付と引用符がどのように処理されるかは大きく異なります(もちろん、それはデータ テーブル)。

  3. もちろん！

例：

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))
}
于 2011-10-20T16:02:55.677 に答える
4

ポイント 2 は間違っています。バイナリ .RData ファイルは、ハードウェアと OS プラットフォーム間で移植可能です。?save のヘルプ ページから引用するには:

すべての R プラットフォームは、バイナリの save-d ファイルで C の int と double の XDR (bigendian) 表現を使用し、これらはすべての R プラットフォームで移植可能です。

ポイント 1 は、データが何であるか、およびそのデータに有効に適用される可能性のある他のプログラムの関数です。コード ベースが save() を使用してデータフレームまたはマトリックスである指定されたオブジェクトを書き込む場合、小さな関数 save2hdf() を簡単に記述してそれらを hdf または ncdf バイナリ ファイルとして書き出すことができ、sed を使用してすべての save( をsave2hdf( コードベースで。少なくとも ncdf は読み取りでパフォーマンスに影響を与えますが、それほど悪くはありません。コードで異種オブジェクトのリストのような保存オブジェクトを使用している場合は、おそらく ncdf や hdf を使用することはできません。個別のコンポーネントオブジェクトを書き出すための再コーディングの取引。

また、R では netCDF 4 にまだ問題があることに注意してください。

于 2011-10-24T22:19:03.250 に答える