«Большие данные» за последний год превратились из темы для инженеров Google и Yahoo в слово, которое произносят на совещаниях у заказчиков. Маркетинг бежит впереди практики: под Big Data подают всё подряд – от обычной витрины в хранилище до отчёта в Excel на миллион строк. Разберём, где проходит граница и когда термин действительно описывает вашу задачу, а не просто украшает презентацию.

Три V и почему важен только переход через порог

Аналитики Gartner описывают Big Data через три признака: объём (Volume), скорость поступления (Velocity) и разнообразие форматов (Variety). Формула удобная, но обманчивая. Гигабайты есть у всех – вопрос в том, перестают ли привычные инструменты справляться с нагрузкой.

Big Data начинается там, где реляционная СУБД на одном сервере уже не тянет: данные не помещаются на диск, индексы строятся часами, а join по двум большим таблицам кладёт базу. Тогда вертикальное масштабирование (более мощный сервер) упирается в потолок цены, и приходится переходить к горизонтальному – десяткам дешёвых узлов. Именно этот переход, а не абсолютная цифра в терабайтах, и есть настоящий маркер.

Разнообразие – отдельная боль. Логи веб-сервера, клики, показания датчиков, тексты обращений граждан не ложатся в жёсткую схему «строки и столбцы». Под такие задачи и выросли NoSQL-хранилища; мы сравнивали их подходы в обзоре NoSQL-решений.

Чем платят за масштаб

Распределённая система не бывает бесплатной. Как только данные размазаны по узлам, вы упираетесь в фундаментальное ограничение: при сбое сети нельзя одновременно гарантировать и согласованность, и доступность. Об этом компромиссе мы подробно писали в разборе теоремы CAP на практике и для бизнеса это не абстракция, а прямой выбор: показать клиенту чуть устаревший баланс счёта или вернуть ошибку.

Технологический стек уже сложился вокруг Hadoop. Распределённая файловая система HDFS хранит данные на десятках машин, а MapReduce считает по ним пакетные задачи: ночной пересчёт сегментов клиентов, агрегацию логов, разбор журналов транзакций. Это инструмент пакетной аналитики, а не замена оперативной базы – ждать ответа в реальном времени от MapReduce не стоит.

Отдельно отметим экономику. Поднять кластер из десятка узлов под разовый расчёт стало проще благодаря облачным мощностям, которые в этом году окончательно вышли из разряда экзотики – мы фиксировали это среди ИТ-трендов 2012 года. Платить за сотню серверов по часам выгоднее, чем держать их в стойке круглый год.

Что это значит для заказчика

Перед тем как закупать Hadoop-кластер, ответьте на три вопроса. Откуда берутся данные и как быстро растут? Какие решения вы примете по результатам анализа и стоят ли они затрат на инфраструктуру? Хватает ли текущему хранилищу мощности, если просто навести в нём порядок?

В половине проектов, которые мы видим, ответ один: классического хранилища и грамотной витрины достаточно. Big Data нужна там, где объёмы и форматы реально вышли за пределы реляционной модели – у телекома с детализацией звонков, у ритейла с историей чеков, у госсектора с межведомственными потоками и логами порталов.

Подходить к этому стоит как к инженерной задаче, а не модной закупке: сначала понятный вопрос к данным, затем выбор архитектуры под него. Путь от аудита источников до промышленного хранилища и построения аналитики на данных проходят последовательно, не перепрыгивая через постановку вопроса.

Big Data – не магия и не самоцель. Это ответ на конкретный технический предел, за которым старые инструменты ломаются. Если предела нет, термин остаётся словом из презентации.