何を学ぶか
実務では 何がこの仕組みの入口になるか？ を先に確認する。設定値だけでなく、入力と出力の境界を明確にする。
Glue CrawlerとData Catalog
S3に置かれたログを、AthenaがSQLで読めるテーブル定義へ変換する流れを掴む。
TL;DR — この章で学ぶこと
- S3のファイルとテーブル定義は別物
- Crawlerがスキーマを推定する
- Parquet化とスキーマ変化を扱う
01S3のファイルとテーブル定義は別物
何がこの仕組みの入口になるか？ — S3のファイルとテーブル定義は別物を、構成図の矢印から読み解く。
02Crawlerがスキーマを推定する
どのサービスが責任を持つか？ — Crawlerがスキーマを推定するを、構成図の矢印から読み解く。
何を学ぶか
実務では どのサービスが責任を持つか？ を先に確認する。設定値だけでなく、入力と出力の境界を明確にする。
03Parquet化とスキーマ変化を扱う
失敗時にはどこへ戻る／進むか？ — Parquet化とスキーマ変化を扱うを、構成図の矢印から読み解く。
何を学ぶか
実務では 失敗時にはどこへ戻る／進むか？ を先に確認する。設定値だけでなく、入力と出力の境界を明確にする。
結論
- S3へファイルを置いてもSQLテーブルにはならない。Data Catalogのdatabaseとtableが、ファイルを読むためのメタデータになる。
- Crawlerは指定したS3パスを巡回し、形式・列・パーティションを推定してCatalogへ反映する。対象prefixを広げすぎない。
- Parquetは分析時の読み取り量を抑えやすい一方、変換時には整ったスキーマが必要。ログ形式の変更はCrawler結果も確認する。