ggsql - Eine grafische Grammatik für SQL

 (opensource.posit.co)
11 Punkte von GN⁺ 9 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Visualisierungstool auf Basis der SQL-Syntax, das Datenabfrage und Diagrammerstellung in einem Ablauf verbindet – über Klauseln wie VISUALIZE, DRAW, PLACE, SCALE und LABEL
  • Spalten lassen sich visuellen Eigenschaften zuordnen, und durch kombinierbare Layer können Streudiagramme, Balkendiagramme, Histogramme, Boxplots und Annotationen innerhalb derselben Struktur erstellt werden
  • SQL-Abfrageergebnisse werden direkt als Eingabe für Visualisierungen verwendet; einige Layer holen Aggregationen sogar über eine einzige SQL-Abfrage, was für große Datenmengen vorteilhaft ist
  • Ausgelegt als kleine, fokussierte ausführbare Datei, die ohne R- oder Python-Runtime nutzbar ist und sich daher gut in codebasierte Reporting-Tools und KI-Analyseassistenten integrieren lässt
  • Die aktuelle Version ist ein alpha-release; geplant sind Erweiterungen wie ein High-Performance-Writer, Themes, Interaktivität, ein Language Server, ein Formatter und Unterstützung für räumliche Daten

Einführung in ggsql

  • ggsql ist eine Implementierung der grammar of graphics auf Basis der SQL-Syntax und erweitert SQL um strukturierte Visualisierungsfunktionen
    • Nutzbar in Quarto, Jupyter notebooks, Positron, VS Code und mehr
  • Es wurde so entworfen, dass SQL-Nutzer Visualisierungscode auf vertraute Weise schreiben können
    • Die deklarative und kombinierbare Struktur von SQL-Klauseln wird auch auf die Visualisierungssprache angewendet
  • Der Beitrag entfaltet die Kernsprache von ggsql zusammen mit Motivation und Anwendungsbeispielen

Grundlegende Beispiele

  • Erster Plot

    • Mit dem eingebauten Datensatz penguins lässt sich ein Streudiagramm erstellen
      • VISUALIZE bill_len AS x, bill_dep AS y FROM ggsql:penguins
      • DRAW point
    • In VISUALIZE werden Datenspalten auf visuelle Eigenschaften gemappt, und DRAW point erzeugt auf Basis dieses Standard-Mappings einen Punkt-Layer
    • Durch das bloße Hinzufügen von species AS color lässt sich eine Farbgruppierung nach Kategorien anwenden
      • VISUALIZE bill_len AS x, bill_dep AS y, species AS color FROM ggsql:penguins
      • DRAW point
    • Mit zusätzlichem DRAW smooth kann über dem Punkt-Layer ein Regressionslinien-Layer ergänzt werden
      • Das Farb-Mapping nach Arten bleibt erhalten, sodass für jede species eine eigene Linie erzeugt wird
    • Statt vordefinierter Plot-Typen verfolgt ggsql einen modularen Ansatz aus kombinierbaren Komponenten
    • Bei gleicher Grundstruktur kann man zu einer völlig anderen Visualisierung wechseln
      • VISUALIZE island AS x, species AS color FROM ggsql:penguins
      • DRAW bar

  • Vollständiges Beispiel

    • Der obere Teil ist eine normale SQL-Abfrage, ab VISUALIZE beginnt die Visualisierungsabfrage
      • Im Beispiel wird DuckDB als Backend verwendet
    • Im SQL-Teil werden ROW_NUMBER() und QUALIFY verwendet, um aus astronauts.parquet nur die jeweils jüngste Mission pro Name zu behalten
    • Danach werden zwei Mengen zusammengeführt
      • year_of_selection - year_of_birth wird als age berechnet und mit der Kategorie Age at selection versehen
      • year_of_mission - year_of_birth wird als age berechnet und mit der Kategorie Age at mission versehen
      • Beide Ergebnisse werden mit UNION ALL zusammengeführt
    • In der Visualisierungsabfrage werden age AS x und category AS fill gemappt und anschließend DRAW histogram verwendet
      • Mit SETTING binwidth => 1, position => 'identity'
    • Mit PLACE rule wird eine Annotation mit vorab berechneten Mittelwert-Positionen hinzugefügt
      • x => (34, 44), linetype => 'dotted'
    • Mit PLACE text wird eine Text-Annotation ergänzt
      • x => (34, 44, 60)
      • y => (66, 49, 20)
      • Die Labels enthalten Mean age at selection = 34, Mean age at mission = 44, John Glenn was 77 on his last mission - the oldest person to travel in space!
      • Mit hjust => 'left', vjust => 'top', offset => (10, 0)
    • SCALE fill TO accent wandelt die auf fill gemappten Werte in die Farbpalette accent um
    • Über die Klausel LABEL werden Titel, Untertitel, x-Achsenbeschriftung und Legendenlabel gesteuert
      • Titel How old are astronauts on their most recent mission?
      • Untertitel Age of astronauts when they were selected and when they were sent on their mission
      • x-Achse Age of astronaut (years)
      • fill => null

Aufbau einer Visualisierungsabfrage

  • Vor VISUALIZE steht reines SQL; die Ergebnistabelle wird nicht als Tabelle ausgegeben, sondern direkt an die Visualisierung übergeben
  • Im SQL-Teil erzeugte Tabellen oder CTEs können in der Visualisierungsabfrage referenziert werden
  • Wenn die Daten bereits in einer für die Visualisierung geeigneten Form vorliegen, kann der SQL-Teil entfallen
    • VISUALIZE year_of_selection AS x, year_of_mission AS y FROM 'astronauts.parquet'
  • VISUALIZE oder VISUALISE markiert das Ende der SQL-Abfrage und den Beginn der Visualisierungsabfrage
  • Das Mapping verknüpft Spalten mit visuellen Eigenschaften, also aesthetics
    • Im Beispiel entspricht age der Position auf der x-Achse, category der Füllfarbe
  • DRAW fügt der Visualisierung Layer hinzu
    • Es gibt einfache Typen wie point, aber auch Typen wie histogram, die Berechnungen für gebündelte Aggregationen benötigen
    • Layer werden in der definierten Reihenfolge gerendert
  • PLACE ist eine Schwesterklausel zu DRAW und dient ausschließlich Annotationen, die statt Tabellendaten Literalwerte verwenden
    • Die Beispielvisualisierung besteht aus drei Layern: einem Histogramm-Layer, einem Annotation-Layer mit Hilfslinien und einem Annotation-Layer mit Text
    • Ein einzelner Layer muss nicht genau einem grafischen Objekt entsprechen; er kann mehrere Einzelobjekte desselben Typs rendern
  • SCALE ist die Klausel, die Datenwerte in für die jeweilige aesthetic passende Werte umwandelt
    • Das reicht von der Umwandlung von Zeichenkettenkategorien in tatsächliche Farben bis zu kontinuierlichen Transformationen, der Definition von Breakpoints oder der Festlegung von Skalentypen wie ordinal oder binned
  • LABEL unterstützt das Hinzufügen und Ändern von Textlabels wie Titel, Untertitel, Achsentitel und Legendentitel

Einen Schritt zurück

  • Das obige Beispiel enthält viel Syntax, deckt aber die wichtigen Teile der Kernsprache auf einmal ab
  • Viele Visualisierungsabfragen können deutlich einfacher sein
  • Als Beispiel wird ein Boxplot der Geburtsjahre nach Geschlecht aus astronauts.parquet gezeigt
    • VISUALIZE sex AS x, year_of_birth AS y FROM 'astronauts.parquet'
    • DRAW boxplot
  • Der Code kann länger sein als in anderen Plotting-Systemen, bietet dafür aber mehr Struktur, Kombinierbarkeit und Selbstbeschreibungsfähigkeit
  • Diese Eigenschaften erleichtern es Nutzern, das Verhalten aller Plot-Arten zu verinnerlichen, und sind auch für zukünftige LLM-Coding-Assistenten von Vorteil
  • Dieselbe Beziehung lässt sich leicht in ein Jitter-Streudiagramm umwandeln
    • DRAW point
    • SETTING position => 'jitter'
  • Der Jitter kann so eingestellt werden, dass er der Datenverteilung folgt und damit einen Violin-Plot-Charakter erhält
    • SETTING position => 'jitter', distribution => 'density'
  • Diese Syntaxstruktur und Kombinierbarkeit erleichtern Wiederholungen in explorativer Analyse und Visualisierungsdesign

Warum ggsql?

  • Fünf Gründe werden für die Entwicklung von ggsql genannt
    • Unterstützung für Datenanalysten und Data Scientists, die hauptsächlich mit SQL arbeiten
    • Die hohe Passung zwischen SQL und der grammar of graphics
    • Das Ziel, ein leistungsfähiges codebasiertes Visualisierungstool ohne vollständige Programmiersprache wie R oder Python bereitzustellen
    • Die starke Fähigkeit von LLMs zur Verarbeitung von SQL und die Möglichkeit neuer Visualisierungsinterfaces
    • Die Absicht, 18 Jahre Entwicklungserfahrung mit ggplot2 auf ein neues Fundament zu übertragen

  • Hello, SQL user

    • Auch während der Data-Science-Revolution mit dem Fokus auf R und Python blieb SQL die verlässliche Grundlage für Datenarbeit
    • Es gibt viele Menschen in der Datenarbeit, die ausschließlich oder überwiegend SQL verwenden
    • Die bisherigen Visualisierungsoptionen für diese Gruppe seien laut Beitrag meist nicht optimal
      • Daten exportieren, um dann R oder Python zu verwenden
      • GUI-basierte BI-Tools nutzen, die Reproduzierbarkeit nur unzureichend unterstützen
      • Direkt in Abfragen integrierte Visualisierungstools verwenden, die aber als nicht leistungsfähig oder ergonomisch genug eingeschätzt werden
    • Die Syntax von ggsql wurde so gestaltet, dass SQL-Nutzer sie sofort verstehen können
      • Sie nutzt die Erwartung an kombinierbare und deklarative Klauseln
    • ggsql soll nicht nur Visualisierung verbessern, sondern SQL-Nutzer auch in das Ökosystem codebasierter Berichte mit Quarto hineinziehen

  • Deklarative Datenverarbeitung, deklarative Visualisierung

    • SQL ist eine domänenspezifische Sprache für relationale Daten, die in einer oder mehreren Tabellen gespeichert sind
    • Die SQL-Syntax basiert auf Konzepten der relationalen Algebra und bietet eine strukturierte Denkweise für Datenmanipulation
    • Die Semantik von SQL definiert keine funktionale, sondern eine deklarative Menge modularer Operationen
    • Die grammar of graphics ist ein theoretischer Rahmen, der Datenvisualisierung in modulare Komponenten zerlegt
    • Werkzeuge wie ggplot2 setzen dieses Konzept praktisch um
    • Auch die grammar of graphics definiert eher eine deklarative als eine funktionale Menge modularer Operationen
    • Beide Systeme haben in ihrer Herangehensweise an den jeweiligen Bereich starke Gemeinsamkeiten und ermöglichen gemeinsam eine natürliche und leistungsfähige Pipeline von Rohdaten bis zur fertigen Visualisierung

  • No runtime, no problem

    • ggplot2 erfordert eine R-Installation, plotnine eine Python-Installation
    • Ein Visualisierungstool auf Basis einer einzelnen, fokussierten ausführbaren Datei bietet dagegen klare Vorteile
      • Eine kleine ausführbare Datei in andere Werkzeuge einzubetten ist einfacher als das Bündeln oder Installieren von R oder Python
      • Durch den kleineren Umfang lässt sich schadhafte oder versehentliche Codeausführung leichter per Sandbox begrenzen
    • Dadurch wird ggsql attraktiver für die Integration in KI-Analyseassistenten oder codebasierte Reporting-Tools, die Code in vielen Umgebungen ausführen
    • Der Verzicht auf eine interpretierte Sprache bringt Einschränkungen mit sich, aber auch deutliche Vorteile
    • Der wichtigste Vorteil ist, dass dank der strengen Struktur im Backend die gesamte Datenpipeline pro Layer als einzelne SQL-Abfrage ausgeführt werden kann
      • Beispiel: Bei einem Balkendiagramm über 10 Milliarden Transaktionen werden aus dem Data Warehouse nur die Count-Werte pro Balken geholt, nicht alle 10 Milliarden Zeilen
      • Dasselbe Prinzip gilt auch für komplexere Layer-Typen wie Boxplots oder Dichteplots
    • Das steht im Kontrast zu den meisten Visualisierungstools, die erst den gesamten Datensatz materialisieren und danach Berechnungen und Plotting ausführen

  • SELECT pod_door FROM bay WHERE closed

    • Es ist belegt, dass LLMs sehr effektiv natürliche Sprache in SQL umwandeln können
    • Die Erwartung ist, dass derselbe Effekt auch auf ggsql übertragbar ist
    • In querychat ist bereits natürliche visuelle Datenexploration über ggsql möglich
    • Weil ggsql eine sicherere und leichtere Runtime als R oder Python bietet, schafft es mehr Vertrauen beim Einsatz von Coding-Agenten in Produktionsumgebungen

  • We are now wise beyond our years

    • 18 Jahre Entwicklung und Wartung von ggplot2 bedeuten 18 Jahre angesammeltes Denken über Grammatik, Benutzbarkeit und Design von Datenvisualisierung
    • Dieses Wissen kann nicht vollständig zurück in ggplot2 fließen
      • Früh getroffene Entscheidungen und Nutzererwartungen müssen respektiert werden; selbst Veränderungen wären nur sehr schrittweise möglich
    • ggsql ist eine blank slate
      • Ein Projekt, das von Grund auf neu aufgebaut wird
      • Ein System, das für eine Umgebung ohne bestehende Erwartungen an Visualisierungstools entworfen wurde
    • Laut Beitrag verlieh dieser Ausgangspunkt der Entwicklung ein Gefühl von Freiheit und Energie, das sich auch in der Nutzererfahrung zeige

Zukunft

  • Die aktuelle Version ist ein alpha-release und noch nicht fertig
  • Genannt wird eine nicht vollständige Liste geplanter Erweiterungen
    • Ein neuer High-Performance-Writer, von Grund auf in Rust geschrieben
    • Theme-Infrastruktur
    • Interaktivität
    • Ein End-to-End-Deployment-Flow von Posit Workbench oder Positron bis Connect
    • Ein vollständiger ggsql Language Server und Code-Formatter
    • Unterstützung für räumliche Daten

  • Was bedeutet das für die Entwicklung von ggplot2?

    • Es wird erwähnt, dass ggplot2-Nutzer die Ankündigung von ggsql mit einer Mischung aus Sorge und Erwartung betrachten könnten
    • Die Antwort auf die Frage, ob Posit ggplot2 zugunsten von ggsql zurückstellt, lautet nein
    • ggplot2 ist bereits sehr ausgereift und stabil, soll aber weiterhin unterstützt und ausgebaut werden
    • Es wird gehofft, dass die Entwicklung von ggsql auch dazu beiträgt, neue Funktionen für ggplot2 zu ermöglichen

Mehr erfahren

  • Wer ggsql sofort ausprobieren möchte, findet im Abschnitt Getting started auf der ggsql-Website Installationshinweise und Tutorials
  • Auf der Dokumentationsseite lässt sich der gesamte von ggsql unterstützte Funktionsumfang nachlesen
  • Abschließend wird um Feedback zur Nutzererfahrung gebeten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 9 일 전
Hacker-News-Kommentare

  • Vielleicht lag es daran, dass ich den Artikel nur schnell überflogen habe, aber allein anhand des Blogposts und der Dokumentation hatte ich das Gefühl, dass die Beziehung zu SQL-Datenbanken nicht klar erklärt wurde.
    Zuerst vermutete ich, es sei so etwas wie eine SQL-ähnliche Visualisierungs-DSL, die von einer Frontend-Chartbibliothek verarbeitet wird.
    Die Anatomy-Dokumentation las sich für mich so, aber in der FAQ unter "Can I use SQL queries inside the VISUALISE clause" stand, dass Teile der Syntax direkt an die Datenbank weitergereicht werden.
    Auf der Startseite steht zwar "ggsql interfaces directly with your database", aber wie die Verbindung konkret funktioniert, war nicht gut erkennbar, was verwirrend war.

    • Ich halte den Einwand für berechtigt. Das Konzept selbst hat tatsächlich eine etwas ungewöhnliche Struktur.
      ggsql kann sich direkt mit einem Datenbank-Backend verbinden und auf Wunsch auch mit in-memory DuckDB laufen.
      Visualisierungsabfragen werden für jede Ebene der Visualisierung in SQL-Queries umgewandelt, und die zurückgegebenen Tabellen werden dann zum Rendern verwendet.
      Eine Query wie VISUALISE page_views AS x FROM visits DRAW smooth wird zum Beispiel in SQL umgewandelt, das einen Smoothing-Kernel über die Daten berechnet, und mit den zurückgegebenen Punkten wird dann das endgültige Liniendiagramm gezeichnet.
    • In ggsql gibt es das Konzept eines reader, und der dient als Schnittstelle zur SQL-Datenbank.
      Der reader kümmert sich um die Datenbankverbindung und die Erzeugung des SQL-Dialekts für die jeweilige DB.
      Im aktuellen Alpha-Stadium werden duckdb, sqlite und ein experimenteller ODBC-reader unterstützt, und die Entwicklung konzentriert sich vor allem auf lokales, dateibasiertes DuckDB.
      Die Kernidee ist, Visualisierungsabfragen in mehrere SQL-Queries umzuwandeln, sie in der Datenbank auszuführen und dann nur aus den kleinen zurückgegebenen Ergebnismengen die Charts aufzubauen.
      So lassen sich auch bei sehr vielen Zeilen nur die für ein Histogramm nötigen Statistiken per SQL berechnen und dann nur die wenigen Punkte abrufen, die zum Zeichnen der Balkenhöhen gebraucht werden.
      Standardmäßig wird eine in-memory-DuckDB-Verbindung verwendet; in der CLI kann man mit --reader eine Verbindung zu einer Datei auf Disk oder zu einer ODBC-URI herstellen.
      In Positron lässt sich das über den "Connections"-Bereich einfacher einrichten, und im ggsql-Jupyter-Kernel kann der reader per magic SQL comment angegeben werden.
      In der Dokumentation soll diese Integration mit externen Tools künftig noch besser erklärt werden.
    • Ich hatte dieselbe Frage. Ein Beispiel, das den gesamten Ablauf von Verkabelung und Abhängigkeiten zum Erzeugen eines Diagramms aus einem externen Datenbankserver zeigt, würde das Verständnis deutlich erleichtern.
    • Aus meiner Sicht sind SQL und Datenbanken nicht dasselbe.
      SQL ist eine deklarative Sprache zur Datenmanipulation; sie wird oft zum Abfragen von Datenbanken verwendet, ist aber nicht ausschließlich an Datenbanken gebunden.
      Man kann SQL auch auf Flatfiles, Datenströme oder Daten im Programmspeicher anwenden.
      Umgekehrt kann man Datenbanken auch ohne SQL abfragen.

  • Beim Überfliegen des Artikels habe ich versucht herauszufinden, warum das gebraucht wird und welches Problem es löst, aber es kam für mich nicht richtig rüber.
    Ich dachte zuerst, es gehe darum, Tabellen aus einer entfernten SQL-Datenbank direkt zu visualisieren und den Schritt zu vermeiden, sie erst in ein R data frame zu ziehen und dann ggplot darauf laufen zu lassen.
    Aber dann fragte ich mich, warum man dafür überhaupt eine neue SQL-ähnliche Sprache schaffen muss.
    In R gibt es mit dbplyr ja bereits etwas, das zwischen R und SQL übersetzt, daher schien es mir direkter, ggplot so zu erweitern, dass es dbplyr-tbl-Objekte direkt unterstützt und SQL erzeugt.
    Oder ist SQL einfach schon so vertraut, dass man annimmt, viele Leute würden solche ggplot-artigen Aufgaben lieber in dieser Syntax erledigen?
    Erst nachdem ich fast die gesamte Doku gelesen hatte, verstand ich, dass es sich um eine eigenständige Visualisierungs-App mit DuckDB- und SQLite-Backends handelt, die derzeit mit Vegalite rendert und künftig weitere Backends und Renderer unterstützen will.
    Wie ein Kommentar weiter unten sagt, wirkt es wie ein Tool, das SQL-zentrierten Nutzern, die Python oder R nicht kennen, das Erstellen von Visualisierungen ermöglichen soll.

    • Ich fand diese Ankündigung ziemlich interessant und glaube, ich kann aus meiner Sicht erklären, warum sie attraktiv ist.
      Ich stimme allerdings zu, dass der Ankündigungstext das besser hätte herausarbeiten können.
      Meiner Erfahrung nach ist die gemeinsame Sprache von Analysten, Wissenschaftlern und Ingenieuren am Ende oft SQL.
      Dass man das auch in R machen kann, stimmt, aber reale Projekte werden nicht zwingend in R oder Python geschrieben; SQL-Datenbanken und Zugriffsschichten sind dagegen meist ohnehin schon vorhanden.
      Ich nutze außerdem in marimo notebooks oft SQL-Zellen mit einer DuckDB im Hintergrund, und dort direkt aus SQL heraus plotten zu können, wäre sehr praktisch.
      Und schließlich fand ich Python-Plotting-APIs immer ziemlich schwer zu merken und flüssig zu benutzen.
      Selbst für einen einfachen Scatterplot gibt es in matplotlib zu viel boilerplate, daher fände ich eine einheitliche Syntax innerhalb derselben Query-Sprache ziemlich gut.
    • Dabei geht es nicht um ggplot an sich, sondern um den Versuch, eine SQL-artige Syntax mit der Grammar of Graphics zu verbinden.
      Der interessante Punkt liegt eher in der Kombination aus SQL als Interface und der Formalisierung durch GoG als in einer bestimmten Bibliothek.
      Der eigentliche Renderer oder die Runtime sind zwar wichtig, aber eher Implementierungsdetails.
    • Für mich sah es wie ein Tool für SQL-Nutzer aus, die Python oder R nicht kennen.
    • Dass es eine deklarative Sprache zum direkten Erstellen von Charts in SQL ist, hat klar Vorteile.
      Natürlich ist das nichts, was man mit ähnlich vielen Zeilen Code nicht auch in R oder Python mit matplotlib hinbekommen könnte.
      Aber solche Umgebungen sicher gegen bösartige Eingaben zu sandboxen, ist schwierig, während sich so eine deklarative Sprache leicht hosten ließe, sodass nicht vertrauenswürdige Nutzer ggsql eingeben können und am Ende nur ein Diagramm erzeugt wird.
      In diesem Sinn ist das eindeutig nützlich.
      Für die meisten üblichen Anwendungsfälle scheint es aber wahrscheinlich einfacher zu sein, einem bevorzugten LLM matplotlib-Code erzeugen zu lassen.

  • Ich unterstütze das Projekt grundsätzlich und stimme stark zu, dass das Konzept sehr gut zu SQL passt.
    In R Daten mit WITH vorzubereiten und danach VISUALIZE anzuhängen, entspricht fast genau auch meinem Stil beim Plotten.
    Abgesehen vom Vorteil einer einfachen DSL ist mir aber noch nicht klar, welchen Vorteil es gegenüber ggplot2 gibt, der die Kosten einer weiteren DSL rechtfertigt.
    Der fast einzige Grund, warum ich ggplot2 für Visualisierungen verlasse, ist, dass nicht standardisierte Visualisierungen ziemlich schwierig werden, sobald man den Standardfall mit vorhandenen geoms verlässt.
    Wenn ich etwas nur leicht Abweichendes bauen will, ist es oft viel einfacher, auf primitive Drawing-Operationen herunterzugehen, als sich einen ggplot-kompatiblen Adapter zurechtzubiegen.
    Selbst das bloße Verpacken eines häufig verwendeten Teils der Spezifikation in eine Funktion fühlt sich nicht immer geschmeidig an, je nachdem, ob es mit + komponiert oder mit |> bzw. dem älteren %>% in eine Pipe eingebunden wird.

    • Unser Ziel ist nicht, irgendwen von ggplot2 wegzulocken.
      Und wir haben auch keineswegs vor, die Entwicklung von ggplot2 einzustellen.
      ggsql ist teilweise ein Versuch, neue Nutzergruppen zu erreichen und starke Visualisierung in neue Kontexte zu bringen.
      Wer die meiste Zeit in R verbringt, gehört wahrscheinlich nicht zur Kernzielgruppe.
      Es gibt allerdings auch einige ziemlich interessante Elemente, die ggplot2 nicht hat, sodass das Erkunden trotzdem Spaß machen könnte.
    • Nur am Rande: |> und %>% sind nicht derselbe Operator.
      Die relativ neue base pipe |> ist zwar schneller, unterstützt aber nicht Dinge wie den Punkt-Platzhalter von %>%, wenn ein Wert nicht als erstes Funktionsargument übergeben werden soll.
      In manchen Fällen kann %>% den Ausdruck deshalb etwas sauberer machen.

  • Das finde ich wirklich gut.
    Auch wir sind beim Bau von GFQL, einer graph dataframe query language, zu ähnlichen Schlussfolgerungen gekommen.
    Besonders für einen LLM-freundlichen Interface, das ohne Code-Sandbox nutzbar ist, bestand in Visualisierungs- und Analyse-Stacks Bedarf.
    Schon mit grundlegenden opencypher-Erweiterungen konnten wir recht umfangreiche GPU-gestützte visuelle Analyse-Pipelines bauen, und aus demselben Grund erscheint der Weg über SQL in der Tabellenwelt ebenfalls sehr sinnvoll.
    Als GFQL-Beispiele lohnen sich overall pipelines zu Datenladen, Shape-Transformation, algorithmusbasierter Enrichment, visueller Kodierung und erstklassigen Pipelines sowie declarative visual encodings in Form einfacher Aufrufe.

  • Das sieht ziemlich gut aus.
    Ich fände es allerdings schön, wenn es auch in Umgebungen ohne Syntax-Unterstützung elegant degradieren würde.
    Ich habe selbst einmal etwas in ähnlicher Richtung entworfen, allerdings mit einem viel einfacheren Ansatz innerhalb von SQL als GoG, und dort war so ein Degrade möglich.
    Es war keine besonders gut lesbare Syntax, eher etwas wie die sqlnb spec.

    • Ich bin mir etwas unsicher, was mit "degrade in context" genau gemeint ist.
      Wenn möglich, wäre eine etwas konkretere Erklärung hilfreich.

  • Als Tool in einer ähnlichen Richtung fällt mir auch Shaper auf DuckDB-Basis ein.
    Das ist ein SQL-first-Ansatz für ganze Dashboards, und die Getting-started-Dokumentation wirkt von der Richtung her ähnlich.

  • Zunächst einmal sieht ggsql wirklich großartig aus, und ich möchte es bald ausprobieren.
    Allerdings ist mir in der Dokumentation eine auffällige Lücke aufgefallen: Es war schwer, etwas über die Ausgabeformate zu finden.
    Kann man PDF ausgeben, gibt es SVG oder PNG, und wie steuert man Dinge wie Breite und Höhe der Ausgabe? Das war nicht gut erkennbar.
    Der nächste Hinweis, den ich gefunden habe, war in der Python-Library-Doku chart.display() und chart.save("chart.html").

    • Der aktuelle writer-Modul ist nur für vegalite ausgelegt, und die Ausgabe ist ein Vegalite-Spec im JSON-Format.
      Diese Ausgabe kann mit bereits vorhandenen Tools als interaktives Chart, SVG, PNG usw. gerendert werden, und auch Größensteuerung folgt den Einstellungen dieser Tools.
      Der ggsql-Jupyter-Kernel kann dieses Vegalite-Spec nutzen, um innerhalb von Quarto-Dokumenten Charts auszugeben.
      Künftig planen wir einen neuen High-Performance-writer, der ohne diesen zwischengeschalteten Vegalite-Schritt auskommt; dann werden wir solche Fragen vermutlich klarer beantworten können.

  • Mich würde interessieren, ob es in naher oder ferner Zukunft Pläne zur Integration mit ggplot2-Erweiterungspaketen gibt, etwa den ggplot2 extension packages.
    Falls das schon beantwortet wurde, entschuldige bitte.

    • Ich glaube nicht, dass wir die vielen niche geoms aus der ggplot2-Community in naher Zukunft übernehmen können.
      Das Ziel dieses Projekts ist nicht, ggplot2 zu ersetzen, sondern einen anderen Ansatz zu bieten.
      Es wird vieles können, was ggplot2 auch kann, und womöglich auch manches, was ggplot2 nicht kann, aber ich erwarte, dass ggplot2 noch lange Zeit für viele Aufgaben das mächtigere Werkzeug bleiben wird.

  • Das sieht wirklich großartig aus, und ich werde es bald ausprobieren.
    Was bei mir direkt Klick gemacht hat, war die Erklärung in der Grammar-Dokumentation.
    Mit dem vertrauten SELECT wählt man Daten aus, mit VISUALIZE oder VISUALISE wechselt man von der Tabelle zum Plot, danach mappt man mit DRAW die aesthetics und stapelt dann SCALE, FACET und LABEL nacheinander auf — beeindruckend fand ich, wie konsequent das die strukturelle Denkweise von SQL fortsetzt.

  • Mir hat der Layering-Ansatz wirklich gut gefallen.
    Sobald man über Basisdiagramme hinausgeht, scheint dieser Ansatz Probleme gut zu lösen, auf die ich bei anderen gemischten SQL-Visualisierungstools oft gestoßen bin.