Databricks 3 — Compute, Cluster & Photon

Compute là trái tim (và hoá đơn) của Databricks

Trong Databricks, compute là tài nguyên tính toán bạn thuê để chạy code — notebook, job ETL, truy vấn SQL, huấn luyện ML. Storage (Delta Lake trên S3/ADLS/GCS) rẻ và gần như vô hạn; compute mới là thứ đắt và phải quản lý chặt. Hiểu đúng mô hình compute là hiểu đúng cả hiệu năng lẫn hoá đơn cuối tháng.

Bài này nối tiếp Databricks 1 — Tổng quan và Databricks 2 — Delta Lake. Nếu bạn đã đọc series Spark thuần (Spark 1 — Tổng quan), phần lớn kiến thức Driver–Executor–DAG vẫn đúng; bài này tập trung vào những gì Databricks thêm vào và tối ưu so với Apache Spark mã nguồn mở (OSS).

Một điểm cần nhớ ngay: bạn không "cài Spark" trên Databricks. Bạn chọn một Databricks Runtime, chọn kích thước/loại compute, và nền tảng lo phần còn lại (cấp máy ảo từ cloud provider, cài Spark đã vá lỗi và tối ưu, gắn Delta, gỡ máy khi xong).

Databricks Runtime (DBR)

Databricks Runtime (DBR) là một image phần mềm đóng gói sẵn: Apache Spark đã được Databricks vá và tối ưu, cộng với hàng loạt thư viện (Delta Lake, Python/Scala/R, pandas, scikit-learn, các connector...) ở phiên bản đã kiểm thử tương thích với nhau. Mỗi cluster phải gắn đúng một phiên bản DBR.

Vài dòng DBR chính:

Quy tắc thực chiến trong môi trường ngân hàng: production luôn ghim một phiên bản LTS cụ thể (ví dụ một bản DBR 1x.y LTS), không dùng "latest". Lý do: một bản DBR nâng cấp có thể đổi hành vi Spark, đổi phiên bản thư viện, và làm job đang chạy ổn định gãy vào 2 giờ sáng. Nâng cấp DBR phải qua kiểm thử ở môi trường staging, có kế hoạch rollback.

DBR còn quyết định AQE (Adaptive Query Execution) bật sẵn, phiên bản Photon khả dụng, và các tối ưu I/O Delta — nên "chọn DBR" không chỉ là chọn phiên bản Spark, mà chọn cả một gói hành vi.

Các loại compute

Databricks có bốn nhóm compute chính. Chọn sai nhóm là nguồn lãng phí chi phí phổ biến nhất.

1. All-purpose cluster (interactive)

Cluster tương tác, dùng chung: nhiều người gắn notebook vào cùng một cluster để khám phá dữ liệu, phát triển pipeline, debug. Nó sống lâu, khởi động một lần rồi ai cũng dùng.

• Ưu: khởi động sẵn, tương tác nhanh, chia sẻ được.
• Nhược: rất tốn tiền nếu để idle (bật cả ngày mà không ai chạy gì). Đây là hố tiền số một.
• Bắt buộc bật auto-termination (tự tắt sau X phút không hoạt động, ví dụ 30–60 phút).

2. Job cluster (job compute)

Cluster được tạo riêng cho một job, chạy xong thì tự huỷ ngay. Bạn cấu hình nó trong định nghĩa job/workflow (xem Databricks 4 — Workflows & DLT), không phải một cluster đứng sẵn.

• Ưu: rẻ hơn đáng kể cho production — chỉ trả tiền đúng thời gian job chạy, không có idle; đơn giá DBU cho Jobs Compute thấp hơn All-purpose.
• Môi trường sạch mỗi lần chạy → tránh "trạng thái rác" giữa các lần.
• Đây là lựa chọn mặc định cho mọi pipeline ETL theo lịch.

3. SQL Warehouse

Compute chuyên cho SQL/BI — phục vụ truy vấn từ SQL Editor, dashboard, hoặc công cụ BI ngoài (Power BI, Tableau) qua JDBC/ODBC. Có ba loại: Classic, Pro, và Serverless. Chi tiết ở Databricks 6 — SQL & BI; ở đây chỉ cần biết nó là một dạng compute riêng, tối ưu cho truy vấn tương tác độ trễ thấp và luôn chạy Photon.

4. Serverless

Với serverless, Databricks tự quản pool máy ảo trong tài khoản của họ; bạn không cấp/không thấy VM, không chờ cloud provider tạo máy. Đổi lại:

• Khởi động cực nhanh (giây thay vì phút) — không phải chờ 3–5 phút cấp cluster.
• Không cấu hình node/autoscale thủ công.
• Có cho SQL Warehouse, Jobs, và Notebook (tuỳ khu vực/plan).
• Đơn giá tính khác (thường cao hơn theo giờ máy nhưng bù lại không có thời gian idle và không tốn phút khởi động) — phù hợp workload bùng nổ, ngắt quãng, ad-hoc.

Cấu hình cluster (compute cổ điển)

Với all-purpose và job cluster cổ điển (không serverless), bạn cấu hình các thành phần sau. Đây là bản đồ tinh thần khi nhìn UI tạo cluster:

• Driver node: máy chạy Driver — điều phối, giữ SparkSession, thu kết quả về. Kích thước driver quan trọng khi bạn collect() nhiều dữ liệu hoặc chạy nhiều task nhỏ.
• Worker node: các máy chạy Executor thực thi task. Số lượng và loại quyết định năng lực xử lý.
• Loại node (instance type): chọn máy tối ưu bộ nhớ (memory-optimized) cho join/aggregate lớn, tối ưu CPU (compute-optimized) cho tính toán nặng, hay có SSD cục bộ cho shuffle. Ánh xạ thẳng sang instance của cloud provider.
• Autoscaling: đặt min/max số worker; Databricks tự thêm/bớt worker theo tải. Giảm lãng phí khi tải thấp, co giãn khi tải cao. Nên bật cho job có tải biến thiên.
• Spot instance: dùng máy giá rẻ (giảm 60–90% so với on-demand) nhưng có thể bị cloud thu hồi bất kỳ lúc nào. Databricks cho phép cấu hình mix: driver on-demand (ổn định) + worker spot (rẻ), và fallback về on-demand nếu hết spot.
• Auto-termination: tự tắt cluster sau N phút idle. Bắt buộc cho all-purpose.

Chủ đề spot/autoscale/auto-termination gắn chặt với tối ưu chi phí compute — xem thêm FinOps 4 — Compute & pipeline.

Cluster pool — giảm thời gian khởi động

Cluster pool là một tập máy ảo đã được cấp sẵn và giữ ở trạng thái idle warm (đang chờ). Khi một cluster cần node, nó lấy máy từ pool thay vì chờ cloud provider tạo mới — giảm thời gian khởi động từ vài phút xuống vài chục giây.

• Bạn trả tiền hạ tầng (VM) cho máy trong pool kể cả khi idle, nhưng không trả DBU cho máy idle trong pool (chỉ trả DBU khi máy được cluster mượn để chạy).
• Rất hợp khi có nhiều job ngắn chạy liên tục — thời gian khởi động cộng dồn lại rất tốn. Pool "cắt" chi phí thời gian đó.

Photon — engine thực thi vectorized

Photon là engine thực thi thế hệ mới của Databricks, viết lại bằng C++ và vectorized (xử lý theo lô cột — batch of columns — tận dụng lệnh SIMD của CPU) thay vì xử lý từng dòng như engine JVM truyền thống. Nó tăng tốc đáng kể các truy vấn SQL và thao tác DataFrame.

Điểm mấu chốt về Photon:

• Tương thích Spark API: bạn không đổi code. Photon là lớp thực thi bên dưới; những phần truy vấn Photon hỗ trợ sẽ chạy bằng engine C++, phần chưa hỗ trợ tự động rơi về (fallback) engine Spark thường. Bạn bật/tắt Photon ở cấp cluster.
• Tăng tốc mạnh nhất với: aggregation, join, filter, quét dữ liệu cột lớn, ghi/đọc Delta. Ít tác dụng với: UDF Python thuần (chạy ngoài JVM/Photon), workload chủ yếu là logic Python.
• Đánh đổi DBU: cluster bật Photon có hệ số DBU cao hơn (thường ~2x DBU/giờ). Nhưng nếu job chạy nhanh hơn ~2 lần, tổng chi phí hoà hoặc rẻ hơn vì thời gian máy ngắn lại. Đây là bài toán đo, đừng đoán.

Khi nào bật Photon: workload SQL/DataFrame nặng trên bảng lớn (ETL Delta, aggregate, join) — gần như luôn nên thử. SQL Warehouse mặc định đã dùng Photon. Khi nào cân nhắc tắt: pipeline chủ yếu UDF Python/ML tuỳ biến, nơi Photon không giúp được mà vẫn tính DBU cao hơn.

Spark trên Databricks khác gì OSS

Cùng là Spark, nhưng bản trên Databricks có nhiều tối ưu đóng sẵn mà OSS không có hoặc phải tự cấu hình:

• Tối ưu I/O Delta: đọc/ghi Delta được tăng tốc (data skipping theo thống kê file, đọc chọn lọc, ghi tối ưu).
• Disk cache: tự động cache dữ liệu Parquet đã đọc lên SSD cục bộ của worker → lần đọc sau nhanh hơn, không tốn RAM như .cache() thủ công.
• AQE bật sẵn: Adaptive Query Execution tự chỉnh số partition shuffle, xử lý skew, đổi chiến lược join theo thống kê runtime — OSS phải bật/tinh chỉnh, Databricks đã bật mặc định.
• Photon: hoàn toàn độc quyền Databricks.

Kết quả: cùng một job, chạy trên Databricks (DBR + Photon + disk cache + AQE) thường nhanh hơn đáng kể so với Spark OSS dựng thủ công — đó là một phần giá trị bạn trả DBU cho.

Ví dụ minh hoạ (KHÔNG đánh dấu chạy được — đây là PySpark, không phải SQL sandbox):

# Minh hoạ: đọc Delta, aggregate — Photon/AQE/disk cache tự động tối ưu
txn = spark.read.table("bank.raw.transactions")   # bảng Delta trong Unity Catalog
daily = (
    txn.filter("created_at >= '2026-01-01'")
       .groupBy("account_id")
       .agg(F.sum("amount").alias("total"),
            F.count("*").alias("n_txn"))
)
daily.write.mode("overwrite").saveAsTable("bank.mart.daily_account_txn")

Quản lý thư viện & môi trường

Mỗi cluster có một môi trường phần mềm. Cách nạp thư viện bổ sung ngoài DBR:

• Cluster libraries: cài thư viện (PyPI, Maven, wheel, jar) gắn vào cluster — mọi notebook/job trên cluster đó dùng chung.
• Notebook-scoped libraries (%pip install ...): cài chỉ trong phiên notebook hiện tại, không ảnh hưởng người khác — tốt cho thử nghiệm.
• Init scripts: script chạy khi node khởi động (cài package hệ thống, cấu hình cert...). Trong ngân hàng, init script thường dùng để cài chứng chỉ CA nội bộ cho proxy doanh nghiệp.

Nguyên tắc production: khoá phiên bản thư viện (pin), quản lý qua cấu hình job/DBR chuẩn thay vì %pip rải rác, để môi trường tái lập được.

Unity Catalog compute & access mode

Khi cluster gắn với Unity Catalog (lớp quản trị/quyền tập trung — xem Databricks 5 — Unity Catalog), nó phải chạy ở một access mode phù hợp:

Với ngân hàng, access mode quyết định liệu kiểm soát quyền theo hàng/cột (row/column-level) của Unity Catalog có được thực thi hay không — nên chọn mode là một quyết định bảo mật, không chỉ kỹ thuật. Job production đọc dữ liệu khách hàng thường chạy single user với service principal để có nhật ký truy cập rõ ràng.

Chi phí compute — DBU

Databricks tính phí compute bằng DBU (Databricks Unit) — đơn vị đo năng lực xử lý theo thời gian. Hoá đơn của bạn gồm hai lớp cộng lại:

1. Phí DBU trả cho Databricks (theo số DBU tiêu thụ × đơn giá).
2. Phí hạ tầng (VM, đĩa, mạng) trả cho cloud provider (AWS/Azure/GCP).

Số DBU/giờ phụ thuộc loại compute và edition/tier:

• Cùng một máy, Jobs Compute rẻ hơn All-purpose Compute (đơn giá DBU thấp hơn) — lý do cốt lõi để đẩy production sang job cluster.
• Photon làm hệ số DBU cao hơn (bù bằng tốc độ).
• SQL Warehouse và serverless có bảng giá DBU riêng.
• Edition/tier (ví dụ các gói Standard/Premium/Enterprise) đổi đơn giá và tính năng bảo mật/quản trị.

Lưu ý: các con số đơn giá DBU thay đổi theo thời gian, khu vực, cloud và hợp đồng — đừng ghi nhớ con số cứng; luôn tra bảng giá hiện hành. Ở đây ta chỉ nắm tương quan giữa các loại compute.

Tra chi phí nội bộ theo nhóm

Databricks thực tế tra chi phí qua bảng system billing riêng. Nhưng nếu team lưu log chi phí quy đổi vào warehouse nội bộ (PostgreSQL), pattern tổng hợp theo nhóm rất quen thuộc — minh hoạ bằng "chi phí theo phòng ban":

-- ▶ Chạy được
SELECT d.name AS department,
       COUNT(e.id) AS headcount,
       SUM(e.salary) AS total_salary
FROM employees e
JOIN departments d ON e.department_id = d.id
GROUP BY d.name
ORDER BY total_salary DESC;

Các đòn bẩy tối ưu chi phí

1. Job cluster thay vì all-purpose cho mọi pipeline theo lịch — cắt idle và hạ đơn giá DBU.
2. Spot instance cho worker — giảm mạnh phí hạ tầng cho workload chịu được gián đoạn (ETL batch có retry).
3. Autoscaling — không cấp cứng số worker lớn "cho chắc".
4. Serverless cho ad-hoc/bùng nổ — bỏ hẳn thời gian idle và khởi động.
5. Tắt idle: auto-termination cho all-purpose; auto-stop cho SQL Warehouse.
6. Photon khi hợp — đo tổng chi phí, không chỉ nhìn DBU/giờ.
7. Cluster pool khi có nhiều job ngắn.

Use case thực tế

Bối cảnh (NCB): Team dữ liệu ngân hàng có hai loại workload đối lập:

(A) ETL đêm — hợp nhất giao dịch từ core banking. Chạy 02:00 hằng đêm, xử lý ~40 triệu giao dịch, viết vào bảng Delta bank.mart.daily_account_txn. Không ai ngồi chờ; chịu được nếu chậm vài phút do retry.

Cấu hình chọn:

• Job cluster (không all-purpose) — tạo lúc 02:00, tắt khi xong. Đơn giá DBU thấp, không idle.
• DBR LTS ghim phiên bản — ổn định, không "latest".
• Autoscaling 4–16 worker — co giãn theo khối lượng đêm.
• Worker spot (driver on-demand) — job có retry, chịu được thu hồi máy. Giảm phí hạ tầng ~70%.
• Photon bật — job toàn aggregate/join trên Delta, chạy nhanh gần gấp đôi → tổng chi phí giảm dù DBU/giờ cao hơn.
• Access mode single user + service principal — nhật ký truy cập dữ liệu khách hàng rõ ràng cho tuân thủ.

Kết quả minh hoạ: so với để một all-purpose cluster on-demand chạy cả đêm, cấu hình trên tiết kiệm ~50–60% chi phí compute cho cùng job.

(B) Phân tích tương tác — analyst dò bất thường giao dịch. Analyst gõ SQL ad-hoc trong ngày, tần suất không đều, cần trả lời trong vài giây.

Cấu hình chọn:

• Serverless SQL Warehouse — khởi động trong giây, không bắt analyst chờ 3–5 phút cấp cluster; auto-stop nhanh khi hết truy vấn nên không tốn tiền lúc rảnh.
• Photon mặc định đã bật trong SQL Warehouse → truy vấn quét bảng lớn vẫn nhanh.
• Đây đúng chỗ serverless thắng: tải bùng nổ, ngắt quãng, cần độ trễ khởi động thấp.

Bài học: cùng một dữ liệu Delta, hai workload dùng hai loại compute khác nhau — ép cả hai vào một all-purpose cluster chung là vừa chậm (analyst chờ) vừa tốn (ETL trả giá all-purpose).

Ghi nhớ

• Compute là thứ đắt và phải quản ở Databricks; storage rẻ. Chọn đúng loại compute là đòn bẩy chi phí lớn nhất.
• DBR = image Spark tối ưu + thư viện đóng gói; production ghim bản LTS, không dùng latest.
• Bốn loại compute: all-purpose (tương tác, dễ để idle tốn tiền) · job cluster (tạo–chạy–huỷ, rẻ nhất cho production) · SQL Warehouse (BI/SQL) · serverless (Databricks quản, khởi động nhanh, không idle).
• Cấu hình cluster cổ điển: driver/worker, loại node, autoscaling, spot (worker), auto-termination (bắt buộc cho all-purpose); cluster pool cắt thời gian khởi động cho nhiều job ngắn.
• Photon = engine C++ vectorized, tương thích Spark API (không đổi code), tăng tốc SQL/DataFrame; DBU/giờ cao hơn nhưng job nhanh hơn → thường hoà/rẻ hơn. Bật cho ETL Delta nặng, cân nhắc tắt với UDF Python thuần.
• Spark trên Databricks nhanh hơn OSS nhờ tối ưu I/O Delta, disk cache, AQE bật sẵn, Photon.
• DBU đo phí compute; hoá đơn = phí DBU (Databricks) + phí hạ tầng (cloud). Jobs Compute rẻ hơn All-purpose; đơn giá thay đổi — luôn tra bảng giá.
• Access mode Unity Catalog (shared vs single user) là quyết định bảo mật: quyết định quyền hàng/cột có được thực thi không.
• Ngân hàng: ETL đêm → job cluster + spot + autoscale + Photon; phân tích tương tác → serverless SQL Warehouse.