Spark Allocation & Dynamic Allocation

Executor demand, dynamic allocation, cluster manager capacity và vì sao platform autoscaling rộng hơn Spark.

Câu hỏi

Spark dynamic allocation giải quyết phần nào, và phần nào vẫn là việc của platform autoscaling?

Mental model

Spark nhìn workload ở mức executor/task:

jobs/stages/tasks
  -> cần thêm hoặc bớt executors
  -> request executor từ cluster manager
  -> executor register về driver

Dynamic allocation giúp Spark tăng/giảm số executor theo backlog/idle/shuffle constraints. Nhưng nó không tự trả lời toàn bộ câu hỏi capacity của managed platform.

Platform còn phải biết gì?

Notebook/runtime platform còn cần biết:

cluster/driver đang ready hay chưa;
command queue có backlog không;
user/session nào đang chạy;
driver có healthy không;
worker/node/pod có sẵn không;
downscale có phá notebook state/shuffle/cache không;
warm pool có thể cấp driver/REPL nhanh không.

Vì sao liên quan Databricks Runtime

Khi đọc Nimbus/Nephos/Chauffeur/DriverCorral, không nên gộp hết vào “Spark dynamic allocation”. Cần tách:

Spark executor allocation
  -> Spark-level demand/supply executors

Databricks platform autoscaling
  -> runtime/service-level health/load/capacity/allocation

Snapshot có dấu vết getClusterLoadInfo, handleGetAutoscalingInfo, warm pool events, Nephos/Nimbus notes. Những thứ này giúp hiểu Databricks nối Spark demand với platform capacity như thế nào.

Đọc tiếp

Interactive Runtime Lifecycle