AWS Athena を使い始める前の基礎理解

はじめに

Amazon Athena を利用する前に理解すべき基礎について、【AWS Black Belt Online Seminar】Amazon Athena - YouTube を参考にまとめました。

Amazon Athena とは

S3 上のデータに対して、標準SQL によるインタラクティブなクエリを投げてデータ分析をできるサービス。特徴については下記参照。

• サーバレスでインフラ管理必要無し
• 大規模データに対しても高速なクエリ
• 事前のデータロードなしに S3 に直接クエリ
• スキャンしたデータに対しての従量課金
• JDBC / ODBC / API 経由で BIツールやシステムと連携
  • ODBC : RDBMS にアクセスするための共通インタフェース
  • JDBC : Java と関係データベースの接続のためのAPI

ユースケース

• 新しく取得したデータに対して、データウェアハウスに入れる価値があるか探索的に検証
  • データウェアハウス(ex. Redshift)は管理コストがかかる
• 利用頻度の低い過去のデータに対する BI ツール経由のアドホックな分析
  • データウェアハウスだとストレージコストがかかるため
• Webサーバのログを S3 に保存しておくことで、障害発生時に SQL で原因追求できる
  • UNIX コマンドで調査が不要になる
• 程頻度実施のETLツール

Amazon Athena のアーキテクチャ

クエリエンジン

• Presto を利用
  • データをディスクに書き出さず、全てメモリ上で処理
  • ノード故障やメモリ溢れが起きたらクエリ自体が失敗する
  • バッチ処理ではなく、インタラクティブクエリ向け

参考：Prestoとは何か，Prestoで何ができるか

メタデータの管理

• AWS Glue
  • Data Catalog でメタデータを管理する
  • メタデータとは、DB / Table / View / Partition

Amazon Athena 基本

テーブル定義

• 標準のテーブル定義の後に、データ形式、圧縮形式、データの場所などを指定
• Glue で S3 データに対して Crawler を投げてテーブル登録することも可能
• スキーマオンリードなので、同一のデータに複数のスキーマを定義可能
  • スキーマとはデータベースの設計図のようなもの

参考：スキーマ (データベース) - wikipedia

利用できるデータ型

データ形式

データの圧縮形式

GZIP はあまり効率的ではない。

対応クエリ

• Presto と同様、標準 ANSI (米国規格協会) SQL に準拠したクエリ
  • WITH, Window関数, JOIN などに対応

SQLの標準規格は、ANSI（米国規格協会）やISO（国際標準化機構）といった標準化団体により、数年に一度改訂されます。

改訂ごとに決められた規格は、制定された年ごとに「SQL:1999」「SQL:2003：「SQL:2003」「SQL:2008」「SQL:2011」「SQL:2016」などと呼ばれます。こうした標準規格に準拠したSQLが標準SQLです

ただし、SQLの標準規格に「すべてのRDBMSは標準SQLを使わなければならない」という強制力はありません。標準SQLをサポートしたRDBMSは増えましたが、それでも標準SQLで書いたSQL文を実行できないことがあります。

参考：標準SQLとは - 標準SQL徹底入門

DDL / クエリの注意点

• DDL(Data Definition Language) とはデータ定義言語のこと
  • SQL でいうと CREATE、 DROP、ALTER、TRUNCATE
• DDLでは、EXTERNAL TABLE のみ利用可能
  • データは常に S3 にあり、Athena サービス外のため
• VIEW、CTAS にも対応
• 以下の処理には未対応
  • トランザクション処理
  • UDF / UDAF
  • ストアドプロシージャ

Athena API

• Athena はSQL クライアントからだけでなく、プログラムから API を呼び出すことができる
• API は大きく2種類
  • Query Execution API
  • クエリを実行することに関する API
  • Named Query API
  • クエリの保存機能に対する API

Amazon Athena の特性

• OLTP(Online Transactional Processiong) ではなく、OLAP(Online Analytical Processing)向け
  • そもそもトランザクションは未サポート
• ETL ではなく分析向け
  • データをフルスキャン&変換するのは高コストな設計
  • リトライ機構がないので、安定的なバッチ処理には向かない
• いかにして読み込むデータ量を減らすかが重要
  • パーティション
  • 列指向フォーマット
  • 圧縮

スキャン量の減らし方

Athena の特性において、コスト削減のためにはいかにしてS3から読み込むデータ量を減らすかが重要。減らし方については下記。

パーティション

• S3 のオブジェクトキーの構成を CREATE TABLE に反映

  • 例：S3://athena-examples/action-logs/year=2020/month=02/day=21/data_01.gz のように保存されている場合、下記のように DDL を発行し、クエリを実行すると WHERE 句で絞ったS3 パスのみ読み込まれるためスキャン量が減る。

CREATE EXTERNAL TABLE IF NOT EXISTS action_log (
  user_id string,
  action_category string,
  year int,
  month int,
  day int
)
PARTITIONED BY (year int, month int, day int)
STORED AS PARQUET
LOCATION 's3://athena-examples/action-log/’
TBLPROPERTIES ('PARQUET.COMPRESS'='SNAPPY');

WHERE句で 2016年の4月~7月のデータを指定

SELECT
  month
  , action_category
  , action_detail
  , COUNT(user_id)
FROM
  action_log
WHERE
  year = 2016
  AND month >= 4
  AND month < 7
GROUP BY
  month
  , action_category
  , action_detail

以下のS3パスのみ読み込まれるのでスキャン量を削減できる

パーティションの分け方

• s3://athena-examples/action-logs/year=2020/month=02/day=21/data_01.gz のように、col=val1/col2=val2 のような Hive 標準の方が推奨
  • MSCK REPAIR TABLE` は、パーティションを Athena で認識されるためのコマンド
• s3://athena-examples/action-logs/2020/02/21/data_01.gz のように val1/val2 のような形式もありだが少し面倒