“How many servers should we buy?”
Kabir's internship company, TiffinGo, delivers lunch boxes in five cities. Their order and app-click data is 200 TB today and growing fast. His manager forwards an email from the finance team: “Please tell us by Friday how many servers to buy for the new data platform, and what it will cost for the next three years.” Kabir brings the email to Arjun Sir, looking worried.
Sir, 200 TB. Each server has about 144 TB of disk. So two servers, maybe three to be safe?
If you send that, the platform will be full on day one. Kabir, what does HDFS do with every block?
Oh. It keeps three copies. So 600 TB… five servers?
Closer. But jobs also need space for temporary files, and a cluster that is 100% full stops working well. And the data grows 40% a year. And there's a deadline: the nightly report must be ready by 6 am, so you need enough CPU too.
So scaling out means working out how many machines, not just “add machines”?
Exactly. In Big Data Fundamentals you learned why scaling out wins. Today you'll learn how a data engineer actually sizes a Hadoop cluster: storage, compute and growth, with real formulas. And then you'll add nodes to a cluster and watch a job get faster.
Scaling out and cluster sizing
Coming from Big Data Fundamentals? Its lesson Why one computer is not enough explained why scaling out beats scaling up (cost curve, ceiling, failures). This lesson is the practical next step: how many nodes a Hadoop cluster needs.
Horizontal scaling (scaling out) increases a system's capacity by adding more nodes and spreading data and work across them, rather than making one machine larger. Cluster sizing (capacity planning) is the process of estimating how many nodes, and of what configuration, a cluster needs to meet its requirements for storage (data volume × replication factor + temporary space + free headroom), compute (tasks that must finish within a time window), memory and network, including expected growth over the planning period. The final size is set by whichever requirement needs the most nodes.
Scaling out means adding more ordinary computers. Sizing means doing the maths first: how much disk do we really need after copies and spare room, how much CPU to finish the work in time, and how fast will it grow? Work out the nodes needed for each, and buy the biggest of those numbers.
Words you'll meet in this lesson
The sizing formulas
| Raw disk needed | data × replication ÷ (1 − temp share − headroom). With 3 copies, 25% temp and 25% headroom: data × 3 ÷ 0.5 = data × 6 |
|---|---|
| Storage nodes | raw disk needed ÷ disk per node, rounded up |
| Compute nodes | total task-minutes ÷ (time window × slots per node), rounded up |
| Final size | the larger of storage nodes and compute nodes, plus spare nodes for failures |
| Growth | data after n years = today × (1 + growth rate)n |
| Compression | if data is stored compressed (for example 3× smaller as Parquet), divide the data size first |
Rules of thumb vary by company and workload. These numbers are a sensible starting point, not a standard.
Sizing at three levels
Beginner The tiffin box shelf
- You must store 200 tiffin boxes, and for safety you keep 3 identical copies of each: that's 600 boxes.
- The kitchen also needs some shelf space for boxes that are being packed right now (temp space).
- And you never fill shelves to the last inch, or you can't move anything (headroom).
- So you need shelves for about six times the boxes you thought. That's cluster sizing in one line.
Intermediate Storage, compute and the bigger number
- Storage-bound clusters keep years of data but run light jobs: size by disk.
- Compute-bound clusters run heavy jobs on less data, or must finish in a short window: size by CPU slots.
- Compute: if the nightly job is 6,000 task-minutes and each node runs 16 tasks at once, a 2-hour window needs 6,000 ÷ (120 × 16) ≈ 3.2, so 4 nodes worth of slots.
- Then take the bigger of the two answers. Most Hadoop clusters end up storage-bound.
- Add a few spare nodes so that losing one or two still meets the requirements.
Advanced Trade-offs a senior engineer weighs
- Many small nodes vs few big nodes: a node with 24 × 20 TB = 480 TB holds a lot, but when it dies, re-copying 480 TB of replicas takes many hours and heavy network use. Smaller nodes recover faster and spread load more evenly.
- Disks vs cores: keep a sensible ratio (often around one or two disks per few cores) so jobs are not starved of disk bandwidth or CPU.
- Erasure coding (Hadoop 3) can store cold data with about 1.5× overhead instead of 3×, cutting raw disk sharply for old data (Module 7).
- Separate storage and compute: in the cloud, data often lives in object storage (S3, GCS, ADLS), and clusters are sized only for compute, then shut down after the job.
- Diminishing returns: doubling nodes rarely halves job time exactly. The master, the shuffle and the slowest task add a fixed part (Amdahl's law).
Exam tip: A typical exam or interview question: “You have X TB growing Y% a year, replication 3. How many nodes of Z TB do you need in 3 years?” Write the formula, show each step (growth → ×3 → temp + headroom → ÷ node size → round up), and state your assumptions.
Ways to grow a cluster
Add worker nodes
The normal way to scale Hadoop. Install the DataNode and NodeManager, add the host to the topology script, start them. New nodes join while the cluster runs.
Scale outAdd disks to nodes
If nodes have empty disk slots, adding disks raises storage without new servers. Compute stays the same.
More storageBigger nodes
Replace old nodes with newer ones that have more cores, RAM and disk. Each node is “scaled up” while the cluster keeps scaling out.
RefreshElastic cloud nodes
Add task-only nodes for a busy night or a festive sale, then remove them. Storage can stay in object storage.
Pay per hourTiered storage
Move old, rarely used data to cheaper storage (archive disks, erasure coding, cloud archive), keeping fast disks for hot data.
Save costFew big nodes vs many small nodes (same total capacity)
| 10 big nodes (480 TB each) | 40 small nodes (120 TB each) | |
|---|---|---|
| Rack space and power | Less | More |
| One node fails | 10% of the cluster gone; ~480 TB of replicas to re-copy | 2.5% gone; ~120 TB to re-copy |
| Parallelism | Fewer disks and NICs to spread work over | More disks and network ports working at once |
| Management | Fewer machines to patch | More machines, but each is less critical |
| Good for | Archive-heavy, cold data | Busy clusters with many jobs |
After adding nodes, run the HDFS balancer (hdfs balancer -threshold 10). New nodes start empty; new writes go everywhere, but old blocks stay where they were until the balancer moves them. Jobs on old data won't use the new nodes' disks until then.
Size TiffinGo's cluster for the next three years
Grow the data to the end of the planning period
Growth compounds: 200 → 280 → 392 → 549 TB. Sizing for today's data only means buying again in a few months.data_tb = 200 * 1.4 ** 3 # 200 TB growing 40% a year, for 3 years print(round(data_tb), "TB in year 3")549 TB in year 3Apply compression (if any)
TiffinGo will store its clicks as compressed Parquet files, about 3× smaller: 549 ÷ 3 ≈ 183 TB on disk. Orders stay as they are. For simplicity, say 300 TB must be stored.
Compression ratios depend on the data. Measure on a sample before you trust a number.Multiply by replication
Each block is on three DataNodes, on at least two racks. Every TB of business data uses 3 TB of disk.print(300 * 3, "TB of replicas")900 TB of replicasAdd temp space and headroom
Half of each disk is reserved for in-between job data and safety margin. Running HDFS close to 100% full causes failed writes and slow jobs.raw = 900 / (1 - 0.25 - 0.25) # 25% temp space, 25% free headroom print(raw, "TB raw disk")1800.0 TB raw diskTurn disk into nodes
Always round up: 12.5 nodes means 13.import math print(math.ceil(1800 / 144), "storage nodes of 144 TB")13 storage nodes of 144 TBCheck compute, then pick the bigger number
The nightly report is 9,000 task-minutes; each node runs 16 tasks at once; the window is 2 hours. 9,000 ÷ (120 × 16) = 4.7, so 5 nodes are enough for compute. Storage needs 13, so storage wins.
Add 2 spare nodes so that a failure or two doesn't break the plan: 15 nodes, which fit in 2 racks of 8 (better for rack awareness than 1 rack). Kabir has his answer, with every assumption written down.
Adding nodes to a full cluster: the dashboard, and what the blocks do
TiffinGo's cluster is getting full. Watch the admin add three nodes. Left: the dashboard. Right: where the blocks are.
- The dashboard turns red: HDFS is 86% full on 6 nodes. Time to scale out.
- Three new nodes are installed and started. Overall usage drops to about 57%.
- But the old nodes are still 86% full and the new ones are empty. The nightly report is no faster.
- The admin runs the HDFS balancer, which moves blocks to the new nodes until every node is within 10% of the average.
- Now the report's tasks are spread over 9 nodes: it drops from 96 to 64 minutes.
- Half again as many nodes gave about a third less time, not half: part of the job doesn't split. (Times here are illustrative.)
- Six DataNodes, each 86% full. Writes start failing on the fullest nodes soon.
- Three new DataNodes start, register with the NameNode and report zero blocks.
- HDFS sends new blocks to all nodes, but existing blocks stay where they are. Old data is still read from only six nodes.
- The balancer copies blocks from over-full nodes to under-full ones and deletes the old copies, slowly, so jobs are not disturbed.
- All nine nodes now hold about the same share. Tasks for old data can run on any of them.
- Reads, writes and processing are spread over more disks and more cores. That is scaling out working.
Try it yourself: does a bigger cluster really run faster?
The same 4 GB file (32 blocks) is loaded on clusters of 3, 6 and 9 nodes. Each node can run 2 tasks at a time. Run the job on each size and compare the times in Job runs.
Where sizing decisions are made
1. The yearly hardware budget
On-premises teams (banks, telecoms, government) size clusters once or twice a year, because buying servers takes weeks or months. They forecast data growth and new projects, then order nodes in batches.
2. Festive sales and big cricket matches
E-commerce and streaming companies see traffic jump many times for a few days. In the cloud they add extra task nodes for those days and remove them after, instead of owning hardware for the peak all year.
3. Cloud: size compute, not storage
With data in object storage, a managed cluster (such as Amazon EMR or Google Dataproc) is sized just for the job, often with autoscaling, and deleted when the job ends. You pay for storage and for compute hours separately.
4. Hot, warm and cold data
A telecom may keep call records for years for regulation, but only the last few weeks are queried often. Old data moves to cheaper, denser storage (or erasure-coded HDFS), so the expensive nodes are sized for hot data only.
5. Adding nodes without downtime
Platform teams add nodes to live clusters regularly: install, add to the topology, start the services, then run the balancer at low speed overnight. Users keep working throughout. You'll do it in Module 12.
Examples are simplified; figures in this lesson are illustrative. Real sizing also considers licences, support contracts, staff and data-centre limits.
A cluster sizing calculator
This function turns business requirements into a number of storage nodes, using the formulas from Part 2. Change the inputs and run it again, then try the challenges.
import math
def storage_nodes(data_tb, replication=3, temp=0.25, headroom=0.25, node_tb=144):
raw_tb = data_tb * replication / (1 - temp - headroom)
return raw_tb, math.ceil(raw_tb / node_tb)
for data in [50, 200, 500]:
raw, nodes = storage_nodes(data)
print(f"{data:>4} TB data -> {raw:>6.0f} TB raw -> {nodes:>3} nodes")def storage_nodes(data_tb, replication=3, temp=0.25, headroom=0.25, node_tb=144):Default values hold the usual assumptions, so a caller only passes what is different, for examplestorage_nodes(200, node_tb=240).raw_tb = data_tb * replication / (1 - temp - headroom)With the defaults, this is data × 3 ÷ 0.5 = data × 6.return raw_tb, math.ceil(raw_tb / node_tb)Return two values at once (a tuple).math.ceilrounds up: you cannot buy half a node.
Growing data year by year, one line at a time
Watch data grow 40% each time round the loop, and see the function called once per year to turn it into nodes. Each call gets its own frame.
Worked examples: real problems, solved and traced in memory
Three sizing problems from real platform planning: storage only, a deadline, and a three-year plan that adds nodes each year. Each runs live and is traced in memory.
How many nodes for 80 TB of data?
Problem statement
A college research group wants to store 80 TB of sensor data in HDFS with replication 3, 25% temp space and 25% headroom. Each node has 96 TB raw. How many nodes, and how many racks of 10?
80 TB · ×3 · ÷0.5 · 96 TB/node · 10 nodes/rack
Raw disk: 480.0 TB Nodes: 5 Racks: 2
Approach
- Raw = data × 3 ÷ 0.5.
- Nodes = raw ÷ 96, rounded up.
- Racks = nodes ÷ 10, rounded up. Use at least 2 racks so copies can span racks.
Solution: run it live
What happens in memory, step by step
Recorded from a real Python run: press Next to execute one line at a time. Watch variables change in each frame, and lists and dictionaries (numbered #1, #2 …) fill up as objects.
Will the nightly job fit in the window?
Problem statement
A bank's risk job has 6,000 map tasks of about 5 minutes each. The cluster has 30 nodes with 12 slots each. Reduces take a fixed 20 minutes after the maps. The job must finish within 90 minutes. Does it fit, and if not, how many nodes are needed?
6,000 tasks × 5 min · 30 nodes × 12 slots · +20 min · 90 min window
30 nodes: 105 min Need 36 nodes: 90 min
Approach
- Waves = tasks ÷ (nodes × slots), rounded up.
- Job time = waves × 5 + 20.
- If too slow, add nodes one at a time until it fits.
Solution: run it live
What happens in memory, step by step
Recorded from a real Python run: press Next to execute one line at a time. Watch variables change in each frame, and lists and dictionaries (numbered #1, #2 …) fill up as objects.
How many nodes to add each year?
Problem statement
TiffinGo has 200 TB today, growing 40% a year. Storage uses the ×6 rule (3 copies ÷ 0.5), nodes have 144 TB, and they keep 2 spare nodes. For each of the next 3 years, print the nodes needed and how many to buy that year.
200 TB · +40%/year · ×6 · 144 TB/node · +2 spares · 3 years
Today: 11 nodes Year 1: 280 TB, need 14, buy 3 Year 2: 392 TB, need 19, buy 5 Year 3: 549 TB, need 25, buy 6
Approach
- Start with the nodes needed for today's data.
- Each year: grow the data, compute the nodes needed, and buy the difference from last year.
- Never buy a negative number (you don't sell nodes when data shrinks).
Solution: run it live
What happens in memory, step by step
Recorded from a real Python run: press Next to execute one line at a time. Watch variables change in each frame, and lists and dictionaries (numbered #1, #2 …) fill up as objects.
Check yourself
Quick revision
Lesson 1.3 in one screen
- Scale out = add nodes. Sizing = decide how many, before buying.
- Storage: raw = data × replication ÷ (1 − temp − headroom). Defaults (3, 25%, 25%) give × 6.
- Compute: nodes = task-minutes ÷ (window × slots per node).
- Final size = max(storage, compute) + spares. Round up.
- Growth compounds: data × (1 + rate)years. Measure compression on real samples.
- Use at least 2 racks so replicas span failure domains.
- New nodes start empty: run
hdfs balancer -threshold 10. - Many small nodes: smaller blast radius, faster re-replication. Few big nodes: less space and power.
- More nodes ≠ proportionally faster: fixed parts of a job remain (Amdahl).
- Cloud: storage in object stores, clusters sized for compute and often temporary.
Interview and viva questions
How do you size a Hadoop cluster?
Start from requirements: current data, growth rate, retention period and compression. Multiply by the replication factor, add temporary space for intermediate data (about 25% of raw is a common rule of thumb) and headroom (20–30%). Divide by usable disk per node to get storage nodes. Separately estimate compute nodes from the workload and time windows. Take the larger number, add spares for failures, and spread nodes over at least two racks. State your assumptions.
Why do we keep free headroom in HDFS?
A nearly full HDFS causes failed writes, uneven nodes and slow jobs. Free space absorbs growth spikes, job temp files and re-replication after a node dies (the surviving nodes must hold the lost replicas).
What does the HDFS balancer do?
It moves blocks from over-utilised DataNodes to under-utilised ones until every node's usage is within a threshold (for example 10%) of the cluster average. It runs in the background with limited bandwidth so normal work continues. It is typically used after adding nodes.
Is it better to have more small nodes or fewer large nodes?
It depends. More small nodes give more parallel disks and network ports, a smaller share lost per failure and faster re-replication. Fewer large nodes save rack space, power and management effort, and suit cold archive data. Very dense nodes make failures expensive to recover from.
Why doesn't doubling the nodes always halve the job time?
Some parts of a job are serial or fixed: start-up, planning, the reduce or final step, waiting for the slowest task, and coordination overhead. Amdahl's law says the serial part limits the maximum speed-up. Moving more data over the network can also add cost.
Practice problems
Sizing questions of the kind asked in data engineering interviews and in real capacity reviews. Work them out on paper first, then run the code.
Raw disk for 50 TB
How much raw disk is needed for 50 TB of data with replication 3, 25% temp and 25% headroom?
50 TB · 3 · 0.25 · 0.25
300.0 TB
Show solution and explanation
print(50 * 3 / (1 - 0.25 - 0.25), "TB")How it works: 50 × 3 ÷ 0.5 = 300 TB: six times the data.
Nodes from raw disk
The cluster needs 1,000 TB raw. Each node has 12 disks of 16 TB. How many nodes?
1000 TB raw · 12 × 16 TB
6 nodes
Show solution and explanation
import math
print(math.ceil(1000 / (12 * 16)), "nodes")How it works: Each node has 192 TB, so 1000 ÷ 192 = 5.2 → 6 nodes.
Waves of tasks
A job has 500 tasks. The cluster has 25 nodes with 8 slots each. How many waves?
500 tasks · 25 × 8 slots
3 waves
Show solution and explanation
import math
print(math.ceil(500 / (25 * 8)), "waves")How it works: 200 tasks run at once, so 500 tasks need 3 waves.
Compression saves nodes
300 TB of logs compress 4× as Parquet. Using the ×6 rule and 144 TB nodes, how many nodes without and with compression?
300 TB · 4× · ×6 · 144 TB
raw logs -> 13 nodes Parquet -> 4 nodes
Show solution and explanation
import math
for label, tb in [("raw logs", 300), ("Parquet", 300 / 4)]:
print(label, "->", math.ceil(tb * 6 / 144), "nodes")How it works: 13 vs 4 nodes. Good file formats are one of the biggest cost levers in big data (Module 10).
When does the cluster get full?
A cluster can hold 400 TB of business data. Data is 150 TB and grows 35% a year. In which year does it pass 400 TB?
capacity 400 · 150 TB · +35%/year
Year 4 -> 498 TB
Show solution and explanation
data, year = 150, 0
while data <= 400:
data *= 1.35
year += 1
print("Year", year, "->", round(data), "TB")How it works: 150 → 203 → 273 → 369 → 498. It passes in year 4, so new nodes must be ordered in year 3, allowing for delivery time.
Re-replication time after a failure
A node with 200 TB of replicas dies. The other 39 nodes each copy at 100 MB/s for re-replication, in parallel. Roughly how many hours until all copies are restored?
200 TB · 39 nodes × 100 MB/s
14.9 hours
Show solution and explanation
mb = 200 * 1024 * 1024
rate = 39 * 100 # MB per second, all nodes together
print(round(mb / rate / 3600, 1), "hours")How it works: About 15 hours with these numbers. Denser nodes take longer, which raises the risk that a second failure hits a block before it is fully copied again.
Cloud cluster per night vs always on
A nightly job needs 40 nodes for 2 hours. A cloud node costs Rs 35 per hour. Compare a cluster kept on all day (24 h) with one created only for the job, for 30 days.
40 nodes · Rs 35/h · 2 h vs 24 h · 30 days
Always on : Rs 10.08 lakh Per job : Rs 0.84 lakh Saved : Rs 9.24 lakh
Show solution and explanation
rate, nodes, days = 35, 40, 30
always = nodes * 24 * rate * days
per_job = nodes * 2 * rate * days
print(f"Always on : Rs {always / 1e5:.2f} lakh")
print(f"Per job : Rs {per_job / 1e5:.2f} lakh")
print(f"Saved : Rs {(always - per_job) / 1e5:.2f} lakh")How it works: Rs 10.08 lakh vs Rs 0.84 lakh a month (illustrative prices). With data in object storage, creating clusters per job saves most of the compute bill.
Full sizing note for a manager
Write a small program that prints a sizing note: data 120 TB, growth 30% for 2 years, replication 3, 25% temp, 25% headroom, 144 TB nodes, 2 spares, 12 nodes per rack.
120 TB · 30% × 2 years · 3 · 0.25 · 0.25 · 144 TB · +2 · 12/rack
Data in 2 years : 203 TB Raw disk needed : 1217 TB Nodes (+2 spare): 11 Racks : 2
Show solution and explanation
import math
data = 120 * 1.3 ** 2
raw = data * 3 / (1 - 0.25 - 0.25)
nodes = math.ceil(raw / 144) + 2
racks = max(2, math.ceil(nodes / 12))
print(f"Data in 2 years : {data:.0f} TB")
print(f"Raw disk needed : {raw:.0f} TB")
print(f"Nodes (+2 spare): {nodes}")
print(f"Racks : {racks}")How it works: Always present the result with its assumptions. If the manager changes growth or replication, the note can be re-run in seconds.
Real-world scenario questions (asked in company interviews)
Sizing and scaling situations that come up in data engineering interviews. Decide your answer first, then compare.
“We have 100 TB. How many 100 TB nodes do we need?”
The interviewer gives you exactly this question and waits. There is no more information.
The interviewer is checking: do you know that HDFS needs far more raw disk than the data size, and do you ask about assumptions?
Show a strong answer
Not one. First, questions: replication factor? growth rate and retention? compression? workload? Then a default calculation:
- 100 TB × 3 copies = 300 TB, ÷ 0.5 for temp space and headroom = 600 TB raw, so 6 nodes, plus 1–2 spares.
- With 40% growth for 2 years: 196 TB of data, about 12 nodes, plus spares.
- Check compute too, and spread over at least two racks.
Avoid saying: “One node, because 100 TB fits.”
We added 10 nodes and nothing got faster
A 30-node cluster was 85% full and jobs were slow. The team added 10 new nodes yesterday. Today jobs are just as slow, and the new nodes show almost no disk usage.
The interviewer is checking: do you know how HDFS treats new nodes and how to fix the imbalance safely?
Show a strong answer
- New DataNodes start empty. Existing blocks stay on the old nodes, so tasks reading old data still run (data-local) mostly on the old 30 nodes.
- Run the balancer:
hdfs balancer -threshold 10, with a bandwidth limit so production jobs are not hurt, preferably at night. - Check that the new nodes are in the topology script (correct racks) and that their NodeManagers are registered, so YARN can use their CPU.
- Also check that the slowness was really storage-related; if jobs were CPU- or network-bound, more disks alone wouldn't help.
Avoid: “Wait a few days, it will balance itself.” Only new writes go to new nodes.
24 × 22 TB disks per node: good idea?
To save rack space, a vendor proposes very dense nodes: 24 disks of 22 TB each (528 TB per node). The cluster would have only 8 nodes instead of 30 smaller ones.
The interviewer is checking: can you reason about failure blast radius, recovery time and parallelism?
Show a strong answer
- Failure impact: one node is 12.5% of the cluster. Its loss forces re-copying up to ~528 TB, which can take a day or more and loads the network.
- Rack awareness: with 8 nodes, spreading replicas over racks evenly is harder.
- Compute: fewer nodes means fewer cores and NICs for parallel tasks, unless the CPU is scaled up too.
- When it's fine: mostly cold, archival data with light processing, possibly with erasure coding.
Avoid: judging only by cost per TB.
The cloud bill doubled, but data only grew 10%
A startup runs a 50-node cloud Hadoop cluster 24 hours a day. Jobs run only from midnight to 4 am. The bill has doubled since last year.
The interviewer is checking: do you know how cloud clusters are sized differently from on-premises ones?
Show a strong answer
- Keep data in object storage (S3, GCS, ADLS) instead of HDFS on the cluster's disks, so the cluster holds no data of its own.
- Create the cluster for the nightly jobs and delete it after, or autoscale it down to a few nodes during the day: about 4 hours a day instead of 24 can cut the compute bill roughly in proportion.
- Use cheaper spot/preemptible nodes for task-only nodes that can be lost safely.
- Check which jobs grew; maybe one job is rescanning all history every night.
Avoid: treating a cloud cluster like on-prem hardware that must run all the time.