おそらく CSV ストレージに代わる最良の方法: Parquet データ

Apache Parquet は、CSV などの従来の方法と比較して、データの保存と取得に関していくつかの利点を提供します。

Parquet 形式は、複雑な型のデータ処理を高速化するために設計されています。この記事では、今日の増え続けるデータ ニーズに Parquet 形式がどのように適しているかについて説明します。

Parquet 形式の詳細を掘り下げる前に、CSV データとは何か、そしてそれがデータ ストレージにもたらす課題について理解しましょう。

CSVストレージとは何ですか?

データを整理およびフォーマットする最も一般的な方法の 1 つである CSV ( カンマ 区切り 値 ) については、誰もがよく聞いたことがあるでしょう。 CSV データ ストレージは行ベースです。 CSV ファイルは .csv 拡張子で保存されます。 Excel、Google スプレッドシート、または任意のテキスト エディタを使用して CSV データを保存したり開いたりできます。ファイルを開くと、データがすぐに 表示されます 。

そうですね、それは良くありません。データベース形式としては間違いなくそうではありません。

さらに、データ量が増加すると、クエリ、管理、取得が困難になります。

.CSV ファイルに保存されるデータの例を次に示します。

 EmpId,First name,Last name, Division
2012011,Sam,Butcher,IT
2013031,Mike,Johnson,Human Resource
2010052,Bill,Matthew,Architect
2010079,Jose,Brian,IT
2012120,Adam,James,Solutions

これを Excel で表示すると、次のような行と列の構造がわかります。

CSV ストレージの課題

CSV などの行ベースのストレージは、 作成 、 更新 、 削除 の操作に適しています。

では、CRUD での 読み取り についてはどうでしょうか?

上記の .csv ファイルに 100 万行があると想像してください。ファイルを開いて探しているデータを検索するには、かなりの時間がかかります。それほどクールではありません。 AWS などのほとんどのクラウドプロバイダーは、スキャンまたは保存されたデータの量に基づいて企業に料金を請求します。やはり、CSV ファイルは大量のスペースを消費します。

CSV ストレージにはメタデータを保存するための排他的なオプションがないため、データのスキャンは面倒な作業になります。

では、すべての CRUD 操作を実行するための、コスト効率が高く最適なソリューションは何でしょうか?探検してみましょう。

Parquet データ ストレージとは何ですか?

Parquet は、 データを保存するためのオープンソースのストレージ形式です。 Hadoop および Spark エコシステムで広く使用されています。 Parquet ファイルは .parquet 拡張子として保存されます。

Parquet は高度に構造化された形式です。データレイクに大量に存在する複雑な生データを最適化するためにも使用できます。これにより、クエリ時間を大幅に短縮できます。

Parquet は、行ベースと列ベース (ハイブリッド) のストレージ形式が混在しているため、データのストレージを効率化し、取得を高速化します。この形式では、データは垂直方向だけでなく水平方向にも分割されます。 Parquet 形式では、解析のオーバーヘッドも大幅に排除されます。

この形式により、I/O 操作の総数が制限され、最終的にはコストが制限されます。

Parquet はメタデータも保存します。メタデータには、データ スキーマ、値の数、列の位置、行グループの最小値、最大値の数、エンコードの種類などのデータに関する情報が保存されます。メタデータは、ファイル内のさまざまなレベルで保存されます。 、データアクセスが高速化されます。

CSV のような行ベースのアクセスでは、クエリが各行を移動して特定の列の値を取得する必要があるため、データの取得に時間がかかります。 Parquet ストレージを使用すると、必要なすべての列に一度にアクセスできます。

要約すれば、

• Parquet はデータストレージ用の柱状構造に基づいています
• 複雑なデータをストレージ システムに一括保存するために最適化されたデータ形式です
• Parquet 形式には、データ圧縮およびエンコードのためのさまざまな方法が含まれています
• CSV などの他のストレージ形式と比較して、データ スキャン時間とクエリ時間が大幅に短縮され、必要なディスク容量が少なくなります。
• IO操作の数を最小限に抑え、ストレージとクエリ実行のコストを削減します。
• データを見つけやすくするメタデータが含まれています
• オープンソースのサポートを提供します

寄木細工のデータ形式

例に入る前に、データがどのように Parquet 形式で保存されるかを詳しく理解しましょう。

1 つのファイル内に行グループと呼ばれる複数の水平パーティションを含めることができます。各行グループ内では、垂直パーティションが適用されます。列はいくつかの列チャンクに分割されます。データは列チャンク内のページとして保存されます。各ページには、エンコードされたデータ値とメタデータが含まれています。前に述べたように、ファイル全体のメタデータは行グループ レベルでファイルのフッターにも保存されます。

データは列チャンクに分割されるため、新しい値を新しいチャンクとファイルにエンコードして新しいデータを追加することも簡単です。その後、影響を受けるファイルと行グループのメタデータが更新されます。したがって、Parquet は柔軟なフォーマットであると言えます。

Parquet は、ページ圧縮および辞書エンコード技術を使用したデータの圧縮をネイティブにサポートしています。辞書圧縮の簡単な例を見てみましょう。

直接比較

CSV 形式と Parquet 形式がどのようなものであるかについてかなり理解できたので、次は両方の形式を比較する統計を作成します。

CSV	寄木細工
行ベースのストレージ形式。	行ベースと列ベースのストレージ形式のハイブリッド。
デフォルトの圧縮オプションが利用できないため、多くのスペースを消費します。たとえば、1 TB のファイルは、Amazon S3 またはその他のクラウドに保存するときに同じスペースを占有します。	保存中にデータを圧縮するため、消費するスペースが少なくなります。 Parquet 形式で保存された 1 TB のファイルは、わずか 130 GB のスペースしか必要としません。
行ベースの検索のため、クエリの実行時間が遅くなります。各列について、データのすべての行を取得する必要があります。	列ベースのストレージとメタデータの存在により、クエリ時間は約 34 倍高速になります。
クエリごとにさらに多くのデータをスキャンする必要があります。	クエリの実行のためにスキャンされるデータが約 99% 減少するため、パフォーマンスが最適化されます。
ほとんどのストレージ デバイスはストレージ容量に基づいて料金を請求するため、CSV 形式はストレージ コストが高くなります。	データは圧縮、エンコードされた形式で保存されるため、ストレージ コストが削減されます。
ファイル スキーマは、推論される (エラーが発生する) か、提供される (面倒な) 必要があります。	ファイル スキーマはメタデータに保存されます。
この形式は単純なデータ型に適しています。	Parquet は、ネストされたスキーマ、配列、辞書などの複雑な型にも適しています。

結論👩‍💻

コスト、柔軟性、パフォーマンスの点で、Parquet が CSV よりも効率的であることを例を通して見てきました。これは、特に全世界がクラウド ストレージとスペースの最適化に向かって進んでいる場合に、データの保存と取得に効果的なメカニズムです。 Azure、AWS、BigQuery などの主要なプラットフォームはすべて Parquet 形式をサポートしています。