2017/9-5-7 に開催された db tech showcase の発表スライドです． http://www.db-tech-showcase.com/dbts/tokyo

1. Amazon Athena で実現する
データ分析の広がり
Makoto Shimura, Data Science Solution Architect
Amazon Web Services K.K.
2017.09.06
© 2017, Amazon Web Services, Inc. or its affiliates. All rights reserved.

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

3. Agenda
• Amazon Athena 概要
• クイックスタート
• Amazon Athena の構成
• Update
• パフォーマンスガイド & Tips
• Athena & Glue によるデータ分析の広がり

4. Amazon Athena の概要
4

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

6. Amazon Athena とは
• re:Invent 2016 のキーノートにて発表された新サービス
• バージニア北部，オレゴン，オハイオ，アイルランド，シンガポール，東京の
計 6 リージョンで展開
• クエリエンジン 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経由でBIツールから直接クエリ

9. マネジメントコンソールから簡単にアクセス
• 利用開始から数分でクエリを投げられる
• クエリごとのスキャンデータ量を確認可能
• Glue データカタログでテーブルスキーマやパーティションを確認

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

11. Amazon Athena の構成
11

12. Presto : 高速な分散クエリエンジン
• Athenaで使用しているクエリエンジン
• データをディスクに書き出さず，すべてメモリ上で処理
• ノード故障やメモリ溢れの場合にはクエリ自体が失敗
• バッチ処理ではなく，インタラクティブクエリ向け
12 https://prestodb.io/overview.html
参考: Presto のアーキテクチャ

13. データカタログ: Hive メタストア
• Athena のデータカタログと互換性がある
• Hive は SQL ライクな記法で，Hadoop上のバッチ処理を記述可能
• データソースに対してスキーマを定義し，テーブルのように扱える
• HDFS上のデータをベースとしており，標準 SQL とは異なる DDL を持つ
13 https://prestodb.io/overview.html
参考: Presto のアーキテクチャ

14. Glue データカタログへのアップグレード
• バージニア北部リージョンのみ，8/14 に GA になった AWS Glue のデー
タカタログを使用
• Athena 以外に Glue，EMR，および Redshift Spectrum で共通して参照
可能
• バージニア北部リージョンで新規に利用する場合は，自動で Glue にデー
タカタログが統合される
• Glue GA 以前から Athena を使っている方は，公式ドキュメントの手順に
従ってアップグレードをおこなってください
14 http://docs.aws.amazon.com/athena/latest/ug/glue-upgrade.html

15. Athena のデータ型
種類 値
プリミティブ型
tinyint, smallint, int, bigint, boolean, float, double,
string, binary, timestamp, decimal, date, varchar, char
配列型 array<data_type>
map型 map<primitive_type, data_type>
struct型* struct<col_name: data_type>
union型 UNIONTYPE<data_type, data_type…>
15 * https://aws.amazon.com/jp/blogs/big-data/create-tables-in-amazon-athena-from-nested-json-and-mappings-using-jsonserde/

16. Athena のデータ形式 / 圧縮形式
16
項目 値 注意点
データ形式
CSV, TSV,
Parquet, ORC,
JSON, Regex,
Avro, Cloudtrail,
Grok
• JSONについては Hive-JsonSerDe と
Openx-JsonSerDe の2つが利用可能
• CroudtrailSerDe* が利用可能
• 2017/8/14 に Grok をサポート**
圧縮形式
Snappy, Zlib, GZIP,
LZO
• 2017/4/6 に LZO をサポート
* https://aws.amazon.com/jp/blogs/big-data/aws-cloudtrail-and-amazon-athena-dive-deep-to-analyze-security-compliance-and-operational-activity/
** https://aws.amazon.com/about-aws/whats-new/2017/08/amazon-athena-adds-support-for-querying-data-using-logstash-grok-filters/

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

18. パーティション
• S3のオブジェクトキーの構成をテーブルに反映し
て，読み込むファイル数を減らす
• WHERE で読み込み範囲を絞るときに頻繁に使われ
るカラムを，キーに指定する
• 絞り込みの効果が高いものが向いている
• ログデータの場合，日付が定番
• “year/month/day” と階層で指定する
18
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-log/year=2016/month=04/day=01/
...
s3://athena-examples/action-log/year=2016/month=07/day=31/

19. パーティションの分け方
19
タイプ 形式 特徴
カラム名あり
(Hive 標準) col1=val1/col2=val2/
• CREATE TABLE をしてから，MSCK REPAIR
TABLE を実行すればOK
• パーティションが増えた際も，MSCK REPAIR
TABLE を1回実行すればOK
• この形式にするために前処理が必要
カラム名なし val1/val2/
• MSCK REPAIR TABLE が使えないため，ALTER
TABLE ADD PARTITION を，パーティション
の数だけ実行する必要がある
• 後からパーティションが増えた際も，増えたぶ
んだけ ALTER TABLE ADD PARTITION*
* あらかじめ先の期間までパーティションを作成しておけば，ファイルを置いた瞬間クエリ可能になる

20. 列指向フォーマット
指向 特徴
列指向
• カラムごとにデータをまとめて保存
• 特定の列だけを扱う処理では，ファ
イル全体を読む必要がない
• OLAP向き
• ORC, Parquet など
行指向
• レコード単位でデータを保存
• 1カラムのみ必要でも，レコード全
体を読み込む必要がある
• OLTP向き
• TEXTFILE(CSV, TSV) など
20
ORCのデータ構造
https://orc.apache.org/docs/spec-intro.html

21. 1 2 3 4 5 6
列指向フォーマット & 圧縮
OLAP 系の分析クエリを効率的に実行できる
• たいていの分析クエリは，一度のクエリで一部
のカラムしか使用しない
• 単純な統計データなら，メタデータで完結する
21
1 2 3 4 5 6 1 2 3 4 5 6
列指向行指向
I/O の効率があがる
• 圧縮と同時に使うことで I/O 効率がさらに向上
• カラムごとに分けられてデータが並んでいる
• 同じカラムは，似たような中身のデータが続く
ため，圧縮効率がよくなる
1 2 3 4 5 61 2 3 4 5 6
列指向行指向

22. 列指向フォーマット & 圧縮の使い方
• CREATE 文で指定するだけ
• データは事前にフォーマット変換 & 圧縮の必要あり
• 分析クエリを投げる際に，使用するカラムだけを読み
こむようになる
22
SELECT
month
, action_category
, COUNT(action_category)
FROM
action_log
WHERE
year = 2016
AND month >= 4
AND month < 7
GROUP BY
month
, action_category
CREATE EXTERNAL TABLE IF NOT EXISTS action_log (
user_id string,
action_category string,
action_detail 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');

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

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

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

26. パフォーマンスガイド & Tips
26

27. Amazon Athena の
パフォーマンスチューニング Tips トップ 10
ストレージのベストプラクティス
1. データをパーティションに分
ける
2. ファイルを圧縮・分割する
3. ファイルサイズを最適化する
4. 列指向データの作成を最適化
する
クエリのベストプラクティス
5. ORDER BY を最適化する
6. JOIN を最適化する
7. GROUP BY を最適化する
8. LIKE 演算子を最適化する
9. 近似関数を使う
10. 必要なカラムだけを読み込む
27 https://aws.amazon.com/jp/blogs/news/top-10-performance-tuning-tips-for-amazon-athena/

28. データをパーティションに分ける
• WHERE 句で頻繁に使われるカラムをパーティションキーに選ぶ
• ログ等の場合は，日付が第一候補
• テーブル内のパーティション数が増えすぎると，メタデータ取得・処理の
オーバーヘッドが増える
• データが特定パーティションに偏っている場合は，パフォーマンス状の恩
恵を受けづらい
クエリ
パーティション分け
されていないテーブル
パーティション分け
されたテーブル
実行時間 スキャン量 実行時間 スキャン量
SELECT COUNT(*) FROM lineitem
WHERE l_shipdate = ‘1996-’09-01’; 9.71s 74.1GB 2.16s 29.06MB

29. データをパーティションに分ける
• WHERE 句で頻繁に使われるカラムをパーティションキーに選ぶ
• ログ等の場合は，日付が第一候補
• テーブル内のパーティション数が増えすぎると，メタデータ取得・処理の
オーバーヘッドが増える
• データが特定パーティションに偏っている場合は，パフォーマンス状の恩
恵を受けづらい
クエリ
パーティション分け
されていないテーブル
パーティション分け
されたテーブル
実行時間 スキャン量 実行時間 スキャン量
SELECT COUNT(*) FROM lineitem
WHERE l_shipdate = ‘1996-’09-01’; 9.71s 74.1GB 2.16s 29.06MB
SELECT count(*) FROM lineitem; 8.4s 74.1GB 10.65s 74.1GB

30. ファイルサイズを最適化する
• パフォーマンスを最適化する際には，CSV のような分割できないフォー
マットを避ける
• Parquet / ORC のような分割可能なファイルフォーマットを用いることで，
ファイルの大きさに関わらず並列処理が行われる
• 読み込みにまつわるオーバヘッドが増大しないように，ファイルサイズは
128MB 以上にまとめるのを推奨
• 以下は 7GB のデータを単一ファイルにした場合と，5000 個に分割（1個
あたり 1.4MB）した場合の比較
30
クエリ ファイル数 実行時間
SELECT count(*) FROM lineitem;
5000 8.40s
1 2.31s

31. JOIN を最適化する
31
JOIN は大きなテーブルを左側に持ってくるほうがよい
右側のテーブルを各ノードに Broadcast して JOIN するため
Presto には Cost-based optimizer がないため，自動で最適化されない
以下の例では，lineitem テーブル=7GB, part テーブル=67GB
クエリ 実行時間
SELECT count(*) FROM lineitem, part
WHERE lineitem.l_partkey = part.p_partkey
22.81s
SELECT count(*) FROM part, lineitem
WHERE lineitem.l_partkey = part.p_partkey
10.71s

32. ORDER BY を最適化する
32
集計クエリで ORDER BY を行う場合，実際にはトップ100件くらいまでしか確認し
ないようなケースが多い
ORDER BY を行う際には，データを単一ノードに集約してソートするため，基本的に
計算を並列化できない
そのため，LIMIT 100 をつけてあげることで，ソート処理を高速に行うことができる
SELECT
*
FROM
lineitem
ORDER BY
l_shipdate
SELECT
*
FROM
lineitem
ORDER BY
l_shipdate
LIMIT
100

33. GROUP BY を最適化する
33
GROUP BY に複数のカラムを指定する場合には，カーディナリティが高
い順番に並べるほうがよい
前に並んだカラムの値に応じて，各ノードにデータを割り振るため，
カーディナリティが低いデータだと，処理が十分に並列化されない
FROM
action_log
GROUP BY
low_card_col
, high_card_col
FROM
action_log
GROUP BY
high_card_col
, low_card_col

34. LIKE 演算子を最適化する
34
LIKE 演算子で多数の比較を行う場合には，RegEx で一括処理をしたほ
うが効率がよい
それぞれの LIKE 演算子について捜査が走るため，数が増えるほど，ま
た文字列が長くなるほど，処理が重くなる
WHERE
comment LIKE ‘%wake%’
, comment LIKE ‘%regular%’
, comment LIKE ‘%expres%’
, comment LIKE ‘%sleep%’
, comment LIKE ‘%hello%’
WHERE
regexp_like(comment, 'wake|regular|express|sleep|hello')

35. 近似関数を使う
35
COUNT DISTINCT でユニーク数を求める際に，正確性より計算速度の
ほうが大事なときは，approx_distinct() で求めた近似値を使うとよい
approx_distinct() は HyperLogLog で近似値を求めているため，実際の
ユニーク数が多い場合でも高速に動作する
SELECT
COUNT(DISTINCT user_id)
SELECT
approx_distinct(user_id)
https://github.com/prestodb/presto/blob/master/presto-main/src/main/java/com/facebook/presto/operator/aggregation/ApproximateCountDistinctAggregations.java
https://github.com/airlift/airlift/blob/master/stats/src/main/java/io/airlift/stats/cardinality/HyperLogLog.java
https://github.com/airlift/airlift/blob/master/stats/docs/hll.md

36. Tips
• クエリ結果のデータが含まれるオブジェクト
キー名を取得
• 別ユーザの S3 バケットに対して Athena でク
エリを実行
• CTAS (CREATE TABLE AS SELECT) 的な運用
を擬似的に実現
36

37. クエリ結果のデータが含まれるオブジェクトキー名を取得
• SELECT の際に “$PATH” を指定することで，オブジェクト
キー名を得ることができる
• 問題のあるオブジェクトを Athena クエリで特定して，実際
にオブジェクトファイルにアクセスしたい場合に有用
37 https://github.com/prestodb/presto/issues/5486
> SELECT "$PATH" FROM mytable LIMIT 1;
s3://example-backet/mytable/2015/01/04/part-r-00023-ce65fca5-d6c6.txt

38. 別ユーザの S3 バケットに対し Athena でクエリを実行
ケース 1: 別のユーザの Athena を利用
• アカウント A が，自身の Athena / S3 に関する権限を
IAM ポリシーに設定して，適当なロールに設定
• アカウント B に対して，作成したロールへのアクセス
を許可
ケース 2: 別のユーザの S3 バケットに対してクエリ
• アカウント A の S3 バケットに対して，アカウント B
からのアクセスを許可するアクセスポリシーを設定する
38

39. CTAS を擬似的に実現
• Athena は現在 CTAS をサポートしていない
• クエリの出力結果は，s3_staging_dir で指定したディレクトリに
出力される
• 出力ディレクトリを指定したテーブルを作成しておき，それに対し
てクエリを投げることで，擬似的に CTAS を実現
39
CREATE EXTERNAL TABLE IF NOT EXISTS yourTableName (
col_name data_type
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
LOCATION 's3://path/to/results/'
https://aws.amazon.com/jp/premiumsupport/knowledge-center/athena-query-results/

40. Athena & Glue によるデータ分析の広がり
40

41. Amazon S3
Data Lake
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

42. Amazon S3
Data Lake
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ヶ所に集めて保存
データストアとデータ処理の分離
用途に応じた適切な処理方法の選択

43. AWS の分析サービス
43
Amazon EMR, AWS GlueETL
Amazon Redshiftデータウェアハウス
アドホッククエリ
Amazon QuickSightBI / 可視化
Amazon EMR, Amazon EC2, AWS Batch機械学習

44. AWS の分析サービス
44
Amazon EMR, AWS GlueETL
Amazon Redshiftデータウェアハウス
Amazon Athenaアドホッククエリ
Amazon QuickSightBI / 可視化
Amazon EMR, Amazon EC2, AWS Batch機械学習

45. AWS の分析サービス
45
Amazon EMR, AWS GlueETL
Amazon Redshiftデータウェアハウス
Amazon Athenaアドホッククエリ
Amazon QuickSightBI / 可視化
Amazon EMR, Amazon EC2, AWS Batch機械学習

46. 2017/8/14 に GA になった AWS上の ETL サービス
巨大データへのETL処理を
スケールアウトで対応
サーバレスで提供
AWS Glue
https://aws.amazon.com/jp/glue/

47. Glue の全体像
• データソースをクロールし，メタデータを取得し，データカタログで管理
• メタデータをもとに PySpark のジョブを作成し，サーバレスな環境で実行
47

48. Glue ベースの S3 データレイク
• 各種データソースに対して Glue ジョブで ETL を実施
• 結果を Redshift に格納して分析
48

49. Glue ベースの S3 データレイク
• S3 上のデータを Glue クローラー経由でデータカタログに登録しておく
• 用途に応じて Athena, EMR, Redshift Spectrum から分析
49

50. Glue で低レイテンシの Parquet 変換 ETL を実施
• CSV/TSV/JSON 等のログファイルを Parquet に変換するた
めに，従来は EMR などを用いる必要があった
• Glue なら GUI 操作のみでも Parquet 変換ジョブを作成可
能
• S3 ファイル追加キックで Lambda を起動して Glue ジョブ
を実行すれば，低レイテンシの変換処理が可能に
50
S3Data Source Lambda Glue S3 Athena

51. Glue でパーティションの自動アップデート
• 従来は，新しく追加された Athena テーブルのパーティションを認
識するために，MSCK REPAIR TABLE / ALTER TABLE ADD
PARTITION コマンドを実行する必要があった
• Glue クローラーをスケジュール or Lambda 経由で実行すること
で，常に最新のパーティション状態を認識させることが可能に
– 5 分間隔でスケジュール実行可能
51

52. Kinesis Firehose 経由で取得したログに対して
ニアリアルタイムでクエリ
• Kinesis Firehose が 2017/8/24 に東京リージョンで利用可能に
• Kinesis Firehose はデフォルトで year/month/day/hour と
いう S3 キーの形で保存され，Glue クローラーなら自動で JSON
フォーマットおよびパーティションを認識してくれる
• ログが置かれたら，すぐに分析クエリを投げることができる
52

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

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

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

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

57. JDBC ドライバーによる BI ツールからのアクセス
• JDBC 対応のさまざまな BI ツールから接続することが可能
• Tableau は 2017/6/5 リリースの 10.3 で Athena コネクタをサポート
• Redash もデータソースとして Athena をサポート
• もちろん，Amazon QuickSight も Athena をデータソースに指定可能
57
https://www.tableau.com/about/blog/2017/5/connect-your-s3-data-amazon-athena-connector-tableau-103-71105
https://redash.io/help/data-sources/amazon-athena.html

58. API 経由での既存アプリケーションとの連携
• クエリ実行とネームドクエリの 2
つのカテゴリ
• AWS SDK 経由で Python / PHP
/ Ruby /Java などから接続でき，
内製アプリケーションと連携可能
• テーブル情報の取得やテーブル操
作は，Glue API 経由でも実行す
ることができる
• AWS CLI からもアクセス
58
Category API
Query
Execution
BatchGetQueryExecution
GetQueryExecution
GetQueryResults
ListQueryExecutions
StartQueryExecution
StopQueryExecution
Named
Query
BatchGetNamedQuery
CreateNamedQuery
DeleteNamedQuery
GetListNamedQuery
ListNamedQueries
http://docs.aws.amazon.com/athena/latest/APIReference/Welcome.html

59. まとめ
59

60. まとめ
• Athena は S3 上のデータに対する，Presto ベースのインタ
ラクティブなクエリサービス
• ベストプラクティスに沿った使い方をすることで，非常に高
いパフォーマンスを得ることができる
• 昨年末のリリース以降，さまざまな機能追加や性能改善を行
なっている
• Athena と他のサービスを組み合わせることで，さまざまな
形で分析を行うことができる
60

61. 61