モダンな SQL つき OLAP 実装の輪郭を眺めるちょろい方法はないかと Impala の paper を読む。

AST から plan をつくって, そいつを色々 rewrite してから実行する。そういえばそんなものだった気がする。AST と plan が別なのは、AST にごてごて色々つけてく一般的なインタプリタと違う。VM のバイトコードといえばそうかもしらんが。そして MapReduce, Spark, Pandas などを通ってから見ると SQL の実行計画ってまったくもってデータフローだね。Hive みたいのを作りたくなる気持ちが今更わかった。

そのほか気になった点: 実行ノード間では tuple をやりとりする。columnar storage でも中間状態は tuple らしい。ただし将来的に materialize したい時は in memory columnar format にしたいと言っている。これは good news のような bad news のようなかんじ。そしてどういう時に materialize が必要なのか自分はわかってない。式の評価に LLVM をつかう。SparkSQL が bytecode generation でやっているところを LLVM でやる。どのくらいの粒度でコード生成してるのかね。書き方から判断するに tuple を渡して評価するくらいの規模に見えるけれど。まあ toyql は interpreter でよい気がする。

更に雑多なメモ: 標準フォーマットは Parquet. Parquet は Twitter と Cloudera の共同開発だったのか。nested/repeated はこの論文の時点ではサポートしていない。Parquet の意味なくね? そういえば Dremel paper は nested/repeated の話で半分くらい紙面を使っていた気がする。Impala paper はそれがないおかげでシステムの全体像にページが割かれており自分の目的には都合がよあかったとも言える。

システムとしては、実行計画をつくる coordinator と評価をする executor という分け方をする。MapReduce とかと同じ。インプロセスでもこういう切り口にするのがいいのかね。わからん。

ちょろく輪郭を冷やかすという目的には良い paper だった。