Questioning the Lambda Architecture

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

Bài quan điểm của Jay Kreps (lúc đó dẫn hạ tầng dữ liệu real-time ở LinkedIn, đồng tác giả Kafka), đăng trên O'Reilly chứ không trên blog LinkedIn. Đây là bài đặt tên "Kappa architecture". Kinh nghiệm dẫn chứng là của LinkedIn; mọi nhận định ghi "theo Kreps".

Bối cảnh

• Lambda architecture (Nathan Marz): cùng một luồng dữ liệu bất biến được đưa song song vào hệ batch (MapReduce) và hệ stream (Storm); logic biến đổi viết hai lần, kết quả hai bên ghép lại lúc truy vấn.
• Theo Kreps, điểm hay: giữ nguyên dữ liệu đầu vào bất biến, và nêu đúng bài toán xử lý lại (code luôn đổi vì thêm trường hay sửa bug, nên phải tính lại output), vốn hay bị bỏ qua. Các lý do khác (stream vốn kém chính xác hơn batch, "đánh bại CAP") theo ông không đứng vững.

Thay đổi chính

• Vấn đề của lambda: giữ hai hệ phân tán phức tạp cho ra cùng một kết quả đau đúng như tưởng tượng, và theo Kreps không sửa được. Một framework trừu tượng phủ cả hai (Summingbird) chỉ giảm được việc viết hai lần; gánh nặng vận hành và gỡ lỗi hai hệ vẫn còn, tính năng chỉ là phần giao của hai bên, và nó cắt người dùng khỏi hệ sinh thái Hadoop.
• LinkedIn đã thử: nhiều kiến trúc lai với Hadoop và cả một API riêng để code chạy "trong suốt" ở real-time hoặc Hadoop. Chạy được nhưng không dễ chịu: giữ code hai hệ đồng bộ rất khó, API che giấu thành trừu tượng rò rỉ nhất, đòi hiểu sâu cả hai tầng.
• Phương án thay thế (kappa): chỉ một hệ stream. (1) giữ toàn bộ log cần xử lý lại trong Kafka (ví dụ retention 30 ngày); (2) khi cần tính lại, chạy bản thứ hai của job từ đầu log, ghi ra bảng output mới, tăng độ song song để đuổi kịp nhanh; (3) đuổi kịp thì chuyển ứng dụng sang đọc bảng mới; (4) dừng job cũ, xoá bảng cũ. Giữ hai bảng một thời gian cho phép quay lui tức thì, hoặc chuyển dần bằng A/B test.
• LinkedIn làm cách này với Samza; giữ hơn 1 PB dữ liệu Kafka online, nhiều ứng dụng dùng retention dài cho đúng mục đích này. Kafka được thiết kế từ đầu để làm nền cho mô hình xử lý lại kiểu đó.

Vì sao

• Theo Kreps, chi phí tài nguyên hai cách gần ngang nhau: lambda chạy cả hai đường liên tục; kappa chỉ chạy bản thứ hai khi cần nhưng tạm thời cần gấp đôi chỗ ở DB output và một DB chịu được ghi khối lượng lớn. Lợi thế thật là phát triển, test, gỡ lỗi, vận hành trên một framework.
• Lời khuyên: không nhạy latency thì dùng batch, nhạy thì dùng stream, đừng làm cả hai cùng lúc trừ khi buộc phải. Lambda chỉ là trạng thái tạm do giới hạn của công cụ thời đó.

Bài học cho SWE

• Hai đường code phải cho cùng kết quả là nguồn lỗi và chi phí vận hành vĩnh viễn; trừu tượng phủ hai hệ khác nhau hẳn thường rò.
• Xử lý lại là yêu cầu thiết kế từ ngày đầu: giữ log đủ lâu, output có phiên bản, chuyển đọc giữa các phiên bản.
• Bảng output mới + chuyển đọc là cùng ý tưởng với blue/green deploy, áp cho dữ liệu dẫn xuất.

Liên quan

• Stream processing
• Walmart 2018 (lambda ở production) · LinkedIn 2019
• Pipeline dữ liệu và analytics · Event-driven, message queue và Kafka