Amazon Athena — Serverless Interactive Query Service - AWS

Prestoのフォースを感じたので，知り合いが試した情報も含めて，今思っている所を書いてみる．

実装

Athenaのページにあるように，実行エンジンは独自実装ではなくて，Facebookが公開しているPrestoを使っている．FacebookのみならずTreasure Data，Airbnb，Netflixなどクエリがガンガン飛ぶ環境で元気に動いている実績もあるので，拡張性，パフォーマンス，安定性で選ばれたのだろうと思われる．あとAWS的にJavaの方が相性は良さそう．

パフォーマンス

いくつかの記事で言及されている．

• Analyzing Data in S3 using Amazon Athena
• Amazon AthenaをBigQueryと比較してみた
• Amazon Athena: カラムナフォーマット『Parquet』でクエリを試してみた

これらを見ると，Prestoをそんなに改造せずに動かしている感じ．例えばGunosyさんやclassmethodさんの記事ではとりあえずフルスキャンをするcsv.gzの方がParquetより速い．データ量が少ないのとクエリが単純なので誤差の範囲に収まってる可能性もあるが，ParquetのReaderをAthena向けに改造している感じはしない(TQA(TDのPresto)の場合，PlazmaDB向けに色々と最適化したReaderを実装してパフォーマンスを稼いでいる(参考))．

AWSがGoogleのColossus相当を持っているという話は聞かないものの，それでもBigQueryに近いパフォーマンスが出たりもするようなので，1クエリで多めにワーカーを使っているんじゃないかと思っている．TQAがクエリによっては同じデータ量でBigQueryとかその他DWHより高速に動いたケースってのはいくつかあるので，Prestoを使っているAthenaでも同様になると思われる．

あと細かなところだけど知り合いの試した情報によると，TQAとかBigQueryはキューイングされてから実行が完了するまでの実行時間が表示されるが，Athenaはクエリが走り始めてから完了するまでの時間しか表示されてないようなので，キューイングまわりで時間が掛かっている場合，体感と表示時間にかなり差があくようだ．

スケジューリング

1クラスタに数千ワーカー(今のPrestoだと万は怪しい？)があって，そこにユーザが割り当てられ，そこの中でさらに適宜ワーカーを選んで処理をしている感じ．

Amazon AthenaでCloudFrontログをSQLで解析する #reinvent #athena

例えばこの記事の最後に「同じSELECTでも数秒で終わるものが時間帯によって数百秒かかることがあったり」というのがあるので，リソースが空いてるワーカーやクラスタをちゃんと選んでいるのではなくて，おそらくランダムか割り当て回数が少ないワーカーを選んでいるっぽい．この辺はBigQueryと同じで，実際複数ユーザが投げ続ける環境だと空いてるワーカーをクエリ負荷含めて探すのはかなり難しいので，この手のアプローチがシンプルでそれなりによく動く．

ただ，知人の試した結果だと，1時間弱くらいResourceUnavailableで弾かれ続けた，みたいな状況もあるようなので，重めのクエリを投げ続けると制限されるのか，ユーザのクラスタ割り当てが一定時間は固定で，ビジーなクラスタに割り当てられるとクエリが失敗しやすくなるのかもしれない．

Athenaのページに同時実行数に関する記述がないので，この辺どれだけ絞っているのかよく分からないのが悩ましいところ……

エラーハンドリング

どうもPresto内部でいくつかエラーを握りつぶしているっぽい．これはBigQueryもそうなんだけど，多分そのエラーによってクラスタの状態とかバックエンドの詳細が分かってしまうので，「とりあえずエラー」みたいなのを返しているようだ． エラーが起きたらとりあえずretryする感じになりそう．

カスタマイズされている部分

ユーザが目に見えるところだと，DDLとか禁止されているクエリ周り．例えば運用上発行されたら困るDDLとかはもちろん弾かれるし，生のPrestoとかTQAだと通るクエリがAthenaではエラーになったりすることもあるようなので，その辺は運用との兼ね合いで禁止しているようだ．

あと当たり前だけどHiveのmetastore周りはAWS向けに専用サーバを実装しているっぽい．

料金

ここは思いっきりBigQueryを参考にしているようだ，がBilling Tierみたいなのはない．いずれ入るかもしれないが，AthenaはBigQueryのようにバッチとか含めてDWH的に使わせる気はあまりないようなので，当分ないだろうと思っている． ただ，AWSは既存のうまく行ってるサービスを自社サービスに取り込んで提供する傾向が強いので，今後BigQueryに寄せていく可能性はありそう．

Athenaは様々なフォーマットに投げられる一方，jsonやcsvみたいなオブジェクトを対象にすると強制的にフルスキャンになるので，その分課金がバーストしやすい．列指向にするにはEMRのSparkとか使って行うのが鉄板のようだ．

あと当たり前だけどS3に対する保存・APIリクエスト・データ転送分も別途課金されるので，1TB per 5$ + additionalというのは気をつけてないと，想像より課金されてた，みたいなのが起きやすそう．特にデータ転送量．

感想

結構TLとか見てると，「BigQueryの対抗だ！」みたいなtweetを見かけたりするけど，個人的にはあくまでManaged Prestoって感じでまだ対抗みたいな感じはしてない．今後，ヘビーユーザが増えた時にどこまでうまくworkするのかは気になっているところ．

出来れば，AWSからPrestoにガンガンパッチとかFeature Requestが飛んでくれると嬉しいなぁと思ってます．

TinySegmenterをJulia移植したらMITの先生に指導してもらえた話

上の記事がTLで結構話題になっていて，そういえば昔TinySegmenterをD言語で実装したなぁと掘り起こした(TinySegmenter written in D)．5年前のコードだったけど最新版でもさっくりと動いたので，どれくらいか比較のためにベンチマークを取ってみた．

結果としては，Juliaには勝てなかった．コードを読んだ限り，Julia実装は他のとは違って中間のsegmentsリストを作らなかったりとか最適化がちょくちょく入っているので，この辺D言語でも頑張れば近いパフォーマンスは出せそう．

ベンチマークしたのは手元のMBP．それぞれの処理系は*envで入れたりhomebrewを使って入れたりした．

• Processor: 2.6 GHz Intel Core i7
• Memory: 16 GB 1600 MHz DDR3

上の記事のベンチマーク結果は，Pythonのベンチマークだけループ回数が100じゃなくて10だったり，Juliaの実装にTC1などのスコアリングがなかったりといくつか完璧ではないので，修正した後にchezouさんが再度計測しなおすと思われます(すでに本人には報告済み)．

以下手元でのベンチマーク結果．速かった順．

• julia 0.4.0

masterだとTC1とかの修正が入ってます．

1
2
3

% julia -L ../src/TinySegmenter.jl benchmark.jl

  8.887454 seconds (5.04 M allocations: 253.778 MB, 0.53% gc time)

• ldc2-0.16.0-beta2

1
2
3

% ~/ldc2-0.16.0-beta2-osx-x86_64/bin/ldc2 tinysegmenter.d -O3 -boundscheck=off -inline -release -run benchmark.d

segment: 14 secs, 923 ms, and 352 μs

• nodejs v4.2.1

1
2
3

% node benchmark.js

82.42sec

• Ruby 2.2.3

高速化したバージョン．パッチはすでに本家に投げました(Improve performance by repeatedly · Pull Request #1 · 6/tiny_segmenter)

1
2
3

% RUBYLIB=./lib ruby benchmark.rb
                 user     system      total        real
segment    110.560000   0.800000 111.360000 (111.823173)

• Python 3.5.0

Python 2の方は3.5に比べて遅いらしいのでやってない．

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

% python tinysegmenter3.py
## benchmarker:         release 4.0.1 (for python)
## python version:      3.5.0
## python compiler:     GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.72)
## python platform:     Darwin-15.0.0-x86_64-i386-64bit
## python executable:   /Users/repeatedly/.pyenv/versions/3.5.0/bin/python
## cpu model:           Intel(R) Core(TM) i7-4960HQ CPU @ 2.60GHz 
## parameters:          loop=1, cycle=1, extra=0

##                        real    (total    = user    + sys)
tokenize              181.4310  181.0800  180.2500    0.8300

## Ranking                real
tokenize              181.4310  (100.0) ********************

## Matrix                 real    [01]
[01] tokenize         181.4310   100.0

• Tokyo Apache Drill Meetup
• MapR CTOも来日！ Tokyo Apache Drill Meetup #tokyodrill まとめ

上のイベントに参加してました．普通の感想は他の人が書くと思うので，質問した内容とその返答を書いておきます．

スキーマを自動検出するけど，途中で変わったらどうなるの？

現状はエラーになる．

DrillはSchema on Readに加えて，データ読み込み時にスキーマを自動で生成する機能もある(Embulkのguessみたいなもの)．JSONとかのローカルファイルに対してクエリ投げる時は，いちいちスキーマを自分で設定する必要がなくて便利なのだけど，さすがに後半のデータで急に型が変わったりフィールドが増えたりすると，クエリ処理を続行できないとのこと．
そういう時はちゃんとスキーマを事前に定義する必要がある

クエリ毎のリソース制御ってどうしてるの？

現状その手の機能はない．並行で処理するクエリの数は制限できる．

Prestoだとクエリ毎にメモリ使用量とかを制限できて，それによってどれだけクエリが投げられても，ワーカー群はかなり安定して処理を実行できるようになっている．現状のDrillユーザは，あらかじめどれだけメモリを使うかなどを測定して，それに見合ったクラスタを構築しているらしい．

大きいDrillクラスタって今どれくらい？

1クラスタ100台の事例はある，とのこと．

Prestoだと1クラスタ1000台とかの事例はあるけど，これを聞く限りまだ大規模での事例はそこまでないようだ．ここは後発なのものあって，今後事例は出てくるかもしれないが，上で言及したリソース制御とかがないと，大規模での運用は結構厳しそう．

分析系の関数やWindow関数がほとんどないようだけど，今どうやって解析してるの？

Window関数相当のSQLを頑張って書いているか，自分達でDrillを拡張しているかのどちらか．

Drillは現状の1.1だと，Window関数とかはあまりサポートされてなくて，Presto/Impalaで使える便利関数群が色々と使えない．今Drillを採用している人達はどうやって様々な分析をやっているのか，というのは運用・自社開発でカバーという感じらしい．この辺がこなれないと，普通の人達が使うのは結構厳しい感じ．

上がMapRの人達に聞いた内容．後発なのでPrestoなどの良いところを取り込んでいるものの，まだ成熟してない感じなので，プロダクションで使うには運用でカバーしないといけない箇所が結構あるなぁという．
ApacheプロジェクトだしMapRがかなり開発リソースを割いてる感じなので，上記の問題群はいずれ解決されるだろうとは思いますが，Presto/Impalaもかなり開発が活発なので，どこまで差別化出来るのかが今後の注目ポイントになりそう．

俺も時間を作って色々とチェックしてみるか…

YAPC::Asia Tokyo 2015

今年で最後となるYAPC::Asia Tokyoで，データ分析基盤まわりについて発表してきました．部屋は満席だったようで，聞きに来てくれた皆さん，ありがとうございました．会場はD言語erにふさわしくD会場でした．

データ分析基盤を支える技術 - YAPC::Asia Tokyo 2015 これが今どきのデータ解析基盤だ！初心者のためのデータ解析講座 #yapcasia #yapcasiaD - Togetterまとめ

どういう展開にしようか悩んだんですが，データ分析基盤の構築に使われる様々なソフトウェアが，どういう問題を解決するために導入されているのか，またその一方どういう問題を持っているのか，を一からデータ分析基盤を作るという流れで話していくことにしました．
既にガリガリやっている人向けではなくて，これからやろうとしている人，やってるけど現状の仕組みだと厳しくなってきたので今後どうしようか考えている人，などの参考になればと思っています．

データ分析周りに興味があった人が結構聞きに来てくれたらしく，全体の流れを俯瞰できて良かった，みたいな感想もチラホラ見受けられたので，この構成にして良かったな，とホッとしています．
スライドのまとめにも書いていますが，Treasure Dataなどのデータ分析基盤や，AWSやGCPやAzureのような分析基盤を作るためのコンポーネントを提供しているクラウドが増えているので，自分で一から構築する必要性はかなり低くなっています．「どういうソフトウェアがありどういうことが出来るのか」を知っておくのは重要ですが，なるべく便利なサービスを利用して，ビジネスに集中した方が良いでしょう．

SparkやFlink，その他可視化，機械学習，データパイプラインなども話したかったんですが，時間が足りなかったので，これらはまたどこかでチャンスがあれば話しても良いかなぁと．

上のtogetterのまとめには質疑応答に関するtweetはまとめられてないようなので，気になる方はいずれアップロードされる動画を見てください :)

YAPC::Asia 2015が8月にあるんですが，最後ということでトークをサブミットしてみました．

データ分析基盤を支える技術 - YAPC::Asia Tokyo 2015

Abstractに書いてあるとおり，そんな感じの話を60分かけてします． 各ソフトウェアとかの詳細に言及すると60分に収まらないので，深い話とかは 別途飲み会とかでしましょう(トークが落ちてもちゃんと参加します！)．

YAPC::Asia Tokyo 2015 Talk Ranking

現在30位前後で受かるかわかりませんが，聞きたいトークがいくつかあるので， 裏番組にならないことを祈るばかりです…(-人-)