Какова роль NameNode в Hadoop и какие проблемы с ним связаны?

NameNode в Hadoop и его роль

NameNode — это главный компонент распределённой файловой системы Hadoop (HDFS), который управляет всей файловой системой. Это критический компонент инфраструктуры Big Data, и его отказ может привести к неработоспособности всего кластера.

Роль NameNode в HDFS

1. Управление файловой системой

NameNode хранит и управляет файловой иерархией и метаданными всех файлов в HDFS:

HDFS Architecture:
┌──────────────────────────────────────────┐
│         NameNode (Master)               │
│  - Filesystem namespace                 │
│  - Filesystem tree                      │
│  - File metadata for all files          │
│  - Does NOT store actual data          │
└──────────────────────────────────────────┘
          ↓  heartbeat + block reports  ↓
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│  DataNode 1  │  │  DataNode 2  │  │  DataNode N  │
│  (block 1,2) │  │  (block 2,3) │  │  (block 1,3) │
└──────────────┘  └──────────────┘  └──────────────┘

2. Управление пространством имён (Namespace)

// NameNode отслеживает иерархию файлов
FileSystem filesystem = FileSystem.get(conf);
FileStatus[] statuses = filesystem.listStatus(new Path("/user/data"));

// Это работает через NameNode
for (FileStatus status : statuses) {
    System.out.println(status.getPath() + ": " + status.getLen());
}

NameNode содержит:

• FSImage — снимок состояния файловой системы
• Edit Logs — журнал изменений
• Namespace. — полная иерархия директорий и файлов

3. Управление блоками и репликацией

# NameNode определяет, где хранятся блоки файлов
from hdfs import InsecureClient

client = InsecureClient('http://namenode-host:50070')

# Получить информацию о расположении блоков
status = client.status('/user/data/file.txt')
print(f"Block size: {status['blockSize']}")

# NameNode решает:
# 1. На скольких DataNodes реплицировать данные (replication factor)
# 2. Где размещать первую, вторую, третью реплику
# 3. Когда нужно переходить блоки между узлами

Стратегия размещения (Rack-aware placement):

• Первая реплика → на узле, где находится writer
• Вторая реплика → на другом узле в том же rack
• Третья реплика → на узле в другом rack

4. Heartbeat и Block Reports

NameNode получает регулярные сообщения от DataNodes:

DataNode → NameNode (каждые 3 секунды):
- Heartbeat ("я живой")
- Block report (список блоков на узле)

NameNode:
- Отслеживает живых DataNodes
- Обнаруживает вышедшие из строя узлы (timeout = 10 минут)
- Инициирует rebalancing и replikация

Основные проблемы с NameNode

Проблема 1: Single Point of Failure (SPOF)

Если NameNode выходит из строя, весь HDFS кластер становится недоступным.

❌ ПРОБЛЕМА:
NameNode crash → весь кластер DOWN
│
├─ Прочитать данные = невозможно
├─ Записать данные = невозможно
├─ Просмотреть файлы = невозможно
└─ Кластер полностью неработоспособен

Решение: HA (High Availability) с Secondary NameNode или NameNode Federation:

<!-- hdfs-site.xml для High Availability -->
<configuration>
  <!-- Включаем HA -->
  <property>
    <name>dfs.nameservices</name>
    <value>mycluster</value>
  </property>
  
  <!-- NameNodes в кластере -->
  <property>
    <name>dfs.ha.namenodes.mycluster</name>
    <value>nn1,nn2</value>
  </property>
  
  <!-- Адреса NameNodes -->
  <property>
    <name>dfs.namenode.rpc-address.mycluster.nn1</name>
    <value>namenode1.example.com:8020</value>
  </property>
  <property>
    <name>dfs.namenode.rpc-address.mycluster.nn2</name>
    <value>namenode2.example.com:8020</value>
  </property>
  
  <!-- Shared edit logs в ZooKeeper -->
  <property>
    <name>dfs.namenode.shared.edits.dir</name>
    <value>qjournal://namenode1:8485;namenode2:8485;namenode3:8485/mycluster</value>
  </property>
  
  <!-- Автоматический failover -->
  <property>
    <name>dfs.ha.automatic-failover.enabled</name>
    <value>true</value>
  </property>
</configuration>

Проблема 2: Масштабируемость и использование памяти

NameNode хранит ВСЕХ метаданные в памяти (не может использовать диск). Каждый файл/блок требует памяти:

Примерный расход памяти:
- Один файл = ~150 байт
- Один блок = ~600 байт

Для кластера:
- 10 миллиардов файлов → минимум 1.5TB памяти
- 10 петабайт данных (с replication factor 3) = 30 петабайт блоков
- → ~300 ТБ памяти необходимо

Решение: NameNode Federation

Before (Single NameNode):
NameNode
├─ /user
├─ /data
├─ /logs
└─ 100 миллиардов файлов → OOM

After (NameNode Federation):
NameNode 1          NameNode 2          NameNode 3
├─ /user (33B)     ├─ /data (33B)     ├─ /logs (33B)
└─ Good memory     └─ Good memory     └─ Good memory

Проблема 3: FSImage и Edit Logs

NameNode использует два файла для состояния:

• FSImage — снимок файловой системы
• Edit Logs — журнал операций

Если Edit Logs становятся слишком большими, NameNode медленно загружается:

Проблема:
Edit Logs растут с каждой операцией → со временем очень большой
│
├─ Время загрузки NameNode: 30 минут → часы
├─ Финансовое воздействие: неактивность кластера
└─ RTO (Recovery Time Objective) = часы

Решение: Checkpointing (Secondary NameNode):

Secondary NameNode (каждый час):
1. Скачивает FSImage + Edit Logs
2. Объединяет в новый FSImage
3. Отправляет обратно на primary NameNode
4. Primary NameNode загружает новый FSImage
5. Edit Logs очищаются

# Проверить размер Edit Logs
hdfs oiv -p JSON -i /path/to/edits -o /tmp/edits.json
ls -lh /path/to/edits*

Проблема 4: Управление квотами и безопасностью

# NameNode управляет квотами
from hdfs import InsecureClient

client = InsecureClient('http://namenode:50070')

# Установить квоту на 100GB для /user/bob
client.set_quota('/user/bob', space_quota=100*1024**3)

# Если превышена квота → ошибка
# "The NameNode has refused the write request"

Проблема 5: Стейл датаноды и блоки

Проблема:
DataNode не отправляет heartbeat → NameNode считает его мёртвым
│
├─ Данные становятся недорепликированными
├─ NameNode создаёт новые реплики на других узлах
├─ Трафик в кластере резко возрастает (sometimes called "Replica Avalanche")
└─ Производительность падает

Решение:
явно пометить DataNode как "in maintenance":

# Hadoop 3.2+
hdfs dfsadmin -enterMaintenance -nodes 172.16.1.10:9866

# DataNode перейдёт в режим обслуживания
# NameNode аккуратно переместит блоки на другие узлы
hdfs dfsadmin -listOpenFiles

Мониторинг NameNode

import requests
import json

# NameNode JMX endpoint
url = "http://namenode:9870/jmx?qry=Hadoop:service=NameNode,name=*"
response = requests.get(url)
jmx_data = response.json()

# Важные метрики
for bean in jmx_data['beans']:
    if 'FSNamesystem' in bean['name']:
        print(f"Total files: {bean['FilesTotal']}")
        print(f"Total blocks: {bean['BlocksTotal']}")
        print(f"Total capacity: {bean['Total']}")
        print(f"Under replicated blocks: {bean['UnderReplicatedBlocks']}")
        print(f"Corrupt blocks: {bean['CorruptBlocks']}")
        print(f"Missing blocks: {bean['MissingBlocks']}")

Best Practices

Советы по управлению NameNode:

1. Включить HA:

# Используй QJM (Quorum Journal Manager) для синхронизации
qjournal://jm1:8485;jm2:8485;jm3:8485/mycluster

1. Настроить Federation для больших кластеров:

# Разделить пространство имён между несколькими NameNodes
dfs.nameservices = ns1,ns2,ns3

1. Регулярно проверять здоровье:

hdfs dfsadmin -report
hdfs dfsadmin -safemode get
hdfs fsck / -files -blocks

1. Мониторить Edit Logs:

hdfs oiv -p Delimited -i /path/to/edits -o /tmp/edits.txt
wc -l /tmp/edits.txt  # Число операций

1. Планировать capacity:

Память NameNode = 150 байт/файл + 600 байт/блок + запас
Для 1B файлов: 150GB
Для 1 ПБ данных (RF=3): 600GB
→ Итого: 1TB памяти достаточно для очень больших кластеров

NameNode — это сердце Hadoop экосистемы. Его надёжность и производительность напрямую влияют на весь кластер.