Amazon Redshift – Comprehensive Lecture Review
Core Purpose
- Fully managed cloud data warehouse for OLAP workloads (analytics, BI, reporting)
- Executes complex SQL across GB–PB+ datasets
Key Architectural Pillars
- Massively Parallel Processing (MPP)
• “Shared-nothing” cluster: Leader node + compute nodes → slices
• Leader: parse, optimize, compile to C++, distribute, aggregate, cache - Columnar storage engine
• Stores values by column ⇒ scans only needed columns
• High compression (auto or manual encodings such as AZ64, ZSTD)
• Zone-maps on sort keys skip whole blocks
Node Families (Provisioned)
- RA3 (decoupled compute / Redshift Managed Storage)
- DC2 (fast SSD, < GB data)
- DS2 (cost-optimized HDD, ≤ PB)
Table Design Essentials
- Distribution styles
• KEY (hash on DISTKEY) → collocated joins
• ALL (replica on every node) → small dimensions
• EVEN (round-robin) → default, avoids skew - Sort keys
• COMPOUND (prefix ordered)
• INTERLEAVED (equal weight columns; higher maintenance)
Mandatory Maintenance (Provisioned)
- VACUUM ⇒ reclaim space & resort
- ANALYZE ⇒ refresh column statistics
Elastic & Modern Features
- Spectrum → SQL on S3 data lake without loading
- Concurrency Scaling → transient clusters for burst traffic (free credits each day)
- Data Sharing → zero-copy, live sharing between clusters/accounts/regions
- Serverless → pay-per-second RPUs, auto-provision & scale
Typical Use Cases
- Interactive BI dashboards & real-time metrics
- Batch big-data analytics / log processing
- In-warehouse ML with Redshift ML (SageMaker integration)
Comparison Snapshot
| Aspect | Redshift | Snowflake | BigQuery |
|---|---|---|---|
| Deploy | Provisioned + Serverless | Fully decoupled “virtual warehouses” | Fully serverless |
| Tuning | Dist/Sort keys, VACUUM | Minimal | None |
| Ecosystem fit | AWS-native | Multi-cloud | GCP-native |
Strengths
- High performance on large scans/aggregations
- Multiple scaling options (RA3, Concurrency, Serverless)
- Cost-effective RIs & pay-per-use models
- Deep AWS integration & standard SQL interface
Limitations
- Manual tuning required for peak speed (keys, maintenance)
- Mis-design ⇒ skew, slow joins, queued queries
- No enforced primary/unique constraints
- Data loads fastest from S3; other sources need extra tooling