久しぶりにログを SQL で調べものをする仕事。二日くらいで終了。

昔にくらべ SQL は相変わらず下手くそだが Pandas/Matplotlib スキルが上がっており、それなりのチャートを Pandas だけで出せるようになってきた。結果として、二年前の "SQL 書くなら Altair 必須" という気分は消え去り、気がつくとぜんぶ Pandas で済ませている。たぶん当時は Pandas と Matplotlib を混ぜて使えなかった。今は Pandas の plot() が matplotlib の薄いラッパであるという事実を活用し、subplot したり axes 重ね書きしたりできるようになった。

とはいえもうちょっとモダンでシュッとしたライブラリを使えた方がいいんじゃね・・・という反省もあり、今回描いたチャートを一通り Altair に移植してみた。が ...mixed feeling. コードはすごいコンパクトかつ宣言的になるし、描かれるチャートもいいかんじ。でも自分の生産性がどれだけあがるかは微妙。

生産性を妨げる要素は、大きく分けて二つある。

ひとつ目は、自分のデータ力の低さ。Altair は入力の DataFrame が tidy data 的に正規化されていることを期待している。Altair が ggplot の追っかけである事実を考えると当たり前の帰結なんだけど、自分の手元のデータは必ずしも tidy でないので reshape しないといけない。でもデータの reshape とか素人には認知的負荷が高いのだよね。Pandas の API もわかんないし。今回のデータでいうと、ひとつ目のチャートは pandas.concat で複数の DataFrame を連結する必要があり、ふたつ目のチャートでは DataFrame.melt というので unpivot した。データの最終型がわかっていればこうした API を探す心の余裕もあるけど、実際の問題の中でごちゃごちゃやってる時には新しい API をみつける気力が無い気がする。同様に SQL も一段階がんばって書かないといけない。最終的に tidy な DataFrame をつくるための小細工とかを SQL に入れる必要があるので。でも SQL とかわかんないのだよ・・・。

一方で Pandas を生で使っていると適当に for 文を回しながらゴミのようなデータから手続き的に欲しい絵が出せるので、問題を考える mental bandwidth を浪費しない。たとえば一つの tidy DataFrame を使うかわりに、二つの単純な SQL のクエリから持ってきた二つの DataFrame を順番に使う、みたいなことができる。ただしコードはゴミ。

Hadley Wickham の Tidyverse がスパルタなデータサイエンティスト養成ギプスとして機能しているように Altair を tidy data 養成ギプスとして受け入れるのがあるべき姿なんだろうけど、自分なんて通りすがりで四半期に一回くらい SQL 書くだけなので、正直そこまでがんばりたくない。弱音吐いちゃう。

ふたつ目は Altair の API ergonomics。

Matlab あたりから延々と鍛え抜かれ磨かれた Pandas/Matplotlib の API は色々ダサいが、一方で使用頻度の高い機能がトップレベルの雑なキーワード引数でズバっと実現できるハフマン符号化的強さがある。しかももれなく SO の回答がある。たとえば outlier を適当に無視しつつレイテンシのグラフを書きたい時、Pandas なら df.plot(...., y='latency', ylim=(0, 10000)...) とかやればいいところで Altair は ....encode(..., y=alt.Y('latency', scale=alt.Scale(domain=(0, 10000), clamp=True)), ...) とか書かないといけない。気持ちはわかるがもうちょっとなんとかなんないんですかね・・・。Altair も所々にショートカットを揃えようという意思は感じるが、ベースの API がやや大げさな上にプロジェクトの若さゆえユーザビリティの苦情による API の圧縮が進んでおらず、上のようなかったるさにしばしば遭遇する。SO も頼りにならない。

Ergonomics 上の問題その二は、ベースにある Vega というオブジェクトモデルが言語非依存なせいで発生する冗長さ。Altair は自分自身がデータを dice and slice する仕組みを色々もっている。まあデータのブレイクダウンが必要なのである程度は仕方ないと思うんだけど、Pandas でやらせてくんないかなあ。一連の Data Transformation の仕組みなんて vega expression というナゾのミニ言語を使わされて、しらねーよという気分。ただし、いまドキュメントをみたら「できるなら Pandas 側でやりましょう。そのほうが便利です」と書いてあるのにきづいた。なんなの・・・。

Altair にせよ Vega にせよ ggplot と戦う気なだけあって色々よく考えられ、その結果としてよく練られた抽象がある。ドキュメントも割とよく書けてる。ただ裏を返すと大袈裟で、学習勾配がきつい。通りすがりのモバイルプログラマにはやや荷が重い。

がしかし！データワナビーとして我々は！背伸びをしてでもモダンなフリをキメるべきではないか！問題解決原理主義者に負けるな！

コードは短くなるしチャートはシュっとしているし DataFrame は Tidy になるし、良いことは良いんだよねー。まあ締め切りの厳しさと相談しつつぼちぼち使っていきたい所存。SQL 仕事だけじゃなく普段のベンチマークの結果整形とかにも使って体を慣らしていくのが良いかもしれない。

追記

Colab の local runtime ではちゃんと動かないことが判明しがっかり・・・。