ストレージ & データ

S4 Scan

Athenaスキャンコスト削減

スキャン料 30–70% 削減置き換え対象のAWSサービス: Athena / Redshift Spectrum スキャン料

AthenaとRedshift Spectrumのスキャン請求を30〜70%削減。クエリが実際に読むレイアウトへS3データレイクのParquetを再最適化 — パーティション/行グループのプルーニング、辞書エンコード、zstd、小ファイル統合を、クエリ結果を変えない安全なshadow-then-swapで適用します。

S4 Scan は、Athenaのクエリ履歴からどの列が読まれどの述語がフィルタするかを学習し、基盤のS3 Parquetをそのクエリが望む物理レイアウトへ書き換えます: ホット列を先頭に、フィルタ列でソートして行グループ統計がプルーニングできるように、低カーディナリティ列を辞書エンコード、ファイルを効率的なサイズに統合、zstd圧縮。AthenaとRedshift SpectrumはS3からスキャンしたTB単位で課金するため、より小さくプルーニングしやすいレイアウトは直接かつ継続的な請求削減になります。安全性が製品の核で、ソースを決して上書きしません。

課題

Athena と Redshift Spectrum は、S3 から実際に読み取ったバイト数に対して課金します（既定 $5/TB、リージョン差あり）。Parquet の物理レイアウトがクエリのアクセスパターンに合っていないと、クエリは返す行のはるか多くを S3 からスキャンし、その分を毎月支払い続けることになります。料金はスキャンしたバイト数で決まるため、レイアウト次第で請求額そのものが上下します。

仕組み

1
クエリ履歴から学習

Glue カタログと Athena のクエリ履歴（ワークグループメトリクス・CloudTrail）を読み、各テーブルでよく読まれる列とフィルタに使われる述語を割り出します。
2
シャドウへ書き出して検証

最適化した Parquet を元データとは別のシャドウ領域に書き出し、値・NULL・decimal 桁・タイムゾーンまでクエリ結果が完全一致することを検証します。
3
Glue でスワップ（ロールバック付き）

検証通過後にのみ Glue テーブルのロケーションを差し替えます。データ移動ではなくカタログのポインタ移動で、ワンコマンドで元に戻せます。

特長

設計上安全: 最適化データはshadowロケーションに書き出し、クエリ結果一致(値・NULL・小数スケール・タイムゾーン)を検証してからGlueカタログ経由でswap。1コマンドでロールバック。ソースはin-placeで変更しない。

コミット前に節約額が見える: dry-runが実テーブルでの月額削減を試算し、パーティション/行グループのプルーニング・辞書+zstd・小ファイル統合に正直に按分。

ロックインなし・お守り不要: 出力は標準のAthena可読Parquet。AMIはEventBridgeスケジュールで再最適化し、節約が自動で積み上がる。

含まれるもの

クエリ履歴分析: 過去のクエリから hot 列・頻出述語・分割/ソートキー候補を集計し、最適化プランを導出。
パーティション + 行グループのプルーニング: 述語に整合した分割で対象外ファイルを丸ごとスキップし、ソート + min/max 統計で当たらない行グループを読み飛ばします。
辞書/RLE エンコード + zstd 圧縮: 低カーディナリティ列を辞書化し、Athena が読める標準 zstd で再圧縮して列の読み取りバイトを削減。
小ファイルコンパクション: 多数の小さなオブジェクトを、I/O と統計に効く適正サイズのファイルへ統合。
シャドウ→検証→スワップとワンコマンドのロールバック: 元データは決して上書きせず、切替は Glue のポインタ移動のみ。
dry-run による月額削減見積り: 何も書き込まずに現状と最適化後のスキャンバイト・月額差を提示し、削減をパーティション/行グループ/辞書+zstd/コンパクションに正直に按分。
EventBridge スケジュールでの再最適化と、ロックインのない Athena 互換の標準 Parquet 出力。

こんな用途に

Athena / Redshift Spectrum のスキャン課金が高く、SQL を書き換えずに請求額を下げたいケース。

列数の多いテーブルで、クエリは少数の列だけを読み少数の述語で絞るのに、ファイル全体をスキャンしてしまっているケース。

多数の小さな Parquet オブジェクトに断片化したデータレイクで、I/O 効率と統計が悪化しているケース。

データが増え続けるため、EventBridge スケジュールで継続的に再最適化を回したいケース。

よくある質問

データが壊れたり、クエリ結果が変わったりしませんか?

元データは一切その場で書き換えません。最適化結果は別のシャドウ領域に書き出し、値・NULL・decimal 桁・タイムゾーン・ネスト型まで結果が一致することを検証してから、Glue のポインタを差し替えるだけです。検証に失敗すればスワップせずシャドウを破棄し、元データはそのまま。スワップ後もワンコマンドで元のロケーションに戻せます。

独自フォーマットにロックインされませんか?

いいえ。出力は標準の Athena 互換 Parquet（標準 zstd・辞書/RLE）のみで、独自 codec は使いません。いつでもロールバックでき、最適化後のデータも通常の Athena ツールでそのまま読めます。

何を最適化すべきか、どうやって判断するのですか?

Athena のクエリ履歴を学習します。どの列がよく読まれ、どの述語でフィルタされているかを集計し、列順・パーティションキー・ソートキーの推奨を導きます。推測ではなく実際のアクセスパターンに基づきます。

実行前に、いくら浮くか分かりますか?

はい。dry-run が何も書き込まずに、現状と最適化後のスキャンバイトおよび月額差を提示します。削減はパーティション/行グループのプルーニング、辞書+zstd、コンパクションに正直に按分されます。30〜70% は前提のずれ具合による幅であり保証値ではないため、まず自分のテーブルで dry-run してください。

どこで動作し、データは外に出ますか?

お客様の AWS アカウント / VPC 内の AMI として動作し、S3・Glue・Athena にアクセスするだけでデータを外部に送りません。EventBridge スケジュールで人手ゼロの運用ができ、最小権限の IAM ロールで実行されます。