Spark: độ trễ dài giữa các công việc

Question

Vì vậy, chúng tôi đang chạy công việc phát tia lửa trích xuất dữ liệu và thực hiện một số chuyển đổi dữ liệu mở rộng và ghi vào một số tệp khác nhau. Tất cả mọi thứ đang chạy tốt nhưng tôi nhận được sự chậm trễ mở rộng ngẫu nhiên giữa kết thúc công việc tài nguyên chuyên sâu và bắt đầu công việc tiếp theo.

Trong hình bên dưới, chúng ta có thể thấy rằng công việc đã được lên lịch lúc 17:22:02 mất 15 phút để hoàn thành, có nghĩa là tôi dự kiến ​​công việc tiếp theo sẽ được lên lịch vào khoảng 17:37:02. Tuy nhiên, công việc tiếp theo đã được lên kế hoạch vào lúc 22:05:59, đó là +4 giờ sau khi công việc thành công.

Khi tôi tìm hiểu giao diện người dùng Spark của công việc tiếp theo, nó hiển thị < chậm trễ 1 giây của trình lên lịch. Vì vậy, tôi bối rối đến nơi mà sự chậm trễ dài 4 giờ này đến từ.

(Spark 1.6.1 với Hadoop 2)

Cập nhật:

tôi có thể xác nhận rằng David trả lời dưới đây được tại chỗ trên về cách ops IO được xử lý trong Spark là chút bất ngờ. (Nó có ý nghĩa để tập tin đó về cơ bản không "thu thập" phía sau bức màn trước khi nó viết xem xét đặt hàng và/hoặc các hoạt động khác.) Nhưng tôi hơi khó chịu bởi thực tế là thời gian I/O không được bao gồm trong thời gian thực hiện công việc. Tôi đoán bạn có thể thấy nó trong tab "SQL" của giao diện người dùng lửa vì các truy vấn vẫn chạy ngay cả với tất cả các công việc đang thành công nhưng bạn không thể đi sâu vào nó.

tôi chắc chắn rằng có nhiều cách để cải thiện nhưng dưới hai phương pháp là đủ cho tôi:

1. giảm số lượng tập tin
2. thiết parquet.enable.summary-metadata false

Answer 1

I/O hoạt động thường đi kèm với chi phí đáng kể sẽ xảy ra trên nút chính. Vì công việc này không được song song, có thể mất khá nhiều thời gian. Và vì nó không phải là một công việc, nó không hiển thị trong giao diện người quản lý tài nguyên. Một số ví dụ về/O nhiệm vụ tôi được thực hiện bởi các nút chính

• Spark sẽ viết thư cho thư mục s3 tạm thời, sau đó di chuyển các tập tin bằng cách sử dụng nút chính
• Đọc các tập tin văn bản thường xảy ra trên các nút chính
• Khi viết các file sàn gỗ, các nút chính sẽ quét tất cả các file sau ghi để kiểm tra schema

những vấn đề này có thể được giải quyết bằng cách tinh chỉnh các thiết lập sợi hoặc thiết kế lại mã của bạn. Nếu bạn cung cấp một số mã nguồn, tôi có thể xác định được vấn đề của bạn.

Discussion of writing I/O Overhead

Discussion of reading I/O Overhead