列指向ストレージ形式を使用する
Apache Parquet
列指向ストレージ形式には以下の特性があるため、Athena での使用に適しています。
-
列のデータ型に合わせて選択された圧縮アルゴリズムによる列ごとの圧縮で、Amazon S3 のストレージ領域を節約し、ディスク容量とクエリの処理中における I/O を削減します。
-
Parquet および ORC での述語プッシュダウンにより、Athena クエリが必要なブロックのみを取得できるようになり、クエリパフォーマンスが向上します。Athena クエリがデータから特定の列値を取得すると、データブロック述語からの統計 (最大値や最小値など) を使用して、そのブロックを読み取るかスキップするかを判断します。
-
Parquet および ORC でのデータの分割により、Athena がデータの読み取りを複数のリーダーに分割して、クエリ処理時における並列化を向上させることが可能になります。
既存の raw データを他のストレージ形式から Parquet または ORC に変換するには、Athena で CREATE TABLE AS SELECT (CTAS) クエリを実行してデータストレージ形式を Parquet もしくは ORC として指定する、または AWS Glue クローラを使用することができます。
Parquet または ORC のどちらかを選択する
ORC(最適化された列指向)または Parquet のどちらを選択するかは、特定の使用要件によって異なります。
Apache Parquet は効率的なデータ圧縮とエンコーディングスキームを提供しており、複雑なクエリの実行や大量データの処理に最適です。Parquet は Apache Arrow
ORC は Hive データを効率的に保存する方法を提供します。ORC ファイルは Parquet ファイルよりも小さいことが多く、ORC インデックスを使用するとクエリを高速化できます。さらに、ORC は構造体、マップ、リストなどの複雑な型をサポートしています。
Parquet または ORC のいずれかを選択するには、以下の点を考慮してください。
クエリのパフォーマンス — Parquet はより幅広い種類のクエリをサポートしているため、複雑なクエリを実行する場合は、Parquet の方が適している場合があります。
複雑なデータ型 — 複雑なデータ型を使用している場合は、ORC の方が幅広い複合データ型をサポートしているので、より適している場合があります。
ファイルサイズ — ディスク容量が懸念される場合、通常、ORC を使用するとファイルが小さくなり、ストレージコストを低減できます。
圧縮 — Parquet と ORC はどちらも優れた圧縮機能を備えていますが、最適な形式は特定のユースケースによって異なります。
進化 — Parquet と ORC はどちらもスキーマの進化をサポートしています。つまり、時間の経過とともに列を追加、削除、または変更できます。
Parquet と ORC はどちらもビッグデータアプリケーションに適していますが、選択する前にシナリオの要件を検討してください。データとクエリに対してベンチマークを実行して、どの形式がユースケースに適したパフォーマンスを発揮するかを確認することをお勧めします。
列形式に変換する
JSON や CSV などのソースデータを列指向形式に簡単に変換するためのオプションには、CREATE TABLE AS クエリや、AWS Glue でのジョブの実行などがあります。
-
CREATE TABLE AS
(CTAS) クエリを使用すると、データを Parquet または ORC に 1 ステップで変換できます。例については、「CTAS クエリの例」ページの「例: クエリ結果を異なる形式で書き込む」を参照してください。 -
ETL に Athena を利用して CSV から Parquet にデータを変換する方法については、「ETL およびデータ分析での CTAS および INSERT INTO を使用する」を参照してください。
-
CSV データを Parquet に変換する AWS Glue ジョブの実行については、AWS Big Data ブログの記事「AWS Glue と Amazon S3 を使用してデータレイクの基礎を構築する
」の「データを CSV 形式から Parquet 形式に変換する」を参照してください。AWS Glue では CSV データの ORC への変換、あるいは JSON データの Parquet または ORC への変換にも同じ手法を使用できます。