(Tại sao) chúng ta cần gọi bộ đệm hoặc duy trì trên RDD

Khi bộ dữ liệu phân tán linh hoạt (RDD) được tạo từ tệp văn bản hoặc bộ sưu tập (hoặc từ RDD khác), chúng ta có cần gọi "bộ đệm" hoặc "tồn tại" một cách rõ ràng để lưu trữ dữ liệu RDD vào bộ nhớ không? Hoặc là dữ liệu RDD được lưu trữ theo cách phân tán trong bộ nhớ theo mặc định?

val textFile = sc.textFile("/user/emp.txt")

Theo hiểu biết của tôi, sau bước trên, textFile là RDD và có sẵn trong tất cả / một số bộ nhớ của nút.

Nếu vậy, tại sao chúng ta cần gọi "cache" hoặc "vẫn tồn tại" trên textFile RDD?

Hầu hết các hoạt động RDD là lười biếng. Hãy nghĩ về một RDD như là một mô tả của một loạt các hoạt động. Một RDD không phải là dữ liệu. Vì vậy, dòng này:

val textFile = sc.textFile("/user/emp.txt")

Nó không làm gì cả. Nó tạo ra một RDD có nội dung "chúng ta sẽ cần tải tệp này". Các tập tin không được tải tại thời điểm này.

Các hoạt động RDD yêu cầu quan sát nội dung của dữ liệu không thể lười biếng. (Chúng được gọi là hành động .) Một ví dụ là RDD.count- để cho bạn biết số lượng dòng trong tệp, tệp cần phải được đọc. Vì vậy, nếu bạn viết textFile.count, tại thời điểm này, tệp sẽ được đọc, các dòng sẽ được tính và số đếm sẽ được trả về.

Nếu bạn gọi textFile.countlại thì sao? Điều tương tự: tập tin sẽ được đọc và đếm lại. Không có gì được lưu trữ. Một RDD không phải là dữ liệu.

Vậy RDD.cachelàm gì? Nếu bạn thêm textFile.cachevào đoạn mã trên:

val textFile = sc.textFile("/user/emp.txt")
textFile.cache

Nó không làm gì cả. RDD.cachecũng là một hoạt động lười biếng. Các tập tin vẫn không được đọc. Nhưng bây giờ RDD nói "đọc tệp này và sau đó lưu trữ nội dung". Nếu bạn sau đó chạy textFile.countlần đầu tiên, các tập tin sẽ được nạp, lưu trữ, và đếm. Nếu bạn gọi textFile.countlần thứ hai, thao tác sẽ sử dụng bộ đệm. Nó sẽ chỉ lấy dữ liệu từ bộ đệm và đếm các dòng.

Các hành vi bộ nhớ cache phụ thuộc vào bộ nhớ có sẵn. Ví dụ, nếu tệp không vừa trong bộ nhớ, thì textFile.countsẽ quay lại hành vi thông thường và đọc lại tệp.

Tôi nghĩ rằng câu hỏi sẽ được xây dựng tốt hơn như:

Khi nào chúng ta cần gọi bộ đệm hoặc tiếp tục sử dụng RDD?

Quá trình Spark là lười biếng, nghĩa là, sẽ không có gì xảy ra cho đến khi nó được yêu cầu. Để trả lời nhanh câu hỏi, sau khi val textFile = sc.textFile("/user/emp.txt")được ban hành, không có gì xảy ra với dữ liệu, chỉ có a HadoopRDDđược xây dựng, sử dụng tệp làm nguồn.

Giả sử chúng ta biến đổi dữ liệu đó một chút:

val wordsRDD = textFile.flatMap(line => line.split("\\W"))

Một lần nữa, không có gì xảy ra với dữ liệu. Bây giờ có một RDD mới wordsRDDchứa tham chiếu đến testFilevà một chức năng sẽ được áp dụng khi cần thiết.

Chỉ khi một hành động được gọi theo RDD, như wordsRDD.countchuỗi RDD, được gọi là dòng sẽ được thực thi. Đó là, dữ liệu, được chia nhỏ trong các phân vùng, sẽ được tải bởi người thi hành của cụm Spark, flatMapchức năng sẽ được áp dụng và kết quả sẽ được tính toán.

Trên một dòng dõi tuyến tính, như một trong ví dụ này, cache()là không cần thiết. Dữ liệu sẽ được tải cho người thực thi, tất cả các biến đổi sẽ được áp dụng và cuối cùng countsẽ được tính toán, tất cả trong bộ nhớ - nếu dữ liệu phù hợp với bộ nhớ.

cachelà hữu ích khi dòng dõi của RDD phân nhánh. Giả sử bạn muốn lọc các từ của ví dụ trước thành số đếm cho các từ tích cực và tiêu cực. Bạn có thể làm điều này như thế:

val positiveWordsCount = wordsRDD.filter(word => isPositive(word)).count()
val negativeWordsCount = wordsRDD.filter(word => isNegative(word)).count()

Ở đây, mỗi chi nhánh phát hành tải lại dữ liệu. Thêm một cachetuyên bố rõ ràng sẽ đảm bảo rằng việc xử lý được thực hiện trước đó được bảo tồn và tái sử dụng. Công việc sẽ như thế này:

val textFile = sc.textFile("/user/emp.txt")
val wordsRDD = textFile.flatMap(line => line.split("\\W"))
wordsRDD.cache()
val positiveWordsCount = wordsRDD.filter(word => isPositive(word)).count()
val negativeWordsCount = wordsRDD.filter(word => isNegative(word)).count()

Vì lý do đó, cacheđược cho là 'phá vỡ dòng dõi' vì nó tạo ra một điểm kiểm tra có thể được sử dụng lại để xử lý thêm.

Nguyên tắc chung: Sử dụng cachekhi dòng dõi RDD của bạn phân nhánh hoặc khi RDD được sử dụng nhiều lần như trong một vòng lặp.

Chúng ta có cần gọi "bộ đệm" hoặc "kiên trì" một cách rõ ràng để lưu trữ dữ liệu RDD vào bộ nhớ không?

Có, chỉ khi cần thiết.

Theo mặc định, dữ liệu RDD được lưu trữ theo cách phân tán trong bộ nhớ?

Không!

Và đây là những lý do tại sao:

• Spark hỗ trợ hai loại biến được chia sẻ: biến quảng bá, có thể được sử dụng để lưu trữ một giá trị trong bộ nhớ trên tất cả các nút và bộ tích lũy, là các biến chỉ được thêm vào, ví dụ như bộ đếm và tổng.

• RDD hỗ trợ hai loại hoạt động: biến đổi, tạo ra một tập dữ liệu mới từ một kiểu hiện có và các hành động, trả về một giá trị cho chương trình trình điều khiển sau khi chạy một tính toán trên tập dữ liệu. Ví dụ, bản đồ là một phép biến đổi chuyển từng phần tử tập dữ liệu qua một hàm và trả về một RDD mới biểu thị các kết quả. Mặt khác, giảm là một hành động tổng hợp tất cả các yếu tố của RDD bằng cách sử dụng một số chức năng và trả về kết quả cuối cùng cho chương trình trình điều khiển (mặc dù cũng có một lessByKey song song trả về một tập dữ liệu phân tán).

• Tất cả các biến đổi trong Spark đều lười biếng, ở chỗ chúng không tính toán kết quả của chúng ngay lập tức. Thay vào đó, họ chỉ nhớ các phép biến đổi được áp dụng cho một số tập dữ liệu cơ sở (ví dụ: một tệp). Các phép biến đổi chỉ được tính khi một hành động yêu cầu kết quả được trả về chương trình trình điều khiển. Thiết kế này cho phép Spark chạy hiệu quả hơn - ví dụ: chúng ta có thể nhận ra rằng một tập dữ liệu được tạo thông qua bản đồ sẽ được sử dụng để giảm và chỉ trả về kết quả giảm cho trình điều khiển, thay vì tập dữ liệu được ánh xạ lớn hơn.

• Theo mặc định, mỗi RDD được chuyển đổi có thể được tính toán lại mỗi khi bạn chạy một hành động trên nó. Tuy nhiên, bạn cũng có thể duy trì RDD trong bộ nhớ bằng phương thức kiên trì (hoặc bộ đệm), trong trường hợp đó Spark sẽ giữ các phần tử xung quanh trên cụm để truy cập nhanh hơn nhiều vào lần tiếp theo bạn truy vấn. Ngoài ra còn có hỗ trợ để duy trì RDD trên đĩa hoặc được nhân rộng trên nhiều nút.

Để biết thêm chi tiết xin vui lòng kiểm tra hướng dẫn lập trình Spark .

Dưới đây là ba tình huống bạn nên lưu trữ RDD của mình:

sử dụng RDD nhiều lần

thực hiện nhiều hành động trên cùng một RDD

cho chuỗi dài biến đổi (hoặc rất tốn kém)

Thêm một lý do khác để thêm (hoặc tạm thời thêm) cachecuộc gọi phương thức.

cho các vấn đề bộ nhớ gỡ lỗi

với cachephương thức, spark sẽ cung cấp thông tin gỡ lỗi liên quan đến kích thước của RDD. vì vậy, trong UI được tích hợp tia lửa, bạn sẽ nhận được thông tin tiêu thụ bộ nhớ RDD. và điều này đã chứng minh rất hữu ích trong việc chẩn đoán các vấn đề về bộ nhớ.