DuckLake - ฟอร์แมตดาต้าเลกและแค็ตตาล็อกแบบรวมศูนย์

 (ducklake.select)
13 คะแนน โดย GN⁺ 2025-05-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โซลูชันใหม่ที่รวมดาต้าเลกและฟอร์แมตแค็ตตาล็อกเข้าไว้ด้วยกัน
  • ทำงานบนพื้นฐานของไฟล์ Parquet และฐานข้อมูล SQL และช่วยให้สามารถสร้างดาต้าเลกที่เรียบง่ายกว่าสถาปัตยกรรมเลคเฮาส์แบบดั้งเดิมได้
  • สามารถจัดการแค็ตตาล็อกเมทาดาทาบนฐานข้อมูลหลายชนิด เช่น PostgreSQL, SQLite, MySQL, DuckDB
  • รองรับฟีเจอร์หลากหลาย เช่น snapshot, time travel query, การเปลี่ยน schema, partitioning พร้อมทั้งมีการจัดการ snapshot แบบเบาที่ไม่จำเป็นต้อง compact บ่อย
  • รองรับโมเดล DuckDB แบบหลายผู้เล่นที่หลายอินสแตนซ์สามารถอ่านและเขียนข้อมูลพร้อมกันได้ และมีการใช้งานโมเดลการจัดการ concurrencyที่ DuckDB ปกติยังไม่รองรับ
  • DuckLake เป็นแนวคิดที่ครอบคลุมทั้งสเปก, ส่วนขยาย DuckDB, และชุดข้อมูลที่จัดเก็บในฟอร์แมต DuckLake และเผยแพร่ภายใต้MIT License

แนะนำ DuckLake

  • DuckLake เป็นฟอร์แมตแบบเปิดที่สร้างโดยทีม DuckDB ซึ่งมอบความสามารถดาต้าเลกระดับสูงโดยไม่ต้องมีเลคเฮาส์ที่ซับซ้อน
  • เพียงมีฐานข้อมูล SQL และไฟล์ Parquet ก็สามารถสร้างคลังข้อมูลของตนเองได้
  • ใช้ฐานข้อมูลเพื่อจัดการเมทาดาทา: PostgreSQL, SQLite, MySQL, DuckDB

ฟีเจอร์หลักของ DuckLake

  • การดำเนินงานของดาต้าเลก

    • snapshot
    • การดูข้อมูลย้อนหลังตามเวลา (Time travel)
    • การพัฒนา schema
    • partitioning

  • การจัดการ snapshot แบบเบา

    • สร้าง snapshot ได้โดยไม่จำกัดจำนวน
    • ทำงานได้โดยไม่ต้อง compact บ่อย

  • ธุรกรรม ACID

    • รับประกันการเข้าถึงพร้อมกันและธุรกรรมสำหรับการดำเนินการหลายตาราง

  • การออกแบบที่เน้นประสิทธิภาพ

    • ใช้สถิติสำหรับ filter pushdown
    • คิวรีได้รวดเร็วแม้กับชุดข้อมูลขนาดใหญ่

คำถามที่พบบ่อย

  • ทำไมจึงควรใช้ DuckLake?

    • เหมาะเมื่อจำเป็นต้องมีโซลูชันแบบเบาที่รวมดาต้าเลกและแค็ตตาล็อกเข้าด้วยกัน
    • รองรับสภาพแวดล้อมแบบหลายผู้เล่นที่ DuckDB หลายอินสแตนซ์อ่านและเขียนชุดข้อมูลเดียวกันได้
      • นี่คือโมเดล concurrencyที่ DuckDB เดิมยังไม่รองรับ
    • แม้ใช้เพียง DuckDB ก็ยังได้รับข้อดีอย่างการดูข้อมูลย้อนหลังตามเวลา, partitioning และโครงสร้างการจัดเก็บแบบหลายไฟล์

  • DuckLake คืออะไร?

    • DuckLake หมายถึง 3 สิ่งต่อไปนี้:
      1. ข้อกำหนดของฟอร์แมต DuckLake (specification)
      2. ส่วนขยาย DuckDB ที่รองรับ DuckLake (ducklake extension)
      3. ชุดข้อมูลเองที่จัดเก็บในฟอร์แมต DuckLake

  • ไลเซนส์ของ DuckLake คืออะไร?

    • เผยแพร่ภายใต้MIT License

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

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

 
GN⁺ 2025-05-29
ความเห็นจาก Hacker News

  • มีจุดหนึ่งที่รู้สึกค้างคาใจกับ Parquet มาตลอด คือเรื่อง ranged partitioning ที่บรรดา “data lake / lakehouse” หลายเจ้าไปแก้กันคนละแบบจนไม่เข้ากัน แอปพลิเคชันของฉันแทบจะเข้ากับ Parquet ได้สมบูรณ์แบบ แต่ข้อมูลที่จัดการเป็นแบบ log อนุกรมเวลา ซึ่ง timestamp ไม่ได้กระจายตัวสม่ำเสมอ คอลัมน์พาร์ทิชันเดินตาม Hive partitioning แต่ในขณะเดียวกันก็ถูกแบ่งตาม timestamp โดยธรรมชาติ ปัญหาคือ Hive partitioning ไม่รองรับรูปแบบนี้ ทำให้เครื่องมือ query หลัก ๆ นำเข้าโครงสร้างข้อมูลของฉันได้ไม่ถูกต้อง ต้องเพิ่มวิธีแก้ขัดอย่างคอลัมน์อิงวันที่ที่ไม่จำเป็น หรือไม่ก็ปล่อยให้ไฟล์กองรวมกัน ซึ่งมีปัญหาเรื่องประสิทธิภาพและต้นทุน Iceberg, Delta Lake ฯลฯ ทำ ranged partitioning ได้ แต่ฉันไม่ต้องการความซับซ้อนระดับนั้น และอยากให้มีการทำมาตรฐานเรื่องกฎการตั้งชื่อไฟล์หรือชื่อไดเรกทอรีที่เรียบง่ายกว่านี้ อีกอย่างคือฟอร์แมตอย่าง Parquet row, Arrow row, Thrift, protobuf ฯลฯ คล้ายกันมากแต่ไม่เหมือนกันเสียทีเดียว ถ้ามี binary format สำหรับ row เดี่ยวหรือ row stream มาคู่กัน ก็น่าจะช่วยให้เครื่องมือต่าง ๆ ทำงานร่วมกันได้ดีขึ้น

    • สงสัยว่าแค่ footer metadata ของไฟล์ Parquet ก็เพียงพอที่จะดึงข้อมูลที่ต้องการแล้วหรือไม่ ใน metadata มีค่า timestamp ต่ำสุด/สูงสุดของคอลัมน์นั้นอยู่แล้ว ดังนั้นตอน query เครื่องมือ query สามารถอ่านแค่ metadata แล้วตัดสินใจได้ว่าจะอ่านไฟล์นั้นหรือไม่ เพื่อหลีกเลี่ยงการอ่านที่ไม่จำเป็น

    • ข้อมูลเวลาเป็นของที่จัดการยาก แต่บางวิธีก็เลี่ยงได้ อย่า query time series ต้นฉบับโดยตรง แต่ให้ normalize timestamp แล้วเก็บไว้ตั้งแต่ขั้นตอนประมวลผล event จะมีประโยชน์ ใช้วิธีหา offset โดยอิง sliding window เพื่อหา event start point ระบุจุดที่ time series กลับไปยัง baseline (0) แล้วใช้สิ่งนั้นเป็นหน่วยของ event

    • Hive รองรับ partitioning สองแบบคือ injected และ dynamic สามารถใช้คอลัมน์ hour ที่อิงเวลา UNIX เป็น partition key ได้ (จำนวนเต็มที่เพิ่มครั้งละ 3600 วินาทีนับจาก epoch) อาจต้องระบุช่วงพาร์ทิชันที่จะอ่านใน query engine แต่ก็ใช้ใน query แบบ datepartition >= a AND datepartition < b ได้ Iceberg ทำให้เรื่องนี้ง่ายกว่ามาก โดยใช้ช่วง timestamp ได้ตรง ๆ และตัดพาร์ทิชันที่ไม่ต้องใช้ทิ้งอัตโนมัติโดยไม่ต้องพึ่ง metadata

    • ในไลบรารีระดับล่างของ arrow/parquet เราสามารถควบคุม row group และ data page ได้โดยตรง ฉันเคยใช้ crate arrow-rs แล้วทำให้ความเร็วในการ query ไฟล์ดีขึ้นมากกว่า 10 เท่า บางกรณีมี row group น้อย บางกรณีก็มีจำนวนมากมาก แต่ถ้าข้ามเฉพาะ row group ที่ไม่ต้องการได้เร็ว ปัญหา skew ก็ไม่ใช่เรื่องใหญ่ อย่างไรก็ดี ต้องระวังว่ามีข้อจำกัดที่ไฟล์หนึ่งไฟล์มี row group ได้สูงสุด 2^15 กลุ่ม

    • ปัญหานี้ดูจะเป็นข้อจำกัดของ Hive มากกว่าจะเป็นปัญหาของ Parquet ต้องเปิดไฟล์ Parquet เพื่อดูข้อมูล min, max ของคอลัมน์ แต่ถ้าไม่ใช่ข้อมูลในช่วงที่ต้องการก็จะไม่มีคำขอเพิ่มเติม ถ้ายกระดับ metadata นี้ไปใช้ชั้นบนกว่าเดิม เช่น ใน DuckLake ก็จะมีประสิทธิภาพมาก

  • หนึ่งในจุดที่อึดอัดที่สุดของ Iceberg (Delta Lake ก็คล้ายกัน แต่ส่วนตัวรู้สึกว่า Iceberg ยุ่งยากกว่า) คือมันลองใช้บน notebook หรือสภาพแวดล้อม local ได้ยาก Delta Lake มี implementation ฝั่ง Python หลายตัวแต่แตกกระจัดกระจาย ส่วน Iceberg ก็มีความยุ่งยากอย่างการต้องตั้งค่า JVM cluster ฉันเคยพยายามใช้ชุด sqlite/postgres + duckdb + parquet เพื่อเก็บลง blob storage แต่ก็ยุ่งพอสมควร ฝั่ง DuckDB กลับทำงานได้ทันทีโดยไม่ต้องลำบากแบบนี้ และขยายไปถึงข้อมูลขนาดพอเหมาะได้อย่างเป็นธรรมชาติ ทีม DuckDB เข้าใจพื้นที่นี้ดีมาก และฉันคาดหวังไว้สูงจริง ๆ

    • ไม่แน่ใจว่าเคยลองใช้ PyIceberg หรือยัง เป็น implementation แบบ Python ล้วนและทำงานได้ดีพอสมควร รองรับทั้ง SQL Catalog และ in-memory catalog ที่ใช้ SQLite
      https://py.iceberg.apache.org/

    • มีคู่มือตั้งค่าแบบทีละขั้นสำหรับ S3 และ RDS อยู่ การปรับเป็น local sqlite ก็คงไม่ยาก
      https://www.definite.app/blog/cloud-iceberg-duckdb-aws

    • ลองบนเครื่องตัวเองได้ง่ายมากจริง ๆ ใน marimo notebook ใช้โค้ดไม่กี่บรรทัดก็พอ (หมายเหตุ: ฉันเป็นนักพัฒนา marimo)
      https://www.youtube.com/watch?v=x6YtqvGcDBY

    • กำลังคิดอยู่ว่าจะทำ helm chart ที่ทำงานกับ k3s ได้ดีไหม ถ้าใช้ datapains ก็ยก trino ขึ้นมาได้ง่าย และถ้าปรับอีกนิดก็น่าจะรัน hivemetastore ได้ด้วย ฉันทดลองการทำงานทั้งชุดโดยเชื่อม Iceberg connector เข้ากับ trino โครงสร้างคือโหลดข้อมูลเข้า hive แล้วให้ trino ชี้ไปที่ตารางเดียวกัน จากนั้นใช้ select เพื่อ insert เข้า iceberg ถ้าฝั่ง DuckDB ออกสภาพแวดล้อมที่ใช้งานได้ง่ายแบบนี้จริง ๆ ก็น่าจะครองความเป็นผู้นำในอุตสาหกรรมได้ด้วย

    • delta-io (อิง deltalake-r) ทำงานบนเครื่อง local ได้ง่ายมาก ติดตั้งผ่าน pip แล้วก็เขียน catalog กับไฟล์ได้เลย
      https://delta-io.github.io/delta-rs/

  • เป็นคำวิจารณ์ Iceberg ที่คมมาก—ในเมื่อสุดท้ายก็ใช้ฐานข้อมูลอยู่ดี ทำไมต้องเอา metadata ไปใส่ไว้ในไฟล์แล้วคอยจัดการด้วยก็ไม่รู้ DuckLake อาจไม่ง่ายที่จะประสบความสำเร็จในวงกว้างนอก DuckDB แต่สุดท้ายแล้วโครงสร้างก็น่าจะไปทางที่ catalog รับหน้าที่ดูแล metadata ด้วย และฟอร์แมต Iceberg แบบเดิมอาจค่อย ๆ กลายเป็นเพียงช่วงเวลาหนึ่งในประวัติศาสตร์

  • ระบบ Lakehouse เดิม ๆ (เช่น Iceberg) เก็บข้อมูลสำคัญระดับตารางอย่าง schema/รายการไฟล์ แยกกระจายเป็นไฟล์ metadata ขนาดเล็กบน object storage อย่าง S3 สิ่งนี้ทำให้ query planning หรือการอัปเดตตารางต้องเรียกเครือข่ายจำนวนมาก จึงช้าหรือเกิดการชนกันบ่อย DuckLake นำ metadata ทั้งหมดไปเก็บในฐานข้อมูล SQL ที่เร็วและมี transaction ที่ดี ทำให้ดึงข้อมูลที่ต้องการทั้งหมดได้ด้วย query เดียว ประสิทธิภาพและความน่าเชื่อถือจึงดีขึ้นมาก

  • แถลงการณ์เกี่ยวกับ DuckLake: https://ducklake.select/manifesto/

  • ที่บริษัท ฉันกำลังพัฒนา “poor man’s datalake” โดยใช้ Python binding ของ deltalake-rs กับ duck db โครงสร้างคือเก็บไฟล์ parquet ลง blob storage แต่มีปัญหากับ concurrent write ตลอด การให้ cloud function ดึงข้อมูลจาก API ตามรอบเวลาที่กำหนดนั้นไม่มีปัญหา แต่พอรัน backfill หลายรอบ มันเสี่ยงจะชนกับ timer function ที่รันพร้อมกัน โดยเฉพาะเวลามีงานหลายร้อยชิ้นค้างอยู่ใน backfill queue และ worker ทำงานเต็มกำลัง

    • มีวิธีคือเติม suffix แบบสุ่มไว้ท้ายชื่อไฟล์

    • ถ้าทำ lease ชั่วคราวบนไฟล์ json ก่อน write แล้วจัดการคำขอ write ผ่านคิว ก็จะป้องกันการชนกันได้

  • โซลูชันคู่แข่งที่พยายามแก้ข้อจำกัดของ Iceberg โดยเฉพาะเรื่องการจัดการ metadata (เช่น Snowflake ใช้ FoundationDB จัดการ metadata ส่วน Iceberg ยังใช้ไปถึง blob storage)
    https://quesma.com/blog-detail/apache-iceberg-practical-limitations-2025

    • ฉันก็ได้ความรู้สึกคล้ายกัน แต่ดูจากวิดีโอแล้ว DuckLake ไม่ได้เป็นคู่แข่งโดยตรง
      https://youtu.be/zeonmOO9jm4?t=4032
      DuckLake จะเขียนไฟล์ manifest/metadata สำหรับ Iceberg เพื่อซิงก์เฉพาะตอนจำเป็น และรองรับการอ่านข้อมูล Iceberg ที่มีอยู่แล้วด้วย มันคือการปรับปรุงปัญหาแกนกลางของ Iceberg มากกว่า ไม่ใช่ผลิตภัณฑ์คู่แข่งแยกต่างหาก แต่เป็นโครงสร้างที่เชื่อมต่อสองทางกับ Iceberg ได้อย่างสะอาด

    • การที่ metadata พองตัวขึ้นนั้นจริง ๆ จัดการได้ตามสถานการณ์

      • จำนวน snapshot
      • การเปลี่ยน schema ขนาดใหญ่บ่อย ๆ
      • การอัปเดตระดับ row บ่อย/มีไฟล์เล็กจำนวนมาก
      • ข้อมูลสถิติ ฯลฯ
        ในอดีต รายการสุดท้ายเคยเป็นปัญหาเพราะ schema มีขนาดใหญ่ ปัจจุบันเอนจินส่วนใหญ่มีเครื่องมืออย่าง compaction, snapshot export ฯลฯ ช่วยจัดการได้ แม้ผู้ใช้ยังต้องรับผิดชอบเองส่วนหนึ่ง S3 table ก็มีฟังก์ชันดูแลบางอย่างให้ ถ้า metadata มีขนาด 1~5MB ก็แทบไม่ใช่ปัญหา ความเร็วในการ commit จะขึ้นกับขนาด metadata และจำนวน writer ฉันเคยจัดการ metadata ขนาดเกิน 1GB ด้วยสคริปต์เองมาแล้ว—โดยทั่วไปแค่ลบ snapshot ที่ถูกเขียนทับไปแล้ว (ส่วนการลบไฟล์จริงปล่อยให้ bucket policy จัดการ) หรือไม่ก็ล้าง schema version เก่า ๆ ก็แก้ได้

  • สุดท้ายแล้ว ถ้าจะสร้างฐานข้อมูลให้ดี ก็ต้องสร้างให้เหมือนฐานข้อมูลจริง ๆ น่าทึ่งมากสำหรับทีม DuckDB

  • อยากรู้ว่ามันมีความสัมพันธ์กับ Mother Duck(https://motherduck.com/) อย่างไร บริษัทนั้นทำ “DuckDB-powered data warehousing” และเริ่มก่อน DuckLake

    • MotherDuck กับ DuckLake จะผสานกันได้ดีมาก ข้อมูลใน MotherDuck จะถูกเก็บใน DuckLake เพื่อเพิ่ม scalability, concurrency และ consistency และยังเปิดให้เครื่องมือภายนอกเข้าถึง underlying data ได้ด้วย เรากำลังพัฒนาส่วนนี้อยู่ในช่วงไม่กี่เดือนที่ผ่านมา และน่าจะมีข้อมูลเพิ่มเติมออกมาเร็ว ๆ นี้

    • MotherDuck คือบริการที่คอยจัดระเบียบให้อัตโนมัติเมื่อคุณนำข้อมูลขึ้นไป และให้ data interface ผ่าน DuckDB ถ้าต้องการความเป็น lakehouse มากขึ้น การเชื่อมกับ blob storage การผสานกับ DuckLake เพิ่มเติม หรืออยากให้ metadata ไปเก็บอยู่บน MotherDuck ก็สามารถใช้ DuckLake ได้

    • MotherDuck เป็นบริการโฮสต์ duckdb บนคลาวด์ ส่วน DuckLake เป็นระบบที่เปิดกว้างกว่ามาก ใน DuckLake คุณสามารถสร้างคลังข้อมูลระดับ petabyte บนหลายสภาพแวดล้อมอย่าง S3 หรือ EC2 ใช้หลายอินสแตนซ์ มีหลาย reader/writer และทั้งหมดเป็น transactional ได้ MotherDuck มี writer ได้ครั้งละหนึ่งตัวเท่านั้น และ read replica ก็มี latency ราว 1 นาที แถมไม่เป็น transactional ด้วย หลายอินสแตนซ์จึงไม่สามารถเขียนคนละตารางพร้อมกันได้ DuckLake ยังให้ทั้งการแยก storage ออกจาก compute และชั้น metadata ที่มี transaction สูงด้วย

  • ฉันชอบ duckDB มาก และรู้สึกว่า DuckLake ก็น่าสนใจมาก คำถามคือ ถ้าจะเริ่มใช้ตอนนี้ ในบริษัทที่มี Snowflake อยู่แล้ว นักวิเคราะห์แต่ละคนจะต้องติดตั้ง duckdb + ส่วนขยายบนเครื่องตัวเอง แล้วชี้ไปยัง blob store กับฐานข้อมูลสำหรับส่วนขยาย datalake (เช่น duckdb ที่รันอยู่บน VM) ใช่ไหม เวลา query แล้ว compute จะเกิดขึ้นที่ไหน และถ้าต้องการทำงานใหญ่ขึ้นจะทำอย่างไร ต้องให้ทุกคน ssh เข้าไป query บน duckdb VM ขนาดใหญ่หรือไม่ อยากให้ช่วยอธิบายส่วนนี้

    • ถ้ารัน duckdb แบบ local การประมวลผลก็เกิดบนเครื่องของแต่ละคน ถ้าต้องการ compute มากขึ้นก็ยก VM ขึ้นมาใช้งานได้ ทั้งสองแบบทำได้—งานเล็กใช้ local ส่วน workload ใหญ่ค่อยขยายไปที่ VM