AWS Athena
- Athenaとは何かを知る
- Athenaをどう使えばいいかを知る
- Athenaの制限を知る
- Athenaのベストプラクティスを知る
Athenaとは何かを知る
概要
Amazon Athena はインタラクティブなクエリサービスで、
Amazon S3 内のデータを標準 SQL を使用して簡単に分析できます。
Athena はサーバーレスなので、インフラストラクチャの管理は不要です。
実行したクエリに対してのみ料金が発生します。
- サーバーレス
- 自動拡張
- 運用不要
- S3の全てのデータを使用可能
- データ容量上限なし
- S3にデータを配置してそのデータに対して標準SQLを用いて分析できるサービス
-
Presto
ベース
-
- S3にあるデータを指定してスキーマの定義をしてSQLを実行
- 大規模データの多くのケースで数秒で結果が返ってくる
- 分析用データを準備するための複雑なETLは不要
- クエリが並列実行される
- データ形式には様々な形式に対応
- CSV, JSON, ORC, Avro, Parquet etc
- ODBCやJDBCでの接続が可能
- AWS Glueと統合されている
料金
- スキャンしたデータに対してのみ支払い
- 1TBに対して5USD
- 仮に 100GB をスキャンした場合 :
0.49 USD
=>54円
- 仮に 100GB をスキャンした場合 :
- スキャンするデータ量を減らすことでコストを削減できる
導入事例
Athenaをどう使えばいいかを知る
ユースケース
- 常時必要でではないスポット的な分析が必要なケース
- 大容量データを数秒で分析できるソリューションが必要なケース
実行まで
- S3バケットへデータを登録する
- データーベースの作成をおこなう
- テーブルの作成を行う
- クエリを発行する
- 結果取得する
アクセス
- AWSコンソール
- API
- AWS SDK
- CLI
ソースデータの使用 (S3)
- S3に保存されているデータをリアルタイムでクエリ
- パフォーマンス向上とコスト削減
- 列指向形式の使用 :
Parquet
- 列指向形式の使用 :
テーブルとS3
- バージョニングされている場合は「最新」のデータのみをクエリ
- S3に対するアクセス許可が必要
- ロールやポリシー
- バケットのアクセス許可
- S3で暗号化するデータはAthenaと同一リージョンに保存する必要がある
-
Location句
で指定した同じバケットで複数のストレージクラスに保存されたオブジェクトでデータをクエリできる - リクエスタ支払いバケットはサポート対象外
- GLACIERも対象外
- ライフサイクルポリシーでGLRACIERに移行されたオブジェクトも対象外
- テーブル削除するとメタデータのみが削除されデータはS3に残る
データのパーティション分割
- データをパーティション分割することでクエリのスキャンデータ量を制限できる
- パフォーマンス向上とコスト削減を達成できる
- パーティションには
Hive
を使用 - 全てのキーでデータをパーティションできる
- 一般的には時間に基づいてパーティション分割
- 年 / 月 / 日
-
CREATE TABLE
でPRTITIONED BY
を指定する
データがパーティション済みでS3に Hive
方式で保存されている場合
-
S3::bucket/year=2019/month=01/day=01
のようなHive方式のディレクトリ構成でS3に保存済み -
CREATE TABLE
でPARTITIONED BY (year string, month string, day string)
を指定 - テーブル作成後
MSCK REPAIR TABLE [table]
を実行しパーティショニング
列指向ストレージ方式
-
Apache Parquet
やORC
はデータを高速に取得できるようにした列指向ストレージ形式
特徴
- 列ごとの圧縮によりS3ストレージ領域を節約してクエリ処理時の I/O や容量を軽減できる
- Parquet および ORC での
述語プッシュダウン
により、Athena クエリで必要なブロックだけを取得できる - Parquet および ORC でのデータの分割により、Athena がデータの読み取りを複数のリーダーに分割して、クエリ処理時の並列処理を向上させることができる
データ変換
-
CTAS
で変換を行う -
EMR
で変換処理を行う
既存の raw データを他のストレージ形式から Parquet または ORC に変換するには、
Athena で CREATE TABLE AS SELECT (CTAS) クエリを実行し、
データストレージ形式として Parquet または ORC を指定するか、
または AWS Glue クローラを使用します。
テーブルデータのクエリ
クエリ結果
- Athenaはクエリ結果をS3へ保存
- クエリ実行毎に以下ファイルを生成
- CSV形式での結果ファイル :
*.csv
- Athenaメタデータファイル :
*.csv.metadata
- このファイルを削除するAthenaにとって重要な情報が失われる
- CSV形式での結果ファイル :
結果保存先指定
- 個々のクエリ
- 個々のクエリ実行時に
OutputLocation API
を使用して指定
- 個々のクエリ実行時に
- ワークグループ内の全てのクエリ
- ワークグループの全てのクエリの保存先を指定する
- コンソールでのクエリ
- デフォルトで自動でバケットが作成され保存される
- Athenaは結果保存先を指定しないとエラーになる
クエリ履歴
- 最大45日保存されている
- コンソールやAPIで履歴一覧や結果取得が可能
- 45日以上保存したい場合は自前でデータストアへ保存する処理が必要
View
- 論理的なテーブル
- ビューを定義するクエリは1つのクエリでビューを参照されるたびに実行される
ユースケース
- データのサブネットをクエリする
- 複数のテーブルを1つのクエリに統合する
- 既存の基本クエリの複雑さを解消する
むずかし〜いクエリの結果をViewさせることでデータを使う人は簡単になる
CTAS
-
CREATE TABLE AS SELECT (CTAS)
クエリは新しいテーブルを別のクエリのSELECT結果から作成する - S3の指定された場所にCTASによってい作成されたデータファイルを配置する
ユースケース
- raw データセットのクエリを繰り返さずに1 回のステップでクエリの結果からテーブルを作成する
- クエリ結果を他のストレージ形式
Parquet, OCR etc
に変換する - 必要なデータのみが含まれている既存のテーブルのコピーを作成できる
考慮と制約
- CTASはS3にクエリ結果をS3にデータファイルとして書き込むがビューではデータを書き込まない
- CTASの結果を保存する先のS3は空である必要がある
- CTASはバケット先がからであるかを確認する
- データが既に存在する場合は上書きをしない
- 保存先を指定しない場合は自動でバケットを作成する
- クエリ結果の保存形式はデフォルトで
Parquet
- 他には
PARQUET, ORC, AVRO, JSON, TEXTFILE
が指定可能
- 他には
- クエリ結果はデフォルトで
GZIP
で圧縮される- Parquet および ORC では、
SNAPPY
を指定することもできる
- Parquet および ORC では、
- 1 つまたは複数の列により、CTAS クエリの結果データをパーティション化することができる
- 最大 100 個のパーティションを作成できる
- CTAS クエリの結果とバケットデータを 1 つまたは複数の列に保存するようにバケットを設定することができまる
- クエリ結果の暗号化が可能
- データ型は元のまま
バケット化とパーティショニング
- CTASクエリ結果で設定できるパーティションの数は
100個
まで - S3に保存しているデータ側がパーティションされているとCTASの性能が向上する
- CTASクエリのバケット化はカーディナリティが高く値が均等に分散されている列によってデータをバケット化するときに上手くいく
- 大量のデータをスキャンしないようなバケット化およびパーティショニングが必要
クエリ例
バケット化とパーティショニングがある
CREATE TABLE ctas_parquet_bucketed
WITH (
format = 'Parquet',
parquet_compression = 'SNAPPY',
external_location = 's3://my_athena_results/',
partitioned_by = ARRAY['nationkey'],
bucketed_by = ARRAY['mktsegment'],
bucket_count = 3)
AS SELECT key1, name1, address1, phone1, acctbal, mktsegment, comment1, nationkey
FROM table1;
配列
- Athena では、配列の作成、連結、異なるデータ型への変換ができます。さらに、フィルタ処理、フラット化、ソートができる
スキーマの更新
- Athenaはスキーマの読み取りクエリエンジン
- Athenaでデータを作成するときにデータの読み取りにスキーマを適用する
- データ形式によりスキーマの更新で出来ること出来ないことが存在する
ワークグループ
- ワークグループを使用してユーザ・チームなどにワークロードを分離することができる
- クエリまたはワークグループ全体で処理できるデータ量に制限を設けコストを追跡できる
- アクセス制御もできる
- CloudWatchでのメトリクスも
クエリログ
- CloudTrailで実行のログを追跡可能
圧縮形式
- Athenaは複数のデータ圧縮形式をサポート
- SNAPPY
-
Parquet
のデフォルト圧縮形式
-
- ZLIB
-
ORC
のデフォルト圧縮形式
-
- LZO
- GZIP
CSV, TSV, JSON
- これらのデータ形式はAthenaがファイル拡張子から圧縮タイプを判断する
- データが圧縮されている場合はファイル名に圧縮拡張子(gzなど)が含まれていることを確認する
Kinesis Data Firehose
- AthenaはFirehoseログに対するクエリではGZIP圧縮を使用する
- Kinesis Data FirehoseとAthenaではサポートされているSNAPPYのバージョンが異なるため互換性のある形式はGZIPのみ
DDL / SQL
- Athena はDDLとANSI SQL関数および演算子をサポートする
Athenaの制限を知る
DDL
20回 / 秒
SQLクエリ
- タイムアウト :
30分
- クエリ文字列長 :
256KB (262144Byte)
-
UTF-8
でエンコードされる
-
- クエリ発行/停止 :
20回 / 秒
StartQueryExecution
StopQueryExecution
- クエリ実行確認 :
100回 / 秒
GetQueryExecution
- クエリ結果取得 :
100回 / 秒
GetQueryResults
ワークグループ
- 最大数 :
1000個 / リージョン
Athenaのベストプラクティスを知る
データをパーティションに分ける
CTASについてもっと詳しく知る
-
クエリした結果が保存されそのデータに対するテーブルが作成される
-
元となるクエリを作成する
-
そのクエリに対するCTASを作成する
トラブルシューティング
-
external_location
で指定するパスにはフォルダまで指定する必要がある- ex)
external_location='s3://output-ctas/tables/'
- ex)
バケッティングについてもっと知る
-
バケッティングは指定したカラムでデータを集約してデータファイルを作成すること
-
したばってカーディナリティが高いカラムを指定することでよりインデックス化された状態を作ることができてスキャンするデータ量を減らすことができる
-
CREATE TABLE
で作成するときにバケッティングされたファイル数を指定する必要がある- 同一ファイル数で作成されていたらいいけど、、、
トラブルシューティング
コンソール
- コンソールでテーブル作成やCTASで新規作成バケット指定してるのに「バケットが無い」とか「指定バケットすでに存在する」とかエラー出た時は、右上
Setting
からデフォルトバケットを変更すると上手くいくかも