Jiaxi Liu (Jesse)

Master’s Graduate

Software Engineer | Scalable APIs · Web Scraping · Data Integration · Code Quality & Refactoring

Back to Blog

Big Data Review: Hadoop, Spark, and Hive

Big data systems solve a basic problem: data is too large for one machine to store or process efficiently, so storage and computation must be distributed.

Hadoop

Hadoop is a foundational big data framework. Core components:

  • HDFS: distributed file system
  • MapReduce: distributed compute model
  • YARN: resource scheduling

HDFS splits large files into blocks, stores them across machines, and uses replication for fault tolerance.

MapReduce has two stages:

  1. Map: each node processes its own data blocks
  2. Reduce: intermediate results are aggregated

It is reliable and scalable, but batch latency is high.

Spark

Spark is a large-scale data processing framework, usually faster than Hadoop MapReduce because it uses memory heavily.

Common components:

  • Spark Core
  • Spark SQL
  • Spark Streaming
  • MLlib
  • GraphX

Spark fits iterative computation, machine learning, interactive analysis, and streaming.

Spark vs Hadoop MapReduce

MapReduce is traditional batch processing and frequently writes intermediate data to disk.

Spark keeps intermediate data in memory when possible, making it better for multi-step workloads.

Hive

Hive is a data warehouse tool that lets users query data on HDFS with SQL-like syntax.

It fits:

  • Offline analysis
  • Reporting
  • Data warehousing
  • SQL access to big data

Hive is not a traditional OLTP database and is not suited for high-frequency low-latency transactions.

Summary

  • Hadoop: distributed storage and batch processing foundation
  • Spark: faster large-scale compute engine
  • Hive: SQL layer for analytical data warehouses

Deeper Notes

When reviewing this topic, do not memorize names only. Focus on HDFS, MapReduce, Spark in-memory processing, Hive SQL, and layered batch data platforms. If this stays at the definition level, it becomes hard to explain in interviews or apply in projects. A stronger way to study it is to place it in a concrete scenario: who calls it, where the input comes from, what happens on failure, and whether data or state can be processed twice.

  • Big data systems are about tradeoffs between throughput, fault tolerance, latency, and cost, not just tool syntax.
  • Separate batch processing, stream processing, interactive querying, and offline modeling before choosing Hadoop, Spark, or Hive.
  • A data platform also needs schema evolution, data quality, partitioning, lineage, and rerun cost control.

In a real project, use it as a decision framework: identify inputs, constraints, failure modes, and observability before choosing a specific tool or pattern. If a solution looks simple, keep asking whether it still works when scale grows, permissions change, recovery matters, and more people collaborate on it.

Practical Checklist

  • Identify where this concept sits in the system: development-time constraint, runtime behavior, infrastructure capability, or collaboration workflow.
  • Write one minimal working example and one failure example; only knowing the happy path is usually not enough.
  • Record common misuses: edge cases, permission assumptions, performance assumptions, sync/async differences, or environment differences.
  • Connect the concept to a project experience so that an interview answer can be grounded in real tradeoffs.
  • End with one sentence about tradeoff: what it gives up and what it buys.

Self-Check Questions

  1. What core problem does this topic solve?
  2. What alternatives exist, and what are their costs?
  3. Where are the most likely edge cases?
  4. How would code, tests, or monitoring prove that it is reliable?

Applied Scenario

A strong example is a log analytics platform. Services produce logs, data lands in object storage or HDFS, Spark cleans and aggregates it, Hive provides a SQL layer, and reports or features are generated downstream. The key questions are data volume, latency, rerun cost, and quality. Batch systems tolerate minutes or hours of delay but need stable reruns; streaming systems need lower latency but have harder state and fault tolerance requirements.

Common Pitfalls:

  • Not separating batch and streaming requirements.
  • Focusing on compute engines while ignoring partitioning and reruns.
  • Skipping quality checks, making downstream output hard to trust.