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?