В-третьих, существует потребность в масштабировании инструментов управления рабочей нагрузкой. Когда различные типы пользователей подают широкий спектр запросов на анализ да еще и на защищенном уровне, необходимо наладить управление рабочей нагрузкой. Сбалансировать разом множество запросов – не такая простая задача, как кажется, однако этот аспект масштабирования легко упустить из виду. Очень нелегко создать систему, которая способна эффективно управлять как незначительными тактическими, так и крупными стратегическими запросами.
Наконец, нужно масштабировать и протоколы безопасности. Организация при необходимости должна быть способна контролировать и блокировать доступ к данным. Пользователям предоставляются только те части данных, которые им позволяется видеть. Крупная организация должна встроить надежные протоколы безопасности во все свои платформы.
Все перечисленные параметры масштабирования – данные, обработка, пользователи, параллелизм, управление рабочей нагрузкой и безопасность – должны присутствовать с самого начала, если организация хочет добиться успеха в операционной аналитике. И потерпят неудачу те, кто заботится только о масштабировании хранения и обработки данных.
Как получить максимальную отдачу от больших данных
Одна из самых распространенных ошибок, которую я видел в организациях, пытающихся внедрить большие данные в свои аналитические процессы, состоит в подходе к большим данным как совершенно отдельной и самостоятельной проблеме. Многие компании даже создают специальные подразделения, занимающиеся только большими данными{19}. А некоторые доходят вплоть до того, что открывают в Кремниевой долине офисы, призванные заниматься реализацией проектов в области больших данных. Однако такой подход может встретиться с трудностями, поскольку большие данные всего лишь один из аспектов общей корпоративной стратегии управления данными и аналитикой. Необходима единая согласованная стратегия, охватывающая все данные, большие и малые, как это проиллюстрировано на рис. 2.5 и 2.6.
Давайте рассмотрим историческую параллель, которая наглядно показывает, почему отсутствие единой стратегии управления данными и аналитикой может привести к проблемам. Когда электронная коммерция уже достигла зрелости, многие ретейлеры все еще рассматривали ее не в качестве аспекта своих стратегий розничного бизнеса, а как совершенно новое направление деятельности. В результате многие из них создавали специальные подразделения электронной коммерции, иногда даже придавая им статус отдельных юридических лиц. Эти отдельные организации создавали собственные цепочки поставок, иерархии продуктов, политику ценообразования и т. д.
Теперь перенесемся в сегодняшний день. Те же самые ретейлеры сейчас желают, чтобы их бизнес воспринимали как единое целое, включая традиционные стационарные магазины и электронную коммерцию. Более того, они хотят обеспечить потребителям плавное переключение между различными каналами торговли. Однако, для того чтобы объединить в некоторых случаях совершенно несовместимые системы, ретейлерам требуются миллионы долларов инвестиций и годы работы.
Разработайте общую стратегию в области данных и аналитикиВы должны рассматривать большие данные как один из аспектов общей стратегии управления данными и аналитикой. В противном случае вы столкнетесь с теми же проблемами, с которыми сегодня сталкиваются ретейлеры, изначально не включившие электронную коммерцию в свои стратегии розничной торговли.
10–15 лет тому назад ретейлеры справедливо признали, что электронная коммерция имеет свою специфику. Но им также нужно было бы признать, что ее следовало вписать в их общую стратегию розничной торговли. Если бы они развивали электронную коммерцию в интеграции с основным бизнесом, то это немного растянуло бы процесс поначалу, зато в долгосрочной перспективе сэкономило бы много денег и времени.
Убедитесь, что ваша организация не совершает ту же ошибку в отношении больших данных. Потратьте время на то, чтобы продумать, как большие данные могут быть интегрированы в вашу общую стратегию управления данными и аналитикой. Это важный момент, поскольку ни один источник данных сам по себе не способен обеспечить оптимальные результаты. Сочетание различных источников данных – единственный способ извлечь из них максимальную ценность. Например, для того чтобы составить представление о потребителе, нужно совместить данные о продажах и поисковых запросах в веб-браузере, демографические данные и другие.
Если же организация внедрит отдельные системы и процессы для больших данных, не подумав о необходимости интеграции, ей будет гораздо труднее добиться в итоге искомой оптимизации. Компании должны стремиться создать единое аналитическое окружение, которое позволяет его пользователям осуществлять любой тип анализа с использованием любого типа и объема данных в любой момент времени. Далее в книге мы подробнее рассмотрим, как создать такое окружение. Читателям, желающим больше узнать о том, как получить максимальную отдачу от использования больших данных в маркетинге, я рекомендую прочитать книгу моей коллеги Лайзы Артур «Маркетинг на основе больших данных: как эффективнее привлечь потребителей и извлечь ценности» (Big Data Marketing: Engage Your Customers More Effectively and Drive Value){20}.
Назад в будущее
Одна из шумно разрекламированных концепций касательно больших данных связана с якобы новым миром, создаваемым набором нереляционных инструментов, которые не опираются на реляционные базы данных и не используют SQL в качестве первичного интерфейса. Аббревиатура SQL расшифровывается как «язык структурированных запросов», и на протяжении многих лет его называли «языком бизнеса». Нереляционнные наборы инструментов не используют SQL эксклюзивно либо вообще его не используют. Приверженцы нереляционного подхода считают, что возникла потребность в дополнительных языках, поскольку SQL во многих компаниях был практически единственным языком бизнеса. В конце концов почему бизнес не может быть многоязычным? Он и должен быть таковым. Более того, он должен был быть таковым с самого начала.
Давайте сразу же разоблачим роковое заблуждение. Дело в том, что нереляционная аналитика – далеко не новая концепция. Когда я начинал свою карьеру аналитика, реляционных баз данных в мире бизнеса еще не существовало. Как и не существовало SQL. Поэтому всю аналитику мы выполняли с помощью нереляционных методов. Например, я обычно использовал инструменты из SAS (системы статистического анализа). Для специалистов вроде меня язык SQL действительно был новинкой. Со временем мы поняли, что SQL лучше подходит для определенных видов задач и обработки. Но всегда встречались и такие виды обработки, которые профессиональные аналитики по-прежнему осуществляли вне окружения SQL.
Сегодня же, с появлением больших данных, организации вновь открыли для себя ценность обработки вне контекста SQL в тех случаях, когда это имеет смысл. Оказалось, что источники больших данных гораздо чаще, чем источники традиционных данных, оправдывают использование нереляционных технологий. Однако многие компании зашли слишком далеко и постарались втиснуть всю обработку в парадигму SQL. Это было ошибкой; организациям действительно необходимо включать в свой набор различные подходы. Просто вы должны знать, что нереляционные технологии были доступны всегда. И дело не в том, что в течение 2010-х гг. не существовало никакой необходимости в нереляционной обработке. Скорее компании слишком сильно сконцентрировались на SQL. Можно ожидать, что в будущем SQL останется доминирующим подходом для анализа данных, а нереляционная аналитика станет применяться в специфических целях.
Огромный сдвиг во взглядах на большие данныеПосле того как на протяжении нескольких лет предсказывалась скорая смерть SQL, сегодня нереляционные платформы стремятся дополниться интерфейсами SQL. В этом нашли отражение не только огромный сдвиг во взглядах, но и реальные потребности бизнеса.
Организациям следует внедрять набор нереляционных инструментов когда это уместно, но ни в коем случае нельзя предполагать, что при этом отпадет необходимость в использовании наряду с ними и SQL. Ведь так легко впасть в противоположную крайность, и многие организации сегодня подвергаются риску поступить именно так. Но, хотя в течение нескольких лет многие эксперты провозглашали смерть SQL, вследствие массовой перемены мнений сейчас возникло сильное движение за внедрение функциональности в стиле SQL в широкий спектр нереляционных платформ, таких как Hadoop. В очередной раз мы возвращается назад в будущее. Подробнее об этом тренде и о том, как правильно выбрать тип обработки, мы поговорим в пятой и шестой главах.
