Building a Distributed Filesystem for Scalable Research

Hudson River Trading · 2025 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• HRT nạp lượng dữ liệu lớn; researcher dùng nó để phát triển và kiểm ý tưởng, ý tưởng tốt thành chiến lược giao dịch. Phần lớn hạ tầng on-premises, trước đây trộn Lustre, NFS filer và vài hệ mã nguồn mở tự vận hành.
• Giới hạn chạm phải (theo HRT): chi phí mua appliance cho hàng trăm petabyte; quy mô (HRT sẽ thành một trong những người dùng lớn nhất Ceph hay Lustre); khó scale (có hệ không scale nổi); multi-tenancy: chống noisy neighbor bằng cách giới hạn concurrency hoặc cấp hẳn hệ lưu trữ riêng, để lại dung lượng và băng thông bị bỏ không; kiểm soát: sửa lỗi nhanh thay vì chờ vòng debug của vendor.

Thay đổi chính

• Tự xây Blobby, dựa nhiều vào prior art (Tectonic của Meta; DeepSeek 3FS, Google Colossus cũng đi đường này). Đội nhỏ nên chỉ nhắm vài yêu cầu: thông lượng tổng hợp cao cho nhiều client cùng lúc (không phải hiệu năng một client); bền (chạy chaos test liên tục); đơn giản: append-only vì phần lớn workload ghi file lớn một lượt.
• Bố cục dữ liệu: file chia block, block chia chunk; mặc định erasure coding 6 data + 3 parity (mất 3 chunk bất kỳ vẫn không mất dữ liệu), chunk 8 MB vì mỗi lần đọc chunk là một lần đọc ngẫu nhiên trên HDD.
• Client là thư viện C++ nhúng vào ứng dụng; dữ liệu chỉ chảy giữa client và chunk server để scale tuyến tính.
• Đặt dữ liệu theo copyset thay vì chọn ngẫu nhiên, giảm xác suất mất dữ liệu khi nhiều đĩa hỏng cùng lúc; chunk của một block nằm ở rack khác nhau.
• Metadata trên FoundationDB: scale ngang, chịu lỗi, giao dịch ACID và strict serializability nên xoá file nhiều dòng là chuyện nhỏ, không cần "garbage collector" sửa metadata lệch như Tectonic.
• Proxy đứng giữa client và DB metadata: chống client lỗi làm hỏng metadata, làm access control, rate limit, cho phép thay DB sau này; chọn đĩa để ghi theo sức khoẻ cụm.
• Dịch vụ nền: shepherd kiểm sức khoẻ (một instance mỗi cụm, không nằm trên đường đọc/ghi), repair ưu tiên khôi phục block còn ít dư địa nhất, prober là client chuyên đọc/ghi trong môi trường kiểm soát để đo latency thật, vì một tiến trình nạp dữ liệu bị nghẽn sẽ làm nghẽn cả lần training phân tán.

Vì sao

• 2025: một cụm "soft-production", đang dựng thêm vài cụm. Cụm NVMe là hệ lưu trữ bền có thông lượng cao nhất ở HRT; cụm HDD cho chi phí/GB thấp nhất. Theo HRT, researcher không còn phải để ý quota.

Bài học cho SWE

• Ở quy mô hàng trăm PB, tự xây có thể rẻ hơn mua, nhưng chỉ khả thi khi bám prior art và cắt yêu cầu xuống tối thiểu (append-only).
• Cô lập bằng cách chia hệ riêng cho từng tenant để lại tài nguyên chết; một hệ lớn dùng chung cần cơ chế cô lập bên trong.
• Đặt một lớp proxy trước kho metadata để giữ quyền thay đổi về sau.
• Đo latency phía client bằng prober riêng, vì metric từ client thật bị nhiễu bởi host ồn.

Liên quan

• Jane Street 2026 (Jane Street tự làm Depot) · Hudson River Trading 2026 · Dropbox 2019
• Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) · Tách compute khỏi storage · Multi-tenancy và cô lập tenant · Chi phí hạ tầng và build vs buy