Ozone - Performance at billions’ scale
summary
Ozone claims HDFS-like throughput while scaling to billions of keys (tested to 10 billion, design target ~1 trillion) by replacing per-block state with 5GB containers (≈100x fewer entities), separating namespace (OM in RocksDB) from storage (SCM + datanodes) and using Raft via Ratis. Benchmarks show ~80–90% of HDFS teragen speed. Practical fixes covered: gRPC protobuf buffer-copy mitigation, Netty thread-cache disablement that cuts GC from ~3min to 37s, retry backoff tuning, and a 64TB vs 64MB RocksDB cache bug that reduced memory from ~20GB to 3GB.
AI-written summary · about
chapters (17)
- 0:00Start
- 0:58Basic Introduction about Ozone
- 1:40Architecture
- 2:51Hdfs Architecture
- 4:29Ozone Architecture
- 6:24Ozone Manager
- 7:22Recon Server
- 10:23Design Principles
- 11:29Write Key and Read Key Workflow
- 13:08Namespace Layer
- 14:47Storage
- 15:38Data Nodes
- 16:24Structure of a Storage Container
- 21:59Performance Improvements
- 22:59Block Allocation Algorithm
- 24:09Data Improvements
- 27:28Buffer Copy
related talks
45mEmbracing Big Data Workload in Cloud-Native Environment with Data Locality
34mWhat We Talk About When We Talk About Disk IO
36mOptimizing Ceph Object Storage for Analytics and AL/ML Workloads - Overview and Future Plans
01h 06mBest practices when accessing Big Data or any other data!
47mDesign Decisions Behind Cube Store - a Blazingly Fast Open-Source Rollup Storage Layer
26mPetabyte Scale Datalake Table Management with Ray, Arrow, Parquet, and S3
25mCloud native data replication strategies
32mStoring State Forever: Why It Can Be Good For Your Analytics