Instacart's Item Availability Architecture: Solving for scale and consistency

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

Phần 3 trong series ba phần; phần 2 (mô hình và lịch chấm điểm): Instacart 2023. Site chặn crawler; ghi chú viết từ bản đọc qua trình duyệt.

Bối cảnh

• Điểm availability real-time từ phần 2 phải phục vụ ba nhu cầu: lấy qua RPC của team ML; lọc hàng loạt ở bước retrieval của search (RPC quá chậm); và nhất quán giữa mọi màn hình (một nơi báo hết hàng, nơi khác báo còn là mất lòng tin).

Thay đổi chính

• Đưa điểm vào DB phục vụ, đặt cạnh dữ liệu retrieval để lọc bằng SQL join, với hai đường nạp:
  • Full sync: dịch vụ chấm điểm cập nhật một bảng Snowflake nhiều lần mỗi ngày; worker đọc định kỳ và upsert điểm của item đã làm mới.
  • Lazy refresh: item xuất hiện trong kết quả search mà điểm đã quá tuổi cho phép thì được làm mới ở job nền; cập nhật gom qua Kinesis rồi ghi vào DB.
• Lý do: full sync thường xuyên cho hàng trăm triệu item không scale và phần lớn điểm không đổi đủ để ảnh hưởng trải nghiệm; item được search/mua nhiều thì có nhiều tín hiệu nên điểm đổi nhiều. Lấy search làm trigger giúp giảm 2/3 tải ingest mà vẫn làm mới thường hơn. Full sync vẫn chạy vài lần mỗi ngày để item đuôi và item đã bị lọc vì hết hàng (nên không bao giờ hiện trong search) có cơ hội cập nhật.
• Thử nhiều model song song bằng cấu hình: mỗi model một cột trong bảng; cấu hình ánh xạ phiên bản model → cột, dùng chung cho cả full sync lẫn lazy refresh; mỗi cột gắn một feature flag cho A/B test, có cột mặc định cho nhóm control. Model thắng được trỏ vào cột mặc định, cột cũ được giải phóng cho model kế tiếp. Số thí nghiệm tăng 6 lần.
• Ngưỡng lọc theo phân khúc: thay vì một ngưỡng cho mỗi tổ hợp (3 model × 3 loại sản phẩm × 4 retailer × 2 vùng × 8 nhóm user = 576), dùng ngưỡng gốc theo model + các delta cộng dồn theo phân khúc, lưu trong DB để chỉnh nhanh (ví dụ khi thiếu sữa bột trẻ em chỉ chỉnh delta của một loại sản phẩm). Sau đó tự động hoá việc chọn delta bằng vòng phản hồi trên metric khách hàng.

Vì sao

• Đặt dữ liệu dẫn xuất gần nơi đọc để lọc trong một truy vấn; làm mới theo độ nóng thay vì làm mới tất cả.

Bài học cho SWE

• Làm mới theo lượt đọc (refresh-on-read khi quá tuổi, chạy nền) cộng quét toàn bộ định kỳ để phủ phần không bao giờ được đọc; chỉ có một trong hai thì hoặc tốn, hoặc kẹt dữ liệu cũ (Cache và invalidation).
• Bẫy của làm mới theo lượt đọc: thứ đã bị lọc khỏi kết quả không bao giờ được đọc lại, nên không bao giờ được làm mới.
• Điểm do pipeline ML sinh ra là dữ liệu dẫn xuất như mọi bảng analytics: cần đường nạp, hạn tuổi và cách thử phiên bản mới (Pipeline dữ liệu và analytics).

Liên quan

• Nền tảng ML (feature, training, serving, giám sát model)
• Cùng công ty: Instacart 2020 · Instacart 2023
• Cache và invalidation · Pipeline dữ liệu và analytics