Phân vùng quá mức (quá nhiều tác vụ) trên cụm Apache Spark/Cassandra

Question

Tôi đang chạy một ứng dụng đơn giản trên cụm Spark/Cassandra. Kể từ khi chuyển sang một môi trường mới (Spark 1.5 thay vì 1.2 và nâng cấp phiên bản Cassandra nhỏ) sự hạ cấp hiệu suất đáng kể đã được quan sát (từ 4 giây xuống còn 1-5 m. Cho cùng một nhiệm vụ và cùng một lượng dữ liệu). Sau khi điều tra ban đầu có vẻ như, cho cùng một mã từ góc nhìn của trình điều khiển tia lửa, có nhiều tác vụ được tạo ra (20 + k, nơi nó được sử dụng lên đến 5) và các bản ghi trên đầu của người thực hiện cũng phản ánh tương tự tình hình:

nhiều hành tuần tự của cùng một truy vấn trên các phân vùng khác nhau:

... 
CassandraTableScanRDD: Fetched 0 rows from x.y for partition 20324 in 0.138 s. 
CassandraTableScanRDD: Fetched 0 rows from x.y for partition 20327 in 0.058 s. 
CassandraTableScanRDD: Fetched 0 rows from x.y for partition 20329 in 0.053 s. 
... 

nơi nó từng là một duy nhất:

CassandraTableScanRDD: Fetched 905 rows from x.y for partition 0 in 2.992 s. 

Vì mã ứng dụng giống nhau, tôi tự hỏi điều gì có thể gây ra sự khác biệt trong hành vi phân vùng và những gì có thể được thực hiện để khắc phục điều đó?

NB! Thiết lập của cả hai môi trường nếu khác nhau, cấu hình không được chia sẻ/kế thừa.

Cảm ơn.

Answer 1

Phiên bản mới của Đầu nối Spark Cassandra sử dụng bảng Hệ thống bên trong Cassandra hiện đại hơn để ước tính kích thước phân chia. Bảng này được cập nhật mỗi (5 phút hiện tại) mặc dù số lượng phân chia bạn đang thấy là rất lớn. Giá trị đọc ra khỏi bảng này được chia cho kích thước phân chia của bạn.

Nếu bạn đang sử dụng C * nhỏ hơn 2.1.5, bảng này không tồn tại và việc phân vùng sẽ cần phải được thực hiện thủ công.

https://github.com/datastax/spark-cassandra-connector/blob/master/doc/FAQ.md#what-does-inputsplitsize_in_mb-use-to-determine-size

Bạn có thể tự vượt qua trong số lượng các mối qua ReadConf nếu bạn đang tiếp tục để xem vấn đề này.