Skippr Docs

Appearance

How to Explain Databricks Tables to Analysts ​

July 2026

Analysts should think of Skippr Databricks tables as current-state Unity Catalog tables, not as a folder of Parquet uploads or a stream of raw change events.

Short Answer ​

Explain Databricks tables as current-state Delta tables that live in the configured Unity Catalog catalog and schema. Skippr may upload Parquet files through the Files API and optionally use COPY INTO, but analysts should treat the resulting table as an ordinary Databricks table where each business key resolves to the latest row after the CDC MERGE completes.

That means a table such as main.default.orders should be described in row terms, not file terms. One row is the latest raw order record. If an order changes status from pending to shipped, analysts should expect the table to show the shipped row once the load finishes, while _skippr_order_token and tombstone handling stay in the background as correctness infrastructure.

Why Teams Struggle with This ​

Databricks often arrives with a lot of platform vocabulary, which can distract from what analysts actually need. The catalog, schema, warehouse ID, and token matter operationally, but the analyst question is still what one row means and when that row is current.

  • The analyst-facing surface is the Unity Catalog table, not the temporary Parquet files used during loading.
  • A CDC-managed table is usually current state per key, not a full event history of every mutation.
  • The optional warehouse_id affects how loads run, but it does not change the meaning of the resulting table rows.
  • The _skippr_order_token column is an operational field and should rarely be modeled as a business attribute.

How Skippr Handles It ​

Skippr helps here because the Databricks destination is explicit about where data lands: workspace, optional SQL warehouse, catalog, and schema. Analysts can be told exactly where the raw tables live, while engineering retains the loading controls it needs.

The CDC semantics are also simple to summarize. Skippr uses Unity Catalog MERGE with order-token guards and tombstones, so the everyday analyst model can stay focused on latest rows in a Delta table.

  • Loads Databricks through Parquet uploads and optional COPY INTO.
  • Targets a specific Unity Catalog catalog and schema.
  • Uses MERGE for exactly-once final-state CDC reconciliation.
  • Automatically creates _skippr_order_token columns and tombstone tables.

What the First Useful Version Looks Like ​

The first useful explanation is one table in one catalog and schema with a known key. Show analysts where it lives, what one row represents, and which columns are business-facing versus system-managed.

If the team later builds history or marts, keep that distinction clear. The Skippr raw Databricks table is strongest when it stays the dependable current-state input to those downstream layers.