What's changed: Deepened DP-600 Chapter 3 (ja figures; comparison tables/scenarios/FAQ/traps/deep paragraphs in all sections)
3.2Exploring and Analyzing Data
Understand ways to explore/analyze data—DAX queries, T-SQL, KQL, Power BI visual exploration, and performance troubleshooting (Performance Analyzer, DAX Studio).
After modeling, you explore/analyze data with queries and visuals, choosing DAX/T-SQL/KQL by use, and diagnosing slowness when needed.
3.2.1Explore, analyze, and tune
- Choosing query languages: DAX (model), T-SQL (SQL endpoint/Warehouse), KQL (Real-Time).
- Visual exploration: analyze interactively in Power BI with charts/slicers/drilldown.
- Performance Analyzer: measures per-visual timings in a report to find slow spots.
- DAX Studio, etc.: analyze/optimize DAX queries and isolate storage vs formula engine issues.
Common on DP-600: model calc/query = DAX, SQL analysis = T-SQL (SQL analytics endpoint), streaming = KQL, visual slowness diagnosis = Performance Analyzer, DAX optimization = DAX Studio. For slow reports, measure with Performance Analyzer first.
Performance issues are improved by a mix of model design (star schema/measures), Delta optimization (V-Order/OPTIMIZE), and storage mode (Direct Lake).
Choose query languages by purpose: DAX for model aggregations (EVALUATE for DAX queries), T-SQL (SQL analytics endpoint) for tabular analysis of Lakehouse/Warehouse, and KQL (Real-Time Intelligence/Eventhouse) for streaming/logs. For ad-hoc work, Power BI’s visual exploration (slicers, drilldown, “Analyze” AI) and quick measures help. To troubleshoot performance, first measure per-visual DAX query time / visual display / other with Performance Analyzer, analyze slow DAX with DAX Studio/Tabular Editor (Best Practice Analyzer), and inspect the storage engine (VertiPaq, fast) vs formula engine (single-threaded, often slow) ratio. Also check whether Direct Lake fallback occurred. Root fixes: “adopt a star schema,” “revise measures (avoid abusing iterators/bidirectional),” “V-Order/OPTIMIZE the Delta,” and “drop unneeded/high-cardinality columns.” The rule is “measure first → identify cause (model/DAX/data layout) → improve.”
| Goal | Language/tool | Target |
|---|---|---|
| Model aggregation | DAX | Semantic model |
| Tabular SQL analysis | T-SQL | SQL endpoint/Warehouse |
| Streaming/logs | KQL | Real-Time (Eventhouse) |
| Diagnose slowness | Performance Analyzer / DAX Studio | Reports/DAX queries |
Scenario: a report page is slow; find the cause and fix it. → First measure per-visual DAX query times with Performance Analyzer to find the slowest visual. Analyze its DAX in DAX Studio; if you find formula-engine heaviness or iterator abuse, rewrite the measure, star-ize the model, and V-Order/OPTIMIZE the Delta to improve.
FAQ: Q. DAX vs T-SQL vs KQL? → A. DAX for model aggregations, T-SQL (SQL analytics endpoint) for SQL tabular analysis, KQL for streaming/logs. Q. First step for a slow report? → A. Measure with Performance Analyzer to pinpoint the bottleneck (which visual/DAX), then dig in with DAX Studio, etc.
Trap: “deleting relationships speeds up the report” is wrong—removing relationships breaks the model; improve via star schema, measure revision, Delta optimization, Direct Lake. Also “use DAX to analyze streaming data” is wrong—real-time/logs use KQL.
3.2.2Section summary
- Explore = DAX/T-SQL/KQL + visuals
- Diagnose = Performance Analyzer, DAX Studio
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to measure per-visual timings in a Power BI report to find slow spots. What do you use?
Q2. Which language queries streaming/real-time data?
Q3. Which is NOT effective for improving a slow report?