100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Programming

HDFS Architecture

How HDFS organizes a cluster around a master/worker design so it can store and stream massive files reliably across commodity hardware.

HDFSBeginner9 min readJul 10, 2026
Analogies

HDFS Architecture Overview

HDFS (Hadoop Distributed File System) is the primary storage layer of the Hadoop ecosystem, built to hold very large datasets, often terabytes to petabytes, across a cluster of inexpensive commodity servers. It follows a master/worker architecture: a single NameNode holds the filesystem namespace and metadata, while many DataNodes store the actual data as fixed-size blocks. Clients talk to the NameNode to locate data, then stream blocks directly to and from DataNodes, keeping metadata operations separate from bulk data transfer.

🏏

Cricket analogy: Like a franchise's head coach who doesn't bat but knows exactly which player is stationed where, while the batting lineup actually faces the deliveries, the NameNode tracks locations while DataNodes handle the real IPL-scale data traffic.

Master/Worker Design

The NameNode maintains the directory tree, file-to-block mapping, and block-to-DataNode location table entirely in memory for fast lookups, persisting only the namespace structure to disk via the FsImage and EditLog. DataNodes, by contrast, are simple workers: they store blocks on local disk, serve read and write requests from clients, and periodically send heartbeats and block reports back to the NameNode so it knows the cluster's real-time state.

🏏

Cricket analogy: Like a team's scorer keeping the full scorecard in a notebook for instant lookup while fielders occasionally radio back their position and fitness, similar to how DataNodes report heartbeats to the NameNode.

bash
# Check overall cluster health and topology from the NameNode
hdfs dfsadmin -report

# Sample output (trimmed)
# Configured Capacity: 48000000000 (44.7 GB)
# Live datanodes (3):
# Name: 10.0.0.11:9866 (dn1.cluster)
# Name: 10.0.0.12:9866 (dn2.cluster)
# Name: 10.0.0.13:9866 (dn3.cluster)

Design Goals and Trade-offs

HDFS was designed around a write-once-read-many access pattern optimized for high-throughput streaming reads of large files rather than low-latency random access, which is why it favors large block sizes and sequential I/O over the small, random reads typical of traditional filesystems. This trade-off means HDFS is a poor fit for storing millions of tiny files or serving interactive, low-latency queries, but it excels at batch analytics over massive datasets.

🏏

Cricket analogy: Like Test cricket footage recorded once after a five-day match and replayed many times by analysts, HDFS favors write-once-read-many streaming over the constant micro-edits of a live T20 scoring app.

Hadoop 3.x defaults to a 128 MB block size (up from 64 MB in Hadoop 1.x). A large block size minimizes the number of disk seeks needed to read a file and keeps NameNode metadata proportional to file count rather than to total data volume, which is exactly why HDFS struggles with the 'small files problem' when a cluster has millions of tiny files.

Scalability and Rack Awareness

Because DataNodes are stateless workers that only need to register with the NameNode, HDFS scales horizontally simply by adding more commodity machines to the cluster without downtime. The rack-awareness feature lets the NameNode learn which rack each DataNode belongs to, so it can place block replicas across different racks to survive a rack-level failure while still minimizing cross-rack network traffic for reads.

🏏

Cricket analogy: Like the IPL adding new franchises each season without disrupting existing matches, HDFS scales by adding DataNodes on the fly, while rack awareness is like spreading a squad's travel across two flights so one cancellation doesn't strand the whole team.

The NameNode is a single point of failure in a non-HA deployment: if it goes down, the entire cluster's namespace becomes unreachable even though the DataNodes still hold all the data. Production clusters should configure HDFS High Availability with an Active/Standby NameNode pair and JournalNodes (Quorum Journal Manager) for automatic failover.

  • HDFS uses a master/worker architecture: one NameNode manages metadata, many DataNodes store data blocks.
  • Files are split into large fixed-size blocks (128 MB default in Hadoop 3.x) distributed across DataNodes.
  • HDFS is optimized for write-once-read-many streaming access to large files, not low-latency random access.
  • The NameNode keeps metadata in memory and persists it via the FsImage and EditLog.
  • DataNodes send periodic heartbeats and block reports so the NameNode tracks live cluster state.
  • Rack awareness lets HDFS place replicas across racks for fault tolerance while limiting cross-rack traffic.
  • HDFS scales horizontally by adding DataNodes without downtime, but the NameNode needs HA to avoid a single point of failure.

Practice what you learned

Was this page helpful?

Topics covered

#Programming#HadoopStudyNotes#HDFSArchitecture#HDFS#Architecture#Master#Worker#StudyNotes#SkillVeris#ExamPrep