01 — Interactive Runtime Lifecycle

Câu hỏi

Databricks làm thế nào để biến Spark driver từ một process gắn với một job thành một runtime service sống lâu cho notebook?

Nói cụ thể hơn: chắc chắn phải có một driver chạy lâu dài, được boot lên theo phase, được monitor, có readiness, có signal để platform biết nó idle/busy/broken, và có đường để autoscaling đọc trạng thái — không thể chỉ phụ thuộc vào Spark dynamic allocation.

Vì sao câu này quan trọng

Trong Spark truyền thống, driver thường đi cùng vòng đời application:

start app -> create SparkContext -> run jobs -> stop app

Trong Databricks interactive cluster, notebook cần:

driver sống lâu
  -> nhiều command nhỏ đi vào
  -> SparkContext/REPL/session giữ state
  -> platform quản health/load/capacity

Nếu không hiểu lifecycle này, mình sẽ dễ nhầm “Databricks notebook = Jupyter gửi code vào Spark” trong khi thật ra runtime đã trở thành một service.

Breakdown

1. Process nào thật sự sống lâu?

Cần phân biệt:

• ChauffeurDaemon: entry/supervisor/control channel cấp container/runtime.
• DriverDaemon: JVM host SparkContext và REPL.
• DriverCorral: dispatcher thật cho REPL/command/status.
• Spark Master/Worker/Executor: execution substrate bên dưới.

Câu cần trả lời: cái nào nhận request, cái nào giữ SparkContext, cái nào quản command, cái nào expose health/load?

2. Boot sequence gồm những phase nào?

Cần trace từ container setup tới driver ready:

container setup
  -> class preload
  -> DriverDaemon main/create/start
  -> DriverCorral server start
  -> comm channel start
  -> DRIVER_READY_NOTIFICATION_SENT

Câu cần trả lời: phase nào là setup filesystem/security/env, phase nào là JVM/runtime, phase nào là ready cho notebook?

3. Driver được monitor/recover thế nào?

Cần tìm:

• monit supervise process nào.
• DriverDaemonMonitor đo gì.
• Chauffeur biết driver ready/dead qua event/channel nào.
• log nào ghi readiness/failure.

4. Warm pool nằm ở tầng nào?

Cần tách rõ:

pod/container warm pool
  -> driver warm pool
  -> REPL warm pool
  -> Spark/Python state snapshot-restore

Các event cần giải thích:

• REPL_DRIVER_READY_FOR_ASSIGNMENT
• DRIVER_ASSIGNED
• WARMPOOL_REPL_ALLOCATED
• SNAPSTART_*
• REPL_SNAPSHOT_* / REPL_RESTORE_*

5. Autoscaling signal ngoài Spark dynamic allocation là gì?

Spark dynamic allocation chỉ nói về executor demand trong Spark. Notebook platform còn cần biết:

• driver đang idle/busy không;
• command queue có backlog không;
• REPL/session nào đang chạy;
• worker nào pending removal;
• cluster load info trả về cho Chauffeur/control plane như thế nào.

Evidence trong snapshot

• Reverse docs:
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/01-tong-quan-kien-truc.md
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/02-boot-flow.md
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/12-nimbus-va-nephos.md
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/13-chauffeur.md
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/14-driverdaemon.md
• Artifact/class/log:
  • etc/monit/conf.d/
  • chauffeur/logs/active.log
  • driver/preload_class.lst
  • DriverDaemon
  • DriverCorral
  • DriverDaemonMonitor
  • SetupDriverEvent$EventType
  • StartReplEvent$EventType
  • ReplLifecycleEvent$EventType
  • getClusterLoadInfo
  • handleGetAutoscalingInfo

Câu trả lời tạm thời

Databricks không chỉ “giữ SparkContext không stop”. Nó biến driver thành một service process dài hạn. ChauffeurDaemon đứng ở rìa container/control channel, DriverDaemon host SparkContext/REPL, còn DriverCorral là dispatcher quản command, REPL, status và load info. Vì driver có lifecycle event, readiness event, monitor, warm pool và load API riêng, platform có thể quản interactive runtime như một service thay vì một job.

Còn thiếu / cần verify

• Chưa đọc sâu body getClusterLoadInfo nên chưa biết exact fields autoscaling đọc.
• Snapshot này không có đầy đủ control plane, nên Nimbus/Nephos decision logic chỉ thấy qua dấu vết driver/chauffeur.
• Cần decode thêm structured log để nối event timeline thật.