Juliaのデータ処理パッケージを比較してみた DataFramedMeta・JuliaDB・Queryverse Part2

データフレームの定義

今回お題が2つあるという話を最初にしました。

今度は型の話をします。抜け忍の方はここでお帰りください。型はないでしょうという話をしたいんですけれども（笑）。すみません、Python、Rにも型はあるのは知ってます。大丈夫です。

型に関しては、そもそもデータフレームって何だっけっていうところから始めたいと思います。データフレームって何だっけって私も思ったときに、誰かがきれいに定義してくれてるとうれしいなと思って探したんですね。

TokyoRでHadley Wickhamが定義してくれてましたので、そちらを引用したいと思います。すみません、もう抜け忍とか言わないので許してください（笑）。

データフレームって何ってことなんですけど、まず1つ目にリストであること。このときのリストっていうのはそれぞれの列が1個の要素として存在するリストであるという意味です。

それぞれの要素に対してユニークな名前が付いていること。そしてそれぞれの要素がベクトルである。もちろんここではベクトルと言ってますけれども、別にリストでも構わないよと。まあRの話なので。

さらにWith equal NROWっていうのが、ここの長さ。今ここでは単純なベクトルだけを入れているんですけれども。例えばこの中身が複雑なマルチバリューなRestとかマトリクスが入ってても、とりあえず図で言うところの縦の長さに相当するNROWが一緒だったらいいよねと。

できれば行の、ここに1、2、3、4……っていう行の数字入れないほうがいいよねと。だってそれもデータじゃんということで言ってます。

この図で言うとっていうのが、例えば今で言うとこういうことですね。上のヘッダーの部分がUnique namesになっていて、それぞれ下の部分がVectorsとしてぶら下がっていると。たぶんこれはJuliaでも普通に自分でstructで作れるなぁというふうに思います。

じゃあList。あれ、リストってあったけな？　そんな柔軟なフワフワしたものはあんまないなと。Vector{Any}になるでしょう。

なぜここで取り上げたのかと言うと、先ほど紹介したDataFramesとJuliaDBの中身を見てみたいと思います。

DataFramesとJuliaDBの考え方

DataFramesはどういうふうに考えているのかというのがこちらになってます。

すみません、小さくて申し訳ないんですけれども。図だけで説明すると、DataFramesはヘッダーとcolumnsと分けていて。ヘッダー自体はさっき見せたSymbolで選択できるような仕組みになっています。

columnsのほうにはAbstractVectorのVectorになっているので、1個1個がVector{AbstractVector}に属するものが入っていれば、データフレームはオーケーだよとDataFramesパッケージでは定義されています。

かたやJuliaDB、JuliaDBの中ではIndexedTablesというのが中でさらに定義を行っていて。タイプとしてはNextTableという名前になっています。

これはどういう思想で作っているかと言うと、むしろさっきのListの発想に近いようなイメージになっています。

これ細かくなっちゃって省略しちゃったんですが、Cっていうcolumnsに属するなにかがあって、1個1個をまず先に分けます。そのうえでなにかしらのプライマリーキーになるようなものをそれらに付与していくというようなかたちになっていて発想が違うんですね。

ここ（DataFrames）は頭と体で分けているというイメージで。こっち（Queryverse）は列ごとに分けているというような構成になっています。

互換性を生み出すパッケージ

じゃあそれでなにが困るのかと言うと、RとかPythonみたいに1個でもなにか支配的になっているパッケージならいいんですけど、Juliaはまだ発展途上なんで、こういうふうに乱立されちゃうとけっこう困りますよねという話をしたいんです。

こういうふうに似てるんだけれどもデータ構造は違うというのは苦痛じゃないでしょうか。別にデータフレームに限らず。困ったなぁ、困ったなぁというところに対してちゃんと解決策はあります。

実はテーブルっぽいものをインターフェースとしてTabletraitsとIterableTablesというパッケージがあります。インターフェースのみをほとんど定義しているやつなんですけれども。これ実はQueryverseを作っている人が作ってます。

これに則っておけばとりあえずは全部互換性みたいなものを作れるよね、というような芯になっているので。今回のプレゼンで覚えていただくとすれば、この2つだけ覚えて帰ってもらって、みなさんがもし自作でデータフレームを作って天下を取りに行くという方がいれば、ぜひちょっとこのインターフェースは守っていただきたいなと思っております。

Table=NamedTuple

Tabletraitsは何を言っているかと言うと、「TableはNamedTupleだ」と言ってるだけです。

NamedTupleって何でしたっけ？　これも0.7以降から追加された型になっていて、Coreに入ってます。

タプルなんだけれども名前が付いている。名前で呼び出すことができる。シンボルでも呼び出せる。keys()でシンボルの中のタプルを呼び出せる単純なものです。

これをさっきのDataFramesで見てみるとどうなるか。1個1個がタプルと考えると、さっきのJuliaDBみたいにリストの感覚ですね。

1個1個の縦の列で存在しますと。NamedTupleなので名前を付けることが強制されています。これが本当に基礎の基礎の構造であるとTabletraitsは言っているわけですね。

ではIterableTablesは何をしているかと言うと、やや実装のほうまで踏み込んだ話になってまして。

これは何ができるのかと言うと、現在Tabletraitsにほどほど乗っかっていればIterableTablesが変換するような基盤を提供しますということをやっています。

実際どういうことができるのかと言うと、最初にDataFramesパッケージからDataFrame()で名前とRankっていう列を持ったデータフレームを作ります。Julia39位、Python3位、R14位ってやつなんですけれども。

さっきデータフレームはJuliaのテーブルとはちょっと違うって話をしたんですけれども、tableっていうのがJuliaのさっきのデータフレームに簡単に変換することができて、またさらにそれをデータフレームに戻すことができています。

なのでとりあえずTabletraitsに乗っかっておいて、IterableTablesにも乗っかっておけば、オレオレデータフレームを作ってもまあ受け入れられるし、変換できるしというようなことになっています。

何が最適なのか？

最初の話に戻ります。Juliaのペアとしては何が最適なのかというところから始まりましたが。この3つという話で話を進めていましたが今のTabletraitsとIterableTablesの話を考えると、イメージとしてはこういうことになるんじゃないでしょうか。

TabletraitsとIterableTablesに乗っかっているようなものであれば、どれでもいいよと。and moreと書きました。実はこの3つ以外にもけっこう人気なパッケージがあって。

例えば、時系列のデータのみを取り扱いたいような、ニッチと言ったらあれですけど、特殊な用途のデータフレームもあります。そういったものも、このTabletraitsに乗っかっておけばとりあえず大丈夫と。

ここではDataFramesMetaとQueryっていうQueryverseの一部の機能なんですけど、これを分けたのは何かと言うとですね。QueryはTabletraitsとIterableTablesに乗っかっているものだったら任せなさい、面倒みますというふうに、だいたい最初にお見せしたパイプ処理がこれでできるようになっています。

なのでQueryはQueryverseのものだけではなくて、実はDataFramesもJuliaDBもこのQueryに流してやると同様の変形ができます。

Juliaでデータ分析パッケージを開発される方に覚えておいていただきたいのが、JuliaにはDataFramesの構造とそれの実際の処理、Queryを流したりする処理というのを別に分けて考えることができるようなロードが敷いてあるということです。

ぜひみなさま、ここにいる方々は優秀なJulia忍者であると思っておりますので（笑）。データフレームを開発する際にぜひご参考にしていただければ幸いです。以上で発表を終わります。

（会場拍手）

可視化における優秀なパッケージ

司会者：なにか質問などある方いらっしゃいますでしょうか？　

（会場挙手）

質問者1：私、抜け忍なのでRでデータ分析やってたんですけれども。その際だとggplot2みたいな優秀な描画パッケージとかあったと思うんですけど。本件に関して適当な可視化がしたいときに優秀なパッケージなどご存じでしたらご教授願いたいと思います。

ki_chi：普通のJuliaで数値計算している方が使ってるようなプロットでもぜんぜん構わないんですが、よくこれと同じ文脈で出てくるので、Queryverseの中に入っているVegaLiteってやつがすごくて。これは単純にプロットみたいなイメージで使える簡単なものになってます。

もう1個、「DataVoyager」があって、これはもう少し可視化に特化した、たぶんTypeScriptかなんかで書かれたものを立ち上げてくるような仕組みになってまして。

立ち上げた瞬間にだいたい散布図とかヒストグラムが全部まとまって、しかもインタラクティブに操作できるようなものが立ち上がってくるような仕組みになっています。

なので全部Juliaでできているというわけではないんですけれども、一応こうした可視化ツールを使うと、そのままそれこそggplotみたいにパイプでこいつらを直接流してデータで表示するということはできます。たぶんバックエンドはElectronかなんかだったような気がします。

質問者1：ありがとうございます。

他の言語との比較

質問者2：もし試されてたらでいいんですけど、ほかの言語との速度面での優位性や今回紹介されたJulia内での速度面での比較はやられていたら教えてください。

ki_chi：みなさんに不都合な真実をお知らせいたします。

（会場笑）

ki_chi：データ分析ではトライアンドエラーで毎回書き換えて処理を実行するということが多いです。Jupyterみたいに。そのときJuliaはやっぱりJITコンパイラで最初にコンパイルしてから実行するので体感は遅いです。PythonやRに比べると（笑）。

ただ1回コードを組んでしまって、それを大量に回すみたいな用途だと、計ってはいないんですが圧倒的に早いと思います。

質問者3：今のに付随しておうかがいしたんですけれども。速度面よりかメモリの効率性って、とくにでっかいデータを扱う方々って気になると思うんですけれども。そこって体感的にざっくりどう優位性があるのか。ほかの言語と比べてどううれしいのかっていう。

とくにRだったら文字列型ってFactorにして扱って、けっこうメモリー効率いいなとかっていうのあるじゃないですか。そこらへんのところを聞けるとすごくうれしいです。

ki_chi：ちゃんと測ってないのでそこ自体はわからないんですけれども。たぶんRもPythonも、tidyverseやPandasはC++やCythonで書かれていて、十分メモリ管理きつくやってるので、正直、現状でJuliaがその点でアドバンテージがあるかと言うとそこは難しいと思ってます。

質問者3：ありがとうございます。

bicycle1885：もし1つくらいなにかある方いらっしゃいましたら。よろしいですか？　ではki_chiさんありがとうございました。

（会場拍手）