Pull-quote: “Governance that the team can’t navigate is governance that the team will route around.”

Why this matters

Most data-governance projects fail because they start with policy. The good ones start with structure. Unity Catalog’s hierarchy (Catalog → Schema → Table) is the structural foundation that makes policy enforceable.

Reference layout (data-mesh)

catalog: zorost
├── domain_aviation
│   ├── flights_silver
│   ├── delays_gold
│   └── safety_rag
├── domain_manufacturing
│   ├── spc_silver
│   └── capability_gold
├── domain_freight
│   ├── corridors_silver
│   └── emissions_gold
├── domain_finance
│   └── ...
└── domain_governance       ← cross-cutting
    ├── audit_logs
    ├── pii_register
    └── data_quality_metrics

Permission model

Row and column security with dynamic views

Unity Catalog supports dynamic views — views whose behavior depends on the current user. A typical pattern:

CREATE VIEW domain_aviation.flights_secure AS
SELECT
  flight_id,
  origin_airport,
  destination_airport,
  CASE WHEN is_member('phi_authorized') THEN passenger_count ELSE NULL END
    AS passenger_count,
  ...
FROM domain_aviation.flights_silver
WHERE
  CASE
    WHEN is_member('all_regions') THEN TRUE
    ELSE region IN (SELECT region FROM domain_governance.user_region_grants
                     WHERE user = current_user())
  END;

is_member(), current_user(), mask(), and filter() together cover row-level, column-level, and full-fledged ABAC patterns.

Tags and classification

Every column and table can carry tags. We standardize a tag taxonomy:

Tags make policy queryable: “show me all PII-tagged columns in domain_finance” returns a row, not an email thread.

Lineage and audit

Unity Catalog captures column-level lineage across SQL, Python, ML, and BI consumption. Audit logs go to a sink the security team owns. Both are queryable via system.access.audit and system.lineage.column_lineage.

Closing

Governance done right starts with structure. Unity Catalog’s hierarchy + permission model + tagging + dynamic views + lineage + audit are the primitives. The implementation is workshop-driven, but the building blocks are stable and the patterns are reproducible.

The post Unity Catalog: Governance Done Right 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.