SQLでグラフを自在に操る！データ可視化の新言語「ggsql」が登場

SQLだけでグラフの文法（Grammar of Graphics）を定義できる画期的なライブラリ「ggsql」が公開されました。複雑なクエリを書くことなく、直感的な構文で柔軟なデータ可視化を実現します。データ分析のワークフローを劇的に効率化したいエンジニア必見のツールです。

読み飛ばしちゃっただけかもしれないけど、ブログ記事やドキュメントを読んでもSQLデータベースとどう関連しているのかがよく分からない。データベース上で動くわけじゃなくて、フロントエンドのチャートライブラリで処理するための可視化用DSL（ドメイン固有言語）をSQLっぽい構文で書くものだと思ってたんだけど。anatomy.htmlを見ると確かにそう見える。でもFAQには「VISUALISE句の中でSQLクエリを使えるか？」という項目があって「構文の一部は直接データベースに渡される」って書いてある。ホームページには「ggsqlはデータベースと直接インターフェースする」ってあるし、結局どうなってるのかが見当たらない。混乱するなあ。

このレイヤー構成のアプローチはいいですね。基本的なチャートから一歩進んだものを作るときに、他のSQLと可視化のハイブリッドツールで苦労していた問題がこれで解決しそうです。

近い将来、あるいは遠い未来でもいいんだけど、ここにあるggplot2依存の拡張パッケージ群を統合する予定ってあるのかな？もしどこかに書いてあったらごめん。

なぜこれが必要なのか、どんな問題を解決するのかを知りたくて記事をざっと読んでみたけど、納得できる答えが見つからなかった。Rのデータフレームにデータを取り込んでからggplotを動かすんじゃなくて、リモートのSQLデータベースのテーブルに対して直接可視化クエリを投げられるようにしたいってこと？でも、わざわざ新しいSQLっぽい言語を作る必要ある？RとSQLの間を変換するdbplyrっていうパッケージがすでにあるし、ggplotを拡張してdbplyrのtblオブジェクトをサポートさせて、ggplotがSQLを生成するようにした方が手っ取り早いんじゃない？それとも、SQLは書くのに優れた言語だから、多くの人がこのSQLっぽい言語でggplotできることを喜ぶっていう考え？追記：ドキュメントを一通り読んでようやく分かった。これはDuckDBとSQLite用のバックエンドを持ち、Vegaliteでプロットを描画する「スタンドアロン」の可視化アプリなんだね。今後バックエンドやレンダラーを増やしていく予定みたい。下のコメントにもある通り、PythonやRを知らないSQLスペシャリストが可視化できるようにするのが目的なのか。

面白いね。ただ、この構文をサポートしていない環境でもうまくフォールバック（正常に機能低下）できるようにしてほしいな。自分も似たようなコンセプト（SQL内で完結させるアプローチ）を考えたことがあるけど、そっちはきれいに書けないんだよね。

これは最高。GFQL（OSSのグラフデータフレームクエリ言語）でも似たような結論に至ったよ。コードサンドボックスを必要とせずに、LLMフレンドリーな可視化と分析スタックへのインターフェースが欲しかったんだ。openCypherを少し拡張するだけで、かなり高度なGPU可視化分析パイプラインを作れることに気づいた。テーブルデータの世界でSQLを使うのも、同じ理由ですごく理にかなってる！

すごく良さそう。近いうちに試してみる！個人的に「あ、そういうことか」と納得できたのは、ドキュメントのこの部分だったよ。「使い慣れたSQLの構文に寄せることで学習曲線を緩やかにした。まずSELECT文でデータを取得して、VISUALIZE（またはVISUALISE）でデータのテーブル化からプロット化に切り替える。次にDRAWでデータと見た目（位置や色、形などの美学的要素）をマッピングするレイヤーを追加する。そしてSCALEでデータと見た目の対応を調整して読みやすくし、FACETでデータのサブセットごとの関係性を比較する。最後にLABELを追加して完成。SQLを書くときと同じ構造的な思考でグラフを作れるようになる」っていうね。

まず、ggsqlは最高にかっこいい。試すのが待ちきれない。フィードバックなんだけど、ドキュメントに肝心なことが書いてない気がする。PDF、SVG、PNGで出力できるの？あと、幅や高さといった出力サイズはどうやって指定するんだろう？Pythonライブラリのドキュメントにあったこのサンプルコードが唯一の手がかりかな。

素晴らしいプロジェクトだね。コンセプトがSQLと見事にマッチしているという点には完全に同意。Rで私がプロットを書くときも、前処理のWITHブロックを書いてから可視化に移る構造にしているから。ただ、ggplot2と比べてこのDSLを使うメリットが何なのかが正直よく分からないんだよね（「また別のDSLが増える」という問題が起きるだけのような）。ggplot2の代わりにこれを使うことで何が得られるんだろう？私がggplot2から離れる唯一の理由は、標準的じゃないことをやろうとしたときに、ggplotのエコシステムに既存のgeomがないと非常に難しいから。そういう「ちょっと違うこと」をするときは、適当なプリミティブな描画操作に落とし込んだ方が、ggplot用のラッパーを書くより遥かに楽なんだ。一般的な指定を関数にまとめるのさえ、パイプ演算子や+との相性次第で苦労するしね。

この系統だと、ダッシュボード全体を処理するためのSQLファーストなアプローチをとっている「Shaper」（DuckDB駆動）もあるよ。