- 3FS คือระบบไฟล์แบบกระจายโอเพนซอร์สประสิทธิภาพสูงที่พัฒนาโดย DeepSeek รองรับการประมวลผลข้อมูลขนาดใหญ่และปริมาณงานสูง
- แม้จะทำงานเหมือนระบบไฟล์ทั่วไป แต่เบื้องหลังคือการกระจายจัดเก็บข้อมูลไว้บนหลายเครื่อง โดยมีชั้น abstraction ที่ทำให้ผู้ใช้ไม่จำเป็นต้องรับรู้รายละเอียดเหล่านั้น
- ใช้งานผ่าน องค์ประกอบหลัก 4 ส่วน (Meta, Mgmtd, Storage, Client) โดยแยกหน้าที่ด้านเมทาดาทา การจัดการโหนด การเก็บข้อมูลจริง และการประมวลผลคำขอของผู้ใช้ออกจากกัน
- บรรลุทั้งความสอดคล้องแบบเข้มงวดและการทนต่อความขัดข้องด้วยอัลกอริทึม CRAQ พร้อมส่งต่อคำขอเขียนอย่างปลอดภัยผ่านโครงสร้างแบบเชน
- 3FS แตกต่างจากระบบไฟล์แบบกระจายอื่น ๆ ในด้าน ความพร้อมใช้งานจริง และ การขยายประสิทธิภาพ
3FS คืออะไร?
- 3FS ย่อมาจาก Fire-Flyer File System เป็น ระบบไฟล์แบบกระจาย ที่ DeepSeek เปิดเผยสู่สาธารณะ
- เปิดตัวพร้อมกับสัปดาห์เผยแพร่โอเพนซอร์สของ DeepSeek
- ภายนอกดูเหมือนพาธไฟล์ทั่วไป แต่จริง ๆ แล้วเป็น abstraction ที่นำเสนอข้อมูลซึ่งถูกกระจายเก็บอยู่บนหลายเครื่อง
ระบบไฟล์แบบกระจายคืออะไร?
- สำหรับผู้ใช้ มัน ดูเหมือนระบบไฟล์ภายในเครื่อง แต่เบื้องหลังจะกระจายเก็บข้อมูลไว้บนหลายเซิร์ฟเวอร์
- ตัวอย่าง: พาธ
/3fs/stage/notes.txt ดูเหมือนเป็นไฟล์เดียว แต่จริง ๆ แล้วถูกแบ่งเก็บอยู่บนหลายเซิร์ฟเวอร์
- ผู้ใช้สามารถใช้คำสั่งอย่าง
mkdir, cat ได้เหมือนเป็นไฟล์ปกติ
ทำไมจึงใช้ระบบไฟล์แบบกระจาย?
- รองรับ ข้อมูลขนาดใหญ่ (ระดับเพตะไบต์) และ throughput สูง
- รับประกันความเสถียรด้วย การทนต่อความขัดข้อง (fault tolerance) และ ความซ้ำซ้อน (redundancy)
- ตัวอย่างการใช้งานจริง:
- เฟรมเวิร์กประมวลผลแบบขนานอย่าง HDFS + Spark
- การทำ checkpoint ใน ML training pipeline
- Colossus ของ Google
- Haystack ระบบจัดเก็บรูปภาพของ Meta
- ตัวอย่างสตอเรจสำหรับ AI: JuiceFS vs CephFS
องค์ประกอบของ 3FS
- ประกอบด้วยโหนดหลักทั้งหมด 4 ประเภท
Meta
- จัดการ เมทาดาทา เช่น พาธไฟล์ คุณสมบัติ และตำแหน่ง
- ประมวลผลคำขอจากไคลเอนต์ผ่าน RPC (open, stat, close เป็นต้น)
- ข้อมูลเมทาจะถูกเก็บไว้ใน FoundationDB
Inode เก็บข้อมูลอย่างขนาดไฟล์ เจ้าของไฟล์ เป็นต้นDirEntry ใช้เชื่อมพาธกับ inode (จึงอาจมีหลายพาธที่ชี้ไปยังไฟล์เดียวกันได้ คล้าย symbolic link)
Mgmtd
- รับผิดชอบ การลงทะเบียนโหนดและตรวจสอบสถานะ ของคลัสเตอร์
- เมื่อบูต โหนดจะลงทะเบียนตัวเองและส่ง heartbeat เป็นระยะ
- ทำหน้าที่เป็น เราเตอร์ศูนย์กลาง ทำให้ไม่จำเป็นต้องรักษาการเชื่อมต่อระหว่างโหนดโดยตรง
- จัดการข้อมูลตั้งค่าที่ใช้สร้างเชน CRAQ ด้วย
Storage
- รับผิดชอบการเก็บข้อมูลจริง
- จัดการบล็อกดิสก์ผ่าน ChunkEngine ที่พัฒนาด้วย Rust
- ติดตามขนาดบล็อกดิสก์ ออฟเซ็ต checksum เวอร์ชัน เป็นต้น
- ผู้ใช้ไม่ได้โต้ตอบกับบล็อกโดยตรง แต่เข้าถึงผ่านอินเทอร์เฟซที่จัดเตรียมไว้
- เมทาดาทาถูกเก็บไว้ใน LevelDB
- มี worker หลายประเภท
AllocateWorker จัดสรรบล็อกใหม่PunchHoleWorker เรียกคืนบล็อกที่ไม่ได้ใช้งานAioReadWorker จัดการการอ่านแบบ asynchronous ผ่านคิว io_uring
- ระหว่างการเขียนข้อมูล จะ ส่งต่อไปยังโหนดถัดไป ตามเชน CRAQ
Client
- ประมวลผลคำขอของผู้ใช้และสื่อสารกับโหนดอื่น ๆ
- ลำดับการทำงาน:
- สอบถามตำแหน่งโหนดจาก Mgmtd
- ส่งคำขอเกี่ยวกับไฟล์ไปยัง Meta
- รับส่งข้อมูลกับ Storage
อัลกอริทึม CRAQ
- ย่อมาจาก Chain Replication with Apportioned Queries และให้ ความสอดคล้องแบบเข้มงวด (linearizability)
- ลำดับการเขียน:
- กระจายการเขียนจาก Head → Middle → Tail
- ในขั้นกลางจะทำเครื่องหมายข้อมูลเป็น dirty (ยังอ่านไม่ได้)
- เมื่อ commit ที่ Tail แล้ว จะกระจายสถานะ clean ย้อนกลับไปด้านหลัง
- ลำดับการอ่าน:
- ถ้าเป็น clean จะส่งคืนได้ทันที
- ถ้าเป็น dirty จะส่งคำขอไปยัง tail เพื่อดึงข้อมูลล่าสุด
CRAQ ในมุมของประสิทธิภาพ
- ความเร็วในการเขียนถูกจำกัดโดยโหนดที่ช้าที่สุด
- หากมีการเข้าถึงข้อมูล dirty บ่อย คำขออ่านอาจไปรวมที่ tail ทำให้ เกิดคอขวดในการอ่าน
- ตัวอย่าง: ประสิทธิภาพอาจลดลงใน Zipfian workload
- ในคลัสเตอร์ที่มี 5 โหนด จะทำ replication 3 ชุดเพื่อลดการสูญเสียประสิทธิภาพเมื่อเกิดความขัดข้อง
ความแตกต่างจากระบบไฟล์แบบกระจายอื่น ๆ
- แม้โครงสร้างจะคล้ายกัน แต่ มีจุดต่างในด้านการนำไปใช้จริงและแนวทางการพัฒนา
- ปัจจัยที่ใช้เปรียบเทียบ:
- เด่นใน workload แบบใด
- ความยืดหยุ่นในการปรับประสิทธิภาพ
- ความง่ายในการ deploy
- ความสามารถในการขยาย throughput
- การควบคุม latency ให้อยู่ใน SLO
- ความน่าเชื่อถือ
- รายละเอียดทางเทคนิค:
- สาเหตุของคอขวดและวิธีจัดการ
- มีการใช้ lock หรือไม่
- โครงสร้างข้อมูลที่ใช้
- ฮาร์ดแวร์เป้าหมาย
- อัลกอริทึมทนต่อความขัดข้อง หรือ วิธีการแก้ไขข้อผิดพลาด ที่ใช้
หัวข้อถัดไปของซีรีส์บล็อก
- มีแผนจะตรวจสอบคำกล่าวอ้างของ DeepSeek ผ่านการวิเคราะห์ประสิทธิภาพจริง
- ประเด็นที่จะทบทวน:
- คำกล่าวอ้างของ DeepSeek เกี่ยวกับ คอขวดของ FUSE
- ความเป็นไปได้ในการทำซ้ำกราฟประสิทธิภาพ
- การวิเคราะห์สถานการณ์ที่ประสิทธิภาพลดลง
- ปัจจัยคอขวด (CPU, หน่วยความจำ, ดิสก์, เครือข่าย)
- workload แบบใดที่ให้ประสิทธิภาพโดดเด่น
- การวิเคราะห์เปรียบเทียบกับระบบเดิม
- ความแตกต่างจากวิธีแก้ปัญหาของระบบเดิม
- การพิจารณาความเป็นไปได้ในการปรับปรุงโดยตรง
แหล่งข้อมูลเพิ่มเติม
2 ความคิดเห็น
ก็เป็นปัญหาที่กำลังกังวลและคิดอยู่เหมือนกัน แต่นี่มัน..
ความคิดเห็นจาก Hacker News
S3FS เป็นระบบไฟล์เมทาดาทาที่ขยายขนาดได้ และถูกนำไปเปรียบเทียบกับระบบไฟล์แบบกระจายหลายตัว
เมื่อต้องประเมินระบบเหล่านี้ ควรพิจารณาทั้งข้อจำกัดเชิงทฤษฎี ประสิทธิภาพ และข้อจำกัดในทางปฏิบัติ
สนใจการเปรียบเทียบกับ SeaweedFS
มีคำถามว่าทำไมไม่ใช้ CephFS
มีคำถามเกี่ยวกับการเปรียบเทียบกับ JuiceFS
ในฐานะผู้ประกอบการรายเล็กและผู้ใช้ homelab คงไม่มีโอกาสต้องใช้ระบบไฟล์แบบกระจายขนาดใหญ่มาก
การตั้งค่าดูซับซ้อน แต่ยังไม่ชัดเจนว่าฟีเจอร์ใดจำเป็นต่อเวิร์กโหลด deep learning
มีคำถามว่าการปิดใช้งานระบบไฟล์แบบกระจายของ DeepSeek ทำได้ง่ายแค่ไหน
มีคำถามว่าสามารถจำลองสิ่งนี้ด้วยไดรฟ์ ZFS ที่กระจายอยู่บนหลายอุปกรณ์ได้หรือไม่