Presto In TD
- TD API
- BI Tool HTTP
から、クエリを投げる。
- prestobase proxy
- node schedular(presto)
- resource group
Prestobase proxy
- JDBC/ODBCはいけていない
リプレイスするためのPrestobase Proxy
HTTP接続するときにPrestoが使える
Scalaで書かれている
- Finagle(RPC proxy)がコア
- Dockerコンテナ上で動いている
- Airframe
- VCR 軽量テストフレームワーク
Finagle
- 実績がある
- クライアント/サーバのインターフェイスが透過的に使える
- サービス提供側からするとドライバからもPresto側からも嬉しい
- プロトコルは問われない
詳細な使い方はドキュメントを見ること
Presto Clientで投げる
- DIしたかったがScalaでは良いツールがなかった
- なかったのでAirframeを作った
- オブジェクトの実装をbindする
- bindを呼び出すことでinjectされたオブジェクトが取れる
- オブジェクトの管理はsessionで行われている
- 良いこと オブジェクトのbindのときにScalaの型安全が保証されること、見た目が良いこと
VCR testing framework
- PrestoのテストをCIをやるとコンテナのメモリが足りなくて死ぬから軽量なのが欲しかった
- filter handler
- client→(prestobase+requestvcr)→sqlite
- CI上ではリプレイするだけなのでPrestoは建てなくても大丈夫
- Prestobase Proxyもいずれオープンソース化する
Node Scheudlar
- 分散のクエリ
- ユースケースが増えすぎる問題
- クエリ
- ステージと呼ばれる集まり
- 分散ワーカーにばらまくタスク(やることは一緒だが取ってくるデータは違う)
- タスクが増えるほど処理効率があがる
- ステージはフローで、ステージ1が終わらないとステージ2が進まない
- この処理(フロー)を制御するのがnode schedular
- 既存のNode Schedularはランダムに仕事を適当に割り振ってしまうので、忙しいワーカーにさらに割りふられることがある
- メモリを考慮したNode Schedularを開発
- e.g. memory pool
- 重たいタスクを使う
- メモリープールを意識したスケジューラ
Resource Group
- 0.147のPrestoから導入
- general group
- adhoc group
root group
最大いくつキューがあるか
- どのくらいのメモリが使えるか
子供の値は親の値から流用できる
maxqueued
- maxrunning
- softmemorylimit
- softcpulimit
- hardcpulimit
https://prestodb.io/docs/current/admin/resource-groups.html
- 投げられたクエリは1つ1つのリソースグループに属する
- リソースグループセレクター
- e.g. sourceにadhocが含まれていたらadhocグループに紐付ける
- resource group di
- Guice injectionを使ったDI
- resource groupの挙動を変えたいときは以下のクラスのメソッドを呼び出す
- ResourceGroupConfigurationManager#configure
- ResourceGroupSelector#match
- SelectionContext
− Authenticated
- User
- Source
- Query Priority
- 認証情報
- Currently available as default
- GuiceからDIで挙動を変更することができる
まとめ
- Prestobase Proxy
- 分散システムのコードをいじるのは大変なので、VCRやAirframeを使ってコードの修正をしやすくした
- タスクの量が増えてきたので、リソース管理を効率的に行うためのスケジューラを作った(experimental)
質疑
- メトリクスとしてはメモリープールを使うっていうのはやっている
- タスクのジョブはリトライされる
