Hỏi đáp về IT
Mã xác nhận Thay đổi một
Ngô Quang Hải quanghaisoft@yahoo.com Bigdata engineering

Phân phối bộ thực thi, lõi và bộ nhớ cho một ứng dụng Spark chạy trong Yarn:

Duyệt qua: 145
Phân phối bộ thực thi, lõi và bộ nhớ cho một ứng dụng Spark chạy trong Yarn:
spark-submit --class <CLASS_NAME> --num-executors ? --executor-cores ? --executor-memory ? ....
Bao giờ tự hỏi làm thế nào để cấu hình --num-executors--executor-memoryvà --execuor-coresparams spark cấu hình cho cluster của bạn? Hãy cùng tìm hiểu cách ..
  1. Lý thuyết bit Lil: Hãy xem một số khuyến nghị chính sẽ giúp hiểu rõ hơn về nó
  2. Thực hành: Tiếp theo, chúng tôi sẽ lấy một cụm ví dụ và đưa ra các con số được đề xuất cho các thông số tia lửa này
Lý thuyết bit Lil: Danh sách sau ghi lại một số đề xuất cần ghi nhớ khi định cấu hình chúng:
  • Hadoop / Yarn / OS Deamons: Khi chúng tôi chạy ứng dụng spark bằng trình quản lý cụm như Yarn, sẽ có một số daemon sẽ chạy trong nền như NameNode, Secondary NameNode, DataNode, JobTracker và TaskTracker. Vì vậy, trong khi chỉ định các trình thực thi num, chúng ta cần đảm bảo rằng chúng ta để lại đủ số lõi (~ 1 lõi cho mỗi nút) để các daemon này chạy trơn tru.
  • Yarn ApplicationMaster (AM): ApplicationMaster chịu trách nhiệm thương lượng tài nguyên từ ResourceManager và làm việc với NodeManagers để thực thi và giám sát các vùng chứa cũng như mức tiêu thụ tài nguyên của chúng. Nếu chúng tôi đang chạy tia lửa trên sợi, thì chúng tôi cần dự trù các tài nguyên mà AM sẽ cần (~ 1024MB và 1 Executor).
  • Thông lượng HDFS: Ứng dụng khách HDFS gặp sự cố với hàng tấn luồng đồng thời. Theo quan sát, HDFS đạt được thông lượng ghi đầy đủ với ~ 5 tác vụ trên mỗi trình thực thi. Vì vậy, thật tốt nếu giữ số lượng lõi cho mỗi người thực thi dưới con số đó.
  • MemoryOverhead: Hình ảnh sau đây mô tả việc sử dụng tia lửa-sợi-bộ nhớ.
    hình ảnh

Hai điều cần lưu ý từ bức tranh này:

 Full memory requested to yarn per executor =
          spark-executor-memory + spark.yarn.executor.memoryOverhead.
 spark.yarn.executor.memoryOverhead = 
        	Max(384MB, 7% of spark.executor-memory)

Vì vậy, nếu chúng tôi yêu cầu 20GB cho mỗi người thực thi, AM thực sự sẽ nhận được 20GB + memoryOverhead = 20 + 7% của 20GB = ~ 23GB bộ nhớ cho chúng tôi.

  • Chạy các trình thực thi với quá nhiều bộ nhớ thường dẫn đến sự chậm trễ thu thập rác quá mức.
  • Chạy các trình thực thi nhỏ (ví dụ: với một lõi đơn và chỉ đủ bộ nhớ cần thiết để chạy một tác vụ đơn lẻ) sẽ loại bỏ những lợi ích có được từ việc chạy nhiều tác vụ trong một JVM.
Lý thuyết đủ rồi .. Hãy bắt tay vào thực hành ..

Bây giờ, chúng ta hãy xem xét một cụm 10 nút với cấu hình sau và phân tích các khả năng khác nhau của việc phân phối bộ nhớ-lõi-bộ thực thi:

**Cluster Config:**
10 Nodes
16 cores per Node
64GB RAM per Node
Phương pháp tiếp cận đầu tiên: Những người thực thi nhỏ [Một người thực thi cho mỗi lõi]:

Các trình thực thi tí hon về cơ bản có nghĩa là một trình thực thi trên mỗi lõi. Bảng sau mô tả các giá trị của các thông số spar-config của chúng tôi với cách tiếp cận này:

- `--num-executors` = `In this approach, we'll assign one executor per core`
                    = `total-cores-in-cluster`
                   = `num-cores-per-node * total-nodes-in-cluster` 
                   = 16 x 10 = 160
- `--executor-cores` = 1 (one executor per core)
- `--executor-memory` = `amount of memory per executor`
                     = `mem-per-node/num-executors-per-node`
                     = 64GB/16 = 4GB

Phân tích: Chỉ với một trình thực thi cho mỗi lõi, như chúng ta đã thảo luận ở trên, chúng ta sẽ không thể tận dụng lợi thế của việc chạy nhiều tác vụ trong cùng một JVM. Ngoài ra, các biến được chia sẻ / được lưu trong bộ nhớ cache như biến phát sóng và bộ tích lũy sẽ được sao chép trong mỗi lõi của các nút là 16 lần . Ngoài ra, chúng tôi không để lại đủ chi phí bộ nhớ cho các quy trình daemon Hadoop / Yarn và chúng tôi không tính trong ApplicationManager. KHÔNG TỐT!

Cách tiếp cận thứ hai: Người thực thi chất béo (Một người thực thi trên mỗi nút):

Các trình thực thi béo về cơ bản có nghĩa là một trình thực thi trên mỗi nút. Bảng sau mô tả các giá trị của các thông số spark-config của chúng tôi với cách tiếp cận này:

- `--num-executors` = `In this approach, we'll assign one executor per node`
                    = `total-nodes-in-cluster`
                   = 10
- `--executor-cores` = `one executor per node means all the cores of the node are assigned to one executor`
                     = `total-cores-in-a-node`
                     = 16
- `--executor-memory` = `amount of memory per executor`
                     = `mem-per-node/num-executors-per-node`
                     = 64GB/1 = 64GB

Phân tích: Với tất cả 16 lõi cho mỗi trình thực thi, ngoài ApplicationManager và các quy trình daemon không được tính, thông lượng HDFS sẽ bị tổn thương và dẫn đến kết quả là quá nhiều rác. Ngoài ra, KHÔNG TỐT!

Phương pháp tiếp cận thứ ba: Cân bằng giữa chất béo (so với) tí hon

Theo các khuyến nghị mà chúng tôi đã thảo luận ở trên:

  • Dựa trên các khuyến nghị được đề cập ở trên, Hãy chỉ định 5 lõi cho mỗi người thực thi => --executor-cores = 5(để có thông lượng HDFS tốt)
  • Để lại 1 lõi trên mỗi nút cho các daemon Hadoop / Yarn => Số lõi có sẵn trên mỗi nút = 16-1 = 15
  • Vì vậy, Tổng số lõi có sẵn trong cụm = 15 x 10 = 150
  • Number of available executors = (total cores/num-cores-per-executor) = 150/5 = 30
  • Để lại 1 người thực thi ApplicationManager => --num-executors= 29
  • Số người thực thi mỗi nút = 30/10 = 3
  • Bộ nhớ cho mỗi người thực thi = 64GB / 3 = 21GB
  • Tính tổng chi phí heap = 7% của 21GB = 3GB. Vì vậy, thực tế --executor-memory= 21 - 3 = 18GB

Vì vậy, cấu hình được khuyến nghị là: 29 trình thực thi, mỗi bộ nhớ 18GB và mỗi lõi 5 lõi !!

Phân tích: Rõ ràng là cách tiếp cận thứ ba này đã tìm thấy sự cân bằng phù hợp giữa cách tiếp cận Fat và Tiny. Không cần phải nói, nó đã đạt được sự song song của một trình thực thi béo và thông lượng tốt nhất của một trình thực thi nhỏ !!

Phần kết luận:

Chúng tôi đã thấy:

  • Một số khuyến nghị cần ghi nhớ để định cấu hình các thông số này cho một ứng dụng spark như:
    • Ngân sách trong các tài nguyên mà Người quản lý ứng dụng của Yarn sẽ cần
    • Cách chúng ta nên dự phòng một số lõi cho các quy trình ngừng hoạt động của Hadoop / Yarn / OS
    • Đã học về spark-yarn-memory-usage
  • Ngoài ra, hãy kiểm tra và phân tích ba cách tiếp cận khác nhau để định cấu hình các thông số này:
    1. Người thực thi tí hon - Một người thực thi trên mỗi lõi
    2. Fat Executor - Một người thi hành mỗi nút
    3. Cách tiếp cận được đề xuất - Cân bằng phù hợp giữa Chất béo nhỏ (Vs) cùng với các khuyến nghị.

--num-executors--executor-coresVà --executor-memory.. ba params đóng một vai trò rất quan trọng trong việc thực hiện tia lửa khi họ kiểm soát số lượng CPU & bộ nhớ ứng dụng tia lửa của bạn được. Điều này làm cho người dùng hiểu đúng cách để cấu hình chúng là rất quan trọng. Hy vọng blog này đã giúp bạn có được quan điểm đó…

bigdata 2020/11/23 9:25

Để lại dấu chân

Bước trên một chân

Bình luận

copyright © bigdata 2010-2020
Processed in 0 seconds, 0 queries