Apacheの寄木細工と矢印の違い
メモリを大量に消費するフロントエンドvisアプリを高速化する方法を検討しています。一部の人々がApache Arrowを推奨しているのを見たのですが、それを調べていると、ParquetとArrowの違いに戸惑っています。
どちらも列化されたデータ構造です。もともと私は寄木細工はディスク用であり、矢印はメモリ内フォーマット用だと思っていました。ただし、abc.arrowのように、矢印をデスクのファイルに保存できることを学びました。この場合、違いは何ですか？彼らは同じことをしていませんか？
Parquetは、データのシリアル化用の列形式のファイル形式です。 Parquetファイルを読み取るには、その内容をある種のメモリ内データ構造に解凍およびデコードする必要があります。デコードのCPU使用率を犠牲にして、スペース/ IO効率が高くなるように設計されています。インメモリコンピューティング用のデータ構造は提供されません。 Parquetはストリーミング形式であり、最初から最後までデコードする必要がありますが、最近いくつかの「インデックスページ」機能がストレージ形式に追加されましたが、一般的にランダムアクセス操作にはコストがかかります。
一方、矢印は何よりもまずインメモリコンピューティングの列データ構造を提供するライブラリです。 Parquetファイルを読み取るときに、データを解凍してデコードすることができますinto矢印の列データ構造。これにより、デコードされたデータに対してメモリ内で分析を実行できます。矢印の列形式にはいくつかの素晴らしいプロパティがあります：ランダムアクセスはO(1)であり、各値のセルはメモリ内の前のセルと次のセルの隣にあるため、反復するのが効率的です。
それでは「矢印ファイル」はどうですか？ Apache Arrowは、メッセージングおよびプロセス間通信に使用できるArrowカラム配列（「レコードバッチ」と呼ばれる）のコレクションを配置するためのバイナリ「シリアル化」プロトコルを定義します。プロトコルは、ディスク上を含む任意の場所に配置できます。これは、後でメモリマップしたり、メモリに読み込んで別の場所に送信したりできます。
このArrowプロトコルは、逆シリアル化を行わずにArrowデータのblobを「マッピング」できるように設計されているため、ディスク上のArrowプロトコルデータに対して分析を実行すると、メモリマッピングを使用でき、実質的にゼロのコストを支払うことができます。プロトコルは、Spark SQLとPython for running pandas functions for chunks）の間でデータをストリーミングするなど、多くのものに使用されますSpark SQLデータ。これらは「パンダudfs」と呼ばれます。
一部のアプリケーションでは、ParquetとArrowを交換してディスク上のデータのシリアル化に使用できます。覚えておくべきいくつかの事柄：
- Parquetは「アーカイブ」を目的としています。つまり、今日ファイルを書き込んだ場合、「Parquetを読み取る」ことができるシステムでは、5年または7年でファイルを読み取ることができると考えられます。 Arrowフォーマットの長期的な安定性については、まだこの主張をしていません（将来的には可能性があります）。
- 寄木細工は、他のデータ構造にデコードする必要があるため、一般的に読み取るのがはるかに高価です。 Arrowプロトコルデータは、単純にメモリマップすることができます。
- Parquetが使用するデータエンコーディングスキームのため、Parquetファイルは多くの場合、Arrow-protocol-on-diskよりもはるかに小さくなります。ディスクストレージまたはネットワークが遅い場合、Parquetがより良い選択になります
つまり、要約すると、Parquetファイルはディスクストレージ用に設計されており、Arrowはインメモリ用に設計されています（ただし、ディスク上に配置し、後でメモリマップすることができます）。これらは相互に互換性があることを目的としており、アプリケーションで一緒に使用されます。
メモリを大量に消費するフロントエンドアプリの場合は、Arrow JavaScript（TypeScript）ライブラリを確認することをお勧めします。