AWS 道場 04–05

Glue Data Catalog と Athena — S3のファイルをテーブルとして読む

S3にファイルを置くだけでは、データを安全にSQLで扱えません。実体・メタデータ・クエリ実行の三層を分けると、GlueとAthenaの役割が明快になります。

TL;DR

  1. S3はデータ本体、Data Catalogは型と場所を表すメタデータ。
  2. CrawlerはS3を走査して、テーブル定義をCatalogへ作る。
  3. AthenaはCatalogを手掛かりにS3を読むため、常駐DBを持たずに分析できる。

01Catalogはデータのコピーではなく、読み方の目録である。

ファイルの保存場所と、SQLから見える表構造を切り離して理解する。

Catalogはデータのコピーではなく、読み方の目録である。
左のS3は実体、右のCatalogカードは読み方だけを持つ点に注目する。

Catalogのtableには、列名・型とs3://...のlocationが登録されるが、元のParquetファイルはS3に残る。

Catalogのテーブル削除はS3オブジェクト削除と同義ではない。逆も同様で、両者のライフサイクルを分けて扱う。

02ファイルの配置と形式から、分析の入口を整える。

人手でDDLを書く代わりに、S3の構造を検査して分析の入口を作る。

ファイルの配置と形式から、分析の入口を整える。
S3プレフィックスからCrawlerを経て、Catalogの列定義へ変換される矢印をたどる。

日付プレフィックス配下のParquetをCrawlerが読み、timestamp・user_id・actionなどを列としてテーブルへ登録する。

自動推定は正解を保証しない。同じ列に異なる型が混ざる場合や入力形式が変わる場合は、推定結果を検証する。

03ログを分析向けの列指向形式へ寄せる。

分析時に読むデータ量を、ファイル形式とクエリの両方で減らす。

ログを分析向けの列指向形式へ寄せる。
JSONが行全体を読む側、Parquetが必要列へ寄せて読む側として対比されている。

actionとtimestampだけを集計するクエリでは、列指向のParquetが不要なpayload列の読み取りを抑えやすい。

Parquet変換はスキーマ依存。ログへ列を追加したら、変換定義・Catalog・既存クエリへの影響を確認する。

結論

  1. S3の実体、Catalogの目録、AthenaのSQL実行を三層で考える。
  2. CrawlerはS3をテーブルとして扱い始める入口。
  3. Parquet化は分析効率を上げるが、スキーマ管理とセットで扱う。