Чтобы ответить на этот вопрос, важно понимать разницу между технологией как симптомом и технологией как причиной. В конце 2012 г. на ежегодной конференции, организованной моей компанией, у меня состоялся разговор с сотрудником крупного клиента. Этот человек входил в команду, занимавшуюся сетями и инфраструктурой, – сфера, с которой я редко сталкиваюсь по роду своей деятельности. Несмотря на то что наши миры редко пересекались, нам обоим было интересно поговорить друг с другом. Но когда разговор зашел о проблемах его компании, он не согласился с моим мнением о том, что дело вовсе не в технологиях.

Собеседник сказал, что понял меня, но при этом отметил, что в его компании использовались устаревшие сетевые протоколы. Корпоративная сеть попросту не справлялась с новыми объемами больших данных и новыми аналитическими требованиями. Сеть задыхалась, и ее поддержание в рабочем состоянии стало для него ежедневным кошмаром. Он поинтересовался, считаю ли я, что и в данном случае технология не является главной проблемой.

Симптом или причина?

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

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

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

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

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

Пожалуй, наиболее широко распространено ошибочное мнение о том, что Hadoop (или более широкий класс нереляционных инструментов, к которым принадлежит Hadoop) постепенно заменяет окружение реляционных баз данных. Hadoop – это проект с открытым исходным кодом, позволяющий разбивать крупные файлы на части и обрабатывать их параллельно. (Далее в этой главе мы рассмотрим технологию Hadoop подробнее.) В действительности же Hadoop наращивает реляционное окружение, и им обоим найдется место в аналитических структурах современных организаций.

Такая путаница проистекает главным образом из того факта, что сегодня практически 100 % компаний уже используют реляционную технологию. Соответственно по рынку гуляет множество историй о том, как компании «переходят на Hadoop». Однако выражение «переходят на Hadoop» неверно. Правильнее будет говорить, что компании «добавляют Hadoop». При ближайшем рассмотрении практически во всех случаях мы видим, что Hadoop добавляется к существующему окружению, но никак не все окружение мигрирует на Hadoop.

Путаница усугубляется тем фактом, что обратный сценарий встречается крайне редко. Крайне мало организаций используют только Hadoop без реляционного окружения, и эти редкие исключения сосредоточены в основном в Кремниевой долине. Таким образом, нечасто можно услышать о том, что пользователь Hadoop «переходит на реляционную модель» или «добавляет реляционную модель» к своему окружению.

Одна из крупнейших компаний, которая традиционно использовала только Hadoop и нереляционные подходы, – это Facebook. Как известно, Facebook всегда делала ставку на разработку в своих стенах собственных технологий и проприетарных систем. Действительно, Facebook разработала Hive, один из первых и ныне популярных компонентов языка структурированных запросов, доступный пользователям Hadoop. Тем не менее на конференции, организованной Институтом хранения данных (The Data Warehousing Institute, TDWI) в мае 2013 г., Facebook объявила о том, что добавляет к окружению Hadoop реляционный компонент{43}. Почему она это делает? Потому что команда Facebook поняла: реляционная технология исключительно хорошо решает некоторые из проблем, с которыми сталкивается компания. Facebook очень долго пыталась заставить Hadoop делать то, что платформа не предназначена делать. Комбинация технологий оказалась более разумной и позволила высвободить ресурсы для решения других задач.

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

Один из экспертов сообщил следующее: «Я понял, что Hadoop превосходно решает именно те задачи, для решения которых эта платформа и была создана за большие деньги такими компаниями, как Google и Yahoo! Если и у вас есть именно такие задачи, например соотнесение ключевых слов в поисковых запросах с содержанием веб-сайтов, тогда и для вас Hadoop станет феноменальной технологией. Если и другие задачи могут быть успешно решены при помощи этой парадигмы обработки, тогда Hadoop тоже окажется очень полезна. Однако существуют такие типы аналитики и обработки, для которых Hadoop совершенно неэффективна по сравнению с другими вариантами». Это вовсе не приговор Hadoop. В действительности ни одна технологическая платформа не может идеально подходить для всех видов обработки и всех ситуаций. У каждой платформы есть свои сильные и слабые стороны. Вот почему, как уже было сказано выше, организациям надо использовать разные технологические платформы и инструменты для разных типов аналитических процессов.