はじめに

こんにちは。たのしいAthenaライフ、送ってますか？
CloudTrailの証跡ログをAthenaからSQLで分析する用事があったのですが、その際にタイトルの件でプチハマりしたので記録に残しておきます。

先に結論

先に結論を書いておきます。

CloudTrailログ検索用のGlueテーブルでパーティション構成を有効化している場合、パーティションの管理は考慮が必要です。
- MSCK REPAIR TABLEによるパーティションの自動検出・修復は利用できません。
- テーブルに対するパーティションの追加はALTER TABLE ADD PARTITIONで行う必要があります。
MSCK REPAIR TABLEでパーティションの更新ができるのはHive形式で保存されている場合のみです。
Hive形式のパーティションとは、S3上でのパス(相当の部分)がField1=Value1/の形式で保存されている状態を指します。

きっかけ

そもそものきっかけは、S3に出力されたCloudTrailの証跡ログから必要なものを抽出して定期的に出力する用事があったためでした。
CloudTrailは、証跡ログをS3バケットに出力することができ、その際のディレクトリ(正確にはキーの一部ではありますが便宜上本稿ではそう呼んでおきます)構成は下記のようになっています。プレフィックスの説明については公式ドキュメントが詳しいのでそちらに譲っておきます。

PATH/TO/PREFIX/AWSLogs/ACCOUNTNUMBER/CloudTrail/REGION/YYYY/MM/DD/

この時はまだ、「パーティションが増えてもMSCK REPAIR TABLEすればお手軽にできそう」と考えていました…。

パーティション更新でハマる

CloudTrailの証跡ログをAthenaからSQLで検索できるようにするには、下準備として、証跡ログをデータソースとするGlueテーブルを作成する必要があります。Athenaはデータのスキャン量に比例した課金体系のため、スキャン量を少なくするには、パーティション化によるスキャン範囲の絞り込みが有効です。パーティションを有効にしたGlueテーブルの作成手順を参考にテーブルを作成します。コンソールのイベント履歴から作成する手順ではパーティション構成が含まれないテーブルになるため気を付けましょう。

下ごしらえができたところで、MSCK REPAIR TABLEによりパーティションを更新します。
します。
します…。

あれ？何も出ないぞ？ファイルも確かに配置したのに…。

実際、SHOW PARTITIONSで見てみてもパーティションは増えていません。

原因

MSCK REPAIR TABLEを実行してもパーティションが増えなかった原因はちゃんとドキュメントに書いてありました…。

Hive と互換性のないパーティションの場合、ALTER TABLE ADD PARTITION を使用してパーティションをロードすることで、データをクエリできるようにします。

ここまで来てはじめて、改めて「Hive形式」について調べてみました。つまるところ、Hive形式とは、パーティションに該当する部分のS3キーがField1=Value1/のフォーマットになっている保存形態を指すとのことです（ドキュメント）。CloudTrailが出力する証跡ログはHive形式じゃなかったんですね…。

対応

原因がわかったので対処もできるようになりました。ALTER TABLE ADD PARTITIONSでコツコツパーティションを追加していくだけですね。PARTITIONS (partition-set)の部分は繰り返し記述することができるので、複数のパーティションがある場合もまとめて追加できます。
パーティションが正しく登録されていれば、SHOW PARTITIONSからも確認できるようになります。