Pull-quote: “Cost optimization is not a one-time project. It’s a recurring discipline. The tooling is there. The discipline is the ask.”

Why this matters

Most Databricks deployments have 30–60% slack in their spend within twelve months of go-live. Some of it is unavoidable (early-stage discovery). Some of it is technical (file layout, cluster sizing). Most of it is organizational (no cost ownership, no tagging, no review cadence).

Where the real savings are

Ranges are typical for engagements where the team has not previously focused on cost. Mature deployments have less to find.

Tagging and ownership — the prerequisite

Without tagging, you can’t optimize. Required tags:

• cost_center
• environment (dev / stage / prod)
• owner (team or person)
• workload (training / serving / ETL / BI / ad-hoc)

These flow into the system tables for cost reporting (system.billing.usage).

The audit, in twelve hours

A typical audit takes about twelve hours of senior engineering time:

1. Pull system.billing.usage for the last 90 days, joined with cluster metadata
2. Identify the top 10 jobs by cost
3. For each, evaluate: is the cluster the right type? Is autoscaling tuned? Are files compacted? Is the workload running at the right cadence?
4. Identify candidates for serverless migration
5. Identify candidates for materialized view replacement
6. Produce a prioritized list with estimated savings

Most teams find five to ten actions that together deliver 20–40% savings.

Common findings

• A nightly batch job using a high-end cluster size when a Photon-enabled smaller cluster would do
• A streaming pipeline running with a cluster sized for peak when traffic is bimodal
• A Power BI model importing 80% of data that nobody queries
• A SELECT * materialized in a downstream view, doubling storage cost on a hot dataset
• An ad-hoc cluster left running over a weekend

Cost ownership cadence

The discipline that holds savings: monthly cost review with the data leadership and the FinOps lead. Each owner explains anomalies. Tags get fixed. Wasteful patterns get retired.

Closing

Cost optimization on Databricks is not a one-time project. It is a recurring discipline backed by tagging, system tables, and a monthly review. The platform tooling is there. The discipline is the ask.

The post Databricks Cost Optimization & Finops: Where the Real Savings Are appeared first on Zorost Intelligence | AI, Cloud & Data Experts.

Pull-quote: “The RPD is not a black box. It is a graph of joins, hierarchies, and security predicates. Treat it that way and migration becomes tractable.”

Why this matters

Oracle BI EE is one of the most widely deployed enterprise BI platforms. It also has accumulated technical debt — schema drift, layered RPDs, undocumented session variables, and report logic split between the BMM and the report itself. Most “migration” projects start by trying to lift-and-shift everything, get blocked, and stall.

The right approach is methodological. The RPD is treatable as three layers, each of which has a clean Databricks SQL equivalent.

The three-layer translation

   OBIEE                                Databricks
   ─────                                ──────────
   Physical layer    ─────►  Delta Lake tables in Unity Catalog
                              + Lakehouse Federation for live sources

   BMM (logical)     ─────►  Databricks SQL semantic model
                              (Lakehouse views with row/column security)

   Presentation      ─────►  Power BI / Tableau on Databricks SQL
                              (dimensions, measures, time intelligence)

Migration sequence

Security translation

Common pitfalls

• Trying to lift-and-shift the BMM. Some logic in the BMM is workaround for OBIEE limitations. Rebuild as Lakehouse views; don’t translate one-for-one.
• Skipping usage telemetry. Half the reports in a typical OBIEE deployment are unused. Don’t migrate them.
• Translating session variables literally. Most session variables become dynamic-view predicates or IDP claims.
• Building the semantic model in Power BI instead of Databricks SQL. Power BI imports work in the short term and create future modernization debt. Direct Lake is the target.

Closing

The OBIEE → Databricks migration pattern is reproducible when you treat the RPD as a graph of joins, hierarchies, and security predicates rather than as a black box. The result is a cleaner semantic model on a platform that supports SQL, ML, streaming, and agentic AI — instead of a single-purpose BI server.

The post OBIEE to Databricks: a Practical Migration Pattern appeared first on Zorost Intelligence | AI, Cloud & Data Experts.