글을 빨리 훑어본 탓일 수도 있지만, 블로그 글과 문서만 봐서는 SQL 데이터베이스와의 관계가 명확하게 설명되지 않았다고 느꼈음
처음에는 프런트엔드 차트 라이브러리가 처리하는 SQL 비슷한 시각화 DSL 정도라고 짐작했음 anatomy 문서는 그렇게 읽혔는데, FAQ의 "Can I use SQL queries inside the VISUALISE clause"에서는 일부 문법이 데이터베이스로 직접 전달된다고 적혀 있었음
홈페이지에는 "ggsql interfaces directly with your database"라고 되어 있지만, 실제로 어떻게 연결되는지는 잘 드러나지 않아 혼란스러웠음
그 지적이 타당하다고 봄. 이 개념 자체가 조금 특이한 구조이긴 함
ggsql은 데이터베이스 백엔드에 직접 연결할 수 있고, 원하면 in-memory DuckDB로도 실행 가능함
시각화 쿼리는 시각화의 각 레이어마다 SQL 쿼리로 변환되고, 그 결과 테이블을 렌더링에 사용하는 방식임
예를 들어 VISUALISE page_views AS x FROM visits DRAW smooth 같은 쿼리는 데이터에 대한 smoothing kernel을 계산하는 SQL로 바뀌고, 반환된 점들로 최종 선 차트를 그리는 구조임
ggsql에는 reader라는 개념이 있고, 이게 SQL 데이터베이스와 연결되는 인터페이스 역할을 맡음
reader가 데이터베이스 연결과 각 DB에 맞는 SQL dialect 생성을 처리함
현재 alpha 단계에서는 duckdb, sqlite, 실험적인 ODBC reader 정도를 지원하고, 개발은 주로 로컬 파일 기반 DuckDB 중심으로 진행 중임
핵심 아이디어는 시각화 쿼리를 여러 개의 SQL 쿼리로 바꿔 데이터베이스에서 실행한 뒤, 반환된 소량의 결과만으로 차트를 구성하는 방식임
그래서 아주 많은 행이 있어도 히스토그램에 필요한 통계만 SQL로 계산하고, 막대 높이를 그리는 데 필요한 몇 개 점만 받아올 수 있음
기본값은 in-memory DuckDB 연결이며, CLI에서는 --reader로 디스크 파일이나 ODBC URI에 연결 가능함
Positron에서는 "Connections" pane으로 더 쉽게 설정할 수 있고, ggsql Jupyter kernel에서는 magic SQL comment로 reader를 지정할 수 있음
문서에도 이런 외부 도구 연동 설명을 더 보강할 계획임
나도 같은 의문이 있었음. 외부 데이터베이스 서버에서 그래프를 만들기 위한 배선과 의존성 전체 흐름을 보여주는 예제가 있으면 훨씬 이해가 쉬울 것 같음
내가 보기엔 SQL과 데이터베이스는 같은 개념이 아님
SQL은 선언형 데이터 조작 언어이고, 데이터베이스를 조회하는 데 자주 쓰이지만 데이터베이스에만 묶여 있는 것은 아님
플랫 파일, 데이터 스트림, 프로그램 메모리 안의 데이터에도 SQL을 적용할 수 있음
반대로 데이터베이스를 SQL 없이 조회하는 것도 가능하다고 봄
글을 훑어보면서, 왜 이게 필요한지와 무슨 문제를 해결하는지 설명을 찾으려 했는데 잘 와닿지 않았음
원격 SQL 데이터베이스의 테이블을 바로 시각화하고, 먼저 R data frame으로 끌고 와서 ggplot을 돌리는 단계를 줄이려는 것인가 싶었음
그런데 왜 굳이 새로운 SQL 유사 언어를 만드는지도 의문이었음
이미 R에는 R과 SQL 사이를 번역해주는 dbplyr가 있으니, 차라리 ggplot이 dbplyr tbl 객체를 직접 지원하고 SQL을 생성하게 확장하는 편이 더 직접적이지 않나 싶었음
아니면 SQL 자체가 워낙 익숙한 언어라서, 많은 사람들이 이 문법으로 ggplot류 작업을 하길 원한다고 보는 건지도 궁금했음
문서를 거의 다 읽고 나서야, 이게 DuckDB와 SQLite 백엔드를 가진 독립형 시각화 앱이고, 현재는 Vegalite로 렌더링하며 앞으로 백엔드와 렌더러를 더 늘릴 계획이라는 점을 이해했음
아래 댓글 말처럼, Python이나 R을 모르는 SQL 중심 사용자가 시각화를 만들게 하려는 도구로 보였음
나는 이 발표를 읽고 꽤 흥미로웠음, 그래서 왜 매력적인지 내 관점에서 설명해볼 수 있을 것 같음
물론 발표 글이 그 점을 좀 더 잘 설명했으면 좋았겠다는 데는 동의함
내 경험상 분석가, 과학자, 엔지니어가 공통으로 공유하는 언어는 결국 SQL인 경우가 많음
R로도 같은 일을 할 수 있지만, 실제 프로젝트가 꼭 R이나 Python으로 작성되는 건 아니고, 대신 SQL 데이터베이스와 접근 엔진은 대체로 이미 존재함
또 나는 marimo notebook에서 백그라운드 DuckDB로 SQL 셀을 자주 쓰는데, 거기서 SQL로 바로 플로팅할 수 있으면 매우 편할 것 같음
마지막으로 Python 플로팅 API는 외우고 손에 익히기가 꽤 어렵다고 느껴왔음
matplotlib로 단순한 scatterplot 하나 그리는 데도 boilerplate가 너무 많아서, 같은 쿼리 언어 안에 통일된 문법이 있으면 꽤 좋겠다고 느낌
이건 ggplot 자체에 대한 이야기가 아니라, SQL 풍 문법과 Grammar of Graphics를 결합하는 시도라고 봄
흥미로운 지점은 특정 라이브러리보다 인터페이스로서의 SQL과 GoG 형식성의 조합에 있음
실제 렌더러나 런타임은 중요하긴 하지만 구현 세부사항에 가깝다고 생각함
내 눈에는 Python이나 R을 모르는 SQL 사용자를 위한 도구처럼 보였음
SQL에서 바로 차트를 만드는 선언형 언어라는 점에는 분명 장점이 있다고 봄
물론 비슷한 줄 수의 코드로 R이나 Python, matplotlib에서도 쉽게 할 수 없는 일은 아님
다만 그런 환경을 악의적 입력에 대해 안전하게 sandboxing하는 일은 어렵고, 이런 선언형 언어라면 신뢰하지 않는 사용자가 ggsql을 입력해도 차트만 생성해주는 형태로 호스팅하기가 쉬워짐
그런 의미에서는 분명 쓸모가 있음
다만 대부분의 일반적인 사용에서는, 좋아하는 LLM에게 matplotlib 코드를 생성하게 시키는 편이 더 쉬운 선택 같기도 함
프로젝트 자체는 응원하고, 개념이 SQL에 아주 잘 들어맞는다는 데 크게 동의함
R에서 WITH로 데이터 준비를 하고 그 뒤에 VISUALIZE를 붙이는 구조는 내 플로팅 코드와도 거의 비슷함
다만 단순한 DSL이라는 장점 외에는, 또 하나의 DSL을 만드는 비용을 감수하면서까지 ggplot2 대비 이점이 무엇인지 아직 잘 모르겠음
내가 시각화 때문에 ggplot2를 떠나는 거의 유일한 이유는, 이미 geom이 만들어진 표준적 경우를 벗어나는 순간 비표준 시각화를 하기가 꽤 어렵기 때문임
뭔가 조금 다른 걸 만들고 싶을 때는 ggplot 친화적인 어댑터를 억지로 만드는 것보다, 차라리 하위 primitive drawing으로 내려가는 편이 훨씬 쉬운 경우가 많았음
흔히 쓰는 부분 사양을 함수로 감싸는 일조차도 +로 합성되는지, |>나 예전 %>% 같은 파이프로 엮이는지에 따라 매끄럽지 않을 때가 많다고 느낌
우리는 누구든 ggplot2에서 갈아타게 만들려는 게 목적은 아님
그리고 ggplot2 개발을 멈출 계획도 전혀 없음
ggsql은 새로운 사용자층에 도달하고, 강력한 시각화를 새로운 맥락에 두려는 시도가 일부 포함된 프로젝트임
대부분의 시간을 R에서 보내는 사람이라면 핵심 타깃 사용자는 아닐 가능성이 큼
다만 ggplot2에 없는 꽤 흥미로운 요소들도 있어서, 탐험해보는 재미는 있을 수 있다고 봄
옆말이지만 |>와 %>%는 같은 연산자가 아님
비교적 최근의 base pipe인 |>가 더 빠르긴 하지만, 함수의 첫 번째 인자가 아닌 위치로 넘길 때 %>%의 점 placeholder 같은 기능을 지원하지 않음
그래서 어떤 경우에는 %>% 쪽이 표현을 조금 더 깔끔하게 만들기도 함
이건 정말 좋다고 느낌
우리도 GFQL이라는 graph dataframe query language를 만들면서 비슷한 결론에 도달했음
특히 코드 sandbox 없이도 쓸 수 있는 LLM 친화적 인터페이스가 시각화와 분석 스택에 필요했음
기본적인 opencypher 확장만으로도 꽤 풍부한 GPU 시각 분석 파이프라인을 만들 수 있다는 걸 확인했고, 같은 이유로 테이블 세계에서 SQL로 가는 접근도 아주 타당해 보였음
GFQL 쪽 예시로는 데이터 로딩, shape 변환, 알고리즘 기반 enrichment, 시각 인코딩, 1급 파이프라인을 다룬 overall pipelines와, 단순 호출 형태의 declarative visual encodings를 참고해볼 만함
이거 꽤 괜찮아 보임
다만 문법 지원이 없는 환경에서도 우아하게 degrade되는 방식이 있었으면 좋겠다고 느낌
나도 비슷한 방향의, 다만 GoG보다는 훨씬 단순한 SQL 내부 접근을 고안한 적이 있고, 그쪽은 degrade가 가능했음
읽기 좋은 문법은 아니지만 sqlnb spec 같은 식이었음
"degrade in context"가 정확히 무슨 뜻인지 나는 조금 헷갈렸음
가능하면 조금 더 구체적으로 설명해주면 좋겠음
같은 흐름의 도구로는 DuckDB 기반의 Shaper도 떠오름
전체 대시보드를 SQL 우선 방식으로 다루는 접근이고, getting started 문서를 보면 방향성이 비슷하다고 느낌
우선 ggsql은 정말 멋져 보이고, 빨리 써보고 싶음
다만 문서에서 눈에 띄는 빠진 점이 하나 있었는데, 출력 형식 설명을 찾기 어려웠음
PDF로 낼 수 있는지, SVG나 PNG는 되는지, 가로세로 크기 같은 출력 제어를 어떻게 하는지가 잘 안 보였음
내가 찾은 가장 가까운 힌트는 Python 라이브러리 문서의 chart.display()와 chart.save("chart.html") 정도였음
현재 writer 모듈은 vegalite 전용만 있고, 출력은 vegalite spec인 JSON 형태임
이 출력은 이미 존재하는 도구들로 인터랙티브 차트, SVG, PNG 등으로 렌더링할 수 있고, 크기 같은 제어도 그 도구들의 설정을 따르면 됨
ggsql Jupyter kernel은 이런 vegalite spec을 이용해 Quarto 문서 안에서 차트를 출력할 수 있음
앞으로는 이 중간 vegalite 단계를 거치지 않는 고성능 writer를 새로 만들 계획이라, 그 시점에는 이런 질문에 더 명확한 답을 줄 수 있을 것 같음
가까운 미래든 먼 미래든, ggplot2 확장 패키지들과의 통합 계획이 있는지 궁금했음
이미 언급된 내용이었다면 미안한 마음임
ggplot2 커뮤니티가 만든 여러 niche geom을 가까운 시일 내에 가져오기는 어렵다고 봄
이 프로젝트의 목적은 ggplot2를 대체하는 것이 아니라, 다른 접근을 제공하는 데 있음
ggplot2가 하는 많은 일을 해낼 수 있고, ggplot2가 못 하는 일부도 가능하겠지만, 앞으로도 오랫동안 많은 작업에서는 ggplot2가 더 강력할 거라고 예상함
이거 정말 멋져 보여서 곧 써볼 생각임
나한테 확 와닿은 건 grammar 문서의 설명이었음
이미 익숙한 SELECT로 데이터를 고르고, VISUALIZE나 VISUALISE로 표에서 플롯으로 전환한 뒤, DRAW로 aesthetics를 매핑하고, SCALE, FACET, LABEL을 차례로 쌓아간다는 흐름이 SQL의 구조적 사고방식 그대로 이어진다는 점이 인상적이었음
나는 레이어링 접근이 정말 마음에 들었음
기본 차트를 넘어서기 시작할 때 다른 SQL 시각화 혼합 도구들에서 자주 겪던 문제를 이 방식이 잘 풀어주는 것처럼 보였음
Hacker News 의견들
글을 빨리 훑어본 탓일 수도 있지만, 블로그 글과 문서만 봐서는 SQL 데이터베이스와의 관계가 명확하게 설명되지 않았다고 느꼈음
처음에는 프런트엔드 차트 라이브러리가 처리하는 SQL 비슷한 시각화 DSL 정도라고 짐작했음
anatomy 문서는 그렇게 읽혔는데, FAQ의 "Can I use SQL queries inside the VISUALISE clause"에서는 일부 문법이 데이터베이스로 직접 전달된다고 적혀 있었음
홈페이지에는 "ggsql interfaces directly with your database"라고 되어 있지만, 실제로 어떻게 연결되는지는 잘 드러나지 않아 혼란스러웠음
ggsql은 데이터베이스 백엔드에 직접 연결할 수 있고, 원하면 in-memory DuckDB로도 실행 가능함
시각화 쿼리는 시각화의 각 레이어마다 SQL 쿼리로 변환되고, 그 결과 테이블을 렌더링에 사용하는 방식임
예를 들어
VISUALISE page_views AS x FROM visits DRAW smooth같은 쿼리는 데이터에 대한 smoothing kernel을 계산하는 SQL로 바뀌고, 반환된 점들로 최종 선 차트를 그리는 구조임reader가 데이터베이스 연결과 각 DB에 맞는 SQL dialect 생성을 처리함
현재 alpha 단계에서는 duckdb, sqlite, 실험적인 ODBC reader 정도를 지원하고, 개발은 주로 로컬 파일 기반 DuckDB 중심으로 진행 중임
핵심 아이디어는 시각화 쿼리를 여러 개의 SQL 쿼리로 바꿔 데이터베이스에서 실행한 뒤, 반환된 소량의 결과만으로 차트를 구성하는 방식임
그래서 아주 많은 행이 있어도 히스토그램에 필요한 통계만 SQL로 계산하고, 막대 높이를 그리는 데 필요한 몇 개 점만 받아올 수 있음
기본값은 in-memory DuckDB 연결이며, CLI에서는
--reader로 디스크 파일이나 ODBC URI에 연결 가능함Positron에서는 "Connections" pane으로 더 쉽게 설정할 수 있고, ggsql Jupyter kernel에서는 magic SQL comment로 reader를 지정할 수 있음
문서에도 이런 외부 도구 연동 설명을 더 보강할 계획임
SQL은 선언형 데이터 조작 언어이고, 데이터베이스를 조회하는 데 자주 쓰이지만 데이터베이스에만 묶여 있는 것은 아님
플랫 파일, 데이터 스트림, 프로그램 메모리 안의 데이터에도 SQL을 적용할 수 있음
반대로 데이터베이스를 SQL 없이 조회하는 것도 가능하다고 봄
글을 훑어보면서, 왜 이게 필요한지와 무슨 문제를 해결하는지 설명을 찾으려 했는데 잘 와닿지 않았음
원격 SQL 데이터베이스의 테이블을 바로 시각화하고, 먼저 R data frame으로 끌고 와서 ggplot을 돌리는 단계를 줄이려는 것인가 싶었음
그런데 왜 굳이 새로운 SQL 유사 언어를 만드는지도 의문이었음
이미 R에는 R과 SQL 사이를 번역해주는 dbplyr가 있으니, 차라리 ggplot이 dbplyr tbl 객체를 직접 지원하고 SQL을 생성하게 확장하는 편이 더 직접적이지 않나 싶었음
아니면 SQL 자체가 워낙 익숙한 언어라서, 많은 사람들이 이 문법으로 ggplot류 작업을 하길 원한다고 보는 건지도 궁금했음
문서를 거의 다 읽고 나서야, 이게 DuckDB와 SQLite 백엔드를 가진 독립형 시각화 앱이고, 현재는 Vegalite로 렌더링하며 앞으로 백엔드와 렌더러를 더 늘릴 계획이라는 점을 이해했음
아래 댓글 말처럼, Python이나 R을 모르는 SQL 중심 사용자가 시각화를 만들게 하려는 도구로 보였음
물론 발표 글이 그 점을 좀 더 잘 설명했으면 좋았겠다는 데는 동의함
내 경험상 분석가, 과학자, 엔지니어가 공통으로 공유하는 언어는 결국 SQL인 경우가 많음
R로도 같은 일을 할 수 있지만, 실제 프로젝트가 꼭 R이나 Python으로 작성되는 건 아니고, 대신 SQL 데이터베이스와 접근 엔진은 대체로 이미 존재함
또 나는 marimo notebook에서 백그라운드 DuckDB로 SQL 셀을 자주 쓰는데, 거기서 SQL로 바로 플로팅할 수 있으면 매우 편할 것 같음
마지막으로 Python 플로팅 API는 외우고 손에 익히기가 꽤 어렵다고 느껴왔음
matplotlib로 단순한 scatterplot 하나 그리는 데도 boilerplate가 너무 많아서, 같은 쿼리 언어 안에 통일된 문법이 있으면 꽤 좋겠다고 느낌
흥미로운 지점은 특정 라이브러리보다 인터페이스로서의 SQL과 GoG 형식성의 조합에 있음
실제 렌더러나 런타임은 중요하긴 하지만 구현 세부사항에 가깝다고 생각함
물론 비슷한 줄 수의 코드로 R이나 Python, matplotlib에서도 쉽게 할 수 없는 일은 아님
다만 그런 환경을 악의적 입력에 대해 안전하게 sandboxing하는 일은 어렵고, 이런 선언형 언어라면 신뢰하지 않는 사용자가 ggsql을 입력해도 차트만 생성해주는 형태로 호스팅하기가 쉬워짐
그런 의미에서는 분명 쓸모가 있음
다만 대부분의 일반적인 사용에서는, 좋아하는 LLM에게 matplotlib 코드를 생성하게 시키는 편이 더 쉬운 선택 같기도 함
프로젝트 자체는 응원하고, 개념이 SQL에 아주 잘 들어맞는다는 데 크게 동의함
R에서 WITH로 데이터 준비를 하고 그 뒤에 VISUALIZE를 붙이는 구조는 내 플로팅 코드와도 거의 비슷함
다만 단순한 DSL이라는 장점 외에는, 또 하나의 DSL을 만드는 비용을 감수하면서까지 ggplot2 대비 이점이 무엇인지 아직 잘 모르겠음
내가 시각화 때문에 ggplot2를 떠나는 거의 유일한 이유는, 이미 geom이 만들어진 표준적 경우를 벗어나는 순간 비표준 시각화를 하기가 꽤 어렵기 때문임
뭔가 조금 다른 걸 만들고 싶을 때는 ggplot 친화적인 어댑터를 억지로 만드는 것보다, 차라리 하위 primitive drawing으로 내려가는 편이 훨씬 쉬운 경우가 많았음
흔히 쓰는 부분 사양을 함수로 감싸는 일조차도
+로 합성되는지,|>나 예전%>%같은 파이프로 엮이는지에 따라 매끄럽지 않을 때가 많다고 느낌그리고 ggplot2 개발을 멈출 계획도 전혀 없음
ggsql은 새로운 사용자층에 도달하고, 강력한 시각화를 새로운 맥락에 두려는 시도가 일부 포함된 프로젝트임
대부분의 시간을 R에서 보내는 사람이라면 핵심 타깃 사용자는 아닐 가능성이 큼
다만 ggplot2에 없는 꽤 흥미로운 요소들도 있어서, 탐험해보는 재미는 있을 수 있다고 봄
|>와%>%는 같은 연산자가 아님비교적 최근의 base pipe인
|>가 더 빠르긴 하지만, 함수의 첫 번째 인자가 아닌 위치로 넘길 때%>%의 점 placeholder 같은 기능을 지원하지 않음그래서 어떤 경우에는
%>%쪽이 표현을 조금 더 깔끔하게 만들기도 함이건 정말 좋다고 느낌
우리도 GFQL이라는 graph dataframe query language를 만들면서 비슷한 결론에 도달했음
특히 코드 sandbox 없이도 쓸 수 있는 LLM 친화적 인터페이스가 시각화와 분석 스택에 필요했음
기본적인 opencypher 확장만으로도 꽤 풍부한 GPU 시각 분석 파이프라인을 만들 수 있다는 걸 확인했고, 같은 이유로 테이블 세계에서 SQL로 가는 접근도 아주 타당해 보였음
GFQL 쪽 예시로는 데이터 로딩, shape 변환, 알고리즘 기반 enrichment, 시각 인코딩, 1급 파이프라인을 다룬 overall pipelines와, 단순 호출 형태의 declarative visual encodings를 참고해볼 만함
이거 꽤 괜찮아 보임
다만 문법 지원이 없는 환경에서도 우아하게 degrade되는 방식이 있었으면 좋겠다고 느낌
나도 비슷한 방향의, 다만 GoG보다는 훨씬 단순한 SQL 내부 접근을 고안한 적이 있고, 그쪽은 degrade가 가능했음
읽기 좋은 문법은 아니지만 sqlnb spec 같은 식이었음
가능하면 조금 더 구체적으로 설명해주면 좋겠음
같은 흐름의 도구로는 DuckDB 기반의 Shaper도 떠오름
전체 대시보드를 SQL 우선 방식으로 다루는 접근이고, getting started 문서를 보면 방향성이 비슷하다고 느낌
우선 ggsql은 정말 멋져 보이고, 빨리 써보고 싶음
다만 문서에서 눈에 띄는 빠진 점이 하나 있었는데, 출력 형식 설명을 찾기 어려웠음
PDF로 낼 수 있는지, SVG나 PNG는 되는지, 가로세로 크기 같은 출력 제어를 어떻게 하는지가 잘 안 보였음
내가 찾은 가장 가까운 힌트는 Python 라이브러리 문서의
chart.display()와chart.save("chart.html")정도였음이 출력은 이미 존재하는 도구들로 인터랙티브 차트, SVG, PNG 등으로 렌더링할 수 있고, 크기 같은 제어도 그 도구들의 설정을 따르면 됨
ggsql Jupyter kernel은 이런 vegalite spec을 이용해 Quarto 문서 안에서 차트를 출력할 수 있음
앞으로는 이 중간 vegalite 단계를 거치지 않는 고성능 writer를 새로 만들 계획이라, 그 시점에는 이런 질문에 더 명확한 답을 줄 수 있을 것 같음
가까운 미래든 먼 미래든, ggplot2 확장 패키지들과의 통합 계획이 있는지 궁금했음
이미 언급된 내용이었다면 미안한 마음임
이 프로젝트의 목적은 ggplot2를 대체하는 것이 아니라, 다른 접근을 제공하는 데 있음
ggplot2가 하는 많은 일을 해낼 수 있고, ggplot2가 못 하는 일부도 가능하겠지만, 앞으로도 오랫동안 많은 작업에서는 ggplot2가 더 강력할 거라고 예상함
이거 정말 멋져 보여서 곧 써볼 생각임
나한테 확 와닿은 건 grammar 문서의 설명이었음
이미 익숙한 SELECT로 데이터를 고르고,
VISUALIZE나VISUALISE로 표에서 플롯으로 전환한 뒤,DRAW로 aesthetics를 매핑하고,SCALE,FACET,LABEL을 차례로 쌓아간다는 흐름이 SQL의 구조적 사고방식 그대로 이어진다는 점이 인상적이었음나는 레이어링 접근이 정말 마음에 들었음
기본 차트를 넘어서기 시작할 때 다른 SQL 시각화 혼합 도구들에서 자주 겪던 문제를 이 방식이 잘 풀어주는 것처럼 보였음