Databricks System Tables for Compute & Job Analytics

Introduction

Trước khi đi sâu vào bài toán cụ thể cũng như cách hiện thực hoá data models và pipelines, tớ nghĩ điều quan trọng đầu tiên là cần hiểu rõ: “hiện tại chúng ta đã có những dữ liệu gì”. Bởi vì khả năng phân tích và thiết kế sau này sẽ phụ thuộc rất nhiều vào granularity và phạm vi thông tin mà source systems cung cấp sẵn.

Khác với nhiều bài toán business analytics thông thường, ta có thể chủ động bổ sung tracking hoặc xây thêm data collection flows. Với Databricks operational metadata, phần lớn dữ liệu phân tích sẽ phải dựa trên những gì Databricks đã expose thông qua system tables.

Databricks hiện đã cung cấp khá nhiều runtime và operational metadata bên trong system catalog. Dù số lượng tables tương đối lớn, trong phạm vi project này tớ sẽ chỉ tập trung vào một số tables quan trọng và thực sự hữu ích cho bài toán compute và job analytics.

Cụ thể, tớ có thể minh hoạ các bảng đó bằng ERD dưới đây:

Các tables được thiết kế để phục vụ runtime systems, state tracking và event logging, thay vì tối ưu cho analytical workloads hoặc business-oriented reporting. Điều đó dẫn tới một số vấn đề phổ biến:

• grain không đồng nhất giữa các tables
• normalized relationships phức tạp
• temporal state tracking khó phân tích
• và việc trả lời các analytical questions thường yêu cầu nhiều joins cùng các transformation bổ sung.

Đó cũng là lý do dimensional modeling trở nên cần thiết trong bài toán này.

Compute Infrastructure & Resource Utilization

Nhóm Compute tables này mô tả phần compute infrastructure ở tầng cluster, node và instance pool. Đây là lớp metadata quan trọng để hiểu platform đang provision compute resources như thế nào, các resources đó được sử dụng ra sao, và lifecycle của từng compute component diễn ra theo thời gian như thế nào.

Về mặt phân tích, nhóm này có thể giúp trả lời các câu hỏi như:

• Cluster sizing có phù hợp với workload thực tế không?
• Compute resources có đang bị over-provision hoặc under-utilize không?
• Autoscaling có hoạt động hiệu quả không?
• Node type hiện tại có phù hợp với workload pattern không?
• Instance pools có thực sự giúp giảm startup overhead và cải thiện resource readiness không?

Các tables trong nhóm này gồm:

Các loại Cluster trên Databricks

• Compute Purpose: Databricks cung cấp nhiều loại compute khác nhau nhằm phục vụ các workload và access patterns riêng biệt. Mỗi loại compute thường có lifecycle, scaling behavior, concurrency model và workload characteristics khác nhau..

  • All-Purpose Compute: Loại compute phục vụ interactive workloads như notebooks, exploratory analysis hoặc collaborative development. Những clusters này thường có lifecycle dài hơn jobs compute và đôi khi được shared giữa nhiều users hoặc workloads khác nhau.
  • Jobs Compute: Loại compute được tạo riêng cho scheduled jobs hoặc pipelines. Cluster thường được khởi tạo khi job bắt đầu và tự terminate sau khi workload hoàn thành.
  • SQL Warehouse: Compute chuyên biệt cho SQL workloads và BI analytics. Loại compute này được tối ưu cho query execution, dashboard workloads và concurrency cao.

• Deployment Model: Ngoài workload purpose, Databricks còn hỗ trợ nhiều deployment models khác nhau cho compute infrastructure.

  • Classic Compute: Users vẫn trực tiếp quản lý cluster configurations node types, autoscaling, instance pools, runtime versions, networking hoặc cloud-specific settings.
  • Serverless Compute: Databricks quản lý toàn bộ compute infrastructure phía dưới. Users không cần trực tiếp quản lý clusters, VM provisioning hoặc autoscaling behavior.

  Một số workloads như Jobs Compute hoặc SQL Warehouse có thể chạy cả dưới dạng serverless và classic compute. Tuy nhiên, telemetry visibility và operational metadata của serverless thường sẽ hạn chế hơn so với classic compute.

Hiểu rõ các loại compute này khá quan trọng trong operational analytics, bởi mỗi loại thường có workload pattern riêng, scaling behavior riêng, cost profile khác nhau và metadata characteristics khác nhau trong system tables.

State machine của instance

Databricks Instance Pools

Databricks Instance Pools là cơ chế duy trì một tập các compute instances ở trạng thái idle nhưng đã được provision sẵn và sẵn sàng sử dụng. Thay vì mỗi lần cluster khởi tạo đều phải request và boot mới VM từ cloud provider, Databricks có thể tái sử dụng ngay các instances đang nằm trong pool. Điều này giúp giảm đáng kể cluster startup time cũng như autoscaling latency, đặc biệt với các workloads thường xuyên scale up/down hoặc có thời gian chạy ngắn như jobs compute. Khi cluster cần thêm nodes:

• Nếu pool còn idle instances, cluster sẽ attach trực tiếp các instances đó.
• Nếu pool không đủ capacity, Databricks sẽ tiếp tục provision thêm instances mới từ cloud provider để mở rộng pool.

Ngược lại, khi cluster terminate hoặc scale down, instances sẽ không bị huỷ ngay mà được trả về pool để chờ tái sử dụng cho các clusters khác. Chỉ những clusters được cấu hình sử dụng cùng instance pool mới có thể reuse các idle instances trong pool đó.

Điều này đồng nghĩa instance pool thực chất là một lớp shared warm capacity nằm giữa Databricks control plane và cloud provider infrastructure. Pool càng giữ nhiều idle instances thì cluster startup càng nhanh, nhưng đổi lại cloud cost nền cũng sẽ tăng lên ngay cả khi chưa có workload chạy.

Databricks cũng cho phép cấu hình capacity và idle behavior của instance pools nhằm cân bằng giữa startup latency và infrastructure cost. Một số cấu hình như: min_idle_instances, max_capacity, idle_instance_autotermination_minutes, preloaded_spark_version đều được expose trực tiếp bên trong system.compute.instance_pools.

Điều này giúp các bài toán operational analytics không chỉ dừng lại ở việc quan sát runtime behavior, mà còn có thể đối chiếu ngược lại với pool configuration để phân tích startup overhead, pool sizing hoặc idle resource efficiency.

Job Execution & Workload Behavior

Nếu nhóm compute tables tập trung vào infrastructure lifecycle và resource utilization, thì nhóm Jobs tables lại mô tả execution behavior của workloads phía trên lớp compute đó. Các tables trong nhóm này chủ yếu phục vụ workload observability, pipeline reliability analytics, SLA/SLO monitoring, retry & failure analysis, queueing analysis, compute attribution, workload cost attribution cũng như execution performance optimization.

Execution Timeline Semantics

Databricks model execution telemetry dưới dạng timeline slices thay vì kiểu truyền thống “1 row cho mỗi run”. Mỗi execution đang chạy sẽ liên tục được cắt thành các khoảng thời gian (period_start_time -> period_end_time) nhằm phản ánh trạng thái runtime theo thời gian thực.

Thiết kế này phù hợp hơn với runtime observability, execution monitoring, temporal analytics hoặc append-only telemetry systems thay vì transactional analytics truyền thống. Đây cũng là một trong những lý do mặc dù các bảng source có relationships tương đối giống star schema nhưng vẫn cần modeling lại vì mục tiêu cuối cùng của tớ là analysis và report.

Duration Breakdown Semantics

Một điểm khá thú vị là Databricks không chỉ expose tổng execution duration, mà còn tách riêng từng phase trong lifecycle của workload như queue_duration_seconds, setup_duration_seconds, execution_duration_seconds hoặc cleanup_duration_seconds. Điều này giúp phân biệt rõ queue bottlenecks, cluster startup overhead, environment setup time, actual business execution time hay teardown overhead, thay vì chỉ nhìn vào tổng runtime như các schedulers truyền thống.

SQL Warehouse & Query Analytics

Nhóm SQL Warehouse tables này mô tả query execution behavior và warehouse scaling telemetry phía dưới SQL workloads. Đây là lớp metadata quan trọng để phân tích query latency, warehouse saturation, autoscaling responsiveness, concurrency bottlenecks cũng như BI workload patterns trên Databricks SQL.

Các bảng này không chỉ expose tổng query duration, mà còn tách riêng từng loại waiting durations như waiting_for_compute_duration_ms hoặc waiting_at_capacity_duration_ms.

Trong thực tế, waiting_for_compute_duration_ms thường phản ánh warehouse cold-start hoặc autoscaling delay, trong khi waiting_at_capacity_duration_ms lại phản ánh concurrency saturation hoặc warehouse sizing chưa phù hợp với workload thực tế.

Mặc dù trong thực tế queries trong system.query.history không chỉ được execute thông qua SQL Warehouses, mà có thể đến từ nhiều sources khác nhau như dashboards, jobs, notebooks, alerts hoặc external BI tools thông qua Databricks SQL và có thể chạy trực tiếp trên all-purpose compute thay vì warehouse-backed compute

Billing & Cost Attribution

Nhóm Billing tables này mô tả usage telemetry và pricing metadata phía dưới compute workloads trên Databricks. Đây là lớp metadata quan trọng để thực hiện cost attribution, usage analysis, chargeback/showback hoặc cost optimization cho jobs, warehouses, clusters và instance pools.

Trong phạm vi bài toán hiện tại, nhóm billing tables chủ yếu đóng vai trò như lớp metadata phụ trợ cho cost attribution và operational analysis, thay vì trở thành analytical domain chính. Phần lớn trọng tâm của tớ vẫn nằm ở execution telemetry, workload behavior và compute utilization nhiều hơn là financial reporting hoặc billing analytics thuần túy.

Ngoài ra, schema của system.billing.usage thực tế cũng khá phức tạp và chứa rất nhiều loại usage records, billing dimensions cũng như attribution metadata khác nhau phía bên trong. Nhiều fields mang tính internal billing semantics nhiều hơn là operational semantics, nên ở thời điểm hiện tại tớ vẫn chưa thực sự chắc sẽ tận dụng được bao nhiêu thông tin từ nhóm tables này cho bài toán analysis phía trên.