こんにちは。
キャスレーコンサルティングのSI(システム・インテグレーション)部の杉光です。

今回はAWS Athenaの機能と特徴、性能検証結果について紹介させて頂きます。

AWS Athenaとは

Athenaは昨年度のRe:Inventで発表されたAWSの新しいインタラクティブクエリサービスです。
Google Big Queryの対抗サービスとも言われています。

現時点では、Management Console(GUI)及び、JDBC接続からクエリの実行ができ、主に以下の機能があります。

自動並列実行クエリサービス

  • 利用者がコンピューティングリソースを意識する必要がなく、サービス側が必要なリソースを計算し、
    クエリが自動的に並列実行される。大容量のデータも数秒〜数分で検索・集計できる。

S3のデータに対して標準SQLで分析可能

  • ANSI SQLに準拠したPrestoがベースとなっており、関数もPrestoでサポートされているものが利用可能です。
  • Schema-On-Readとなっていて、テーブルの作成、削除、変更、
    パーティションの追加・削除のDDLをApache Hiveで作成できる。
  • 実行したクエリに対してのみ料金が発生し、1TBあたり5USDの料金が発生する。(S3の料金は別途掛かる)

その他の特徴

利用の制限

  • クエリは検索のみ。UPDATE/INSERTなどはできない。
    Hadoop特有のORCやParquetなどのファイルフォーマットを用意する場合は、
    HiveやSparkなど他のエコシステムから作成する必要があります。
  • UDFやストアド・プロシージャが使えない。
  • データベースやテーブル単位での認可が行えない。(リソースはAWSアカウントで共有されてしまいます。)
    現状はDBやテーブル単位でのIAM制御が行えないので、S3バケットに対してのアクセス制御(IAM/バケットポリシー)となります。

コストの節約

  • パーティション化による節約
    S3に格納するデータをPrefixで区切り、パーティション化することで、データの参照を限定できる。
  • カラムナデータによる節約
    ORCやParquetのデータ・フォーマットにすることにより、特定のカラムの参照に限定することができる。

Athenaの使用例

続いて、Athenaの使用方法について簡単にご説明します。

事前作業として、Athenaを使用するIAMについては事前にAthenaを実行するために必要なポリシーを付与しています。
また、データを以下のようにS3のemrtest-dataバケットに配置しました。
気象庁の過去天気データを各都市毎に格納しています。

S3-dir

AthenaのConsole画面は以下のようになっています。
4つのタブがありますが、今回はクエリの編集や実行ができる「Query Editor」をご説明をします。
画面中央部がクエリの編集&実行部になり、その下で実行結果が確認できます。

athena_1

テーブルとパーティションの作成

DB、テーブル、パーティションの作成は「Catalog Manager」からでも行えますが、
今回はHiveクエリのDDLにて作成します。
尚、DBについてはDefaltを使用します。青枠のクエリにてweather_tsvテーブルを作成しました。
athena_2

パーティションの作成

続いて、先程作成したテーブルに対してパーティションを作成します。
該当データをS3パスにて/key=valueの形式で配置したので、動的にパーティションを認識することができます。
動的にパーティションを認識するには青枠のように”MSCK REPAIR TABLE table_name“を使います。
athena_3_msck

登録されているパーティションを確認します。
例では”city”をパーティションKeyとして認識していることが実行結果からわかると思います。
athena_4_showpartition

検索クエリの実行

作成したテーブルに対してクエリ(SELECT)を実行します。
各都市毎、年毎の平均気温を降順に表示しています。(那覇が上位を占めますね・・・)
クエリの実行結果はCSVファイルでダウロードすることもできます。

athena_5_execquery

Hive/Prestoとパフォーマンスを比較

最後にAthenaのパフォーマンスを確認します。
比較対象としてApache HiveとAthenaのベースとなっているPrestoを使用します。
PrestoはFacebook社が開発した分散クエリ実行エンジンです。

HiveとPrestoはAmazon EMRを用いて性能を計りたいと思います。
EMRはHive、Presto共にアプリーケーションサポートしているので、起動が簡単です。
リソースとバージョンは以下の通りです。

各検証サービスのバージョンとリソース

Hive:2.1.1 (Tez:0.8.4)
Presto:0.157.1(Hive catalogを使用)
EMRリソース
– Master Instance : m1.mededium
– Core Instance : m4.large

対象データ

Athenaの利用例にて少し触れましたが、気象庁が提供する過去の天気データを使用しました。
(http://www.data.jma.go.jp/gmd/risk/obsdl/index.php)
項目は、日付/日中平均気温/降水量の日合計/天気概状(昼)を選んでいます。
※ダウンロードしたデータの中には品質情報や、均質番号が含まれていますが、集計対象からは無視しています。

対象フォーマットと件数

対象データのフォーマットはTSV、Parquetとし、件数はそれぞれ、オリジナルのデータ件数、
オリジナルの10倍、オリジナルの100倍の件数を用意しました。
S3への配置方法は利用例と同様に各都市毎に約60年分のデータを置いています。

検証クエリ

まず、TSV、Parquetのデータに対して以下のようにテーブルを定義します。
HiveのDDLになりますが、PrestoとAthenaともに同じクエリを使うことができます。

TSVファイル

CREATE EXTERNAL TABLE weather_tsv(
dt STRING,
temperature FLOAT,
t_1 STRING,
t_2 STRING,
precipitation FLOAT,
p_1 STRING,
p_2 STRING,
p_3 STRING,
summary STRING,
s_1 STRING,
s_2 STRING
)
PARTITIONED BY( city STRING )
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '\t'
LINES TERMINATED BY '\n'
LOCATION 's3://emr-testdata/tsv3/';

Parquetファイル

CREATE EXTERNAL TABLE weather_parq(
dt STRING,
temperature FLOAT,
t_1 STRING,
t_2 STRING,
precipitation FLOAT,
p_1 STRING,
p_2 STRING,
p_3 STRING,
summary STRING,
s_1 STRING,
s_2 STRING
)
PARTITIONED BY( city STRING )
STORED AS PARQUET
LOCATION 's3://emr-testdata/parquet3/';

検索クエリ
計測対象のクエリは以下の2種類です。

検証クエリ①

--- 年毎に天気概状の中に"雪"が含まれている日を集計し、降順にソート
--- select tsv (ANSI)
select city,substr(dt,1,4),count(*) as cnt from weather_tsv where summary like '%雪%' group by city,substr(dt,1,4) order by cnt desc;
--- select parq (ANSI)
select city,substr(dt,1,4),count(*) as cnt from weather_parq where summary like '%雪%' group by city,substr(dt,1,4) order by cnt desc;

検証クエリ②

--- 年毎に平均気温を降順にソート
--- select tsv
select city,substr(dt,1,4),avg(temperature) as tmp from weather_tsv group by city,substr(dt,1,4) order by tmp desc limit 20;
--- select parq
select city,substr(dt,1,4),avg(temperature) as tmp from weather_parq group by city,substr(dt,1,4) order by tmp desc limit 20;

検証結果

各データ(フォーマット/件数/クエリ)に対する結果は以下の通りです。
(各々3回クエリを実行し、平均値を四捨五入したものになります)
※単位は秒です。

ファイル形式 TSV Parquet
件数 origin 10倍 100倍 origin 10倍 100倍
クエリ
Hive 30 35 44 45 58 83 23 19 43 45 59 84
Presto 7 3 11 7 34 43 7 3 11 7 34 44
Athena 1 2 3 3 4 3 2 1 5 3 3 3

今回の検証はEMRクラスタのリソースを小さめに設定しました。
HiveとPrestoは件数が増えるにつれて、処理時間が増していますが、Athenaは殆ど変わりないことが確認できました。
Prestoもインタラクティブクエリと言われているだけあり、データ容量とクラスタリソースの関係によっては、
Athenaに引けを取りませんでした。

さいごに

以上の結果からAthenaがリソースを意識することなくQueryを実行し、結果を得られることがわかりました。
今まではEMRでETLを行い、Redshiftで分析・集計を行うプロセスが多かったかと思いますが、
ETLを行うケースが減り、EMRのパフォーマンスに苦しんでいたエンジニアを助け、
分析官もより柔軟に素早くデータに触れる機会が増えることと思います。
現時点ではManagement ConsoleとJDBCからの利用に限られますが、
今後利用リージョンの拡充と他サービスとの連携が可能になり、利用用途も増えてくると思うので楽しみに待ちたいと思います。

参考文献

https://aws.amazon.com/jp/blogs/news/analyzing-data-in-s3-using-amazon-athena/
http://docs.aws.amazon.com/athena/latest/ug/what-is.html