Concourse: Generating Personalized Content Notifications in Near-Real-Time

LinkedIn · 2018 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• Thông báo về nội dung trong mạng (Project Pepper) chạy bằng workflow Hadoop vài lần mỗi ngày: event Kafka được ETL vào HDFS, join với đồ thị fan-out, gắn feature, chấm điểm bằng model, rồi chuyển cho ATC (cổng chung cho mọi liên lạc với member).
• Hai hạn chế: trễ 6–10 giờ từ hoạt động tới thông báo (tin thời sự đã cũ, cuộc thảo luận đã qua), và join quá đắt nên không mở rộng được đồ thị target.

Thay đổi chính

• Concourse: nền tảng nearline trên Samza quyết định gửi thông báo nào cho ai (không tự gửi).
  • Workflow manager chuẩn hoá request, đẩy vào Kafka partition theo actor (người tạo nội dung) để cache feature của actor tại chỗ.
  • Fanout gọi Edges API lấy kết nối và follower, sinh một payload cho mỗi người nhận, gộp nếu một người nối qua nhiều cạnh.
  • Feature của actor và nội dung được gắn trước fanout (ít message, gọi mạng được); feature người nhận và cạnh phải tra local: dữ liệu vài TB, hàng trăm tỷ bản ghi, nằm trong RocksDB trên đĩa máy xử lý (vài chục µs so với vài ms tới vài trăm ms khi gọi mạng). Một job riêng đổi khoá mọi nguồn feature theo người nhận để cùng partition với stream chấm điểm.
• Partition theo người nhận: "superactor" có hàng triệu follower sinh hàng triệu ứng viên cho mỗi hoạt động; chia theo người nhận thì tải rải đều và mỗi host chỉ giữ feature của người nhận băm về nó.
• Đọc topic Kafka local thay vì aggregate: mỗi data center chỉ xử lý traffic của mình, tăng năng lực gấp 4.
• Over-partition topic giữa fanout và chấm điểm để mỗi process chỉ chấm vài nghìn bản ghi/giây và giữ vài GB feature.
• Đẩy delta feature: đẩy đủ từ Hadoop mất gần một ngày và đè nặng Kafka; chuyển sang đẩy phần thay đổi mỗi ngày và đẩy đủ mỗi tuần, rải trong vài ngày.
• Quy mô: hàng triệu ứng viên/giây, chấm điểm khoảng 500K QPS lúc đỉnh; hơn 550 triệu member.

Vì sao

• Thông báo có giá trị khi còn tươi; dữ liệu feature quá lớn để gọi mạng cho mỗi ứng viên nên phải đưa tới chỗ tính.

Bài học cho SWE

• Trong fan-out, gắn dữ liệu của phía "một" trước khi nhân bản, dữ liệu của phía "nhiều" thì co-partition và tra tại chỗ.
• Đổi khoá partition giữa các bước (actor → người nhận) là cách xử lý người nổi tiếng mà không cần nhánh đặc biệt.
• Dữ liệu đổi theo nhịp khác nhau thì đẩy delta thường xuyên và đẩy đủ thưa.

Liên quan

• LinkedIn 2018 · LinkedIn 2022 (cùng hướng batch → gần realtime) · LinkedIn 2015 (cụm local và aggregate)
• Realtime và fan-out · Stream processing · Hot partition và thundering herd