• Vega-Lite: A Grammar of Interactive Graphics

Altair は vega-lite というのをつかっているらしいが、これと Vega の違いがよくわかっていなかったので元ネタの paper を読む。

Vega-lite も Vega もフォーマットが JSON である点は一緒。Vega が低レベルの表現なのに対し、Vega-lite はもうちょっと高位の表現を持ち、その高位の表現から Vega のデータを生成する。Vega-lite をみると、Altair は要するに Vega-lite の Python 表現なのだとわかる。

Vega にしろ Vega-lite にしろ、データを JSON につっこんで JS のライブラリに描画をさせるアプローチ。これによってホスト言語 (ex. Python) 非依存にできる。そして対話性を与えられる。

理論的には良さそうだが、実際には弱点もある。まずでかいデータに弱い。せっかく Pandas がでかいデータを持てるのに、それを JSON に変換すると効率性が失われる。実際データポイントの上限が 5000 個に制限されており、適当に 1000 ずつサンプリングしたヒストグラム用のデータを 6 個つなげるとエラーになったりする。というか昨日その問題にぶつかった。サンプル数を減らせばいいんだけど、そういう制限気にするのかったるいのだよ・・・。データポイントの上限にヒットしていないのに描画中に死ぬこともある。ipynb も無駄にでかくなる。PNG を保存したい場合は Selenium 使ってねとかアホなの？（実際は右クリックで "save image" することもできるが。)更にこの裏返しとして、遅い。

対価として得られるはずの対話性: コードを書いてる身からすると図の上での対話性とか別にいらないのだよね。コードをいじって再描画すればいいので。図の上での対話性は、たとえば The Upshot や Distill などの data journalism みたいな文脈で意味があるのは理解している。D3 とかをやってた研究室発なのでそういう対話的可視化に注力しているのもわかる。でも自分には必要ないし、そのためのコストが生産性に跳ね返ってくるのが厳しい。

一方でブレイクダウンをいい感じにやってくれる高位表現というアイデアの力は、Altair をさわっているとたしかに伝わってくる。こういう気の利いた API を Python ネイティブでバリっと実装したライブラリがほしいなあ。

Python native の気の利いた API というと Seaborn があるわけだが、一旦 Altair をみたあと Seaborn をみるとしょぼい。Altair/Vega-Lite の uniformity は、冗長性はいまいちだけど納得感がある。Seaborn はそれと比べるとだいぶ ad-hoc である。というわけで自分が Seaborn を使うことはなさそう。

まあしばらくは DataFrame/Matplotlib と Altair の間を行ったり来たりします、というかまた SQL 仕事の機会がきたら考えます。

なお paper は Grammar-Based Visual Encoding の歴史を軽くおさらいしており、そこは勉強になった。The Grammar of Graphics はそのうち読みたいと思いつつ何年もたっているけれど、これが Tableau の言及になっていたとは知らなかった。

はー可視化とか一度くらい真面目に勉強してみたいもんだわ・・・。