Building Venice with Apache Helix
Bài tóm tắt LinkedIn 2017 3. Quy mô lớn Độ khó: Khó
LinkedIn · 2017 · 3. Quy mô lớn · Độ khó: Khó — bài gốc
Bối cảnh
- LinkedIn có nhiều kho chuyên biệt với đánh đổi khác nhau (kho chỉ cần put/get nhanh, kho cần nhất quán mạnh và index). Theo bài, họ không viết mỗi kho từ đầu mà dùng thư viện chung; Helix (ra đời cho Espresso) lo quản lý cụm và được dùng cho storage, stream processing, search, analytics.
- Voldemort Read-Only là nơi phục vụ dữ liệu dẫn xuất: Hadoop tính dataset (ví dụ xếp hạng kết nối cấp hai cho People You May Know) rồi đẩy nguyên batch bất biến lên để web server đọc.
- Nhu cầu mới là dữ liệu dẫn xuất từ stream (Samza), ví dụ "impression discounting": gợi ý đã xem mà không bấm bị hạ hạng gần realtime.
Thay đổi chính
- Venice, kế nhiệm Voldemort Read-Only, phục vụ cả batch lẫn stream trong một hệ: hỗ trợ kiểu lambda, chỉ batch, hoặc chỉ stream (kappa).
- Đường ghi đi qua Kafka: dữ liệu từ Hadoop hoặc Samza được đẩy vào Kafka; storage node không nhận ghi online mà tự ingest bất đồng bộ từ Kafka. Đường đọc: router stateless chuyển request tới đúng node nhờ theo dõi bảng partition (vai spectator của Helix).
- Mỗi store-version ứng 1:1 với một topic Kafka và một resource Helix; mỗi partition Venice ứng với một partition Kafka. Controller tính số partition theo kích thước dataset.
- State model năm trạng thái: OFFLINE → BOOTSTRAP (đang đọc Kafka, chưa phục vụ) → ONLINE; lỗi thì ERROR; DROPPED khi dọn. Helix bảo đảm replica cùng partition không chung máy và rải đều.
- Chịu lỗi: controller leader/standby, dựng lại context từ ZooKeeper; node chết thì Helix dời partition, nhưng dùng delayed rebalance để sự cố ngắn không gây dời dữ liệu lớn; vì node luôn bootstrap từ Kafka nên phục hồi được kể cả khi mất mọi replica.
- Quy mô 2017: hơn 100 TB đẩy vào mỗi ngày, vài trăm nghìn QPS.
Vì sao
- Batch push bất biến không phục vụ được tín hiệu gần realtime; ghép batch và stream vào cùng một kho tránh phải ghép kết quả hai hệ ở phía ứng dụng.
Bài học cho SWE
- Coi Kafka là nguồn dữ liệu của kho phục vụ: replica là bản dựng lại được từ log, nên replication factor của kho và của Kafka độc lập.
- Thư viện quản lý cụm dùng chung (state machine + controller) làm các kho mới chỉ phải định nghĩa trạng thái và transition.
- Chờ một chút trước khi rebalance rẻ hơn dời partition lớn cho mỗi lần node chập chờn.
Liên quan
- LinkedIn 2015 (Helix ra đời ở đây) · LinkedIn 2014 (kappa) · LinkedIn 2022 (Venice chứa thuộc tính để join) · LinkedIn 2019
- Chọn database theo workload · Stream processing · Failover, replica và dự phòng dữ liệu
#Venice#Voldemort Read-Only#derived data serving#Apache Helix#state model#controller/participant/spectator#Kafka ingestion#store-version#BOOTSTRAP/ONLINE#delayed rebalance#lambda#kappa#PYMK
Được nhắc tới trong
Công ty (1)