▲

ggsql - SQL을 위한 그래픽 문법

 (opensource.posit.co)
2P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • SQL 문법 기반 시각화 도구로, VISUALIZE, DRAW, PLACE, SCALE, LABEL 같은 절을 통해 데이터 조회와 그래프 구성을 한 흐름으로 결합
  • 열을 시각적 속성에 매핑하고 레이어 조합 방식으로 산점도, 막대그래프, 히스토그램, 박스플롯, 주석 요소까지 같은 구조 안에서 구성 가능
  • SQL 쿼리 결과를 곧바로 시각화 입력으로 넘기며, 일부 레이어는 단일 SQL 쿼리 실행으로 집계만 가져오는 구조여서 대규모 데이터 처리에 유리함
  • R이나 Python 런타임 없이도 사용할 수 있는 작고 집중된 실행 파일 지향 설계로, 코드 기반 보고 도구와 AI 분석 도우미 통합에도 적합성 부각
  • 현재 버전은 alpha-release이며, 고성능 writer, 테마, 인터랙티비티, language server, formatter, 공간 데이터 지원 같은 확장 계획 제시

ggsql 소개

  • ggsql은 SQL 문법 기반의 grammar of graphics 구현체로, SQL에 구조화된 시각화 기능 추가
    • Quarto, Jupyter notebooks, Positron, VS Code 등에서 사용 가능
  • SQL 사용자에게 익숙한 방식으로 시각화 코드를 작성할 수 있도록 설계됨
    • SQL의 선언적이고 조합 가능한 절 구성을 시각화 문법에도 적용
  • 동기와 사용 예시를 함께 제시하며 ggsql의 핵심 구문 전개

기본 예시

  • 첫 번째 플롯

    • 내장 penguins 데이터셋으로 산점도 작성 가능
      • VISUALIZE bill_len AS x, bill_dep AS y FROM ggsql:penguins
      • DRAW point
    • VISUALIZE에서 데이터 열을 시각적 속성에 매핑하고, DRAW point가 해당 기본 매핑을 사용해 점 레이어 생성
    • species AS color 추가만으로 색상 범주 구분 적용 가능
      • VISUALIZE bill_len AS x, bill_dep AS y, species AS color FROM ggsql:penguins
      • DRAW point
    • DRAW smooth 추가로 점 레이어 위에 회귀선 레이어 누적 가능
      • 종별 색상 매핑이 유지되어 species마다 별도 선 생성
    • 미리 정해진 플롯 종류 대신 모듈식 구성요소 조합 방식 채택
    • 같은 구조를 유지한 채 전혀 다른 시각화로 전환 가능
      • VISUALIZE island AS x, species AS color FROM ggsql:penguins
      • DRAW bar

  • 완전한 예시

    • 상단은 일반 SQL 쿼리, VISUALIZE 이후는 시각화 쿼리로 구분됨
      • 예시에서는 DuckDB 백엔드 사용
    • SQL 부분은 astronauts.parquet에서 이름별 최신 mission만 남기기 위해 ROW_NUMBER()와 QUALIFY 사용
    • 이어서 두 집합 결합
      • year_of_selection - year_of_birth를 age로 계산하고 Age at selection 범주 부여
      • year_of_mission - year_of_birth를 age로 계산하고 Age at mission 범주 부여
      • 두 결과를 UNION ALL로 결합
    • 시각화 쿼리에서는 age AS x, category AS fill 매핑 후 DRAW histogram 사용
      • SETTING binwidth => 1, position => 'identity' 지정
    • PLACE rule로 사전 계산된 평균 위치 주석 추가
      • x => (34, 44), linetype => 'dotted'
    • PLACE text로 텍스트 주석 추가
      • x => (34, 44, 60)
      • y => (66, 49, 20)
      • 라벨에 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! 포함
      • hjust => 'left', vjust => 'top', offset => (10, 0) 지정
    • SCALE fill TO accent로 fill 매핑값을 accent 색상 팔레트로 변환
    • LABEL 절로 제목, 부제, x축 라벨, 범례 라벨 제어
      • 제목 How old are astronauts on their most recent mission?
      • 부제 Age of astronauts when they were selected and when they were sent on their mission
      • x축 Age of astronaut (years)
      • fill => null

시각화 쿼리 구조

  • VISUALIZE 이전은 순수 SQL이며, 결과 테이블이 표로 반환되지 않고 시각화 입력으로 직접 전달됨
  • SQL 부분에서 생성된 테이블이나 CTE는 시각화 쿼리에서 참조 가능
  • 데이터가 이미 시각화에 적합한 형태라면 SQL 부분 생략 가능
    • VISUALIZE year_of_selection AS x, year_of_mission AS y FROM 'astronauts.parquet'
  • VISUALIZE 또는 VISUALISE는 SQL 쿼리 종료와 시각화 쿼리 시작 표시
  • 매핑은 열을 시각적 속성, 즉 aesthetics에 연결하는 역할 수행
    • 예시에서는 age가 x축 위치, category가 채우기 색상에 대응
  • DRAW는 시각화에 레이어 추가
    • point처럼 단순한 타입도 있고, histogram처럼 구간화 집계 계산이 필요한 타입도 존재
    • 레이어는 정의된 순서대로 렌더링
  • PLACE는 DRAW의 형제 절로, 테이블 데이터 대신 리터럴 값을 사용하는 annotation 전용 절
    • 예시 시각화는 히스토그램 레이어, 규칙선 annotation 레이어, 텍스트 annotation 레이어의 세 레이어로 구성
    • 하나의 레이어가 하나의 그래픽 객체에만 대응하지는 않으며, 같은 타입의 여러 개별 객체 렌더링 가능
  • SCALE은 데이터값을 aesthetic에 맞는 값으로 변환하는 절
    • 문자열 범주를 실제 색상으로 바꾸는 역할 외에도 연속형 변환, break point 정의, ordinal 또는 binned 같은 스케일 타입 설정 가능
  • LABEL은 제목, 부제, 축 제목, 범례 제목 등 텍스트 라벨 추가 및 수정 기능 지원

한 걸음 물러서서

  • 위 예시는 많은 구문을 포함하지만, 핵심 문법의 중요한 부분을 한 번에 포괄
  • 많은 시각화 쿼리는 이보다 훨씬 단순한 형태 가능
  • astronauts.parquet를 사용한 성별별 출생연도 박스플롯 예시 제시
    • VISUALIZE sex AS x, year_of_birth AS y FROM 'astronauts.parquet'
    • DRAW boxplot
  • 코드 길이는 다른 플로팅 시스템보다 길 수 있지만, 더 구조적, 조합 가능, 자기서술적 특성 보유
  • 이러한 특성은 사용자가 모든 종류의 플롯 동작을 내면화하기 쉽게 만들며, 미래의 LLM 코딩 도우미에도 유리함
  • 같은 관계를 지터 산점도로 쉽게 전환 가능
    • DRAW point
    • SETTING position => 'jitter'
  • 지터가 데이터 분포를 따르도록 지정해 violin plot 성격 부여 가능
    • SETTING position => 'jitter', distribution => 'density'
  • 이런 구문 구조와 조합성은 탐색적 분석과 시각화 설계에서 반복 작업을 쉽게 만듦

왜 ggsql인가

  • ggsql 개발 이유로 다섯 가지 제시
    • 주로 SQL로 작업하는 데이터 분석가와 데이터 과학자 지원 목적
    • SQL과 grammar of graphics의 높은 궁합
    • R이나 Python 같은 전체 프로그래밍 언어 없이도 강력한 코드 기반 시각화 도구 구축 목적
    • LLM의 뛰어난 SQL 처리 능력과 새로운 시각화 인터페이스 가능성
    • ggplot2 18년 개발 경험을 새로운 바탕에 적용하려는 의도

  • Hello, SQL user

    • 데이터 과학 혁명 과정에서 R과 Python이 주목받는 동안에도 SQL은 데이터 작업의 신뢰 가능한 기반 역할 지속
    • 오직 SQL 또는 주로 SQL만 사용하는 데이터 작업자 다수 존재
    • 이들에게 주어진 기존 시각화 선택지는 본문 기준으로 대체로 비최적
      • 데이터를 내보내 R 또는 Python 사용
      • 재현성 지원이 부족한 GUI 기반 BI 도구 사용
      • 쿼리 내부 직접 시각화 도구 사용, 그러나 충분히 강력하거나 인체공학적이지 않다고 판단
    • ggsql 문법은 SQL 사용자가 즉시 이해할 수 있도록 설계됨
      • 조합 가능하고 선언적인 절에 대한 기대 활용
    • ggsql은 시각화 방식 개선뿐 아니라 SQL 사용자를 Quarto 기반의 코드 기반 보고서 생성 및 공유 생태계로 끌어들이는 역할 수행

  • 선언적 데이터 가공, 선언적 시각화

    • SQL은 하나 이상의 테이블에 저장된 관계형 데이터를 다루는 도메인 특화 언어
    • SQL 구문은 관계대수 개념에 기반하며, 데이터 조작을 구조적으로 생각하는 방식 제공
    • SQL 의미론은 함수형이 아니라 선언적인 모듈식 연산 집합 정의
    • grammar of graphics는 데이터 시각화 개념을 모듈식 구성요소로 분해하는 이론적 틀
    • ggplot2 같은 도구가 이 개념을 실제 구현으로 옮김
    • grammar of graphics 역시 함수형보다 선언적인 모듈식 연산 집합 정의
    • 두 체계는 각자 영역에 접근하는 방식에서 공통점이 크며, 원시 데이터부터 최종 시각화까지 자연스럽고 강력한 전체 파이프라인 구성 가능

  • No runtime, no problem

    • ggplot2는 R 설치, plotnine은 Python 설치 필요
    • 반면 단일하고 집중된 실행 파일 기반 시각화 도구에는 분명한 이점 존재
      • 다른 도구에 작은 실행 파일을 내장하기가 R/Python 번들링 또는 설치 요구보다 쉬움
      • 범위가 작아 악의적이거나 실수에 의한 코드 실행을 sandbox로 제한하기 쉬움
    • 이런 특성은 ggsql을 AI 분석 도우미나 여러 환경에서 코드를 실행하는 코드 기반 보고 도구 통합에 더 매력적인 선택지로 만듦
    • 해석형 언어에서 벗어나며 제약도 있지만 얻는 부분도 큼
    • 가장 중요한 장점은 엄격한 구조 덕분에 백엔드에서 레이어당 전체 데이터 파이프라인을 단일 SQL 쿼리로 실행할 수 있다는 점
      • 예시로 100억 건 거래 데이터의 bar plot 작성 시 데이터 웨어하우스에서 각 막대의 count 값만 가져오고 100억 행 전체는 가져오지 않음
      • boxplot, density plot 같은 더 복잡한 레이어 타입에도 같은 원리 적용
    • 이는 전체 데이터를 먼저 물질화한 뒤 계산하고 플로팅하는 대부분의 시각화 도구와 대비되는 특성

  • SELECT pod_door FROM bay WHERE closed

    • LLM은 자연어를 SQL로 변환하는 데 매우 효과적임이 입증됨
    • ggsql에도 같은 수준의 효과 적용 가능하다는 기대 제시
    • querychat에서 ggsql을 통해 자연어 기반 시각적 데이터 탐색이 이미 가능
    • ggsql은 R이나 Python보다 더 안전하고 가벼운 런타임이므로, 프로덕션 환경에 코딩 에이전트를 배포할 때 더 높은 확신 제공

  • We are now wise beyond our years

    • ggplot2 18년 개발과 유지보수는 데이터 시각화 문법, 사용성, 설계에 대한 18년의 축적된 사고 의미
    • 이 지식이 모두 ggplot2로 다시 들어갈 수는 없음
      • 오래전에 정해진 결정과 사용자 기대를 존중해야 하며, 도전하더라도 매우 점진적으로만 가능
    • ggsql은 blank slate
      • 처음부터 새로 구축하는 프로젝트
      • 시각화 도구에 대한 기존 기대가 없는 환경을 위해 설계된 시스템
    • 이러한 출발점이 개발 과정에서 해방감과 활력을 줬으며, 그것이 사용자 경험에도 드러난다고 밝힘

미래

  • 현재 버전은 alpha-release이며 아직 완료되지 않음
  • 앞으로 추가하고자 하는 비포괄적 목록 제시
    • Rust로 처음부터 작성한 새로운 고성능 writer
    • 테마 인프라
    • 인터랙티비티
    • Posit Workbench 또는 Positron에서 Connect까지의 종단간 배포 흐름
    • 완전한 ggsql language server와 코드 formatter
    • 공간 데이터 지원

  • ggplot2 개발에는 어떤 의미인가

    • ggplot2 사용자는 ggsql 발표를 두려움과 기대가 섞인 시선으로 볼 수 있다는 언급
    • Posit가 ggplot2를 뒤로하고 ggsql에 집중하는 것인지에 대한 답은 아님
    • ggplot2는 이미 매우 성숙하고 안정적이지만 계속 지원하고 확장할 계획
    • ggsql 개발 과정이 ggplot2에 새로운 기능을 제공하는 데도 기여하길 기대

더 알아보기

  • ggsql을 바로 사용하고 싶다면 ggsql 웹사이트의 Getting started 섹션에서 설치 안내와 튜토리얼 확인 가능
  • 문서 페이지에서는 ggsql이 지원하는 전체 기능 확인 가능
  • 사용자 경험에 대한 피드백을 기대한다는 언급 포함

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
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로 바뀌고, 반환된 점들로 최종 선 차트를 그리는 구조임
    • 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 시각화 혼합 도구들에서 자주 겪던 문제를 이 방식이 잘 풀어주는 것처럼 보였음

답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.