Prestoで実現するインタラクティブクエリ - dbtech showcase 2014 Tokyo

Editor's Notes

1. トレジャーデータがデータベースの企業として成長するお手伝いをしています
2. 3~4週間に1回 新しいversionがリリースされるくらい開発速度が速い。 TDのcontributionは現在Facebookに次いで2位 UDF機能の追加、TD_TIME_FORMAT, TD_TIME_RANGEなど
3. Treasure Dataでは2種類のSQL Engineを提供 Hive バッチクエリ：スループット重視 日に数千~数万件以上のクエリを処理するなど 時間はかかるが大量データ処理を確実に処理する 耐障害性 CPU使用効率が悪い（1 map/reduce task = 1 core） Presto アドホッククエリ：レスポンスタイム重視 数秒〜数分でクエリの結果を知りたい場合 耐障害性なし TDでは独自にリトライ機構を導入 CPU使用効率が良い 相互に補完しあう関係
4. ではHadoopを使った良くあるデータ解析システムの問題を、図を使って具体的に見てみます。 可視化ツールが直接Hiveクエリを投げる使い方は、遅すぎてストレスフルなので、Hiveが定期的にクエリを実行し、中間的なDBに結果を書き出し、BIツールなどから可視化する。この中間DBはデータマートと呼ばれたりします。しかし…
5. そこがスケールしない。あるいは余計にコストがかかる。 BIツールやDashboardが生のデータに直接投げられないとなると、こっちの解析チームからすると、インフラチームに頼んで、必要なデータをデータマート上に作るバッチジョブを実行しておいてね、みたいな話が起きてきます。インフラチームはさらに、実はOracleに入っているで他をHDFSに定期的にコピーするスケジュールを作ったりしないと行けない。 インフラ側の問題としても、性格の異なる2つのプラットフォームを維持し続けるには、異なる知識が必要です。このプラットフォームを維持すること自体のコストが高い。
6. これが、Prestoがあると解決します。 DashboardやBIツールは、Prestoを使ってHDFS上にあるデータにクエリを実行できるようになります。このため、中間的なデータマートをHDFSに作れます。従って、中間データベースに割くコストは削減できます。 さらに、すべてHDFSという単一のプラットフォームに載っているので、インフラの維持が大幅に楽になります。
7. さらに、PrestoはHDFS以外のデータストアからデータを読み出すことができます。データをHDFS上に持ってこなくても、データをJOINして可視化したりできます。そもそも、HDFSを使わないという選択肢も出てきますね。例えばCassandraをデータ解析のプライマリストレージに使う選択肢もアリです。 実はプラグイン構造なので、商用DBや、自社専用のストレージエンジンにもクエリを実行できます。
8. さらに、PrestoはHDFS以外のデータストアからデータを読み出すことができます。データをHDFS上に持ってこなくても、データをJOINして可視化したりできます。そもそも、HDFSを使わないという選択肢も出てきますね。例えばCassandraをデータ解析のプライマリストレージに使う選択肢もアリです。 実はプラグイン構造なので、商用DBや、自社専用のストレージエンジンにもクエリを実行できます。
9. 毎日200億レコード、数TB
10. online to offline
11. さらに、Prestoは商用BIツールと安定して接続が可能です。これがなぜ可能かと言う秘密は後ほど紹介します。 以上のデータ解析プラットフォームを、Prestoをハブとして構築できる。これがPrestoの大きな導入メリットです。
12. で、考えた方法ですが、PostgreSQLプロトコルを使えばいいじゃない。 PostgreSQLのプロトコルを話すのだけど、裏側ではPrestoのクエリを実行する。これなら、PostgreSQLの安定した実績のあるODBCドライバを使えますね。 そこで、これ僕が作ったんですが、Prestogresというゲートウェイサーバを作りました。
13. どういう仕組みで動いているかというと、pgpool-IIという既存のミドルウェアを改造しました。 pgpool-IIは、元々はPostgreSQL用のロードバランサ兼コネクションプールの実装です。そこにクエリを書き換える機能を入れたんですね。どいう書き換えるかというと、受け取ったSELECT文を、関数の引数の中に入れます。それをPostgreSQLで実行すると、PostgreSQL的には普通の関数を実行しているのと同じように見えます。 その関数は、僕が自作した関数で、Prestoにクエリを投げて結果を返す関数なんです。
14. これがPrestoのアーキテクチャ図です。１つずつ解説していきます。
15. まずPrestoには、3種類のサーバがあります：Coordinator、Worker、Discovery Service。 Discover Serviceは、このネットワークにどんなサーバがいるか、という情報を持っていて、coordinatorやworkerはDiscovery Serviceを経由して他のノードを見つけ出します。
16. クエリを実行するときは、まずクライアントがCoordinatorにSQLクエリを発行します。 ここのプロトコルはHTTPです。POSTで送ります。
17. それから、Coordinatorがクエリの実行計画を立てます。 このときに、CoordinatorがConnector pluginというライブラリを経由して、テーブル一覧やスキーマを取得してきます。
18. 実行計画ができたら、Coordinatorはその実行タスクをWorkerに割り振ります。これで分散実行が始まります。
19. クエリが始まったら、WorkerはConnector pluginというライブラリを経由して、ストレージから行をどんどん読み出していきます。
20. Workerはデータを読み出しつつ相互に通信して、クエリを実行していきます。この実行は全部メモリ上で行われます。途中結果をディスクに書き出したりはしません。全部パイプライン化されています。
21. 結果ができあがってきたら、クライアントがworkerから結果を取得します。
22. 全体図です。Discovery serviceがサーバの発見を行います。Coordinatorがクライアントからクエリを受け取り、実行計画を立てて、Workerにタスクを割り当てます。Workerはクエリを実行します。 テーブル一覧の取得や、データの読み出しは、Connector pluginと呼ばれるライブラリを経由して行われます。
23. まずQuery Plannerです。Query Plannerは、クライアントから受け取ったSQL文と、Hiveメタストア、つまりコネクタから取得したテーブルスキーマを元に、論理クエリプランを組み立てます。さらにそこから分散クエリプランを組み立てます。 例えば、このselect文では、partial aggregation、final aggregation、outputの3つのステージからなる分散クエリプランが出来上がります。
24. ここで重要なのは、SinkとExchangeです。 Exchangeは、他のworkerからデータをもらってきます。Sinkは、他のworkerにデータを受け渡します。このクエリだと、2回のデータ通信が発生します。 SinkとExchangeのペアで区切られた部分をStageと呼びます。つまりこのクエリは、3ステージからなる分散クエリになっています。 アグリゲーションは、複数のステージに分けて実行されます。
25. こうして作られたクエリプランは、Execution Plannerに渡されます。 Execution Plannerは、Node Managerからworkerの一覧を受け取り、実行計画を立てます。 分散実行可能なステージをworkerの台数分、または設定された数だけ分割して、タスクとします。 例えば2台のworkerが存在するとすれば、1ステージ2タスクになります。
26. タスクは、1つか複数のsplitを持っています。 テーブルスキャンを含むタスクは複数のsplit、その他のタスクは1つのsplitです。このsplitが、スレッドに割り当てられて実際に実行されます。つまり、1ステージごとに、1workerごとに1タスクずつ割り当てられ、そのworkerの中ではsplitがworkerの上で並列実行されるわけです。だいたい掴んでいただけたでしょうか？