ML Feature Serving Infrastructure at Lyft
Bài tóm tắt Lyft 2021 3. Quy mô lớn Độ khó: Trung bình
Lyft · 2021 (dựng từ 2017) · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc
Bài đầu của một cặp; bài sau về training: Lyft 2021.
Bối cảnh
- Model ML ở Lyft (ghép tài xế–khách, định giá, coupon, chống gian lận, hỗ trợ) cần feature tính theo hai cách: batch trên data warehouse Hive (ví dụ lịch sử huỷ chuyến một năm của user) và stream từ Kafka (ví dụ giá ước tính cho chuyến hiện tại). Cả hai loại đều phải đọc được theo hai kiểu: truy vấn batch giá trị lịch sử để train, và tra cứu điểm giá trị hiện tại lúc inference.
Thay đổi chính
- Feature Service (dựng Q4 2017) phục vụ cả bốn tổ hợp đó. Số liệu lúc viết (2021): vài nghìn feature, hàng triệu request mỗi phút, latency một chữ số ms, availability 99,99%+.
- Định nghĩa feature bằng SQL (người làm ML đã quen): một cột là entity ID (driver, passenger, ride), các cột còn lại là feature; có định nghĩa tới vài nghìn dòng SQL. Feature gom theo nhóm (entity type) để quản lý, nhưng version theo từng feature để lặp nhanh. Kèm metadata JSON: owner, kiểu dữ liệu, quy tắc kiểm tra, team cần báo khi việc sinh feature hỏng hoặc ra dữ liệu sai.
- Nạp: feature batch chạy job định kỳ bằng Flyte (tần suất đặt theo từng feature), chạy SQL trên warehouse rồi ghi vào Feature Service; feature stream chạy job Flink chạy SQL trên cửa sổ stream.
- Ghi và đọc: gRPC/REST; khi ghi, giá trị được kiểm theo metadata rồi lưu vào DynamoDB (mỗi dòng là giá trị mới nhất của một feature), từ đó nhân bản sang Hive (cho training) và Elasticsearch. Redis làm write-through cache cho cả giá trị lẫn metadata. Người ghi có thể phân tán nên dùng conditional check của DynamoDB làm optimistic locking: bản có timestamp mới nhất thắng. Đọc bằng
batch-get: Redis trước, miss thì DynamoDB, không khoá. - Online–offline parity: feature định nghĩa một lần, training và serving dùng chung định nghĩa, kiểm tra và biến đổi; nhưng giá trị mà hai bên thấy chỉ nhất quán sau cùng vì trễ nhân bản, trong mức chấp nhận được với các ứng dụng của Lyft.
Vì sao
- Mỗi model tự lo feature thì cùng một feature bị tính hai cách (một cho train, một cho serving) và lệch nhau; một chỗ định nghĩa duy nhất là cách giữ hai đường khớp.
Bài học cho SWE
- Tách đường ghi (một kho nguồn) khỏi các bản sao theo kiểu đọc (key-value cho tra cứu điểm, warehouse cho quét lịch sử); chấp nhận độ trễ nhân bản và nói rõ nó.
- Nhiều người ghi phân tán vào cùng một khoá thì cần quy tắc thắng rõ ràng (timestamp mới nhất qua conditional write), không để ghi đè ngẫu nhiên.
- Metadata vận hành (ai báo khi hỏng, quy tắc hợp lệ) đi cùng định nghĩa feature, không nằm riêng ở chỗ khác.
Liên quan
- Nền tảng ML (feature, training, serving, giám sát model)
- Cùng công ty: Lyft 2021 · Lyft 2019
- Cùng bài toán: Dropbox 2025 · Instacart 2023 · Spotify 2022 (Flyte, do Lyft tạo ra)
#Feature store#Feature Service#SQL feature definition#Flyte#Flink#DynamoDB#Redis write-through#Hive#Elasticsearch#optimistic locking#online-offline parity
Được nhắc tới trong
Công ty (1)
Bài tóm tắt (6)