Хайп «Big Data» (2012): как Hadoop и MongoDB начали революцию данных
«Big Data» появился в Цикле хайпа Gartner в 2012 году на пике завышенных ожиданий. На каждой конференции было как минимум два keynote о нём. Каждая консалтинговая компания ребрендировалась как «Big Data». Каждый CTO в корпорациях спрашивал свои команды, нужен ли им Hadoop-кластер.
Большинству - не нужен. Но основные проблемы, которые Big Data адресовал, были реальными. И технологии, появившиеся из хайпа - MongoDB и Hadoop MapReduce - реально изменили инфраструктуру данных.
Что Hadoop на самом деле решал
До Hadoop обработка больших датасетов означала либо обработку на одной большой машине (дорого), либо написание кастомного распределённого кода (чрезвычайно сложно).
Google опубликовал статью о MapReduce в 2004 году. Apache Hadoop реализовал его как open-source в 2006. Идея: разбить большой датасет на множество дешёвых машин, обрабатывать параллельно, агрегировать результаты.
Канонический пример MapReduce - подсчёт слов:
// Map: разбить текст на пары (слово, 1)
public class WordCountMapper extends Mapper<LongWritable, Text, Text, IntWritable> {
public void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException {
StringTokenizer tokenizer = new StringTokenizer(value.toString());
while (tokenizer.hasMoreTokens()) {
word.set(tokenizer.nextToken().toLowerCase());
context.write(word, ONE);
}
}
}
// Reduce: суммировать все подсчёты для каждого слова
public class WordCountReducer extends Reducer<Text, IntWritable, Text, IntWritable> {
public void reduce(Text key, Iterable<IntWritable> values, Context context) throws IOException, InterruptedException {
int sum = 0;
for (IntWritable val : values) sum += val.get();
context.write(key, new IntWritable(sum));
}
}
Где Hadoop был реально полезен:
- Обработка логов: анализ 500ГБ логов веб-сервера
- Пакетный ETL: трансформация сырых данных в агрегированные отчёты за ночь
- Обучение ML на больших датасетах
Где Hadoop был избыточным:
- Любой датасет меньше 10ГБ (один MySQL-сервер справляется отлично)
- Любая нагрузка с необходимостью малой задержки (задачи MapReduce занимали минуты-часы)
- Большинство «Big Data» проектов в компаниях, которые на самом деле не были large
MongoDB: документная база данных
MongoDB 1.0 вышла в 2009. К 2012 году - самая популярная NoSQL база, широко позиционированная как замена MySQL.
// MongoDB - нет схемы, нет миграций, документная модель
db.products.insertOne({
name: "Беспроводные наушники",
price: 4500,
variants: [
{ color: "чёрный", sku: "WH-001-BLK", stock: 42 },
{ color: "белый", sku: "WH-001-WHT", stock: 17 }
],
specifications: { batteryLife: "20 часов", bluetooth: "5.0", noiseCancelling: true },
tags: ["электроника", "аудио", "bluetooth"]
});
db.products.find({
"variants.color": "чёрный",
"specifications.noiseCancelling": true
});
Для каталогов товаров, CMS и пользовательских профилей - иерархических данных с переменными схемами - MongoDB была реально лучше MySQL. Изменения схемы, требующие ALTER TABLE в MySQL (потенциально блокирующего большую таблицу на минуты), были нон-ивентом в MongoDB.
Где MongoDB провалилась в 2012
Без транзакций. Многодокументные атомарные операции не существовали до MongoDB 4.0 (2018). В 2012 году заказ, обновляющий склад по нескольким документам, мог частично завершиться успехом. Мы обрабатывали это двухфазными фиксациями на уровне приложения - сложно, подверженно ошибкам.
Небезопасные записи по умолчанию. Умолчательный write concern в MongoDB 2.x был «fire and forget» - записи подтверждались до сброса на диск. Краш сервера мог потерять последнюю секунду записей. Для production требовалось явно устанавливать {w: 1, j: true} на каждой записи.
Реальный урок: правильный инструмент для задачи
К 2014-2015 мы пришли к прагматичной позиции:
- PostgreSQL для транзакционных данных: заказы, платежи, аккаунты
- MongoDB для каталогов/контента: товары, статьи, профили с переменными схемами
- Hadoop для пакетной аналитики действительно больших датасетов (>50ГБ)
- Redis для кэша и сессий
Хайп 2012 подтолкнул многие команды заменить MySQL на MongoDB полностью. Большинство из них частично мигрировали обратно к 2016 году. Документная модель была реально лучше для одних данных; реляционная - для других. Ответ никогда не был «NoSQL заменяет SQL». Он был «разные модели данных для разных форм проблем».