Designing Dimensions for Runtime Analytics

Introduction

Dimension design đi sau business process và grain. Nếu grain trả lời câu hỏi “một row đại diện cho điều gì”, thì dimensions lại trả lời câu hỏi “người dùng sẽ muốn filter, group, compare hoặc aggregate fact này theo context nào”. Nếu nhìn về bản chất gốc của Kimball techniques, phần lớn bài toán dimensional modeling thực ra đều xoay quanh việc trả lời các câu hỏi quen thuộc như what, when, where hoặc who.

Tuy nhiên, cách đặt những câu hỏi này sẽ thay đổi tuỳ theo bối cảnh thực tế của từng hệ thống. Ví dụ trong operational analytics:

• Workload nào đang chạy?
• Cluster hoặc warehouse nào đang được sử dụng?
• Job đó chạy vào thời điểm nào?
• Workload đang chạy trên workspace, node type hoặc instance pool nào?
• Ai là người trigger job hoặc thực hiện query đó?

Tất cả những yếu tố này khi kết hợp lại sẽ tạo thành execution context để diễn giải các runtime facts phía dưới.

Và nhiệm vụ của dimension design chính là xây dựng các dimensions đủ bao quát để mô tả toàn bộ context đó một cách nhất quán. Điều này cũng giúp tránh việc phải lặp lại cùng một metadata hoặc execution context trên quá nhiều fact tables khác nhau. Thay vì mỗi fact tự mang toàn bộ thông tin về workload, compute, workspace hoặc execution source, các dimensions sẽ đóng vai trò central context layer để nhiều facts có thể reuse, drill-across hoặc correlate với nhau dễ dàng hơn.

Về bản chất, đây cũng chính là một trong những tư tưởng cốt lõi mà Kimball techniques luôn hướng tới: xây dựng các dimensions đủ ổn định, đủ reusable và đủ extensible để nhiều business processes hoặc analytical workloads khác nhau có thể cùng chia sẻ chung một analytical context layer thay vì liên tục tái định nghĩa cùng một context ở nhiều nơi khác nhau.

Và khi nhìn vào context trong bài toán này, tớ tạm thời chia các dimension vào các nhóm mà sẽ được đi chi tiết vào từng nhóm ở phần sau:

• Time dimensions
• Organization and execution dimensions
• Workload dimensions
• Compute dimensions
• Lifecycle and taxonomy dimensions
• Generic support dimensions

Design Principles

Trước khi đi vào chi tiết từng nhóm dimension cụ thể, tớ nghĩ nên chuẩn bị trước một số nguyên tắc, hoặc nhớ lại một số kĩ thuật mà nên áp dụng:

1. Conformed Dimensions: Một số dimensions như workspace, datetime bucket hoặc compute resource sẽ được reuse giữa nhiều facts khác nhau. Điều này giúp các reports hoặc dashboards có thể drill-across giữa job executions, query workloads, pool utilization hoặc warehouse operations một cách nhất quán hơn.
2. Slowly Changing Dimensions: Nhiều resource configurations trong Databricks thực tế có thể thay đổi liên tục theo thời gian như cluster configs, warehouse settings, autoscaling ranges, attached pools hoặc DBR/runtime versions. Những thay đổi này ảnh hưởng trực tiếp tới cách diễn giải historical facts phía sau. Vì vậy, phần lớn infrastructure hay resource dimensions trong model này sẽ phù hợp hơn với SCD Type 2. Thực tế, chính Databricks cũng đang expose nhiều resource metadata tables dưới dạng temporal history thay vì current-state snapshots thuần túy. Các tables như system.compute.clusters, system.compute.instance_pools, system.compute.warehouses hoặc system.lakeflow.jobs đều lưu lại configuration history theo thời gian thông qua các fields như change_time hoặc delete_time. Điều này sẽ dễ dàng hơn cho chúng ta khi apply trực tiếp.
3. Degenerate Dimensions: Một số identifiers như run_id, statement_id hoặc update_id vẫn sẽ được giữ trực tiếp bên trong fact tables dưới dạng degenerate dimensions nhằm hỗ trợ debugging, traceability hoặc drill-through về raw execution telemetry.
4. Generic vs Specialized Dimensions: Mặc dù có thể xây dựng một generic dim_compute_resource để unify clusters, warehouses hoặc pools dưới cùng một abstraction, nhưng phần lớn analytical use cases thực tế vẫn cần các specialized dimensions riêng cho jobs, tasks, warehouses, clusters hoặc node types để giữ được execution semantics và operational context chi tiết hơn.
5. Bridge Tables: Một số execution facts có thể liên kết tới nhiều compute resources cùng lúc, đặc biệt với các fields như compute_ids. Trong các trường hợp này, bridge tables sẽ phù hợp hơn việc cố nhét nhiều resource keys trực tiếp vào fact table, đồng thời giúp model giữ được flexibility cho các bài toán cross-resource analysis phía sau.

Time Dimensions

Time dimensions gần như luôn là một trong những nhóm dimensions quan trọng nhất trong operational analytics vì phần lớn execution telemetry phía dưới đều mang tính time-series và workload behaviors thường có tính chu kỳ theo thời gian.

Trong thực tế, workloads thường không chạy hoàn toàn ngẫu nhiên mà có xu hướng bám theo business schedules, batch windows hoặc operational patterns cố định như đầu ngày làm việc, cuối ngày, nightly ETL windows, cuối tháng hoặc cuối tuần. Điều này khiến context về thời gian trở thành một analytical dimension gần như bắt buộc nếu muốn phân tích runtime behaviors, contention patterns hoặc workload trends một cách nhất quán hơn.

Nhóm dimensions này trong model hiện tại bao gồm:

• dim_date
• dim_time
• dim_datetime_bucket

dim_date

dim_date chủ yếu phục vụ các bài toán phân tích theo ngày, tuần hoặc seasonality patterns. Trong thực tế, rất nhiều workloads được schedule theo daily hoặc weekly cadence, khiến các attributes như weekday, weekend, workday, month-end hoặc holiday trở nên khá quan trọng khi phân tích workload behaviors hoặc runtime changes theo thời gian. Dimension này thường sẽ mang các calendar attributes quen thuộc như:

• year, quarter, month, week
• weekday hoặc weekend
• workday hoặc holiday
• month-end hoặc quarter-end flags

Các attributes này giúp việc aggregate hoặc so sánh workload behaviors theo calendar patterns tự nhiên hơn thay vì phải repeatedly derive từ raw timestamps ở nhiều nơi khác nhau.

dim_time

Trong khi đó, dim_time lại tập trung nhiều hơn vào time-of-day patterns. Các workloads thường có xu hướng bám theo business behaviors như đầu ngày làm việc, cuối ngày, nightly ETL windows hoặc business hours. Vì vậy, ngoài hour hoặc minute cơ bản, dimension này thường sẽ bổ sung thêm các semantic groupings như business hours, overnight periods, daypart hoặc peak windows để giúp việc aggregate và phân tích operational patterns phía trên tự nhiên hơn.

Dimension này thường sẽ chứa các contexts như:

• hour hoặc minute trong ngày
• business hours hoặc overnight periods
• morning, afternoon, evening hoặc midnight windows
• peak hoặc off-peak periods

Những groupings này khá hữu ích khi phân tích runtime degradation, contention windows hoặc workload behaviors theo thời điểm trong ngày.

dim_datetime_bucket

Ngoài ra, model cũng cần thêm dim_datetime_bucket như một abstraction layer cho các bài toán concurrency hoặc contention analysis. Về bản chất, execution telemetry là time-series liên tục, nhưng việc phân tích trực tiếp trên raw timestamps thường không hiệu quả cho reporting hoặc aggregation.

Vì vậy, timestamps sẽ được gom vào các fixed-size buckets như 5 phút, 15 phút hoặc 1 giờ để giúp xử lý các bài toán như workload overlap, peak windows, concurrency spikes hoặc batch contention dễ dàng và tối ưu hơn cho analytical queries phía trên.

Dimension này thường sẽ mô tả:

• bucket start/end timestamps
• bucket size
• hour-level hoặc day-level grouping
• timezone context nếu cần

Điều này giúp nhiều facts khác nhau có thể được aggregate hoặc correlate theo cùng một time window thay vì phải xử lý raw timestamp alignment trực tiếp trong từng query riêng lẻ.

Organization, Actor and Taxonomy Dimensions

Nhóm dimensions này mô tả các context mang tính tổ chức, định danh và phân loại chung cho workload hoặc compute resources.

Nói đơn giản hơn, nhóm này giúp trả lời các câu hỏi như: workload thuộc workspace nào, resource tổng quát là gì, ai là người tạo hoặc trigger workload, và event/status phía dưới nên được hiểu theo trạng thái nào.

Trong model này, nhóm này bao gồm:

• dim_workspace dùng để xác định workload hoặc resource thuộc workspace nào. Đây là context gần như xuất hiện ở tất cả facts vì hầu hết Databricks resources đều được scoped theo workspace.
• dim_compute_resource đóng vai trò là một logical resource dimension tổng quát, giúp unify các loại resources như job, task, cluster, warehouse, instance pool hoặc node dưới cùng một lớp định danh chung. Dimension này không thay thế các specialized dimensions như dim_cluster, dim_warehouse hoặc dim_instance_pool, mà chủ yếu phục vụ cross-resource navigation, inventory-style reporting hoặc recommendation layer phía sau.
• dim_principal dùng để mô tả actor hoặc execution identity, ví dụ user hoặc service principal tạo job, trigger workload, execute query hoặc được gắn với billing usage.
• dim_event_type dùng để normalize các event/status/lifecycle semantics như running, terminated, failed, idle, active hoặc capacity-related states để nhiều facts có thể filter/group theo cùng một cách hiểu.

Tuy nhiên, với MVP hiện tại, tớ chưa ưu tiên build đầy đủ toàn bộ nhóm dimensions này thành các bảng vật lý riêng, dù về mặt dimensional modeling thì chúng hoàn toàn hợp lý và vẫn nên được liệt kê rõ trong design. Lý do chủ yếu là tradeoff giữa modeling completeness và tốc độ launch MVP.

Thực tế, phần lớn analytical use cases hiện tại vẫn có thể hoạt động tốt chỉ bằng các surrogate-style keys, normalized keys hoặc raw identifiers được giữ trực tiếp trong facts dưới dạng degenerate dimensions. Đồng thời, natural keys của các entities này cũng thường khá ổn định. Ví dụ user/service principal trong Databricks đã có định danh riêng, còn event type/status cũng chủ yếu là các giá trị hệ thống tương đối cố định.

Điều này giúp model hiện tại vẫn giữ được extensibility phía sau mà chưa cần overbuild ownership hoặc taxonomy layers quá sớm. Sau này, nếu bắt đầu xuất hiện nhu cầu rõ ràng hơn về ownership analysis, recommendation routing, reusable lifecycle taxonomy hoặc cross-resource governance/reporting, các dimensions như dim_principal hoặc dim_event_type hoàn toàn có thể được materialize đầy đủ hơn mà không cần thay đổi lại grain hoặc core fact structures phía dưới.

Compute Dimensions

Nhóm dimensions này mô tả runtime environment mà workloads thực tế đang chạy trên đó. Trong operational analytics, đây thường là một trong những nhóm dimensions quan trọng nhất vì phần lớn runtime behaviors, startup latency, contention hoặc utilization patterns đều bị ảnh hưởng trực tiếp bởi compute configurations phía dưới.

Nói cách khác compute dimensions sẽ giúp trả lời “workload đang chạy trên môi trường nào”. Trong model này, nhóm compute dimensions bao gồm:

• dim_cluster
• dim_instance_pool
• dim_node_type
• dim_warehouse

dim_cluster

dim_cluster mô tả execution environment của workloads chạy trên Databricks clusters, bao gồm cả all-purpose clusters và job clusters. Đây là một trong những compute dimensions quan trọng nhất vì nhiều runtime behaviors phía dưới chỉ có thể được diễn giải đúng khi biết workload đã chạy trên cluster configuration nào tại thời điểm đó.

Ví dụ, cùng một job run nhưng runtime, startup latency hoặc failure pattern có thể thay đổi đáng kể nếu cluster chuyển sang node type khác, đổi DBR version, thay đổi autoscaling range, attach vào instance pool khác hoặc chạy dưới một cluster policy khác.

Vì vậy, dim_cluster được model dưới dạng SCD Type 2 dimension, với grain là một row cho mỗi cluster config version. Mỗi lần cluster configuration thay đổi, model tạo một version mới để các facts như job run, task run, instance lifecycle hoặc node utilization có thể join về đúng cluster context tại thời điểm event xảy ra.

Ở mức high-level, dimension này cần capture một số nhóm attributes chính:

• cluster identity: cluster id, cluster name, owner, workspace
• compute shape: driver/worker node type, worker count, autoscaling range
• runtime configuration: DBR version, security mode, policy, auto-termination, elastic disk
• pool attachment: driver/worker instance pool ids
• cloud-specific attributes: availability, spot/on-demand strategy hoặc cloud provider settings
• lifecycle metadata: create time, delete time, effective start/end timestamps, current flag

dim_instance_pool

dim_node_type

dim_warehouse

Workload dimensions

dim_job

dim_job_task

dim_pipeline

Bridge tables

bridge_job_task_dependency

bridge_task_run_compute