02 — Command Execution Path

Câu hỏi

Một cell notebook đi từ UI/control plane xuống Databricks Runtime như thế nào?

Mình muốn biết rõ hơn:

UI/API
  -> control channel
  -> queue/dispatch trong driver
  -> Python/Scala/SQL/R runtime
  -> output/result/progress
  -> UI

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

Notebook không chạy như một spark-submit mới cho mỗi cell. Nó cần gửi nhiều command nhỏ vào một runtime đang sống. Mỗi command phải có context, credential, language state, output streaming, cancel/interrupt, error/result serialization.

Nếu không tách command path, mình sẽ không hiểu Databricks đã biến Spark thành client-server interactive runtime bằng cách nào.

Breakdown

1. Control path từ UI/control plane vào container

Cần trả lời:

• UI nói trực tiếp với DriverDaemon hay qua ChauffeurDaemon?
• Chauffeur giữ request và DriverDaemon callback lại hay request sync?
• Có những server nào: Jetty HTTPS, Armeria gRPC/WebSocket, routing server?
• routeDirectNotebookMessageToRepl có phải đường streaming output thấp latency không?

2. Command queue/dispatch/cancel/result

Cần trả lời:

• handleRPCRequest nhận request gì?
• executeCommandImpl queue command ra sao?
• Nếu driver đang busy thì command mới đi đâu?
• Cancel/interrupt command đi theo path nào?
• Result lớn được trả inline hay ghi DBFS/storage?

3. Pre-command/post-command setup

Trước mỗi command, runtime có thể phải setup lại:

• AWS/Azure/Databricks API credential;
• Spark Connect running-command notification;
• Python FUSE init;
• Python hooks/sys.path/library update;
• Delta properties;
• display handler;
• post-command cleanup / WSFS flush.

Câu quan trọng: Databricks treat mỗi cell như một small transaction có setup/cleanup riêng, không phải chỉ send text vào REPL.

4. Python execution path

Cần trả lời:

• Driver JVM là Jupyter client hay server?
• ipykernel sống ở đâu?
• JVM gửi code qua Jupyter ZMQ hay Py4J?
• Py4J dùng cho control/helper object nào?
• DatabricksShell.do_execute thêm hook gì so với ipykernel thường?

5. Scala execution path

Cần trả lời:

• Scala classic dùng DriverILoop/SparkILoop in-process không?
• Khi nào dùng ScalaJupyterDriverLocal?
• Scala isolated/serverless có path khác với Dedicated không?
• State qua nhiều cell giữ ở interpreter/session boundary nào?

6. SQL/R/display path

Cần trả lời:

• SQL đi qua SQLDriverLocal hay Spark SQL trực tiếp?
• %sql trong Python notebook dùng comm channel hay py4j?
• R dùng Jupyter protocol hay socket riêng?
• Display dataframe/MIME bundle/result được serialize ở module nào?

Evidence trong snapshot

• Reverse docs:
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/05-python-notebook-kernel.md
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/13-chauffeur.md
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/14-driverdaemon.md
  • /Users/chimeyrock/ChimeyRock/databricks/reverse/docs/15-flow-thuc-thi-code.md
• Artifact/class/source:
  • DriverCorral.handleRPCRequest
  • DriverCorral.executeCommandImpl
  • cancelCommandImpl
  • writeDbfsCommandResultInternal
  • ExecuteCommandEvent$EventType
  • JupyterDriverLocal
  • PythonDriverLocal
  • PythonEntryPointInterface
  • ScalaDriverLocal
  • ScalaJupyterDriverLocal
  • DriverILoop
  • SQLDriverLocal
  • RDriverLocal, RShell, ROutputBuffer
  • python_shell/lib/dbruntime/DatabricksShell.py
  • python_shell/lib/dbruntime/spark_connection.py

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

Databricks biến notebook thành một command system. UI/control plane gửi request vào runtime qua Chauffeur/DriverDaemon; DriverCorral queue và dispatch command; mỗi language có DriverLocal/wrapper riêng; Python dùng ipykernel/Jupyter protocol với JVM làm client, Scala có path classic/Jupyter, SQL/R có driver-local riêng; output/result/progress được stream hoặc ghi qua result writer/storage.

Còn thiếu / cần verify

• Chưa có sequence end-to-end từ log thật cho một command cụ thể.
• Chưa xác định đầy đủ schema message/result giữa Chauffeur và DriverCorral.
• Cần đọc thêm body của language-specific DriverLocal nếu muốn kết luận exact protocol per language.