The Log: What every software engineer should know about real-time data's unifying abstraction

LinkedIn · 2013 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài luận dài của Jay Kreps (khi đó ở LinkedIn). Phần lớn là lý thuyết về log; trang này tóm phần kể chuyện LinkedIn và các luận điểm chính. Bài sau của cùng tác giả: LinkedIn 2014.

Bối cảnh

• Khoảng 2007 LinkedIn bắt đầu chạm giới hạn của một database tập trung, chuyển sang một danh mục hệ phân tán chuyên biệt: search, social graph, Voldemort (key-value), Espresso (document), recommendation, OLAP, Hadoop, Teradata, inGraphs.
• Hạ tầng log sớm nhất là Databus: lớp cache log trên các bảng Oracle cũ, để nhiều hệ (graph, search index) subscribe thay đổi DB.
• Khoảng 2008, sau khi ra Voldemort, tác giả dựng Hadoop để chạy recommendation. Dự tính vài tuần cho việc đưa dữ liệu vào/ra, thực tế việc chép dữ liệu chiếm phần lớn công sức: lấy dữ liệu nhanh từ Oracle là "nghệ thuật đen", data warehouse đã xử lý không đảo ngược được nên phải đi thẳng vào DB nguồn và file log; mỗi nguồn mới cần cấu hình riêng và hay hỏng; pipeline hỏng thì Hadoop "chạy thuật toán hay trên dữ liệu xấu".

Thay đổi chính

• Bài toán O(N²): hàng chục hệ, mỗi hệ vừa là nguồn vừa là đích; nối từng cặp nghĩa là hai pipeline mỗi hệ và tiến tới O(N²). Cần một kho trung tâm: thêm một hệ chỉ phải nối vào một pipeline.
• Kafka được dựng để ghép ý tưởng messaging với khái niệm log trong DB: đầu tiên làm pipeline trung tâm cho activity data, sau mở rộng sang đẩy dữ liệu từ Hadoop ra, monitoring... Hàng trăm loại event (page view, impression, search, gọi service, exception). Năm 2013: hơn 60 tỷ message ghi/ngày.
• Lợi ích kiến trúc: trang job chỉ cần phát event "đã xem job"; Hadoop, chống scrape, analytics cho người đăng, impression cap của recommendation đều tự đọc log, nên code hiển thị không phải biết tới chúng. Log cũng làm buffer để consumer chậm không kéo producer.
• Cách scale log: chia partition (mỗi partition có thứ tự, không có thứ tự toàn cục), batch đọc/ghi, một định dạng nhị phân dùng chung cho bộ nhớ, đĩa và mạng (zero-copy).
• Stream processing: job batch chạy hằng ngày thường chỉ là tính toán liên tục với cửa sổ một ngày; khi dữ liệu có sẵn dạng log realtime nhiều subscriber, xử lý stream (Samza, Storm) trở nên tự nhiên. State của stream processor là bảng dẫn xuất từ changelog; log compaction giữ bản ghi mới nhất mỗi key thay vì xoá theo thời gian.
• Luận điểm "unbundled database": nhìn cả tổ chức như một database phân tán, các hệ truy vấn (Redis, Solr, Hive) là index, còn log là trục dữ liệu, nhất quán và phục hồi.

Vì sao

• Theo Kreps, giá trị lớn nhất của Hadoop đến từ việc có dữ liệu ở một chỗ mới; phủ được dữ liệu đòi pipeline tự động (schema đi kèm, bảng Hive tự sinh), điều không làm nổi nếu mỗi nguồn là một dự án riêng.

Bài học cho SWE

• Khi số hệ dữ liệu tăng, chi phí nằm ở tích hợp, không ở từng hệ; đặt một log trung tâm biến N² thành N.
• Phát event mô tả sự việc thay vì gọi từng hệ quan tâm giữ code đường chính gọn và để consumer tự thêm vào.
• Bảng và stream là hai mặt: changelog dựng lại được bảng, nên log là nguồn để bootstrap và sửa các index dẫn xuất.

Liên quan

• LinkedIn 2014 (bước tiếp: kappa) · LinkedIn 2015 (Kafka vận hành năm 2015) · LinkedIn 2019 (thay Databus) · LinkedIn 2015
• Event-driven, message queue và Kafka · Pipeline dữ liệu và analytics · Stream processing