Lợi ích của Apache Beam so với Spark / Flink để xử lý hàng loạt là gì?

Apache Beam hỗ trợ nhiều phụ trợ Á hậu, bao gồm Apache Spark và Flink. Tôi quen thuộc với Spark / Flink và tôi đang cố gắng xem ưu / nhược điểm của Beam để xử lý hàng loạt.

Nhìn vào ví dụ đếm từ Beam , có cảm giác nó rất giống với các từ tương đương Spark / Flink bản địa, có thể với cú pháp dài dòng hơn một chút.

Tôi hiện không thấy lợi ích lớn của việc chọn Beam qua Spark / Flink cho một nhiệm vụ như vậy. Những quan sát duy nhất tôi có thể thực hiện cho đến nay:

• Pro: Tính trừu tượng trên các phụ trợ thực thi khác nhau.
• Con: Sự trừu tượng này phải trả giá bằng việc kiểm soát ít hơn những gì chính xác được thực thi trong Spark / Flink.

Có ví dụ nào tốt hơn nêu bật những ưu / nhược điểm khác của mô hình Beam không? Có bất kỳ thông tin nào về việc mất kiểm soát ảnh hưởng đến hiệu suất như thế nào không?

Lưu ý rằng tôi không yêu cầu sự khác biệt trong các khía cạnh phát trực tuyến, một phần được đề cập trong câu hỏi này và được tóm tắt trong bài viết này (lỗi thời do Spark 1.X).

Có một số thứ mà Beam bổ sung trên nhiều công cụ hiện có.

• Hợp nhất hàng loạt và phát trực tuyến. Nhiều hệ thống có thể xử lý cả hàng loạt và phát trực tuyến, nhưng chúng thường làm như vậy thông qua các API riêng biệt. Nhưng trong Beam, hàng loạt và phát trực tuyến chỉ là hai điểm trên phổ độ trễ, tính đầy đủ và chi phí. Không có vách đá học tập / viết lại từ hàng loạt sang phát trực tuyến. Vì vậy, nếu bạn viết một quy trình hàng loạt ngày hôm nay nhưng ngày mai độ trễ của bạn cần thay đổi, thì việc điều chỉnh vô cùng dễ dàng. Bạn có thể thấy loại hành trình này trong các ví dụ về Trò chơi trên thiết bị di động .

• Các API nâng cao mức độ trừu tượng : Các API của Beam tập trung vào việc nắm bắt các thuộc tính của dữ liệu và logic của bạn, thay vì để thông tin chi tiết về thời gian chạy cơ bản bị rò rỉ. Đây vừa là chìa khóa cho tính di động (xem đoạn tiếp theo) và cũng có thể cung cấp cho thời gian chạy sự linh hoạt trong cách chúng thực thi. Một cái gì đó như hợp nhất ParDo (hay còn gọi là thành phần chức năng) là một tối ưu hóa khá cơ bản mà đại đa số người chạy đã làm. Các tối ưu hóa khác vẫn đang được triển khai cho một số người chạy. Ví dụ: API nguồn của Beamđược xây dựng đặc biệt để tránh xác định quá mức độ phân giải trong đường ống. Thay vào đó, họ cung cấp cho người chạy các móc phù hợp để cân bằng lại động hoạt động trên các máy có sẵn. Điều này có thể tạo ra sự khác biệt rất lớn về hiệu suất bằng cách loại bỏ các mảnh ghép lệch tầng. Nói chung, chúng ta càng xây dựng được nhiều thông minh hơn cho những người chạy, chúng ta càng có lợi. Ngay cả việc điều chỉnh bằng tay cẩn thận nhất cũng sẽ thất bại khi dữ liệu, mã và môi trường thay đổi.

• Khả năng di chuyển qua các thời gian chạy. : Bởi vì hình dạng dữ liệu và yêu cầu thời gian chạy được tách biệt rõ ràng, nên cùng một đường ống có thể chạy theo nhiều cách. Và điều đó có nghĩa là bạn sẽ không phải viết lại mã khi bạn phải chuyển từ tại chỗ sang đám mây hoặc từ một hệ thống đã thử và đúng sang một thứ gì đó tiên tiến. Bạn có thể dễ dàng so sánh các tùy chọn để tìm ra sự kết hợp giữa môi trường và hiệu suất phù hợp nhất với nhu cầu hiện tại của mình. Và đó có thể là sự kết hợp của nhiều thứ - xử lý dữ liệu nhạy cảm tại chỗ với một trình chạy mã nguồn mở và xử lý dữ liệu khác trên một dịch vụ được quản lý trên đám mây.

Việc thiết kế mô hình Beam trở thành một sự trừu tượng hữu ích so với nhiều động cơ khác nhau là một việc khó. Beam không phải là giao điểm của chức năng của tất cả các động cơ (quá hạn chế!) Cũng không phải là sự kết hợp (quá nhiều của một bồn rửa nhà bếp!). Thay vào đó, Beam cố gắng đi đầu trong lĩnh vực xử lý dữ liệu, cả việc đẩy chức năng vào và kéo các mẫu ra khỏi công cụ thời gian chạy.

• Keyed State là một ví dụ tuyệt vời về chức năng tồn tại trong các công cụ khác nhau và cho phép các trường hợp sử dụng thú vị và phổ biến, nhưng ban đầu không thể hiện rõ trong Beam. Gần đây, chúng tôi đã mở rộng mô hình Beam để bao gồm một phiên bản của chức năng này theo các nguyên tắc thiết kế của Beam .
• Và ngược lại, chúng tôi hy vọng rằng Beam cũng sẽ ảnh hưởng đến lộ trình của các động cơ khác nhau. Ví dụ, ngữ nghĩa của Luồng dữ liệu của Flink bị ảnh hưởng bởi mô hình Beam (née Dataflow).
• Điều này cũng có nghĩa là các khả năng sẽ không phải lúc nào cũng hoàn toàn giống nhau trên các người chạy Beam khác nhau tại một thời điểm nhất định. Vì vậy, đó là lý do tại sao chúng tôi sử dụng ma trận khả năng để cố gắng truyền đạt rõ ràng trạng thái của mọi thứ.