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.
# 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
1. What is the primary responsibility of the HDFS NameNode?
2. What is the default HDFS block size in Hadoop 3.x?
3. What access pattern is HDFS primarily optimized for?
4. What mechanism keeps the NameNode aware of which DataNodes are alive and what blocks they hold?
5. Why is the NameNode considered a single point of failure without HA configuration?
Was this page helpful?
You May Also Like
NameNode and DataNodes
A closer look at HDFS's two core daemons: the NameNode that governs metadata and the DataNodes that physically store block data.
Blocks and Replication
How HDFS splits files into large blocks and replicates them across the cluster to guarantee durability and availability.
HDFS Read/Write Workflow
Step-by-step walkthrough of what actually happens inside HDFS when a client writes a new file or reads an existing one.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics
ProgrammingPowerShell Study Notes
Programming · 30 topics