Why is it called Hadoop?
Riya is filling in the syllabus tracker for the Big Data track: Hadoop, Hive, Spark, Kafka, Delta Lake, Airflow… She stops and asks the question every beginner asks: why are there so many tools, and why do they have such strange names?
Sir, why is it called Hadoop? It sounds like a cartoon.
Almost. Doug Cutting, one of its creators, named it after his young son’s toy elephant. That’s why the logo is a yellow elephant.
And Kafka? TiffinGo’s tech blog mentions it everywhere.
Jay Kreps at LinkedIn named it after the writer Franz Kafka, because it is a system built for writing. The names are fun. The reasons the tools exist are what matter.
What do you mean by reasons?
Each tool was built because the tool before it hit a wall. Google couldn’t fit the web on one machine, so it wrote the GFS and MapReduce papers. MapReduce was slow for repeated steps, so Spark appeared. Nightly batches were too late, so Kafka and streaming arrived. Learn the story once, and the whole ecosystem makes sense.
So history is actually a map of the ecosystem?
Exactly, Kabir. Today we walk through five eras in about twenty-five years, and see what users saw and what engineers built in each one.
How did big data begin?
Modern big data technology traces back to Google’s research papers on the Google File System (2003), MapReduce (2004) and Bigtable (2006), which described how to store and process web-scale data on clusters of commodity machines that tolerate failure. Open-source implementations such as Apache Hadoop (2006) spread the approach, followed by NoSQL databases, SQL-on-Hadoop, stream processing (Kafka), in-memory processing (Spark), cloud data warehouses and, most recently, the lakehouse.
Around 2003 Google had more data than any one computer could hold, so it worked out how to use thousands of cheap computers together and published how. Others copied the idea for free (Hadoop). Every big data tool since then was built to fix a weakness of the ones before it.
Words you’ll meet in this lesson
Milestones to remember
| 1997 | NASA researchers Michael Cox and David Ellsworth use the term “big data” for datasets too large for memory and disk |
|---|---|
| 2001 | Analyst Doug Laney describes Volume, Velocity and Variety (the 3 Vs) |
| 2003 · 2004 · 2006 | Google publishes the GFS, MapReduce and Bigtable papers |
| 2006 | Hadoop starts (Doug Cutting, Mike Cafarella; strongly backed by Yahoo!). Amazon launches S3 and EC2 |
| 2008 | Hadoop becomes a top-level Apache project; Facebook open-sources Hive and Cassandra |
| 2011 | LinkedIn open-sources Kafka |
| 2014 | Spark becomes a top-level Apache project and reaches version 1.0 |
| 2016 | India launches UPI (NPCI) and Jio’s cheap mobile data brings crores of new users online |
| 2019 → | Delta Lake is open-sourced; Iceberg and Hudi mature; the “lakehouse” idea spreads |
The history at three levels
Beginner Five eras in one breath
- Before 2000, one big database: companies kept data in one powerful server (Oracle, IBM DB2, mainframes) and built data warehouses for reports.
- 2003–2008, the Google papers and Hadoop: Google showed how to store and process the whole web on thousands of cheap machines. Hadoop copied the idea as free, open-source software.
- 2008–2014, more tools for more jobs: SQL on Hadoop (Hive), NoSQL databases (HBase, Cassandra, MongoDB), streaming (Kafka) and faster in-memory processing (Spark).
- 2010s, the cloud: rent storage (Amazon S3) and warehouses (BigQuery, Redshift, Snowflake) by the hour instead of buying servers.
- Today, the lakehouse and AI: one copy of data in open formats (Delta Lake, Iceberg) serving reports, streaming and machine learning, increasingly queried in plain language.
Intermediate Who built what, and why
- Google GFS (2003): a file system that splits huge files into large blocks and keeps 3 copies on different cheap machines. Became HDFS.
- Google MapReduce (2004): a way to process those blocks in parallel (map), then group and combine results (reduce), with automatic re-runs on failure. Became Hadoop MapReduce.
- Google Bigtable (2006): a giant sorted table spread across machines. Inspired HBase and, with Amazon’s Dynamo paper (2007), Cassandra.
- Facebook Hive (2008): analysts knew SQL, not Java, so Hive turned SQL into MapReduce jobs.
- LinkedIn Kafka (2011): a durable log that many systems can publish to and read from in real time.
- UC Berkeley Spark (2009, Apache top-level 2014): keeps data in memory between steps, so repeated steps and machine learning run far faster than MapReduce.
- Netflix Iceberg, Uber Hudi, Databricks Delta Lake (2017–2019): table formats that give files in a lake database-like features.
Advanced The forces behind each shift
- Hardware economics: disk prices per GB fell by more than a million times between 1980 and the 2010s, so keeping everything became cheaper than deciding what to throw away.
- Commodity clusters beat big iron: many ordinary servers plus software that expects failure (replication, re-execution) cost far less than one fault-tolerant supercomputer.
- Disk vs memory: as RAM got cheaper, engines moved intermediate results from disk (MapReduce) to memory (Spark), trading memory for 10–100× faster iterative jobs.
- Separation of storage and compute: cloud object storage plus on-demand compute let teams scale each independently and pay per use. This is why modern warehouses and lakehouses look the way they do.
- Latency expectations: users went from accepting next-day reports to expecting live dashboards and instant fraud checks, which pushed streaming (Kafka, Flink) into the mainstream.
- Regulation and trust: privacy laws (Europe’s GDPR in 2018, India’s DPDP Act in 2023) made governance, lineage and deletion first-class requirements.
Exam tip: For “Explain the evolution of big data technologies”, write the eras in order with one tool and one reason each: RDBMS/warehouse → GFS + MapReduce (Hadoop: HDFS, MapReduce) → NoSQL and Hive → Spark (in-memory) and Kafka (streaming) → cloud warehouses → lakehouse. Mention the 2003/2004/2006 Google papers by name.
Five eras of data technology
1. One big database (to ~2003)
Everything in a powerful relational database, plus a separate data warehouse for reports. Scale up when it gets slow.
Scale up2. Hadoop era (2006–2012)
HDFS stores huge files across cheap machines; MapReduce processes them in parallel in nightly batches.
Batch on clusters3. Specialised tools (2008–2015)
Hive for SQL, HBase/Cassandra/MongoDB for fast look-ups, Kafka for streams, Spark for fast processing.
Right tool per job4. Cloud era (2012 →)
Object storage plus warehouses rented by the hour (BigQuery, Redshift, Snowflake). No servers to manage.
Pay per use5. Lakehouse and AI (2019 →)
Open table formats over cheap storage serve BI, streaming and ML from one copy; AI assistants write the queries.
One copy, many usesThe famous papers and what they became
| Paper (year) | Problem it solved | Open-source descendant |
|---|---|---|
| Google File System (2003) | Store files bigger than any disk, on machines that fail | HDFS |
| MapReduce (2004) | Process those files in parallel without writing distributed code by hand | Hadoop MapReduce (later Spark, Flink) |
| Bigtable (2006) | Fast reads and writes on a table with billions of rows | HBase, and partly Cassandra |
| Amazon Dynamo (2007) | A shopping cart that is always available, even during failures | Cassandra, Riak, DynamoDB |
| Google Dremel (2010) | Interactive SQL over huge nested data in seconds | BigQuery, Apache Drill, ideas in Parquet |
| Spark / RDD paper (2012) | Fast repeated computations with fault tolerance | Apache Spark |
A pattern worth noticing: big companies hit a wall first, publish a paper or open-source their tool, and the rest of the industry adopts it a few years later. Watching what large platforms build today is a good hint of what you’ll use tomorrow.
Twenty-five years in six steps
2000: one server and a nightly report
A bank keeps every transaction in one large Oracle database. A data warehouse is loaded each night, and managers read reports the next morning.
It works while data is gigabytes. When it grows, the only answer is a bigger, far costlier server. That is scaling up, and it has a ceiling.2003–2004: Google writes down its secret
Google’s index of the web is far too big for any server. Its engineers store files as 64 MB blocks with 3 copies across thousands of cheap machines (GFS), and process them with two simple functions,
The key ideas: expect failure, move code to data, and let a framework handle splitting, scheduling and retries. Google published both papers.mapandreduce.2006–2008: Hadoop makes it free
Doug Cutting and Mike Cafarella build an open-source version for their web-search project. Yahoo! hires Cutting and runs it at huge scale. It becomes Apache Hadoop: HDFS + MapReduce.
Now any company can run a cluster on ordinary servers. Facebook adds Hive so analysts can write SQL instead of Java MapReduce code.2009–2014: faster and more varied
MapReduce writes to disk after every step, so jobs with many steps are slow. Spark keeps data in memory. Kafka carries events in real time. NoSQL databases serve apps that need millisecond look-ups.
The single “Hadoop stack” becomes an ecosystem of specialised tools, each solving one weakness of the original.2012 onwards: rent, don’t buy
Instead of running their own clusters, companies store data in cloud object storage and query it with warehouses billed by usage: BigQuery, Redshift, Snowflake.
Storage and compute are separated: keep petabytes cheaply, and rent 100 machines for 10 minutes when a query needs them.Today: one copy for everything, and AI on top
Table formats (Delta Lake, Iceberg, Hudi) add transactions and updates to files in the lake. The same tables feed dashboards, streaming jobs and ML models, and AI assistants turn questions into SQL.
This is the lakehouse. Under the hood, it still uses the 2003 ideas: blocks, copies, parallel tasks and re-running failed work.
What users saw, and what engineers built
Step through the six frames. Left: what ordinary people saw on their screens in each era. Right: what engineers were building behind it.
- 2000: people visit websites on desktop computers. Pages change slowly.
- 2004: a search box answers from billions of web pages in a fraction of a second.
- 2008: social feeds: every like, post and photo is new data, all day.
- 2012: smartphones put an app for everything in every pocket.
- 2016: in India, UPI makes payments instant and cheap 4G brings crores of people online at once.
- Today: you ask a question in plain language and get an answer from huge data in seconds.
- One powerful database server, plus a data warehouse loaded every night. To grow, buy a bigger server.
- Google’s answer: GFS stores 64 MB blocks with 3 copies on thousands of cheap machines; MapReduce processes them in parallel and re-runs failed tasks.
- Hadoop brings the same ideas to everyone for free. Hive adds SQL; HBase and Cassandra add fast look-ups.
- Spark keeps data in memory for speed, Kafka carries events live, and the cloud lets teams rent storage and warehouses.
- Everything becomes a stream of events. Storage and compute are separated, so each can grow on its own.
- Lakehouse tables serve dashboards, streaming and AI from one copy of data. Underneath, the 2003 ideas still do the work.
Real-time scenarios: the history in action
Three live scenarios: the same business question answered in five eras, the five forces that made big data necessary, and an advanced look at why in-memory processing took over.
Real-time scenario 1The same question in five eras
TiffinGo-sized data: a 10 TB orders table. The manager asks the simplest question: how many orders per city yesterday? Watch how the work, the code and the waiting time change across the eras. The bar shows how long the wait feels (longer bar = faster answer).
- 2000: on one big database, scanning 10 TB with a GROUP BY can take all night, and DBAs often stop such queries because they slow the live business.
- 2008: with Hadoop, an engineer writes a MapReduce program in Java. It runs on hundreds of cheap machines and finishes in about an hour, writing to disk between the map and reduce steps.
- 2014: with Spark, the same job is three lines (read, group, count) and data stays in memory: minutes.
- 2018: in a cloud warehouse it is one SQL statement, with no servers to manage, billed by data scanned: seconds.
- Today: the manager types the question in plain language; an AI assistant writes the SQL, and the lakehouse runs it. (All times are illustrative.)
Five forces that created big data
Big data didn’t appear because someone invented Hadoop. Five changes in the world made it necessary, and each one still shapes how platforms are built.
- Cheap storage: the cost of a GB of disk fell by more than a million times over about three decades. Companies started keeping every click and log, which created the volume.
- Commodity clusters: instead of one fault-tolerant supercomputer, use thousands of cheap servers and let software handle failures. This is the Google/Hadoop insight.
- Phones and cheap data: smartphones, and in India the 2016 mobile-data price drop, put crores of people online. Every tap, payment and ride became an event: velocity and variety.
- The cloud: renting machines by the minute means a two-person startup can use the same scale as a giant, and pay only for what it uses.
- AI: modern models need enormous, clean, well-documented data. That pushes quality, governance and lakehouse tables to the centre.
Why Spark replaced MapReduce for most jobs
Machine learning and graph algorithms repeat the same calculation many times over the same data. Watch the two engines run a 5-step job, and see how Spark still recovers from a failure without saving every step to disk.
- An iterative job: each pass improves a model using the result of the previous pass. Both engines start the first step together.
- MapReduce writes each step’s output to HDFS, with 3 copies, then reads it back for the next step. Spark keeps the intermediate data in memory across steps.
- Spark has finished all five steps while MapReduce is still waiting on disk for step 3.
- For iterative work, avoiding the disk round-trips often makes Spark 10–100 times faster. That is why the Spark paper caught on so quickly.
- Fault tolerance without saving every step: Spark records the lineage (the recipe used to build each piece of data), so when a machine fails it recomputes only the lost piece from its parent. (Timings are illustrative.)
History you can see in today’s job descriptions
1. Banks and telecom still run Hadoop clusters
Many large Indian banks and telecom companies built on-premises Hadoop clusters in the 2010s. They still run HDFS and Hive for regulatory reports and are gradually moving to Spark, cloud or lakehouse platforms. Knowing both worlds is valuable.
2. Start-ups are born “streaming-first”
Food-delivery, ride-hailing and fintech start-ups founded after 2015 usually put Kafka (or a cloud equivalent) at the centre from day one, because their products are real-time.
3. New platforms are lakehouses
Teams building fresh platforms today usually choose cloud object storage with Delta Lake or Iceberg tables and Spark or SQL engines on top, instead of a separate lake and warehouse.
4. AI raises the bar on data quality
Companies training or grounding AI models need well-documented, high-quality, legally collected data. Data engineers with governance and lineage skills are in demand because of this latest shift.
A timeline you can query
The milestones of big data are stored as a list of tuples: (year, event, era). The program prints the timeline and counts the events in each era. Change it, then try the challenges: find gaps between a paper and its open-source copy, sort events, and follow the “family tree” of tools.
timeline = [
(2003, "GFS paper", "Google papers"),
(2004, "MapReduce paper", "Google papers"),
(2006, "Hadoop starts", "Hadoop era"),
(2008, "Hive open-sourced", "Hadoop era"),
(2011, "Kafka open-sourced", "Specialised tools"),
(2014, "Spark 1.0", "Specialised tools"),
(2012, "Redshift announced", "Cloud"),
(2019, "Delta Lake open-sourced", "Lakehouse"),
]
for year, event, era in sorted(timeline):
print(year, "-", event)
per_era = {}
for year, event, era in timeline:
per_era[era] = per_era.get(era, 0) + 1
print("Events per era:", per_era)(2003, "GFS paper", "Google papers"),Each milestone is a tuple: (year, event, era). Tuples keep related values together.for year, event, era in sorted(timeline):sortedorders tuples by their first item, the year, so the 2012 entry moves into place.per_era[era] = per_era.get(era, 0) + 1The counting pattern: start at 0 for a new era, add 1 each time.
Run it on your PC: your life on the big data timeline
This program prints the milestones grouped by era, with a small text bar, and tells you how old you were at each one. Save it as history_timeline.py, change BORN to your birth year, and run it.
The timeline, grouped by era
"""Print the big data timeline as a text chart, grouped by era.
Change BORN to your birth year to see how old you were at each milestone."""
BORN = 2006
NOW = 2026
milestones = [
(1997, "Term 'big data' used by NASA researchers", "Before Hadoop"),
(2001, "Doug Laney describes the 3 Vs", "Before Hadoop"),
(2003, "Google File System paper", "Google papers"),
(2004, "MapReduce paper", "Google papers"),
(2006, "Bigtable paper; Hadoop starts; Amazon S3", "Google papers"),
(2008, "Hadoop top-level Apache project; Hive, Cassandra", "Ecosystem"),
(2011, "Kafka open-sourced by LinkedIn", "Ecosystem"),
(2014, "Spark 1.0, Apache top-level project", "Ecosystem"),
(2016, "UPI launched; cheap 4G in India", "Cloud and mobile"),
(2019, "Delta Lake open-sourced", "Lakehouse"),
(2023, "India's DPDP Act passed", "Lakehouse"),
]
era = None
for year, event, group in milestones:
if group != era:
era = group
print(f"\n== {era} ==")
age = year - BORN
when = f"you were {age}" if age >= 0 else f"{-age} years before you were born"
bar = "#" * ((year - 1995) // 2)
print(f"{year} {bar:<16} {event} ({when})")
span = milestones[-1][0] - milestones[0][0]
print(f"\n{len(milestones)} milestones over {span} years; {NOW - 2003} years since the GFS paper.")
# In a terminal: python history_timeline.pyRecorded from a real run with Python 3.13 and BORN = 2006. Your output changes with your birth year. The bar length grows by one # every two years after 1995, so later events have longer bars.
Paper to open source, one line at a time
The program works out how many years passed between each Google paper and its open-source copy, and keeps the longest gap. Watch longest change only when a bigger gap appears.
Worked examples: real problems, solved and traced in memory
Four small programs about the history, from grouping events by decade to walking a family tree of tools. Each runs live and is traced.
Group milestones by decade
Problem statement
Group these milestone years by decade (1990s, 2000s, 2010s, 2020s) and print how many fall in each.
1997, 2001, 2003, 2004, 2006, 2008, 2011, 2014, 2016, 2019, 2023
1990s: 1 milestones 2000s: 5 milestones 2010s: 4 milestones 2020s: 1 milestones
Approach
- The decade of a year is
year // 10 * 10(2014 → 2010). - Count with a dictionary.
- Print the decades in order.
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 long did the open-source world take to catch up?
Problem statement
For each research paper, find the gap to its open-source version, then print the average gap and the pair with the shortest gap.
GFS 2003→HDFS 2006 · MapReduce 2004→Hadoop 2006 · Bigtable 2006→HBase 2008 · Dynamo 2007→Cassandra 2008
Gaps: [3, 2, 2, 1] Average: 2.0 years Fastest copy: Dynamo -> Cassandra
Approach
- Store each pair as a tuple (paper, paper year, clone, clone year).
- Compute the gap for each and keep a list.
- Use
minwith a key to find the shortest gap.
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.
Match each requirement to the era that solved it
Problem statement
A team lists its needs. For each need, print the tool family that was invented for it and the year it appeared.
store 500 TB of files, live order events, fast ML training loops, SQL for analysts
2006: store 500 TB of files -> HDFS / object storage 2008: SQL for analysts -> Hive, later cloud warehouses 2011: live order events -> Kafka 2014: fast ML training loops -> Spark
Approach
- Keep a dictionary need → (tool, year).
- Loop over the team's needs and look each one up.
- Sort the result by year to see the order the problems were solved in.
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.
Find every tool descended from one paper
Problem statement
Each tool lists the tools or papers that inspired it (some have two parents). Find all descendants of the Bigtable paper, at any depth.
HBase ← Bigtable · Cassandra ← Bigtable, Dynamo · ScyllaDB ← Cassandra · DynamoDB ← Dynamo
Descended from Bigtable : ['HBase', 'Cassandra', 'ScyllaDB']
Approach
- Store parents as lists:
{"Cassandra": ["Bigtable", "Dynamo"], …}. - Start a “to visit” list with the paper. Repeatedly take one item and find every tool whose parents include it.
- Add new descendants to the result and to the list to visit (this is breadth-first search).
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.4 in one screen
- Term “big data”: NASA researchers, 1997. The 3 Vs: Doug Laney, 2001.
- Google papers: GFS (2003) → HDFS · MapReduce (2004) → Hadoop MapReduce · Bigtable (2006) → HBase. Amazon Dynamo (2007) → Cassandra (with Bigtable).
- Hadoop (2006, Doug Cutting and Mike Cafarella, backed by Yahoo!; named after a toy elephant). Apache top-level 2008.
- Hive (Facebook, SQL on Hadoop) · Kafka (LinkedIn, 2011) · Spark (UC Berkeley, 2009; Apache top-level 2014).
- Cloud: S3 (2006), BigQuery, Redshift, Snowflake. Storage and compute separated; pay per use.
- Lakehouse: Delta Lake, Iceberg, Hudi over object storage. One copy for BI, streaming and ML.
- Forces: cheap storage, commodity clusters, phones and cheap data, the cloud, AI.
Interview and viva questions
Explain the evolution of big data technologies.
Before 2000 data lived in single relational databases and warehouses that scaled up. Google's GFS (2003) and MapReduce (2004) papers showed how to store and process data on clusters of commodity machines; Hadoop (2006) implemented them as open source. Hive added SQL, and NoSQL stores (HBase, Cassandra, MongoDB) served fast look-ups. Spark brought in-memory processing and Kafka real-time streams. Cloud platforms separated storage from compute (S3, BigQuery, Redshift, Snowflake). Today lakehouses use open table formats (Delta Lake, Iceberg, Hudi) to serve BI, streaming and ML from one copy of the data.
Why was Hadoop named Hadoop?
Doug Cutting named it after his son's toy elephant, which is why the logo is a yellow elephant.
What problems of MapReduce did Spark solve?
MapReduce writes intermediate results to disk between steps, is hard to program (low-level map and reduce functions), and is slow for iterative and interactive work. Spark keeps intermediate data in memory, plans whole multi-step jobs as a DAG, recovers lost data through lineage, and offers high-level APIs (DataFrames, SQL, streaming, MLlib).
Is Hadoop dead?
Hadoop MapReduce is rarely used for new work, but HDFS, YARN and Hive still run in many enterprises, and their ideas live on in Spark, cloud object storage and lakehouses. Many companies are migrating from on-premises Hadoop to cloud or lakehouse platforms, so the knowledge remains useful.
What is the lakehouse and how is it different from earlier architectures?
Earlier platforms kept raw data in a lake and a separate, cleaned copy in a warehouse. A lakehouse stores data once in open formats on cheap object storage and adds a table layer (Delta Lake, Iceberg, Hudi) that provides transactions, schema enforcement, updates and time travel, so the same tables serve BI, streaming and machine learning.
Practice problems
Small programs built around the timeline. The last two are business tasks about technology decisions.
Years since a milestone
Print how many years have passed between each milestone and 2026.
GFS 2003, Hadoop 2006, Kafka 2011, Spark 2014
GFS 23 years ago Hadoop 20 years ago Kafka 15 years ago Spark 12 years ago
Show solution and explanation
milestones = {"GFS": 2003, "Hadoop": 2006, "Kafka": 2011, "Spark": 2014}
for name, year in milestones.items():
print(name, 2026 - year, "years ago")How it works: A dictionary maps each name to its year; subtract from the current year.
Earliest and latest
Print the earliest and latest milestone years from the list.
[2011, 2003, 2019, 2006, 2014]
Earliest: 2003 Latest: 2019
Show solution and explanation
years = [2011, 2003, 2019, 2006, 2014]
print("Earliest:", min(years))
print("Latest:", max(years))How it works: min and max work on any list of numbers.
Name the creator
Look up which organisation created each tool and print it.
Hive, Kafka, Spark, Iceberg
Hive was created at Facebook Kafka was created at LinkedIn Spark was created at UC Berkeley Iceberg was created at Netflix
Show solution and explanation
created_at = {"Hive": "Facebook", "Kafka": "LinkedIn", "Spark": "UC Berkeley", "Iceberg": "Netflix"}
for tool in ["Hive", "Kafka", "Spark", "Iceberg"]:
print(f"{tool} was created at {created_at[tool]}")How it works: Dictionary look-up by key.
Events in a range
Print only the events between 2005 and 2015 (inclusive), in year order.
6 events
2006 Hadoop 2008 Hive 2011 Kafka 2014 Spark 1.0
Show solution and explanation
events = [(2019, "Delta Lake"), (2006, "Hadoop"), (2003, "GFS"),
(2011, "Kafka"), (2014, "Spark 1.0"), (2008, "Hive")]
for year, name in sorted(events):
if 2005 <= year <= 2015:
print(year, name)How it works: Sort the tuples by year, then filter with a chained comparison.
Tools per era
Given each tool's year, count how many belong to each era: before 2009, 2009–2018, 2019 onwards.
Hadoop 2006, Hive 2008, Kafka 2011, Spark 2014, Snowflake 2015, Delta 2019, Iceberg 2018
{'Hadoop era': 2, 'Specialised + cloud': 4, 'Lakehouse': 1}Show solution and explanation
tools = {"Hadoop": 2006, "Hive": 2008, "Kafka": 2011, "Spark": 2014,
"Snowflake": 2015, "Delta": 2019, "Iceberg": 2018}
eras = {"Hadoop era": 0, "Specialised + cloud": 0, "Lakehouse": 0}
for name, y in tools.items():
if y < 2009:
eras["Hadoop era"] += 1
elif y < 2019:
eras["Specialised + cloud"] += 1
else:
eras["Lakehouse"] += 1
print(eras)How it works: An if/elif chain puts each year into exactly one bucket.
Follow the chain of inspiration
Each tool points to the one that inspired it. Print the chain from Delta Lake back to the start.
Delta Lake ← Hive tables ← Hadoop ← GFS
Delta Lake <- Hive tables <- Hadoop <- GFS
Show solution and explanation
inspired_by = {"Delta Lake": "Hive tables", "Hive tables": "Hadoop", "Hadoop": "GFS"}
tool = "Delta Lake"
chain = [tool]
while tool in inspired_by:
tool = inspired_by[tool]
chain.append(tool)
print(" <- ".join(chain))How it works: A while loop follows links until a tool has no recorded parent.
Disk round-trips saved
An iterative job has 8 steps. MapReduce writes 100 GB with 3 copies and reads it back between every pair of steps, at 2 GB/s. Print the total disk time in minutes that Spark avoids by keeping the data in memory.
8 steps, 100 GB, 3 copies, 2 GB/s
Seconds per gap: 200.0 Minutes saved: 23.3
Show solution and explanation
steps, gb, copies, speed = 8, 100, 3, 2
per_gap = (gb * copies + gb) / speed
total = (steps - 1) * per_gap
print("Seconds per gap:", per_gap)
print("Minutes saved:", round(total / 60, 1))How it works: Between each pair of steps MapReduce writes (with copies) and reads the data. 7 gaps × 200 s ≈ 23 minutes of pure disk time.
Buy a bigger server or rent the cloud?
A big server costs Rs 90 lakh and lasts 5 years. The same work in the cloud costs Rs 1,200 per hour, and the job runs 4 hours a day. Compare the 5-year cost.
Rs 90 lakh · Rs 1,200/hour × 4 h/day × 365 × 5
Server, 5 years: Rs 9000000 Cloud, 5 years : Rs 8760000 Cheaper: cloud
Show solution and explanation
server = 90_00_000
cloud = 1200 * 4 * 365 * 5
print("Server, 5 years: Rs", server)
print("Cloud, 5 years : Rs", cloud)
print("Cheaper:", "cloud" if cloud < server else "server")How it works: Pay-per-use wins when machines would otherwise sit idle most of the day. If the job ran 24 hours a day, the answer could flip.
Migration progress
A bank is moving 120 Hive jobs from Hadoop to a lakehouse. It moves 8 jobs a week. How many weeks until done, and what percentage is done after 6 weeks?
120 jobs, 8 per week
Weeks needed: 15 Done after 6 weeks: 40 %
Show solution and explanation
import math
jobs, per_week = 120, 8
print("Weeks needed:", math.ceil(jobs / per_week))
print("Done after 6 weeks:", round(6 * per_week / jobs * 100), "%")How it works: math.ceil rounds up, because a part-week still counts as a week.
Real-world scenario questions (asked in company interviews)
History questions that interviewers use to test real understanding. Decide your answer first, then open the model answer.
“Why was Hadoop created?”
An interviewer opens with: “In two minutes, why was Hadoop created and what problem did it solve?”
The interviewer is checking: do you understand the problem behind the tool, not just its name?
Show a strong answer
Around 2003 web-scale data no longer fitted on one machine, and scaling up was too expensive and had a ceiling. Google published GFS and MapReduce, showing how to store data as replicated blocks on many cheap machines and process it in parallel with automatic retries. Hadoop (2006) implemented these ideas as open source: HDFS for storage and MapReduce for processing, later YARN for resource management.
Avoid: listing Hadoop components without saying what problem they solve.
An old Hadoop cluster and a cloud proposal
Your company runs a 10-year-old on-premises Hadoop cluster with Hive jobs. Leadership asks whether to move to a cloud lakehouse.
The interviewer is checking: can you weigh history, cost and risk instead of following fashion?
Show a strong answer
- List what runs today: Hive SQL, MapReduce jobs, Spark jobs, downstream reports and their deadlines.
- Compare total cost: hardware refresh, admin staff and licences versus cloud storage and compute.
- Check rules: data that must stay in India (choose an Indian cloud region), security and audit needs.
- Plan in phases: copy data to object storage, convert tables to Parquet/Delta or Iceberg, move Hive SQL to Spark SQL, run both systems in parallel and compare outputs before switching off.
Avoid: “Hadoop is old, so throw it away tomorrow” or “it works, never touch it”.
Why not just use MapReduce today?
A teammate says, “Spark is just faster MapReduce, so the ideas are the same.” The interviewer asks you to agree or disagree.
The interviewer is checking: do you know what Spark actually changed, and what it kept?
Show a strong answer
Partly agree. Spark keeps the core ideas: partitioned data, parallel tasks, a shuffle for grouping, and re-running failed work. It changed three things: it keeps intermediate data in memory instead of writing to HDFS after every step, it builds a DAG of many steps and optimises the whole plan, and it recovers using lineage instead of replicated intermediate files. It also offers high-level APIs (DataFrames, SQL, streaming, MLlib) instead of hand-written map and reduce functions.
Avoid: saying they are completely different, or that Spark doesn’t need fault tolerance.
“Should I still learn Hadoop in 2026?”
A junior asks you whether learning Hadoop is a waste of time now that lakehouses exist.
The interviewer is checking: can you give balanced, practical advice?
Show a strong answer
Learn the ideas deeply (HDFS blocks and replication, MapReduce, YARN), because Spark, cloud storage and lakehouses are built on them and interviews still ask them. Spend most hands-on time on Spark, SQL, Kafka, a cloud platform and a table format. Many large Indian enterprises still run Hadoop, so knowing it helps with migration projects.
Avoid: dismissing old tools completely, or spending months on MapReduce Java code.