Scale out in practice: how big should a cluster be?

“Add more machines” is the easy part. The real question every data team faces is: how many? This lesson turns business requirements (data size, growth, copies, deadlines) into a number of nodes, with formulas you can reuse in interviews and at work. Then you will add nodes to a full cluster, watch the balancer spread the data, and test in the playground whether three times the nodes really means three times the speed.

Module 1 · Foundations: before Hadoop⏱ 26 minBeginner → AdvancedCluster PlaygroundRuns in your browser (Python)Sizing calculator8 practice problems
1 The story

“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.

What the business says • 200 TB of data today • grows 40% a year • keep 3 years • nightly report by 6 am • don't lose data! Sizing × 3 copies (replication) + 25% temp space ÷ 0.75 keep space free ÷ TB per node check CPU and network The answer N nodes in R racks + how many to add each year Scaling out is not “buy lots of servers”. It is a calculation, done before every purchase. myphatshala.in
Kabir

Sir, 200 TB. Each server has about 144 TB of disk. So two servers, maybe three to be safe?

Arjun Sir

If you send that, the platform will be full on day one. Kabir, what does HDFS do with every block?

Kabir

Oh. It keeps three copies. So 600 TB… five servers?

Arjun Sir

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.

Riya

So scaling out means working out how many machines, not just “add machines”?

Arjun Sir

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.

2 Definition

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.

Formal definition (write this in exams)

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.

In simple words

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

Raw capacityTotal disk in all nodes added together, before any copies.
Usable capacityWhat is left for business data after replication, temp space and headroom.
Replication factorHow many copies HDFS keeps of each block. Default: 3.
HeadroomFree space you keep on purpose (often 20–30%) so the cluster never runs full.
Temp (intermediate) spaceDisk used by jobs for in-between results, like map outputs. A common rule of thumb is about 25% of raw.
WaveOne round of tasks when there are more tasks than slots. 100 tasks on 40 slots = 3 waves.
BalancerAn HDFS tool that moves blocks from full nodes to emptier ones, for example after adding nodes.
Elastic scalingAdding and removing nodes as the load changes. Easy in the cloud.

The sizing formulas

Raw disk neededdata × replication ÷ (1 − temp share − headroom). With 3 copies, 25% temp and 25% headroom: data × 3 ÷ 0.5 = data × 6
Storage nodesraw disk needed ÷ disk per node, rounded up
Compute nodestotal task-minutes ÷ (time window × slots per node), rounded up
Final sizethe larger of storage nodes and compute nodes, plus spare nodes for failures
Growthdata after n years = today × (1 + growth rate)n
Compressionif 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

Pick your level. New to this? Start at Beginner and climb.

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.

3 Types and ways to use it

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 out

Add disks to nodes

If nodes have empty disk slots, adding disks raises storage without new servers. Compute stays the same.

More storage

Bigger 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.

Refresh

Elastic 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 hour

Tiered storage

Move old, rarely used data to cheaper storage (archive disks, erasure coding, cloud archive), keeping fast disks for hot data.

Save cost

Few big nodes vs many small nodes (same total capacity)

10 big nodes (480 TB each)40 small nodes (120 TB each)
Rack space and powerLessMore
One node fails10% of the cluster gone; ~480 TB of replicas to re-copy2.5% gone; ~120 TB to re-copy
ParallelismFewer disks and NICs to spread work overMore disks and network ports working at once
ManagementFewer machines to patchMore machines, but each is less critical
Good forArchive-heavy, cold dataBusy 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.

4 Step by step

Size TiffinGo's cluster for the next three years

  1. Grow the data to the end of the planning period

    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 3
    Growth compounds: 200 → 280 → 392 → 549 TB. Sizing for today's data only means buying again in a few months.
  2. Apply 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.
  3. Multiply by replication

    print(300 * 3, "TB of replicas")
    900 TB of replicas
    Each block is on three DataNodes, on at least two racks. Every TB of business data uses 3 TB of disk.
  4. Add temp space and headroom

    raw = 900 / (1 - 0.25 - 0.25)   # 25% temp space, 25% free headroom
    print(raw, "TB raw disk")
    1800.0 TB raw disk
    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.
  5. Turn disk into nodes

    import math
    print(math.ceil(1800 / 144), "storage nodes of 144 TB")
    13 storage nodes of 144 TB
    Always round up: 12.5 nodes means 13.
  6. Check 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.
5 See it happen

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.

Scaling out a running cluster 6 steps
What you see Cluster dashboard HDFS used 86% · alert: add capacity 57% overall 57% · balanced Nodes 6 9 Nightly report 96 min 64 min Old nodes 86% full, new nodes 0%“Why is the report not faster?” $ hdfs balancer -threshold 10Moving blocks… The cluster is balanced. 50% more nodes → report about 1/3 fasternot exactly 50%: some work doesn't split myphatshala.in
Behind the screen Disk used on each node new nodes only new writes reach the new nodes balancer moves blocks old → new every node ~57%: tasks run on all 9 reads, writes and tasks now spread evenly 6 nodes at 86% 3 empty nodes join the cluster myphatshala.in

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.

6 Real-world use

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.

Growth forecast→Sizing sheet→Purchase order
sale day

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.

Peak forecast→Temporary nodes→Remove after
S3EMR

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.

Data in object store→Cluster for 2 hours→Shut down

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.

New data (hot)→Age policy→Archive tier (cold)
+3

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.

New servers→Join + balancer→Bigger cluster

Examples are simplified; figures in this lesson are illustrative. Real sizing also considers licences, support contracts, staff and data-centre limits.

7 Run the code

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")
50 TB data -> 300 TB raw -> 3 nodes 200 TB data -> 1200 TB raw -> 9 nodes 500 TB data -> 3000 TB raw -> 21 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 example storage_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.ceil rounds up: you cannot buy half a node.
8 Line by line

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.

Example 1BeginnerPlatform planning · storage

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?

Input
80 TB · ×3 · ÷0.5 · 96 TB/node · 10 nodes/rack
Expected output
Raw disk: 480.0 TB
Nodes: 5
Racks: 2

Approach

  1. Raw = data × 3 ÷ 0.5.
  2. Nodes = raw ÷ 96, rounded up.
  3. 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.

Example 2IntermediateBanking · batch window

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?

Input
6,000 tasks × 5 min · 30 nodes × 12 slots · +20 min · 90 min window
Expected output
30 nodes: 105 min
Need 36 nodes: 90 min

Approach

  1. Waves = tasks ÷ (nodes × slots), rounded up.
  2. Job time = waves × 5 + 20.
  3. 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.

Example 3AdvancedData platform · 3-year plan

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.

Input
200 TB · +40%/year · ×6 · 144 TB/node · +2 spares · 3 years
Expected output
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

  1. Start with the nodes needed for today's data.
  2. Each year: grow the data, compute the nodes needed, and buy the difference from last year.
  3. 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.

9 Quiz and revision

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.

P1Easy

Raw disk for 50 TB

How much raw disk is needed for 50 TB of data with replication 3, 25% temp and 25% headroom?

Input
50 TB · 3 · 0.25 · 0.25
Expected output
300.0 TB
Show solution and explanation
print(50 * 3 / (1 - 0.25 - 0.25), "TB")
300.0 TB

How it works: 50 × 3 ÷ 0.5 = 300 TB: six times the data.

P2Easy

Nodes from raw disk

The cluster needs 1,000 TB raw. Each node has 12 disks of 16 TB. How many nodes?

Input
1000 TB raw · 12 × 16 TB
Expected output
6 nodes
Show solution and explanation
import math
print(math.ceil(1000 / (12 * 16)), "nodes")
6 nodes

How it works: Each node has 192 TB, so 1000 ÷ 192 = 5.2 → 6 nodes.

P3Easy

Waves of tasks

A job has 500 tasks. The cluster has 25 nodes with 8 slots each. How many waves?

Input
500 tasks · 25 × 8 slots
Expected output
3 waves
Show solution and explanation
import math
print(math.ceil(500 / (25 * 8)), "waves")
3 waves

How it works: 200 tasks run at once, so 500 tasks need 3 waves.

P4Medium

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?

Input
300 TB · 4× · ×6 · 144 TB
Expected output
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")
raw logs -> 13 nodes Parquet -> 4 nodes

How it works: 13 vs 4 nodes. Good file formats are one of the biggest cost levers in big data (Module 10).

P5Medium

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?

Input
capacity 400 · 150 TB · +35%/year
Expected output
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")
Year 4 -> 498 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.

P6Medium

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?

Input
200 TB · 39 nodes × 100 MB/s
Expected output
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")
14.9 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.

P7Business problem

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.

Input
40 nodes · Rs 35/h · 2 h vs 24 h · 30 days
Expected output
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")
Always on : Rs 10.08 lakh Per job : Rs 0.84 lakh Saved : Rs 9.24 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.

P8Business problem

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.

Input
120 TB · 30% × 2 years · 3 · 0.25 · 0.25 · 144 TB · +2 · 12/rack
Expected output
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}")
Data in 2 years : 203 TB Raw disk needed : 1217 TB Nodes (+2 spare): 11 Racks : 2

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.

Data platform · capacityFresher

“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.”

Retail · operations1–3 years

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
  1. 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.
  2. Run the balancer: hdfs balancer -threshold 10, with a bandwidth limit so production jobs are not hurt, preferably at night.
  3. Check that the new nodes are in the topology script (correct racks) and that their NodeManagers are registered, so YARN can use their CPU.
  4. 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.

Infrastructure · hardware choice3+ years

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.

Startup · cloud cost1–3 years

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.