A short history of big data: from one server to the lakehouse

Hadoop, Hive, Spark, Kafka, Delta Lake… each tool was built because the one before it hit a wall. In this lesson you follow five eras in about twenty-five years, see what users saw and what engineers built in each, watch the same question get answered in five eras, and learn why in-memory processing replaced MapReduce. After this, the whole ecosystem will make sense as one story.

Module 1 · Introduction⏱ 25 minBeginner → AdvancedRuns in your browser (Python)3 real-time scenariosTimeline program for your PC9 practice problems
1 The story

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?

1997term “big data”2003GFS paper2004MapReduce2006Hadoop · S32011Kafka2014Spark 1.02016UPI · Jio2019Delta Laketodaylakehouse · AI Each tool was invented to solve one problem the previous tools could not. myphatshala.in
Riya

Sir, why is it called Hadoop? It sounds like a cartoon.

Arjun Sir

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.

Kabir

And Kafka? TiffinGo’s tech blog mentions it everywhere.

Arjun Sir

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.

Riya

What do you mean by reasons?

Arjun Sir

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.

Kabir

So history is actually a map of the ecosystem?

Arjun Sir

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.

2 Definition

How did big data begin?

Formal definition (write this in exams)

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.

In simple words

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

Research paperA public write-up of how a system works. Google, Amazon and others published papers that the open-source world then implemented.
Open sourceSoftware whose code is free to use, read and change, usually managed by a foundation such as Apache.
Apache Software FoundationThe non-profit that hosts Hadoop, Spark, Kafka, Hive, Cassandra, Iceberg and hundreds of other projects.
Commodity hardwareOrdinary, inexpensive servers instead of special fault-tolerant machines.
In-memory processingKeeping data in RAM between steps instead of writing it to disk each time.
Separation of storage and computeStoring data in one place (object storage) and renting processing power separately, only when needed.
LakehouseLake storage plus table formats that add database features (transactions, updates, time travel).

Milestones to remember

1997NASA researchers Michael Cox and David Ellsworth use the term “big data” for datasets too large for memory and disk
2001Analyst Doug Laney describes Volume, Velocity and Variety (the 3 Vs)
2003 · 2004 · 2006Google publishes the GFS, MapReduce and Bigtable papers
2006Hadoop starts (Doug Cutting, Mike Cafarella; strongly backed by Yahoo!). Amazon launches S3 and EC2
2008Hadoop becomes a top-level Apache project; Facebook open-sources Hive and Cassandra
2011LinkedIn open-sources Kafka
2014Spark becomes a top-level Apache project and reaches version 1.0
2016India 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

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

Beginner Five eras in one breath

  1. Before 2000, one big database: companies kept data in one powerful server (Oracle, IBM DB2, mainframes) and built data warehouses for reports.
  2. 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.
  3. 2008–2014, more tools for more jobs: SQL on Hadoop (Hive), NoSQL databases (HBase, Cassandra, MongoDB), streaming (Kafka) and faster in-memory processing (Spark).
  4. 2010s, the cloud: rent storage (Amazon S3) and warehouses (BigQuery, Redshift, Snowflake) by the hour instead of buying servers.
  5. 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.

3 Types and ways to use it

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 up

2. Hadoop era (2006–2012)

HDFS stores huge files across cheap machines; MapReduce processes them in parallel in nightly batches.

Batch on clusters

3. Specialised tools (2008–2015)

Hive for SQL, HBase/Cassandra/MongoDB for fast look-ups, Kafka for streams, Spark for fast processing.

Right tool per job

4. Cloud era (2012 →)

Object storage plus warehouses rented by the hour (BigQuery, Redshift, Snowflake). No servers to manage.

Pay per use

5. 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 uses

The famous papers and what they became

Paper (year)Problem it solvedOpen-source descendant
Google File System (2003)Store files bigger than any disk, on machines that failHDFS
MapReduce (2004)Process those files in parallel without writing distributed code by handHadoop MapReduce (later Spark, Flink)
Bigtable (2006)Fast reads and writes on a table with billions of rowsHBase, and partly Cassandra
Amazon Dynamo (2007)A shopping cart that is always available, even during failuresCassandra, Riak, DynamoDB
Google Dremel (2010)Interactive SQL over huge nested data in secondsBigQuery, Apache Drill, ideas in Parquet
Spark / RDD paper (2012)Fast repeated computations with fault toleranceApache 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.

4 Step by step

Twenty-five years in six steps

  1. 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.
  2. 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, map and reduce.

    The key ideas: expect failure, move code to data, and let a framework handle splitting, scheduling and retries. Google published both papers.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
5 See it happen

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.

What users saw, and what engineers built 6 steps
What you see 2000Welcome to MyPortalA desktop web page, refreshed by hand2004cheap flights to GoaResult 1 · relevant pageResult 2 · relevant pageResult 3 · relevant pageBillions of pages searched in 0.3 s2008Friends’ posts, likes, photos2012An app for everything, all day2016Paid ₹20UPI · 2 seconds4G video · 1 GB/dayCrores of new users, all onlineTodayWhich city orderedmost this week?Pune: 41,200Mumbai: 38,900answer in secondsAsk in plain language myphatshala.in
Behind the screen One big serverOracle / DB2scale up = buy biggerNightly data warehouse loadGigabytes. Reports next morning.GFS: 64 MB blocks × 3 copiesMapReduce: map → shuffle → reduceThousands of cheap machines.Failure is normal; tasks re-run.HadoopHDFS + MapReduce(open source, 2006)HiveSQL → MapReduce(Facebook, 2008)HBase · CassandraNoSQL look-ups(2008)Yahoo! clustersthousands of nodesnightly batchesThe ecosystem begins.Sparkin-memory steps10–100× faster loopsKafkareal-time event log(LinkedIn, 2011)Cloud: S3 storage + warehouses by the hourBigQuery · Redshift · SnowflakeBatch + streaming + cloud.Streams everywhereevery payment, click and ride is an eventStorageobject storage, PBcheap, always onComputerented per queryscales to the peakStorage and compute separated.Lakehouse tables (Delta · Iceberg · Hudi)one copy of data, with transactionsBIdashboardsStreamingliveAI / MLmodels, chatUnderneath: still blocks, copies,parallel tasks and re-runs from 2003. myphatshala.in
6 Real-world use

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 1

The 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).

One question, 25 years 5 steps
Animated example Question: orders per city yesterday, from a 10 TB table2000 · one databaseSQL on one big servertime to answer~10+ hoursQuery runs all night; often killed forblocking the morning business. Answer: maybe tomorrow.2008 · Hadoop MapReduce≈ 150 lines of Java (map + reduce)time to answer~1 hourRuns on 200 cheap nodes in parallel.Writes to disk between steps. Answer in about an hour.2014 · Spark3 lines: read · groupBy · counttime to answer~5 minutesSame cluster, data kept in memory.Answer in a few minutes.2018 · cloud warehouseSELECT city, COUNT(*) … GROUP BY citytime to answer~20 secondsNo cluster to manage; billed per query.Answer in seconds.Today · lakehouse + AI“Which city ordered most yesterday?”time to answersecondsAn assistant writes the SQL; thelakehouse runs it over open tables. myphatshala.in
Real-time scenario 2

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.

Why it happened 5 steps
Animated example Force 1Force 2Force 3Force 4Force 5Force 1 · storage became nearly freeDisk cost per GB fell more than a million timesfrom 1980 to the 2010s. Keeping everything gotcheaper than deciding what to delete → volume.Force 1Force 2Force 3Force 4Force 5Force 2 · cheap clusters beat big serversSoftware that expects failure lets thousands ofordinary machines replace one costly supercomputer.→ scale out instead of scale up.Force 1Force 2Force 3Force 4Force 5Force 3 · phones and cheap dataSmartphones, and in India cheap 4G from 2016,put crores of people online all day. Every tap isan event → velocity and variety.Force 1Force 2Force 3Force 4Force 5Force 4 · the cloudRent 100 machines for 10 minutes. No buying,no data-centre. Startups get the same toolsas giants → big data for everyone.Force 1Force 2Force 3Force 4Force 5Force 5 · AI needs dataMachine-learning and AI models are trained onhuge, clean, well-governed datasets → quality,lineage and lakehouses matter more than ever. myphatshala.in
Real-time scenario 3 · advanced

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.

Disk between steps vs memory 5 steps
Animated example MapReduceS1diskS2S3S4S5SparkS1S2S3S4S5One iterative job, two engines (5 steps)An ML model improves itself in 5 passes over the same data.Both engines start step 1.MapReduceS1diskS2S3S4S5SparkS1S2S3S4S5One iterative job, two engines (5 steps)MapReduce writes every step’s result to HDFS (3 copies)and reads it back for the next step. Spark keeps it in memory.MapReduceS1diskS2S3S4S5SparkS1S2S3S4S5One iterative job, two engines (5 steps)Spark has finished all 5 steps.MapReduce is still on step 3, waiting on disk.MapReduceS1diskS2S3S4S5SparkS1S2S3S4S5One iterative job, two engines (5 steps)MapReduce finishes last. For loops like this, keeping datain memory is often 10–100× faster.MapReduceS1diskS2S3S4S5SparkS1S2S3S4S5lost piece of S2 → rebuilt from S1One iterative job, two engines (5 steps)A machine dies? Spark knows how each piece was made(its lineage) and recomputes only the lost piece. myphatshala.in

History you can see in today’s job descriptions

HDFS

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.

On-prem HDFS + Hive→Migration to Spark / cloud→Lakehouse
Kafka

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.

App events→Kafka→Live features + lake
Delta / Icebergon S3 / ADLS

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.

Object storage→Open table format→BI + ML
AI

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.

Raw data→Clean, governed tables→AI models
7 Run the code

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 2004 - MapReduce paper 2006 - Hadoop starts 2008 - Hive open-sourced 2011 - Kafka open-sourced 2012 - Redshift announced 2014 - Spark 1.0 2019 - Delta Lake open-sourced Events per era: {'Google papers': 2, 'Hadoop era': 2, 'Specialised tools': 2, 'Cloud': 1, 'Lakehouse': 1}
  • (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):sorted orders 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.py
== Before Hadoop == 1997 # Term 'big data' used by NASA researchers (9 years before you were born) 2001 ### Doug Laney describes the 3 Vs (5 years before you were born) == Google papers == 2003 #### Google File System paper (3 years before you were born) 2004 #### MapReduce paper (2 years before you were born) 2006 ##### Bigtable paper; Hadoop starts; Amazon S3 (you were 0) == Ecosystem == 2008 ###### Hadoop top-level Apache project; Hive, Cassandra (you were 2) 2011 ######## Kafka open-sourced by LinkedIn (you were 5) 2014 ######### Spark 1.0, Apache top-level project (you were 8) == Cloud and mobile == 2016 ########## UPI launched; cheap 4G in India (you were 10) == Lakehouse == 2019 ############ Delta Lake open-sourced (you were 13) 2023 ############## India's DPDP Act passed (you were 17) 11 milestones over 26 years; 23 years since the GFS paper.

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

8 Line by line

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.

Example 1BeginnerRevision · timeline

Group milestones by decade

Problem statement

Group these milestone years by decade (1990s, 2000s, 2010s, 2020s) and print how many fall in each.

Input
1997, 2001, 2003, 2004, 2006, 2008, 2011, 2014, 2016, 2019, 2023
Expected output
1990s: 1 milestones
2000s: 5 milestones
2010s: 4 milestones
2020s: 1 milestones

Approach

  1. The decade of a year is year // 10 * 10 (2014 → 2010).
  2. Count with a dictionary.
  3. 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.

Example 2IntermediateHistory · lag

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.

Input
GFS 2003→HDFS 2006 · MapReduce 2004→Hadoop 2006 · Bigtable 2006→HBase 2008 · Dynamo 2007→Cassandra 2008
Expected output
Gaps: [3, 2, 2, 1]
Average: 2.0 years
Fastest copy: Dynamo -> Cassandra

Approach

  1. Store each pair as a tuple (paper, paper year, clone, clone year).
  2. Compute the gap for each and keep a list.
  3. Use min with 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.

Example 3IntermediateArchitecture · choosing tools

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.

Input
store 500 TB of files, live order events, fast ML training loops, SQL for analysts
Expected output
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

  1. Keep a dictionary need → (tool, year).
  2. Loop over the team's needs and look each one up.
  3. 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.

Example 4AdvancedEcosystem · family tree

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.

Input
HBase ← Bigtable · Cassandra ← Bigtable, Dynamo · ScyllaDB ← Cassandra · DynamoDB ← Dynamo
Expected output
Descended from Bigtable : ['HBase', 'Cassandra', 'ScyllaDB']

Approach

  1. Store parents as lists: {"Cassandra": ["Bigtable", "Dynamo"], …}.
  2. Start a “to visit” list with the paper. Repeatedly take one item and find every tool whose parents include it.
  3. 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.

9 Quiz and revision

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.

P1Easy

Years since a milestone

Print how many years have passed between each milestone and 2026.

Input
GFS 2003, Hadoop 2006, Kafka 2011, Spark 2014
Expected output
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")
GFS 23 years ago Hadoop 20 years ago Kafka 15 years ago Spark 12 years ago

How it works: A dictionary maps each name to its year; subtract from the current year.

P2Easy

Earliest and latest

Print the earliest and latest milestone years from the list.

Input
[2011, 2003, 2019, 2006, 2014]
Expected output
Earliest: 2003
Latest: 2019
Show solution and explanation
years = [2011, 2003, 2019, 2006, 2014]
print("Earliest:", min(years))
print("Latest:", max(years))
Earliest: 2003 Latest: 2019

How it works: min and max work on any list of numbers.

P3Easy

Name the creator

Look up which organisation created each tool and print it.

Input
Hive, Kafka, Spark, Iceberg
Expected output
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]}")
Hive was created at Facebook Kafka was created at LinkedIn Spark was created at UC Berkeley Iceberg was created at Netflix

How it works: Dictionary look-up by key.

P4Medium

Events in a range

Print only the events between 2005 and 2015 (inclusive), in year order.

Input
6 events
Expected output
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)
2006 Hadoop 2008 Hive 2011 Kafka 2014 Spark 1.0

How it works: Sort the tuples by year, then filter with a chained comparison.

P5Medium

Tools per era

Given each tool's year, count how many belong to each era: before 2009, 2009–2018, 2019 onwards.

Input
Hadoop 2006, Hive 2008, Kafka 2011, Spark 2014, Snowflake 2015, Delta 2019, Iceberg 2018
Expected output
{'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)
{'Hadoop era': 2, 'Specialised + cloud': 4, 'Lakehouse': 1}

How it works: An if/elif chain puts each year into exactly one bucket.

P6Advanced

Follow the chain of inspiration

Each tool points to the one that inspired it. Print the chain from Delta Lake back to the start.

Input
Delta Lake ← Hive tables ← Hadoop ← GFS
Expected output
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))
Delta Lake <- Hive tables <- Hadoop <- GFS

How it works: A while loop follows links until a tool has no recorded parent.

P7Advanced

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.

Input
8 steps, 100 GB, 3 copies, 2 GB/s
Expected output
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))
Seconds per gap: 200.0 Minutes saved: 23.3

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.

P8Business problem

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.

Input
Rs 90 lakh · Rs 1,200/hour × 4 h/day × 365 × 5
Expected output
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")
Server, 5 years: Rs 9000000 Cloud, 5 years : Rs 8760000 Cheaper: cloud

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.

P9Business problem

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?

Input
120 jobs, 8 per week
Expected output
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), "%")
Weeks needed: 15 Done after 6 weeks: 40 %

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.

Interview · fundamentalsFresher

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

Platform modernisation1–3 years

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

System design · reasoning1–3 years

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.

Career · learning planFresher

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