- Công cụ trực quan hóa dựa trên cú pháp SQL, kết hợp truy vấn dữ liệu và cấu hình biểu đồ trong một luồng duy nhất thông qua các mệnh đề như
VISUALIZE, DRAW, PLACE, SCALE, LABEL
- Có thể ánh xạ các cột vào thuộc tính trực quan và xây dựng scatter plot, biểu đồ cột, histogram, boxplot, cả các thành phần chú thích trong cùng một cấu trúc bằng cách kết hợp layer
- Kết quả truy vấn SQL được chuyển thẳng thành đầu vào trực quan hóa; một số layer còn có cấu trúc chỉ lấy phần tổng hợp bằng một lần chạy truy vấn SQL duy nhất, thuận lợi cho xử lý dữ liệu quy mô lớn
- Được định hướng như một tệp thực thi nhỏ gọn, tập trung có thể dùng mà không cần runtime R hay Python, qua đó nổi bật về mức độ phù hợp để tích hợp với công cụ báo cáo dựa trên mã và trợ lý phân tích AI
- Phiên bản hiện tại là alpha-release, đồng thời đưa ra kế hoạch mở rộng như writer hiệu năng cao, theme, interactivity, language server, formatter và hỗ trợ dữ liệu không gian
Giới thiệu ggsql
- ggsql là một triển khai grammar of graphics dựa trên cú pháp SQL, bổ sung khả năng trực quan hóa có cấu trúc vào SQL
- Có thể dùng trong Quarto, Jupyter notebooks, Positron, VS Code, v.v.
- Được thiết kế để người dùng SQL có thể viết mã trực quan hóa theo cách quen thuộc
- Cấu trúc mệnh đề khai báo và có thể kết hợp của SQL cũng được áp dụng vào ngữ pháp trực quan hóa
- Bài viết trình bày động cơ và ví dụ sử dụng, đồng thời triển khai các cú pháp cốt lõi của ggsql
Ví dụ cơ bản
-
Biểu đồ đầu tiên
- Có thể tạo scatter plot với bộ dữ liệu tích hợp
penguins
VISUALIZE bill_len AS x, bill_dep AS y FROM ggsql:penguins
DRAW point
- Trong
VISUALIZE, các cột dữ liệu được ánh xạ vào thuộc tính trực quan, và DRAW point tạo layer điểm bằng cách dùng ánh xạ mặc định đó
- Chỉ cần thêm
species AS color là có thể áp dụng phân biệt danh mục theo màu sắc
VISUALIZE bill_len AS x, bill_dep AS y, species AS color FROM ggsql:penguins
DRAW point
- Có thể chồng thêm layer đường hồi quy lên trên layer điểm bằng
DRAW smooth
- Ánh xạ màu theo loài vẫn được giữ nguyên nên sẽ tạo đường riêng cho từng
species
- Thay vì dùng loại biểu đồ được định sẵn, công cụ chọn cách kết hợp các thành phần mô-đun
- Có thể chuyển sang một kiểu trực quan hóa hoàn toàn khác mà vẫn giữ cùng cấu trúc
VISUALIZE island AS x, species AS color FROM ggsql:penguins
DRAW bar
-
Ví dụ hoàn chỉnh
- Phần trên là truy vấn SQL thông thường, còn từ
VISUALIZE trở đi là truy vấn trực quan hóa
- Ví dụ sử dụng backend DuckDB
- Phần SQL dùng
ROW_NUMBER() và QUALIFY để chỉ giữ lại mission mới nhất theo từng tên từ astronauts.parquet
- Sau đó kết hợp hai tập dữ liệu
- Tính
year_of_selection - year_of_birth thành age và gán danh mục Age at selection
- Tính
year_of_mission - year_of_birth thành age và gán danh mục Age at mission
- Gộp hai kết quả bằng
UNION ALL
- Trong truy vấn trực quan hóa, ánh xạ
age AS x, category AS fill rồi dùng DRAW histogram
- Chỉ định
SETTING binwidth => 1, position => 'identity'
- Thêm chú thích vị trí trung bình đã tính sẵn bằng
PLACE rule
x => (34, 44), linetype => 'dotted'
- Thêm chú thích văn bản bằng
PLACE text
x => (34, 44, 60)
y => (66, 49, 20)
- Nhãn bao gồm
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!
- Chỉ định
hjust => 'left', vjust => 'top', offset => (10, 0)
SCALE fill TO accent chuyển các giá trị được ánh xạ vào fill sang bảng màu accent
- Mệnh đề
LABEL điều khiển tiêu đề, phụ đề, nhãn trục x và nhãn chú giải
- Tiêu đề
How old are astronauts on their most recent mission?
- Phụ đề
Age of astronauts when they were selected and when they were sent on their mission
- Trục x
Age of astronaut (years)
fill => null
Cấu trúc truy vấn trực quan hóa
- Trước
VISUALIZE là SQL thuần, và bảng kết quả không được trả về dạng bảng mà được chuyển trực tiếp làm đầu vào trực quan hóa
- Các bảng hoặc CTE được tạo trong phần SQL có thể được tham chiếu trong truy vấn trực quan hóa
- Nếu dữ liệu đã ở dạng phù hợp để trực quan hóa thì có thể bỏ qua phần SQL
VISUALIZE year_of_selection AS x, year_of_mission AS y FROM 'astronauts.parquet'
VISUALIZE hoặc VISUALISE đánh dấu kết thúc truy vấn SQL và bắt đầu truy vấn trực quan hóa
- Ánh xạ có vai trò kết nối các cột với thuộc tính trực quan, tức aesthetics
- Trong ví dụ,
age tương ứng với vị trí trục x, category tương ứng với màu tô
DRAW thêm layer vào trực quan hóa
- Có loại đơn giản như
point, và cũng có loại như histogram cần tính toán tổng hợp theo khoảng
- Các layer được render theo đúng thứ tự đã định nghĩa
PLACE là mệnh đề ngang hàng với DRAW, chuyên dùng cho annotation bằng giá trị literal thay vì dữ liệu bảng
- Biểu đồ trong ví dụ gồm ba layer: layer histogram, layer annotation đường quy tắc và layer annotation văn bản
- Một layer không nhất thiết chỉ tương ứng với một đối tượng đồ họa duy nhất; nó có thể render nhiều đối tượng riêng lẻ cùng loại
SCALE là mệnh đề chuyển đổi giá trị dữ liệu sang giá trị phù hợp với aesthetic
- Ngoài việc biến danh mục chuỗi thành màu sắc thực tế, nó còn có thể xử lý biến đổi liên tục, định nghĩa break point, hoặc đặt loại scale như ordinal hay binned
LABEL hỗ trợ thêm và chỉnh sửa nhãn văn bản như tiêu đề, phụ đề, tiêu đề trục, tiêu đề chú giải, v.v.
Lùi lại một bước
- Ví dụ trên chứa nhiều cú pháp, nhưng đồng thời bao quát những phần quan trọng của ngữ pháp cốt lõi
- Nhiều truy vấn trực quan hóa có thể đơn giản hơn rất nhiều
- Bài viết đưa ra ví dụ boxplot năm sinh theo giới tính dùng
astronauts.parquet
VISUALIZE sex AS x, year_of_birth AS y FROM 'astronauts.parquet'
DRAW boxplot
- Độ dài mã có thể lớn hơn các hệ thống vẽ biểu đồ khác, nhưng đổi lại có các đặc tính có cấu trúc hơn, có thể kết hợp, tự mô tả
- Những đặc tính này giúp người dùng dễ nội tại hóa cách vận hành của mọi loại biểu đồ, đồng thời cũng có lợi cho các trợ lý lập trình LLM trong tương lai
- Có thể dễ dàng chuyển cùng mối quan hệ đó sang scatter plot có jitter
DRAW point
SETTING position => 'jitter'
- Có thể chỉ định để jitter đi theo phân bố dữ liệu, tạo tính chất của violin plot
SETTING position => 'jitter', distribution => 'density'
- Cấu trúc cú pháp và khả năng kết hợp như vậy giúp lặp lại công việc dễ dàng hơn trong phân tích khám phá và thiết kế trực quan hóa
Vì sao là ggsql
- Bài viết nêu ra năm lý do phát triển ggsql
- Nhằm hỗ trợ các nhà phân tích dữ liệu và nhà khoa học dữ liệu chủ yếu làm việc với SQL
- SQL và grammar of graphics rất tương hợp với nhau
- Mục tiêu xây dựng một công cụ trực quan hóa mạnh mẽ dựa trên mã mà không cần ngôn ngữ lập trình đầy đủ như R hay Python
- Khả năng xử lý SQL xuất sắc của LLM và tiềm năng cho giao diện trực quan hóa mới
- Ý định áp dụng 18 năm kinh nghiệm phát triển ggplot2 lên một nền tảng mới
-
Hello, SQL user
- Trong khi R và Python được chú ý trong cuộc cách mạng khoa học dữ liệu, SQL vẫn tiếp tục là nền tảng đáng tin cậy cho công việc dữ liệu
- Có rất nhiều người làm việc với dữ liệu chỉ dùng SQL hoặc chủ yếu dùng SQL
- Theo bài viết, các lựa chọn trực quan hóa hiện có dành cho họ phần lớn chưa tối ưu
- Xuất dữ liệu ra để dùng R hoặc Python
- Dùng công cụ BI dạng GUI thiếu hỗ trợ tốt cho tính tái lập
- Dùng công cụ trực quan hóa ngay trong truy vấn, nhưng bị đánh giá là chưa đủ mạnh hoặc chưa đủ thuận tiện
- Ngữ pháp ggsql được thiết kế để người dùng SQL có thể hiểu ngay lập tức
- Tận dụng kỳ vọng về các mệnh đề có thể kết hợp và mang tính khai báo
- ggsql không chỉ cải thiện cách trực quan hóa mà còn đóng vai trò đưa người dùng SQL vào hệ sinh thái tạo và chia sẻ báo cáo dựa trên mã của Quarto
-
Biến đổi dữ liệu khai báo, trực quan hóa khai báo
- SQL là ngôn ngữ chuyên biệt theo miền để xử lý dữ liệu quan hệ được lưu trong một hay nhiều bảng
- Cú pháp SQL dựa trên các khái niệm của đại số quan hệ, cung cấp cách suy nghĩ có cấu trúc về thao tác dữ liệu
- Ngữ nghĩa SQL không mang tính hàm mà là tập hợp các phép toán mô-đun mang tính khai báo
- grammar of graphics là một khung lý thuyết phân rã khái niệm trực quan hóa dữ liệu thành các thành phần mô-đun
- Các công cụ như ggplot2 đã chuyển khái niệm này thành triển khai thực tế
- grammar of graphics cũng là tập hợp các phép toán mô-đun mang tính khai báo hơn là theo kiểu hàm
- Hai hệ thống có nhiều điểm chung trong cách tiếp cận lĩnh vực của mình, từ đó có thể tạo nên một pipeline tổng thể tự nhiên và mạnh mẽ từ dữ liệu thô tới trực quan hóa cuối cùng
-
No runtime, no problem
- ggplot2 cần cài R, còn plotnine cần cài Python
- Trong khi đó, công cụ trực quan hóa dựa trên một tệp thực thi đơn lẻ, tập trung có những lợi thế rõ ràng
- Việc nhúng một tệp thực thi nhỏ vào công cụ khác dễ hơn so với đóng gói hoặc yêu cầu cài R/Python
- Phạm vi nhỏ hơn nên dễ giới hạn việc thực thi mã độc hại hoặc vô tình bằng sandbox
- Những đặc tính này khiến ggsql trở thành lựa chọn hấp dẫn hơn để tích hợp vào trợ lý phân tích AI hoặc công cụ báo cáo dựa trên mã chạy mã trong nhiều môi trường
- Việc rời xa ngôn ngữ thông dịch cũng có đánh đổi, nhưng cái được là rất lớn
- Lợi thế quan trọng nhất là nhờ cấu trúc nghiêm ngặt, backend có thể chạy toàn bộ pipeline dữ liệu của từng layer bằng một truy vấn SQL duy nhất
- Ví dụ, khi vẽ bar plot từ 10 tỷ bản ghi giao dịch, hệ thống chỉ lấy giá trị count của từng cột từ kho dữ liệu thay vì kéo toàn bộ 10 tỷ hàng về
- Nguyên lý tương tự cũng áp dụng cho các loại layer phức tạp hơn như boxplot hay density plot
- Đây là đặc điểm đối lập với đa số công cụ trực quan hóa vốn thường materialize toàn bộ dữ liệu trước rồi mới tính toán và vẽ
-
SELECT pod_door FROM bay WHERE closed
- LLM đã được chứng minh là rất hiệu quả trong việc chuyển ngôn ngữ tự nhiên thành SQL
- Bài viết cho rằng mức độ hiệu quả tương tự cũng có thể áp dụng cho ggsql
- Trong
querychat, việc khám phá dữ liệu trực quan bằng ngôn ngữ tự nhiên đã khả thi thông qua ggsql
- Vì ggsql có runtime an toàn và nhẹ hơn R hoặc Python, nó mang lại mức độ tự tin cao hơn khi triển khai coding agent trong môi trường production
-
We are now wise beyond our years
- 18 năm phát triển và bảo trì ggplot2 đồng nghĩa với 18 năm tích lũy suy nghĩ về ngữ pháp trực quan hóa dữ liệu, tính khả dụng và thiết kế
- Không phải toàn bộ tri thức đó đều có thể đưa trở lại ggplot2
- Cần tôn trọng các quyết định từ lâu và kỳ vọng của người dùng, và ngay cả khi muốn thách thức chúng thì cũng chỉ có thể làm rất dần dần
- ggsql là một blank slate
- Một dự án được xây dựng mới hoàn toàn từ đầu
- Một hệ thống được thiết kế cho môi trường không có kỳ vọng sẵn có về công cụ trực quan hóa
- Tác giả cho biết điểm xuất phát này mang lại cảm giác giải phóng và tràn đầy năng lượng trong quá trình phát triển, và điều đó cũng thể hiện trong trải nghiệm người dùng
Tương lai
- Phiên bản hiện tại là alpha-release và vẫn chưa hoàn thiện
- Bài viết đưa ra danh sách không đầy đủ về những gì muốn bổ sung tiếp theo
- Một writer hiệu năng cao mới được viết lại hoàn toàn bằng Rust
- Hạ tầng theme
- Interactivity
- Luồng triển khai end-to-end từ Posit Workbench hoặc Positron tới Connect
- Language server và formatter hoàn chỉnh cho ggsql
- Hỗ trợ dữ liệu không gian
-
Điều đó có ý nghĩa gì với việc phát triển ggplot2
- Bài viết nhắc rằng người dùng ggplot2 có thể nhìn thông báo về ggsql với cảm giác vừa lo lắng vừa kỳ vọng
- Câu trả lời cho việc Posit có đang bỏ ggplot2 để tập trung vào ggsql hay không là không
- ggplot2 đã rất trưởng thành và ổn định, nhưng vẫn sẽ tiếp tục được hỗ trợ và mở rộng
- Tác giả kỳ vọng quá trình phát triển ggsql cũng sẽ góp phần mang lại tính năng mới cho ggplot2
Tìm hiểu thêm
- Nếu muốn dùng ggsql ngay, có thể xem hướng dẫn cài đặt và tutorial trong phần Getting started trên website ggsql
- Ở trang tài liệu có thể xem toàn bộ tính năng mà ggsql hỗ trợ
- Bài viết cũng cho biết họ mong nhận được phản hồi về trải nghiệm người dùng
1 bình luận
Ý kiến trên Hacker News
Có thể là vì tôi chỉ lướt nhanh bài viết, nhưng chỉ đọc blog post và tài liệu thì tôi cảm thấy mối quan hệ với cơ sở dữ liệu SQL chưa được giải thích rõ ràng
Ban đầu tôi đoán đây chỉ là một kiểu DSL trực quan hóa giống SQL do thư viện biểu đồ frontend xử lý
Tài liệu anatomy khiến tôi hiểu như vậy, nhưng trong FAQ ở câu hỏi "Can I use SQL queries inside the VISUALISE clause" lại ghi rằng một phần cú pháp được chuyển thẳng xuống cơ sở dữ liệu
Trang chủ có viết "ggsql interfaces directly with your database", nhưng thực tế kết nối như thế nào thì không hiện ra rõ nên khá dễ gây bối rối
ggsql có thể kết nối trực tiếp tới backend cơ sở dữ liệu, và nếu muốn thì cũng có thể chạy bằng DuckDB in-memory
Truy vấn trực quan hóa được chuyển thành các truy vấn SQL cho từng layer của hình vẽ, rồi dùng các bảng kết quả đó để render
Ví dụ, một truy vấn như
VISUALISE page_views AS x FROM visits DRAW smoothsẽ được biến thành SQL để tính smoothing kernel trên dữ liệu, rồi dùng các điểm trả về để vẽ line chart cuối cùngreader xử lý kết nối cơ sở dữ liệu và việc tạo SQL dialect phù hợp cho từng DB
Ở giai đoạn alpha hiện tại, nó hỗ trợ duckdb, sqlite và một reader ODBC mang tính thử nghiệm; quá trình phát triển hiện chủ yếu xoay quanh DuckDB dựa trên tệp cục bộ
Ý tưởng cốt lõi là chuyển truy vấn trực quan hóa thành nhiều truy vấn SQL, chạy chúng trong cơ sở dữ liệu, rồi chỉ dùng lượng nhỏ kết quả được trả về để dựng biểu đồ
Vì vậy dù có rất nhiều dòng dữ liệu, nó vẫn có thể chỉ tính bằng SQL các thống kê cần cho histogram, rồi lấy về vài điểm cần thiết để vẽ chiều cao các cột
Mặc định là kết nối DuckDB in-memory; trong CLI có thể dùng
--readerđể kết nối tới tệp trên đĩa hoặc URI ODBCTrong Positron thì có thể cấu hình dễ hơn qua pane "Connections", còn trong ggsql Jupyter kernel có thể chỉ định reader bằng magic SQL comment
Nhóm phát triển cũng dự định bổ sung thêm vào tài liệu phần giải thích về các tích hợp với công cụ bên ngoài này
SQL là ngôn ngữ thao tác dữ liệu mang tính khai báo, thường được dùng để truy vấn cơ sở dữ liệu nhưng không chỉ bị ràng buộc với cơ sở dữ liệu
Bạn có thể áp dụng SQL cho flat file, data stream, hay dữ liệu trong bộ nhớ chương trình
Ngược lại, tôi cũng cho rằng có thể truy vấn cơ sở dữ liệu mà không cần SQL
Khi lướt qua bài viết, tôi cố tìm xem tại sao thứ này lại cần thiết và nó giải quyết vấn đề gì, nhưng không thấy thật sự thuyết phục
Tôi đoán có lẽ mục tiêu là trực quan hóa ngay các bảng trong cơ sở dữ liệu SQL từ xa, giảm bước phải kéo dữ liệu về R data frame trước rồi mới chạy ggplot
Nhưng tôi vẫn thắc mắc vì sao lại phải tạo thêm một ngôn ngữ kiểu SQL mới
Trong R đã có dbplyr để dịch qua lại giữa R và SQL, nên có vẻ trực diện hơn nếu mở rộng ggplot để hỗ trợ trực tiếp đối tượng tbl của dbplyr và tự sinh SQL
Hoặc cũng có thể vì bản thân SQL đã quá quen thuộc, nên nhiều người sẽ muốn làm kiểu công việc ggplot bằng cú pháp này
Mãi đến khi gần đọc hết tài liệu tôi mới hiểu rằng đây là một ứng dụng trực quan hóa độc lập với backend DuckDB và SQLite, hiện render bằng Vegalite và về sau dự định mở rộng thêm backend lẫn renderer
Như một bình luận bên dưới nói, nó có vẻ là công cụ giúp người dùng thiên về SQL tạo trực quan hóa mà không cần biết Python hay R
Dĩ nhiên tôi cũng đồng ý là bài giới thiệu lẽ ra nên làm rõ điểm đó tốt hơn
Theo kinh nghiệm của tôi, ngôn ngữ chung mà analyst, scientist và engineer cùng chia sẻ thường vẫn là SQL
Bạn có thể làm điều tương tự bằng R, nhưng trên thực tế dự án không nhất thiết được viết bằng R hay Python; thay vào đó thì cơ sở dữ liệu SQL và engine truy cập thường đã sẵn có
Tôi cũng hay dùng SQL cell trong marimo notebook với DuckDB chạy nền, nên nếu có thể plot trực tiếp từ SQL thì sẽ rất tiện
Cuối cùng, tôi luôn thấy API vẽ biểu đồ trong Python khá khó nhớ và khó thành thạo
Chỉ để vẽ một scatterplot đơn giản bằng matplotlib thôi cũng đã có quá nhiều boilerplate, nên có một cú pháp thống nhất ngay trong cùng ngôn ngữ truy vấn sẽ rất hay
Điểm thú vị nằm ở sự kết hợp giữa SQL như một giao diện và tính hình thức của GoG, hơn là ở một thư viện cụ thể
Renderer hay runtime thực tế tất nhiên vẫn quan trọng, nhưng theo tôi chúng gần với chi tiết triển khai hơn
Dĩ nhiên không phải là điều mà R, Python hay matplotlib không thể làm dễ dàng với số dòng mã tương tự
Nhưng việc sandboxing các môi trường đó để an toàn trước đầu vào độc hại thì khó hơn, còn với một ngôn ngữ khai báo như thế này, bạn có thể host nó theo kiểu người dùng không đáng tin vẫn nhập ggsql nhưng hệ thống chỉ tạo biểu đồ
Xét theo nghĩa đó thì nó rõ ràng hữu ích
Dù vậy, trong phần lớn trường hợp thông thường, có lẽ bảo LLM yêu thích của bạn sinh mã matplotlib sẽ là lựa chọn dễ hơn
Tôi ủng hộ dự án này, và rất đồng ý rằng khái niệm của nó khớp với SQL một cách tự nhiên
Trong R, kiểu chuẩn bị dữ liệu bằng WITH rồi nối tiếp bằng VISUALIZE gần như cũng giống hệt code plotting của tôi
Tuy vậy, ngoài ưu điểm là một DSL đơn giản, tôi vẫn chưa rõ lợi thế so với ggplot2 là gì đến mức đáng để chấp nhận chi phí tạo thêm một DSL nữa
Gần như lý do duy nhất khiến tôi rời ggplot2 vì trực quan hóa là khi vượt ra ngoài các trường hợp chuẩn có sẵn geom thì việc làm trực quan hóa phi tiêu chuẩn khá khó
Khi muốn tạo thứ gì đó hơi khác đi một chút, nhiều lúc hạ xuống primitive drawing ở tầng thấp lại dễ hơn rất nhiều so với việc cố bẻ ra một adapter thân thiện với ggplot
Ngay cả việc gói một phần đặc tả thường dùng vào hàm cũng không phải lúc nào trơn tru, tùy vào việc nó được ghép bằng
+hay nối bằng|>hoặc kiểu pipe cũ%>%Và cũng hoàn toàn không có kế hoạch dừng phát triển ggplot2
ggsql là một dự án phần nào nhằm tiếp cận nhóm người dùng mới và đặt trực quan hóa mạnh mẽ vào những ngữ cảnh mới
Nếu bạn dành phần lớn thời gian trong R thì có lẽ bạn không phải người dùng mục tiêu cốt lõi
Dù vậy, trong đó vẫn có vài điểm khá thú vị mà ggplot2 không có, nên tôi nghĩ khám phá thử cũng vui
|>và%>%không phải cùng một toán tử|>là base pipe xuất hiện tương đối gần đây và nhanh hơn, nhưng nó không hỗ trợ những thứ như placeholder dấu chấm của%>%khi cần truyền vào vị trí không phải đối số đầu tiên của hàmVì thế trong một số trường hợp,
%>%vẫn giúp biểu thức gọn hơn đôi chútCái này thật sự rất hay
Bên tôi cũng đã đi tới kết luận tương tự khi xây dựng GFQL, một graph dataframe query language
Cụ thể là chúng tôi cần một giao diện thân thiện với LLM cho stack trực quan hóa và phân tích mà không cần sandbox mã nguồn
Chúng tôi nhận thấy chỉ với phần mở rộng opencypher cơ bản cũng đã có thể tạo ra pipeline phân tích trực quan GPU khá phong phú, và vì cùng lý do đó nên cách tiếp cận đi tới SQL trong thế giới bảng biểu cũng có vẻ rất hợp lý
Nếu muốn xem ví dụ phía GFQL, có thể tham khảo overall pipelines nói về nạp dữ liệu, biến đổi shape, enrichment dựa trên thuật toán, visual encoding và pipeline hạng nhất, cùng với declarative visual encodings ở dạng gọi đơn giản
Trông cái này khá ổn
Tuy vậy, tôi muốn có một cách để nó degrade một cách thanh lịch ngay cả trong môi trường không có hỗ trợ cú pháp
Tôi cũng từng nghĩ ra một hướng tiếp cận tương tự nhưng bên trong SQL, dù đơn giản hơn nhiều so với GoG, và phía đó có thể degrade được
Cú pháp không phải kiểu dễ đọc, nhưng đại loại như sqlnb spec
Nếu được thì mong bạn giải thích cụ thể hơn một chút
Một công cụ cùng hướng khác làm tôi nghĩ tới là Shaper dựa trên DuckDB
Nó tiếp cận dashboard toàn bộ theo kiểu SQL-first, và xem tài liệu getting started thì thấy định hướng khá giống
Trước hết phải nói là ggsql trông rất tuyệt và tôi muốn thử ngay
Nhưng tôi thấy có một điểm thiếu khá rõ trong tài liệu, đó là khó tìm phần giải thích về định dạng đầu ra
Có xuất được PDF không, có ra SVG hay PNG không, và điều khiển đầu ra như kích thước ngang dọc thì làm thế nào đều không hiện ra rõ
Gợi ý gần nhất tôi tìm thấy chỉ là
chart.display()vàchart.save("chart.html")trong tài liệu thư viện PythonĐầu ra này có thể được render thành biểu đồ tương tác, SVG, PNG... bằng các công cụ sẵn có, và việc điều khiển kích thước cũng sẽ theo cấu hình của các công cụ đó
ggsql Jupyter kernel có thể dùng vegalite spec này để xuất biểu đồ trong tài liệu Quarto
Về sau chúng tôi dự định tạo một writer hiệu năng cao mới không cần qua bước vegalite trung gian, nên khi đó có lẽ sẽ trả lời rõ ràng hơn cho kiểu câu hỏi này
Tôi tò mò không biết trong tương lai gần hay xa có kế hoạch tích hợp với các gói mở rộng ggplot2 như ggplot2 extension packages hay không
Nếu đây là điều đã được nhắc tới rồi thì xin lỗi vì tôi đã bỏ sót
Mục tiêu của dự án này không phải là thay thế ggplot2 mà là cung cấp một cách tiếp cận khác
Nó có thể làm được nhiều việc mà ggplot2 làm, và có thể cả một số việc ggplot2 không làm được, nhưng tôi dự đoán rằng trong thời gian dài nữa ggplot2 vẫn sẽ mạnh hơn cho rất nhiều tác vụ
Cái này trông thật sự rất hay, tôi định sớm thử
Điều khiến tôi thấy rất thuyết phục là phần giải thích trong tài liệu grammar
Việc dùng SELECT quen thuộc để chọn dữ liệu, rồi chuyển từ bảng sang plot bằng
VISUALIZEhoặcVISUALISE, sau đó ánh xạ aesthetics bằngDRAW, rồi lần lượt thêmSCALE,FACET,LABELđã tạo cảm giác tiếp nối đúng lối tư duy cấu trúc của SQLTôi thực sự thích cách tiếp cận theo layer
Khi bắt đầu vượt ra ngoài các biểu đồ cơ bản, cách này có vẻ giải quyết khá tốt những vấn đề mà tôi thường gặp ở các công cụ trộn SQL với trực quan hóa khác