F3 - รูปแบบไฟล์ข้อมูลโอเพนซอร์สสำหรับอนาคต

 (github.com/future-file-format)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • F3 คือรูปแบบไฟล์ข้อมูลที่ออกแบบโดยคำนึงถึง ประสิทธิภาพ, การทำงานร่วมกันได้ และความสามารถในการขยาย
  • มันนำเสนอวิธีการจัดระเบียบข้อมูลที่แก้ข้อจำกัดด้าน เลย์เอาต์ ของรูปแบบยุคก่อนอย่าง Parquet พร้อมคงความสามารถในการทำงานร่วมกันและการขยายผ่านตัวถอดรหัส Wasm แบบฝังในตัว
  • ไฟล์ F3 แบบอธิบายตัวเองได้มีโครงสร้างที่บรรจุไม่เพียงข้อมูลและเมทาดาทาเท่านั้น แต่ยังรวม ไบนารี WebAssembly สำหรับถอดรหัสข้อมูลไว้ด้วย
  • วิธีการฝังตัวถอดรหัสไว้ในไฟล์ต้องการพื้นที่จัดเก็บขั้นต่ำในระดับกิโลไบต์ และเป็นการออกแบบเพื่อรับประกันความเข้ากันได้บนทุกแพลตฟอร์ม แม้ไม่มีตัวถอดรหัสเนทีฟ
  • เป็นโครงการ Future-proof File Format ที่มอบทั้งโครงสร้างการจัดระเบียบข้อมูลและ API แบบทั่วไป เพื่อให้นักพัฒนาสามารถเพิ่มวิธีการเข้ารหัสใหม่ได้อย่างง่ายดาย
  • สถานะปัจจุบันคือ ต้นแบบงานวิจัย ที่ใช้ตรวจสอบแนวคิดในงานวิชาการ และห้ามนำไปใช้ในโปรดักชัน
  • การบิลด์ได้รับการทดสอบเฉพาะบน Debian 12 บนเครื่อง Intel เท่านั้น และการบิลด์แพ็กเกจ PoC กับการทดสอบหน่วยทำได้ด้วย cargo build -p fff-poc, cargo test -p fff-poc
  • นิยามรูปแบบไฟล์อิงตาม FlatBuffer และมีทั้งโค้ดหลัก, การติดตั้งใช้งานการถอดรหัส Wasm, เบนช์มาร์กสำหรับการทดลองในงานวิชาการ และสคริปต์ที่ให้มาพร้อมกัน
  • ไลเซนส์คือ MIT License

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

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

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Hacker News

  • ไม่ค่อยเข้าใจว่าทำไมถึงได้คะแนนโหวตเยอะขนาดนี้ และหน้าแลนดิ้งเพจก็ไม่ค่อยดีนัก ดูเหมือนว่าไปอ่านงานวิจัยจะดีกว่า: https://dl.acm.org/doi/epdf/10.1145/3749163
    มันดูเหมือน รูปแบบการจัดเก็บแบบคอลัมน์ ที่พยายามแก้ข้อเสียบางส่วนของ Parquet แต่จุดตัดสินที่แท้จริงของรูปแบบแบบนี้คือความเข้ากันได้ และรูปแบบใหม่ก็เสียเปรียบในจุดนี้ทันทีที่ถือกำเนิดขึ้น
    Parquet แข็งแกร่งมากเพียงเพราะเป็นตัวแรกที่แพร่หลายอย่างกว้างขวาง และตามงานวิจัย แม้แต่ Parquet เวอร์ชันที่ถูกใช้มากที่สุดก็ยังเป็นเวอร์ชันเก่าสุดจากปี 2013 ซึ่งเท่ากับว่าแม้แต่ Parquet เองก็ยังแทนที่ Parquet ไม่ได้
    ถ้า F3 จะก้าวข้ามสิ่งนี้ได้ก็คงต้องมีผลลัพธ์ที่แข็งแกร่งมาก แต่ยังดูไม่เป็นแบบนั้น
    ส่วนตัวแล้วปัญหาใหญ่ที่สุดของ Parquet สำหรับผมคือเรื่อง หนึ่งตารางต่อหนึ่งไฟล์ ซึ่งที่นี่ก็ไม่ได้แตะต้อง แถมชื่อยังให้ความรู้สึกเว่อร์ไปหน่อย และแม้จะใส่ไบนารี Wasm สำหรับถอดรหัสมาให้ แต่การพาร์สก้อนนั้นก็ยังต้องใช้ FlatBuffers อยู่ดี ทำให้เป้าหมายดูไม่ชัดเจน
    ผลงานหลักดูเหมือนจะเป็นการปรับปรุงการเข้าถึงแบบสุ่ม แต่เดิมทีการจัดเก็บแบบคอลัมน์ก็เกิดมาเพื่อยอมแลกการเข้าถึงแบบสุ่มกับการวิเคราะห์ที่รวดเร็ว และ F3 กลับเหมือนยอมเสียการวิเคราะห์ที่เร็วเพราะตัวถอดรหัส Wasm เลยทำให้เข้าใจได้ยาก

    • เรื่อง หนึ่งตารางต่อหนึ่งไฟล์ ของ Parquet ดูจะใกล้เคียงกับความคาดหวังที่ query engine มีต่อรูปแบบไฟล์ มากกว่าจะเป็นตัวรูปแบบไฟล์เอง
      Spark, DataFusion และ DuckDB ต่อให้รับไฟล์ที่มีหลายตารางได้ ก็คงไม่ค่อยรู้ว่าจะต้องทำอะไรกับมัน
      จริงอยู่ที่ Parquet ทำหลายอย่างได้ดีมาก แต่ไม่ได้หมายความว่าเพียงเพราะมันมาก่อน มันต้องเป็นรูปแบบไฟล์สำหรับงานวิเคราะห์เพียงหนึ่งเดียวไปตลอดกาล
      การวิเคราะห์ที่รวดเร็วกับเวิร์กโหลดแบบ machine learning สมัยใหม่ โดยเนื้อแท้แล้วเป็นการผสมกันระหว่างการสแกนทั้งชุดกับการเข้าถึงแบบสุ่ม
      ผู้เขียน F3 บางคนก็เคยเขียนงานวิจัยที่ลงรายละเอียดข้อเสียของ Parquet ไว้ด้วย: https://www.vldb.org/pvldb/vol17/p148-zeng.pdf
      รูปแบบอย่าง Vortex, Lance และ F3 ที่ออกมาในช่วงหลัง กำลังพยายามแก้ปัญหาที่สรุปไว้ในงานวิจัยนั้น
      Lance มีแนวคิดที่น่าสนใจ ส่วน Vortex เปลี่ยนตัวเข้ารหัสแบบกล่องดำของ Parquet ให้เป็นการเข้ารหัสที่โปร่งใส โดยเน้น ความขยายตัวและประสิทธิภาพ
      สิ่งนี้ช่วยลดการต้องประนีประนอมระหว่างการถอดรหัสปริมาณมากกับการถอดรหัสระดับองค์ประกอบ ทำให้ได้ทั้งการสแกนทั้งชุดที่มีประสิทธิภาพและการเข้าถึงแบบสุ่มที่เร็วมาก
      ตัวอย่างเช่น LangChain อธิบายว่าได้สร้างระบบที่อิงกับไฟล์ Parquet ขึ้นใหม่ด้วย Vortex และเห็นการเพิ่มความเร็วอย่างมาก: https://www.langchain.com/blog/introducing-smithdb
      อนึ่ง ผมกำลังพัฒนา Vortex อยู่ เลยได้คิดกับคำถามว่า “ทำไมต้องสร้างรูปแบบใหม่” โดยตรงมามาก
    • ผมมองว่า ความเรียบง่าย ของ Parquet ไม่ใช่ข้อเสีย แต่เป็นข้อดี
      ถ้าต้องการหลายตาราง ก็แค่รวมไฟล์ Parquet หลายไฟล์เข้าด้วยกันด้วย tar และมันเรียบง่ายอย่างสวยงาม เพราะอ่านได้ง่ายในทุกภาษาที่มีไลบรารี tar และ Parquet
    • ตอนจัดการกับ Parquet ผมเคยจินตนาการถึงรูปแบบชื่อ .parquetz
      ถ้าเป็นไฟล์ zip ที่บรรจุไฟล์ Parquet แบบไม่บีบอัดหลายไฟล์ ก็จะย้ายหลายตารางได้ในไฟล์เดียว และน่าจะเข้าถึงได้ผ่าน range requests ด้วย
    • เมื่อเทียบกับหน้าแลนดิ้งเพจสมัยนี้ส่วนใหญ่ที่เต็มไปด้วยข้อความรบกวนราวกับสร้างด้วย ChatGPT อันนี้กลับถือว่าแปลกใหม่เสียด้วยซ้ำ

  • แนวคิดที่ไม่ต้องพึ่ง SDK หรือไลบรารีรายภาษา และถ้าไม่มีก็ fallback ไปใช้ เมธอด Wasm ที่ฝังมาให้ได้นั้น ค่อนข้างชาญฉลาดทีเดียว
    “ไฟล์ F3 แบบ self-describing แต่ละไฟล์ไม่ได้มีแค่ข้อมูลและเมทาดาทา แต่ยังรวมไบนารี WebAssembly (Wasm) สำหรับถอดรหัสข้อมูลด้วย พื้นที่จัดเก็บที่ต้องใช้เพื่อฝังตัวถอดรหัสลงในแต่ละไฟล์มีขนาดเล็กมาก (ระดับกิโลไบต์) และรับประกันความเข้ากันได้บนทุกแพลตฟอร์ม แม้จะไม่มี native decoder ก็ตาม”

    • แปลว่าไม่ต้องให้นักโจมตีสร้างไฟล์เสียหายโดยเจตนาด้วยซ้ำ แค่ใส่โค้ดโจมตีลงไปในไฟล์ข้อมูลเองก็พอหรือ?
    • ฟังดูเท่มาก แต่รู้สึกว่าน่าจะพังได้เมื่อเป็นรูปแบบที่ซับซ้อนสูง
      ตัวถอดรหัสที่ฝังอยู่ใน PDF จะหน้าตาเป็นอย่างไรนะ?
      เพราะมันผูกติดกับไบต์ของไฟล์อย่างแน่นหนา คนสร้างไฟล์อาจเลือกได้ว่ารูปแบบไหนสมเหตุสมผล แต่ก็ไม่ได้แปลว่าทุกรูปแบบจะมี “ขั้นตอนถอดรหัสที่ถูกต้องหนึ่งเดียว”
    • ไม่เข้าใจว่ามันควรทำงานอย่างไร
      ตัวถอดรหัสถอดออกมาเป็นอะไร?
      มันต้องขึ้นอยู่กับชนิดของข้อมูลทั้งหมดอยู่แล้ว บางรูปแบบเป็นสตรีมไบต์ บางรูปแบบเป็นระนาบพิกเซลสองมิติ ขณะที่บางรูปแบบต้องมีจุดยอด ระนาบพิกเซลสองมิติ และ UV map และในบางกรณี object graph ก็ดูเป็นธรรมชาติกว่า
    • ดูเหมือนการกลับมาของ Applet
    • Wasm ดีกว่า C bindings ตรงไหน?

  • ไม่รู้ว่าคนอื่นกำลังดูอะไรแล้วถึงพูดกันแบบนี้
    ใน README แทบไม่มีข้อมูลเลยว่ามันคืออะไร หรือแก้ปัญหาอะไร มีแค่คำอธิบายของ FlatBuffers กับลิงก์ไปไดเรกทอรีซอร์สโค้ด
    ผมพลาดบริบทอะไรไปหรือเปล่า?

  • ดูเหมือนว่ายังต้องการคำอธิบายเรื่อง “ทำไม” เพิ่มอีกหน่อย
    เขาบอกว่าจะเอาชนะข้อเสียของ Parquet ได้ แต่ก็อยากรู้ว่าข้อเสียนั้นคืออะไร
    เรื่องการรองรับเครื่องมืออย่างกว้างขวางคงไม่ใช่แน่
    ทำไมต้องเลิกใช้ Parquet หรือ ORC แล้วหันมาใช้โครงสร้างนี้?

    • คำตอบของ “ทำไม” เชื่อมไปยังเอกสารอ้างอิงท้าย README และดูเหมือนว่าไม่ได้ตั้งใจให้ใช้แค่จาก repository นี้อย่างเดียว
      น่าจะควรเริ่มจากอ่านงานวิจัยก่อน: https://doi.org/10.1145/3749163
    • ตอนแรกไม่เข้าใจเลยว่าเขากำลังพูดถึงอะไร แต่มีประเด็นที่ดีเกี่ยวกับการที่ Parquet ไม่ได้คำนึงถึงฮาร์ดแวร์มากนัก และเมทาดาทาก็ค่อนข้างเป็นแบบส่วนกลาง
      บทความนี้น่าสนใจดี: https://medium.com/@reliabledataengineering/f3-the-future-pr...
    • หลายข้อในนี้ดูเหมือนจะจัดการได้ถ้าลงเวลาในการพัฒนา Parquet เพิ่มอีกหน่อย
    • ในงานวิจัยมีการกล่าวถึง Parquet, ORC, Nimble, Lance, TSFile, Bullion, BtrBlocks

  • บางคนบอกว่าเป็นไอเดียอัจฉริยะ แต่ถ้าจะรับบทคนขี้สงสัยแบบ HN มันก็ดูค่อนข้างไม่เข้าท่า
    ฟอร์แมตบีบอัดข้อมูลเป็นเรื่องรองเมื่อเทียบกับสิ่งที่จะทำกับข้อมูลนั้นหลังถอดรหัสแล้ว
    ไฟล์เสียงกับภาพ SVG นั้นต่างกันโดยสิ้นเชิง และถึงจะมี VM ในตัวที่คลายวิดีโอออกมาเป็นพิกเซลดิบได้ ก็ไม่ได้แปลว่าจะเปิดวิดีโอนั้นในโปรแกรมแก้ไขข้อความได้ ดังนั้นจึงไม่ได้เกิดการทำงานร่วมกันแบบใหม่อย่างแท้จริง
    ทุกฟอร์แมตใหม่ก็ยังต้องมีการจัดการเฉพาะฟอร์แมตอยู่ดี
    ตัวอย่างเช่น ถ้าคุณสร้างวิธีบีบอัดวิดีโอที่ดีกว่า H.265 แต่ทุกแพลตฟอร์มยังไม่รองรับ ก็อาจมีประโยชน์ในแง่ฝังตัวถอดรหัสไว้เพื่อให้เล่นบนฮาร์ดแวร์เก่าได้
    แต่นั่นก็เผยจุดอ่อนเช่นกัน ฮาร์ดแวร์เก่าคงมีโอกาสน้อยที่จะถอดรหัสฟอร์แมตวิดีโอแห่งอนาคตด้วยซอฟต์แวร์ได้ดี และถึงแนวคิดนี้จะเกิดขึ้นตั้งแต่ยุค 1990 ก็คงไม่ได้ทำให้ดู Netflix บน i386 ได้
    ในทำนองเดียวกัน ก็ยังน่าสงสัยว่าจะช่วยให้เปิดไฟล์ Word 2021 ใน Word 97 ได้จริงไหม เพราะไม่มีความสอดคล้องแบบ 1:1 ระหว่างโครงสร้างข้อมูล
    ถ้าความเข้ากันได้นี้ไม่ใช่ชัยชนะที่ชัดเจน ก็ไม่แน่ใจว่าเป้าหมายคืออะไร
    ข้อเสียก็ชัดเจนอยู่แล้ว หากมีบั๊กในตัวถอดรหัสที่ต้องแก้ คุณจะไปแพตช์ไฟล์ทั้งหมดที่ฝังตัวถอดรหัสนั้นไว้แล้วอย่างไร?
    ยังมีภาระด้านขนาดและความเสี่ยงด้านความปลอดภัยด้วย และเท่ากับเพิ่ม พื้นผิวการโจมตี อย่างมากให้ parser ของทุกฟอร์แมต เปิดโอกาสให้เกิดการรันโค้ดจากระยะไกล การโจมตีให้ทรัพยากรหมด ฯลฯ มากขึ้น
    ไม่ใช่ว่าเป็นแนวทางที่ผิดเสมอไป แต่สิ่งสำคัญคือประโยชน์ที่ได้คืออะไร

    • ดูเหมือนคุณยังไม่เคยเจอปัญหาที่ฟอร์แมตตระกูลนี้พยายามแก้
      ถ้าลองค้นหา column-oriented storage format ตอนนี้มีการสรุปข้อดีข้อเสียไว้ค่อนข้างดีแล้ว
      แน่นอนว่าไม่ใช่สำหรับการถอดรหัสวิดีโอ

  • ข้อดีของฟอร์แมตสมัยใหม่บางประเภทคือเครื่องมือต่าง ๆ สามารถอ่านได้เร็วมากในความรู้สึกใช้งานจริง
    ตัวอย่างเช่น DuckDB สามารถใช้การปรับแต่งหลายอย่างได้เมื่ออ่านฟอร์แมตเนทีฟของตัวเองหรือ Parquet
    แต่ผมไม่แน่ใจว่าจะใช้การปรับแต่งแบบนั้นได้มีประสิทธิภาพแค่ไหนกับฟอร์แมตที่ต้องรันก้อน Wasm เพื่อจะเข้าใจฟอร์แมต
    ไม่ว่าจะไม่ใช่ SIMD หรือปรับแต่งด้วย SIMD ถ้าต้องไล่อ่านข้อมูลหนึ่งรอบในขณะที่รอบนั้นไม่เข้าใจคิวรี ก็อาจเสียเปรียบไปแล้ว
    ผมแค่อ่านคร่าว ๆ ต้นงานวิจัยเท่านั้น ดังนั้นฟอร์แมตจริงอาจไม่ได้ทั่วไปมากอย่างที่ฟังดู

    • เท่าที่เข้าใจ มันเป็น fallback mechanism

  • พอนึกภาพการใช้แทน EXE แตกไฟล์ในตัวได้บ้าง แต่เหตุผลสำคัญส่วนหนึ่งที่เลือกใช้ฟอร์แมตไฟล์เฉพาะก็คือความสามารถเฉพาะที่ฟอร์แมตนั้นมีให้
    ระบบแบบ self-describing ก็อาจลงเอยเหมือนฟอร์แมตอื่น ๆ คือ “มีฟีเจอร์แข่งกันมากเกินไปจนไม่มีใครรองรับครบทั้งหมด”
    เช่น ไฟล์นี้สามารถ mmap ได้อย่างมีประสิทธิภาพหรือไม่?
    ถ้าข้างในเลียนแบบ tar ก็อาจจะได้ แต่ไม่ลองรันดูก็ไม่รู้
    มันสามารถกระโดดไปยังตำแหน่งไบต์ที่กำหนดเพื่อคลายข้อมูลออกมาแค่บางส่วนได้หรือไม่?
    อาจรองรับเฉพาะ exploratory release ล่วงหน้าของ ISO-36898533 และไลบรารีไฟล์ที่ใช้อยู่ก็อาจตัดการรองรับนั้นไปแล้วตั้งแต่ 6 ปีก่อน
    ถ้าเขียนทับใหม่ตรง 1MB ตรงกลาง จะเปลี่ยนแค่เพจนั้นบนดิสก์ได้เลยไหม หรือว่าต้องเขียนใหม่ทั้งก้อน?
    ก้อน Wasm อาจรองรับ API สำหรับเรื่องนี้ถึง 97 ตัว โดย 35 ตัวเป็นแค่สำเนาที่ต่างกันแต่ชื่อ จนมีขนาดใหญ่กว่าตัวข้อมูลเอง แต่ก็ไม่มีใครสนใจ
    สุดท้ายตัวเลือกที่พอจำแนกได้มี 19 แบบ แต่ตัวเร่ง Wasm แบบเนทีฟของ CPU รองรับจริงแค่สองสามแบบ คุณก็อาจยังต้องทำโค้ดให้เฉพาะทางหนักอยู่ดี
    อย่างน้อยถ้าเป็น *.tar.gz ก็ยังพอเดาได้ว่าทำอะไรได้บ้าง

  • ดีเลย โลกนี้ต้องการฟอร์แมตข้อมูลที่ดีกว่าอยู่เสมอ
    เพียงแต่ถ้าใน README เขียนข้อดีเมื่อเทียบกับ Parquet และฟอร์แมตไฟล์อื่นไว้ให้ชัดตั้งแต่แรก น่าจะดึงความสนใจได้มากกว่า
    เมื่อมีคนเข้าไปที่ https://github.com/future-file-format/f3 ก็ควรเห็นได้ทันทีว่าทำไมถึงควรลองใช้
    เอาข้อดีและตัวชี้วัดขึ้นมาแสดงเถอะ จะเลือกเฉพาะตัวชี้วัดที่เข้าข้างตัวเองก็ได้
    อาจมีกรณีใช้งานที่ดีอยู่จริง แต่จาก README ตอนนี้ยังไม่ชัดว่าใครควรใช้และเพราะอะไร

  • ถ้าจะเก็บข้อมูลระดับ PB ไว้นานเกิน 10 ปี ผมคงไม่อยากพึ่งว่าภายภาคหน้าจะยังมี Wasm interpreter อยู่และเร็วพอสำหรับการอ่านไฟล์
    ผมอยากได้ข้อกำหนดระดับไบต์ที่เรียบง่ายและมีเอกสารชัดเจนแบบ Parquet
    ยิ่งไปกว่านั้น การใส่ลอจิกถอดรหัสไว้ในไบนารี Wasm ก็คือการเพิ่มชั้นการประมวลผลแบบ active เข้าไปในสิ่งที่ควรเป็น cold storage

    • ฟอร์แมต WinRAR ก็ฝัง RAR VM bytecode เป็นส่วนหนึ่งของ archive เพื่อให้ได้การบีบอัดล่าสุดกับไฟล์มีเดีย
      มันถูก sandbox และได้รับการยอมรับอย่างกว้างขวาง และ Wasm ก็มีความสามารถด้าน sandbox แบบเดียวกัน
      สำหรับการเก็บระยะยาวอาจยิ่งดีกว่าด้วยซ้ำ
      เพราะไม่ต้องพกโปรแกรมแตกไฟล์แยกต่างหาก เนื่องจากมันอยู่ในไฟล์ archive เอง
    • หมายถึงคุณไม่อยากรันฟังก์ชัน parse ข้อมูลแบบปรับแต่งเองที่มีอายุ 10 ปีทุกครั้งที่อ่านเรคอร์ดข้อมูลเดี่ยว ๆ ใช่ไหม?

  • ถ้าการถอดรหัสล้มเหลว ก็จะต้องไปดีบัก Wasm ที่คนอื่นใส่เข้ามา และก็น่ากังวลว่ามันอาจมีบั๊กแปลก ๆ ปะปนอยู่ด้วย
    ถ้ามีไลบรารีดีโคเดอร์มาตรฐานที่โปรเจ็กต์เป็นผู้ดูแลและทดสอบก็น่าจะช่วยได้ แต่ก็ไม่แน่ใจว่านั่นจะไปทำลายข้อดีด้าน ความยืดหยุ่น ที่แนวทางนี้มอบให้หรือไม่

    • Wasm เป็นการทำงานแบบ deterministic execution ดังนั้นถ้าการถอดรหัสฝั่งผมล้มเหลว ฝั่งที่สร้างมันขึ้นมาก็ควรจะล้มเหลวเหมือนกัน
      กล่าวคือมันไม่ใช่ปัญหาใหม่ที่เกิดจากระบบของผมเอง และพวกเขาควรจะสามารถทำให้เกิดซ้ำได้โดยไม่ขึ้นกับไคลเอนต์ตัวไหนก็ตาม