Pinot: Enabling Real-time Analytics Applications

参考

Join on the fly
- ベーステーブルからクエリ実行のタイミングでデータ生成
Pre Join + Pre Aggregate
- 分析で必要となるテーブルをストリーム処理等で事前作成
- 事前処理はマスタデータのテーブルとの結合、など
Pre Join + Pre Aggregate + Pre Cube
- さらに分析で求められる結果データを予め作成、インデックス化
- 例えばAggregationしておく、など

レイテンシと柔軟性のトレードオフの関係：

LinkedIn以外の企業では、

あたりが利用しているようだ。 Uberは、自身の技術ブログでも触れていた。

Pinotは、原則としてPre Aggregation、Pre Cubeを前提とする仕組みなので、スキーマの定義が非常に重要。

またバッチとストリーム両方に対応しているので、それぞれデータ入力（Ingestion）を定義する。

データはセグメントに分けられ、サーバに分配される。

セグメントに基づき、Brokerによりルーティングされる。

ストリームから取り込んだデータとバッチで取り込んだデータは、共通のスキーマを用いることになる。

したがって、統一的にクエリできる？

Scan、Inverted Index、Sorted Index、Star-Tree Indexを併用可能。

比較対象として、Druidがよく挙げられているが、Sorted Index、Star-Tree Indexがポイント。

カラムナデータフォーマットを用いるのは前提。それに加え、Dictionary Encodeing、Bit Compressionを使ってデータ構造に基づいた圧縮を採用。

転置インデックスを作っておく、という定番手法。

予め、Dimensionに基づいてソートしておくことで、フィルタする際にスキャン量を減らしながら、かつデータアクセスを効率化。

すべてをCube化するとデータ保持のスペースが大量に必要になる。そこで部分的にCube化する。 ★要確認

Druidと簡易的に比較した結果が載っている。

まずは、レイテンシの小ささが求められるインタラクティブな分析における性能特徴：

ミリ秒単位での分析を取り扱うことに関してDruidと共通だが、各種インデックスのおかげか、Druidよりもパーセンタイルベースの比較でレイテンシが小さいとされている。

つづいて、あらかじめ定義されたクエリを大量にさばくユースケース：

レイテンシを小さく保ったまま、高いQPSを実現していることを示すグラフが載っている。この辺りは、工夫として載っていた各種インデックスを予め定義していることが強く効きそうだ。

続いて異常検知ユースケースの例：

データがSkewしていることが強調されているが、その意図はもう少し読み解く必要がありそう。 ★要確認