1.
Presto ベースのマネージドクエリサービス
Amazon Athena
アマゾンウェブサービスジャパン株式会社
ソリューションアーキテクト, 志村 誠
2017.06/15
© 2017, Amazon Web Services, Inc. or its affiliates. All rights reserved.

2.
自己紹介
2
所属:
アマゾンウェブサービスジャパン株式会社
業務:
ソリューションアーキテクト
(データサイエンス領域)
経歴:
Hadoopログ解析基盤の開発
データ分析
データマネジメントや組織のデータ活用
志村 誠 (Makoto Shimura)

3.
Agenda
• Amazon Athena 概要
• クイックスタート
• GA 以降のアップデート
• Athena を包む AWS のデータ分析サービス
• Athena のベストプラクティス
3

4.
Amazon Athena の概要
4

5.
Amazon Athena とは
S3上のデータに対して，標準 SQL による
インタラクティブなクエリを投げて
データの分析を行うことができるサービス
5

6.
Amazon Athena とは
• re:Invent 2016 のキーノートにて発表された新サービス
• バージニア北部，オレゴン，オハイオの3リージョンで提供
• クエリエンジン Presto と，Hive メタストア互換のデータカタログを使用
6 https://aws.amazon.com/jp/blogs/news/amazon-athena-interactive-sql-queries-for-data-in-amazon-s3/

7.
データ分析基盤の進化の流れ
Data warehouse
appliances
1985 2006
Hadoop
clusters
2009
Decoupled EMR
clusters
2012
Cloud DWH
Redshift
Today
Clusterless
Athena Glue

8.
Athena の特徴
8
サーバレスでインフラ管理の必要なし
大規模データに対しても高速なクエリ
事前のデータロードなしにS3に直接クエリ
スキャンしたデータに対しての従量課金
JDBC / API / CLI からクエリ可能

9.
Athena の想定ユースケース
9
ユースケース データ ユーザ
新しく取得した非構造化データに対して，
DWに入れる価値があるか探索的に検証
新しく取得したデータ アナリスト
利用頻度の低い過去のデータに対する，
BIツール経由のアドホックな分析
コールドデータ アナリスト
Webサーバで障害が発生したときに，
ログを漁って原因追求
アクセスログ サーバ運用
大規模でないデータに対しての，
低頻度で実施するETL処理
生データ 開発者

10.
Athena のアーキテクチャ
• 2 つのコンポーネント
– Presto ベースのクエリエンジン
– Hive メタストアベースのデータカタログ
10 https://prestodb.io/overview.html参考: Presto のアーキテクチャ

11.
Athena のアーキテクチャ
• Presto on EMR で Hive connector を使って S3 デー
タを読み込むのと，基本的には同様
• 細かな点で仕様に違いがあるので注意
– データ型 REAL→FLOAT, TIME 型は Athena にはない
• パフォーマンスに関しては，以下の3点が基本
– 適切にパーティション分けした形でテーブルを作る
– 列指向フォーマットを使う
– データは圧縮する
11

12.
リソースに関する制約
• 1アカウントあたりの最大クエリ同時実行数は5個
• クエリは30分でタイムアウト
• 1アカウントあたりの最大データベース数は100個
• 1データベースあたりの最大テーブル数は100個
• 1テーブルあたりの最大パーティション数は20000個
12
Athena のリソースには現状，以下のような制約がある*
* 上限緩和申請によって増やすことが可能
http://docs.aws.amazon.com/athena/latest/ug/service-limits.html

13.
I/Oに関する制約
13
入力に関する制約
• どのリージョンの S3 からでもデータの読み込みは可能
• ただしリージョンをまたぐ場合，データ転送時間と，転送料金がかかる
• 暗号化データ読み込みは SSE-S3, SSE-KMS, CSE-KMS に対応
出力に関する制約
• Athena 実行リージョンの S3 にヘッダ付き csv で出力のみ
• 結果ファイルは SSE-S3, SSE-KMS, CSE-KMS の3方式で暗号化して出力可能
• SELECT INSERT には未対応

14.
料金体系
• クエリ単位の従量課金
• S3 のデータスキャンに対して，$5 / 1TB の料金
• バイト数はメガバイト単位で切り上げられ，10MB 未満のク
エリは 10MB と計算される
• スキャンデータ量は，圧縮状態のデータサイズで計算される
• 別リージョンからデータを読み込む場合には，別途S3
のデータ転送料金がかかる
• DDL のクエリや，実行に失敗したクエリの料金は無料
• パーティション，列指向フォーマット，圧縮を活用する
ことで，スキャンするデータ量を減らして，コスト削減
が可能

15.
クイックスタート
15

16.
Demo

17.
GA 後のアップデート
17

18.
2017/2/16 に以下の新機能＆性能改善をリリース
18
• 新たな SerDe のサポート（Avro, OpenCSVSerDe）
• オハイオリージョン（us-east-2）のローンチ
• テーブル追加ウィザードで，カラム名/型をまとめて入力可能に
新機能
性能改善
• 大規模な Parquet テーブルのクエリ速度を改善
http://docs.aws.amazon.com/athena/latest/ug/release-note-2017-02-20.html

19.
OpenCSVSerDe
• 囲み文字を quoteChar で指定できる
• OpenCSVSerDe 自体の制約として，以下の2点に注意
– カラム型として string しか選択できない
– 文字列内の改行文字はサポートされていない
19
CREATE EXTERNAL TABLE myopencsvtable (
col1 string,
col2 string,
col3 string,
col4 string,
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde’
WITH SERDEPROPERTIES (
'separatorChar' = ',',
'quoteChar' = '"',
'escapeChar' = '’
)
STORED AS TEXTFILE
LOCATION 's3://location/of/csv/';
"a1", "a2", "a3", "a4”
,"1" ,"2" "abc", "def”
"a", "a1", "abc3", "ab4"

20.
2017/3/24 に以下の新機能＆性能改善をリリース
20
• 新たな SerDe のサポート（CloudTrailSerDe*）
新機能
性能改善
• パーティション数が非常に多い場合のスキャン速度を改善
• MSCK REPAIR TABLE の速度を改善
• オハイオリージョンでも他リージョンの S3 からのデータ読み込み
が可能に
http://docs.aws.amazon.com/athena/latest/ug/release-note-2017-03-24.html
* https://aws.amazon.com/blogs/big-data/aws-cloudtrail-and-amazon-athena-dive-deep-to-analyze-security-compliance-and-operational-activity /

21.
2017/4/6 に以下の新機能をリリース
21
• 入出力データの暗号化に対応
• 新バージョンの JDBC ドライバ (AthenaJDBC41-1.0.1.jar) リリース
• ALTER TABLE で カラムの追加，置き換え，変更処理が可能に
• LZO 圧縮形式に対応
新機能
http://docs.aws.amazon.com/athena/latest/ug/release-note-2017-04-04.html
* https://aws.amazon.com/blogs/big-data/aws-cloudtrail-and-amazon-athena-dive-deep-to-analyze-security-compliance-and-operational-activity /

22.
入出力データの暗号化に対応
• 暗号化方式として， SSE-S3, SSE-KMS, CSE-KMS に対応
• 暗号化データへのクエリ，とクエリ結果の暗号化保存，は個別に設
定する必要がある
– そのため，両者で暗号化方式が違っていてもOK
• マネジメントコンソール，JDBCの両方に対応
22
入出力 手段 ユーザ
入力
コンソール
JDBC
CREATE TABLE の tablproperties で指定
出力 コンソール 画面右上の Settings から暗号化方式を指定
JDBC JDBC ドライバのオプションで指定

23.
2017/5/19 に以下の新機能をリリース
23
• Athena のクエリ関連処理が API に対応
• AWS SDK や AWS CLI も API に対応した形でアップデート
• 新バージョンの JDBC ドライバ (AthenaJDBC41-1.1.0.jar) リリー
ス
新機能
http://docs.aws.amazon.com/athena/latest/ug/release-note-2017-05-18.html#may-19-2017
性能改善
• クエリストリングの上限が 256KB に増加

24.
以下の API に対応
24
カテゴリ API
クエリ実行
• StartQueryExecution
• StopQueryExecution
• GetQueryExecution
• GetQueryResults
• BatchGetQueryExecution
• ListQueryExecutions
ネームドクエリ
(よく使われるクエリを保存)
• CreateNamedQuery
• DeleteNamedQuery
• GetNamedQuery
• BatchGetNamedQuery
• ListNamedQueries

25.
2017/6/5 にサードパーティー製品の対応
• Tableau 10.3 がリリースされ，Amazon Athena コネクタ
がサポート
25 https://www.tableau.com/ja-jp/new-features/10.3

26.
Athena を包む AWS のデータ分析サービス
26

27.
Amazon S3
Data Lake
Batch Analytics
Amazon Kinesis
Streams & Firehose
Hadoop / Spark
Amazon Redshift
Data Warehouse
Amazon DynamoDB & ElastiCache
NoSQL DB & Redis
Relational Database
Amazon EMR
Amazon Aurora
Amazon Machine Learning
Machine Learning
Any Open Source Tool
of Choice on EC2
DataSources
Amazon S3を中心としたデータレイク
Clusterless SQL Query
Amazon Athena
TransactionalData

28.
Amazon S3
Data Lake
Batch Analytics
Amazon Kinesis
Streams & Firehose
Hadoop / Spark
Amazon Redshift
Data Warehouse
Amazon DynamoDB & ElastiCache
NoSQL DB & Redis
Relational Database
Amazon EMR
Amazon Aurora
Amazon Machine Learning
Machine Learning
Any Open Source Tool
of Choice on EC2
DataSources
Amazon S3を中心としたデータレイク
Clusterless SQL Query
Amazon Athena
TransactionalData
すべてのデータを1ヶ所に集めて保存
データストアとデータ処理の分離
用途に応じた適切な処理方法の選択

29.
AWS の分析サービス
29
Amazon EMR, AWS Glue*ETL
Amazon Redshiftデータウェアハウス
アドホッククエリ
Amazon QuickSightBI / 可視化
Amazon EMR, Amazon EC2, AWS Batch機械学習
* Glue は 2017/6/15 時点ではプレビュー中で，正式リリースされてはいません

30.
AWS の分析サービス
30
Amazon EMR, AWS Glue*ETL
Amazon Redshiftデータウェアハウス
Amazon Athenaアドホッククエリ
Amazon QuickSightBI / 可視化
Amazon EMR, Amazon EC2, AWS Batch機械学習
* Glue は 2017/6/15 時点ではプレビュー中で，正式リリースされてはいません

31.
再掲: Athena の想定ユースケース
31
ユースケース データ ユーザ
新しく取得したデータに対して，
DWに入れる価値があるか探索的に検証
新しく取得したデータ アナリスト
利用頻度の低い過去のデータに対する，
BIツール経由のアドホックな分析
コールドデータ アナリスト
Webサーバで障害が発生したときに，
ログを漁って原因追求
アクセスログ サーバ運用
大規模でないデータに対しての，
低頻度で実施するETL処理
生データ 開発者

32.
Athena が向いていない処理
• リトライ機構がなく，データを絞って高速にスキャンするア
ーキテクチャのため，バッチ処理にはあまり向かない
• 分析処理でも，大量データを長時間処理するのには向かない
32
ユースケース 適したサービス
大規模なデータに対して，フルスキャンを定期的に行う処理 EMR
テンポラリテーブルを活用した多段のETL処理 EMR, Glue
サブクエリやJOINを駆使した複雑な集計処理 Redshift
高頻度なレポーティングのための大量の分析処理 Redshift

33.
Amazon Athena では対応できないこと
• ピークタイミングのノード数追加
• Presto のパラメタ設定
• 実行する Presto のバージョンを正確に指定
• 利用料金の固定
33
Athena はサーバーレスのクエリサービスであり
利用者側で制御できない部分が存在する

34.
Presto on EMR という選択肢
• EMR クラスタを立てて，その上で Presto を動かす
• クラスタの構築・運用コストを下げながら，詳細な
チューニングを行うことが可能
• インスタンスフリートやスポットブロック* を活用
することで，利用時のコストを削減することも可能
34
+
https://aws.amazon.com/jp/blogs/news/new-amazon-emr-instance-fleets/

35.
Redshift + Spectrum という選択肢
• ホットデータに対する高頻
度の重たいワークロードが
主体の場合には，Redshift
を使う方が適切
• その上で Spectrum を使っ
て，大量のコールドデータ
に対するアクセシビリティ
を確保
• Spectrum は，Redshift か
ら S3 上のデータを直接読
みこむ機能を持つ
35
Amazon
Redshift
JDBC/ODBC
...
1 2 3 4 N
Amazon S3
Exabyte-scale object storage
Spectrum
Layer

36.
事例
36

37.
NASDAQ におけるデータ分析環境
• ホットデータを Redshift で，コールドデータを Presto on EMR で
• Redshift は 100 以上のテーブルから 60-200億行/日を取り込み
• Presto on EMR は S3 上の 500TB のデータが対象で，1.5PB の過
去データをマイグレーションしている
37
https://www.slideshare.net/AmazonWebServices/aws-reinvent-2016-securing-enterprise-big-data-workloads-on-aws-sec308
https://www.slideshare.net/AmazonWebServices/bdt314-a-big-data-analytics-app-on-amazon-emr-amazon-redshift

38.
DataXu におけるデータパイプライン
38
Athena
CDN
Real Time Bidding
Reporting Platform
Kinesis ETL
(Spark SQL)
S3
Data Visualization
Reporting
マーケティングプラットフォームを提供する会社
180TB / 日のデータを Athena で分析
http://www.slideshare.net/AmazonWebServices/announcing-amazon-athena-instantly-analyze-your-data-in-s3-using-sql

39.
Japan Taxi におけるログ集計基盤
• S3 に集約したログに対して集計クエリを実行
• digdag / embulk 等と組み合わせてデータを加工整形
• 予約注文数や注文ピークタイムなどを re:dash で可視化
39

40.
まとめ
40

41.
まとめ
• Athena は S3 上のデータに対する，Presto ベ
ースのインタラクティブなクエリサービス
• 昨年末のリリース以降，さまざまな機能追加や
性能改善を行なっている
• Athena だけですべてをまかなうのではなく，
適材適所で他の分析サービスと使い分ける
41

42.
42