Объёмы логов, транзакций и машинных данных растут быстрее, чем реляционные хранилища успевают их переваривать. Когда таблица упирается в сотни терабайт, вертикальное масштабирование сервера превращается в гонку с бюджетом, которую вы проигрываете. Apache Hadoop отвечает на это иначе: разложить данные и вычисления по дешёвым серверам и считать там, где данные лежат. Разберём, как это устроено и где оно действительно работает в корпоративном и государственном контуре.

HDFS: хранение, которое переживает отказ диска

В основе Hadoop лежит HDFS – распределённая файловая система. Большой файл режется на блоки по 64 МБ, каждый блок пишется на несколько узлов (по умолчанию три реплики). Узел NameNode хранит карту блоков, узлы DataNode держат сами данные. Выход из строя диска или целого сервера – штатное событие: кластер перечитывает реплики и восстанавливает фактор репликации без остановки.

Расплата за это – согласованность. HDFS оптимизирован под последовательную запись и многократное чтение, а не под произвольные обновления записей. Здесь нет транзакций уровня СУБД и нет редактирования файла «в середине». Это прямое следствие компромисса, который мы разбирали в CAP-теореме на практике: доступность и устойчивость к разделению покупаются ценой строгой согласованности. Понимать это нужно до проектирования, а не после первого расхождения отчётов.

MapReduce: считать там, где лежат данные

MapReduce – модель пакетной обработки. Задача делится на две фазы. На фазе Map каждый узел обрабатывает свои локальные блоки и выдаёт пары «ключ – значение». Между фазами система сортирует и группирует данные по ключу (shuffle). На фазе Reduce узлы агрегируют значения по каждому ключу в результат.

Ключевая идея – не тащить терабайты по сети к коду, а отправить код к данным. Это даёт линейный рост производительности: добавили узлы – пропорционально ускорили обработку. Цена – латентность. MapReduce считает минуты и часы, а не миллисекунды. Это инструмент для ночного пересчёта витрин, разбора архива логов, обучения моделей на исторических данных – но не для онлайн-ответа пользователю. Если вы ждёте отклика за секунды, Hadoop в этом месте не нужен.

Где это применять в корпоративном и госсекторе

Hadoop оправдан там, где данных много, они разнородны и аналитика терпит пакетный режим: консолидация логов и событий ИБ, обработка телеметрии и показаний приборов учёта, анализ обращений граждан, подготовка данных для отчётности и BI. В госсекторе важен ещё один аргумент – кластер собирается на обычном оборудовании и open source, без лицензионной привязки к одному вендору, что упрощает импортонезависимость и обоснование закупки.

Чего ждать не стоит: Hadoop не заменяет операционную СУБД, не отменяет хранилище данных и не работает как «коробка из магазина». Это слой пакетной обработки, который встраивается в существующий ландшафт рядом с реляционными системами и BI. Что именно складывать в кластер и какую отдачу это даст бизнесу, мы разбирали в материале о больших данных для бизнеса.

Разворачивать кластер можно как на собственном железе, так и в арендованной инфраструктуре – выбор между моделями мы описывали в разборе IaaS, PaaS и SaaS. Реальная отдача начинается не с самого кластера, а с проектирования схемы данных, конвейеров MapReduce и их интеграции с отчётностью.

Вывод

Hadoop – не панацея и не модное слово, а инженерный ответ на конкретную задачу: дёшево хранить и пакетно обрабатывать данные, которые не помещаются в один сервер. Внедряйте его осознанно: под пакетную аналитику, рядом с существующими СУБД, с трезвым пониманием компромисса между согласованностью и масштабом.