Hadoop Best Practices

Analogy categoryAnalogies

Designing for Scale and Reliability

Hadoop clusters rarely fail because of one dramatic event; they degrade because of accumulated small mistakes — undersized NameNode heaps, unbalanced racks, and jobs that ignore data locality. Best practices exist to catch these issues before they compound, covering data layout, resource tuning, and operational discipline across the cluster's lifetime.

🏏

Cricket analogy: Like a team management plan for MS Dhoni's franchise across a decade — small decisions on player rotation and fitness monitoring each season prevent the squad from collapsing right before the playoffs.

Data Layout and File Formats

Choosing the right file format has an outsized effect on cluster efficiency. Columnar formats like Parquet and ORC let query engines skip irrelevant columns and apply predicate pushdown, dramatically reducing I/O for analytical workloads, while Avro remains preferable for row-oriented streaming data with evolving schemas. Combine this with splittable compression codecs such as Snappy for intermediate data and Gzip only for cold archival storage, since Gzip is not splittable and forces a single mapper to read an entire large file.

🏏

Cricket analogy: Choosing Parquet over plain text is like Virat Kohli's analysts storing ball-by-ball data in a structured spreadsheet instead of prose match reports — you can instantly filter for 'all sixes off spin bowling' without reading every commentary line.

sql

-- Hive DDL: store analytical tables as ORC with Snappy compression
CREATE TABLE sales_fact (
  order_id BIGINT,
  customer_id BIGINT,
  amount DECIMAL(10,2),
  order_date DATE
)
PARTITIONED BY (year INT, month INT)
STORED AS ORC
TBLPROPERTIES ('orc.compress'='SNAPPY');

-- Merge small partition files into fewer, larger ones
ALTER TABLE sales_fact PARTITION (year=2026, month=6) CONCATENATE;

The Small Files Problem

Every file, directory, and block in HDFS consumes roughly 150 bytes of heap on the NameNode. A cluster storing 100 million tiny files can exhaust NameNode memory long before it exhausts disk capacity, and each small file also spawns its own mapper, wasting JVM startup overhead on records that take milliseconds to process. The fix is to consolidate at ingestion time using SequenceFiles, Hadoop Archives (HAR), or CombineFileInputFormat, and to set a minimum file-size threshold in ingestion pipelines like Flume or NiFi.

🏏

Cricket analogy: Is like a scorer recording every single delivery of a decade of domestic cricket in separate notebooks instead of one ledger per season — the storage room fills up long before anyone reads a page.

Do not rely on the Secondary NameNode as a backup or failover node — it only periodically merges the fsimage and edit log to bound restart time. In production, always run HDFS High Availability with an active/standby NameNode pair coordinated by ZooKeeper (via ZKFC) to avoid a single point of failure.

Resource Management and Job Tuning

YARN allocates containers based on requested memory and vCores, so setting mapreduce.map.memory.mb and mapreduce.reduce.memory.mb too low causes containers to be killed for exceeding physical memory, while setting them too high wastes cluster capacity through fragmentation. Enable speculative execution (mapreduce.map.speculative, mapreduce.reduce.speculative) cautiously — it launches duplicate attempts of slow tasks on other nodes, which helps with stragglers caused by flaky hardware but wastes resources if slowness is due to genuine data skew that speculation cannot fix.

🏏

Cricket analogy: Is like a captain deciding how many overs to allocate a part-time spinner — too few and they never build rhythm, too many and the strike bowlers run out of overs to close the innings.

A good starting point for container sizing is to set yarn.scheduler.minimum-allocation-mb to your smallest realistic task footprint (e.g., 1024 MB) and mapreduce.map.memory.mb to roughly 1.2–1.5x the JVM heap (mapreduce.map.java.opts -Xmx) to leave headroom for off-heap memory and avoid OOM container kills.

Security and Operational Discipline

Production Hadoop clusters should enforce Kerberos authentication for every service (NameNode, DataNode, ResourceManager, Hive Metastore) and layer authorization on top with HDFS ACLs or a policy engine like Apache Ranger, rather than relying on OS-level file permissions alone. Operationally, monitor NameNode heap usage, DataNode disk balance, and JVM garbage-collection pause times through JMX metrics surfaced in Ambari or Cloudera Manager, and set the default replication factor (dfs.replication, typically 3) deliberately per dataset — critical tables may warrant higher replication while scratch/staging data can safely run at 2.

🏏

Cricket analogy: Is like a stadium requiring both a ticket scan (authentication) and a specific seating-zone wristband (authorization) — proving you're a ticket holder alone doesn't let you into the players' pavilion.

Use columnar formats (Parquet/ORC) with splittable compression like Snappy for analytical data; reserve Gzip for cold storage only.
Consolidate small files at ingestion using SequenceFiles, HAR, or CombineFileInputFormat to protect NameNode heap.
The Secondary NameNode is not a failover node — use HDFS HA with ZooKeeper-coordinated active/standby NameNodes in production.
Size YARN container memory (mapreduce.map/reduce.memory.mb) with headroom above the JVM heap to avoid OOM container kills.
Use speculative execution for straggler hardware, not for genuine data skew — it won't fix a skewed key distribution.
Enforce Kerberos authentication cluster-wide and layer authorization with HDFS ACLs or Apache Ranger rather than relying on OS permissions.
Monitor NameNode heap, DataNode disk balance, and GC pauses continuously via JMX/Ambari rather than only after an incident.