- 3FS là một hệ thống tệp phân tán mã nguồn mở hiệu năng cao do DeepSeek phát triển, hỗ trợ xử lý dữ liệu quy mô lớn và thông lượng cao
- Nó hoạt động giống như một hệ thống tệp thông thường, nhưng thực tế dữ liệu được lưu phân tán trên nhiều máy, còn người dùng không cần phải nhận biết lớp trừu tượng này
- 4 thành phần chính (Meta, Mgmtd, Storage, Client) giúp tách biệt việc quản lý metadata, quản lý nút, lưu trữ dữ liệu thực tế và xử lý yêu cầu người dùng
- Đạt được tính nhất quán mạnh và khả năng chịu lỗi thông qua thuật toán CRAQ, đồng thời truyền bá yêu cầu ghi một cách an toàn theo cấu trúc chuỗi
- 3FS khác biệt với các hệ thống tệp phân tán khác ở khả năng ứng dụng thực tế và khả năng mở rộng hiệu năng
3FS là gì?
- 3FS là viết tắt của Fire-Flyer File System, một hệ thống tệp phân tán được DeepSeek công bố
- Được phát hành cùng với tuần công bố mã nguồn mở của DeepSeek
- Trông như một đường dẫn tệp thông thường, nhưng thực tế cung cấp một lớp trừu tượng cho dữ liệu được lưu phân tán trên nhiều máy
Hệ thống tệp phân tán là gì?
- Với người dùng, nó trông giống như hệ thống tệp cục bộ, nhưng thực tế dữ liệu được lưu phân tán trên nhiều máy chủ
- Ví dụ: đường dẫn
/3fs/stage/notes.txt trông như một tệp duy nhất, nhưng thực tế được chia ra lưu trên nhiều máy chủ
- Người dùng có thể dùng các lệnh như
mkdir, cat như với tệp thông thường
Vì sao dùng hệ thống tệp phân tán?
- Hỗ trợ dữ liệu dung lượng lớn (mức petabyte) và thông lượng cao
- Đảm bảo độ ổn định thông qua khả năng chịu lỗi (fault tolerance) và dự phòng (redundancy)
- Ví dụ sử dụng thực tế:
- Các framework xử lý song song như HDFS + Spark
- Checkpointing trong pipeline huấn luyện ML
- Colossus của Google
- Haystack, kho lưu trữ ảnh của Meta
- Ví dụ lưu trữ cho AI: JuiceFS vs CephFS
Các thành phần của 3FS
- Gồm tổng cộng 4 loại nút chính
Meta
- Quản lý metadata như đường dẫn tệp, thuộc tính, vị trí
- Xử lý yêu cầu từ client qua RPC (
open, stat, close v.v.)
- Thông tin meta được lưu trong FoundationDB
Inode lưu thông tin như kích thước tệp, chủ sở hữuDirEntry liên kết đường dẫn với inode (một tệp có thể tồn tại ở nhiều đường dẫn, giống như symbolic link)
Mgmtd
- Phụ trách đăng ký nút và kiểm tra trạng thái của cluster
- Khi khởi động, các nút tự đăng ký và định kỳ gửi heartbeat
- Đóng vai trò router trung tâm, nên không cần duy trì kết nối trực tiếp giữa mọi nút
- Cũng quản lý thông tin cấu hình cho chuỗi CRAQ
Storage
- Phụ trách lưu trữ dữ liệu thực tế
- Quản lý các block trên đĩa thông qua ChunkEngine viết bằng Rust
- Theo dõi kích thước, offset, checksum, phiên bản của block đĩa
- Cung cấp giao diện để người dùng không phải tương tác trực tiếp với block
- Metadata được lưu trong LevelDB
- Có nhiều worker khác nhau
AllocateWorker cấp phát block mớiPunchHoleWorker thu hồi các block không còn dùngAioReadWorker xử lý đọc bất đồng bộ thông qua hàng đợi io_uring
- Khi ghi, dữ liệu được chuyển tiếp sang nút tiếp theo theo chuỗi CRAQ
Client
- Xử lý yêu cầu của người dùng và giao tiếp với các nút khác
- Luồng xử lý:
- Truy vấn vị trí nút từ Mgmtd
- Gửi yêu cầu thao tác tệp tới Meta
- Truyền dữ liệu với Storage
Thuật toán CRAQ
- Viết tắt của Chain Replication with Apportioned Queries, cung cấp tính nhất quán mạnh (linearizability)
- Luồng ghi:
- Ghi được lan truyền theo thứ tự Head → Middle → Tail
- Ở các bước trung gian, dữ liệu được đánh dấu là dirty (không thể đọc)
- Sau khi commit ở Tail, trạng thái clean được lan truyền ngược lại
- Luồng đọc:
- Nếu clean thì trả về ngay
- Nếu dirty thì gửi yêu cầu đến tail để lấy dữ liệu mới nhất
CRAQ dưới góc độ hiệu năng
- Tốc độ ghi bị giới hạn bởi nút chậm nhất
- Dữ liệu dirty được truy cập thường xuyên có thể khiến yêu cầu đọc dồn về tail, gây nghẽn đọc
- Ví dụ: hiệu năng suy giảm với Zipfian workload
- Trong cluster 5 nút, dữ liệu được sao chép thành 3 bản để giảm thiểu mất hiệu năng khi xảy ra sự cố
Khác biệt so với các hệ thống tệp phân tán khác
- Kiến trúc tương tự, nhưng có điểm khác biệt ở khả năng áp dụng thực tế và cách triển khai
- Các yếu tố so sánh:
- Mạnh ở loại workload nào
- Độ linh hoạt trong điều chỉnh hiệu năng
- Mức độ dễ triển khai
- Khả năng mở rộng thông lượng
- Quản lý độ trễ trong phạm vi SLO
- Độ tin cậy
- Các chi tiết kỹ thuật:
- Nguyên nhân gây nghẽn và cách xử lý
- Có dùng lock hay không
- Cấu trúc dữ liệu được sử dụng
- Phần cứng mục tiêu
- Thuật toán chịu lỗi hoặc cơ chế sửa lỗi được sử dụng
Chủ đề tiếp theo của loạt blog
- Dự kiến kiểm chứng các tuyên bố của DeepSeek thông qua phân tích hiệu năng thực tế
- Các hạng mục xem xét:
- Tuyên bố của DeepSeek về nút thắt cổ chai FUSE
- Khả năng tái lập các biểu đồ hiệu năng
- Phân tích các tình huống suy giảm hiệu năng
- Các yếu tố gây nghẽn (CPU, bộ nhớ, đĩa, mạng)
- Workload nào cho hiệu năng tốt
- So sánh với các hệ thống hiện có
- Khác biệt với cách các hệ thống hiện có giải quyết vấn đề
- Xem xét khả năng cải tiến trực tiếp
Tài liệu bổ sung
2 bình luận
Đây đúng là vấn đề mình đã từng băn khoăn, vậy mà cái này ..
Ý kiến Hacker News
S3FS là một hệ thống tệp metadata có khả năng mở rộng, được so sánh với nhiều hệ thống tệp phân tán khác
Khi đánh giá các hệ thống này cần xem xét giới hạn lý thuyết, hiệu quả và giới hạn thực tế
Có người quan tâm đến việc so sánh với SeaweedFS
Có câu hỏi vì sao không dùng CephFS
Có câu hỏi về việc so sánh với JuiceFS
Với tư cách là nhà vận hành quy mô nhỏ và người dùng homelab, có lẽ sẽ không bao giờ cần dùng các hệ thống tệp phân tán quy mô lớn
Đây là một thiết lập phức tạp, nhưng chưa rõ những tính năng nào thực sự thiết yếu cho workload deep learning
Có câu hỏi mức độ dễ dàng khi vô hiệu hóa hệ thống tệp phân tán của DeepSeek
Có câu hỏi liệu có thể tái tạo điều này bằng các ổ ZFS phân tán trên nhiều thiết bị hay không