ggsql - SQL için grafik dilbilgisi

 (opensource.posit.co)
11 puan yazan GN⁺ 9 일 전 | 1 yorum | WhatsApp'ta paylaş
  • SQL sözdizimi tabanlı bir görselleştirme aracı olup VISUALIZE, DRAW, PLACE, SCALE, LABEL gibi ifadelerle veri sorgulama ve grafik oluşturmayı tek bir akışta birleştirir
  • Sütunları görsel özelliklere eşleyip katman birleştirme yaklaşımıyla saçılım grafiği, çubuk grafik, histogram, kutu grafiği ve açıklama öğelerini aynı yapı içinde kurmayı mümkün kılar
  • SQL sorgu sonucunu doğrudan görselleştirme girdisi olarak aktarır; bazı katmanlar ise tek bir SQL sorgusu çalıştırarak yalnızca özet veriyi aldığı için büyük ölçekli veri işlemede avantaj sağlar
  • R veya Python çalışma zamanı olmadan da kullanılabilen küçük ve odaklı bir çalıştırılabilir dosya yaklaşımıyla tasarlanmıştır; bu da kod tabanlı raporlama araçları ve yapay zeka analiz yardımcılarıyla entegrasyona uygunluğunu öne çıkarır
  • Mevcut sürüm alpha-release durumundadır; yüksek performanslı writer, temalar, etkileşimlilik, language server, formatter ve mekânsal veri desteği gibi genişleme planları sunulmuştur

ggsql'e giriş

  • ggsql, SQL sözdizimine dayalı bir graphics grammar uygulamasıdır ve SQL'e yapılandırılmış görselleştirme yetenekleri ekler
    • Quarto, Jupyter notebooks, Positron, VS Code gibi ortamlarda kullanılabilir
  • SQL kullanıcılarının aşina olduğu bir şekilde görselleştirme kodu yazabilmesi için tasarlanmıştır
    • SQL'in bildirime dayalı ve birleştirilebilir ifade yapısını görselleştirme diline de uygular
  • Gerekçeyi ve kullanım örneklerini birlikte sunarak ggsql'in temel sözdizimini açıklar

Temel örnek

  • İlk grafik

    • Yerleşik penguins veri kümesiyle bir saçılım grafiği oluşturulabilir
      • VISUALIZE bill_len AS x, bill_dep AS y FROM ggsql:penguins
      • DRAW point
    • VISUALIZE içinde veri sütunları görsel özelliklere eşlenir ve DRAW point bu varsayılan eşlemeyi kullanarak nokta katmanını oluşturur
    • Yalnızca species AS color eklenerek renk kategorileri uygulanabilir
      • VISUALIZE bill_len AS x, bill_dep AS y, species AS color FROM ggsql:penguins
      • DRAW point
    • DRAW smooth eklenerek nokta katmanının üzerine regresyon çizgisi katmanı bindirilebilir
      • Tür bazlı renk eşlemesi korunur; böylece her species için ayrı bir çizgi oluşturulur
    • Önceden tanımlı grafik türleri yerine modüler bileşenlerin birleştirildiği bir yaklaşım benimsenir
    • Aynı yapı korunarak tamamen farklı bir görselleştirmeye geçilebilir
      • VISUALIZE island AS x, species AS color FROM ggsql:penguins
      • DRAW bar

  • Tam örnek

    • Üst kısım normal SQL sorgusudur, VISUALIZE sonrasındaki bölüm ise görselleştirme sorgusudur
      • Örnekte DuckDB backend'i kullanılır
    • SQL kısmı, astronauts.parquet içinden isim başına yalnızca en güncel görevi bırakmak için ROW_NUMBER() ve QUALIFY kullanır
    • Sonrasında iki küme birleştirilir
      • year_of_selection - year_of_birth değeri age olarak hesaplanır ve Age at selection kategorisi atanır
      • year_of_mission - year_of_birth değeri age olarak hesaplanır ve Age at mission kategorisi atanır
      • İki sonuç UNION ALL ile birleştirilir
    • Görselleştirme sorgusunda age AS x, category AS fill eşlemesinden sonra DRAW histogram kullanılır
      • SETTING binwidth => 1, position => 'identity' belirtilir
    • PLACE rule ile önceden hesaplanmış ortalama konumları için açıklama eklenir
      • x => (34, 44), linetype => 'dotted'
    • PLACE text ile metin açıklamaları eklenir
      • x => (34, 44, 60)
      • y => (66, 49, 20)
      • Etiketlerde 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! yer alır
      • hjust => 'left', vjust => 'top', offset => (10, 0) belirtilir
    • SCALE fill TO accent ile fill eşleme değerleri accent renk paletine dönüştürülür
    • LABEL ifadesiyle başlık, alt başlık, x ekseni etiketi ve lejand etiketi kontrol edilir
      • Başlık How old are astronauts on their most recent mission?
      • Alt başlık Age of astronauts when they were selected and when they were sent on their mission
      • x ekseni Age of astronaut (years)
      • fill => null

Görselleştirme sorgusunun yapısı

  • VISUALIZE öncesi bölüm saf SQL'dir ve sonuç tablo olarak döndürülmek yerine doğrudan görselleştirme girdisi olarak iletilir
  • SQL bölümünde oluşturulan tablo veya CTE'ler görselleştirme sorgusunda referans alınabilir
  • Veri zaten görselleştirmeye uygun yapıdaysa SQL bölümü atlanabilir
    • VISUALIZE year_of_selection AS x, year_of_mission AS y FROM 'astronauts.parquet'
  • VISUALIZE veya VISUALISE, SQL sorgusunun bittiğini ve görselleştirme sorgusunun başladığını gösterir
  • Eşlemeler, sütunları görsel özelliklere yani aesthetics'e bağlar
    • Örnekte age x ekseni konumuna, category ise dolgu rengine karşılık gelir
  • DRAW, görselleştirmeye katman ekler
    • point gibi basit türler olduğu gibi, histogram gibi aralıklama ve toplulaştırma hesaplaması gerektiren türler de vardır
    • Katmanlar tanımlandıkları sırayla render edilir
  • PLACE, DRAW ile kardeş bir ifadedir ve tablo verisi yerine sabit değer kullanan, yalnızca annotation amaçlı bir ifadedir
    • Örnek görselleştirme; histogram katmanı, kural çizgisi annotation katmanı ve metin annotation katmanı olmak üzere üç katmandan oluşur
    • Bir katman her zaman yalnızca tek bir grafik nesnesine karşılık gelmez; aynı türde birden çok ayrı nesne render edebilir
  • SCALE, veri değerlerini ilgili aesthetic'e uygun değerlere dönüştüren ifadedir
    • Yalnızca metin kategorilerini gerçek renklere çevirmekle kalmaz; sürekli dönüşümler, break point tanımları ve ordinal ya da binned gibi ölçek türleri de ayarlanabilir
  • LABEL, başlık, alt başlık, eksen başlığı, lejand başlığı gibi metin etiketlerini ekleme ve değiştirmeyi destekler

Bir adım geri çekilip bakınca

  • Yukarıdaki örnek çok sayıda ifade içerir, ancak temel sözdiziminin önemli kısımlarını tek seferde kapsar
  • Pek çok görselleştirme sorgusu bundan çok daha basit olabilir
  • astronauts.parquet kullanılarak cinsiyete göre doğum yılı kutu grafiği örneği verilir
    • VISUALIZE sex AS x, year_of_birth AS y FROM 'astronauts.parquet'
    • DRAW boxplot
  • Kod uzunluğu diğer çizim sistemlerinden daha fazla olabilir, ancak daha yapısal, birleştirilebilir ve kendini açıklayan özellikler taşır
  • Bu özellikler, kullanıcıların her tür grafik davranışını içselleştirmesini kolaylaştırır ve gelecekteki LLM kodlama yardımcıları için de avantaj sağlar
  • Aynı ilişki kolayca jitter'lı bir saçılım grafiğine dönüştürülebilir
    • DRAW point
    • SETTING position => 'jitter'
  • Jitter'ın veri dağılımını izlemesi sağlanarak violin plot benzeri bir karakter kazandırılabilir
    • SETTING position => 'jitter', distribution => 'density'
  • Bu sözdizimsel yapı ve birleştirilebilirlik, keşifsel analiz ve görselleştirme tasarımında yinelemeli çalışmayı kolaylaştırır

Neden ggsql?

  • ggsql'in geliştirilme nedeni olarak beş madde sunulur
    • Ağırlıklı olarak SQL ile çalışan veri analistlerini ve veri bilimcilerini desteklemek
    • SQL ile graphics grammar arasındaki yüksek uyum
    • R veya Python gibi tam teşekküllü programlama dilleri olmadan da güçlü, kod tabanlı bir görselleştirme aracı kurmak
    • LLM'lerin güçlü SQL işleme becerileri ve yeni görselleştirme arayüzü olasılıkları
    • ggplot2 üzerinde 18 yıllık geliştirme deneyimini yeni bir zeminde uygulamak

  • Hello, SQL user

    • Veri bilimi devrimi boyunca R ve Python öne çıkmış olsa da SQL, veri çalışmaları için güvenilir temel olmayı sürdürdü
    • Yalnızca SQL veya çoğunlukla SQL kullanan çok sayıda veri çalışanı bulunuyor
    • Metne göre, bu kişiler için mevcut görselleştirme seçenekleri genelde ideal değil
      • Veriyi dışa aktarıp R veya Python kullanmak
      • Tekrarlanabilirlik desteği sınırlı GUI tabanlı BI araçlarını kullanmak
      • Sorgu içinde doğrudan çalışan görselleştirme araçları kullanmak; ancak bunların yeterince güçlü veya ergonomik olmadığı düşünülüyor
    • ggsql sözdizimi, SQL kullanıcılarının hemen kavrayabileceği şekilde tasarlanmıştır
      • Birleştirilebilir ve bildirime dayalı ifadelere yönelik beklentilerden yararlanır
    • ggsql, yalnızca görselleştirmeyi iyileştirmekle kalmaz; SQL kullanıcılarını Quarto tabanlı, kod tabanlı rapor oluşturma ve paylaşma ekosistemine de çekmeyi hedefler

  • Bildirime dayalı veri işleme, bildirime dayalı görselleştirme

    • SQL, bir veya daha fazla tabloda depolanan ilişkisel verilerle çalışmak için alan odaklı bir dildir
    • SQL sözdizimi ilişkisel cebir kavramlarına dayanır ve veri manipülasyonunu yapısal biçimde düşünmeyi sağlar
    • SQL anlambilimi fonksiyonel değil, bildirime dayalı modüler işlemler kümesi tanımlar
    • graphics grammar, veri görselleştirme kavramlarını modüler bileşenlere ayıran kuramsal bir çerçevedir
    • ggplot2 gibi araçlar bu kavramı pratik uygulamaya dönüştürür
    • graphics grammar da fonksiyonel olmaktan çok bildirime dayalı modüler işlemler kümesi tanımlar
    • İki sistem, kendi alanlarına yaklaşım biçimlerinde büyük ortaklık taşır; ham veriden nihai görselleştirmeye kadar doğal ve güçlü bir uçtan uca akış kurulabilir

  • No runtime, no problem

    • ggplot2 için R kurulumu, plotnine için Python kurulumu gerekir
    • Buna karşılık tek ve odaklı bir çalıştırılabilir dosyaya dayanan bir görselleştirme aracının belirgin avantajları vardır
      • Küçük bir çalıştırılabilir dosyayı başka araçların içine gömmek, R/Python paketlemek veya kurulum zorunluluğu getirmekten daha kolaydır
      • Kapsam dar olduğu için kötü niyetli ya da hatalı kod çalıştırmayı sandbox içinde sınırlamak daha kolaydır
    • Bu özellikler, ggsql'i yapay zeka analiz yardımcılarına veya farklı ortamlarda kod çalıştıran kod tabanlı raporlama araçlarına entegre etmek için daha cazip hale getirir
    • Yorumlanan dillerden uzaklaşmanın bazı kısıtları vardır, ama önemli kazanımları da bulunur
    • En önemli avantaj, katı yapı sayesinde backend'in katman başına tüm veri hattını tek bir SQL sorgusu olarak çalıştırabilmesidir
      • Örneğin 10 milyar satırlık işlem verisiyle çubuk grafik çizilirken, veri ambarından yalnızca her çubuğun count değeri alınır; 10 milyar satırın tamamı taşınmaz
      • Aynı ilke kutu grafiği, density plot gibi daha karmaşık katman türleri için de geçerlidir
    • Bu, önce tüm veriyi somutlaştırıp sonra hesaplayarak çizen çoğu görselleştirme aracından ayrışan bir özelliktir

  • SELECT pod_door FROM bay WHERE closed

    • LLM'lerin doğal dili SQL'e dönüştürmede çok etkili olduğu kanıtlanmıştır
    • Aynı düzeyde bir etkinliğin ggsql için de geçerli olacağı beklentisi dile getirilir
    • querychat içinde ggsql aracılığıyla doğal dil tabanlı görsel veri keşfi zaten mümkündür
    • ggsql, R veya Python'a kıyasla daha güvenli ve hafif bir çalışma zamanı sunduğundan, üretim ortamlarına kodlama ajanı dağıtırken daha yüksek güven verir

  • We are now wise beyond our years

    • ggplot2'nin 18 yıllık geliştirme ve bakım süreci, veri görselleştirme dilbilgisi, kullanılabilirlik ve tasarım konusunda 18 yıllık birikmiş düşünce anlamına gelir
    • Bu bilginin tamamı yeniden ggplot2'ye geri aktarılamaz
      • Uzun zaman önce alınmış kararları ve kullanıcı beklentilerini gözetmek gerekir; değişim olsa bile ancak çok kademeli olabilir
    • ggsql bir blank slatetir
      • Sıfırdan inşa edilen bir projedir
      • Görselleştirme araçlarına dair yerleşik beklentilerin bulunmadığı ortamlar için tasarlanmıştır
    • Bu başlangıç noktası, geliştirme sürecine özgürlük ve enerji kattı; bunun kullanıcı deneyimine de yansıdığı belirtiliyor

Gelecek

  • Mevcut sürüm alpha-release düzeyindedir ve henüz tamamlanmamıştır
  • İleride eklenmesi planlanan bazı başlıklar sıralanır
    • Rust ile sıfırdan yazılmış yeni, yüksek performanslı bir writer
    • Tema altyapısı
    • Etkileşimlilik
    • Posit Workbench veya Positron'dan Connect'e kadar uçtan uca dağıtım akışı
    • Tam özellikli bir ggsql language server ve kod formatter
    • Mekânsal veri desteği

  • Bunun ggplot2 geliştirmesi açısından anlamı ne?

    • ggplot2 kullanıcılarının ggsql duyurusuna hem kaygı hem de heyecanla bakabileceği belirtilir
    • Posit'in ggplot2'yi geri plana atıp ggsql'e odaklanıp odaklanmadığı sorusunun yanıtı hayırdır
    • ggplot2 zaten çok olgun ve kararlı, ancak desteklenmeye ve genişletilmeye devam edecek
    • ggsql geliştirme sürecinin ggplot2'ye yeni özellikler kazandırılmasına da katkı sağlaması umuluyor

Daha fazlasını öğrenin

  • ggsql'i hemen kullanmak isteyenler, ggsql web sitesindeki Getting started bölümünden kurulum talimatlarını ve öğreticileri bulabilir
  • Dokümantasyon sayfasında ggsql'in desteklediği tüm özellikler görülebilir
  • Kullanıcı deneyimine ilişkin geri bildirimlerin beklendiği de belirtilir

İlgili okumalar

1 yorum

 
GN⁺ 9 일 전
Hacker News yorumları

  • Yazıyı hızlıca gözden geçirmiş olmamdan da kaynaklanıyor olabilir ama, blog yazısı ve dokümanlara bakınca SQL veritabanıyla ilişkisi net biçimde açıklanmamış gibi geldi
    İlk başta bunun, frontend chart kütüphanelerinin işlediği SQL benzeri bir görselleştirme DSL’i olduğunu tahmin etmiştim
    anatomy dokümanı bana böyle hissettirdi ama SSS içindeki "Can I use SQL queries inside the VISUALISE clause" bölümünde bazı sözdiziminin doğrudan veritabanına iletildiği yazıyordu
    Ana sayfada "ggsql interfaces directly with your database" deniyor ama gerçekte nasıl bağlandığı pek anlaşılmadığı için kafa karıştırıcıydı

    • Bu eleştirinin yerinde olduğunu düşünüyorum. Kavramın kendisi biraz alışılmadık bir yapıya sahip
      ggsql doğrudan bir veritabanı backend’ine bağlanabiliyor ve istenirse in-memory DuckDB ile de çalışabiliyor
      Görselleştirme sorgusu, görselleştirmenin her katmanı için bir SQL sorgusuna dönüştürülüyor ve dönen tablo render işlemi için kullanılıyor
      Örneğin VISUALISE page_views AS x FROM visits DRAW smooth gibi bir sorgu, veri üzerinde smoothing kernel hesaplayan SQL’e çevriliyor ve dönen noktalarla son çizgi grafik oluşturuluyor
    • ggsql’de reader diye bir kavram var ve bu, SQL veritabanına bağlanan arayüz görevini üstleniyor
      reader veritabanı bağlantısını ve her VT için uygun SQL dialect üretimini yönetiyor
      Şu an alpha aşamasında duckdb, sqlite ve deneysel bir ODBC reader destekleniyor; geliştirme ise daha çok yerel dosya tabanlı DuckDB etrafında sürüyor
      Temel fikir, görselleştirme sorgusunu birden fazla SQL sorgusuna çevirip bunları veritabanında çalıştırmak ve grafiği yalnızca dönen küçük sonuçlarla kurmak
      Böylece çok fazla satır olsa bile histogram için gereken istatistikler SQL ile hesaplanabiliyor ve sadece çubuk yüksekliklerini çizmek için gereken birkaç nokta geri alınıyor
      Varsayılan bağlantı in-memory DuckDB; CLI’de --reader ile disk dosyasına ya da bir ODBC URI’sine bağlanılabiliyor
      Positron’da bunu "Connections" paneliyle daha kolay yapılandırmak mümkün ve ggsql Jupyter kernel’ında magic SQL comment ile reader belirtilebiliyor
      Dokümanlarda da bu tür harici araç entegrasyonları daha ayrıntılı anlatılacak
    • Benim de aklımda aynı soru vardı. Harici bir veritabanı sunucusundan grafik üretmek için gereken bağlantı ve bağımlılık akışının tamamını gösteren bir örnek olsa anlamak çok daha kolay olurdu
    • Bana göre SQL ile veritabanı aynı şey değil
      SQL bildirime dayalı bir veri işleme dili; veritabanı sorgulamakta sık kullanılıyor ama sadece veritabanına bağlı değil
      Düz dosyalara, veri akışlarına ve program belleğindeki verilere de SQL uygulanabilir
      Tersine, bir veritabanını SQL olmadan sorgulamak da mümkün

  • Yazıyı gözden geçirirken bunun neden gerekli olduğunu ve hangi sorunu çözdüğünü anlamaya çalıştım ama pek oturmadı
    Acaba uzak bir SQL veritabanındaki tabloları doğrudan görselleştirip önce R data frame’e çekip sonra ggplot çalıştırma adımını ortadan kaldırmak mı istiyor diye düşündüm
    Ama neden yeni bir SQL benzeri dil tasarlamak gerektiği de aklıma takıldı
    Zaten R tarafında R ile SQL arasında çeviri yapan dbplyr var; bu durumda ggplot’un dbplyr tbl nesnelerini doğrudan destekleyip SQL üretmesini sağlamak daha doğrudan olmaz mıydı diye düşündüm
    Ya da SQL zaten çok tanıdık bir dil olduğu için birçok kişinin bu sözdizimiyle ggplot benzeri işler yapmak isteyeceği mi varsayılıyor, onu da merak ettim
    Dokümanların neredeyse tamamını okuduktan sonra bunun DuckDB ve SQLite backend’leri olan bağımsız bir görselleştirme uygulaması olduğunu, şu anda Vegalite ile render ettiğini ve ileride daha fazla backend ile renderer eklemeyi planladığını anladım
    Aşağıdaki yorumda dendiği gibi, Python ya da R bilmeyen SQL odaklı kullanıcıların görselleştirme yapabilmesi için tasarlanmış bir araç gibi göründü

    • Bu duyuruyu okurken bana oldukça ilginç geldi; neden cazip olduğunu kendi açımdan açıklayabilirim sanırım
      Tabii ki duyuru yazısının bunu biraz daha iyi anlatmış olmasını isterdim, buna katılıyorum
      Benim deneyimimde analistler, bilim insanları ve mühendislerin ortak paylaştığı dil çoğu zaman SQL oluyor
      Aynı şeyi R ile de yapmak mümkün ama gerçek projeler her zaman R ya da Python ile yazılmıyor; buna karşılık SQL veritabanları ve erişim motorları çoğunlukla zaten mevcut oluyor
      Ayrıca ben marimo notebook içinde arka planda DuckDB ile SQL hücrelerini sık kullanıyorum; orada SQL’den doğrudan plot alabilmek çok kullanışlı olurdu
      Son olarak Python plotting API’lerini ezberleyip doğal biçimde kullanmak bana hep oldukça zor gelmiştir
      matplotlib ile basit bir scatterplot çizmek için bile çok fazla boilerplate gerekiyor; aynı sorgu dili içinde birleşik bir sözdizimi olması bu yüzden oldukça hoş görünüyor
    • Bunun ggplot’un kendisinden ziyade SQL tarzı sözdizimi ile Grammar of Graphics yaklaşımını birleştirme girişimi olduğunu düşünüyorum
      İlginç olan nokta, belirli bir kütüphaneden çok arayüz olarak SQL ile GoG biçimselliğinin birleşimi
      Asıl renderer veya runtime önemli olsa da daha çok uygulama ayrıntısı gibi geliyor
    • Bana göre bu, Python ya da R bilmeyen SQL kullanıcıları için bir araç gibi göründü
    • Doğrudan SQL içinden grafik üretmeye yarayan bildirime dayalı bir dil olmasının kesin avantajları var bence
      Tabii benzer satır sayısıyla R’de, Python’da ya da matplotlib ile de yapılamayacak bir şey değil
      Ama bu tür ortamları kötü niyetli girdilere karşı güvenli biçimde sandbox etmek zor ve böyle bildirime dayalı bir dil olunca güvenilmeyen kullanıcılar ggsql girse bile yalnızca grafik üretilecek şekilde barındırmak daha kolay hale geliyor
      Bu açıdan bakınca kesinlikle faydalı
      Yine de çoğu genel kullanım için, sevdiğiniz bir LLM’e matplotlib kodu yazdırmak daha kolay bir seçenek gibi de görünüyor

  • Projenin kendisini destekliyorum ve kavramın SQL’e çok iyi oturduğu fikrine büyük ölçüde katılıyorum
    R’de WITH ile veriyi hazırlayıp ardından VISUALIZE ekleme yapısı benim plot koduma da neredeyse çok benziyor
    Ancak basit bir DSL olmanın dışında, bir DSL daha yaratmanın maliyetine değecek şekilde ggplot2’ye kıyasla ne avantaj sunduğunu hâlâ çok net göremiyorum
    Benim görselleştirme için ggplot2’den uzaklaştığım neredeyse tek durum, hazır bir geom’un bulunduğu standart örneklerin dışına çıkınca standart dışı görselleştirmeler yapmanın oldukça zorlaşması
    Biraz farklı bir şey yapmak istediğimde, ggplot dostu bir adapter’i zorlayarak üretmektense daha alt düzey çizim primitive’lerine inmek çoğu zaman çok daha kolay oldu
    Sık kullanılan kısmi spesifikasyonları fonksiyonla sarmak bile, bunun + ile mi birleştiğine yoksa |> ya da eski %>% gibi pipe’larla mı zincirlendiğine göre her zaman akıcı hissettirmiyor

    • Amacımız kimseyi ggplot2’den vazgeçirmek değil
      Ve ggplot2 geliştirmesini durdurma gibi bir planımız da kesinlikle yok
      ggsql kısmen yeni bir kullanıcı kitlesine ulaşma ve güçlü görselleştirmeleri yeni bağlamlara taşıma girişimi olan bir proje
      Zamanının çoğunu R içinde geçiren biriyseniz, muhtemelen asıl hedef kullanıcı siz değilsinizdir
      Yine de ggplot2’de olmayan epey ilginç yönleri var; bu yüzden keşfetmek keyifli olabilir
    • Yan not olarak |> ile %>% aynı operatör değil
      Görece yeni base pipe olan |> daha hızlı ama %>% içindeki nokta placeholder’ı gibi, değeri fonksiyonun ilk argümanı olmayan bir konuma aktarmayı desteklemiyor
      Bu yüzden bazı durumlarda %>% ifadeyi biraz daha temiz hale getirebiliyor

  • Bu gerçekten çok iyi görünüyor
    Biz de GFQL adlı bir graph dataframe query language geliştirirken benzer bir sonuca vardık
    Özellikle kod sandbox’ı olmadan kullanılabilecek LLM dostu bir arayüze görselleştirme ve analiz yığınında ihtiyaç vardı
    Temel bir opencypher uzantısıyla bile oldukça zengin GPU görsel analiz pipeline’ları kurulabildiğini gördük; aynı nedenle tablo dünyasında SQL’e yönelmek de çok mantıklı görünüyor
    GFQL tarafında örnek olarak veri yükleme, shape dönüşümü, algoritma tabanlı enrichment, görsel encoding ve birinci sınıf pipeline’ları ele alan overall pipelines ile, daha basit çağrı biçimindeki declarative visual encodings incelenebilir

  • Bu oldukça iyi görünüyor
    Yalnız, sözdizimi desteği olmayan ortamlarda bile zarif biçimde degrade olan bir yaklaşım olsaydı keşke diye düşündüm
    Ben de benzer yönde ama GoG’den çok daha basit bir SQL içi yaklaşım tasarlamıştım ve onda degrade mümkündü
    Pek okunaklı bir sözdizimi değil ama sqlnb spec gibi bir şeydi

    • "degrade in context" ile tam olarak ne demek istediğini biraz karıştırdım
      Mümkünse biraz daha somut açıklar mısın

  • Aynı çizgide bir araç olarak DuckDB tabanlı Shaper da akla geliyor
    Bu da tüm dashboard’u SQL öncelikli bir yaklaşımla ele alıyor; getting started dokümanına bakınca yönelim benzer görünüyor

  • Öncelikle ggsql gerçekten harika görünüyor ve bir an önce denemek istiyorum
    Ama dokümanlarda gözüme çarpan bir eksik vardı: çıktı formatı konusunda açıklama bulmak zordu
    PDF üretilebiliyor mu, SVG ya da PNG mümkün mü, genişlik-yükseklik gibi çıktı ayarları nasıl yapılıyor pek belli değildi
    Bulabildiğim en yakın ipucu Python kütüphane dokümanındaki chart.display() ve chart.save("chart.html") oldu

    • Şu anda writer modülü yalnızca vegalite’e özel ve çıktı, vegalite spec biçiminde JSON
      Bu çıktı mevcut araçlarla interaktif grafik, SVG, PNG gibi biçimlerde render edilebiliyor; boyut gibi ayarlar da o araçların yapılandırmasına göre yapılıyor
      ggsql Jupyter kernel’ı bu vegalite spec’i kullanarak Quarto belgeleri içinde grafik gösterebiliyor
      İleride bu ara vegalite katmanını kullanmayan yüksek performanslı writerlar eklemeyi planlıyoruz; o zaman bu tür sorulara daha net yanıt verilebilir

  • Yakın ya da uzak gelecekte ggplot2 genişletme paketleriyle entegrasyon planı olup olmadığını merak ettim
    Eğer daha önce değinildiyse kusura bakmayın

    • ggplot2 topluluğunun ürettiği çeşitli niş geom’ları yakın vadede taşımamız zor görünüyor
      Bu projenin amacı ggplot2’nin yerini almak değil, farklı bir yaklaşım sunmak
      ggplot2’nin yaptığı birçok şeyi yapabilir, hatta ggplot2’nin yapamadığı bazı şeyleri de yapabilir; ama uzun süre boyunca pek çok işte ggplot2’nin daha güçlü kalacağını düşünüyorum

  • Bu gerçekten çok havalı görünüyor; yakında denemeyi düşünüyorum
    Bende en çok karşılık bulan şey grammar dokümanındaki anlatımdı
    Zaten tanıdık olan SELECT ile veriyi seçip, VISUALIZE ya da VISUALISE ile tablodan plot’a geçmek, ardından DRAW ile aesthetics eşlemesi yapmak ve SCALE, FACET, LABEL katmanlarını sırayla eklemek, SQL’in yapısal düşünme biçimini aynen devam ettiriyor gibi geldi

  • Ben katmanlama yaklaşımını gerçekten çok beğendim
    Temel grafiklerin ötesine geçmeye başlayınca başka SQL görselleştirme karma araçlarında sık gördüğüm sorunları bunun iyi çözdüğü izlenimini verdi