Databricks 6 — Databricks SQL & BI

Databricks SQL là gì

Databricks SQL (DBSQL) là trải nghiệm data warehouse / BI chạy ngay trên lakehouse. Ý tưởng cốt lõi: cho phép analyst và công cụ BI chạy truy vấn SQL độ trễ thấp trực tiếp trên các bảng Delta (xem Databricks 2 — Delta Lake) đã nằm sẵn trong data lake — không cần copy dữ liệu sang một data warehouse riêng (Snowflake, Teradata, một cụm Oracle...). Đây chính là lời hứa "lakehouse": một bản sao dữ liệu, vừa phục vụ data engineering/ML (Spark), vừa phục vụ báo cáo/BI (SQL).

Với ngân hàng, điều này gỡ một nút thắt kiến trúc kinh điển: trước đây, dữ liệu phải ETL từ lake → warehouse chuyên dụng để BI truy vấn được, tạo ra độ trễ, chi phí lưu trữ nhân đôi, và một điểm lệch (dữ liệu warehouse trễ hơn lake). DBSQL cho BI đọc thẳng bảng gold trên lake, giảm một tầng copy.

DBSQL không phải một sản phẩm tách rời — nó dùng chung Unity Catalog để phân quyền/audit (xem Databricks 5 — Unity Catalog), chung bảng Delta với pipeline, chung engine Photon để tăng tốc. Nó chỉ là một persona và một loại compute được tối ưu riêng cho SQL tương tác.

SQL Warehouse: compute cho truy vấn SQL

SQL Warehouse (trước gọi là SQL endpoint) là một cụm compute chuyên để chạy truy vấn SQL. Khác với all-purpose cluster hay job cluster dành cho notebook/Spark job (xem Databricks 3 — Spark & Compute), SQL warehouse được đóng gói và tối ưu riêng cho khối lượng BI: nhiều truy vấn ngắn, đồng thời, độ trễ thấp. Nó luôn bật Photon (engine vector hoá viết bằng C++) và tối ưu cache cho SQL.

Có ba loại SQL warehouse:

Serverless là lựa chọn mặc định cho hầu hết use case BI hiện nay: nó khởi động trong vài giây (compute được giữ sẵn ở phía Databricks), auto-stop rất nhanh khi không dùng (giảm chi phí khi warehouse rảnh giữa các phiên báo cáo). Đổi lại, compute chạy trong tài khoản của Databricks — một số ngân hàng có yêu cầu residency/mạng khắt khe sẽ cân nhắc classic/pro để giữ compute trong VPC của mình.

Sizing, auto-scaling và multi-cluster

Cấu hình một SQL warehouse gồm ba núm chính, đừng nhầm lẫn giữa chúng:

• Cluster size (T-shirt size): 2X-Small → 4X-Large. Đây là kích thước một cluster — quyết định sức mạnh cho một truy vấn nặng. Truy vấn quét bảng lớn, join nhiều, cần size lớn.
• Auto-scaling (min–max clusters): DBSQL thêm/bớt số cluster trong dải min–max tuỳ tải đồng thời (concurrency). Đây là multi-cluster — quyết định bao nhiêu truy vấn chạy song song không xếp hàng. Buổi sáng nhiều người mở dashboard cùng lúc → scale lên nhiều cluster; đêm khuya → co về min.
• Auto-stop: dừng warehouse sau X phút rảnh. Serverless nên đặt ngắn (vài phút) vì bật lại nhanh; classic đặt dài hơn để tránh chờ khởi động lại.

Nguyên tắc thực chiến: size cho độ nặng của một query, số cluster (auto-scaling) cho số người dùng đồng thời. Dashboard nhẹ nhưng 200 người xem cùng lúc → cần nhiều cluster nhỏ, không phải một cluster khổng lồ. Ngược lại, một truy vấn phân tích quét 5 tỷ dòng → cần size lớn.

Photon (đã nhắc ở Databricks 3 — Spark & Compute) luôn bật trên SQL warehouse — đây là lý do DBSQL nhanh hơn hẳn Spark SQL thuần trên cùng dữ liệu: engine C++ vector hoá xử lý các phép quét/aggregate/join của BI cực nhanh.

Tính năng của Databricks SQL

DBSQL không chỉ là compute — nó có cả một bộ công cụ BI bản địa:

• SQL editor: giao diện viết và chạy SQL trên trình duyệt, có autocomplete theo Unity Catalog, xem schema, chạy nhiều truy vấn.
• Query history & profile: lưu lịch sử mọi truy vấn (ai chạy, khi nào, mất bao lâu, quét bao nhiêu dữ liệu). Query profile hiển thị cây thực thi chi tiết — tìm bottleneck (spill, skew, quét thừa) để tối ưu. Đây là công cụ chẩn đoán quan trọng nhất khi báo cáo chậm.
• Dashboard (bản địa): ghép nhiều truy vấn + biểu đồ thành dashboard ngay trong Databricks, chia sẻ theo quyền UC, lịch refresh tự động. Đủ dùng cho báo cáo nội bộ mà không cần công cụ BI ngoài.
• Alert: đặt cảnh báo theo ngưỡng trên kết quả một truy vấn — vd "số giao dịch lỗi > 100 trong 1 giờ" thì gửi email/webhook. Chạy theo lịch, so kết quả với điều kiện.
• Parameter: truy vấn/dashboard nhận tham số (dropdown, ngày, text) — người xem tự lọc theo chi nhánh, khoảng ngày mà không sửa SQL.
• Visualization: biến kết quả truy vấn thành biểu đồ (bar, line, pie, counter, bảng pivot...) ngay trong editor.

Về nguyên tắc thiết kế dashboard/biểu đồ tốt (chọn loại chart, bố cục), xem Viz 5 — Dashboard Design; về chuẩn hoá chỉ số/KPI cho báo cáo, xem BI 4 — Metrics & KPI.

Kết nối công cụ BI bên ngoài

Dashboard bản địa của DBSQL đủ cho báo cáo nội bộ, nhưng nhiều ngân hàng đã chuẩn hoá trên một công cụ BI doanh nghiệp. DBSQL để chúng kết nối vào SQL warehouse qua JDBC/ODBC hoặc connector chuyên dụng:

• Power BI — có connector Databricks bản địa, hỗ trợ cả DirectQuery (truy vấn trực tiếp warehouse) lẫn Import; SSO qua Entra.
• Tableau — connector Databricks sẵn có.
• Superset / Metabase — công cụ BI mã nguồn mở, kết nối qua driver Databricks (SQLAlchemy/JDBC).

Điểm mấu chốt về governance: dù người dùng vào từ Power BI hay Tableau, quyền vẫn do Unity Catalog quyết định — cùng row filter, column mask, audit như khi truy vấn từ SQL editor (xem Databricks 5 — Unity Catalog). Không có chuyện BI bypass được policy dữ liệu. Đây là khác biệt lớn so với kiến trúc cũ (extract dữ liệu ra file rồi BI đọc file — mất kiểm soát quyền).

-- Cấu hình JDBC minh hoạ (KHÔNG phải SQL chạy được)
jdbc:databricks://<host>:443/default;
  transportMode=http;ssl=1;
  httpPath=/sql/1.0/warehouses/<warehouse-id>;
  AuthMech=3;UID=token;PWD=<personal-access-token>

Tối ưu cho BI

Báo cáo BI đòi hỏi độ trễ thấp và ổn định. Vài kỹ thuật tối ưu trên DBSQL:

• Result cache (query result cache): hai người chạy cùng một truy vấn trên cùng dữ liệu → lần sau lấy kết quả từ cache, không tính lại. Rất hiệu quả cho dashboard nhiều người xem cùng chỉ số.
• Delta caching (disk cache): file Delta được cache trên SSD của cluster; lần quét sau đọc từ SSD thay vì object storage → nhanh hơn nhiều. Tự động, không cần cấu hình thủ công.
• Materialized view: precompute sẵn kết quả tổng hợp nặng (vd doanh số theo chi nhánh theo ngày), refresh incremental. Dashboard đọc bảng đã tính sẵn thay vì aggregate 5 tỷ dòng mỗi lần mở.
• Bảng gold chuẩn hoá cho báo cáo: đây là điểm quan trọng nhất. Đừng để BI truy vấn thẳng bảng bronze/silver thô. Xây một tầng gold — bảng đã làm sạch, đã join sẵn, đã aggregate ở mức phù hợp báo cáo, được liquid clustering / Z-order theo cột lọc thường dùng (chi nhánh, ngày). Bảng gold nhỏ, gọn, đúng hạt (grain) khiến truy vấn BI nhanh và rẻ.

Kiến trúc medallion (bronze → silver → gold) từ Databricks 4 — Workflows & DLT chính là nền cho việc này: pipeline sản xuất ra gold, DBSQL phục vụ gold cho BI.

Quản trị qua Unity Catalog

Mọi truy cập qua DBSQL đi qua Unity Catalog (xem Databricks 5 — Unity Catalog):

• Phân quyền: analyst chỉ SELECT được bảng/schema được GRANT; USE CATALOG/USE SCHEMA để "đi vào" namespace.
• Row filter & column mask: cán bộ chi nhánh chỉ thấy dữ liệu chi nhánh mình; CCCD/số tài khoản bị mask trừ nhóm được phép — áp ngay cả khi truy cập từ Power BI.
• Audit: mọi truy vấn (từ editor, dashboard, hay BI ngoài) đều vào query history + audit log — ai xem báo cáo nào, lúc nào. Cực quan trọng cho tuân thủ NĐ13/NHNN.
• Lineage: truy vết một chỉ số trên dashboard ngược về bảng gold, silver, bronze nguồn.

So sánh với các lựa chọn khác

DBSQL vs. warehouse chuyên dụng (Snowflake / BigQuery). Warehouse chuyên dụng (xem BigQuery 1 — Overview) là engine SQL trưởng thành, tối ưu sâu cho BI, vận hành gần như không cần chỉnh. DBSQL đổi lại cho bạn không phải copy dữ liệu ra khỏi lake — một bản dữ liệu, một hệ quyền (UC), dùng chung với ML/Spark. Nếu tổ chức đã "all-in" trên Databricks cho data engineering + ML, DBSQL tránh việc bê dữ liệu sang một hệ thứ hai. Nếu nhu cầu thuần BI trên dữ liệu quan hệ, warehouse chuyên dụng có thể đơn giản hơn về vận hành. Lưu ý: Snowflake/BigQuery dùng phương ngữ SQL riêng, không tương thích cú pháp Databricks.

DBSQL vs. Trino/Presto. Trino 5 — Lakehouse Query cũng là engine SQL federated truy vấn trực tiếp lakehouse (đọc Delta/Iceberg trên object storage) và là mã nguồn mở, không khoá vendor. DBSQL là bản thương mại tích hợp chặt hệ Databricks: Photon, UC governance, dashboard/alert bản địa, serverless managed. Trino mạnh khi cần liên kết nhiều nguồn (query cả lake lẫn Postgres/MySQL trong một câu) và tránh phụ thuộc một nhà cung cấp; DBSQL mạnh khi đã ở trong hệ Databricks và muốn trải nghiệm BI liền mạch cùng governance thống nhất.

Chi phí

Chi phí DBSQL tính theo DBU (Databricks Unit) — đơn vị đo mức tiêu thụ compute mỗi giờ, nhân với số giờ warehouse chạy. Serverless SQL có mức DBU/giờ cao hơn classic (vì compute managed), nhưng auto-stop nhanh thường bù lại: warehouse chỉ tính tiền khi thực sự phục vụ truy vấn, tắt trong vài giây khi rảnh. Ba đòn bẩy chi phí chính:

1. Auto-stop ngắn cho serverless — không trả tiền cho warehouse rảnh giữa các phiên.
2. Đúng size + auto-scaling — đừng để warehouse quá lớn chạy suốt; để nó co giãn theo tải.
3. Tối ưu truy vấn (gold table, materialized view, cache) — query nhanh = ít giờ compute = ít DBU.

Ngoài DBU, còn phí hạ tầng cloud (với classic/pro chạy VM trong tài khoản bạn) và phí object storage — không đáng kể so với compute.

Ví dụ truy vấn phân tích

Kiểu truy vấn BI điển hình trên bảng gold (cú pháp Databricks — minh hoạ, KHÔNG chạy trong sandbox):

-- Ví dụ minh hoạ (Databricks SQL — KHÔNG chạy trong sandbox)
-- Doanh số giao dịch theo chi nhánh, 30 ngày gần nhất, dùng parameter ngày
SELECT
  branch_code,
  COUNT(*)             AS num_txn,
  SUM(amount)          AS total_amount,
  AVG(amount)          AS avg_amount
FROM banking_core.gold.txn_daily
WHERE txn_date BETWEEN :start_date AND :end_date
GROUP BY branch_code
ORDER BY total_amount DESC;

:start_date / :end_date là parameter — người xem chọn khoảng ngày trên dashboard mà không sửa SQL.

Về mẫu SQL phân tích (window function, cohort, running total) áp dụng được cho cả DBSQL, xem SQL 13 — Analytics Patterns.

Để hình dung một truy vấn tương tự trên dữ liệu quan hệ thuần (đây là ví dụ chạy được trong sandbox Postgres, cú pháp chuẩn):

-- ▶ Chạy được
SELECT a.currency,
       COUNT(*)      AS num_txn,
       SUM(t.amount) AS total_amount,
       AVG(t.amount) AS avg_amount
FROM transactions t
JOIN accounts a ON a.id = t.account_id
GROUP BY a.currency
ORDER BY total_amount DESC;

Use case thực tế

Bối cảnh: đội Retail Analytics của NCB cần một hệ báo cáo doanh số & rủi ro giao dịch phục vụ ~180 người dùng (cán bộ chi nhánh, quản lý vùng, ban lãnh đạo). Dữ liệu giao dịch (~4 tỷ dòng lịch sử, +8 triệu dòng/ngày) đã nằm trên lakehouse dưới dạng bảng Delta. Trước đây, dữ liệu phải ETL hằng đêm sang một cụm warehouse riêng để BI truy vấn — trễ 6 tiếng, chi phí lưu trữ nhân đôi.

Triển khai DBSQL:

1. Pipeline DLT sản xuất bảng gold gold.txn_daily (giao dịch tổng hợp theo chi nhánh/ngày, ~2 triệu dòng) và gold.txn_detail — cả hai liquid clustering theo branch_code, txn_date.
2. Tạo SQL warehouse serverless, size Small, auto-scaling 1–4 cluster, auto-stop 5 phút.
3. Dashboard bản địa cho báo cáo chuẩn (doanh số, tỷ lệ giao dịch lỗi) với parameter chi nhánh + khoảng ngày; Power BI (DirectQuery) cho báo cáo ban lãnh đạo.
4. Row filter qua UC: cán bộ chi nhánh chỉ thấy chi nhánh mình; quản lý vùng thấy cả vùng. Column mask che số tài khoản với vai trò không được phép.
5. Alert: truy vấn "tỷ lệ giao dịch lỗi theo giờ" chạy mỗi 15 phút, vượt ngưỡng 2% thì gửi cảnh báo cho đội vận hành.

Kết quả: báo cáo từ trễ 6 tiếng còn gần thời gian thực (đọc thẳng gold cập nhật liên tục). Buổi sáng 8–9h khi ~150 người mở dashboard, warehouse tự scale lên 4 cluster rồi co về 1 cluster lúc trưa; nhờ auto-stop, đêm không tốn compute. Result cache khiến nhiều người xem cùng chỉ số chỉ tính một lần. Loại bỏ hẳn tầng ETL sang warehouse riêng và bản sao dữ liệu — giảm chi phí lưu trữ ~40% và một điểm lỗi vận hành. Mọi truy cập, dù từ dashboard hay Power BI, đều bị UC kiểm soát quyền và ghi audit — sẵn sàng cho thanh tra.

Ghi nhớ

• DBSQL mang trải nghiệm warehouse/BI lên lakehouse: SQL độ trễ thấp trực tiếp trên bảng Delta, không cần copy sang warehouse riêng.
• SQL Warehouse = compute chuyên cho SQL, luôn bật Photon; ba loại classic / pro / serverless — serverless khởi động vài giây, auto-stop nhanh, DBU/giờ cao hơn.
• Phân biệt size (sức cho một query nặng) với auto-scaling/multi-cluster (số truy vấn đồng thời) — đừng nhầm; đặt auto-stop ngắn cho serverless.
• Tính năng bản địa: SQL editor, query history & profile, dashboard, alert (ngưỡng), parameter, visualization.
• Kết nối Power BI/Tableau/Superset/Metabase qua JDBC/ODBC/connector; quyền vẫn do Unity Catalog áp — BI không bypass được policy.
• Tối ưu BI: result cache, Delta cache, materialized view, và quan trọng nhất là bảng gold chuẩn hoá/clustering cho báo cáo.
• Governance qua UC: quyền, row filter/column mask, audit, lineage — phục vụ tuân thủ NĐ13/NHNN.
• So sánh: vs Snowflake/BigQuery (tránh copy dữ liệu, một hệ quyền) và vs Trino (Trino mạnh federation/mã nguồn mở, DBSQL liền mạch trong hệ Databricks).
• Chi phí tính theo DBU: đòn bẩy là auto-stop ngắn + đúng size/auto-scale + tối ưu truy vấn.