Practice: Working in customer data platforms: Snowflake and Databricks

Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.

Main tool: Databricks · Databricks puts the lakehouse, workspaces, compute, Unity Catalog governance and AI features in one account, so a single free trial workspace lets you practise every part of working inside a customer data platform. · Alternatives: Snowflake (SQL-first warehouse with virtual warehouses as its compute and its own role hierarchy, less notebook and Spark centred), BigQuery (fully serverless warehouse billed per query, no clusters to size), and self-managed Apache Spark with Delta Lake (the same open engine and table format, runnable free on a laptop, but without the managed workspace or Unity Catalog governance).

Every step links into the tool's own documentation; links were checked on 2026-10-11 · version 1

Setup (one time)

1. Sign up for the Databricks free trial from your laptop browser; no local install or GPU is needed, and open source Spark with Delta Lake is the closest fully local substitute if you cannot use a trial.
Databricks is a hosted platform, so the laptop is only the client. The trial gives you a real workspace without a paid cloud commitment.
Explained in: Sign up for Databricks for free | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: You can log in and see the workspace home page with its sidebar.
2. Read the trial limits and note which compute types and features your trial workspace allows.
Customer accounts always come with budgets and restrictions. Knowing the limits first stops you from planning steps the workspace cannot run.
Explained in: Sign up for Databricks for free | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: You have a short note listing the trial duration, credit limit and any restricted features.
3. Start the default SQL warehouse in the workspace so SQL queries have compute to run on.
Nothing runs without compute attached. Starting a warehouse is the first thing you do in any customer workspace before you can look at data.
Explained in: Connect to a SQL warehouse | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: The warehouse shows a running state in the SQL warehouses list.

Steps

1. Create a notebook and load a CSV file into a DataFrame by following the import tutorial.
This is the shortest path to a first successful run. It shows how a notebook, attached compute and a file come together in a workspace.
Explained in: Tutorial: Import and visualize CSV data from a notebook | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: The notebook cell displays rows of the CSV data as a table.
2. Save the DataFrame to a table in a catalog and schema you have write access to.
Tables, not files, are what customers govern and query. Saving one teaches you the three-level name you will use everywhere else.
Explained in: Tutorial: Import and visualize CSV data from a notebook | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: The new table appears in the catalog browser under your chosen catalog and schema.
3. Create a one-page diagram of the lakehouse you just used, marking where storage, compute, the workspace and governance sit.
A forward deployed engineer has to read a customer architecture quickly. Drawing your own workspace makes the storage and compute separation concrete.
Explained in: What is Databricks? | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: Your diagram names the storage layer, the compute you started, the workspace and the catalog, with the table from the previous step placed on it.
4. Configure the size and auto stop of a SQL warehouse, then write a short comparison with Snowflake virtual warehouses, storage and cloud services layers.
Both platforms separate storage from compute but provision compute differently. Sizing one yourself shows where cost comes from and how the two models line up.
Explained in: Connect to a SQL warehouse | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: The warehouse shows your chosen size and auto stop setting, and you have a comparison table with a row each for storage, compute and services.
5. Create a map of the Unity Catalog objects your user can see, from metastore down to catalogs, schemas, tables and the privileges granted on them.
In an account you do not own, what you can do is defined by grants on this hierarchy. Mapping it tells you what to ask the customer admin for.
Explained in: What is Unity Catalog? | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: You have a list of visible catalogs and schemas, with the privilege you hold on at least one table.
6. Query an unfamiliar sample table from a notebook to discover its columns, row counts and likely keys without any documentation.
Customer warehouses are rarely documented. Profiling a table you have never seen is the daily skill for finding the right data.
Explained in: Tutorial: Query and visualize data from a notebook | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: You can state what one row of the table represents and name its main columns from your query results.
7. Run an update on your own table, then query its previous version and compare the two results.
Delta Lake keeps table history, which lets you check what changed and recover from mistakes. That safety net matters when working on customer data.
Explained in: What is Delta Lake in Databricks? | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: Two queries on the same table return different values, one from the current version and one from the earlier version.
8. Run a language model task over rows of your table from inside the workspace, using a built-in AI capability if your trial allows it, or a small CPU model in a notebook if it does not.
Running AI next to the data avoids moving governed data out of the customer account. It is usually the only approach a customer security team will accept.
Explained in: What is Databricks? | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: A query or notebook cell returns your table rows with an added column of model output.
9. Serve the curated table to a consumer by querying it through the SQL warehouse as a downstream dashboard or application would.
The serving layer is where your work meets the customer's analysts and applications. Reading through it confirms the table is usable outside your notebook.
Explained in: What is a data lakehouse? | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: A query run in the SQL editor on the warehouse returns the same curated rows your notebook produced.
10. Create a pipeline and a job that runs it on a schedule by following the ETL pipeline tutorial.
Work that only runs when you click a notebook cell does not survive after you leave the engagement. A scheduled job makes it repeatable.
Explained in: Tutorial: Build an ETL pipeline with Lakeflow pipelines | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: The job shows at least one successful run in its run history.
11. Configure the job compute to use a pinned long term support runtime version, as a production workspace would, and record that version alongside the job.
Runtime upgrades change library and Spark versions underneath your code. Pinning a supported version is what keeps a customer deployment reproducible.
Explained in: Databricks release notes | Databricks on AWS (docs.databricks.com), checked 2026-10-11
Done when: The job configuration shows a specific runtime version that matches an entry in the runtime release notes, and the job reruns successfully on it.

Back to Working in customer data platforms: Snowflake and Databricks