ggsql: SQLのためのグラフィックス文法

20日前原文(opensource.posit.co)

概要

ggsql はSQL構文ベースの グラフィックス文法 を実装した新しい可視化ツール。 Quarto や Jupyter などで利用可能、SQLユーザー向けの直感的な可視化体験を提供。 VISUALIZE/DRAW/PLACE/SCALE/LABEL などの宣言的な構文で柔軟にグラフ作成。 SQLクエリと可視化クエリを シームレスに連携 可能。 構造化・拡張性・再現性 に優れる点が特徴。

ggsqlのαリリース発表

ggsql はSQL構文でグラフィックス文法を実装した可視化ツール
Quarto、Jupyter notebooks、Positron、VS Code などで利用可能
SQLユーザーが直感的に扱える 宣言的・構造的な可視化構文 を提供
VISUALIZE 句でデータと視覚要素のマッピングを開始
DRAW 句でグラフレイヤーを追加、 PLACE 句で注釈やテキストを配置
SCALE 句で色や軸などのスケール変換を管理
LABEL 句でタイトルや軸ラベルなどのテキストを設定
SQLクエリの結果を直接可視化クエリに流用可能、 データ加工から可視化まで一貫操作
拡張性と再利用性 に優れる構文設計
コードが 自己記述的 であり、将来的なAI支援にも親和性

基本的な使用例

散布図 の作成例（penguinsデータセット使用）
- VISUALIZE bill_len AS x, bill_dep AS y FROM ggsql:penguins DRAW point
色分け の追加
- VISUALIZE bill_len AS x, bill_dep AS y, species AS color FROM ggsql:penguins DRAW point
回帰線レイヤー の追加
- DRAW smoothを追加することで、種ごとの回帰線を重ね描き
棒グラフ への切り替えもマッピング変更のみで対応
- VISUALIZE island AS x, species AS color FROM ggsql:penguins DRAW bar

完全な例と構文解説

SQLクエリと可視化クエリを 1つのスクリプトで連結
- SQL部分：データ抽出・加工
- VISUALIZE以降：可視化設定
DRAW でヒストグラムや点・線など複数レイヤーを追加
PLACE で平均値ラインや注釈テキストを配置
SCALE で色や軸の変換・パレット指定
LABEL でタイトルやサブタイトル、軸ラベルを指定
各レイヤーは 複数の要素 を一括で描画可能
データが整形済みの場合は VISUALIZE句のみ でも可視化可能

構造的・自己記述的な可視化の利点

コードの 可読性・再現性・拡張性 が高い
ggplot2 と同様の構造で、長期的な進化やLLMとの親和性も高い
レイヤーやマッピングの 追加・変更・削除が容易
例：箱ひげ図からジッター付き散布図、バイオリンプロットへの切り替えも 構文の差分のみ

ggsql開発の動機

SQLユーザー がデータ可視化を直感的に行える環境の整備
SQLとグラフィックス文法の 相性の良さ を活かした設計
RやPythonを使わずに 強力なコードベース可視化 を実現
LLM（大規模言語モデル）との連携を見据えた 宣言的構文
ggplot2の18年にわたる知見を 新しい基盤 に応用

SQLユーザーへのアプローチ

SQLのみで分析を行うユーザー層向けの 新しい可視化体験
データをエクスポートせずに 一貫した分析・可視化フロー を実現
GUIベースBIツールの 再現性の低さ や既存SQL可視化ツールの 機能不足 を解消
Quarto などコードベースのレポート生成・共有エコシステムへの橋渡し

宣言的データ加工・宣言的可視化

SQLは 宣言的・構造的なデータ操作 言語
グラフィックス文法も 宣言的・モジュラー構造 が特徴
両者の親和性を活かし、 強力かつ直感的な可視化ツール を提供

このように、 ggsql はSQLユーザーのための 新しい可視化体験 を提供し、 構造化・拡張性・再現性 に優れたコードベースの可視化を実現します。

Hackerたちの意見

もしかしたら速く読みすぎたかもしれないけど、ブログやウェブサイトのドキュメントには、これがSQLデータベースとどう関係しているのかの明確な説明が見当たらなかった。なんとなく、データベースで動くわけじゃなくて、フロントエンドのチャートライブラリが扱う可視化用のSQLライクな構文なんじゃないかと思ってた。それがhttps://ggsql.org/get_started/anatomy.htmlに書かれている内容みたい。でも、https://ggsql.org/faq.htmlには「VISUALISE句の中でSQLクエリを使えますか？」というセクションがあって、「構文の一部は直接データベースに渡されます」と書いてある。ホームページには「ggsqlはあなたのデータベースと直接インターフェースします」とあるけど、それがどうやって実現されるのかは示されていないように思う。混乱してる。

└

そう、これが私の質問でもあった。外部データベースサーバーからグラフを生成するための全ての接続や依存関係を示す例があればすごく助かる。

└

それは確かにそうだね。ちょっと特別な概念だし。ggsqlは、希望すればデータベースのバックエンドと直接接続する（メモリ内のDuckDBバックエンドでも動かせる）。あなたの視覚的クエリは、可視化の各レイヤーに対してSQLクエリに変換され、その結果のテーブルが描画に使われる。例えば、"VISUALISE page_views AS x FROM visits DRAW smooth"は、データに対してスムージングカーネルを計算するSQLクエリを生成し、その結果としてポイントを返す。それらのポイントが最終的な折れ線グラフを作成するのに使われるんだ。

└

ggsqlには「リーダー」という概念があって、これはggsqlがSQLデータベースと接続する方法だと考えられる。データベースへの接続を管理し、そのデータベースに合ったSQLの方言を生成する。今のところ、アルファ版としてはduckdb、sqlite、実験的なODBCリーダーのいくつかだけをサポートしてる。主にローカルファイルでduckdbを操作することに開発を集中しているけど、duckdbには他のタイプのデータベースと通信するための拡張もある。ggsqlはあなたの可視化クエリを受け取り、データベースで実行するためのSQLクエリを生成する。リーダーを使ってこれらのクエリを送信し、返されたデータで可視化を構築する。これが、非常に多くの行のデータからヒストグラムを描く方法なんだ。ヒストグラムを生成するために必要な統計がSQLクエリに変換され、正しい高さのバーを描くために必要なポイントだけが返される。デフォルトでは、ggsqlはメモリ内のduckDBデータベースに接続する。CLIを使っている場合は、--reader引数を使ってディスク上のファイルやODBC URIに接続できる。Positronを使うと、専用の「接続」ペインを通じてこれをもう少し簡単に行えるし、ggsqlのJupyterカーネルには特定のリーダーを設定するためのマジックSQLコメントがある。これらの外部ツールとのggsqlの使い方について、ドキュメントで少し詳しく説明する予定だよ。

└

SQLデータベース... "SQL"と"データベース"は別物だよ。SQLはデータ操作のための宣言型言語なんだ。データベースをクエリするためにSQLを使うことはできるけど、データベース自体には特別なことはない。フラットファイルやデータストリーム、プログラムのメモリ内のデータなど、他の非データベースソースをクエリするためにSQLを書くこともできる。逆に、SQLなしでデータベースをクエリすることもできるよ。

レイヤーアプローチが好きだな。これで他のSQL/ビジュアルハイブリッドで基本的なチャートを超えた時の問題が解決できる。

近い将来、ここに書かれているggplot2依存のパッケージ（https://exts.ggplot2.tidyverse.org/gallery/）が統合される予定はあるのかな？もしどこかで既に言及されていたらごめん。

└

ggplot2コミュニティが開発した様々なニッチなジオムがすぐに手に入るとは思えないな。これはggplot2を超えるためのものじゃなくて、ggplot2ができることの多くと、できないことのいくつかを実現する別のアプローチを提供するためのものだよ。でも、ggplot2は今後何年も多くのタスクにおいてより強力であり続けると思う。

この記事をざっと読んで、なぜこれが必要なのか、どんな問題を解決するのかの説明が見つからなかった。要するに、リモートのSQLデータベースのテーブルに対して直接可視化を要求できるようにしたいってことなのかな？それとも、まずデータをRのデータフレームに引き込んでからggplotを実行する必要があるの？でも、なんで新しいSQLライクな言語を作る必要があるの？既にRとSQLの間を翻訳するdbplyrというパッケージがあるのに。ggplotをdbplyrのtblオブジェクトをサポートするように拡張して、ggplotがSQLを生成する方が直接的じゃない？それとも、SQLが書くのにすごく優れた言語だから、多くの人がこのSQLライクな言語でggplotを作ることにワクワクするってこと？追記：ああ、ほとんど全てのドキュメントを見た後、やっと理解できた。これはDuckDBとSQLiteのバックエンドを持つSQLライクなAPIのスタンドアロン可視化アプリで、Vegaliteでプロットを描画するんだ。将来的にはもっと多くのバックエンドやレンダラーをサポートする予定らしい。下のコメントでも言われているように、PythonやRを知らないSQL専門家が可視化を作るのを助けるためのものなんだね。

└

これはPythonやRを知らないSQLユーザー向けみたいだね。

└

これを読んだとき、すごくワクワクしたんだ。だから、なぜ私にとって興味深いのか説明できるかも。ただ、発表の仕方はもう少し良くできたと思うけどね。私の経験では、データフィールドが共有している唯一のものはSQL（アナリスト、科学者、エンジニア）だよ。君が言ったように、Rでも同じことができるけど、君のプロジェクトがRやPythonで書かれているとは限らないし、SQLデータベースとデータにアクセスするためのエンジンを使っている可能性が高い。あと、marimoノートブックを使って分析してるんだけど、バックグラウンドのduckdbを使ってSQLセルを書くのがすごく簡単なんだ。だから、SQLから直接プロットできたら最高だよ。最後に、Pythonのプロット用APIは覚えるのが本当に難しいと思う。matplotlibでのシンプルな散布図を作るのに必要なボイラープレートの量は馬鹿げてるよ、LLMを使ってもね。だから、統一されたクエリ言語の中で統一された文法があったらかなりクールだと思う。

└

これはggplot（または特定のライブラリ）についてというより、グラフィックスの文法を使ったSQLの一種についてなんだ: https://en.wikipedia.org/wiki/Wilkinson%27s_Grammar_of_Graph... 面白いのは、インターフェース（SQL）と形式主義（GoG）が組み合わさっているところだよ。実際の視覚化やランタイムは実装の詳細（重要だけどね）なんだ。

これは面白いね。でも、文法をサポートしていない環境でもうまく機能する方法があればいいなと思う。私は似たようなアプローチを考えたんだけど（SQL内で、GoGに比べてかなり簡略化したもの）、それは劣化する（でも見た目は良くない）んだ: https://sqlnb.com/spec

└

"コンテキストで劣化する"ってどういう意味かよくわからないんだけど、もう少し詳しく教えてもらえる？

これは素晴らしい！私たちもGFQL（オープンソースのグラフデータフレームクエリ言語）について似たような結論に達したんだ。特にコードサンドボックスを必要とせずに、視覚化と分析スタックにLLMフレンドリーなインターフェースが必要だったからね。基本的な拡張を加えることで、かなりリッチなGPUビジュアル分析パイプラインができることに気づいたよ。タブularな世界のためにSQLを使うのは、同じ理由で理にかなってる！GFQLバージョン（OpenCypher）について、データの読み込み、整形、アルゴリズムの強化、視覚的エンコーディング、ファーストクラスのパイプラインの例を挙げると: - 全体のパイプライン: https://pygraphistry.readthedocs.io/en/latest/gfql/benchmark... - 宣言的な視覚エンコーディングをシンプルな呼び出しで: https://pygraphistry.readthedocs.io/en/latest/gfql/builtin_c...

ずいぶん昔のことだけど、UberでほとんどのRツールを作って、実際にR DBツールの上にこれとほぼ同じものを実装したんだ。みんな、振り返ってみれば正しかったと思うけど、私が見せたときはほとんど役に立たないと思ってた。データを引っ張って瞬時に可視化する良い方法になると思ってたけど、実際にはそんなに価値があることはなかったんだよね。

これめっちゃクールだね、すぐに試してみる！自分がハマったのは、以下の部分からなんだよね：

「私たちは、すでに慣れ親しんでいるSQLの構文に近い文法を保つことで、学習曲線をできるだけ簡単にしようとしました。最初は、欲しいデータを取得するためのクラシックなSELECT文から始まります。それから、VISUALIZE（またはVISUALISE）を使って、データのテーブルを作成するのから、そのデータのプロットを作成することに切り替えます。次に、データの列を位置、色、形などの美的要素にマッピングするレイヤーをDRAWします。それから、プロットを読みやすくするために、データと視覚的特性の間のマッピングであるSCALEを調整します。最後に、データのサブセット間での関係の違いを示すためにプロットをFACETし、他の人にプロットを説明するためにLABELを追加して仕上げます。これにより、SQLクエリを設計するのと同じ構造的思考を使ってグラフィックスを作成できます。」

まず、ggsqlはめっちゃかっこいいね。早く試したい！フィードバックとして、ggsqlのドキュメントに欠けてる点があるんだけど、出力の可能性についての言及が見当たらないんだ。PDFでグラフィックを出力できる？SVGやPNGでも？出力の寸法（例えば、幅=8.5インチ、高さ=11インチ）をどうやってコントロールするの？ドキュメントのPythonライブラリの例コードで見つけたのは、これくらいの数行だけだった：

Display or save chart.display()

In Jupyter chart.save("chart.html")

Save to file

じゃあ、これを例えばgrafanaの上に乗せられるの？

ハクソク