Interactive Databricks interview questions on SQL Warehouses: compute shaped for BI. Practice with the matching lesson. Serverless vs Pro vs Classic, the caches behind a fast dashboard, and why size and cluster count are different dials.
Question 1 of 4
The BI team wants to point Tableau at Databricks. Why hand them a SQL warehouse instead of the cluster they already have access to?
Answer it out loud, then reveal. Play steps through like the simulators.
Case 1 of 2 · symptoms
Symptoms
Indexed as FAQ. Open any item if you prefer a list to Play.
The BI team wants to point Tableau at Databricks. Why hand them a SQL warehouse instead of the cluster they already have access to?
SQL Warehouses: compute shaped for BI · tap to open the answer
Short: A warehouse is a SQL endpoint built for many short concurrent queries: Photon on by default, result caching, auto-stop, and extra clusters when concurrency rises.
Detailed: An all-purpose cluster runs notebooks and BI inside the same Spark application, so one runaway cell starves the dashboard and there is no per-query profile for the analyst. A warehouse gives JDBC/ODBC endpoints, Query History with a profile per statement, and scale-out for concurrency instead of fighting notebooks for slots.
Common mistake: Handing BI the JDBC URL of the team's interactive cluster because it is already warm.
Follow-up: Classic, Pro, or Serverless — which would you pick and what changes?
One analyst is fine, but at 9am with forty people the dashboards crawl. Do you bump the T-shirt size?
SQL Warehouses: compute shaped for BI · tap to open the answer
Short: No — size is scale-up for one query's horsepower; concurrency needs more clusters, so raise max clusters.
Detailed: Cluster size (2X-Small through 4X-Large) decides how much compute a single query can use; min/max clusters decides how many queries run in parallel before they queue. If Query History shows long queue time against short execution time, it is a concurrency problem, and upsizing just makes each idle cluster more expensive.
Common mistake: Jumping from Small to 2X-Large, watching the bill grow, and finding the queue still there.
Follow-up: Where in Query History do you separate queue time from execution time?
Finance says the SQL warehouse bill tripled but query volume is flat. Where do you look?
SQL Warehouses: compute shaped for BI · tap to open the answer
Short: At uptime, not queries: auto-stop disabled, min clusters pinned above 1, a warehouse left running, or someone changed the size or type.
Detailed: Warehouses bill DBUs for the time they are up, so an idle warehouse with no auto-stop bills all night for zero queries. Chart warehouse DBUs from system.billing.usage next to query counts per warehouse, then check the warehouse settings for auto-stop, min clusters, size, and a Classic-to-Pro or Serverless switch.
Senior: Uptime × size × SKU is the bill; query count is not in that formula. Flat query volume with rising DBU hours means idle time, so the fix is auto-stop plus min clusters back to 1 — not a smaller size that makes every real query slower. Serverless changes the tradeoff because startup is seconds, so aggressive auto-stop stops being painful.
Common mistake: Opening the query profile of the slowest statement — the queries did not change, the running hours did.
Follow-up: What auto-stop value would you set for a 9-to-6 BI workload, and what breaks if it is too aggressive?
The same dashboard query took 3 seconds yesterday afternoon and 90 seconds after the overnight load. The SQL is identical. Explain it.
SQL Warehouses: compute shaped for BI · tap to open the answer
Short: The result cache was invalidated by the new table version and the warehouse's local disk cache is cold for the new files, so the first run pays a full read.
Detailed: Databricks serves byte-identical queries from a result cache, and that cache is invalidated when the underlying Delta table commits a new version. Below it, each warehouse cluster keeps a local SSD disk cache of Parquet it has already read, which is also empty after auto-stop, a restart, or a rewrite by OPTIMIZE — and if the load produced many small files, that cold read is expensive on top.
Senior: Three caches with different lifetimes: the result cache (per identical query, killed by a new table version), the disk cache on the cluster's local SSDs (killed by restart or auto-stop), and Spark's in-memory cache that BI never touches. I would warm it deliberately with a small scheduled job that runs the top dashboard queries right after the load commits, and keep gold compacted so the cold read is cheap when it does happen.
Common mistake: Blaming Photon or asking for a bigger warehouse when the first query after every load is simply uncached.
Follow-up: How would you make 9am fast without keeping the warehouse hot all night?
