Inside the feature store powering real-time AI in Dropbox Dash

Dropbox · 2025 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bối cảnh

• Dropbox Dash (tìm kiếm và agent trên tài liệu, chat, nội dung công ty) xếp hạng tài liệu bằng ML theo thời gian thực. Một query kéo ranker chấm nhiều file, mỗi file cần hàng chục feature hành vi và ngữ cảnh, nên một lượt tìm thành hàng nghìn lượt tra feature, trong ngân sách latency dưới 100 ms.
• Hạ tầng chia hai thế giới: hệ on-premises cho gọi service–service latency thấp, và môi trường cloud chạy Spark nơi làm feature engineering. Theo Dropbox, điều này loại các feature store cloud-native chuẩn.
• Tín hiệu mới (mở một tài liệu, vào một kênh Slack) phải hiện trong lượt tìm kế tiếp, trong vài giây.

Thay đổi chính

• Chọn Feast sau khi xét Feast, Hopsworks, Featureform, Feathr, Databricks, Tecton: tách định nghĩa feature khỏi hạ tầng (engineer ML chỉ viết biến đổi PySpark), và có adapter DynamoDB, nhờ đó cắm được Dynovault, kho tương thích DynamoDB tự làm của Dropbox. Dynovault đặt cạnh workload inference trên hạ tầng hybrid cloud, không đi qua internet công cộng, latency phía client khoảng 20 ms.
• Viết lại đường phục vụ online bằng Go: bản đầu dùng SDK Python của Feast; profiling cho thấy parse JSON nặng CPU và GIL là nút thắt khi concurrency cao; chạy nhiều process đỡ tạm nhưng thêm chi phí điều phối. Bản Go (goroutine, bộ nhớ chung, parse JSON nhanh hơn) phục vụ hàng nghìn request/giây, chỉ thêm khoảng 5–10 ms trên latency của Dynovault, p95 khoảng 25–35 ms.
• Nạp theo ba đường:
  • Batch cho biến đổi lớn trên kiến trúc medallion, kèm phát hiện thay đổi để chỉ ghi bản ghi đã đổi: số bản ghi ghi mỗi lần chạy từ hàng trăm triệu xuống dưới một triệu, thời gian cập nhật từ hơn một giờ xuống dưới năm phút. Cơ sở: chỉ khoảng 1–5% giá trị feature đổi trong một cửa sổ 15 phút thông thường.
  • Streaming cho tín hiệu nhanh (hoạt động cộng tác, tương tác nội dung).
  • Ghi thẳng cho feature nhẹ hoặc tính sẵn, ví dụ điểm relevance từ một pipeline đánh giá bằng LLM, vào online store trong vài giây thay vì chờ chu kỳ batch.
• Quanh lõi có giám sát job hỏng, theo dõi độ tươi, lineage.

Vì sao

• Theo Dropbox, con đường giữa (nền mã nguồn mở + hạ tầng nội bộ, chỉnh từng lớp theo ràng buộc thật) hợp hơn tự viết hết hay dùng nguyên một sản phẩm vendor.

Bài học cho SWE

• Hiểu mẫu truy cập đáng giá ngang đổi hạ tầng: biết chỉ vài phần trăm dữ liệu đổi mỗi chu kỳ thì ghi phần thay đổi, không ghi lại toàn bộ.
• Fan-out trong một request (một query thành nghìn lượt tra) biến latency của từng lượt tra thành latency của cả request; đặt kho cạnh nơi inference chạy.
• Runtime có GIL không hợp cho tải trộn CPU và I/O ở concurrency cao; đo trước rồi mới viết lại.
• Mỗi loại feature một đường nạp phù hợp (batch, stream, ghi thẳng) thay vì ép mọi thứ qua một pipeline.

Liên quan

• Nền tảng ML (feature, training, serving, giám sát model) · Đổi ngôn ngữ và runtime
• Cùng công ty: Dropbox 2016 · Dropbox 2017
• Cùng bài toán: Lyft 2021 · Instacart 2023 (tần suất tính lại theo mức thay đổi)