Databricks

Why Databricks Runtime Is Worth Studying

Cá nhân tớ cho rằng Databricks cũng phải đối mặt những khó khăn tương tự mà tớ đã đề cập trước đó ở Stacks Integration khi tích hợp các thành phần của một Data Platform theo hướng Lakehouse. Tuy nhiên, điểm khác biệt - đồng thời cũng là lợi thế lớn của Databricks - nằm ở việc họ kiểm soát tương đối xuyên suốt trải nghiệm của user: từ control plane, compute và runtime cho đến governance, credential, storage access và observerbility.

Nhờ sở hữu nhiều lớp trong cùng một platform, Databricks có thể thiết kế các contract xuyên suốt execution path, thay vì để platform team tự nối từng hệ thống bằng convention, plugin và glue code. Databricks Runtime là một lát cắt phù hợp để quan sát cách những contract đó được đưa xuống data plane và gắn trực tiếp với quá trình thực thi workload.

From Open-Source Components to an Integrated Data Platform

Một data platform không chỉ có compute engine. Khi tự xây platform từ các dự án open source, platform team thường phải ghép nhiều hệ thống độc lập:

Khó khăn chính của open-source stack không nhất thiết nằm ở từng thành phần riêng lẻ, mà nằm ở các boundary giữa chúng. N otebook có thể biết user hiện tại nhưng Spark driver chỉ chạy bằng service account. Catalog có thể kiểm tra quyền truy cập table nhưng storage credential vẫn cho phép đọc trực tiếp raw path. Airflow biết job nào đang chạy nhưng audit system lại cần biết ai là requester hoặc owner thực sự. Log của notebook, Spark và SQL engine cũng thường nằm ở những hệ thống khác nhau.

Databricks cũng phải giải quyết gần như cùng một nhóm bài toán, nhưng cách tiếp cận của họ mạnh tay hơn việc ghép các open-source component có sẵn. Họ xây dựng và kiểm soát gần như toàn bộ platform surface - từ workspace, control plane, job orchestration và compute management cho đến runtime, catalog, credential boundary và observability — đồng thời mở rộng sâu các nền tảng open source nằm bên dưới.

Nếu xét riêng từng bài toán, một Databricks component chưa chắc có đầy đủ chiều sâu hoặc toàn bộ feature set của một công cụ open source chuyên biệt. Một hệ thống chuyên về orchestration, query serving, catalog hay observability có thể mạnh hơn trong phạm vi riêng của nó. Nhưng Databricks không tối ưu từng component như những sản phẩm độc lập. Họ chấp nhận một tập capability có chọn lọc ở mỗi lớp để đổi lấy khả năng thiết kế và tối ưu toàn bộ platform như một hệ thống thống nhất.

Đây mới là khác biệt quan trọng so với cách ghép một open-source stack. Trong open-source stack, mỗi component thường được tối ưu cục bộ cho bài toán của nó, còn identity, policy, credential, execution context và telemetry phải được platform team nối qua các boundary bằng convention, plugin hoặc glue code. Khi sở hữu các lớp ở cả hai phía của những boundary đó, Databricks có thể thay đổi contract giữa chúng và tối ưu theo mục tiêu toàn cục: một workload đi xuyên suốt platform vẫn giữ được identity, policy, storage boundary và observability context.

Databricks Runtime là điểm quan sát phù hợp vì đây là nơi lựa chọn kiến trúc đó trở thành hành vi thực tế. Những quyết định ở control plane, governance và credential layer cuối cùng phải đi vào execution path, tác động đến cách runtime khởi tạo session, thực thi command, truy cập dữ liệu và phát telemetry.

Why Start from the Interactive Runtime?

Databricks có nhiều compute surface như all-purpose compute cho notebook và development loop, Jobs Compute cho batch workload, hay SQL Warehouse cho query serving. Tuy nhiên, trong snapshot hiện tại, phần duy nhất tớ có thể quan sát được là interactive runtime, cụ thể hơn là notebook chạy trên all-purpose compute.

Lý do của giới hạn tương đối đơn giản, Databricks chỉ cho phép user sử dụng terminal trên all-purpose cluster chạy ở dedicated mode. Ớ đó tớ có thể tớ có thể quan sát trực tiếp nhiều thành phần tham gia vào execution path: daemon supervision, driver lifecycle, language session, command context, Spark configuration, filesystem wrapper, credential handling, authorization check và query-history hook.

Dù vậy, snapshot này vẫn cho phép tớ nhìn ra ngoài phạm vi interactive runtime, nhưng chỉ nên dừng ở mức nhận diện các mechanism và integration pattern chung. Nhiều vấn đề bộc lộ tại đây không chỉ dành riêng cho notebook; bất kỳ managed execution nào cũng phải trả lời những câu hỏi tương tự: runtime được khởi tạo và giám sát như thế nào, workload thực thi dưới identity nào, policy được áp dụng ở đâu, credential được cấp với scope gì, config nào cần được bảo vệ, và execution được ghi nhận vào audit hoặc telemetry ra sao.

Bên cạnh đó, Interactive runtime cũng khác rõ với mental model của một Spark application thông thường. Với spark-submit, driver được khởi tạo, tạo SparkContext, thực thi một workload xác định rồi kết thúc. Trong notebook chạy trên all-purpose compute, driver và runtime lại sống lâu để tiếp nhận nhiều command từ notebook hoặc client; language session duy trì state giữa các lần thực thi, mỗi command mang theo execution context riêng, còn result, log và telemetry được đưa ngược trở lại platform. Sự khác biệt này khiến interactive runtime trở thành một điểm vào hữu ích: phạm vi evidence tuy hẹp nhưng đủ sâu để quan sát cách Databricks đưa Spark từ một compute engine vào trong một managed runtime.

Research Questions

Thay vì đọc snapshot theo danh sách package, class hoặc config, tớ nghĩ điểm bắt đầu hợp lý hơn nên là đặt ra các câu hỏi về cách Databricks biến Spark thành một managed runtime. Với mỗi câu hỏi, tớ sẽ đối chiếu baseline của Spark hoặc open-source stack, xác định vấn đề Databricks cần giải thêm, tìm evidence trong snapshot, rồi phân biệt rõ đâu là observation, inference và phần vẫn chưa biết.

1. How Does Spark Become an Interactive Runtime?

Một Spark application thông thường được khởi tạo để thực thi workload rồi kết thúc. Databricks đã bổ sung những thành phần và protocol nào để biến nó thành một runtime sống lâu, tiếp nhận nhiều command và duy trì state cho notebook session?

Từ đó tớ có thể đặt ra các câu hỏi cần nghiên cứu như sau:

• Driver và các runtime process được khởi tạo, giám sát và kết thúc như thế nào?
• Thành phần nào quản lý lifecycle, readiness và failure recovery?
• Language session được tạo và duy trì state giữa các command ra sao?
• Một command đi từ notebook hoặc Control Plane xuống driver theo execution path nào?
• Result, log và execution status được truyền ngược về platform như thế nào?
• Các signal về warm pool, autoscaling và capacity xuất hiện ở đâu, và snapshot thực sự cho phép kết luận đến mức nào?

Từ đó có thể chia thành hai nhánh nghiên cứu chính:

• Interactive Runtime Lifecycle: runtime và các process liên quan được khởi tạo, giám sát, giữ sống và kết thúc như thế nào; các mechanism về readiness, failure recovery, warm pool và capacity tham gia vào lifecycle ra sao.
• Command Execution Path: một command đi từ notebook hoặc Control Plane xuống language session và Spark driver như thế nào; execution context được gắn ở đâu, state được duy trì ra sao, và result, log cùng execution status được truyền ngược về platform bằng cơ chế nào.

2. How Is Governance Enforced Inside the Runtime?

Khi user có thể thực thi code trực tiếp trong notebook, Databricks làm thế nào để identity, authorization và storage policy tiếp tục được duy trì xuyên suốt execution path, thay vì để runtime trở thành một đường bypass governance?

Và các câu hỏi cho phần này là:

• Runtime xác định user, service principal, session và run_as identity như thế nào?
• Identity dùng để authenticate có khác identity dùng để authorize hay không?
• Permission trên catalog, schema, table, row và column được kiểm tra tại lớp nào?
• Policy được gắn vào catalog resolution, analyzer, query plan hoặc execution path ra sao?
• Storage credential được cấp cho ai, với scope và lifetime như thế nào?
• Databricks ngăn việc truy cập raw path hoặc filesystem bypass catalog policy bằng mechanism nào?
• Những guarantee nào có evidence trực tiếp trong runtime, và phần nào phụ thuộc vào Unity Catalog hoặc Control Plane mà snapshot không quan sát được?

Với ba nhánh nghiên cứu chính:

• Identity & run_as: runtime biết ai đang chạy code gì, run_as được handle thế nào, principal nào dùng để authenticate/authorize.
• AuthZ & FGAC: table/catalog permission, row filter, column mask, policy check nằm ở đâu trong Spark/catalog/analyzer path.
• Credential & Storage Boundary: token/credential xuống storage được cấp theo scope nào và làm sao hạn chế raw-path/filesystem bypass.

3. [Optional] How Is the Runtime Turned into a Managed Product?

Ngoài việc chạy Spark workload, Databricks phải bổ sung những runtime contract nào để execution có thể được quản lý như một phần của platform với câu hỏi cần trả lời như sau:

• Databricks ngăn user vô hiệu hóa security và governance guardrail như thế nào?
• Runtime phát ra những health, readiness và capacity signal nào?
• Command, query, result, log, metric và audit event được liên kết với nhau ra sao?

Và tớ sẽ hoàn thiện phần này nếu có thể chứ nhiều lắm rồi =))).

My Summary

Trước khi đi vào từng research question, tớ sẽ tìm hiểu tổng quan về Databricks Interactive Runtime. Nếu chưa tự tin với baseline của Spark OSS, có thể đọc thêm phần Spark Foundation trước khi tiếp tục.