- 1500 users
- 150000 queries
hosting prest as a serviceとしてのtreasure data
- aws(us-east)
- aws(tokyo)
- IDCF
- マルチテナンシークラスター
- S3 + PlazmaDB インデックスを貼ってファイルのスキャンを早くする試み
- storage format: MPC(message pack)
- 複数タイプのデータをカラムとして持つことができる(カラムの型をintからstringへカラムデータを変更することなく変換できる)
- 200B JVM memory per node
- 運用してみないとメモリの計算がわからないので、予め大きめのメモリを積んでおく
- メモリが枯渇してwaiting for memoryになると他のクエリが動かなくなる
- major GCが起きやすくなるため
- prestoは普通より遅いというクレーム
- 20%くらいしかTDのスケジューリングを使っていない
- 85%くらいはサードパーティツール的なものでスケジューリングされている
ServiceLevelObjectiveを捕まえないといけないかが課題
SLOはFAQとしてドキュメント化
- TDでスケジュールされたクエリは統計を見れる
- サードパーティでスケジュールされたクエリは確認しないといけない
- implicit SLOを決めている
- アプローチとしてのイベントドリブン
- prestoからクエリのログをfluentd経由でTDに流して解析している
- スキーマレスなので1回もテーブルを作り直したことがない
- 2億くらいのクエリログ
- queryのイベントログ
- テーブルスキャン
- split
- query
- 85%くらいのクエリがスケジューリングされている
- が、どんなクエリをどこから投げられているかが分からない
- 特定の構文を簡単な文字列に変換してわかりやすくする
- どんなクエリがどのくらい投げられているかを統計できる
- クエリのばらつきをCoV(coefficient of variation=MAD / median)
- Median absolute deviation
- SLO violation 違反していたらクエリの実行時間が多めにかかっているかどうかわかる
- 典型的なボトルネック
- S3にアクセスしすぎ
- シングルノード
- order by
- window
- シングルノードのオペレーションなのにcount distinct
- など
- Presto独自のリソースマネージャーを実装している
- クエリがソースを使いすぎるのを避けたい
- create split resource manager
- クエリがノードに使うリソースを制限する
- presto ops robot
- JMXでメトリックをdatadogに流して、アラートの出たノードに対して重いクエリのプロセスを殺すとかgraceful shutdownするなどする
- S3 Access Performance
- S3のGETは30ms-50msのレイテンシがある(低くない)
- S3から500が帰ってくること
- S3のレイテンシがボトルネックになりうる
- 独自のI/O manager なるたけ多くのリクエストをまとめて送る
- presto stella: plazma storage optimizer
- データがあとからやってくる 時差が発生する
- S3データのフラグメンテーションが起きる
- ファイルのマージにもS3が使われている
- ファイルの数はすごく重要
- new direction explored by presto
- DBA(required dataase administrator)からdata providerによるスキーマデザイン
- prestobase proxy: prestoにアクセスするためのプロキシ(Scalaのfinagleをベースに実装)
- たとえばprestoはユーザー認証の機能がない
- DIをふんだんに使ってる(airframe)
- セッションマネジメントを最初から入れている
- optimizing query results transfer in prestobase
- application/x-msgpack
- prestoを返すオブジェクトをmsgpackに入れる
- クエリ高速化が見込める
- modules
- prestobase-proxy
- prestobase-agent
- prestobase-vcr
- prestobase-codec
- prestobase-hq
- prestobase-counductor
- 一部はオープンソースにしてもいいかな
- bridging gaps between sql and programming language
- 既存のアプローチ ORM
- SQL Firstへ
- クエリを書いたらScalaのコード(case classとか関数とか)を自動生成してくれる
- xerial/sbt-sql
- パイプラインが壊れたことを検知しつつコードやクエリを書ける
課題
- 膨大なデータをどうやって処理するか
- インクリメンタルプロセッシング
- 解決するためのdigdag
- YAMLを書くだけでprestoのクエリのパイプラインを作っていくことができる
- インクリメンタルプロセッシング
- MessageFrame
- tabular data format
- layer-0
- 2つ以上に分ける
- カラムのメタデータを入れる
- layer-n
まとめ
- managing implicit SLOs
- Presto Fluentd TD Presto
- digdagなどで