Skip to main content

HDFS Architecture & Internals

Module Duration: 4-5 hours Hands-on Labs: 6 practical exercises Prerequisites: Understanding of GFS concepts from Module 1

Introduction

HDFS (Hadoop Distributed File System) is the storage foundation of the Hadoop ecosystem. Inspired by Google’s GFS, HDFS provides:
  • Fault-tolerant storage across commodity hardware
  • High throughput for large datasets
  • Scalability to petabytes and beyond
  • Data locality for efficient processing
In this module, we’ll go beyond theory to understand implementation details and write real code.

HDFS Architecture Overview

The Core Components

NameNode: The Brain

The NameNode is the single master that manages:
  1. File System Namespace:
    • Directory tree
    • File metadata (permissions, timestamps)
    • Mapping: filename → block IDs
  2. Block Management:
    • Block locations (which DataNodes store each block)
    • Replication factor enforcement
    • Block creation, deletion, and re-replication
  3. Heartbeat Management:
    • Monitors DataNode health (3-second heartbeats)
    • Detects failures and initiates recovery
Critical Design Choice: All metadata stored in RAM
  • Pros: Fast metadata operations (no disk I/O)
  • Cons: Limits namespace size (1GB RAM ≈ 1 million blocks)

DataNodes: The Workers

DataNodes:
  • Store actual data blocks on local disk
  • Send heartbeats to NameNode every 3 seconds
  • Report block lists periodically (block reports)
  • Serve read/write requests from clients
  • Execute replication commands from NameNode

Secondary NameNode: The Misconception

Common Misconception: Secondary NameNode is NOT a backup or standby!
Actual Role: Performs periodic checkpointing
  • Merges edit logs into FSImage
  • Reduces NameNode restart time
  • Does NOT take over if NameNode fails (use HA NameNode for that)

Block Storage Deep Dive

What is a Block?

HDFS splits files into fixed-size blocks:
  • Default size: 128MB (configurable: 64MB, 256MB, etc.)
  • Why so large?: Minimize metadata overhead, optimize sequential reads
Example:

Replication Strategy

Each block replicated (default: 3 copies) for fault tolerance. Replica Placement Algorithm (Rack-Aware):
Why This Strategy?:
  • Fault tolerance: Survives node and rack failures
  • Write performance: 2 replicas on same rack (fast)
  • Read optimization: Multiple replicas for load balancing
  • Network efficiency: 1/3 of data crosses racks (not 3/3)

Block Placement Code Example

Here’s how HDFS decides block placement (simplified from actual code):

HDFS Read Operation

Let’s trace a complete read operation with detailed code.

The Read Flow

Java Client Code

Behind the Scenes: DFSInputStream

Here’s what happens inside fs.open():
Key Optimizations:
  • Data locality: Reads from closest replica
  • Streaming: Reads one block at a time (doesn’t load entire file)
  • Retry logic: Switches to another replica on failure
  • Checksum verification: Validates data integrity

HDFS Write Operation

Writing is more complex due to replication pipeline.

The Write Flow

Write Pipeline Architecture

Java Write Code

Advanced: Custom Replication Factor


Fault Tolerance Mechanisms

DataNode Failure

Detection:
Recovery Process:

NameNode Failure (High Availability)

Problem: NameNode is single point of failure Solution: HA NameNode with ZooKeeper
Automatic Failover:
  1. Active NameNode crashes
  2. ZooKeeper detects failure
  3. Standby NameNode promoted to Active
  4. Clients automatically redirect to new Active

HDFS Configuration

Essential Configuration Files

core-site.xml (Cluster-wide settings):
hdfs-site.xml (HDFS-specific):

Hands-on Labs

Lab 1: HDFS CLI Operations

Lab 2: Programmatic File Operations

Lab 3: Monitoring HDFS Health


Performance Tuning

Optimizing Block Size

Rule of Thumb: Block size should minimize metadata while avoiding too many small files

Short-Circuit Reads

When client and DataNode are on same machine, skip network:
Performance Impact: 30-50% faster local reads

Common Issues & Troubleshooting

Symptoms: NameNode crashes, OutOfMemoryError in logsCause: Too many files/blocks for allocated heapSolutions:
  1. Increase NameNode heap: -Xmx16g-Xmx32g
  2. Enable HDFS Federation (multiple NameNodes)
  3. Merge small files into larger ones
  4. Clean up old/unused data
Prevention: Monitor namespace size, set quotas
Symptoms: hdfs fsck shows under-replicated blocksCauses:
  • DataNode failures
  • Network issues
  • Disk space exhaustion
Solutions:
Check logs: /var/log/hadoop/hadoop-hdfs-datanode-*.logCommon causes:
  1. Incompatible cluster ID:
  2. Port already in use:
  3. Permission issues:

Interview Focus

Key Concepts to Master:
  • Explain NameNode vs DataNode responsibilities
  • Describe block replication algorithm and rack awareness
  • Walk through read/write data flows
  • Discuss Single NameNode limitations and HA solutions
  • Compare HDFS to other storage (S3, traditional file systems)
Sample Questions:
  1. “Why can’t HDFS handle lots of small files efficiently?”
    • Answer: Each file/block = metadata entry in NameNode RAM
    • 1 million 1KB files = 1 million blocks vs 8 files of 128MB = 8 blocks
  2. “How does HDFS ensure data locality for MapReduce?”
    • Answer: JobTracker queries NameNode for block locations, schedules map tasks on DataNodes storing blocks
  3. “What happens if a client crashes during a write?”
    • Answer: File remains in incomplete state, lease eventually expires, NameNode closes file

What’s Next?

You now understand HDFS storage layer. Next, learn how to process this data with MapReduce!

Module 3: MapReduce Programming Model

Master distributed data processing with MapReduce patterns and hands-on coding