HDF5とファイルのあるフォルダーとの違いは何ですか？
私は オープンソースプロジェクト に取り組んでいます。フォルダへのメタデータの追加を扱っています。提供されている（Python）APIを使用すると、単なる別のフォルダーのようにメタデータを参照してアクセスできます。それは別のフォルダだからです。
\folder\.meta\folder\somedata.json
それから HDF5 とその派生 Alembic に出会いました。
本のHDF5を読む PythonおよびHDF5 フォルダー内のファイルを使用するよりも使用することの利点を探していましたが、私が出会ったことのほとんどは、階層ファイル形式の利点について話しましたAPIを介してデータを追加する際の単純さの条件：
>>> import h5py
>>> f = h5py.File("weather.hdf5")
>>> f["/15/temperature"] = 21
または、リクエストに応じて特定の部分のみを読み取る機能（ランダムアクセスなど）、および単一のHDF5ファイルの並列実行（マルチプロセッシングなど）
HDF5ファイルをマウントできます https://github.com/zjttoefs/hdfuse5
GroupsとDatasetsの強力かつシンプルな基盤コンセプトを誇っていますwikiから：
- 同種型の多次元配列であるデータセット
- グループ。データセットや他のグループを保持できるコンテナー構造です。
DatasetをFileおよびに置き換えますGroupwithFolderおよび機能セット全体は、フォルダ内のファイルがすでに完全に実行できるように聞こえます。
私が出会ったすべての利益について、HDF5専用として目立った人はいませんでした。
だから私の質問は、HDF5ファイルを1つと、同じ内容のファイルを含むフォルダを1つ与えるとしたら、どのシナリオでHDF5がより適していますか？
編集：
HDF5の移植性についていくつかの回答を得ました。
それは素敵に聞こえますが、HDF5がファイルのあるフォルダーをしのぐシナリオの例はまだ与えられていません。フォルダーが任意のコンピューター、ネットワーク上の任意のファイルシステムで読み取り可能で、「パラレルI/O」をサポートし、HDF5インタープリターがなくても人間が読み取り可能な場合、なぜ誰かがHDF5の使用を検討します。
私が言った限りでは、ファイルのあるフォルダーは、HDF5よりもはるかにポータブルです。
編集2：
Thucydides411は、移植性が重要なシナリオの例を示しました。 https://stackoverflow.com/a/28512028/478949
このスレッドの答えから取っているのは、上の例のシナリオのように、たくさんの（数百万）小さい（〜1バイト）ファイルやフォルダーの組織構造が必要な場合にHDF5が適しているということです。データ構造;個々の数字や文字列のように。少数および大規模ではなく、小規模および多数を支持する「サブファイルシステム」を提供することにより、ファイルシステムに不足しているものを補うこと。
コンピューターグラフィックスでは、幾何学モデルと個々の頂点に関する任意のデータを格納するために使用します。これは、科学界での使用と非常によく一致すると思われます。
ファイルのフォルダーを使用してからHDF5に移行する科学プロジェクトを開発した人として、HDF5の利点に光を当てることができると思います。
プロジェクトを始めたとき、私は小さなテストデータセットを操作し、キロバイトの範囲で少量の出力を生成していました。最も簡単なデータ形式であるASCIIでエンコードされたテーブルから始めました。処理したオブジェクトごとに、ASCII table。
オブジェクトのグループにコードを適用し始めました。つまり、各実行の最後に複数のASCIIテーブルと、関連する出力を含むASCIIテーブルグループ全体に。各グループには、次のようなフォルダがありました。
+ group
| |-- object 1
| |-- object 2
| |-- ...
| |-- object N
| |-- summary
この時点で、私は最初の困難に直面し始めました。 ASCIIファイルは読み取りと書き込みが非常に遅く、数値情報は非常に効率的にパックされません。各桁がエンコードするのに〜3.3ビットではなく完全なバイトを必要とするからです。各オブジェクトをカスタムバイナリファイルとして書き込むことで、I/Oを高速化し、ファイルサイズを削減しました。
多数（数万から数百万）のグループの処理にスケールアップすると、突然、非常に多くのファイルやフォルダーを処理することに気づきました。小さなファイルが多すぎると、多くのファイルシステムで問題になる可能性があります（多くのファイルシステムでは、ディスク容量に関係なく、保存できるファイルの数に制限があります）。また、データセット全体で後処理を行おうとすると、多くの小さなファイルを読み取るためのディスクI/Oがかなりの時間を要し始めていることに気付き始めました。ファイルを統合することでこれらの問題を解決しようとしたため、各グループに対して2つのファイルのみを作成しました。
+ group 1
| |-- objects
| |-- summary
+ group 2
| |-- objects
| |-- summary
...
また、データを圧縮したかったので、グループのコレクション用に.tar.gzファイルを作成し始めました。
この時点で、データスキーム全体が非常に面倒になり、データを他の誰かに渡したい場合、その使用方法を説明するのに多大な労力がかかるというリスクがありました。たとえば、オブジェクトを含むバイナリファイルは、リポジトリと私のオフィスの紙の上のREADMEファイルにのみ存在する独自の内部構造を持ちました。私の結合オブジェクトバイナリファイルの場合、ヘッダー内の各メタデータエントリのバイトオフセット、タイプ、エンディアン、およびファイル内のすべてのオブジェクトのバイトオフセットを知る必要があります。
データをグループ化および圧縮する方法にも問題がありました。 1つのオブジェクトを見つけたいとしましょう。含まれている.tar.gzファイルを見つけ、アーカイブの内容全体を一時フォルダーに解凍し、興味のあるグループに移動し、独自のカスタムAPIでオブジェクトを取得してバイナリファイルを読み取る必要があります。完了したら、一時的に解凍したファイルを削除します。それはエレガントなソリューションではありませんでした。
この時点で、標準形式に切り替えることにしました。 HDF5は多くの理由で魅力的でした。まず、データの全体的な編成をグループ、オブジェクトデータセット、およびサマリーデータセットに保つことができました。第二に、カスタムバイナリファイルI/O APIを捨てて、多次元配列データセットを使用してすべてのオブジェクトをグループに格納することができます。 C構造体の配列のような、より複雑なデータ型の配列を作成することもできました。すべてのエントリのバイトオフセットを詳細に文書化する必要はありません。次に、HDF5にはチャンク圧縮があり、データのエンドユーザーに対して完全に透過的です。圧縮はチャンク化されているため、ユーザーが個々のオブジェクトを見たい場合は、各オブジェクトを別々のチャンクに圧縮して、ユーザーが関心のあるデータセットの部分のみを解凍する必要があります。チャンク圧縮は非常に強力な機能です。
最後に、内部でどのように編成されているかについてあまり説明することなく、今すぐ1つのファイルを誰かに渡すことができます。エンドユーザーは、コマンドラインまたはGUI HDFViewでPython、C、Fortran、またはh5lsでファイルを読み取り、中身を確認できます。 .tar.gzコレクションは言うまでもなく、これはカスタムバイナリフォーマットでは不可能でした。
確かに、HDF5でできることはすべて、フォルダー、ASCII、およびカスタムバイナリファイルを使用して複製できます。すべてを効率的でポータブルな方法でまとめていました。
この興味深い質問をしてくれてありがとう。ディレクトリをMacのスティックにコピーして、同じディレクトリとファイルをPCで見ることができるので、ファイルのあるフォルダーはポータブルですか？オペレーティングシステムを作成している人々のおかげで、ファイルディレクトリ構造は移植可能であることに同意しますが、これはファイル内のデータが移植可能であることとは無関係です。現在、このディレクトリ内のファイルがpdfの場合、複数のオペレーティングシステムでPDFを読み取って意味のあるツールがあるため、それらは移植可能です（Adobeのおかげです）。ただし、それらのファイルが未加工の科学データ（ASCIIまたはバイナリは重要ではない）である場合、それらはまったく移植性がありません。ASCIIファイルは次のようになりますXMLまたはjsonファイルの場合、jsonはASCIIであるため読み取り可能になりますが、含まれる情報はXML/jsonタグの意味のために移植性がない可能性がありますこれは重要なポイントです。ASCIIファイルの文字は移植可能ですが、それらが表す情報はそうではありません。
多くのオペレーティングシステムには、HDF5ファイルのデータを読み取ることができるツールがあります（pdfリーダーのように、 http://www.hdfgroup.org/products/hdf5_toolsを参照してください） /index.html ）。また、多くの言語のライブラリを使用して、データを読み取り、ユーザーにとって意味のある方法で表示することができます。これがAdobe Readerの機能です。 HDF5コミュニティには、ユーザーに対して同じことを行う何百ものグループがあります（ http://www.hdfgroup.org/HDF5/users5.html を参照）。
ここでも圧縮についていくつかの議論がありました。 HDF5ファイルでの圧縮に関する重要なことは、オブジェクトが独立して圧縮され、必要なオブジェクトのみが出力で解凍されることです。これは、ファイル全体を圧縮し、それを読み取るためにファイル全体を解凍するよりも明らかに効率的です。
もう1つの重要な点は、HDF5ファイルが自己記述的であることです。したがって、ファイルを作成するユーザーは、ユーザーやツールがファイルの内容を知るのに役立つ情報を追加できます。変数とは何か、そのタイプは何か、どのソフトウェアはそれらを書いたのか、どの楽器はそれらを収集したのか、など。あなたが取り組んでいるツールはファイルのメタデータを読むことができるようだ。 HDF5ファイル内の属性は、ファイル内の任意のオブジェクトに添付できます。これは単なるファイルレベルの情報ではありません。これは巨大です。そしてもちろん、これらの属性は、多くの言語と多くのオペレーティングシステムで作成されたツールを使用して読み取ることができます。
私にとって、最も重要なデータがメタデータのセットで記述された配列である科学データの関連するコンテキストでのみ、フォルダーとファイルをHDF5と比較できます。
一般的な文脈では、Marcusは、ファイルを含むフォルダーがどのHDF5よりもはるかに移植性が高いと主張していても大丈夫です。一般的な状況では、ファイルのあるフォルダーはHDF5ファイルよりもはるかにアクセスしやすいと付け加えます。明らかな課題は、「通常の」フォルダーとファイルでは、データにアクセスするための特別なAPIが必要ないことです。これは、データとメタデータを同じファイルに保持するHDF5では不可能です。
PDFファイルを読むには、HDF5を理解する新しいPDFリーダーが必要ですか？あなたの音楽を再生するには、HDF5をデコードできる音楽プレーヤーが必要だと想像してください。 pythonスクリプトを実行するには、pythonインタプリタはHDF5を最初にデコードする必要がありますか？または合計で、python =インタープリター、オペレーティングシステムはHDF5をデコードする必要がありますか？など。OSがWebブラウザーを起動できず、その読み取りができないため、この答えを書くことができません。以前はすべてをHDF5に変換していたため（おそらく、ハードドライブ内のすべてに対応する大きなHDF5）。
メタデータを個別のファイルに保存することには、頭痛の種を追加することなく、すでに存在する膨大な量のデータファイルやソフトウェアとうまく機能するという大きな利点があります。
これがお役に立てば幸いです。
多くのリソースをメモリにロードする必要があるゲームは、HDF5がファイルのあるフォルダーよりも優れているシナリオです。ファイルからのデータのロードには、シーク時間、各ファイルを開くのに必要な時間、およびファイルからメモリにデータを読み込むためのコストがかかります。 DVDまたはBlu-rayからデータを読み取る場合、これらの操作はさらに遅くなる可能性があります。単一のファイルを開くと、これらのコストを大幅に削減できます。
主な利点は移植性であると思います。
HDF5は、整数や浮動小数点数のサイズ、タイプ、エンディアンなどのデータセットに関する情報を保存します。つまり、異なるアーキテクチャのマシンで作成された場合でも、hdf5ファイルを移動して内容を読み取ることができます。
グループとデータセットに任意のメタデータを添付することもできます。ファイルシステムが拡張属性をサポートしている場合は、おそらくファイルとフォルダーでそれを行うこともできます。
Hdf5ファイルは単一のファイルで、フォルダーやファイルをZip/tarするよりも便利な場合があります。これには大きな欠点もあります。データセットを削除すると、新しいファイルを作成せずにスペースを再利用できなくなります。
一般に、HDF5は、大規模な数値配列、通常は科学的データセットの格納に適しています。
私は現在HDF5を評価しているので、同じ質問がありました。
この記事- HDF5からの退去 –はほぼ同じ質問をしています。この記事は、現代のオープンソース標準によって比較的不透明な状況で開発されたHDF5ライブラリの実装が1つしかないという事実について、いくつかの良い点を挙げています。
タイトルからわかるように、著者はHDF5から、JSONファイルのメタデータを持つ配列を含むバイナリファイルのファイルシステム階層に移行することを決定しました。これは、HDF5に多額の投資を行ったにもかかわらず、データの破損とパフォーマンスの問題で指を焼かれたにもかかわらずです。
はい、主な利点はHDF5がポータブルであることです。 HDF5ファイルには、Python（APIが構築されている）、MATLAB、Fortran、Cなど、他のプログラミング/解釈言語のホストがアクセスできます。Simonが示唆したように、HDF5は広く使用されています私の経験では、特定のデータセット（および領域）のみを取得する機能が有用であることがわかりました。さらに、並列I/O用のHDF5ライブラリを構築すると、rawの後処理に非常に有利です。後でデータ。
ファイルは自己記述型でもあるため、生データだけでなく、配列サイズ、配列名、ユニット、追加のメタデータのホストなど、そのデータの説明も保存できます。
お役に立てれば。
考慮すべき1つの要素は、ディスクアクセスのパフォーマンスです。 hd5fを使用すると、すべてがディスクの連続領域に保存されるため、ディスクのシークと回転が少なくなり、データの読み取りが速くなります。一方、ファイルシステムを使用してデータを整理するには、多くの小さなファイルから読み取る必要があるため、より多くのディスクアクセスが必要です。
HDF5は、最終的には、大規模なデータセット用に最適化された、数値を格納する形式です。主な長所は、圧縮のサポート（多くの状況でデータの読み取りと書き込みを高速化できる）および高速のカーネル内クエリ（特定の条件（たとえば、温度が30を超える場合の圧力のすべての値）を満たすデータの取得）です。 C）。
同じファイルに複数のデータセットを結合できるという事実は、単に便利です。たとえば、さまざまな気象観測所に対応する複数のグループを作成し、各グループを複数のデータテーブルで構成することができます。各グループには、機器の詳細を説明する属性のセットがあり、各テーブルには個々の設定があります。データのブロックごとに1つのh5ファイルを作成し、対応する場所に属性を設定すると、同じ機能が得られます。しかし、HDF5でできることは、最適化されたクエリのためにファイルを再パックし、全体をわずかに圧縮し、情報を非常に高速に取得することです。複数のファイルがある場合、各ファイルは個別に圧縮され、OSはディスク上のレイアウトを決定しますが、これは最適ではない可能性があります。
HDF5で最後に許可されることの1つは、ディスクと同じAPIを公開するメモリ（ファイル）を読み込むことです。そのため、たとえば、データのサイズと使用可能なRAMに応じて、1つまたは他のバックエンドを使用できます。あなたの場合、これはLinuxの関連情報を/ dev/shmにコピーすることと同等であり、変更をディスクにコミットする責任があります。