Có cách nào (hoặc bất kỳ gói nào) để có thể biến các bộ sưu tập phân phối Spark (RDD s, Dataframe hoặc Dataset s) trực tiếp thành Broadcast biến mà không cần collect? API công khai dường như không có bất kỳ thứ gì "ngoài hộp", nhưng có thể làm gì đó ở cấp độ thấp hơn?Làm thế nào để chuyển đổi RDD, Dataframe hoặc Dataset thẳng đến một biến Broadcast mà không cần thu thập?
Tôi có thể tưởng tượng có một số tiềm năng tăng tốc 2x (hoặc nhiều hơn?) Cho các loại hoạt động này. Để giải thích chi tiết tôi muốn nói chi tiết, hãy làm việc qua ví dụ:
val myUberMap: Broadcast[Map[String, String]] =
sc.broadcast(myStringPairRdd.collect().toMap)
someOtherRdd.map(someCodeUsingTheUberMap)
Điều này làm cho tất cả dữ liệu được thu thập cho người lái xe, sau đó dữ liệu được phát sóng. Điều này có nghĩa là dữ liệu được gửi qua mạng cơ bản hai lần.
Điều gì sẽ là tốt đẹp là một cái gì đó như thế này:
val myUberMap: Broadcast[Map[String, String]] =
myStringPairRdd.toBroadcast((a: Array[(String, String)]) => a.toMap)
someOtherRdd.map(someCodeUsingTheUberMap)
đây Spark có thể bỏ qua việc thu thập các dữ liệu hoàn toàn và chỉ cần di chuyển dữ liệu giữa các nút.
THƯỞNG
Bên cạnh đó, có thể có một API monoid-like (hơi giống combineByKey) cho các tình huống nơi .toMap hoặc bất cứ hoạt động trên Array[T] là tốn kém, nhưng có thể có thể được thực hiện song song. Ví dụ. xây dựng cấu trúc Trie nhất định có thể tốn kém, loại chức năng này có thể dẫn đến phạm vi tuyệt vời cho thiết kế thuật toán. Hoạt động CPU này cũng có thể được chạy trong khi IO đang chạy quá - trong khi cơ chế phát sóng hiện tại đang chặn (tức là tất cả IO, sau đó tất cả CPU, sau đó tất cả IO một lần nữa).
Làm rõ
Gia nhập là không (chính) sử dụng trường hợp ở đây, nó có thể được giả định rằng tôi thưa thớt sử dụng cấu trúc dữ liệu phát sóng. Ví dụ: các phím trong someOtherRdd không có nghĩa là bao gồm các phím trong myUberMap nhưng tôi không biết phím nào tôi cần cho đến khi tôi đi qua someOtherRdd VÀ giả sử tôi sử dụng myUberMap nhiều lần.
Tôi biết rằng tất cả âm thanh hơi mơ hồ, nhưng vấn đề là thiết kế thuật toán học máy tổng quát hơn.
Tôi đã đưa ra một ưu tiên cho việc chỉ ra thực sự cho việc tham gia thường xuyên tham gia ngẫu nhiên thường tốt hơn. Nhưng không chấp nhận vì trường hợp sử dụng của tôi là tổng quát hơn thế - tôi đã không nói rằng tôi chỉ muốn tham gia những người tham gia đơn lẻ thường xuyên. Tôi đoán vì đó là điều mà 99% người làm với các chương trình phát sóng đó là một giả định công bằng. Tôi đã cập nhật OP của mình để rõ ràng hơn. Cảm ơn. – samthebest
Ồ, tôi hiểu rồi. Thing là miễn là chúng ta không sử dụng cấu trúc off-heap GC sẽ ăn chúng ta sống nhanh hơn nhiều so với lưu lượng mạng. Hoặc ít nhất đây là những gì tôi đã nhìn thấy cho đến nay. Và nếu chúng ta bắt đầu điều chỉnh cho những vật thể rất lớn thì chúng ta sẽ đạt được hiệu suất cao hơn. Vì vậy, ứng dụng duy nhất tôi có thể nghĩ ra là các đối tượng nhỏ và điều chỉnh để xử lý gần đúng thời gian thực. Nhưng không phát trực tuyến bởi vì chúng ta không thể phá hủy và tái phát thanh lịch. – zero323
Tôi nghĩ rằng sẽ hữu ích khi có thể nhanh chóng phát trực tiếp dữ liệu phát sóng từ những người thực thi. Nó sẽ cung cấp sự linh hoạt. Ví dụ: nếu biến phát sóng là kết quả của việc truy vấn nguồn dữ liệu jdbc bên ngoài rất chậm. Người ta có thể sử dụng khả năng tải song song của một cụm tia lửa để khởi tạo nhiều truy vấn trên máy chủ nguồn, có thể chạy trong các luồng song song. – ThatDataGuy