What's changed: Deepened DP-600 Chapter 1 (ja figures; comparison tables/scenarios/FAQ/traps/deep paragraphs in all sections)
1.1Planning Analytics Solutions and Fabric Setup
Understand Microsoft Fabric from an analytics-engineer view, plus workspaces/capacity and planning analytics solutions (requirements → store choice → serving). The starting point for DP-600.
Analytics engineers shape raw data into analysis-ready forms (semantic models, report-ready) and serve it. Fabric supports the whole flow in one SaaS.
1.1.1Fabric and planning essentials
- Capacity/workspace: capacity (F SKUs) provides compute; workspaces manage items and access.
- Store choice: Lakehouse for Spark/files, Warehouse for T-SQL DW.
- Serving: build a semantic model for analysis and read via Direct Lake in Power BI.
- Planning: design in order—requirements (freshness/scale/SQL vs Spark) → store → serving method.
Common on DP-600: Fabric is unified SaaS (capacity → workspace → items), Spark/files = Lakehouse, T-SQL DW = Warehouse, analytics serving = semantic model + Direct Lake, plan: requirements → store → serving. "Prepare and serve data" is the largest domain.
DP-600 shares the platform (Fabric/OneLake) with DP-700 (data engineer) but emphasizes semantic models and Power BI serving.
The analytics engineer’s central artifact is the semantic model (formerly dataset). You ingest and shape raw data in a Lakehouse/Warehouse (the medallion gold layer), then build an analysis-oriented meaning model on top, consumed in Power BI. Plan in order: “requirements (freshness, scale, SQL vs Spark, concurrency, cost) → store choice (Spark/files = Lakehouse, T-SQL DW = Warehouse) → serving method (Direct Lake/import/DirectQuery).” Fabric is a unified SaaS where items (Lakehouse/Warehouse/semantic model/report/notebook/pipeline) sit in workspaces on a capacity (F SKU, CU), all sharing OneLake. By requirement, choose Real-Time Intelligence for real-time, Dataflows Gen2 for no-code shaping, or Spark for large transforms. DP-600’s largest domain is “prepare and serve data,” and the serving layer’s (semantic model/Direct Lake) design quality drives report performance.
| Planning step | What you decide | Example |
|---|---|---|
| Requirements | Freshness, scale, SQL/Spark, cost | Near-real-time / large batch |
| Store choice | Lakehouse vs Warehouse | Spark=Lakehouse, T-SQL=Warehouse |
| Serving method | Direct Lake / import / DirectQuery | Freshness + speed = Direct Lake |
Scenario: shape large data with Spark and show fresh data fast in Power BI. → From requirements (large, fresh, fast), choose a Lakehouse, build gold-layer Delta tables with Spark, and configure a Direct Lake semantic model for fast Power BI reads. If a T-SQL DW requirement dominates, choose a Warehouse.
FAQ: Q. DP-600 vs DP-700? → A. Same platform (Fabric/OneLake), but DP-700 leans data engineering (ingest/transform/ops) and DP-600 leans analytics serving (semantic models, DAX, Power BI). Q. Lakehouse vs Warehouse? → A. Lakehouse for Spark/files/data science; Warehouse for read-write T-SQL DW.
Trap: “decide the serving method first, then the store” is wrong—plan requirements → store → serving. Also “DP-600 means configuring infrastructure (VM/OS) yourself” is wrong—Fabric is SaaS; assign capacity and use items.
1.1.2Section summary
- Fabric = capacity → workspace → items (shared OneLake)
- Plan = requirements → store (Lakehouse/Warehouse) → serving (semantic model/Direct Lake)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which Microsoft platform handles the whole analytics flow (prepare, serve, model, report) in one SaaS?
Q2. You want a T-SQL-centric data warehouse. Which Fabric store?
Q3. What is the correct order for planning an analytics solution?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.