Spark Foundation

Cầu nối giữa Databricks Runtime thesis và phần Apache Spark nền tảng cần đọc trước khi đi sâu vào runtime evidence.

Motivation

Trang trước đang nói về một thesis khá rộng: Databricks không chỉ đóng gói Spark, mà own rất nhiều integration seam quanh workload execution — control plane, compute, notebook, runtime, catalog, credential, storage và observability.

Nhưng nếu nhảy thẳng từ thesis đó xuống các class như DriverDaemon, ChauffeurDaemon, ManagedCatalogSessionCatalog, CheckPermissions hay CredentialScopeFileSystem, mình rất dễ bị lẫn hai thứ:

đâu là behavior vốn có của Spark;
đâu là phần Databricks phải thêm vào để biến Spark thành managed runtime.

Vì vậy page này không phải một syllabus Spark đầy đủ. Nó là bridge page: đọc sau Databricks Runtime, trước khi đi vào Databricks Interactive Runtime và các research question cụ thể.

Nói ngắn gọn:

Databricks Runtime thesis
  -> mình cần Spark baseline nào để đọc đúng evidence?
  -> quay lại từng Databricks runtime question

Scope

Phần học Spark đầy đủ nằm ở Apache Spark. Trang này chỉ gom những baseline cần thiết để đọc Databricks Runtime, không thay thế learning path Spark độc lập.

The Main Boundary to Keep in Mind

Một Spark application bình thường đã có nhiều concept riêng: driver, executor, SparkContext, SparkSession, job, stage, task, catalog, SQL analyzer, Hadoop FileSystem, event log...

Databricks Runtime không xóa những concept này. Nó bọc thêm một managed layer quanh chúng:

Spark OSS baseline
  -> chạy application / query / task

Databricks Runtime layer
  -> giữ runtime sống lâu hơn
  -> nhận command từ notebook/control plane
  -> gắn identity/run_as/context
  -> enforce catalog/storage policy
  -> phát query history, audit, health, telemetry

Nếu không tách boundary này, mình sẽ dễ kết luận quá mạnh. Ví dụ thấy driver sống lâu trong notebook rồi nghĩ Spark driver vốn là service sống lâu. Không đúng. Spark driver bình thường sống theo application; còn notebook runtime làm nó trở thành một interactive execution service.

Reading Order

Tạm chia baseline thành bốn cụm. Mỗi cụm trả lời một nhóm câu hỏi trước, rồi mới quay lại Databricks evidence.

1. Spark Application Lifecycle

Câu hỏi đầu tiên rất cơ bản:

Một Spark application bình thường bắt đầu, chạy và kết thúc như thế nào?

Cần nắm được:

spark-submit tạo application ra sao;
driver giữ vai trò gì;
executor làm gì;
action tạo job/stage/task như thế nào;
driver chết khác executor chết ra sao;
cluster manager chịu trách nhiệm phần nào, Spark driver chịu trách nhiệm phần nào.

Đọc nền:

Quay lại Databricks đọc:

Điểm cần so sánh:

Spark batch/application lifecycle
  vs
Databricks notebook/runtime lifecycle

Trong Databricks interactive runtime, driver/runtime không chỉ chạy một job rồi kết thúc. Nó phải sống đủ lâu để nhận nhiều notebook command, giữ session state, báo readiness, stream result/log và cho platform observe/cancel/recover.

2. Session, State, and Client-server Boundary

Sau lifecycle là state boundary:

Khi user chạy nhiều cell/notebook/language khác nhau, Spark-level state và language-level state nằm ở đâu?

Cần nắm được:

một driver có bao nhiêu SparkContext;
SparkSession khác SparkContext thế nào;
SharedState và SessionState khác nhau ở đâu;
temp view, global temp view, cache, config nằm ở boundary nào;
PySpark classic dùng Py4J/JVM boundary ra sao;
Spark Connect thay đổi client/server boundary như thế nào;
Python variable, Scala variable và SQL temp view không cùng một loại state.

Đọc nền:

Quay lại Databricks đọc:

Điểm cần so sánh:

SparkSession / language session / notebook session

Đây là chỗ rất dễ nhầm. Hai notebook có thể share một phần Spark application/context, nhưng không nhất thiết share Python variables hay Scala REPL variables. Ngược lại, một vài Spark-level state như cache/global temp view/config có thể sống theo boundary khác.

3. Catalog, Analyzer, and AuthZ Path

Khi chuyển sang governance, câu hỏi không nên bắt đầu từ “Databricks có Ranger không?”. Câu hỏi đúng hơn là:

Một query Spark đi qua catalog/analyzer như thế nào trước khi chạm data, và policy có thể hook vào đâu?

Cần nắm được:

SQL/DataFrame query đi qua parse, analyze, optimize, physical planning, execution như thế nào;
catalog resolve table/schema/location ra sao;
SessionCatalog, external catalog, V2 catalog ở mức mental model;
analyzer rule có thể rewrite/check logical plan như thế nào;
table/column/row-level policy nên nằm ở phase nào;
DataFrame API, SQL string, catalog API, DDL/DML và path-based read có thể đi qua path khác nhau.

Đọc nền:

Spark Catalog & AuthZ Foundation

Quay lại Databricks đọc:

Điểm cần so sánh:

Spark catalog/analyzer baseline
  -> Databricks ManagedCatalog / Unity Catalog / CheckPermissions / row-column policy

Nếu chỉ thấy tên class hoặc config, chưa nên kết luận ngay “policy được enforce ở đây”. Cần phân biệt observation, inference và evidence: class tồn tại, config enable, stack trace, error path, query plan rewrite, hoặc runtime behavior.

4. Storage, Credential, and Bypass Surface

Catalog permission chưa đủ nếu user vẫn có thể đọc raw object storage path bằng credential nằm trong runtime. Vì vậy câu hỏi kế tiếp là:

Spark đọc file qua abstraction nào, credential đi vào runtime ra sao, và Databricks chặn raw-path bypass bằng lớp nào?

Cần nắm được:

Hadoop FileSystem abstraction;
s3a://, abfss://, gs://, dbfs://, file:// map tới implementation như thế nào;
fs.<scheme>.impl và credential provider chain;
path-based read khác table-based read ở đâu;
SparkConf/HadoopConf có lifecycle và mutability thế nào;
Py4J/shell/local process mở thêm bypass surface gì.

Đọc nền:

Quay lại Databricks đọc:

Điểm cần so sánh:

Spark/Hadoop FileSystem baseline
  -> Databricks CredentialScopeFileSystem / UC credential vending / config guardrail

Đây là chỗ Databricks Runtime quan trọng vì user có code execution. Nếu runtime cho phép user tự đổi config, lấy token, bypass wrapper, hoặc đọc raw path ngoài policy, thì catalog governance sẽ bị hở.

5. Observability as Runtime Contract

Cuối cùng là observability. Ở open-source stack, logs, Spark event log, query history, audit log và platform metrics thường là nhiều nguồn rời nhau. Với managed runtime, những signal này phải được nối lại theo context.

Câu hỏi cần giữ:

Một command/query trong notebook sinh ra những event nào, và platform map chúng về user/session/job/query/runtime như thế nào?

Cần nắm được:

Spark listener/event log/query execution ID ở mức mental model;
app log, audit log, query history, metric, trace khác nhau ở đâu;
command failed, Spark job failed, driver failed, executor failed, permission denied khác nhau thế nào;
health/readiness/capacity signal được dùng cho UX, autoscaling, support hay recovery.

Đọc nền:

hiện chưa có page Spark observability riêng;
tạm dùng Spark UI / event log / query execution ID như background cần bổ sung sau.

Quay lại Databricks đọc:

Observability as Runtime Contract

Điểm cần so sánh:

logging for debugging
  vs
telemetry as managed-runtime contract

Trong managed platform, telemetry không chỉ để xem log sau khi lỗi. Nó là contract để platform biết workload nào đang chạy, của ai, trong session nào, query nào, tốn tài nguyên ra sao, lỗi ở lớp nào và nên expose gì cho user/support/audit.

How to Use This Page While Reading

Mỗi khi đọc một Databricks runtime page, nên tự check theo format này:

Question
  -> mình đang hỏi gì?

Spark baseline
  -> Spark OSS bình thường làm gì?

Databricks gap
  -> managed platform cần giải thêm gì?

Observed mechanism
  -> snapshot thấy class/config/log/process nào?

Confidence
  -> observation, inference hay hypothesis?

Limit
  -> còn thiếu evidence gì?

Ví dụ:

Question
  -> notebook command chạy vào driver bằng đường nào?

Spark baseline
  -> spark-submit chạy main program trong driver process.

Databricks gap
  -> notebook cần gửi nhiều command vào runtime sống lâu, preserve state, stream result.

Observed mechanism
  -> Chauffeur / DriverDaemon / language kernel / command context.

Limit
  -> snapshot có thể thấy runtime process/class, nhưng không nhất thiết thấy full control-plane protocol.

Open Questions

Có cần tách một page Spark observability riêng trong phần Apache Spark không?
Khi viết từng Databricks page, baseline Spark nên nằm ngay trong page hay chỉ link về Spark foundation?
Với phần authZ/storage, evidence nào đủ mạnh để nói “enforced” thay vì chỉ “suggested by class/config”?
Spark Connect nên được dùng như comparison point tới đâu, để không làm người đọc hiểu nhầm rằng Databricks interactive runtime được xây dựa trên Spark Connect?

My Summary

Page này nên đóng vai trò như cái bản lề.

Trang Databricks Runtime trả lời vì sao Databricks Runtime đáng học như một case study về stack integration. Trang này trả lời: trước khi đọc sâu case study đó, mình cần giữ những baseline nào của Spark trong đầu.

Baseline quan trọng nhất không phải nhớ hết API Spark, mà là biết Spark bình thường có boundary nào:

application lifecycle
session/state boundary
catalog/analyzer path
storage/filesystem boundary
observability signal

Sau đó mới đọc Databricks Runtime như phần “Databricks thay đổi hoặc bọc thêm gì quanh các boundary đó để biến Spark thành managed data platform runtime”.

Spark Foundation

On this page