Amazon Athena
# Amazon Athena
https://d1.awsstatic.com/webinars/jp/pdf/services/20200617_BlackBelt_Amazon_Athena.pdf
## Athena とは
Amazon S3 にあるデータ（または様々なデータソース）に対してSQLを使用して簡単に分析可能とするインタラクティブなクエリサービス
- 特徴
- ユースケース
- シンプルにS3に対してクエリを発行して分析
- ログ分析
- S3に出力される様々なAWSサービスのログや収集データに対してクエリ
- ETL (Extract/Transform/Load)パイプラインをAthena で構築
## Athena の使い方
- データをS3に保存する
- Database Migration Service
- Kinesis Data Firehose
- Kinesis Data Streams
- S3
- Storage Gateway
- Snowball / Snowball Edge / Snowmobile
- DataSync
- AWS Transfer Family
- テーブルを定義する
- Athena ではクエリのためにテーブル定義が必要
- デフォルトでAWS Glue Data Catalog 状のテーブル定義を使用
- HiveQL形式でDDLを記述
- データソース
- データを記述するデータカタログとデータを合わせてデータソースと呼ぶ
- デフォルトのデータソースはAWS Glue Data Catalog
- すでに既存の仕組みがあり、Hive Metastore を持っている場合にはこれに対してAthena を接続できる
- クエリを実行する
## Athena の様々なクエリ
- CTAS(Create Table As Select)
- クエリ結果をもとに新しいテーブルを作成
- ETL処理をAthena で実行可能
- データを圧縮フォーマットに変換
- データを複雑に加工整形するための多段クエリ
- パーティショニングとバケッティング
- INSERT INTO
- クエリ結果をもとに、既存のテーブルにデータを追加
- 実行のたびに新しいファイルが生成されるため、少量データでの実行を繰り返すことで、大量の小さなファイルが生成されクエリパフォーマンスに影響
- パーティション追加
- VIEW
- クエリ自体を仮想的なテーブルとして登録
- 活用シーン
- データのサブセットをクエリする
- 複数のテーブルを１つのクエリに結合する
- 既存の基本クエリの複雑性を解消して、ユーザーによるクエリの実行を単純化する
- クエリ問い合わせのインターフェースとして利用し、クエリ仕様変更に対する影響を最小限にする
- 地理空間データ分析
- 変数（SELECT $path, WHERE $path)
- LIKE 句やWhere 句で利用
- Amazon Athena Federated Query
- 様々なデータソースに対してSQLクエリを実行可能
- AWS Lambda で動作するコネクタを利用して実行
- 標準コネクタ
- Amazon DynamoDB
- Amazon Redshift
- Apache HBase
- MySQL
- PostgreSQL
- Athena Query Federation SDK を利用して、独自コネクタを実装可能
- User Defined Function(UDF)
- ユーザ独自のスカラー関数をUDFとして定義してSQLクエリで呼び出すことが可能
- データの圧縮・解答、機密データの編集、カスタマイズされた復号の適用など独自の処理を実行可能
- Java で実装し、Lambda関数としてAthena から呼び出される
- Machine Learning(ML) with Amazon Athena
- Athena SQL クエリでSageMake MLモデルを呼び出し、推論を実行可能
## パフォマンスチューニング
### データ最適化
- 列指向フォーマットにする
- Online Analytical Processing 向き
- 特定の列をまとめて保持
- 特定の列だけを扱う処理では、ファイル全体を読む必要がない
- メリット
- OLAP 系の分析クエリを効率的に実行できる
- 単純な統計データならメタデータで完結する
- IOの効率が上がる
- データ圧縮
- 最低限分割可能な圧縮形式を利用しておくことで分散処理をすることが可能
### データレイアウトの最適化
- パーティションを利用する
- S3 オブジェクトのキーを構成をCREATE TABLE に反映
- Where句で絞った時に LOCATION でS3のパスを指定し該当ディレクトリだけを読み込む
- Partition Projection
- 概要
- 非常に多くのパーレィションがあるテーブルにたいするクエリ処理を高速化し、パーティション管理を自動化することが可能
- パーティションプルーニングでメタデータを利用して、クエリに適用されるパーティションにだけ処理を実行することで高速化を図れる。
- しかし、テーブルに非常に多くのパーティションがある場合AWS Glue Data Catalog に対するパーティション取得APIの呼び出しがクエリパフォーマンスに影響する可能性が生じる
- Partition Projection を利用するとパーティション情報をAthenaが計算できるようになるため(AWS Glue Data Catalog を経由しないため）クエリ高速化の恩恵を享受できる
- ユースケース
### クエリの最適化
- LIMIT を利用してORDER BY を最適化
- JOINの順番を工夫する
- GROUP BYの工夫
- LIKE演算子を利用する際にはregex に置き換えて実行する
- （多少の誤差を許容できる場合）近似関数を利用する
- 必要なカラムだけを読み込む
## Athena の運用管理
- Workgroups を利用した利用量・コストの管理
- EventBridge を利用したクエリ監視
- CloudWatch メトリクスの利用
- CloudTrail を利用した利用状況のロギング
## Athena のセキュリティ
- 保管時の暗号化
- 転送時の暗号化
- AWS Lake Formation によるFine Grained Access Control
- シンプルな権限のGrant / Revoke
- データカタログのデータベース・テーブル・列に対して権限を指定可能
- 全てのデータアクセスを一箇所で監査
- AWS Glue Data Catalog のリソースベースポリシー
- IAM との連携
- AWS Glue Data Catalog
- S3
- VPC エンドポイント
## 雑感
Athena と Redshift はSQLを発行できる、列指向（がメイン）として利用されるので競合に当たるものだと思う。Athena はフルマネージド、Redshift はマネージドだがクラスタを用意しないといけない点で異なる。イメージとしてはアドホックに利用したい場合や既存のあるデータが対応している場合に利用してみるかという感じ、Redshift はそもそもデータから何かを生み出すように設計して運用される場合に利用されるイメージ。
