Когда я только начинал работать с приложениями для обработки “больших данных” (т. е. когда имеется много данных о чем-то или о ком-то или имеются данные о многих вещах и многих людях), “большое” на самом деле означало еще довольно малое.

Однажды я создал систему для современного трёхсоткоечного госпиталя, которая хранила всё (включая записи о полумиллионе пациентов) в менее чем 10-Гб (да-да, именно так!) высокопроизводительном дисковом хранилище.

Интересно, что современные относительно большие хранилища ненамного (возможно, вдвое) быстрее, чем те, которыми я располагал в 80-е. Просто в них хранится больше данных и снижена стоимость хранения в расчете на один бит. При этом некоторые операционные проблемы не решены.

Во-первых, остается проблемой качество данных. Чем больше данных вы аккумулируете, тем труднее хранить все в порядке. Мы изобрели новые направления (управление мастер-данными) и инструменты для работы с проблемами “входящего мусора — исходящего мусора”, но легче не стало. Располагая действительно большими массивами накопленных со временем данных, вы должны обеспечивать “мусор на входе — золото на выходе” и предотвращать противоположные ситуации (“золото на входе — мусор на выходе”).

Во-вторых, адекватное описание данных (метаданные) имеет решающее значение. Методика работы с данными (и даже методика хранения) требует знания того, сколько данных будет храниться, как быстро будет расти их объем и как часто они будут меняться. Запрос, который хорошо справляется с поиском сотни строк из миллиона, может не справиться с таблицей из ста миллиардов строк. Имеет значение, как вы фиксируете и отслеживаете ошибки. Ведение журнала изменений и аудит также важны, если данные часто изменяются.

В-третьих, интерпретация — это по-прежнему скорее искусство, чем наука, или наука, доступная только небольшому количеству подготовленных специалистов. Чтобы нивелировать этот фактор, разработчики были вынуждены создать эффективные фильтры и распознаватели структур, которые могут просеять горы данных и найти (возможно, неожиданные) релевантные структуры.

В-четвертых, визуализация данных. Критически важное значение имеет представление результатов в легко читаемой форме. От информации мало проку, если вы не можете понять результаты работы аналитика или аналитической программы. Теория дизайна визуализации не нова, но подобно многим вещам, требующим глубокого понимания капризов человеческого познания, трудна в практической реализации.

В-пятых, обычно приходится выбирать между режимами просмотра данных в реальном времени (что означает необходимость постоянного пересчета при изменении данных) и ретроспективным (наиболее распространенный способ для аналитики на базе кубов). В последнем случае результаты аналитики — всегда слегка устаревшие.

В-шестых, как вы узнаете заранее, на каком временном промежутке ценны или релевантны данные? Сбор, хранение, анализ и создание запасных копий стоит денег. Вместо типичного подхода “хранить все всегда” нужно иметь политику хранения данных и применять её.

Не лучше ли взяться за легкую часть задачи и хранить только то, что вам действительно нужно? В конце концов, возможно, кто-то уже хранит остальную часть информации для вас.