3 Changes to Expand DoorDash's Product Search Beyond Delivery

DoorDash · 2022 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Search của DoorDash được xây cho đồ ăn: nhà hàng và menu lồng nhau, gắn chặt với hệ thống giao đồ ăn. Khi mở sang tạp hoá, tiện lợi, rượu, đồ thú cưng, dữ liệu thành từng SKU rời với số lượng lớn hơn hẳn, và mỗi ngành cần hiểu query/tài liệu riêng.

Thay đổi chính

• Hạ tầng search dựng lại từ đầu:
  • Indexing thế hệ mới: tạo materialized view của tài liệu search trước khi đưa vào index, nên rebuild nhanh hơn và tất định, tái lập được. Cập nhật ưu tiên cao (ảnh hưởng người dùng nhiều nếu cũ) đi đường index tăng dần để không bị kẹt sau lần rebuild (head-of-line blocking). Control plane tự động chuyển giữa index cũ và mới.
  • Federated search: search từng ngành độc lập rồi trộn (federate-then-blend). Thêm ngành mới không còn phải sửa lõi; mỗi ngành tự chỉnh relevance và có SLA latency riêng, một index lỗi thì suy giảm từng phần thay vì sập toàn bộ search. Tầng trộn lo tối ưu nhiều mục tiêu, chèn quảng cáo.
  • Rời Elasticsearch bản host: khó đặt tính toán gần dữ liệu (một round-trip giữa container khoảng 10 ms, search hai giai đoạn phải nhiều vòng), ít lựa chọn ranker vòng một (chỉ qua plugin), đắt khi tăng dung lượng dù đã tối ưu và mua cam kết. Thử nghiệm tự làm trên Lucene cho latency đầu-cuối giảm nhiều lần và chi phí tính toán nhỏ hơn một bậc (kết quả sớm, theo DoorDash), nhờ đẩy logic xuống gần storage và dùng early termination.
• Hiểu query/tài liệu: taxonomy cho đồ ăn, bán lẻ, ý định query; gán nhãn đi từ làm tay → quy trình chuẩn cho đội vận hành → model, có kiểm toán mẫu; thuê ngoài gán nhãn với nhiều người cho cùng một việc. Gán POS tag bằng transformer trong Python quá chậm khi online; các phương án: tính sẵn cho query đầu và giữa (Cassandra/Redis), model JVM đơn giản hơn, hoặc tối ưu sâu runtime Python.
• Learning-to-rank: từ BM25 + độ phổ biến sang GBDT dự đoán tỉ lệ chuyển đổi (cuối 2020), rồi thêm feature cá nhân hoá. Theo DoorDash, model đầu mất hơn sáu tháng từ lúc phát triển tới deploy vì phải dựng cả hệ thống quanh ML (build, deploy, đo).

Vì sao

• Search gắn chặt với một ngành không mở rộng được theo số ngành; tách thành nhiều nguồn độc lập cộng một tầng trộn biến việc thêm ngành thành cấu hình.

Bài học cho SWE

• Tách đường cập nhật gấp (incremental) khỏi đường rebuild toàn bộ để rebuild không chặn dữ liệu tươi.
• Federate-then-blend vừa là kiến trúc mở rộng vừa là ranh giới lỗi: mỗi nguồn có SLA, lỗi một nguồn không làm sập kết quả.
• Khi logic ranking phải nằm sát dữ liệu, search engine dạng dịch vụ đóng thành giới hạn; đó là lúc cân nhắc tự vận hành thư viện lõi.
• Model đầu tiên tốn nhiều thời gian nhất vì hạ tầng quanh nó chưa có.

Liên quan

• Hạ tầng tìm kiếm · Nền tảng ML (feature, training, serving, giám sát model)
• So sánh: Grab 2022 · Uber 2026