Athenaではパーティション分割は必須中の必須
AWS AthenaはS3に突っ込んだファイルに対してSQLを投げて直接分析ができるという点でとても魅力的なサービスです。
が、クエリの際にスキャンするデータサイズにしたがって課金が発生するため、うっかりしているととんでもない費用請求になったりします。
そのための手段としてはとにかくきちんとパーティションを設計・設定して、不要なところまでスキャンさせないということをしないといけません。
Athena パーティション設定
パーティションの設定には、
1. S3のフォルダをパーティションに対応する構造に作っておく
s3://バケットの場所/year=2019/month=3/day=1 s3://バケットの場所/year=2019/month=3/day=2 s3://バケットの場所/year=2019/month=3/day=3 （略）
2. Athena側でCreate Tableする際にパーティション設定をしておく
CREATE EXTERNAL TABLE IF NOT EXISTS athena_table_name ( ... ... ) PARTITIONED BY ( year int, month int, day int ) （以下略）
3. フォルダが増えていったら、都度Alter Tableしてパーティションを追加
ALTER TABLE athena_table_name ADD PARTITION ( year='2019',month='3',day='20' ) location 's3://バケットの場所/year=2019/month=3/day=20'
というお作法を踏んでいけばOKです。
あとはパーティションを意識して必要な範囲に絞ったクエリを投げる。
それでもビッグデータ破産の恐怖はなくならない
ところが、この地道な作業（当然パーティションを追加していくところは自動化するとして）をしてパーティションをきっちり構成したとしても、やはり「人間が叩くアドホックなクエリ」という敵がいます。
「Where句面倒だしとりあえず全部まとめて引っ張ってこよう」という方も中にはいらっしゃるかもしれない。
データ量によってはAthenaだけで数十万円とか数百万円とかいってもおかしくないわけで、予算表の圧を受けながら仕事をしている身としてはやはりびびります。
（Athena環境作ったはずなのに、この恐怖に耐えかねて結局Athenaを破棄して普通のRDSにデータを流すことにしたという苦い過去があります。）
Athena Workgroup, データ利用制御機能リリース
しかしとうとう、AWSの中の人から朗報が届きました。
Athenaでクエリスキャンの上限が設定できるようになったとのこと。ヤッターー！
あらたにWorkgroupという概念が導入され、このWorkgroupの単位でスキャン上限だけでなく、接続ユーザ・アプリケーションやワークロードなどの管理もできるようになったようです。
これは本当にいいアップデートですね…。もっと早く出してくれればさらに嬉しかったです…。
クエリスキャン上限設定の手順
Athenaに入ると画面上部（Glueリンクのお隣）に新しく「Workgroup: primary」というリンクができています（primaryというのはデフォルトのWorkgroup名）。
このリンクから入った画面でひとつWorkgroupを選択し、「View Details」ボタン押下した先の画面にある「Data Usage Control」タブがお目当ての場所です。
10MB以上にはなりますが、ここから1クエリあたりのスキャンサイズ上限を設定することができます（設定値を超えた場合はクエリキャンセルとなります）。
これで一安心
これでAthenaを使う安心度がぐっと上がりました。
Athenaを使ってデータレイク構想を進めようとしていた皆さん、サーバレスで簡単に分析環境つくりたい皆さん、これで相当やりやすくなったんじゃないでしょうか。
