DP-300 · Question #91
Case Study 3 - Contoso, Ltd 2 Overview Contoso, Ltd. is a clothing retailer based in Seattle. The company has 2,000 retail stores across the United States and an emerging online presence. The…
Azure Synapse Analytics: Table Distribution Types Dropdown 1: Retail Store Table -> Replicated Why Replicated is correct: The retail store table is approximately 2 MB - an extremely small dimension table. A Replicated table caches a full copy on every Compute node (up to 60)…
Question
Exhibit
Answer Area
- Table type to store retail store data:HashReplicatedRound-robin
- Table type to store promotional data:HashReplicatedRound-robin
Explanation
Azure Synapse Analytics: Table Distribution Types
Dropdown 1: Retail Store Table -> Replicated
Why Replicated is correct: The retail store table is approximately 2 MB - an extremely small dimension table. A Replicated table caches a full copy on every Compute node (up to 60). Since queries joining retail store addresses with sales transactions are frequent, replication eliminates all data movement during joins. No shuffling across nodes = maximum join performance for a tiny table.
Why the others are wrong:
- Hash: Designed for large tables (fact tables, typically hundreds of GB+). On a 2 MB table, hash distribution adds unnecessary complexity and still requires data movement if the joining table isn't hash-distributed on the same key.
- Round-robin: Spreads rows randomly across distributions. Fast for bulk loads/staging but requires a shuffle operation (data movement) on every join, defeating the purpose for a frequently-joined dimension table.
Dropdown 2: Promotional Table -> Hash
Why Hash is correct:
The promotional table is 5 GB - too large for Replicated (Microsoft's recommended upper limit is ~2 GB; larger replicated tables waste memory and slow maintenance). The table links promotion_id -> product_id, and the requirement explicitly states queries filtering/joining on product ID must complete as fast as possible. Hash-distributing on product_id co-locates promotional rows with matching sales transaction rows (assuming the sales table is also hash-distributed on product_id), eliminating the expensive broadcast/shuffle step during joins.
Why the others are wrong:
- Replicated: 5 GB exceeds the practical threshold. Each Compute node would cache 5 GB, wasting memory and causing slow table refresh after DML operations.
- Round-robin: Distributes rows with no awareness of join keys. Every join on
product_idwould require a full data shuffle across all 60 distributions - terrible for query performance on a table explicitly requiring fast product ID joins.
Key Technical Concept
Azure Synapse dedicated SQL pools distribute data across 60 distributions. The rule of thumb:
| Size | Distribution |
|---|---|
| < ~2 GB | Replicated (full copy on each node) |
| Large, frequently joined on a key | Hash (on the join key) |
| Staging / no join pattern | Round-robin |
Topics
Community Discussion
No community discussion yet for this question.
