Runtime Anatomy: What I Found Under /databricks

What I Actually DidCopy Anchor Link

Mình mở Web Terminal trên Driver của một All-purpose Dedicated compute, rồi bắt đầu từ filesystem runtime mà terminal này nhìn thấy:

/databricks

Lúc đầu mình chỉ muốn tìm Spark Driver. Nhưng nhìn sơ bộ thì /databricks không giống một thư mục cài Spark thông thường. Nó giống một runtime bundle khá lớn: Spark engine, classpath, config theo Driver/Executor, notebook kernel, lifecycle service, catalog/storage client, sandbox artifact, native utility và startup/diagnostic asset đều nằm cạnh nhau.

Trang này không cố giải thích process nào gọi process nào. Nó chỉ trả lời câu hỏi đầu vào hơn:

Khi đứng trong Driver runtime của Dedicated compute, mình đã thấy những nhóm artifact nào dưới /databricks, và mỗi nhóm có thể phục vụ phần nào của interactive runtime?

Các trang sau mới đi từ artifact trên đĩa sang process, port, lifecycle và command path.

The First Big PictureCopy Anchor Link

Một cách nhìn hữu ích là tách /databricks thành các nhóm theo vai trò thay vì cố nhớ từng folder:

/databricks
  ├─ Spark engine and shared classpath
  ├─ Driver / Executor / common bootstrap configuration
  ├─ Lifecycle and driver-control runtime assets
  ├─ Notebook language and session environments
  ├─ Catalog, storage, credential and compatibility assets
  ├─ Safe execution / sandbox capabilities
  └─ Native startup, optimization and diagnostic assets

Điều này thay đổi mental model một chút. Dedicated compute không phải chỉ là một Spark distribution được khởi động trong cluster. Spark là engine lõi, nhưng quanh nó còn có một bundle lớn hơn để runtime có thể sống lâu, phục vụ notebook, tích hợp managed service và xử lý nhiều mode/capability khác nhau.

1. Spark Engine and Shared ClasspathCopy Anchor Link

Nhóm dễ nhận ra nhất gồm spark/, jars/ và hadoop-safety-jars/.

• spark/ chứa Spark distribution, các command quen thuộc như pyspark, spark-shell, spark-sql, spark-submit, sparkR, cùng scripts/config/runtime asset đi kèm.
• jars/ là classpath lớn mà Driver và Spark runtime dùng, không chỉ có artifact Apache Spark thuần mà còn có Databricks-specific implementation.
• hadoop-safety-jars/ là một bundle classpath nhỏ tách riêng, liên quan tới phần Hadoop/filesystem safety của Driver/Executor startup path.

Vì vậy, khi nhìn thấy Spark API trong notebook, phía dưới không đơn giản là một spark-submit tự dựng driver. Image đã mang sẵn engine, dependency và các script để đặt engine đó vào một managed interactive runtime.

2. Role-Specific Bootstrap and ConfigurationCopy Anchor Link

Các nhóm common/, driver/, executor/, etc/ và init_scripts/ cho thấy runtime được chuẩn bị theo role, chứ không dùng một config folder chung cho mọi process.

• common/ chứa cấu hình dùng chung cho deploy/runtime integration.
• driver/ chứa driver-side config, startup/preload asset và working surface dành cho long-lived Driver runtime.
• executor/ có asset hỗ trợ executor startup/runtime; điều này không có nghĩa executor chạy trong Driver container.
• etc/ là nơi có các runtime/service configuration phụ trợ.
• init_scripts/ là điểm móc trong boot sequence để chạy init script trước khi driver service đi lên. Snapshot này không giữ payload đã chạy, nên folder rỗng không có nghĩa chưa từng có init script.

Điểm đáng chú ý không phải là từng file config. Nó là việc runtime image tách sẵn common config, Driver config và Executor-supporting asset. Đây là một tín hiệu rằng notebook environment được dựng từ nhiều role/layer khác nhau trước khi user có object spark để dùng.

3. Lifecycle and Driver-Control AssetsCopy Anchor Link

Hai nhóm chauffeur/ và chauffeur-jars/ là dấu hiệu rõ nhất rằng Driver runtime không chỉ là một JVM Spark application độc lập.

• chauffeur/ giữ runtime/log artifact của một service thường trực mang tên Chauffeur.
• chauffeur-jars/ là dependency bundle riêng được startup script đặt lên classpath của ChauffeurDaemon.
• Bên trong spark/scripts/ có các script khác nhau để khởi động Chauffeur, Driver và Spark Master.

Chỉ từ filesystem, cách đọc an toàn là: image đóng gói một lifecycle/control layer cho Driver runtime, tách dependency và startup contract của nó khỏi Spark Driver classpath chính.

Trang Runtime Architecture from Process Signals mới dùng process/port evidence để đi tiếp: Chauffeur có phải control-plane không, nó có quan hệ gì với DriverDaemon, và Spark Master đứng ở đâu trong process topology.

4. Notebook Languages and Session EnvironmentsCopy Anchor Link

Interactive notebook cần nhiều hơn Spark API. Nó phải có nơi chạy Python, Scala/REPL, SQL/R entrypoint, giữ session state và trả output về notebook.

Snapshot có một nhóm khá rõ cho chuyện này:

• python_shell/ có Databricks-specific Python/IPython kernel integration: kernel launcher, REPL/session/communication helper và context cho notebook.
• scala-kernel-jars/ chứa classpath lớn cho Scala interactive session, gồm cả Almond/Ammonite-related artifact và môi trường dependency của Scala REPL.
• kernel-connections/ là chỗ dành cho kernel connection descriptor; snapshot không còn descriptor nào nên không thể dùng nó để kết luận kernel có đang chạy hay không.
• python-lsp/ là environment riêng cho Python language-server, formatting, linting và editor assistance — khác với việc chạy notebook Python code.
• sparkconnect/ có marker/setup artifact, trong khi spark/ cũng đóng gói command và package Connect-oriented.

Nhìn tổng thể, image đang chuẩn bị nhiều language/session surface song song. Nhưng cần giữ distinction quan trọng:

Package cho Python/Scala/Connect tồn tại trong image
  ≠ runtime này đang chạy mọi language kernel
  ≠ notebook hiện tại đang dùng đúng execution path đó

Đây là lý do page Command Execution Path cần tồn tại riêng: artifact trên disk chỉ cho biết runtime có thể làm gì; command trace mới nói một notebook thực sự đi qua đâu.

5. Catalog, Storage and Compatibility AssetsCopy Anchor Link

Một nhóm khác làm snapshot này khác Spark distribution thông thường là các directory về catalog/storage compatibility:

• databricks-hive-* và hive/ mang nhiều bộ dependency Hive/metastore theo version, cùng config dành cho đường SQL/Hive compatibility.
• unitycatalog/ mang code/module/connector liên quan Unity Catalog và Spark/Hadoop integration.
• một phần storage/filesystem behavior còn nằm trong Spark classpath, Hadoop config và wrapper implementation.

Cách hiểu vừa đủ ở giai đoạn inventory là: runtime bundle cần chuẩn bị nhiều đường để Spark/SQL có thể nói chuyện với catalog, metastore và filesystem theo managed platform model.

Không nên nhảy ngay tới kết luận “Unity Catalog đang bật” hoặc “runtime đang nối tới metastore X” chỉ vì folder/dependency có mặt. Những folder đó nói về capability và compatibility surface, không nói phiên bản nào được chọn hoặc policy nào đang được enforce trong compute cụ thể.

6. Safe Execution and Security-Adjacent AssetsCopy Anchor Link

safespark/, safespark-daemon/, keys/ và git/ cho thấy image còn mang theo nhiều asset phục vụ boundary xung quanh user code.

• safespark/ có client/config artifact cho SafeSpark-related integration.
• safespark-daemon/ có daemon runtime, sandbox image, CNI/network setup, container runtime binary và entrypoint scripts. Đây là bằng chứng mạnh rằng image có capability để tạo sandboxed execution boundary cho một số path.
• keys/ chứa trust/key/certificate artifact phục vụ secure channel; không đưa nội dung các file này vào note.
• git/ có integration/credential helper cho workflow Git trong runtime.

Có một caveat đặc biệt quan trọng ở đây: safespark-daemon/ khá lớn và đầy đủ không có nghĩa SafeSpark daemon hay sandbox đang active trong snapshot này. Nó có thể là capability chung của một image phục vụ nhiều access mode, workload hoặc feature flag khác nhau.

7. Native, Startup and Diagnostic AssetsCopy Anchor Link

Những folder như native/, appcds/, jvm-startup/, jfr_configs/ và snapstart/ dễ bị bỏ qua vì không hiện trực tiếp trong notebook, nhưng chúng giải thích tại sao image này lớn hơn nhiều một Spark distribution cơ bản.

• native/ mang native dependency/data, trong đó có asset cho geospatial coordinate transformation.
• appcds/ có Java class-data-sharing archive để hỗ trợ cold-start optimization khi JVM được cấu hình dùng nó.
• jvm-startup/ là điểm móc/startup artifact theo role JVM.
• jfr_configs/ có profile Java Flight Recorder cho diagnostic/performance capture.
• snapstart/ có script cho một checkpoint/restore-oriented startup path và xử lý config phụ thuộc host sau restore.

Tất cả những thứ này cho thấy image được chuẩn bị cho startup, diagnostics và nhiều runtime mode. Chúng không chứng minh AppCDS, JFR hay SnapStart đã được bật trong compute mà mình quan sát.

8. Small but Interesting Auxiliary AreasCopy Anchor Link

Ngoài các nhóm chính còn có data/, common/, keys/, git/, python-lsp/ và một số asset native/diagnostic khác.

Ở đây mình không cố ép mỗi folder vào một câu chuyện lớn. Ví dụ data/ chỉ cho thấy có configuration cho một data client, nhưng tên folder không đủ để xác định protocol hay service đứng sau. Cách ghi nhận đúng là: runtime bundle còn có các integration asset phụ trợ; cần probe cụ thể mới biến chúng thành một claim kiến trúc có ích.

Presence, Activity, and Architecture Are Different ClaimsCopy Anchor Link

Khi đọc snapshot, mình đang dùng ba mức claim khác nhau:

Phần lớn page này chỉ nằm ở hai mức đầu. Đây không phải nhược điểm; nó là cách giữ ranh giới rõ trước khi process architecture biến các artifact thành một working model.

Where This Leads NextCopy Anchor Link

Sau inventory này, Runtime Architecture from Process Signals có context rõ hơn:

• Khi thấy ChauffeurDaemon, mình biết nó thuộc một lifecycle/control bundle đã có startup script và classpath riêng.

• Khi thấy DriverDaemon, mình biết nó chạy trên một Driver-specific runtime surface, không phải toàn bộ /databricks thu gọn thành một process.

• Khi thấy Python kernel, Scala REPL hay SafeSpark-related process, mình có thể phân biệt language/session capability với service hiện đang active.

• Khi thấy catalog/storage endpoint, mình không mặc định xem nó là full control-plane topology chỉ từ một directory hoặc dependency.

• Runtime Architecture from Process Signals: artifact nào thực sự hiện thành process/port/component boundary.

• Runtime Lifecycle and Session Boundaries: runtime được boot, ready, giữ sống và share qua notebook session như thế nào.

• Command Execution Path: một cell thật sự đi từ notebook tới language runtime, Spark và result path ra sao.

My SummaryCopy Anchor Link

Điều mình thu được từ lần mở terminal này không phải là “đã hiểu Databricks internals”. Nó là một ảnh tổng thể cụ thể hơn nhiều: phía dưới notebook có một /databricks runtime bundle lớn, Spark engine chỉ là một phần trong đó.

Bundle này đóng gói sẵn config theo role, lifecycle service, kernel/REPL, catalog/storage compatibility, sandbox capability và startup/diagnostic asset. Từ đây mới có cơ sở để đọc process tree một cách có nghĩa: không chỉ hỏi process này tên gì, mà hỏi nó đang hiện thực hóa phần nào của interactive runtime đã được đóng gói sẵn trên disk.