Benchmarking Streaming Computation Engines at Yahoo!

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

Bối cảnh

• Yahoo dùng Apache Storm cho streaming từ 2012 (thay S4 tự làm); cuối 2015 có khoảng 2.300 node Storm. Thị trường đã có Flink, Spark Streaming, Samza, Apex, Dataflow, và các benchmark có sẵn không giống tải thật.
• Team Storm của Yahoo tự viết benchmark (mã nguồn mở) để biết Storm mạnh, yếu ở đâu so với Flink 0.10.1 và Spark Streaming 1.5.1.

Thiết kế benchmark

• Ứng dụng quảng cáo đơn giản: đọc event JSON từ Kafka → giải mã → lọc theo event_type → chiếu ad_id, event_time → join ad_id với campaign_id trong Redis → đếm theo cửa sổ 10 giây mỗi campaign, ghi cửa sổ vào Redis kèm thời điểm cập nhật cuối; phải xử lý event đến trễ.
• SLA 1 giây: Storm và Flink ghi Redis mỗi giây. Latency của một cửa sổ = (lần cập nhật cuối − thời điểm cửa sổ) − độ dài cửa sổ. 100 campaign × 10 quảng cáo; cụm 40 node, 20–25 node dùng cho benchmark; mỗi producer Kafka tụt lại ở khoảng 17.000 event/giây nên chạy nhiều producer. Mỗi lần chạy 30 phút.

Kết quả

• Storm và Flink phản ứng gần tuyến tính, latency dưới giây ở thông lượng khá cao; Storm có p99 thấp nhất. Flink ổn định từ 50.000 tới 170.000 event/giây, latency tăng vọt sau p99.
• Spark Streaming (micro-batch) có hình bậc thang: latency cao hơn nhiều, đổi lại kỳ vọng chịu được thông lượng cao hơn. Ở 100.000 message/giây latency tăng mạnh. Có hai nút chỉnh: độ dài batch (dài thì ít overhead, thông lượng cao, latency cao; tìm giá trị tối ưu tốn thời gian vì mỗi lần thử 30 phút) và song song (phải reshuffle như MapReduce). Ba vùng hoạt động: batch đủ dài (hầu hết event xử lý trong batch hiện tại); batch ngắn sát ngưỡng (event xử lý trong 3–4 batch sau, latency tốt hơn); tụt lại (spill ra đĩa, có thể hết đĩa).
• Tính năng back pressure mới của Spark 1.5: vùng một không có tác dụng; vùng hai làm latency dài hơn; vùng ba tác động xấu nhất, đổi độ dài batch nhưng vẫn không theo kịp.
• Storm 0.10.0 không chịu được trên 135.000 event/giây. Storm 0.11.0 thêm bộ điều khiển back pressure đơn giản, cho phép tắt acking (vốn chỉ dùng để điều tiết luồng chứ không để bảo đảm xử lý); tắt acking thì Storm thắng cả Flink về latency ở thông lượng cao, bật acking thì tệ ở 150.000/giây.
• Mọi engine chạy cấu hình mặc định; Flink và Spark tự gộp operator, Storm (không Trident) thì không, nên event đi qua nhiều bước hơn. Ghi chú ngày 17–18/12/2015: data Artisans chỉ ra code Flink công bố có debug, sau xác nhận code chạy thật không có, số liệu giữ nguyên.

Vì sao

• Theo Yahoo, kết luận là Storm "làm tốt" và không có người thắng rõ; hiệu năng chỉ là một yếu tố bên cạnh bảo mật và tích hợp. Đây là benchmark do chính team phát triển Storm làm, nên nên đọc như vậy.

Bài học cho SWE

• Micro-batch đổi latency lấy thông lượng; độ dài batch là nút chỉnh trực tiếp của đánh đổi đó, và tối ưu nó tốn công đo (Batching và khấu hao round-trip).
• Backpressure không tạo thêm năng lực: khi hệ không theo kịp, nó chỉ đổi chỗ tồn đọng, có khi làm latency xấu hơn (Load shedding, rate limit và backpressure).
• Benchmark streaming phải gần tải thật (join với kho ngoài, cửa sổ, event trễ) và đo latency đầu-cuối ở phân vị cao, không chỉ thông lượng (Pipeline dữ liệu và analytics).

Liên quan

• Yahoo 2015
• Stream processing
• Pipeline dữ liệu và analytics · Batching và khấu hao round-trip · Load shedding, rate limit và backpressure