Анализ социальной сети с определением количества и крепости связей между ее подписчиками требует совершенно других методологий, чем, скажем, прогнозирование продаж. Подобное разнообразие больших данных представляет собой куда больший вызов, чем их «громадность». В чем заключается сложность? Давайте посмотрим на примере.
Предположим, что организация впервые решает запустить текстовый анализ сообщений по электронной почте. Даже для того чтобы проанализировать всего несколько тысяч имейлов, потребуется приобрести специальное программное обеспечение, установить его и настроить, а также определить желательную для организации логику анализа. Создание процесса текстового анализа для 10 000 писем потребует столько же времени и усилий, как и для 10 млн или 100 млн. Будет применяться одна и та же логика, только увеличится масштаб. Поскольку текст представляет собой иной тип данных, придется проделать много подготовительной работы, чтобы запустить анализ даже очень малого объема текстовых данных.
Разумеется, при выполнении аналитического процесса 10 000 имейлов будут обработаны быстрее, чем 100 млн. Несмотря на то что увеличение объема требует масштабирования процесса, лежащая в его основе логическая схема анализа остается прежней. Поэтому первым делом нужно решить, как управлять разнообразием источника больших данных. А затем решить, как управлять разнообразием при масштабировании.
Большие данные требуют масштабирования по нескольким параметрам
Главное внимание при работе с большими данными обычно уделяется проблеме масштабирования. Если конкретнее, то количеству данных и объему требуемой обработки. Между тем нужно учитывать и другие параметры масштабирования в том случае, если организация решает внедрить аналитику на уровне всего предприятия и особенно если решает превратить ее в операционную. Эти аспекты проиллюстрированы на рис. 2.3 и 2.4.
Во-первых, необходимо произвести масштабирование касательно количества и разнообразия пользователей, имеющих доступ как к исходным данным, так и к результатам основанных на них аналитических процессов. Десяткам и сотням тысяч сотрудников может потребоваться в любое время ознакомиться в разных аспектах с первичными данными и результатами их анализа. Корпоративные платформы должны быть дружественными к пользователям и совместимыми с широким спектром инструментов и приложений.
Масштабирование касается не только хранения и обработки
Основное внимание при внедрении больших данных, как правило, уделяется возможностям масштабирования хранения и обработки данных. При этом часто упускаются из виду другие важные параметры, которые также требуют масштабирования, такие как количество пользователей, уровень параллелизма, управление рабочей нагрузкой и протоколы безопасности. Если системы не будут масштабированы по всем перечисленным параметрам, организации не удастся добиться успеха в операционной аналитике.
Во-вторых, крайне важно произвести масштабирование такого параметра, как параллелизм. Под ним понимается количество пользователей или приложений, которые одновременно могут получить доступ к определенному набору информации. Также параллелизм на уровне предприятия означает, что по мере изменения данных все пользователи получают согласованные ответы на свои запросы. По мере роста параллелизма значительно возрастает и риск того, что система перестанет справляться с обработкой запросов. Следовательно, если крупная организация решает внедрить у себя операционно-аналитические процессы, она должна создать такую среду, где множество разных пользователей и приложений могут одновременно взаимодействовать с одной и той же информацией.
В-третьих, существует потребность в масштабировании инструментов управления рабочей нагрузкой. Когда различные типы пользователей подают широкий спектр запросов на анализ да еще и на защищенном уровне, необходимо наладить управление рабочей нагрузкой. Сбалансировать разом множество запросов – не такая простая задача, как кажется, однако этот аспект масштабирования легко упустить из виду. Очень нелегко создать систему, которая способна эффективно управлять как незначительными тактическими, так и крупными стратегическими запросами.
Наконец, нужно масштабировать и протоколы безопасности. Организация при необходимости должна быть способна контролировать и блокировать доступ к данным. Пользователям предоставляются только те части данных, которые им позволяется видеть. Крупная организация должна встроить надежные протоколы безопасности во все свои платформы.
Все перечисленные параметры масштабирования – данные, обработка, пользователи, параллелизм, управление рабочей нагрузкой и безопасность – должны присутствовать с самого начала, если организация хочет добиться успеха в операционной аналитике. И потерпят неудачу те, кто заботится только о масштабировании хранения и обработки данных.
Как получить максимальную отдачу от больших данных
Одна из самых распространенных ошибок, которую я видел в организациях, пытающихся внедрить большие данные в свои аналитические процессы, состоит в подходе к большим данным как совершенно отдельной и самостоятельной проблеме. Многие компании даже создают специальные подразделения, занимающиеся только большими данными
{19}. А некоторые доходят вплоть до того, что открывают в Кремниевой долине офисы, призванные заниматься реализацией проектов в области больших данных. Однако такой подход может встретиться с трудностями, поскольку большие данные всего лишь один из аспектов общей корпоративной стратегии управления данными и аналитикой. Необходима единая согласованная стратегия, охватывающая все данные, большие и малые, как это проиллюстрировано на рис. 2.5 и 2.6.
Давайте рассмотрим историческую параллель, которая наглядно показывает, почему отсутствие единой стратегии управления данными и аналитикой может привести к проблемам. Когда электронная коммерция уже достигла зрелости, многие ретейлеры все еще рассматривали ее не в качестве аспекта своих стратегий розничного бизнеса, а как совершенно новое направление деятельности. В результате многие из них создавали специальные подразделения электронной коммерции, иногда даже придавая им статус отдельных юридических лиц. Эти отдельные организации создавали собственные цепочки поставок, иерархии продуктов, политику ценообразования и т. д.
