Большие данные — это не просто тяжёлый файл. На примере доставки разбираемся, как объём, скорость и разнообразие информации меняют требования к её обработке.
Большая таблица — уже Big Data?
У одного человека «очень много данных» — это семейный фотоархив, у другого — история заказов сети магазинов. Название Big Data не даёт универсального ответа в гигабайтах. Для практической задачи важнее понять, может ли существующая система хранить и обрабатывать информацию так, как требуется.
Например, архив может занимать много места, но обращаться к нему нужно редко. А сравнительно небольшой поток событий иногда требует быстрой реакции. Одинакового решения для этих двух ситуаций ждать не стоит: важны назначение данных, скорость поступления и требования к результату.
Три свойства, которые помогают разобраться
AWS объясняет Big Data через сочетание объёма, скорости и разнообразия. Объём — сколько информации накоплено. Скорость — как быстро она поступает и насколько скоро требуется результат. Разнообразие — насколько отличаются её источники и форматы.
Представим доставку еды. Заказы образуют историю операций, координаты курьеров поступают регулярно, а отзывы содержат свободный текст. Даже если всё относится к одному сервису, обращаться с этими сведениями одинаково неудобно. Таблица покупок, последовательность местоположений и текст жалобы отвечают на разные вопросы.
Что меняется в повседневной задаче
Руководитель условного сервиса хочет понять, где доставка опаздывает. Для отчёта за месяц можно собрать завершённые заказы и сравнить районы. Чтобы заметить задержку прямо во время поездки, нужны свежие сведения и другое время реакции. Один и тот же вопрос о доставке превращается в разные задачи обработки.
Если на этапе постановки задачи это различие не обсудили, можно получить дорогую систему, которая прекрасно считает вчерашние итоги, но не помогает диспетчеру сейчас. Поэтому описание нужного результата стоит начинать со слов пользователя: какое решение он примет, как часто и на основании каких сведений.
Количество ещё не означает пользу
Oracle дополнительно выделяет ценность и достоверность данных. Ценность связана с тем, помогают ли сведения решать задачу. Достоверность — с тем, насколько им можно доверять. Чем больше записей собрано, тем важнее понимать их происхождение и ограничения.
В нашем условном примере два события о том же заказе не обязательно означают две покупки. А отсутствие координаты не доказывает, что курьер остановился. Если такие различия потерять, большой набор данных может привести к убедительному, но неверному выводу. Объём сам по себе не исправляет смысловые ошибки.
Что обычно приходится организовывать
Команде нужно договориться, откуда брать сведения, как отличать повтор от нового события и какие данные нужны для конкретного отчёта. Затем выбрать место хранения и способ обработки. Часть результатов нужна быстро, часть можно подготовить по расписанию. Эти решения связаны с рабочей задачей, а не с размером одной выгрузки.
Полезно заранее описать и неприятный сценарий: источник задержался, формат изменился, часть истории недоступна. Что тогда увидит пользователь? Сможет ли он отличить полноценный результат от неполного? Такие вопросы делают разговор о больших данных конкретным даже для человека, который не занимается программированием.
Когда сложная система избыточна
Небольшой команде с понятными источниками и редкими отчётами может хватать существующей базы и привычных средств анализа. Переход к более сложному решению имеет смысл обсуждать после того, как обнаружено ограничение: результат регулярно опаздывает, хранение стало неудобным или новые источники невозможно нормально включить в процесс.
Для первого разговора достаточно трёх вопросов. Что именно перестало устраивать? Как выглядит приемлемый результат? На каких реальных данных можно сравнить варианты? Ответы не заменяют проектирование, зато помогают избежать ситуации, когда обсуждаются названия технологий, а исходная проблема остаётся неясной.
Где продолжить знакомство
Если интереснее всего устройство системы целиком — где хранить сведения, как связать источники и как подготовить результат для разных пользователей, — посмотрите интенсив «Архитектор данных». Это смежное направление для изучения архитектуры, а не обещание универсального решения любой задачи Big Data. Сравните содержание и требования к опыту со своей целью.
