こんにちは。
キャスレーコンサルティングの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バケットに配置しました。
気象庁の過去天気データを各都市毎に格納しています。
AthenaのConsole画面は以下のようになっています。
4つのタブがありますが、今回はクエリの編集や実行ができる「Query Editor」をご説明をします。
画面中央部がクエリの編集&実行部になり、その下で実行結果が確認できます。
テーブルとパーティションの作成
DB、テーブル、パーティションの作成は「Catalog Manager」からでも行えますが、
今回はHiveクエリのDDLにて作成します。
尚、DBについてはDefaltを使用します。青枠のクエリにてweather_tsvテーブルを作成しました。
パーティションの作成
続いて、先程作成したテーブルに対してパーティションを作成します。
該当データをS3パスにて/key=valueの形式で配置したので、動的にパーティションを認識することができます。
動的にパーティションを認識するには青枠のように”MSCK REPAIR TABLE table_name“を使います。
登録されているパーティションを確認します。
例では”city”をパーティションKeyとして認識していることが実行結果からわかると思います。
検索クエリの実行
作成したテーブルに対してクエリ(SELECT)を実行します。
各都市毎、年毎の平均気温を降順に表示しています。(那覇が上位を占めますね・・・)
クエリの実行結果はCSVファイルでダウロードすることもできます。
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