Presto雑感
約1年間Prestoを運用していて気づいたことを書いてみようと思う。
Prestoが素晴らしいOSSプロダクトであることは間違いなくて、Hiveを使っている人はインストールして損は無いと思う。
メリットは下記の通り
- Hiveに比べるとオンメモリで処理するので高速でアドホッククエリに向いている
- 安定している。
- ストレージを持たないアーキテクチャなのでアップデートが簡単
- 開発が活発。最近は以前に比べるとバージョンアップのスピードは落ちてきたがそれでも3週間に1回はバージョンアップしている。
- バグ報告すると数日で修正されたバージョンがリリースされる。
- 開発がオープン。pull requestも受け付けておりコードレビューが丁寧
- コードが奇麗でモダンJavaの代表だと勝手に思ってる
最近の変更を見る限りPrestoは安定性を重視しているように見え、これは僕のような管理者にとっては運用負荷が少なくなって嬉しい。
世の中にはユーザーにとっては便利だけれども管理者にとっては辛いプロダクトもある。
その例はSparkなのではと疑っているが、僕が使ったこと無いので正直なところはわからない。
Hiveも若干運用負荷もあって、例えば誰かがうっかり重いクエリを投げっぱなしで帰宅した場合にどうするかという話がある。
他のバッチジョブのクエリになるべく悪影響を与えたくないからね。
この手の糞クエリ問題は分析サービスをクラウド上で展開している企業にとっても大きな問題のはず。
JobTracker時代であればMapReduceジョブにプライオリティを付けるというのが一つの手段だったがYARNだとどうなんだろ。
うちの環境ではShibの設定で一定時間を超えたら自動でkillするようにしたり、map数が一定数を超えたら知らせるようなスクリプトを仕込んだりしてます。
Prestoの安定性に関わる最近の変更として具体的に言うとメモリ管理の方式が変わった。
ドキュメントとしては以下の辺りが多少参考になると思う。
https://prestodb.io/docs/current/release/release-0.103.html
https://github.com/facebook/presto/issues/2624
ざっくりいうと従来タスク単位で制限していたメモリ使用量(task.max-memory)をクエリ単位で制限できるようになった。
これによってタスク数が多いクエリが走ったときにOutOfMemoryになってworkerが落ちるということが無くなった。
仕組みとしては、クエリをsubmitするとそのクエリのメモリ使用量をトラッキングして一定量（デフォルトだと1nodeで1GB(query.max-memory-per-node)、クラスタ全体で50GB(query.max-memory)）を超えるとエラーになって返ってくる。ちなみにうちの環境ではquery.max-memory-per-nodを2GBにしてます。
クエリのtimeout機能(query_max_run_time)もあるんだけど、デフォルトが100日になっててFacebookはどういう運用なのか不思議。1日で十分な気がするけど、Prestoで数日かかるようなクエリが日常的に実行されているということなのかな。
良い事ばかり書いたけどデメリットもある。
具体的には下記2つ。
プラグインアーキテクチャが無いので自分でUDFを作った時に再起動無しにdeployすることが出来ない。
Connectorも同じ。
現状だとUDFやConnectorも1つのリポジトリにあって、Presto teamの人がMongoDBやElasticsearchのConnectorのpull requestをレビューしているが、これだと辛いよね。。。
EclipseやJenkinsなど成功したOSSプロダクトはたいていプラグインアーキテクチャを持っており、開発者が自由に機能追加出来る環境を持っているのでPrestoもそうなると良いなあと思ってます。
JDBC周りはやる気無さそうっていうのはpull requestが放置されているのもそうだし、現状だとPrestoからMySQLやPostgreSQLにクエリなげたときにLIMIT効かないし、whereも一部しか効かない。
Presto teamからするとRDBMSにある少量のマスターデータをjoinすればいいので、別にfull scanで良いよねってことだと思う。
ただしこれだと、Redshift, Netezza, InfiniDBのような大量のデータを対象にしたときには使えない。
この問題があるのでHiveを使ってない人がPrestoを活用するメリットが少なくなっている。
以上が僕の印象です。
