Parquet と CSV

Scrapeless Google Search API は、下流のパイプラインが分析用テーブルに変換できる構造化された JSON を返します。

要約

Parquet は列指向のバイナリファイル形式です。 分析的な読者は、その構造を利用して特定の列やメタデータを読み取ることができます。
CSV はテキスト交換フォーマットです。 テーブルの契約が明示されていると、検査や大規模なインポートを行う際に便利です。
圧縮およびクエリの節約量は、データとリーダーに依存します。 代表的な測定値なしに、固定的な速度やサイズの主張は避けてください。
ファイル形式はデータベースではありません。 データセットの更新、トランザクションルール、およびカタログ管理には、追加の設計が必要です。

同じレコードが異なる作業に使われるとき、Parquet と CSV の比較が有用になります。小さなエクスポートを開くアナリストは、長い履歴にわたって選択されたフィールドをスキャンする定期実行クエリとは、異なる受け渡し方法を必要とします。フォーマットの選択は、ワークロード、受け取り側のツール、および値を保持するためのルールに従うべきです。

CSV はテキストを簡単に検査できるようにします。Parquet は型付きのカラムを整理し、分析的なアクセスを可能にします。Parquet を内部データセットとして保持しつつ、特定のレビュー用には CSV を公開することで、どちらの形式もすべての利用者にとっての唯一のソースにする必要はありません。

列形式ストレージは分析系の読み取り方法を変える

Parquet は、各レコードを区切り付きテキスト行として保存するのではなく、データを列指向の表現でグループ化します。 Parquet 形式の概要この形式が分析ワークロード向けの効率的な保存と取得に重点を置いていることを説明している。ごく一部のフィールドだけを必要とするリーダーは、無関係な列を具体化せずに済む。

CSV はテキストレコードの中にフィールドをまとめて配置します。パーサーは、最終的な解析で一部の列だけを保持する場合でも、一般的にレコード境界と区切り文字を解釈する必要があります。だからといって、CSV が小規模な作業に不向きになるわけではなく、横に広い履歴テーブルが別の表現形式の恩恵を受ける理由を説明しているのです。

クエリコンテキスト、URL、タイトル、および説明テキストを含む検索データセットを想像してください。ドメイン頻度レポートには、ドメインとキャプチャコンテキストが必要ですが、すべてのタイトルやスニペットは必要ありません。カラム指向リーダーは、そのように範囲が狭い要件を利用できます。実際の節約効果は、データセットの書き込み方法とクエリ方法に依存します。

次元	Parquet	CSV
表現	型付きバイナリ列	区切られたテキストレコード
選択した列	リーダーは必要な列データを読み取ることができる	パーサーはテキストレコードを解釈する
人による検査	互換性のあるビューアが必要です	テキストおよびテーブルツールで読み取り可能
ネストされた値	テキストがまだ送信されていないようです。翻訳する英語のテキストをそのまま貼り付けてください。	変換規約が必要です
共有の更新	データセットの調整が必要	データセットの調整が必要

CSV には方言が必要で、Parquet には互換性のある型が必要

CSV の相互運用性は、宣言されたテキスト規約に依存します。 CSV の引用とレコードのルールフィールド内のカンマや改行など、一般的なケースを網羅します。エンコーディング、区切り文字の選択、null の解釈については、依然として利用者との合意が必要です。

Parquet はスキーマ情報を保持しますが、スキーマが存在していても、すべてのエンジンがすべての論理型を同一の方法で解釈することが保証されているわけではありません。タイムスタンプの単位、タイムゾーンの扱い、小数の精度、拡張型などによって、互換性に関する問題が生じることがあります。本番データセットを書き出す前に、下流のツールがどの論理型をサポートしているかを確認しておきましょう。

どちらの形式でも、識別子は識別子として扱ってください。先頭にゼロが付いた値は、すべての文字が数字であっても、それだけを理由に数値に変換すべきではありません。複数の文脈が現れうる場合は、通貨や計量単位を列名の外側で定義してください。エクスポートを受け入れる前に、非 ASCII 文字、欠損値、および大きな識別子を含む、あえて扱いにくくしたレコードをテストしてください。

行グループと統計により選択的な処理が可能になる

Parquet ファイルには、保存された値を整理するための行グループ、カラムチャンク、およびページが含まれています。 Parquet ファイルのレイアウトそれらの構造について説明します。読者は、フィルタがファイルの一部を除外する場合に作業を回避するために、利用可能なメタデータや統計情報を使用できます。

この機能は条件付きです。フィルターは、エンジンがそれを適用でき、かつ保存されたメタデータが有用な情報を提供する場合にのみ役立ちます。すべての行グループがフィルター対象の値の全範囲をまたいでいる場合、フィルターはほとんど除外できないかもしれません。選択された列は、そのデータが必要とされるときには、なおデコードが必要です。

実際のクエリを基準に設計してください。レポートが通常、期間とマーケットを選択するのであれば、それらの制約によってスキャン範囲を絞り込めるようにデータセットを配置します。ファイル拡張子を指定すればあらゆる最適化が有効になると仮定するのではなく、リーダーの実行動作を検証してください。データセット全体を読み込んでから後段でフィルタするクエリでは、期待されるメリットを享受できません。

圧縮はワークロードとのトレードオフ

圧縮は、エンコードおよびデコード処理のコストと引き換えに、保存バイト数を削減します。Parquet はカラムエンコーディングと圧縮を組み合わせることができ、隣接する値にエンコーディングが活用できるパターンがある場合に有用です。CSV も圧縮できるため、公平な比較を行うには、両者で実際に配信される表現形式を含めて評価する必要があります。

代表的な値を用いて、書き込み時間、読み込み時間、ピークメモリ、および転送バイト数を測定しましょう。繰り返しカテゴリのカラムは、すでに圧縮されている、あるいは非常に変動の大きいテキストのカラムとは異なる挙動を示します。選択したコーデックやリーダー実装は、ファイル形式と同様に重要です。

1 つの計測結果を普遍的な比率に変換することは避けてください。テーブル全体のエクスポート、選択カラムに対する集計、単一レコードの調査では、それぞれ異なるコストがかかります。受け入れ対象となるクエリと、想定されるハードウェアもしくはサービス構成を定義してください。機械向けの分析表現がバイナリであっても、トラブルシューティングを容易にするために、人間がレビューするためのエクスポートを残しておきましょう。

パーティション分割と小さなファイルには別々の計画が必要

パーティション分割されたデータセットは、リーダーが関連するサブセットを選択できるようなレイアウトを持つファイル群の集合です。 Arrow の Parquet データセット処理では、個々のファイルとパーティション分割されたコレクションの両方について説明しています。パーティションレイアウトは、Parquet ファイルを書き出すと自動的に付与される性質ではなく、追加で選択する設計項目です。

パーティションキーは、よく使われるフィルターと想定されるレコード数から選んでください。非常に高いカーディナリティのキーは多数の小さなファイルを生み出す一方、粒度の粗いキーではほとんど絞り込みができない場合があります。データセットに極端に小さなオブジェクトが大量に含まれていると、ファイル一覧取得やメタデータ処理がクエリの支配的なコストになり得ます。

更新セマンティクスは明示的に保ちましょう。新しいファイルを追加すると、すでに他の場所に存在する業務レコードが重複する可能性があります。ファイルを安全に置き換えるには、メタデータ変更を協調して行えるカタログやテーブル形式が必要になることがあります。CSV と Parquet だけでは、共有の可変データセットに対するトランザクションプロトコルは提供されません。利用者は、どのファイル群が完全に公開されたスナップショットを構成するのかを知る必要があります。

検索取得とストレージの決定を分けて考える

取得用 API と分析ストレージ形式は、ワークフローの異なる段階を解決するためのものです。 Scrapeless Google Search API は構造化された検索 JSON を返します。パイプライン側でテーブル粒度を選び、フィールドを検証し、次の利用者のために Parquet または CSV として書き出します。

テーブルを構築する際には、クエリコンテキスト、マーケット、言語、取得主体、結果カテゴリを保持してください。分析用の射影で省かれたネストした詳細が必要な場合に備えて、元のレスポンスは別途保持します。ウェブデータストレージに関する議論は、エクスポートをより広いデータパイプラインの中でどこに位置付けるかについての文脈を提供します。

現在の Scrapeless pricingに基づいて取得コストを見積もり、そのうえでデータセットを保持するシステムにおけるストレージおよびクエリコストを測定してください。より小さな分析ファイルになっても、どのリクエストが行われたかは変わりませんし、リクエストが成功したからといって、得られたテーブルが意図したスキーマやレコード網羅性を備えていることが保証されるわけではありません。

繰り返し行う分析には Parquet を、受け渡しには CSV を選ぶ

互換性のある分析ツールが、選択されたフィールドを繰り返し読み出し、フィルターを適用し、型付きストレージの利点を活かせる場合には Parquet を選びましょう。受け取り側がポータブルなテーブル、簡単なインポート、あるいは直接のテキスト確認を必要とする場合には CSV を選びます。利用者が異なり、検証済みの同一変換を共有できるのであれば、両方の出力を保持してもかまいません。

性能を比較する前に、値が正しく保持されているか確認してください。想定する粒度での行数、識別子の値、null の数、小数の扱い、タイムスタンプの解釈を検証します。書き出しに使ったものと同じツールだけに頼るのではなく、下流のツールで出力を読み込んで確認してください。

データセットとともに、スキーマ、パーティション方式、公開境界を記録してください。フィールドの意味が変わった場合は、古いファイルと新しいファイルが暗黙のうちに食い違うことのないよう、明示的なマイグレーションを作成します。不整合なデータに対するクエリが高速であっても、その結果は依然として信頼できません。フォーマットの選択は、所有権とバリデーションが明確になっているときに最も良く機能します。

結論

Parquet vs CSV は、どちらか一方が永続的な勝者となる競争ではなく、ワークロードに応じた選択です。繰り返し行う分析読み取りには互換性のある型付きカラムナストレージを使い、表形式の受け渡しには仕様のはっきりした CSV を使いましょう。受け取り側のエンジンで値を検証し、実際のクエリを測定し、パーティション分割とデータセット更新は明示的な設計責任として扱ってください。

分析用の検索データセットを構築する準備はできましたか？

Google Search API で構造化された検索レコードを収集し、検証済みテーブルを下流のツールが必要とする形式で公開しましょう。

今すぐ登録して $5 分の無料クレジットを獲得 — クレジットカードは不要です.

$5 のクレジットを今すぐ受け取る →

FAQ

Parquet は常に CSV より小さいですか？

Parquet があらゆる CSV 表現よりも必ず小さくなるとは限りません。データ分布、エンコーディング、圧縮、ファイルサイズが結果に影響します。ワークフローで実際に使用する圧縮方式と書き込み設定を用いて、同等のレコード同士を比較してください。

Parquet をテキストエディタで開けますか？

Parquet はバイナリ形式であるため、テキストエディタで通常の可読なテーブルとして表示することはできません。互換性のあるライブラリやビューアを使用して、そのスキーマ、メタデータ、値を確認してください。テキストベースの受け渡しが必要な相手には、CSV ビューを生成して渡しましょう。

Parquet はデータウェアハウスの代わりになりますか？

Parquet はそれ自体ではデータウェアハウスの代わりにはなりません。これはファイル形式です。クエリ実行、アクセス制御、カタログ、トランザクション、信頼できるデータセット公開には、別のコンポーネントが必要です。ウェアハウスやレイクのアーキテクチャは、ストレージ設計の一部として Parquet を使用する場合があります。

小規模な一度きりのエクスポートに Parquet を使うべきか？

小規模な一度きりのエクスポートでは、受け取り側が正確に利用できる形式を使うべきです。CSV はスプレッドシートでの確認に実用的であることが多く、型の互換性や後の分析用途が重要な場合は Parquet が有用です。ファイルサイズだけで選ぶのではなく、値を検証してください。