Какая стандартная репликация в HDFS и на что она влияет?

HDFS репликация: стандарты и влияние

HDFS (Hadoop Distributed File System) использует репликацию данных для обеспечения надёжности и доступности. Понимание репликации критично для production систем.

Стандартный фактор репликации

По умолчанию HDFS хранит 3 копии каждого блока данных (replication factor = 3).

# Просмотр текущего фактора репликации
hdfs dfs -ls -R /path/to/file

# Изменение репликации для файла
hdfs dfs -setrep 2 /path/to/file

# Изменение для директории и рекурсивно
hdfs dfs -setrep -R 3 /data/

Архитектура размещения

Стандартная схема размещения 3 реплик:

Rack-aware placement:

• Replica 1: Узел, где находится writer
• Replica 2: Другой узел в том же rack
• Replica 3: Узел в другом rack

Очень редко: узел, но другой Rack

Это обеспечивает баланс между надёжностью (разные racks) и производительностью (близкие узлы).

Конфигурация в hdfs-site.xml

<!-- Фактор репликации по умолчанию -->
<property>
  <name>dfs.replication</name>
  <value>3</value>
</property>

<!-- Минимальная репликация для завершения write -->
<property>
  <name>dfs.namenode.replication.min</name>
  <value>1</value>
</property>

<!-- Минимальная репликация в разных racks -->
<property>
  <name>dfs.replication.max</name>
  <value>512</value>
</property>

Влияние на различные аспекты

1. Использование диска

Данные с репликацией occupancy дискового пространства:

• File size: 100GB
• Replication factor: 3
• Total disk usage: 300GB

# В Spark можно проверить
df = spark.read.parquet("/user/hive/warehouse/table")
print(f"Rows: {df.count()}")
# Реальное использование диска = df.count() * avg_row_size * replication_factor

2. Сетевая пропускная способность

При write операции:

• Данные отправляются на 3 узла последовательно (pipeline)
• Пропускная способность не утраивается благодаря pipelined replication

Client → Node1 → Node2 → Node3
  ↓        ↓       ↓       ↓
отправка одновременно на все три

3. Надёжность и recovery

Пример: Стоимость репликации

# Кластер из 100 узлов, каждый по 10TB
Total capacity = 1000TB

# С репликацией 3
Usable capacity = 1000TB / 3 = 333TB
Wasted space = 667TB (67%)

# С репликацией 2
Usable capacity = 1000TB / 2 = 500TB
Wasted space = 500TB (50%)

Оптимизация репликации по типам данных

# Архивные данные (низкий приоритет)
hdfs dfs -setrep 2 /data/archive/

# Критичные данные
hdfs dfs -setrep 3 /data/critical/

# Временные данные (можно 1)
hdfs dfs -setrep 1 /tmp/spark-temp/

Проверка состояния репликации

# Файлы с недостаточной репликацией (under-replicated)
hdfs fsck / -files -blocks -locations | grep "Under replicated"

# Детально для файла
hdfs fsck /path/to/file -files -blocks

# Использование diskspace
hdfs dfsadmin -report

Влияние на Spark jobs

from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("HdfsTest") \
    .config("spark.default.parallelism", "100") \
    .config("spark.sql.shuffle.partitions", "100") \
    .getOrCreate()

# Readдовать данные из HDFS
df = spark.read.parquet("hdfs://namenode:9000/data/table")

# Spark обычно размещает task там, где находится блок
# С репликацией 3 есть выбор
# С репликацией 1 нет выбора — data locality ниже

df.explain(extended=True)

Практические рекомендации

Production cluster:

• Критичные данные: replication = 3 (стандарт)
• Пересчитываемые данные: replication = 2
• Временные данные: replication = 1
• Очень важные данные: replication = 4

Развивающиеся команды с ограниченным диском:

# Уменьшить глобальный default
hdfs dfs -setrep 2 /user/
# Но сохранить 3 для критичного
hdfs dfs -setrep 3 /user/hive/warehouse/

Масштабирование и repk

# При добавлении новых узлов
# HDFS автоматически перебалансирует блоки

# Команда balancer переместит блоки для даты расхождения
start-balancer.sh

# Проверить прогресс
hdfs dfsadmin -report

Заключение

Стандартная репликация HDFS = 3 копии обеспечивает баланс между надёжностью и эффективностью использования места. Выбор фактора репликации зависит от цены данных (их восстановляемости) и доступного дискового пространства в кластере.