Did you mean "Galene"?

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

Đồng tác giả Sriram Sankar cũng là đồng tác giả bài Unicorn của Facebook năm 2013 (Meta 2013); hai thiết kế giống nhau ở nhiều chỗ (static rank, index dựng offline + live update).

Bối cảnh

• Search của LinkedIn (hơn 300 triệu member, 2014) dựng trên Lucene, rồi đắp thêm từng lớp mỗi khi gặp giới hạn: Sensei (sharding, quản lý cụm), Search Content Store (giữ mọi term của entity, vì Lucene cập nhật bằng xoá rồi thêm cả entity), Zoie (bản trong bộ nhớ cho phần chưa commit), cùng Bobo, Cleo, Krati, Norbert, đều mở mã nguồn.
• Theo LinkedIn, cách scale phản ứng, hẹp dẫn tới "chạm tường": tốn thời gian giữ hệ chạy và các mẹo scale:
  • Dựng lại toàn bộ index cực khó (index dựng tăng dần), nên ngại cải tiến index; khi index hỏng phải bỏ rất nhiều công.
  • Live update ở cấp entity: đổi một term phải thay cả entity hàng trăm term, và phải giữ bản thứ hai của index.
  • Scoring cứng nhắc, khó cắm scorer viết tay hay học máy.
  • Lucene thiếu nhiều thứ (relevance offline, viết lại query, rerank, blend, thử nghiệm).
  • Quá nhiều thành phần nhỏ mở mã nguồn: sở hữu phân mảnh qua nhiều tổ chức, khó giữ chúng chạy cùng nhau.

Thay đổi chính (Galene)

• Giữ Lucene chỉ làm tầng index; bỏ hết Sensei, Search Content Store, Zoie và các thành phần khác. Galene là một framework thống nhất, không tách nhỏ để mở mã nguồn riêng.
• Đường query: Federator (viết lại query bằng plugin rewriter: sửa chính tả, từ đồng nghĩa, cá nhân hoá theo đồ thị) → nhiều vertical (member, job, company) → Broker của mỗi vertical (viết lại thêm, fan-out tới Searcher, gộp hoặc rerank) → Searcher trên một shard (retrieve, chấm điểm bằng plugin scorer). Federator và Broker là cùng một hệ với plugin khác nhau; blend nhiều vertical ở Federator.
• Dựng index offline trên Hadoop bằng chuỗi MapReduce (làm giàu dữ liệu bằng thuật toán relevance, rồi template dựng index và data model).
• Static rank tính offline, sắp entity theo độ quan trọng trong mọi posting list, để dừng sớm (early termination) khi đủ kết quả, dành CPU cho scorer phức tạp hơn.
• Live update ở cấp field bằng term partitioned segment, ba tầng: base index dựng trên Hadoop hằng tuần, không bao giờ sửa; live update buffer trong bộ nhớ; snapshot index trên đĩa, gộp từ buffer vài giờ một lần.
• Indexer riêng (giống Searcher nhưng không phục vụ search) làm việc gộp snapshot tốn kém, rồi chuyển snapshot tới Searcher; phân phối index và data model bằng framework dựa trên BitTorrent theo replica group, có version và rollback.
• Ví dụ Instant Member Search (typeahead): trước chỉ tìm trong kết nối cấp 1–2, giờ tìm được mọi member; theo LinkedIn nhanh hơn gấp đôi với khoảng một phần ba phần cứng.
• Tác động tổ chức: index dựng lại hằng tuần buộc quy trình test và release linh hoạt hơn; tách rõ việc hạ tầng khỏi việc relevance (engineer relevance không phải viết code đa luồng hay RPC). Hướng tiếp: search as a service, chuyển dần các vertical và các hệ khác trên Lucene/Sensei (gợi ý, feed, ads).

Vì sao

• Mỗi lớp vá một giới hạn cục bộ, nhưng tổng thể không dựng lại được, không đổi được, và không ai sở hữu trọn.

Bài học cho SWE

• Tách index dựng offline, bất biến khỏi lớp cập nhật trực tuyến nhỏ: dựng lại toàn bộ thành chuyện thường, phục hồi khi hỏng dễ (Hạ tầng tìm kiếm).
• Việc tốn kém (gộp snapshot) chạy trên máy không phục vụ request.
• Nhiều thành phần nhỏ đắp dần có thể gộp lại thành một framework có plugin; thêm một mảnh nhỏ không phải lúc nào cũng rẻ hơn (Monolith và microservices — đi và quay lại).
• Tách hạ tầng khỏi logic relevance bằng giao diện plugin để mỗi nhóm làm phần của mình; bốn năm sau LinkedIn gộp tiếp tầng federation (LinkedIn 2018).

Liên quan

• Cùng công ty: LinkedIn 2017 · LinkedIn 2018 · LinkedIn 2018 · LinkedIn 2019
• Meta 2013 (Unicorn, cùng đồng tác giả)
• Hạ tầng tìm kiếm · Monolith và microservices — đi và quay lại