ggsql - ไวยากรณ์เชิงกราฟิกสำหรับ SQL

 (opensource.posit.co)
11 คะแนน โดย GN⁺ 9 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นเครื่องมือสร้างภาพข้อมูลบนไวยากรณ์ของ SQL ที่รวมการดึงข้อมูลและการประกอบกราฟไว้ในโฟลว์เดียวผ่าน clause อย่าง VISUALIZE, DRAW, PLACE, SCALE, LABEL
  • สามารถแมปคอลัมน์เข้ากับคุณลักษณะเชิงภาพ และประกอบเป็นเลเยอร์เพื่อสร้าง scatter plot, bar chart, histogram, boxplot ไปจนถึงองค์ประกอบ annotation ได้ภายในโครงสร้างเดียวกัน
  • ส่งผลลัพธ์จาก SQL query ไปเป็นอินพุตสำหรับการแสดงผลได้ทันที และบางเลเยอร์มีโครงสร้างที่ดึงมาเฉพาะค่าที่ aggregate ผ่านการรัน SQL query เพียงครั้งเดียว จึงได้เปรียบเมื่อต้องจัดการข้อมูลขนาดใหญ่
  • ออกแบบให้เป็นไฟล์ executable ขนาดเล็กและทำงานเฉพาะทางที่ใช้งานได้โดยไม่ต้องมี R หรือ Python runtime จึงเหมาะกับการผสานเข้ากับเครื่องมือรายงานแบบ code-based และผู้ช่วยวิเคราะห์ AI
  • เวอร์ชันปัจจุบันเป็น alpha-release และมีแผนขยายต่อ เช่น writer ประสิทธิภาพสูง, ธีม, interactivity, language server, formatter และการรองรับข้อมูลเชิงพื้นที่

แนะนำ ggsql

  • ggsql คือ implementation ของ grammar of graphics ที่อิงไวยากรณ์ SQL โดยเพิ่มความสามารถด้านการแสดงผลแบบมีโครงสร้างเข้าไปใน SQL
    • ใช้งานได้ใน Quarto, Jupyter notebooks, Positron, VS Code เป็นต้น
  • ถูกออกแบบมาเพื่อให้ผู้ใช้ SQL เขียนโค้ดสำหรับการแสดงผลข้อมูลได้ด้วยรูปแบบที่คุ้นเคย
    • นำแนวคิดเรื่อง clause แบบประกาศเจตนาและประกอบรวมกันได้ของ SQL มาใช้กับไวยากรณ์สำหรับการแสดงผลด้วย
  • มีการอธิบายทั้งแรงจูงใจและตัวอย่างการใช้งาน พร้อมค่อย ๆ แสดงไวยากรณ์หลักของ ggsql

ตัวอย่างพื้นฐาน

  • พล็อตแรก

    • สามารถสร้าง scatter plot จากชุดข้อมูล penguins ที่มีมาให้ได้
      • VISUALIZE bill_len AS x, bill_dep AS y FROM ggsql:penguins
      • DRAW point
    • ใน VISUALIZE จะเป็นการแมปคอลัมน์ข้อมูลเข้ากับคุณลักษณะเชิงภาพ และ DRAW point จะใช้การแมปพื้นฐานนั้นเพื่อสร้าง point layer
    • เพียงเพิ่ม species AS color ก็สามารถแยกหมวดหมู่ด้วยสีได้
      • VISUALIZE bill_len AS x, bill_dep AS y, species AS color FROM ggsql:penguins
      • DRAW point
    • เพิ่ม DRAW smooth เพื่อซ้อน regression line layer ทับบน point layer ได้
      • การแมปสีตามชนิดจะยังคงอยู่ จึงสร้างเส้นแยกตาม species
    • ใช้วิธีประกอบจากองค์ประกอบแบบโมดูลาร์แทนการยึดติดกับชนิดพล็อตที่กำหนดไว้ล่วงหน้า
    • สามารถเปลี่ยนไปเป็นการแสดงผลคนละแบบได้โดยยังคงโครงสร้างเดิม
      • VISUALIZE island AS x, species AS color FROM ggsql:penguins
      • DRAW bar

  • ตัวอย่างแบบสมบูรณ์

    • ส่วนบนเป็น SQL query ทั่วไป และหลัง VISUALIZE จะแยกเป็น visualization query
      • ในตัวอย่างใช้ DuckDB เป็น backend
    • ในส่วน SQL ใช้ ROW_NUMBER() และ QUALIFY เพื่อเก็บเฉพาะ mission ล่าสุดของแต่ละชื่อจาก astronauts.parquet
    • จากนั้นรวมข้อมูลสองชุดเข้าด้วยกัน
      • คำนวณ year_of_selection - year_of_birth เป็น age และกำหนดหมวดหมู่ Age at selection
      • คำนวณ year_of_mission - year_of_birth เป็น age และกำหนดหมวดหมู่ Age at mission
      • รวมผลลัพธ์ทั้งสองด้วย UNION ALL
    • ใน visualization query จะทำการแมป age AS x, category AS fill แล้วใช้ DRAW histogram
      • ระบุ SETTING binwidth => 1, position => 'identity'
    • ใช้ PLACE rule เพื่อเพิ่ม annotation ของตำแหน่งค่าเฉลี่ยที่คำนวณไว้ล่วงหน้า
      • x => (34, 44), linetype => 'dotted'
    • ใช้ PLACE text เพื่อเพิ่ม annotation แบบข้อความ
      • 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
    • ใช้ clause LABEL เพื่อควบคุมชื่อเรื่อง, คำบรรยายรอง, ป้ายแกน x และป้าย legend
      • ชื่อเรื่อง 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

โครงสร้างของ visualization query

  • ส่วนก่อน VISUALIZE คือ SQL ล้วน ๆ และผลลัพธ์จะไม่ถูกส่งกลับมาเป็นตาราง แต่ถูกส่งต่อเป็นอินพุตสำหรับการแสดงผลโดยตรง
  • ตารางหรือ CTE ที่สร้างในส่วน SQL สามารถอ้างอิงได้ใน visualization query
  • หากข้อมูลอยู่ในรูปแบบที่เหมาะกับการแสดงผลอยู่แล้ว ก็สามารถละส่วน SQL ออกได้
    • VISUALIZE year_of_selection AS x, year_of_mission AS y FROM 'astronauts.parquet'
  • VISUALIZE หรือ VISUALISE ใช้เป็นตัวบอกจุดสิ้นสุดของ SQL query และจุดเริ่มต้นของ visualization query
  • การแมปมีหน้าที่เชื่อมคอลัมน์กับคุณลักษณะเชิงภาพ หรือ aesthetics
    • ในตัวอย่าง age ตรงกับตำแหน่งบนแกน x และ category ตรงกับสีเติม
  • DRAW ใช้เพิ่มเลเยอร์ให้กับการแสดงผล
    • มีทั้งชนิดที่เรียบง่ายอย่าง point และชนิดที่ต้องคำนวณ aggregate แบบแบ่งช่วงอย่าง histogram
    • เลเยอร์จะถูกเรนเดอร์ตามลำดับที่นิยามไว้
  • PLACE เป็น clause ระดับเดียวกับ DRAW แต่ใช้ค่า literal แทนข้อมูลจากตาราง และมีไว้สำหรับ annotation โดยเฉพาะ
    • การแสดงผลในตัวอย่างประกอบด้วย 3 เลเยอร์ คือ histogram layer, rule annotation layer และ text annotation layer
    • หนึ่งเลเยอร์ไม่ได้จำเป็นต้องตรงกับวัตถุกราฟิกเพียงชิ้นเดียวเสมอไป และอาจเรนเดอร์วัตถุย่อยหลายชิ้นในชนิดเดียวกันได้
  • SCALE เป็น clause สำหรับแปลงค่าข้อมูลให้เหมาะกับ aesthetic ที่ใช้งาน
    • นอกจากการแปลงหมวดหมู่แบบสตริงให้เป็นสีจริงแล้ว ยังรองรับการแปลงแบบต่อเนื่อง, การกำหนด break point และการตั้งชนิดของสเกลอย่าง ordinal หรือ binned
  • LABEL รองรับการเพิ่มและแก้ไขป้ายข้อความ เช่น ชื่อเรื่อง, คำบรรยายรอง, ชื่อแกน และชื่อ legend

ถอยออกมามองอีกก้าว

  • แม้ตัวอย่างข้างต้นจะมีไวยากรณ์จำนวนมาก แต่ก็ครอบคลุมส่วนสำคัญของไวยากรณ์หลักได้ในครั้งเดียว
  • visualization query จำนวนมากสามารถเขียนให้ง่ายกว่านี้ได้มาก
  • มีตัวอย่าง boxplot ของปีเกิดแยกตามเพศโดยใช้ astronauts.parquet
    • VISUALIZE sex AS x, year_of_birth AS y FROM 'astronauts.parquet'
    • DRAW boxplot
  • ความยาวของโค้ดอาจมากกว่าระบบ plotting อื่น แต่มีคุณสมบัติที่ มีโครงสร้าง, ประกอบต่อได้, และ อธิบายตัวเองได้ มากกว่า
  • คุณสมบัติเหล่านี้ช่วยให้ผู้ใช้ซึมซับพฤติกรรมของพล็อตทุกชนิดได้ง่ายขึ้น และยังเป็นประโยชน์กับผู้ช่วยเขียนโค้ดแบบ LLM ในอนาคต
  • ความสัมพันธ์เดียวกันนี้สามารถเปลี่ยนเป็น jittered scatter plot ได้ง่าย
    • DRAW point
    • SETTING position => 'jitter'
  • และยังระบุให้ jitter ตามการกระจายของข้อมูลเพื่อให้มีลักษณะคล้าย violin plot ได้
    • SETTING position => 'jitter', distribution => 'density'
  • โครงสร้างไวยากรณ์และความสามารถในการประกอบกันเช่นนี้ช่วยให้การทำ exploratory analysis และการออกแบบการแสดงผลที่ต้องลองซ้ำหลายรอบทำได้ง่ายขึ้น

ทำไมต้อง ggsql

  • มีการยกเหตุผล 5 ข้อสำหรับการพัฒนา ggsql
    • เพื่อรองรับนักวิเคราะห์ข้อมูลและนักวิทยาศาสตร์ข้อมูลที่ทำงานด้วย SQL เป็นหลัก
    • เพราะ SQL กับ grammar of graphics เข้ากันได้ดีมาก
    • เพื่อสร้างเครื่องมือสร้างภาพข้อมูลแบบ code-based ที่ทรงพลังโดยไม่ต้องพึ่งภาษาโปรแกรมเต็มรูปแบบอย่าง R หรือ Python
    • เพราะ LLM มีความสามารถเด่นในการจัดการ SQL และเปิดโอกาสให้เกิดอินเทอร์เฟซการแสดงผลแบบใหม่
    • เพื่อประยุกต์ประสบการณ์พัฒนา ggplot2 ตลอด 18 ปีลงบนฐานใหม่

  • Hello, SQL user

    • แม้ในช่วงการปฏิวัติด้าน data science จะมี R และ Python ที่โดดเด่น แต่ SQL ก็ยังคงเป็นฐานที่เชื่อถือได้สำหรับงานข้อมูลเสมอ
    • มีผู้ทำงานด้านข้อมูลจำนวนมากที่ใช้เพียง SQL หรือใช้ SQL เป็นหลัก
    • ตัวเลือกการแสดงผลที่มีอยู่เดิมสำหรับคนกลุ่มนี้ถือว่ายังไม่เหมาะนักในมุมมองของบทความ
      • ส่งออกข้อมูลไปใช้กับ R หรือ Python
      • ใช้เครื่องมือ BI แบบ GUI ที่รองรับ reproducibility ได้ไม่ดีพอ
      • ใช้เครื่องมือแสดงผลภายใน query โดยตรง แต่ถูกมองว่ายังไม่ทรงพลังหรือใช้งานไม่ลื่นไหลเพียงพอ
    • ไวยากรณ์ของ ggsql ถูกออกแบบให้ผู้ใช้ SQL เข้าใจได้ทันที
      • อาศัยความคุ้นเคยกับ clause ที่ประกอบรวมกันได้และเป็น declarative
    • ggsql ไม่ได้แค่ปรับปรุงวิธีการแสดงผล แต่ยังทำหน้าที่ดึงผู้ใช้ SQL เข้าสู่ระบบนิเวศของการสร้างและแชร์รายงานแบบ code-based บน Quarto ด้วย

  • การแปลงข้อมูลแบบ declarative, การแสดงผลแบบ declarative

    • SQL เป็นภาษาเฉพาะทางสำหรับจัดการข้อมูลเชิงสัมพันธ์ที่เก็บอยู่ในหนึ่งตารางหรือหลายตาราง
    • ไวยากรณ์ของ SQL ตั้งอยู่บนแนวคิดของ relational algebra และมอบวิธีคิดเชิงโครงสร้างต่อการจัดการข้อมูล
    • ความหมายเชิงการทำงานของ SQL ไม่ใช่แบบฟังก์ชัน แต่เป็นการนิยามชุดปฏิบัติการแบบโมดูลาร์เชิง declarative
    • grammar of graphics เป็นกรอบทฤษฎีที่แยกแนวคิดการแสดงผลข้อมูลออกเป็นองค์ประกอบแบบโมดูลาร์
    • เครื่องมืออย่าง ggplot2 ได้นำแนวคิดนี้ไปสู่การใช้งานจริง
    • grammar of graphics เองก็เช่นกัน คือการนิยามชุดปฏิบัติการแบบโมดูลาร์เชิง declarative มากกว่าจะเป็นแบบฟังก์ชัน
    • ทั้งสองระบบมีความคล้ายคลึงกันมากในวิธีเข้าหาโดเมนของตน และสามารถประกอบเป็น pipeline ที่เป็นธรรมชาติและทรงพลังตั้งแต่ข้อมูลดิบไปจนถึงการแสดงผลขั้นสุดท้าย

  • No runtime, no problem

    • ggplot2 ต้องติดตั้ง R ส่วน plotnine ต้องติดตั้ง Python
    • ขณะที่เครื่องมือแสดงผลที่อิงกับไฟล์ executable เดี่ยวและเน้นหน้าที่เฉพาะมีข้อดีชัดเจน
      • การฝัง executable ขนาดเล็กลงในเครื่องมืออื่นทำได้ง่ายกว่าการ bundle หรือต้องติดตั้ง R/Python
      • ด้วยขอบเขตที่เล็กกว่า จึง sandbox เพื่อจำกัดการรันโค้ดที่เป็นอันตรายหรือผิดพลาดโดยไม่ตั้งใจได้ง่ายกว่า
    • คุณสมบัติเหล่านี้ทำให้ ggsql เป็นตัวเลือกที่น่าสนใจยิ่งขึ้นสำหรับการผสานเข้ากับผู้ช่วยวิเคราะห์ AI หรือเครื่องมือรายงานแบบ code-based ที่รันโค้ดในหลายสภาพแวดล้อม
    • การออกห่างจากภาษาแบบ interpreted มีข้อจำกัดบางอย่าง แต่ก็ได้ประโยชน์กลับมามากเช่นกัน
    • ข้อได้เปรียบที่สำคัญที่สุดคือ ด้วยโครงสร้างที่เข้มงวด ทำให้ backend สามารถรัน data pipeline ทั้งชุดของแต่ละเลเยอร์ด้วย SQL query เดียวได้
      • ยกตัวอย่าง หากต้องสร้าง bar plot จากข้อมูลธุรกรรม 10 พันล้านรายการ ก็จะดึงกลับมาจาก data warehouse แค่ค่า count ของแต่ละแท่ง ไม่ใช่ทั้ง 10 พันล้านแถว
      • หลักการเดียวกันนี้ใช้ได้กับเลเยอร์ที่ซับซ้อนกว่าอย่าง boxplot หรือ density plot
    • นี่เป็นคุณสมบัติที่ต่างจากเครื่องมือแสดงผลส่วนใหญ่ซึ่งมัก materialize ข้อมูลทั้งหมดก่อน แล้วค่อยคำนวณและพล็อต

  • SELECT pod_door FROM bay WHERE closed

    • มีการพิสูจน์แล้วว่า LLM มีประสิทธิภาพมากในการแปลงภาษาธรรมชาติเป็น SQL
    • และมีความคาดหวังว่าประสิทธิภาพระดับเดียวกันนี้จะใช้กับ ggsql ได้ด้วย
    • ใน querychat มีการใช้ ggsql ทำการสำรวจข้อมูลเชิงภาพด้วยภาษาธรรมชาติได้แล้ว
    • เพราะ ggsql มี runtime ที่ปลอดภัยและเบากว่า R หรือ Python จึงให้ความมั่นใจมากขึ้นเมื่อต้องนำ coding agent ไปใช้งานใน production

  • We are now wise beyond our years

    • การพัฒนาและดูแล ggplot2 มานาน 18 ปี หมายถึงการสั่งสมความคิดเกี่ยวกับไวยากรณ์การแสดงผลข้อมูล, การใช้งาน, และการออกแบบตลอด 18 ปี
    • ความรู้เหล่านี้ไม่สามารถใส่กลับเข้าไปใน ggplot2 ได้ทั้งหมด
      • เพราะต้องเคารพการตัดสินใจในอดีตและความคาดหวังของผู้ใช้ และแม้จะท้าทายกรอบเดิมก็ทำได้เพียงอย่างค่อยเป็นค่อยไปเท่านั้น
    • ggsql คือ blank slate
      • เป็นโปรเจกต์ที่สร้างขึ้นใหม่ตั้งแต่ต้น
      • เป็นระบบที่ออกแบบมาสำหรับสภาพแวดล้อมที่ไม่มีความคาดหวังเดิมเกี่ยวกับเครื่องมือแสดงผลข้อมูล
    • ผู้เขียนระบุว่าจุดเริ่มต้นแบบนี้ให้ทั้งอิสรภาพและพลังในการพัฒนา และสิ่งนั้นก็สะท้อนออกมาในประสบการณ์ใช้งานของผู้ใช้ด้วย

อนาคต

  • เวอร์ชันปัจจุบันเป็น alpha-release และยังไม่เสร็จสมบูรณ์
  • มีการยกตัวอย่างรายการสิ่งที่จะเพิ่มในอนาคตแบบไม่ครอบคลุมทั้งหมด
    • writer ประสิทธิภาพสูงตัวใหม่ที่เขียนด้วย Rust ตั้งแต่ต้น
    • โครงสร้างพื้นฐานสำหรับธีม
    • interactivity
    • workflow การ deploy แบบ end-to-end ตั้งแต่ Posit Workbench หรือ Positron ไปจนถึง Connect
    • ggsql language server แบบสมบูรณ์และ code formatter
    • การรองรับข้อมูลเชิงพื้นที่

  • แล้วสิ่งนี้หมายความว่าอย่างไรต่อการพัฒนา ggplot2

    • มีการกล่าวว่าผู้ใช้ ggplot2 อาจมองการเปิดตัว ggsql ด้วยความรู้สึกทั้งกังวลและคาดหวังปะปนกัน
    • คำตอบต่อคำถามว่า Posit จะละ ggplot2 แล้วไปโฟกัสที่ ggsql หรือไม่ คือ ไม่ใช่
    • ggplot2 นั้นมีความสมบูรณ์และเสถียรมากอยู่แล้ว แต่ก็ยังมีแผนจะสนับสนุนและขยายต่อไป
    • และหวังว่ากระบวนการพัฒนา ggsql จะช่วยส่งมอบฟีเจอร์ใหม่กลับไปยัง ggplot2 ได้ด้วย

อ่านเพิ่มเติม

  • หากอยากเริ่มใช้ ggsql ทันที สามารถดูคำแนะนำการติดตั้งและทิวทอเรียลได้ในส่วน Getting started ของเว็บไซต์ ggsql
  • ในหน้าดocumentation สามารถดูฟีเจอร์ทั้งหมดที่ ggsql รองรับได้
  • มีการกล่าวปิดท้ายว่าคาดหวังฟีดแบ็กเกี่ยวกับประสบการณ์ใช้งานจากผู้ใช้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 9 일 전
ความคิดเห็นจาก Hacker News

  • อาจเป็นเพราะผมรีบอ่านผ่านๆ แต่จากแค่โพสต์บล็อกกับเอกสาร ผมรู้สึกว่า ความสัมพันธ์กับฐานข้อมูล SQL ยังอธิบายได้ไม่ชัดเจน
    ตอนแรกผมเดาว่ามันน่าจะเป็นประมาณ DSL สำหรับการทำภาพคล้าย SQL ที่ไลบรารีกราฟฝั่งฟรอนต์เอนด์เอาไปประมวลผล
    เอกสาร anatomy อ่านออกมาแบบนั้น แต่ใน FAQ ตรง "Can I use SQL queries inside the VISUALISE clause" กลับเขียนว่า syntax บางส่วนถูกส่งต่อไปยังฐานข้อมูลโดยตรง
    หน้าเว็บหลักบอกว่า "ggsql interfaces directly with your database" แต่กลับไม่ค่อยทำให้เห็นว่า มันเชื่อมต่อกันอย่างไร เลยทำให้สับสน

    • ผมว่าเป็นข้อสังเกตที่ถูกต้อง แนวคิดนี้เองก็มี โครงสร้างที่ค่อนข้างแปลก อยู่เล็กน้อย
      ggsql เชื่อมต่อกับ database backend ได้โดยตรง และถ้าต้องการก็รันด้วย in-memory DuckDB ได้เช่นกัน
      visualisation query จะถูกแปลงเป็น SQL query สำหรับแต่ละเลเยอร์ของภาพ แล้วใช้ตารางผลลัพธ์นั้นในการเรนเดอร์
      ตัวอย่างเช่น query อย่าง VISUALISE page_views AS x FROM visits DRAW smooth จะถูกแปลงเป็น SQL ที่คำนวณ smoothing kernel ของข้อมูล และใช้จุดที่ส่งกลับมาเพื่อวาด line chart สุดท้าย
    • ใน ggsql มีแนวคิดเรื่อง reader ซึ่งทำหน้าที่เป็นอินเทอร์เฟซเชื่อมกับฐานข้อมูล SQL
      reader จะจัดการทั้งการเชื่อมต่อฐานข้อมูลและการ สร้าง SQL dialect ให้เหมาะกับแต่ละ DB
      ตอนนี้ในช่วง alpha รองรับ duckdb, sqlite และ experimental ODBC reader อยู่ประมาณหนึ่ง โดยการพัฒนาหลักยังเน้นที่ DuckDB แบบไฟล์ในเครื่อง
      แนวคิดหลักคือแปลง visualisation query เป็น SQL หลายตัวไปรันในฐานข้อมูล แล้วใช้เฉพาะผลลัพธ์ขนาดเล็กที่ส่งกลับมาเพื่อประกอบกราฟ
      ดังนั้นแม้จะมีจำนวนแถวมหาศาล ก็สามารถคำนวณเฉพาะสถิติที่ต้องใช้กับ histogram ใน SQL แล้วดึงกลับมาแค่ไม่กี่จุดที่จำเป็นต่อการวาดความสูงของแท่งได้
      ค่าปริยายคือการเชื่อมต่อ in-memory DuckDB และใน CLI สามารถใช้ --reader เพื่อเชื่อมไปยังไฟล์บนดิสก์หรือ ODBC URI ได้
      ใน Positron สามารถตั้งค่าได้ง่ายขึ้นผ่าน pane "Connections" และใน ggsql Jupyter kernel สามารถระบุ reader ได้ด้วย magic SQL comment
      เราวางแผนจะเสริมคำอธิบายเรื่อง การเชื่อมกับเครื่องมือภายนอก ในเอกสารให้มากขึ้นด้วย
    • ผมก็มีคำถามเดียวกัน ถ้ามีตัวอย่างที่แสดง ภาพรวมทั้งสายของการต่อใช้งานและ dependency สำหรับสร้างกราฟจากฐานข้อมูลภายนอกได้ ก็น่าจะเข้าใจง่ายขึ้นมาก
    • สำหรับผม SQL กับฐานข้อมูลไม่ใช่สิ่งเดียวกัน
      SQL เป็นภาษาประกาศเชิง declarative สำหรับจัดการข้อมูล แม้มักถูกใช้เพื่อ query ฐานข้อมูล แต่ไม่ได้ผูกกับฐานข้อมูลเท่านั้น
      จะใช้ SQL กับ flat file, data stream หรือข้อมูลในหน่วยความจำของโปรแกรมก็ได้
      ในทางกลับกัน ผมก็มองว่าสามารถ query ฐานข้อมูลโดยไม่ใช้ SQL ได้เหมือนกัน

  • ตอนอ่านผ่านๆ ผมพยายามหาคำอธิบายว่า ทำไมสิ่งนี้ถึงจำเป็น และมัน แก้ปัญหาอะไร แต่ยังไม่ค่อยเก็ต
    ผมเดาว่าเป็นการพยายามให้ visualise ตารางจาก remote SQL database ได้ตรงๆ โดยลดขั้นตอนที่ต้องดึงเข้ามาเป็น R data frame ก่อนแล้วค่อยรัน ggplot ใช่ไหม
    แต่ก็ยังสงสัยว่าทำไมต้องสร้าง ภาษาแนว SQL ใหม่ ขึ้นมาอีก
    ใน R เองก็มี dbplyr ที่แปลระหว่าง R กับ SQL อยู่แล้ว ผมเลยรู้สึกว่าถ้าขยาย ggplot ให้รองรับ dbplyr tbl object โดยตรงและสร้าง SQL เอง น่าจะตรงทางกว่าไหม
    หรือจริงๆ เพราะ SQL เป็นภาษาที่คนคุ้นเคยมากอยู่แล้ว เลยคิดว่าหลายคนน่าจะอยากทำงานแนว ggplot ผ่าน syntax แบบนี้ก็ได้
    ผมต้องอ่านเอกสารแทบทั้งหมดถึงจะเข้าใจว่ามันเป็น แอป visualisation แบบ standalone ที่มี backend เป็น DuckDB กับ SQLite ตอนนี้เรนเดอร์ด้วย Vegalite และมีแผนเพิ่ม backend กับ renderer ในอนาคต
    เหมือนคอมเมนต์ด้านล่างบอกไว้ มันดูเป็นเครื่องมือที่ให้ ผู้ใช้สาย SQL ที่ไม่รู้ Python หรือ R สามารถสร้างภาพข้อมูลได้

    • ผมอ่านประกาศนี้แล้วรู้สึกว่า น่าสนใจมาก เลยคิดว่าน่าจะอธิบายได้ว่าทำไมมันถึงมีเสน่ห์ในมุมมองของผม
      แน่นอนว่าผมก็เห็นด้วยว่าโพสต์ประกาศน่าจะอธิบายจุดนี้ให้ดีกว่านี้หน่อย
      จากประสบการณ์ของผม ภาษาที่นักวิเคราะห์ นักวิทยาศาสตร์ และวิศวกรมักใช้ร่วมกันได้จริงๆ ก็คือ SQL
      จะทำแบบเดียวกันใน R ก็ได้ แต่ในโปรเจ็กต์จริงก็ไม่ได้เขียนทุกอย่างด้วย R หรือ Python เสมอไป ขณะที่ SQL database และ access engine มักมีอยู่แล้ว
      อีกอย่าง ผมใช้ SQL cell บน DuckDB เบื้องหลังใน marimo notebook บ่อยมาก ถ้าพล็อตจาก SQL ได้ตรงๆ ก็น่าจะสะดวกมาก
      สุดท้าย ผมรู้สึกว่า API สำหรับ plotting ใน Python จำและใช้ให้คล่องค่อนข้างยาก
      แค่จะวาด scatterplot ง่ายๆ ด้วย matplotlib ก็ยังมี boilerplate เยอะเกินไป ถ้ามี syntax ที่สอดคล้องกันอยู่ใน query language เดียวกันก็คงดีมาก
    • ผมมองว่านี่ไม่ใช่เรื่องของ ggplot เอง แต่เป็นความพยายามที่จะผสาน syntax แบบ SQL เข้ากับ Grammar of Graphics
      จุดที่น่าสนใจอยู่ที่การจับคู่ระหว่าง SQL ในฐานะอินเทอร์เฟซ กับ ความเป็นแบบแผนของ GoG มากกว่าจะเป็นไลบรารีตัวใดตัวหนึ่ง
      ตัว renderer หรือ runtime จริงๆ ก็สำคัญ แต่ผมคิดว่ามันใกล้เคียงกับรายละเอียดด้าน implementation มากกว่า
    • สำหรับผมมันดูเหมือนเป็นเครื่องมือสำหรับ ผู้ใช้ SQL ที่ไม่รู้ Python หรือ R
    • ผมคิดว่าการเป็น ภาษาประกาศ สำหรับสร้างกราฟได้ตรงจาก SQL นั้นมีข้อดีชัดเจน
      แน่นอนว่าไม่ใช่ว่ามันทำสิ่งที่ R หรือ Python หรือ matplotlib ทำไม่ได้ด้วยจำนวนโค้ดใกล้ๆ กัน
      แต่การทำ sandboxing ให้สภาพแวดล้อมพวกนั้นปลอดภัยต่อ malicious input เป็นเรื่องยาก และถ้าเป็นภาษาประกาศแบบนี้ก็จะโฮสต์ในลักษณะที่ผู้ใช้ที่ไม่น่าเชื่อถือส่ง ggsql เข้ามาแล้วระบบสร้างแค่กราฟกลับไปได้ง่ายกว่า
      ในแง่นั้นมันมีประโยชน์แน่นอน
      แต่อีกด้านหนึ่ง สำหรับการใช้งานทั่วไปส่วนใหญ่ ผมก็ยังรู้สึกว่าการให้ LLM ตัวโปรดช่วยสร้างโค้ด matplotlib ให้น่าจะเป็นทางเลือกที่ง่ายกว่า

  • ผมเอาใจช่วยโปรเจ็กต์นี้ และเห็นด้วยมากว่าแนวคิดนี้ เข้ากับ SQL ได้ดีมาก
    ใน R โครงสร้างแบบเตรียมข้อมูลด้วย WITH แล้วตามด้วย VISUALIZE ก็แทบเหมือนกับโค้ด plotting ที่ผมเขียนอยู่แล้ว
    แต่ถ้านอกเหนือจากข้อดีเรื่องเป็น DSL ที่เรียบง่าย ผมก็ยังไม่แน่ใจว่าอะไรคือ ข้อได้เปรียบเหนือ ggplot2 ที่คุ้มกับต้นทุนของการสร้าง DSL เพิ่มอีกตัว
    เกือบเหตุผลเดียวที่ทำให้ผมอยากออกจาก ggplot2 เวลาทำ visualisation คือพอออกนอกกรณีมาตรฐานที่มี geom ให้พร้อมแล้ว การทำ ภาพแบบไม่มาตรฐาน จะยากขึ้นมาก
    เวลาอยากทำอะไรที่ต่างออกไปนิดหน่อย หลายครั้งการลงไปใช้ primitive drawing ระดับล่างจะง่ายกว่าการฝืนทำ adapter ให้เป็นมิตรกับ ggplot เสียอีก
    ต่อให้เป็นการห่อ partial spec ที่ใช้บ่อยเป็นฟังก์ชัน ก็ยังรู้สึกว่าบางทีไม่ลื่นนัก ขึ้นกับว่าจะประกอบด้วย + หรือจะเชื่อมด้วย pipe อย่าง |> หรือ %>% แบบเก่า

    • เป้าหมายของเราไม่ใช่การทำให้ใคร ย้ายออกจาก ggplot2
      และเราก็ไม่มีแผนจะหยุดพัฒนา ggplot2 แต่อย่างใด
      ggsql เป็นโปรเจ็กต์ที่มีส่วนของการพยายามเข้าถึงผู้ใช้กลุ่มใหม่ และนำ visualisation ที่ทรงพลังไปวางไว้ใน บริบทใหม่
      ถ้าคุณใช้เวลาส่วนใหญ่ใน R ก็น่าจะไม่ใช่กลุ่มเป้าหมายหลัก
      แต่ก็มีองค์ประกอบที่น่าสนใจอยู่ไม่น้อยซึ่ง ggplot2 ไม่มี ดังนั้นอาจสนุกดีถ้าลองสำรวจดู
    • นอกเรื่องนิดหนึ่ง แต่ |> กับ %>% ไม่ใช่โอเปอเรเตอร์เดียวกัน
      |> ซึ่งเป็น base pipe ที่ค่อนข้างใหม่จะเร็วกว่า แต่ไม่รองรับความสามารถอย่าง dot placeholder ของ %>% เวลาจะส่งค่าไปตำแหน่งที่ไม่ใช่อาร์กิวเมนต์ตัวแรกของฟังก์ชัน
      ดังนั้นในบางกรณี %>% ก็ทำให้นิพจน์ดูสะอาดกว่าได้นิดหน่อย

  • อันนี้ดีมากจริงๆ
    พวกเราก็เคยสร้าง graph dataframe query language ชื่อ GFQL และไปถึงข้อสรุปคล้ายๆ กัน
    โดยเฉพาะในเรื่องที่สแตกสำหรับ visualisation และ analysis ต้องการ อินเทอร์เฟซที่เป็นมิตรกับ LLM โดยไม่ต้องพึ่ง code sandbox
    เราพบว่าแค่ขยาย opencypher พื้นฐาน ก็สร้าง GPU visual analytics pipeline ที่ค่อนข้างสมบูรณ์ได้แล้ว และด้วยเหตุผลเดียวกัน การเดินไปทาง SQL สำหรับโลกของตารางก็ดูสมเหตุสมผลมาก
    ถ้าสนใจตัวอย่างฝั่ง GFQL ก็มี overall pipelines ที่ครอบคลุม data loading, การแปลง shape, algorithm-based enrichment, visual encoding และ first-class pipeline รวมถึง declarative visual encodings ในรูปแบบเรียกใช้งานง่ายๆ

  • อันนี้ดูค่อนข้างดี
    แต่ผมก็อยากให้มีวิธีที่ degrade ได้อย่างสวยงาม ในสภาพแวดล้อมที่ไม่รองรับ syntax นี้
    ผมเองก็เคยออกแบบแนวทางคล้ายกันสำหรับ SQL ภายใน เพียงแต่เรียบง่ายกว่า GoG มาก และฝั่งนั้น degrade ได้
    syntax อ่านไม่ง่ายนัก แต่ประมาณแบบ sqlnb spec

    • ผมยังงงนิดหน่อยว่า "degrade in context" หมายถึงอะไรแน่
      ถ้าเป็นไปได้ช่วย อธิบายให้เฉพาะเจาะจงขึ้นอีกนิด จะดีมาก

  • เครื่องมืออีกตัวในแนวเดียวกันที่ทำให้นึกถึงคือ Shaper บน DuckDB
    มันเป็นแนวทางจัดการ dashboard ทั้งชุดแบบ SQL-first และพออ่าน getting started document แล้วก็รู้สึกว่าทิศทางคล้ายกัน

  • เบื้องต้น ggsql ดูเจ๋งมากจริงๆ และผมอยากลองใช้เร็วๆ นี้
    แต่มีจุดที่ดูเหมือนขาดไปอย่างหนึ่งในเอกสาร คือหาคำอธิบายเรื่อง รูปแบบเอาต์พุต ได้ยาก
    เช่น ส่งออกเป็น PDF ได้ไหม รองรับ SVG หรือ PNG หรือเปล่า และจะควบคุมขนาดกว้างยาวของผลลัพธ์อย่างไร
    เบาะแสที่ใกล้ที่สุดที่ผมหาเจอคือ chart.display() กับ chart.save("chart.html") ในเอกสารไลบรารี Python

    • ตอนนี้ writer module มีแค่แบบ vegalite อย่างเดียว และผลลัพธ์เป็น JSON ในรูปแบบ vegalite spec
      เอาต์พุตนี้สามารถนำไปเรนเดอร์เป็น interactive chart, SVG, PNG และอื่นๆ ได้ด้วยเครื่องมือที่มีอยู่แล้ว และการควบคุมอย่างขนาดก็จะเป็นไปตามการตั้งค่าของเครื่องมือเหล่านั้น
      ggsql Jupyter kernel สามารถใช้ vegalite spec นี้เพื่อแสดงกราฟในเอกสาร Quarto ได้
      ในอนาคตเราวางแผนจะสร้าง writer ประสิทธิภาพสูง ที่ไม่ต้องผ่านขั้น vegalite ระหว่างทาง ซึ่งตอนนั้นก็น่าจะตอบคำถามลักษณะนี้ได้ชัดเจนขึ้น

  • ไม่ว่าจะในอนาคตอันใกล้หรือไกล ผมสงสัยว่ามีแผนจะ ผสานกับแพ็กเกจขยายของ ggplot2 ไหม
    ถ้ามีการพูดถึงไปแล้วก็ขออภัยด้วย

    • ผมคิดว่าคงยากที่จะดึง niche geom ต่างๆ ที่ชุมชน ggplot2 สร้างไว้เข้ามาได้ในเร็ววัน
      เป้าหมายของโปรเจ็กต์นี้ไม่ใช่การแทนที่ ggplot2 แต่เป็นการเสนอแนวทางอีกแบบหนึ่ง
      มันน่าจะทำหลายอย่างที่ ggplot2 ทำได้ และอาจทำบางอย่างที่ ggplot2 ทำไม่ได้ด้วย แต่สำหรับงานจำนวนมากไปอีกนาน ggplot2 ก็น่าจะยังทรงพลังกว่า

  • อันนี้ดูเจ๋งมากจนผมคิดว่าจะลองใช้เร็วๆ นี้
    สิ่งที่ทำให้ผมรู้สึกคลิกมากคือคำอธิบายใน เอกสาร grammar
    การเลือกข้อมูลด้วย SELECT ที่คุ้นเคยอยู่แล้ว จากนั้นสลับจากตารางไปเป็น plot ด้วย VISUALIZE หรือ VISUALISE แล้วค่อยแมป aesthetics ด้วย DRAW และค่อยๆ ซ้อน SCALE, FACET, LABEL ต่อไป เป็นลำดับที่ให้ความรู้สึกเหมือน วิธีคิดเชิงโครงสร้างของ SQL ถูกต่อยอดออกไปตรงๆ

  • ผมชอบ แนวทางแบบ layering มากจริงๆ
    พอเริ่มทำอะไรที่เกินกว่ากราฟพื้นฐาน มันดูเหมือนจะแก้ปัญหาที่ผมเจอบ่อยในเครื่องมือผสม SQL-visualisation อื่นๆ ได้ดีมาก