Parquetとは？カラムナー ストレージ、スキーマ、および使用例

スクレイピングなしのAPIは、分析パイプラインが検証し、Apache Parquetに変換して繰り返しカラム指向のクエリを実行できるJSONまたはCSVの構造化されたウェブデータを返します。

Apache Parquetとは？

Apache Parquetは効率的なストレージと取得のためのオープンソースのカラム指向データファイル形式です。1つのレコードのすべてのフィールドを一緒に書き込むのではなく、Parquetは行の制限されたグループ内でカラムごとに値を整理します。分析エンジンは、すべてのレコードのすべてのフィールドをスキャンするのではなく、クエリに必要なカラムだけを読み取ることができます。

その Apache Parquetドキュメント は形式仕様、概念、ファイル形式の詳細、および実装リソースへのリンクを提供します。この形式はデータ処理エンジンおよび言語全体でサポートされているため、データレイク、データウェアハウス、特徴パイプライン、およびアーカイブ分析データセットに共通のストレージ境界を提供します。

Parquetはバイナリです。テキストエディターで開いて編集することを意図していません。リーダーライブラリは、ファイルに保存されたメタデータを使用してカラムチャンクを見つけ、ページをデコードし、圧縮コーデックを適用し、行やカラムベクトルを再構築します。

カラムナー ストレージの重要性

顧客ID、国、カテゴリ、説明、価格、イベント時刻を含むデータセットを考えてみてください。国ごとの平均価格を計算するクエリは、必要なカラムが3つだけです。行指向のテキストファイルでは、エンジンは未使用のフィールドである説明を読み続けます。Parquetでは、エンジンは必要なカラムチャンクを選択できます。

カラムの値は隣接する値に似ている傾向があります。国カラムは小さなコードのセットを繰り返すかもしれませんし、ブールカラムは非常に低いカーディナリティを持つかもしれません。ソートされたタイムスタンプは小さなデルタを持つかもしれません。エンコーディングと圧縮は、無関係なフィールドタイプが行ごとに交互に並ぶレイアウトよりもこれらのパターンをより効果的に利用することができます。

カラムナー ストレージがすべての操作を速くするわけではありません。個々のレコードを完全に再構築するには多くのカラムチャンクに触れる必要があります。1つのレコードを更新することは、通常、多くのデータを再書き込み、行をその場で変更することを意味します。Parquetはスキャン、集約、フィルタリング、選択的プロジェクションを好みます。

Parquetファイルの構成方法

Parquetファイルには、複数のレイヤーを通じて組織されたメタデータとエンコードデータが含まれています：

• ファイルメタデータ。 フッターには、スキーマ、行グループ、カラムの位置、エンコーディング、圧縮情報、およびオプションのキー・バリューメタデータが記録されています。
• 行グループ。 行グループは行の水平方向のパーティションです。その行範囲内の各カラムは、カラムチャンクとして保存されます。
• カラムチャンク。 チャンクは、1つの行グループ内の1つのカラムの値を含み、ページに分割されます。
• ページ。 ページはエンコーディング、圧縮、および一部の統計が適用され、読み取られる単位です。
• フッター。 ファイルの末尾のメタデータにより、リーダーはレイアウトを発見し、フェッチするデータ範囲を選択する前に情報を得ることができます。

詳細な構造とエンコーディングは、 Apache Parquet形式仕様リポジトリに存在します。実装は異なるサブセットまたはオプションの機能をサポートする可能性があるため、パイプラインはそのライターとリーダー全体で互換性をテストする必要があります。

物理的および論理的タイプ

Parquetは、整数、浮動小数点値、バイト配列、固定長バイト配列を含む低レベルストレージを制御する物理タイプを定義します。論理タイプの注釈は、文字列、十進数、日付、時間、タイムスタンプ、UUID、リスト、マップ、および整数の幅など、ドメイン意味を追加します。

十進数値は、区別が重要である理由を示しています。その物理バイトは整数またはバイト配列として保存されるかもしれませんが、論理注釈は精度とスケールを提供します。リーダーは両方のレイヤーを必要とし、意図された値を正しく再構築します。

スキーマ設計はビジネスの意味を保持すべきです。タイムスタンプには文書化されたタイムゾーンの解釈が必要です。十進の精度は期待される値をカバーしなければなりません。数字に見える識別子は文字列型に属する可能性があります。後のファイルがより大きな値を含む可能性がある場合、ライターは小さなサンプルから狭いタイプを推測してはいけません。

Parquetのネストされたデータ

Parquetは、ネストされたレコード、リスト、およびマップを表すことができ、すべてのデータセットをフラットなテーブルに強制することはありません。ネストされたフィールドが存在するかどうか、および繰り返された値が再構築された構造のどこに属するかをエンコードするために、定義レベルと繰り返しレベルを使用します。

この能力により、Parquetは配列または子オブジェクトを含む検証済みJSONレコードの自然な目的地になります。変換には安定したスキーマが必要です。1つのレコードがフィールドを文字列として格納し、別のレコードが同じ名前の下にオブジェクトを格納する場合、ライターは信頼できるデータセットを生成する前にその衝突を解決する必要があります。

ネストされたカラムは、すべての子を行にフラットにすることと比較して、繰り返される親データを削減できます。また、エンジンがネストされた構造を異なって公開する場合には、クエリや相互運用性が複雑になることがあります。パイプラインで使用される正確なリストおよびマップの形状をテストしてください。

Parquet vs CSVおよびJSON

圧縮、エンコーディング、および統計

パーケットはエンコーディングを圧縮から分離します。エンコーディングは、圧縮コーデックがページバイトを処理する前に値を効率的に表現します。実装は、辞書エンコーディング、ランレングステクニック、ビットパッキング、デルタエンコーディング、または種類とデータに基づいたプレーン表現を選択できます。

メタデータ統計には、最小および最大値、nullのカウント、その他のインデックスが含まれる場合があります。クエリエンジンは、値の範囲がフィルタを満たすことができない行グループをスキップするためにそれらを使用できます。これはストレージ層での述語プッシュダウンまたはプルーニングです。データの組織と統計がクエリの述語と一致する場合、I/Oを削減します。

統計はアクセス制御の代替にはならず、ファイルメタデータを読むことができる誰にでも値の範囲またはカウントを明らかにする可能性があります。センシティブなデータセットには、ストレージ権限、暗号化制御、およびオブジェクトおよびカタログ層でのガバナンスが必要です。

パーティション、ファイル、および小ファイル問題

データセットはしばしば、日付や地域などの頻繁にフィルタリングされる値でパーティション分割されたディレクトリにパーケットファイルを配置します。クエリエンジンは、ファイルメタデータを開く前に全体のパスをスキップできます。パーティションフィールドは制御された基数を持つべきです；ユーザーごとまたはリクエストごとにディレクトリを作ると、管理が難しい数の小さなパーティションが生成される可能性があります。

多くの小さいファイルは、計画、リスト、接続、メタデータのオーバーヘッドを追加します。また、各ファイルの内部で効果的な圧縮のために利用可能なデータの量を減らします。パイプラインは通常、小さな出力をクエリエンジンとオブジェクトストアのサイズに合わせたファイルに圧縮し、プルーニングをサポートするパーティションの境界を保持します。

すべてのシステムに適合する普遍的なファイルサイズはありません。オブジェクトストアの動作、クエリの同時実行、行の幅、メモリの制限、書き込みの間隔、およびエンジンの指針に基づいて選択します。計画時間とスキャンスループットの両方を測定します。

パーケットはテーブルフォーマットではありません

パーケットファイルは、そのファイル内のデータを記述します。それ自体では、数千のファイルにわたるトランザクションログ、スナップショットのアイソレーション、アトミックなマルチファイルコミット、行レベルの変更、または現在のテーブル状態に属するファイルのカタログを提供しません。

データプラットフォームは、そのカタログとテーブルレイヤーを通じてそれらの懸念を管理できます。この区別は、更新およびスキーマ変更中に重要です。ディレクトリ内のすべてのオブジェクトをリストし、それを現在のデータと見なすと、周辺システムがコミットセマンティクスを定義しない限り、 obsoleteまたは部分的に書き込まれたファイルが含まれる可能性があります。

スキーマの進化

オプションのカラムを追加することは、古いファイルが単にそれを欠いており、リーダーがnullを供給できるため、しばしば管理可能です。カラムの名前を変更するのは難しいです；名前ベースのリーダーは、異なる2つのフィールドを見るかもしれません。一部のエコシステムは安定したフィールド識別子を追跡しますが、サポートはライター、リーダー、およびテーブルレイヤー全体で一貫している必要があります。

物理的または論理的な型を変更するには互換性プランが必要です。整数を広げることは一部のリーダーで機能するかもしれませんが、文字列をネストされたレコードに変更することはセマンティックな破綻です。スキーマのバージョンを保存し、公開前に新しいファイルを検証し、混合バージョンの読み込みをテストします。

1つのファイルのスキーマに全体のデータセット契約を依存させないでください。ディレクトリには、異なるジョブまたは異なる時間に書かれたファイルが含まれている可能性があります。カタログスキーマとインジェッション検証は、受け入れられるものを定義する必要があります。

一般的なParquetの使用ケース

Parquetを使用しないべき時

Parquetは、人々が手動で編集する必要のあるドキュメント、公共APIレスポンス、または小さな独立したメッセージのストリームには適しません。また、インデックスまたはテーブルエンジンなしでの頻繁な単一行の更新や直接のキー値の検索には不便です。

CSVは簡単なアナリストの引き渡しに適しているかもしれません。JSONやNDJSONはサービスやイベント処理に適しているかもしれません。トランザクショナルデータベースは、変更可能な操作状態に適しているかもしれません。同じパイプラインが、1つの形式で生入力を受け入れ、Parquet形式でキュレーションされた分析レイヤーを公開できます。

信頼性のあるParquetデータを作成する方法

1. 標準スキーマを定義します。 null許可、論理型、タイムスタンプの意味、小数精度、ネスト構造を指定します。
2. 受信レコードを検証します。 ファイルを書き込む前に、型の競合や不正な値を解決します。
3. 測定によって行グループとファイルターゲットを選択します。 メモリ、圧縮、並列性、メタデータのオーバーヘッドのバランスを取ります。
4. 実際のフィルタのためにパーティションを分けます。 高基数のパスや空のパーティションを避けます。
5. すべてのリーダーをテストします。 ネストされた型、論理的注釈、圧縮コーデック、展開されたエンジンセット全体でのスキーマの進化を確認します。
6. データセットレイヤーを通じて原子的に公開します。 検証とカタログの更新が成功するまで不完全なファイルを見えなくします。

結論

Apache Parquetは型付きレコードを列指向ファイルに変換し、分析システムが選択的に読み取ることができます。そのスキーマ、エンコーディング、圧縮、統計、およびネストデータのサポートは、多くのスキャン重視のワークロードに対して不必要なI/Oを削減します。これらの利点は、確りとしたデータセットデザインに依存します：制御されたスキーマ、適切なファイルと行グループ、有用なパーティション、互換性のあるリーダー、トランザクションやスナップショットが重要な場合のテーブルレイヤー。Parquetは、ユニバーサルなJSON、CSV、データベース、またはイベントフォーマットの置き換えとしてではなく、キュレーションされた分析の目的地として最も強力です。