メモリを大量に消費するフロントエンド vis アプリを高速化する方法を探しています。Apache Arrow を推奨している人がいるのを見ましたが、調べているうちに Parquet と Arrow の違いがよくわからなくなってしまいました。
どちらも列化されたデータ構造です。当初は parquet はディスク用、arrow はメモリ内形式用だと思っていました。しかし、desk で arrow を abc.arrow のようにファイルに保存できることを知りました。その場合、違いは何でしょうか? 同じことをしているのではないでしょうか?
ベストアンサー1
Parquet は、データのシリアル化のための列形式のファイル形式です。Parquet ファイルを読み取るには、その内容を何らかのメモリ内データ構造に解凍してデコードする必要があります。デコード時の CPU 使用率を犠牲にして、スペース/IO 効率を高めるように設計されています。メモリ内コンピューティング用のデータ構造は提供していません。Parquet は最初から最後までデコードする必要があるストリーミング形式ですが、最近ストレージ形式にいくつかの「インデックス ページ」機能が追加されましたが、一般にランダム アクセス操作はコストがかかります。
一方、Arrowは、何よりもまず、列指向データ構造を提供するライブラリです。インメモリコンピューティングParquetファイルを読むときは、データを解凍してデコードすることができます。の中へArrow 列データ構造を使用すると、デコードされたデータに対してメモリ内で分析を実行できます。Arrow 列形式には、ランダム アクセスが O(1) であり、各値セルがメモリ内で前のセルと次のセルに隣接しているため、反復処理が効率的であるという優れた特性があります。
では、「Arrow ファイル」はどうでしょうか? Apache Arrow は、メッセージングやプロセス間通信に使用できる Arrow 列配列のコレクション (「レコード バッチ」と呼ばれる) を配置するためのバイナリ「シリアル化」プロトコルを定義します。このプロトコルは、ディスク上を含む任意の場所に配置でき、後でメモリ マップしたり、メモリに読み込んで他の場所に送信したりできます。
この Arrow プロトコルは、デシリアライズを行わずに Arrow データの BLOB を「マップ」できるように設計されているため、ディスク上の Arrow プロトコル データの分析を実行するときにメモリ マッピングを使用し、実質的にコストをゼロにすることができます。このプロトコルは、Spark SQL と Python の間でデータをストリーミングして Spark SQL データのチャンクに対して pandas 関数を実行するなど、さまざまな目的で使用されます。これらは「pandas udfs」と呼ばれます。
一部のアプリケーションでは、ディスク上のデータのシリアル化に Parquet と Arrow を互換的に使用できます。次の点に注意してください。
- Parquet は「アーカイブ」目的に設計されています。つまり、今日ファイルを書き込むと、「Parquet を読める」と謳っているシステムは、5 年後または 7 年後にもそのファイルを読むことができると期待しています。Arrow 形式の長期的な安定性についてはまだ断言していません (将来的にはそうするかもしれませんが)。
- Parquet は、他のデータ構造にデコードする必要があるため、一般的に読み取りコストがかなり高くなります。Arrow プロトコルのデータは、単純にメモリマップできます。
- Parquet ファイルは、Parquet が使用するデータエンコード方式により、Arrow プロトコル オン ディスクよりもはるかに小さくなることがよくあります。ディスク ストレージまたはネットワークが遅い場合は、Parquet の方が適しています。
つまり、要約すると、Parquet ファイルはディスク ストレージ用に設計されており、Arrow はメモリ内用に設計されています (ただし、ディスク上に配置して後でメモリ マップすることもできます)。これらは互いに互換性があり、アプリケーションで一緒に使用されるように設計されています。
メモリを大量に消費するフロントエンド アプリの場合は、Arrow JavaScript (TypeScript) ライブラリを検討することをお勧めします。