ระบบจัดการเวอร์ชันข้อมูล

 (dvc.org)
2 คะแนน โดย GN⁺ 2024-10-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Data Version Control คือชุดเครื่องมือที่ใช้โมเดลคล้าย Git เพื่อจัดการข้อมูลเหมือนกับโค้ด ช่วยให้ทีมข้อมูล, AI/ML และวิทยาศาสตร์ข้อมูลนำแนวปฏิบัติด้านวิศวกรรมซอฟต์แวร์มาใช้ได้
  • สำหรับโครงสร้างพื้นฐาน AI/ML และข้อมูลขนาดใหญ่ มี lakeFS รองรับ โดยมุ่งจัดการที่เก็บอ็อบเจ็กต์มัลติโมดัลและ data lake ระดับเพตะไบต์ในสภาพแวดล้อมงานปฏิบัติการ AI ที่ซับซ้อนและบิ๊กดาต้า
  • สำหรับโปรเจกต์วิทยาศาสตร์ข้อมูลขนาดเล็ก มี DVC Git extension ที่ออกแบบมาให้เหมาะกับนักวิทยาศาสตร์ข้อมูลรายบุคคล สามารถใส่การจัดการเวอร์ชันข้อมูลเข้าไปในเวิร์กโฟลว์ได้โดยมี overhead ต่ำ
  • DVC ให้ใช้งานฟรีแบบโอเพนซอร์ส และมีส่วนขยาย DVC for VS Code โดย repository บน GitHub แสดงจำนวนดาว 15,713 ดวง
  • เมื่อคอมมูนิตี้ DVC เข้าร่วมกับ lakeFS family จึงสามารถดูการแบ่งบทบาทระหว่าง lakeFS กับ DVC และ FAQ ที่เกี่ยวข้องแยกต่างหากได้

บทบาทของ Data Version Control

  • Data Version Control ตั้งเป้าหมายว่า “จัดการข้อมูลด้วยวิธีเดียวกับที่จัดการโค้ด”
  • เป็นโครงสร้างที่ช่วยให้ทีมข้อมูล, AI/ML และวิทยาศาสตร์ข้อมูลใช้ แนวปฏิบัติที่ดีที่สุดด้านวิศวกรรมซอฟต์แวร์ ผ่านโมเดลที่คล้ายกับ Git
  • กรณีใช้งานแบ่งออกเป็น 2 สายหลัก
    • ทีม AI/ML และโครงสร้างพื้นฐานข้อมูล
    • เวิร์กโฟลว์ในเครื่อง และโปรเจกต์วิทยาศาสตร์ข้อมูลขนาดเล็ก

กลุ่มเป้าหมายและเส้นทางเริ่มต้นของแต่ละผลิตภัณฑ์

  • lakeFS คือโครงสร้างพื้นฐานการจัดการเวอร์ชันข้อมูลสำหรับทีม AI ระดับองค์กรและทีมวิศวกรรมข้อมูล
    • มุ่งรองรับงานปฏิบัติการ AI ที่ซับซ้อนและสภาพแวดล้อมบิ๊กดาต้า
    • จัดการ ที่เก็บอ็อบเจ็กต์มัลติโมดัล และ data lake ระดับเพตะไบต์
    • มีลิงก์เริ่มต้นเป็น Get started with lakeFS และ Book a Demo
  • DVC คือ Git extension สำหรับนักวิทยาศาสตร์ข้อมูลรายบุคคล
    • มุ่งให้เป็น การจัดการเวอร์ชันข้อมูลที่ใช้ง่าย สำหรับโปรเจกต์วิทยาศาสตร์ข้อมูลขนาดเล็ก
    • สามารถนำไปใช้กับเวิร์กโฟลว์วิทยาศาสตร์ข้อมูลได้โดยมี overhead ต่ำที่สุด
    • ลิงก์เริ่มต้นคือ Get started with DVC
  • สามารถใช้งานใน VS Code ได้ผ่านส่วนขยาย DVC for VS Code
  • คอมมูนิตี้ DVC ได้เข้าร่วมกับ lakeFS family โดยมีข้อมูลที่เกี่ยวข้องเชื่อมไปยัง lakeFS and DVC และ FAQs
  • repository GitHub ของ DVC คือ treeverse/dvc และในหน้าดังกล่าวแสดงดาว 15,713 ดวง

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

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

 
GN⁺ 2024-10-21
ความคิดเห็นจาก Hacker News

  • ตลอด 5 ปีที่ผ่านมา ผมใช้ DVC ในโปรเจกต์ส่วนใหญ่ ข้อดีคือมันทำงานเหมือน Git
    ถ้านักวิทยาศาสตร์เข้าใจ branch, commit, diff ก็จะเข้าใจ DVC ได้เช่นกัน ส่วนข้อเสียก็คือมันทำงานเหมือน Git นั่นแหละ เพราะในความเป็นจริง นักวิทยาศาสตร์จำนวนมากไม่ได้เข้าใจหรือใช้งาน branch, commit, diff ได้ดีนัก สิ่งที่ดีที่สุดคือมันแทบจะบังคับให้ทำตาม Ten Simple Rules for Reproducible Computational Research ในทีมที่ผมเคยทำงานด้วย ความสามารถในการทำซ้ำ เป็นโจทย์ใหญ่

    • ผมก็รู้สึกคล้ายกัน และ แรงต้านต่อการเรียน Git ค่อนข้างมาก ซึ่งก็พอเข้าใจได้ในระดับหนึ่ง
      นักวิจัยรู้ว่า Git คืออะไรและรู้ว่ามีคุณค่า แต่คิดว่าการเรียนรู้ใช้เวลานานเกินไป และอยากเดินหน้าให้เร็ว ผมจึงเริ่มทำเครื่องมือชื่อ Calkit(https://github.com/calkit/calkit) เพื่อทำให้ Git และ DVC ง่ายขึ้นและรวมเข้าด้วยกันสำหรับนักวิจัยกลุ่มนี้ ผมอยากโน้มน้าวว่าการทำงานแบบทำซ้ำได้ในระยะยาวนั้นเร็วกว่า และท้ายที่สุดทำให้งานถูกนำไปใช้โดยตรงเพื่อเร่งความก้าวหน้าของทั้งสาขาได้มากขึ้น

  • ผมเป็นผู้ดูแลและผู้เขียน DVC ดีใจที่เห็น DVC ขึ้นมาหน้าแรก
    ผมตอบคำถามเกี่ยวกับ DVC และโปรเจกต์พี่น้องอย่าง DataChain https://github.com/iterative/datachain ได้ DataChain เป็นเครื่องมือจัดการเวอร์ชันข้อมูลที่ตั้งสมมติฐานต่างออกไปเล็กน้อย มีการแปลงข้อมูลในตัว และไม่ต้องคัดลอกไฟล์

    • ถ้าไฟล์ข้อมูลทั้งหมดเป็นไฟล์ข้อความ อยากรู้ว่าความต่างระหว่าง DVC กับ Git ล้วน ๆ คืออะไร
    • ผมทำคอนซัลต์ในฐานะ data engineer เป็นหลัก ไม่ใช่ผู้เชี่ยวชาญ MLOps แต่สนใจเรื่องนี้
      เรามี ไฟล์ Parquet ย้อนหลัง 10 ปีจาก Kafka topic กว่า 300 รายการ และกำลังย้ายไป Apache Iceberg ตอนนี้ จะ backfill เฉพาะเมื่อจำเป็น และถ้าติดตามกระบวนการนั้นด้วย Git ได้ก็น่าจะดี อยากรู้ว่าเหมาะกับกรณีใช้งานแบบนี้ไหม ความเป็นไปได้อีกอย่างคือการติดตามการเปลี่ยนแปลง schema ด้วยวิธีที่ดีกว่าปัจจุบัน ผมอยู่ในสายนี้มากว่า 20 ปีแล้ว และมองว่าแนวทาง anything-as-code เข้ากับข้อมูลได้ดี

  • ดีใจที่เห็น DVC ถูกพูดถึงที่นี่
    ในฐานะเครื่องมือ มันทำให้การจัดการเวอร์ชันของข้อมูลและโมเดลง่ายขึ้นมาก และเป็นจุดเปลี่ยนครั้งใหญ่สำหรับคนจำนวนมากในสาย MLOps โดยเฉพาะวิธีที่ฉลาดในการเชื่อมไฟล์ขนาดใหญ่เข้ากับ Git repository โดยตรงและเก็บไว้ใน object storage ใด ๆ โดยไม่ต้องมี application server แยกแบบ git-lfs หรือเขียน Git ใหม่ ที่ DagsHub https://dagshub.com เราผสานรวมกับ DVC โดยตรงมานานแล้ว ทำให้ทีมสามารถทำ visualization และ labeling ของ dataset, จัดการโมเดล, รันการทดลองร่วมกัน และติดตาม code·data·model ได้ในที่เดียว ถ้าใช้งาน DVC อยู่แล้วหรือกำลังพิจารณา ก็มีตัวเลือกที่จะใช้มันเป็นส่วนประกอบของ toolchain ที่ใกล้เคียง end-to-end มากขึ้น

  • อยากรู้ว่าเมื่อเทียบกับ Oxen แล้วเป็นอย่างไร
    https://github.com/Oxen-AI/Oxen

    • ผมเป็นผู้ดูแล Oxen เหตุผลที่เริ่มทำ Oxen ตอนแรกคือ DVC ค่อนข้างช้าและมีฟีเจอร์ที่ไม่จำเป็นมาก
      ภายในเรา optimize โครงสร้าง Merkle tree, อัลกอริทึม hash, โปรโตคอลเครือข่าย ฯลฯ เพื่อให้เร็วแม้กับ dataset ขนาดใหญ่ ที่ https://oxen.ai ยังมี frontend ที่ค่อนข้างดีสำหรับดูและ query ข้อมูลด้วย
    • ถ้าใช้สิ่งนี้ร่วมกับ GitHub ได้ ผมน่าจะย้ายจาก DVC ทันที
    • เพิ่งเคยได้ยิน Oxen แต่ดูเป็นทางเลือกที่น่าสนใจมาก และอยากฟังจากคนที่เคยใช้ทั้งสองตัว
      จากความประทับใจแรก DVC ถูกทำมาให้ใช้ร่วมกับ Git โดยให้ DVC จัดการโฟลเดอร์ใด ๆ ภายใน Git repository ส่วน Oxen ดูใกล้เคียงกับทางเลือกที่เป็น data repository แยกต่างหากมากกว่า อีกอย่าง Oxen มีการผสานรวมกับ dataframe, ข้อมูลแบบตาราง, ข้อมูลสำหรับการฝึกและ inference ของ AI มาก จึงดูเหมือนเติมส่วนที่ DVC ไม่มี ในทางกลับกัน DVC มี DAG pipeline engine แบบครบถ้วน, การนำเข้า·ส่งออก และ backend ที่สลับเปลี่ยนได้รวมอยู่ด้วย

  • ยังไม่ค่อยเห็นภาพว่าสิ่งนี้ปฏิสัมพันธ์กับข้อมูลอย่างไร
    ถ้าเก็บ Delta table ไว้บน ADLS และไม่สามารถดึงข้อมูล production มาที่เครื่อง local ได้ ก็ยังใช้ได้ไหม อยากรู้ด้วยว่าถ้าการย้อนกลับไปเวอร์ชันเก่าแค่ดู Delta log ก็พอแล้ว ยังมีเหตุผลอะไรให้ใช้ DVC หรือไม่

    • ตามวิธีที่ผมใช้ DVC ใกล้เคียงกับ git LFS ที่รองรับ backend หลายแบบ และอาจมองว่าเป็น git-annex ที่ง่ายกว่าได้
      นอกจากนี้ยังมีฟีเจอร์เฉพาะทางด้าน MLOps เพิ่มเข้ามา ใช้สะดวกเมื่อจัดการเวอร์ชันการเทรนโมเดลที่ข้อมูลบน S3 เปลี่ยนไป

  • เราก็เคยพิจารณา DVC แต่สำหรับ use case บางอย่าง Git paradigm ไม่ได้มีประโยชน์มากนัก
    เป็น ไฟล์วิดีโอขนาดใหญ่มาก ที่แทบไม่เปลี่ยนแปลง และต้องมีสำเนาข้อมูลหนึ่งชุดที่ฝั่งต้นทาง กับอีกชุดในแต่ละระบบที่ใช้เทรน สุดท้ายเราไปใช้ไฟล์และโฟลเดอร์บน NAS ซึ่งก็ทำงานได้ดีพอ แนวทาง hybrid ที่จัดการเฉพาะ metadata ของ dataset ด้วย DVC แล้วทำ versioning ตรงนั้นดูเป็นไปได้ แต่เรื่องนี้เกิดขึ้นเมื่อหลายปีก่อน และสงสัยว่าตอนนี้มีโซลูชันจัดการเวอร์ชันข้อมูลแบบ on-premises เพิ่มขึ้นหรือยัง ตอนที่ค้นหาล่าสุด ส่วนใหญ่ดูเหมือนจะเน้น cloud

  • สงสัยว่า DVC มีข้อดีอะไรเมื่อเทียบกับ Apache Iceberg
    ถ้ามีใครเคยใช้ทั้งสองอย่าง อยากฟังความเห็น

    • ถ้าสงสัยเรื่องนี้ ก็ควรดู Icechunk ที่เพิ่งเปิดเป็นโอเพนซอร์สในสัปดาห์นี้ด้วย
      คล้ายกับ Apache Iceberg แต่เป็นเครื่องมือสำหรับข้อมูลหลายมิติอย่าง Zarr ดู https://earthmover.io/blog/icechunk และ https://news.ycombinator.com/item?id=41850352
    • ยังไม่เห็นข้อดีที่ชัดเจนเท่าไร และรู้สึกเหมือนเอาเครื่องมือที่คุ้นเคยอยู่แล้วไปใช้ในที่ที่ไม่ค่อยเหมาะ
      Iceberg อาจถูกปรับมาให้เหมาะกับโมเดลที่เปลี่ยนแปลงช้ากว่าวิธีนี้มากกว่า
    • ยังเรียบเรียงความคิดได้ไม่ค่อยดีนัก แต่ถ้าลองอธิบาย ตัวอย่างที่ดีของ ข้อมูลแบบ blob ที่พูดถึงตรงนี้คือชุดไฟล์วิดีโอ 1080p ที่ยาวมาก
      สรุปคือ ข้อมูล blob แบบไม่มีโครงสร้างควรใส่ใน DVC ส่วนข้อมูลที่มีโครงสร้างควรใส่ใน Iceberg ข้อที่ DVC ดีกว่า Iceberg คือไม่ต้องฝืนยัดข้อมูล blob เข้าไปในรูปแบบตาราง และหลีกเลี่ยงขั้นตอนประมวลผลจุกจิกที่ตามมากับกระบวนการนั้นได้ จริง ๆ แล้วแทบไม่ต้องรันขั้นตอนประมวลผลเพื่อดึงข้อมูล blob ออกจากไฟล์ Parquet ด้วยซ้ำ แค่ใช้คำสั่งอย่าง dvc pull เพื่อดาวน์โหลดแต่ละไฟล์ลงมาตามสภาพเดิมก็พอ แก้ไฟล์ในเครื่องแล้วก็ commit ได้ด้วยคำสั่งประมาณสามคำสั่ง และไม่ต้องมี pipeline สำหรับ ingest ข้อมูลที่คอยฝืนยัด blob เข้าไปในตารางด้วย ไม่มี schema เลยโดยสมบูรณ์ จึงไม่ต้องกังวลเรื่อง type แค่ใส่ลงใน repository แล้ว commit ก็พอ สามารถ rollback ตามประวัติ commit ทั้งหมดได้ ไม่ใช่แค่ถึง vacuum/checkpoint ล่าสุด การยัดข้อมูล blob เข้าไปในฟอร์แมตข้อมูลแบบตารางแทบจะเป็นสูตรสำเร็จของความเจ็บปวด และการใส่ blob ไว้ใน repository แบบ Git นั้นเร็วและง่ายกว่ามาก โดยเฉพาะถ้าต้องการประวัติ version ทั้งหมดหรือ branch สำหรับผลลัพธ์ที่ต่างกัน เช่น การนำไฟล์วิดีโอ 1080p ยาว ๆ ไปใช้ฟิลเตอร์ ffmpeg ต่างกันในแต่ละ branch แล้วทำให้คนเข้าถึงผลลัพธ์และประวัติทั้งหมดได้ ถ้าทำใน Iceberg คงเป็นฝันร้าย แต่ใน DVC ทำได้ง่าย สุดท้ายทุกอย่างถูกจัดการด้วย version control จึงให้ความรู้สึกเหมือนสร้าง data lake ที่ไม่กลายเป็นหนองข้อมูล

  • ตอนใช้กับ dataset ที่ประกอบด้วยไฟล์ jpg จำนวนมาก เจอปัญหาเยอะมาก
    ทุกครั้งที่รัน dvc status งาน ทำดัชนี ที่ตรวจไฟล์ทั้งหมดใช้เวลาหลายนาที และ caching ก็ไม่ทำงาน น่าเสียดายที่ต้องเลิกใช้

    • ใช่ ประสิทธิภาพค่อนข้างแย่ และอาจมีเรื่องปวดหัวจาก caching ได้มาก
      โดยเฉพาะถ้าใช้ file system ที่ไม่รองรับ reflink ยิ่งเป็นอย่างนั้น สำหรับ dataset แบบ sharding ขนาดใหญ่อย่าง WebDataset โซลูชันอื่นน่าจะดีกว่า โดยเฉพาะถ้า pipeline สำหรับ machine learning สามารถสตรีมจาก object storage ได้โดยตรง

  • เคยได้ยินชื่อ lakeFS ในฐานะเครื่องมือจัดการ version ของข้อมูลบน S3 object storage ด้วย
    สงสัยว่า DVC จะเป็นคู่แข่งในพื้นที่นี้ได้หรือไม่