Технологический прогноз. БОЛЬШИЕ ДАННЫЕ: как извлечь из них информацию

Технологическийпрогноз

БОЛЬШИЕ ДАННЫЕ:как извлечь из них информацию

Ежеквартальный журналРоссийское издание2010 выпуск 3

В этом выпуске:

15Информационный потенциал больших данных

41Поиск эффективных инструментов работы с большими данными

57Новые задачи для ИТ-директора по организации работы с данными

29Использование распределенных вычислений в банковской сфере

37Большие данные — волшебная палочка маркетолога

53Большие данные в Интернете

1 Технологический прогноз

Статьи7 Между стандартами управления

и информационной стихией

На пути совершенствования управления бизнес-процессами и превращения потоков информации в «умные» цифровые ресурсы встает масштабная проблема больших данных

15 Информационный потенциал больших данных

Работа с большими данными требует особых подходов и инструментов

41 Поиск эффективных инструментов работы с большими данными

Применение компаниями кластерных технологий с открытым кодом для анализа данных

57 Новые задачи для ИТ-директора по организации работы с данными

Переключитесь на новый стиль мышления, вырастите новые таланты, освойте новые инструменты — и вы окажетесь на гребне следующей инновационной волны

69 Там, где кончается асфальт (послесловие научного рецензента)

Методы работы с большими данными предполагают широкую вариативность мышления и недюжинную изобретательность

Содержание

Бренд PwC объединяет фирмы, входящие в глобальную сеть фирм PricewaterhouseCoopers International Limited (PwCIL). Каждая фирма сети является самостоятельным юридическим лицом и не выступает в качестве агента PwCIL или любой другой фирмы сети. PwCIL не оказывает услуги клиентам. PwCIL не несет ответственность за действия или бездействие любой фирмы сети, не может контролировать профессиональные суждения, высказываемые фирмами сети, и не может никаким образом связать их каким-либо обязательством. Ни одна из фирм сети не несет ответственность за действия или бездействие любой другой фирмы сети, не может контролировать профессиональные суждения другой фирмы и не может никаким образом связать другую фирму сети или PwCIL каким-либо обязательством.

Содержание 2

Центр технологий и инноваций PwC

Интервью25. Проблемы работы со сверхбольшими массивами

данных

Джон Паркинсон (TransUnion) обсуждает проблемы в сфере обработки данных, которые станут актуальными для все большего числа компаний в ближайшие три-пять лет

29 Использование распределенных вычислений в банковской сфере

Сергей Рябов и Андрей Кувалдин (Сбербанк России) обсуждают особенности применения технологий параллельных вычислений и распределенного хранения данных в банковской сфере

33 Оптимизация затрат по обработке больших данных

Бад Алберс, Скотт Томпсон и Мэтт Эстес (Disney) делятся опытом эффективного применения технологий с открытым кодом и облачных вычислений

37 Большие данные — волшебная палочка маркетолога

Татьяна Чернова («КАРО Фильм») и Гамид Костоев (IBS Group) обсуждают перспективы развития маркетинговых инструментов анализа сверхбольших массивов неструктурированных данных

51 Hadoop принимается в эксплуатацию

Амр Авадалла (Cloudera) рассказывает, как и почему различные компании стремятся освоить новые технологии на основе Hadoop

53 Большие данные в Интернете

Владимир Габрелян (технический директор Mail.ru), Анатолий Орлов (руководитель разработки поиска, «Яндекс») и Роман Козлов (руководитель инфраструктурного отдела, «Нигма.РФ/itim.vn») рассказывают о способах хранения, обработки и извлечения больших данных в Интернете

65 Новые подходы к анализу клиентской статистики

Марк Тейлор и Рэй Велес (Razorfish) обсуждают, каким образом новые технологии способны сделать анализ петабайт веб-данных более эффективным

От издателя3 Предисловие к российскому изданию

4 Слово редактора

73 Благодарности

75 Словарь терминов


Предисловие к российскому изданию

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

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

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

Этот выпуск «Технологического прогноза» целиком посвящен теме больших данных. В нем представлены интервью с такими компаниями, как Disney Corporation, где применяются новые и инновационные подходы к управлению и извлечению информации из сверхбольших массивов данных. Кроме этого, спе-циально для российского выпуска издания мы подготовили ряд актуальных ма-териалов, в том числе интервью с главным ИT-архитектором Сбербанка России Сергеем Рябовым и его коллегой, занимающимися внедрением инновационных подходов обработки больших данных в этом одном из крупнейших банков мира.

PwC с удовольствием представляет вам этот выпуск «Технологического про-гноза», и я надеюсь, вы получите удовольствие от чтения представленных в нем материалов.*

Дуглас Даунинг Партнер, Консультационные услуги в области информационных технологий

* Вопросы и комментарии по содержанию «Технологического прогноза» присылайте, пожалуйста, по адресу [email protected]

Слово редактора 4


Слово редактора

Билл Джеймс, знаменитый «саберметрист»1 и автор ежегодника «Бейс-больное обозрение», увлекался бейсбольной статистикой с детства. Еще ребенком, в начале 1960-х, он вырезал бейсбольные карточки из коро-бок от зерновых хлопьев. Сегодня он — главный игровой консультант бейсбольной команды «Boston Red Sox», раньше консультировал другие команды Высшей лиги.

Джеймс изменил мир бейсбольной статистики больше, чем кто-либо другой за последние годы. По словам спортивного комментатора Боба Костаса, Джеймс «не просто понимает информацию. Он демонстрирует новый способ ее интерпретации». До Билла Джеймса все бейсбольные команды Высшей лиги исходили из одних и тех же стереотипных пред-ставлений о том, что нужно делать, чтобы выиграть матч. Например, они придавали чрезмерно большое значение показателю среднего процента отбитых мячей.

Джеймс изменил эти стереотипы. Он начал задавать вопросы перво-степенной важности, не имевшие на тот момент удовлетворительных ответов, и проводить аналитические исследования, ориентированные на поиск лучших ответов. Например, сколько дней отдыха нужно релиф-питчеру для восстановления? Ответ Джеймса: некоторые релиф-питчеры могут хорошо подавать в течении двух и более дней к ряду, другим же необходим перерыв между матчами в один-два дня. Это зависит от кон-кретного человека. Почему клоузер обычно появляется на поле только на девятом иннинге, хотя его роль часто выполняет лучший релиф-питчер в команде? По наблюдениям Джеймса, менеджеры зачастую не используют в полной мере потенциала лучших игроков.

Урок от Билла Джеймса следующий: чтобы получить наилучшие стати-стические показатели, нужно задавать наилучшие вопросы и искать на них ответы. Но какие вопросы окажутся лучшими? Джеймс применяет итеративный подход: он анализирует данные, которые у него уже есть или которые он может собрать, задает вопросы по результатам этого анализа и на них ищет ответы. При этом он не ограничивается одним набором ста-тистических показателей. Первый набор показателей подсказывает ему ряд вопросов, второй набор показателей дает на них ответы и, в свою очередь, порождает новые вопросы. Это процесс непрерывного поиска, призванный выявить лучшие вопросы, вместо того, чтобы предполагать, что такие вопросы уже заданы.

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

Проблема обработки таких данных включает два аспекта: во-первых, они с трудом поддаются анализу, во-вторых, их обработка их с помощью тра-диционных систем занимает слишком много времени и требует слишком больших затрат.

1 «Sabermetrics» — термин, придуманный Биллом Джеймсом, обозначает особый способ анализа статистических бейсбольных данных. Получен из акронима SABR (Society for American Baseball Research).


Эффективное разрешение этих проблем не требует радикально новых технологий. Достаточно выбрать оптимальную организацию архитекту-ры и программное обеспечение. Поисковые системы, такие как Google и Yahoo, предлагают практичное решение подобных задач. Они демон-стрируют, что эффективный и оптимальный по стоимости системный дизайн приведет к такой архитектуре системы, которая позволит обраба-тывать различные данные разными способами.

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

В этом выпуске журнала «Технологический прогноз» мы рассмотрим эко-номичные технологии распределенных вычислений, которые позволят компаниям обработать большее количество данных новыми методами. В статье «Информационный потенциал больших данных» на стр. 15 пред-ставлены исследовательские методы — аналитика, отличная от тради-ционной деловой информации. Эти методики позволят искать иголку сразу во многих стогах, а не в одном-единственном.

Статья «Поиск эффективных инструментов работы с большими данны-ми» на стр. 41 освещает растущий интерес к Hadoop-кластерам. Систе-ма Hadoop обеспечивает низкозатратную обработку больших объемов данных на базе программного обеспечения с открытым кодом и сотен или тысяч стандартных серверов. Она также позволяет применить упрощенные методы параллельной обработки более сложных данных. Методы, ценовые преимущества и масштабируемость вычислений (с применением Hadoop-кластеров) открывают дорогу компаниям к анализу большей части данных, работать с которыми раньше было не-возможно.

Сейчас идет шумиха вокруг больших данных и «облачной обработки дан-ных» (этим термином производители обозначают менее дорогостоящие технологии кластерных вычислений), но в статье «Новые задачи для ИТ-директора по организации работы с данными» на стр. 57 подчеркивает-ся, что у директора по информационным технологиям еще есть время на поиски и выбор наиболее подходящих решений и подходов. Самые мно-гообещающие возможности открываются в сфере обработки «серых» данных, то есть данных, поступающих из множества разнообразных источников. Чаще всего это необработанные и непроверенные данные, поступающие в огромных количествах и еще не имеющие установленной ценности. Анализ «серых» данных требует от специалиста совершенно иного набора навыков, а именно — природной склонности к поиску.

Как всегда, мы включили в наш выпуск интервью с руководителями ком-паний, обладающими широкой эрудицией по заявленным темам:

• Джон Паркинсон (TransUnion) обсуждает проблемы в сфере обработки данных, с которыми в ближайшие три-пять лет столкнется большинство компаний;

• Бад Алберс, Скотт Томпсон и Мэтт Эстес (Disney) делятся своим виде-нием использования гибких технологий на основе открытого кода и об-лачных вычислений;

Слово редактора 6


• Амр Авадалла (Cloudera) исследует причины внедрения фреймворка Apache Hadoop в поисковых технологиях, социальных медиа и в секторе финансовых услуг;

• Марк Тейлор и Рэй Велес (Razorfish) обсуждают преимущества новых масштабируемых технологий анализа клиентских данных.

Вы можете ознакомиться с этими статьями, а также с другими выпусками нашего журнала на сайте pwc.com/techforecast. Если вы хотите получать будущие выпуски журнала «Технологический прогноз» в виде приложений в формате PDF, предлагаем вам оформить подписку на странице pwc.com/techforecast/subscribe.*

Мы будем признательны за ваши отзывы и предложения для будущих ис-следований и анализа в следующих выпусках.

Том ДеГармо Руководитель направления технологий [email protected]

* Информация о размещении статей и номеров российского издания «Технологического прогноза», а также о том, как оформить подписку, приведена на стр. 76.


Между стандартами управления и информационной стихией

На пути совершенствования управления бизнес-процессами и превращения потоков информации в «умные» цифровые ресурсы встает масштабная проблема больших данных. Применение методик свободного поиска информации в социальных сетях порождает проблему ее согласования с корпоративными стандартами обработки данныхАвтор: Владимир Рубанов

Между стандартами управления и информационной стихией 8


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

В первом номере «Технологического прогноза» основное внимание было сосредоточено на каче-стве моделирования бизнес-процессов и необхо-димости учета особенностей компании как адап-тивной системы, представляющей собой результат комплексных взаимодействий между людьми (Б. Паркер, К. Васден, А. Моррисон. «Использование непредсказуемости»). По утверждению авторов, точный прогноз и контроль результатов изменений требует моделирования как детерминистических, так и эмерджентных свойств организации. Необхо-димость создания качественной модели построения и функционирования корпорации как основы раз-работки и реализации соответствующей стратегии приводит к постановке вопроса о роли ее высшего руководителя в определении контекста стратегиче-ского видения ситуации и достижения согласованно-сти действий между всеми участниками процессов управления. Простое суммирование разрозненных частностей не может привести к созданию целост-ной системы управления и обеспечить должную координацию процессов преобразований и текущей деятельности компании. В материалах первого но-мера раскрыта суть трех распространенных методик разработки и реализации управленческих проектов: исследование деятельности компании, агентное моделирование и анализ ценностных сетей. Приме-нение этих методов создает смысловой фундамент формализации процессов внутри корпорации и в ее взаимодействии с внешней средой.

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

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

В. Байя и Б. Паркер связывают будущее компаний с необходимостью использовать «умные» цифровые ресурсы для формирования метапроцесса сквозного управления деятельностью корпорации через изме-нения и трансформации бизнеса.

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

Опасность превращения хранилищ данных в их «кладбища»На пути совершенствования моделирования управ-ления бизнес-процессами и превращения потоков информации в «умные» цифровые ресурсы встает масштабная во всех смыслах проблема, на которую обращает внимание Т. ДеГармо в третьем номере «Технологического прогноза». Предприятия начина-ют тонуть в море данных, которые имеют разную ценность и используются не лучшим образом.

Ключевым моментом в создании системы управления бизнес-процессами является моделирование, направленное на достижение целей корпорации и обеспечение целостности процесса ее деятельности


Существуют исследования компании IDC с оцен-ками состояния и тенденций изменения типов и объемов данных, которые выражаются следую-щими числовыми значениями. В настоящее время в глобальном информационном пространстве объ-ем структурированных данных составляет 20%, а неструктурированных — 80%. Каждые 18 месяцев происходит удвоение объемов данных. При этом темпы прироста структурированных данных за это время составляют 32%, неструктурированных — 63%, а объем репликаций (копий) возрастает на 49%. Объемы хранения данных в экзабайтах1 в 2009 году оцениваются следующим образом: структурированная информация — 5 экзабайт; неструктурированная информация — свыше 11 экзабайт. Экстраполяция сложившихся тен-денций изменения глобального информационного пространства позволило компании IDC сделать следующий прогноз на 2013 год: объем структури-рованной информации составит около 10 экзабайт, а неструктурированной — свыше 55 экзабайт2.

Взрывной рост объемов данных отмечается и на корпоративном уровне. Исполнительный вице-президент и директор по технологиям Группы общих сервисов корпорации Disney Б. Алберс за-мечает в этой связи: «Пожалуй, сегодня мы за год генерируем больше данных, чем вся Walt Disney Co. за первые 80 лет существования. Проблемы начинаются, когда мы задумываемся, что со всем этим делать». Высокие темпы роста объема ин-формационного пространства при доминировании в его составе неструктурированных данных (как по абсолютным показателям, так и по более высо-ким темпам прироста) создают угрозу превраще-ния хранилищ информации в их «кладбища».

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

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

Что делать с большими даннымиНеобработанные и непроверенные данные, по-ступающие из множества внешних разнообразных источников, определяются в «Технологическом прогнозе» как «серые» данные. Они обычно ха-рактеризуются большими объемами и не имеют явно выраженной ценности. Отбор и аналитиче-ская обработка больших объемов «серых данных» требует от руководителей корпораций и корпора-тивных архитекторов высокого профессионально-го уровня, а от работающих с ними аналитиков — специфических навыков, способностей, личных качеств и технологического обеспечения.

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

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

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

1 1 экзабайт равен 1018 байт2 Sources: IDC worldwide enterprise disk in Exabytes from «Changing Enterprise Data Profile», 12/2007.



ценность неструктурированных данных указывают многие специалисты, призывающие относиться с большей серьезностью к такой информации. Так, С. Томпсон (Walt Disney Co.) делает на основании этого вывод о том, что технологией будущего яв-ляется хранение неструктурированных данных в необработанном формате. Применяемые для этого инструменты обеспечивают техническую поддерж-ку определенного типа анализа, позволяющего рассматривать мир в его натуральном виде, нахо-дить в нем повторяющиеся сходства и различия с последующим углубленным изучением перспектив-ных зон и направлений.

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

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

Суть предлагаемой в «Технологическом прогнозе» методики анализа информации на основе техноло-гий свободного поиска — это просеивание данных

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

Масштабную работу с большими данными органи-зовала компания Walt Disney Co. Это позволило наладить на основе технологий свободного поиска процесс извлечения ценных сведений из больших данных и создать новый тип анализа, отличный от традиционных систем анализа деловой инфор-мации. Разработанные Walt Disney Co. методики обработки больших данных позволяют специально созданной для этого группе изучать массивы раз-нотипной информации для выявления повторяю-щихся схем поведения клиентов. Представители компании Razorfish Р. Велес и М. Тейлор на примере применения сервисов Amazon Elastic Compute Cloud (EC2), Elastic MapReduce и Microsoft Azure Table раскрывают в «Технологическом прогнозе» воз-можности технологий работы с большими данными для массовой сегментации клиентов и интеллек-туального анализа данных. Такого рода методики станут, по их мнению, важным источником полу-чения ценных сведений для компаний, расширят возможности поиска, получения и использования знаний «из дикого и запутанного мира информа-ции», обеспечат экономию за счет обращения к открытым данным и применения дешевых методов их обработки.

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

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

Складывающаяся технологическая практика работы с большими данными указывает на целесообразность реализации кластерного подхода на базе компьютеров массового использования и программного обеспечения с открытым исходным кодом


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

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

Аналитики решают всеЭто порождает необходимость совместного рас-смотрения и взаимосогласованного применения трех названных выше методов в рамках целост-ного информационно-аналитического комплекса: моделирования и стратегической координации; разметки неструктурированной информации ме-таданными и формирования «умных» цифровых ресурсов; свободного поиска информации в рабо-те с большими данными. Такое видение проблемы актуализирует необходимость перевода всех по-

лучаемых и обрабатываемых различными спосо-бами данных в единый формат по определенному стандарту. Это позволит объединить преимуще-ства каждого из названных подходов и создать методологические основы агрегирования объем-ных и разрозненных данных в одном месте для их совместной аналитической обработки в информа-ционной системе.

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

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

Смысл текста ценнее битов информацииСвязь между моделями управления, «умными» цифровыми ресурсами и свободным поиском дан-ных в открытом информационном пространстве можно представить следующим образом (рис. 1).

Информационное пространство

Метаданные

Понимание

Модель

ИдентификацияДокумент

Практика

Язык

Смысл Cлово

Логика

Стандарт

Зна

ние

Баз

а д

анны

х

Классификатор

Грамматика

Теория Представление

Контекст Текст

Cемантика

Рис 1. Схема включения данных, получаемых свободным поиском в глобальной сети, в аналитическое обеспечение организации



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

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

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

Технологические заделы развития аналитикиВ настоящее время отмечается развитие как общих методик форматирования и алгоритмизации обра-ботки данных в информационных системах органи-заций, так и технологий работы с большими данными в глобальных сетях. Первое направление развития ассоциируется с разработками Wolfram Inc во главе с британским физиком и математиком С. Вольфрамом. Созданный этой компанией продукт WolframAlpha представляет собой большую энциклопедию, снаб-женную механизмом поиска и вычисления, а также отображения результатов в структурированном виде. Создатели называют его Computational Knowledge

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

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

Соединение «серых» данных со структурированной информацией для совместной обработки порождает необходимость их разметки метаданными в соответ-ствии с форматами корпоративных систем. На эту проблему обращает внимание Б. Матайсел (компа-ния Achievo) в данном номере «Технологического прогноза». На повестке дня стоит вопрос о конвер-генции двух основных направлений: моделирования и расширения сферы применения форматированных документов; разработки и соблюдения общих правил работы с большими данными в глобальных сетях.

От «коллекции документов» к «коллекции знаний»Одним из наиболее масштабных и заметных направ-лений приложения усилий в данной области явля-ется инициатива Т. Бернерса-Ли по формированию «семантической сети» (Semantic Web или Web 3.0). Web 3.0 позиционируется как следующая ступень совершенствования Web 1.0 и Web 2.0, направлен-ная на семантический поиск по Интернету. Таким образом, идея «умных» цифровых ресурсов в корпо-ративных информационных системах дополняется идеей «умного» поиска в глобальном пространстве на базе общей платформы социальных сетей.

Предполагается, что коллективное знание в первую очередь опирается на связи. А связи — это социаль-ные сети, и Web 3.0. будет расти снизу вверх, посте-пенно превращая весь веб-контент из «коллекции документов» в «коллекцию знаний». При этом луч-шим транслятором знаний для человека в системе Web 3.0 все еще останется другой человек — экс-перт в заданной области. Для превращения концеп-ции семантической паутины в реально работающий


Web 3.0 консорциумом W3 предполагается создание сети документов, содержащих метаданные о ресур-сах. И если сами web-ресурсы предназначены для восприятия человеком, то метаданные — для по-исковых роботов и других интеллектуальных аген-тов. Для Web 3.0 разработаны специальные языки описания метаданных: язык онтологии для Интер-нета OWL (Web Ontology Language) и RDF (Resource Description Framework). Наиболее впечатляющим успехом реализации Web 3.0 является WikiPedia и сформировавшееся сообщество пользователей FreeBase, которые создают связи к базам данных по метапризнакам, категориям и фольксомонии.

Следует отметить, что проект семантической сети имеет как горячих сторонников, так и убежденных скептиков. Идея создания универсального формата для обмена данными на базе некоторой онтологии на практике не приживается. Развитие блогосферы указывает на то, что люди начали обмениваться данными без обращения к формализмам семан-тической сети и разметки своих сообщений мета-данными. Расчет на то, что коммуникации будут проще, если все будут описывать вещи одинаковым способом, оказывается трудно реализуемым, а главное — слабо востребованным. Выясняется, что формализация связей между людьми в свободных коммуникациях лишается значительной части своего первоначального смысла, а попытка выразить не-явные и туманные взаимоотношения ясным и явным способом не проясняет смысл, а разрушает его. В связи с этим один из критиков концепции Web 3.0 К. Ширки замечает, что попытки навязать семантику в области взаимоотношений между людьми закан-чиваются поражением семантики и не делают связи более информативными3.

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

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

Навязать пользователям единую формализован-ную точку зрения на окружающий нас предмет-ный мир и невозможно, и не нужно. Но и строить

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

Одной из таких областей является корпоративная деятельность. Успех корпоративного управления за-висит от алгоритмически четкой проработки стра-тегии и единства ее понимания всеми участниками целостного бизнес-процесса.

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

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

3 Источник: http://www.shirky.com/writings/semantic_syllogism.html (Ссылка проверена 01.11.2010)

Необходимо идти по пути подготовки осмысленных в рамках корпоративной логики документов, а не пытаться найти смыслы в текстах, не отвечающих такой логике



правила и процедуры подготовки корпоративных документов в соответствие со стратегическим за-мыслом деятельности организации и следованием определенному контексту при создании текстов обеспечения решения управленческих задач.

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

От информационного пространства — к смысловому универсумуНельзя отказываться и от попыток создания уни-версальных моделей представления и аналити-ческой обработки в информационных системах. Однако для этого необходимо осознание того, что формирование «умных» цифровых ресурсов и «умных» поисковых машин в информационных системах выходят за технологические рамки и отно-сится к фундаментальной проблеме искусственного интеллекта.

Надежды на то, что с увеличением вычислитель-ных мощностей машина сама научиться думать о мире подобно человеку — необоснованная и несбыточная фантазия. Это связано с распро-страненным заблуждением, что проблема ис-кусственного интеллекта возникла с появления кибернетики. Такой технократический оттенок привел к отождествлению мышления с вычисле-нием и выдвинул на роль создателей искусствен-ного интеллекта алгоритмистов, программистов и исследователей мозга. Упоение близкими ожида-ниями создания машинного разума технократами привело к пренебрежению классической философ-ской традицией, являющейся средоточием знания о естественном интеллекте. Справедливости ради необходимо подчеркнуть, что осмысление искус-ственного интеллекта началось не с кибернетиков ХХ века, а с работ монаха Р. Луллия XIII века. Для него множество истин представлялось конечным, а все осмысленные представления о мире полага-лись выводимыми из упорядоченного множества по определенным правилам (логическая машина Луллия). Возможность существования и форми-рования «алфавита человеческих мыслей» допу-скали Р. Декарт, Б. Паскаль, Г. Лейбниц4, и Д. Локк.

А. Вержбицкая с концепцией «семантических примитивов»5 и Ю. Апресян с «квантовыми эле-ментарными смыслами»6 подошли вплотную к идее смысловых преобразований.

Многие ожидания искусственного интеллекта свя-зываются с результатами исследований мозга. Но мыслит не мозг, а человек с помощью мозга. Коллек-тивный разум человечества мозгом не является и развивается независимо от воли каждого входящего в него человека. Российские исследователи пробле-мы искусственного интеллекта С. Бычков и А. Кри-чевец полагают, что человечество — это глобальная формальная дедуктивная система, корни которой лежат в греческой математике7. Поэтому проблему искусственного интеллекта нельзя решить, не решая проблему естественного интеллекта.

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

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

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

4 Позиция Лейбница сводится к следующему: «Природа имеет обыкновение создавать как можно большее как можно меньшими средствами, то есть действовать простейшим способом. «Алфавит человеческих мыслей» [Alphabetum Cogitationum humanorum] есть каталог тех [понятий], кото-рые мысленно представимы сами по себе и посредством комбинаций которых возникают остальные наши идеи». Источник: Leibniz G.W. De organo sive arte margna cogitandi.- In: «Opuscules et fragments inedits», ed. L. Couturat, Paris, 1903, p. 430

5 Вержбицкая. А. Семантические примитивы // http://www.belb.net/obmen/Wierzbicka.htm6 Апресян Ю. О языке толкований и семантических примитивах // Серия литературы и языка. 1994. Т. 53. 4.7 Левкович-Маслюк Л. Естественный и искусственный разум: джем-сейшн // Компьютерра. 1998, 40.


Информационный потенциал больших данных

Работа с большими данными требует особых подходов и инструментовАвтор: Гален Груман

Информационный потенциал больших данных 16


Как большинство корпораций, компания Walt Disney Co. плывет по расширяющемуся морю больших данных — информации, накапливаемой о коммерческих операциях, клиентах, транзак-циях и т. д., неструктурированной информации, генерируемой в социальных сетях и других веб-репозиториях, включая домашнюю страницу самой компании Disney и сайты ее тематических парков, фильмов, книг и музыки, плюс многочис-ленные сайты ее крупных бизнес-подразделений включая телевизионные компании ESPN и ABC.

«Пожалуй, за год мы генерируем больше данных, чем вся Walt Disney Co. произвела за первые 80 лет существования, — отмечает Бад Алберс, исполни-тельный вице-президент и технический директор группы распределенных технологических сервисов компании Disney. — Проблемы начинаются, когда мы задумываемся, что со всем этим делать».

Алберс и его команда находятся на ранних стади-ях формулирования ответов на свои собственные вопросы при помощи низкобюджетной архитектуры кластерных вычислений, базирующейся на ряде экономически эффективных и масштабируемых технологий Apache Hadoop, распределенной файло-вой системы с открытым кодом на базе Java, осно-ванной на файловой системе Google и развиваемой на платформе программного обеспечения Apache. Эти пока еще только появляющиеся технологии позволяют аналитикам компании Disney обрабаты-вать многочисленные терабайты информации без существенных затрат времени и средств, характер-ных для традиционных систем бизнес-аналитики.

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

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

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

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

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

«Пожалуй, сегодня за год мы генерируем больше данных, чем вся Walt Disney Co. произвела за первые 80 лет существования». — Бад Алберс, Disney


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

Бад Алберс считает, что анализ больших данных неминуемо будет иметь существенное значение. «Скорость бизнеса в наши дни и объем данных, в который мы погружены, заставляют нас искать новые подходы к этим данным, их анализу и ис-пользованию», — говорит он.

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

для повышения эффективности информацион-ных центров, — виртуализации.

Виртуализация обеспечивает целый ряд преиму-ществ, в том числе более высокий коэффициент использования существующих серверов и возмож-ность туннелирования процессов для предотвра-щения возникновения узких мест. Организация также может при необходимости передавать на-грузку внешним облачным провайдерам, используя их как резервные ресурсы (для этого используется специальный термин cloudbursting). Благодаря при-менению таких методик Технологическая группа стандартных сервисов снизила темпы прироста расходов на ИТ с 27% до 3%, увеличив годовой прирост объемов обработки данных с 17% до 45%.

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

Hadoop

Репозиторий метаданных

Облачный D-кластер обработки данных

Интерфейс для кластера (MapReduce/Hive/Pig)

Данные о пользовании сайтами

Центральный лог-сервис

Основная ИТ-система и системы

бизнес-подразделений

Внутренние партнеры

Аффилированные компании

Посетители сайтов

Болеекачественный

пользовательскийсервис

1

2 3

4

Рис. 1. Hadoop-кластер компании Disney и центральная регистрационная служба

Новый облачный D-кластер данных компании Disney может масштабироваться для решения обработки (1) слабострукту-рированных данных о пользовании сайтами путем создания (2) центрального лог-сервиса, (3) экономически эффективного аналитического процессора и кластера из стандартных компьютеров на базе Hadoop. Результатом (4) является предо-ставление пользователям более персонализированного и гибкого сервиса.

Источник: Disney, 2010



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

Компания Disney собрала Hadoop-кластер и уста-новила центральный лог-сервис для датамайнинга, чего не могла сделать до сих пор. По планам вну-тренний доступ к кластеру должен был быть открыт в октябре 2010 года. На рис. 1 показано, какие преи-мущества Hadoop-кластер предоставит внутренним пользователям, бизнес-партнерам и клиентам.

Проще говоря, низкая себестоимость Hadoop-кластера означает большую свободу для экс-перимента. Под Hadoop-кластер в Disney задей-ствовано паау десятков уже морально устаревших серверов и небольшая группа сотрудников. Мэтт Эстес, главный архитектор данных Технологи-ческой группы стандартных сервисов компании Disney, оценивает стоимость проекта в пределах от 300 тыс. до 500 тыс. долларов.

«Раньше для такой инициативы мне пришлось бы за-ложить в смету расходы от 3 до 5 млн долларов, — подчеркивает г-н Алберс. — Сегодня я могу реализо-вать ее, не опускаясь до ватерлинии по расходам».

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

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

Особенности анализа больших данныхЧто можно в целом ожидать от использования Hadoop для целей анализа данных? Прежде всего, возможности вести исследовательский по-иск, что невозможно традиционными системами бизнес-аналитики. Новая бизнес-аналитика будет давать не окончательные ответы, а задавать на-правления нового поиска. Для этого потребуется иной образ мышления, способность начать работу с исследования, и по результатам этого иследова-ния выработать рабочие гипотезы, которые под-вергнутся проверке, и только потом будут утверж-дены и консолидированы.

Такие методы могли бы быть применены для ответа на следующие вопросы: какие индика-торы могли бы указать на предстоящий скачок интернет-трафика, какие ткани и цвета будут по-пулярны среди законодателей моды в определен-ных социальных группах, из каких источников мы могли бы получить такую информацию, велико ли влияние этого законодателя на веб-трафик через его или ее социальную сеть? Во вставке «Инфор-мационная ценность больших данных» приведены дополнительные примеры типов вопросов, на которые можно ответить на основе анализа боль-ших данных.

Информационная ценность больших данных

Примеры задач, которые могут решаться при помощи анализа информационных потоков больших данных:

• прогноз темпов оттока клиентов — на основании анализа данных колл-центров, служб технической поддержки и трафика веб-сайтов;

• анализ изменения репутации компании и вероят-ности действий в отношении нее со стороны регу-лирующих органов — на основании мониторинга социальных сетей и новостных веб-сайтов;

• прогнозирование спроса в реальном времени — на основе самых разных данных, таких как про-гнозы погоды, информация о бронировании транс-портных билетов, интенсивность транспортного потока, данные кассовых аппаратов в розничных торговых точек;

• оптимизация цепи поставок — на основании анали-за метеорологических условий, сценариев потенци-альных катастроф и политических беспорядков.

«Скорость бизнеса в наши дни и объем данных, в который мы погружены, означают необходимость новых способов и новых технологий получения данных, их идентификации и степени выгоды для нас от их обработки». — Бад Алберс, Disney


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

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

Большиеобъемыданных

Нереляционные данные

Реляционные данные

Малыеобъемыданных

Большие данные (с помощью Hadoop/MapReduce)

Низкая масштабируемость

Традиционные системы бизнес-аналитики

Низкая аналитическая ценность

Рис. 2. Местоположение больших данных

Источник: PwC, 2010

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

Подходы к обработке больших данных позволяют задавать больше вопросов к большим объемам данных, открывая широкий спектр потенциальных

возможностей, которые вы не могли себе позволить в прошлом. «Одна из ролей аналитики — бросить вызов исходным посылкам», — считает Мэтт Эстес. Системы анализа деловой информации на это не рассчитаны, они предназначены для уточнения из-вестных вопросов и обнаружения вариаций, кото-рые могут указать на отклонения от ожидаемых результатов.

Более того, анализ больших данных обычно ите-ративен: вы задаете один вопрос или проверяете один набор данных, потом придумываете новые вопросы или решаете рассмотреть больше данных. Это отличается от стратегии «единого источника истины» стандартных систем анализа деловой ин-формации и хранилищ данных. Команда из Disney начала с обеспечения возможности находить дан-ные и получать к ним доступ и затем приступила к итеративному усовершенствованию процессов об-работки данных. «Мы активно двинулись вперед, чтобы определить направления и базу дальнейшей работы. Затем, вместо того, чтобы пытаться устро-ить Большой взрыв, мы стали постадийно доби-ваться улучшений», — рассказывает г-н Алберс.

К ажиотажу вокруг технологий работы с больши-ми данными присоединились и другие компании. Первыми новые технологии восприняли веб-ориентированные компании, изначально вы-нужденные перерабатывать огромные объемы данных, такие как Yahoo!, Twitter и Google. Сегодня к концепции больших данных присматриваются и более традиционные компании (например, служ-ба кредитных рейтингов TransUnion), оценившие преимущества в плане экономии затрат и масшта-бируемости, реализованные веб-компаниями.

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

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



Высокиепроцес-

синговыемощности

Пользователи облачных вычислений с низкой потребностью в вычислительных мощностях

Централизованная архитектура вычислений

Предприятия, сталкивающиеся с проблемами масштабирования и высокой стоимости процессинга

Google, Amazon, Facebook, Twitter и др. (масштабы операций обуславливают использование нереляционных хранилищ данных)

Большинство предприятий

Распределенная архитектура вычислений

Низкиепроцес-

синговыемощности

Рис. 3. Карта архитектуры данных в 2010 году


Подходы различных предприятий к работе с большими данными

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

«В TransUnion мы тратим много времени на пере-бор десятков и сотен миллиардов фрагментов данных в поисках элементов, приближенно соот-ветствующих шаблону, — рассказывает исполняю-щий обязанности директора по информационным технологиям TransUnion Джон Паркинсон. — Нам необходимо осуществлять тщательное сопостав-ление но по нечетким признакам и категоризацию очень больших наборов слабоструктурированных данных».

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

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

она доработана на 80%. В коде оказались огра-ничения, которые привели к отказу всей системы задолго до того, как мы достигли, с нашей точки зрения, теоретического предела».

Паркинсон выражает мнение многих руководите-лей в сфере ИТ, в основном скептически относя-щихся к программному обеспечению с открытым кодом. «Если у меня есть хорошие инженеры, я не хочу, чтобы они тратили все свое время на тех-ническую поддержку того, что как продукт дол-жен был бы войти в нашу архитектуру в готовом виде», — считает он.

Это вполне законная точка зрения, особенно учитывая объемы данных, с которыми работает TransUnion, — 8 петабайт из 83 тыс. источников в 4 тыс. форматах, и это число неуклонно растет. Функции обработки этих данных имеют критиче-ское значение для выполнения миссии компании. Система оценки кредитных рейтингов должна работать бесперебойно и рассчитывать точные рейтинги по нескольку раз в день. Это оператив-ная система, на основе которой каждый день принимаются миллионы важнейших коммерческих решений (более подробная информация о компа-нии TransUnion приведена в интервью с Паркинсо-ном на стр. 27).

Система, используемая компанией Disney, пред-назначена скорее для исследовательской работы или в лучшем случае для подготовки отчетов, которые со временем могут иметь значение при разработке продуктовой стратегии или дизайна веб-сацтов. Отказ системы или необходимость ее незначительной модификации не критичны.

Но Алберс имеет собственное мнение об упомяну-тых инструментах, отмечая, что Технологическая группа стандартных сервисов компании Disney тоже имеет дело с немалым количеством данных. По его мнению, Hadoop и MapReduce ничуть не хуже мно-гих лицензионных программных продуктов. «Я абсо-лютно допускаю, что мы работаем вещах, которые отказывают», — признает он и шутливо добавляет: «Как будто ни один коммерческий продукт, с кото-рым я имел дело, никогда не отказывал».

Архитектор данных Эстес также отмечает опе-ративность разработчиков открытых решений: «Мы что-то выявляем в ходе тестирования, и тебе есть с кем пообщаться на другом конце провода. Это же их детище, верно? И они, естественно, стремятся решить вопрос».

Алберс подчеркивает эффективность Hadoop и MapReduce в плане общего объема затрат: «Мои расходы на программное обеспечение равны нулю. Конечно, остаются расходы на внедрение, но их уровень практически постоянен, независимо от конкретной ситуации. Конечно, на этом этапе игры вам могут потребоваться более компетентные


сотрудники, и, возможно, их труд придется оплачи-вать немного выше, зато вам уж точно не придется утверждать расходы на кластер Teradata. Речь идет лишь о хранилищах данных класса Tier 3, т.е. об очень скромной себестоимости хранения данных».

Аргументы Алберса тоже вполне обоснованны. По прогнозу PwC, необходимый уровень качества инструментов с открытым кодом будет достигнут скорее раньше, чем позже, причем они уже вполне пригодны для применения в ситуациях и приложе-ниях, не имеющих критического значения. Поэто-му в статье «Новые задачи для ИТ-директора по организации работы с данными» на стр. 69 мы рекомендуем предпринять осторожную разведку в этом направлении.

Новые бизнес-вопросы

Безусловно, экономия затрат составляет не-малое преимущество, однако, по мнению PwC, наибольший выигрыш от применения анализа больших данных с использованием Hadoop заклю-чается в потенциальном росте продаж. «Не-структурированные данные организаций заклю-чают в себе огромную потенциальную ценность, и сегодня к ним начинают относиться с большей серьезностью», — считает главный специалист по архитектуре PwC Том Уркхарт. Их следует рассматривать как «целый Google в одной ко-робке, позволяющий осуществлять интеллекту-альный поиск вне зависимости от структуриро-ванности или неструктурированности контента», утверждает он.

Методы анализа по образцу Google с применением Hadoop, MapReduce и аналогичных решений ра-ботают принципиально иначе, чем традиционные системы бизнес-аналитики, которые используют строго форматированные кубы данных и извле-кающие информацию из хранилищ. Инструменты обработки больших данных позволяют работать с данными без необходимости их предварительно-го моделирования архитектором, поэтому можно анализировать и сравнивать данные различного типа и различного уровня логической строгости. Поскольку эти инструменты обычно не стирают и не изменяют исходные данные перед началом анализа, они остаются доступными для последую-щего детального анлиза.

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

Неконсолидированные данные(не собираются)

Все собранные данные

Обобщенные данные по подразделениям

Наблюдения

Потери информации

Консолидация

Более глубокие наблюдения

Меньш

ие потери инф

ормации

Исследование

Все собранные данные

Обобщенные данные по подразделениям

Обобщенные данные по

предприятию

КонсолидацияОбобщенные данные по

предприятию



Рис. 4. Потери информации в процессе консолидации данных




Мэшап сервисы по выявлению закономерностей

Существует еще одно применение больших дан-ных — выявление закономерностей на основе ана-лиза данных из разнородных источников в режиме реального времени. Интернет-магазин Amazon.com первым начал давать клиентам рекомендации по выбору продукции, применяя технологии обработ-ки больших данных для анализа данных о клиенте, включая историю его покупок, рейтинги продуктов и комментарии. Алберс надеется создать нечто аналогичное. Его цель в режиме реального време-ни предоставлять рекомендаций клиентам, захо-дящим на сайт, в магазин или звонящим в службы бронирования компании Disney на основе анализа их прошлого онлайнового или офлайнового пове-дения при коммуникациях с Disney.

Издательство O'Reilly Media, известное своими техническими публикациями и Интернет-сайтами, сотрудничает с Белым домом в области разра-ботки мэшап приложений для выявления зако-номерностей на основе анализа неоднородного контента, которые могут быть использованы лоббистами и политиками. Так, на основании комбинированного анализа данных переписи населения США и трудовой статистики можно определить, на какие графства приходятся наи-большие объемы международной и внутренней иммиграции, чтобы затем сопоставить эти харак-теристики с изменениями расходов правитель-ства, говорит директор по научным исследовани-ям O'Reilly Роджер Магулас.

Mashups like this can also result in customer-facing services. FlightCaster for iPhone and BlackBerry uses Big Data approaches to analyze flight-delay records and current conditions to issue flight-delay predictions to travelers.

Подобное этом мэшап приложение может стать основой для создания клиентских сервисов. Приложение FlightCaster для iPhone и BlackBerry применяет методики обработки больших данных для анализа данных о задержках рейсов и теку-щей информации о метеоусловиях, и на его основе предоставляет пассажирам прогноз задержки их рейсов.

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

Специальное исследование по сходной цене

Методики работы с большими данными позволяют организовать низкозатратный поиск закономер-ностей, которые могут означать новые возможно-

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

Большой потенциал для такого анализа содержит-ся, например, в медицинской статистике. «Многие случайные открытия совершаются на выходные, когда люди, работающие с данными, просто игра-ют с ними», — отмечает Дуг Ленат, основатель и исполнительный директор Cycorp и бывший про-фессор Стэнфордского университета и Универси-тета Карнеги-Меллон.

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

Анализ данных, не подготовленных для обработки традиционными системами бизнес-аналитики

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

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

«Серые» данные

НеобработанныеСмешанные данные и контекст

ЗашумленныеГипотетические

НепроверенныеОриентировочные

Менее достоверныеВ ведении бизнес-

подразделений

например, Википедия например, данные систем финансового учета

«Черные» данные

КлассифицированныеРазделенные по типамОчищенныеФактические

ПроверенныеПодтвержденныеБолее достоверныеВ ведении ИТ

Рис. 5. «Серые» данные против «черных» данных



Человек использует свои знания и опыт для того, чтобы надлежащим образом взвесить и сопоставить информацию, найденную в «серых» данных, и разра-ботать исходя из этого новые пути развития бизнеса. На рис. 5 приведено сравнение «серых» данных и более нормализованных «черных» данных.

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

Аналогичные методы позволяют выявить измене-ния вкусов покупателей, например в отношении одежды или мебели. А анализ «серых» данных, относящихся к стоимости ресурсов и изменениям графика перевозок, позволяет предугадать рост загрузки существующих поставщиков и найти аль-тернативных.

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

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

Реализация этого потенциала возможна только при условии консолидированного анализа всех этих данных. Сегодня информации попросту слиш-

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

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

Что еще важнее, возникающие сегодня методики обработки больших данных в перспективе могут предоставить возможность проведения такого анализа не только профессиональным исследова-телям и бизнес-аналитикам. Ряд новых компаний предлагают инструменты, которые позволяют применить для работы с большими данными всем знакомые инструменты, типа баз данных на осно-ве SQL или электронных таблиц Excel. Это позво-лит заниматься анализом данных более широкому кругу специалистов.

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

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



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

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

нейшую информацию, от своего местонахожде-ния и физического состояния до информации об окружающей среде.

Подобная ситуация уже возникла в связи с рас-пространением смартфонов со встроенными видеокамерами, микрофонами, средствами геопозиционирования и компасами. Переносные медицинские датчики, температурные маркеры для упаковочных контейнеров и другие радио-фицированные датчики являются реальностью уже сегодня. Завтра они превратятся в источники сообщений для Twitter и Facebook, предоставляя обширные объемы новых данных, способных стать источником ранее недоступной ситуативной информации о поведении и окружающей среде, а также и огромного количества «шума», скрываю-щего за собой эту информацию.

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


Проблемы работы со сверхбольшими массивами данныхДжон Паркинсон (TransUnion) обсуждает проблемы в сфере обработки данных, которые станут актуальными для все большего числа компаний в ближайшие три-пять летИнтервью провели: Винод Байя, Алан Моррисон

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

PwC: Работая в TransUnion вы опробовали мно-гие технологии обработки больших объемов данных. Что вы думаете о Hadoop и MapReduce?ДП: MapReduce является весьма привлека-тельной технологией для определенного класса вычислительных задач. Если вы работаете с таким классом задач, имеет смысл задуматься об использовании MapReduce. Однако глав-ная проблема этой системы состоит в том, что количество людей, которые действительно понимают математические формулы, лежащие в основе MapReduce, гораздо меньше числа людей, пытающихся понять, что со всем этим делать. Эта система еще не эволюционирова-ла до такого уровня, чтобы технический спе-циалист на любом предприятии мог с легкостью ее использовать.

PwC: Какой класс задач вы имеете в виду?ДП: MapReduce лучше всего работает в случаях, когда необходимо произвести тщательное сопо-ставление по нечетким признакам и категориза-цию больших объемов слабоструктурированных данных. В TransUnion мы тратим много времени на перебор десятков и сотен миллиардов фраг-ментов данных в поисках элементов, прибли-женно соответствующих шаблону. MapReduce эффективнее многих других применявшихся у нас фильтров для некоторых алгоритмов поиска по шаблону. По крайней мере в ее теоретической формулировке эта система отлично поддержива-ет высокую степень параллелизации исполнения задач, чего нельзя сказать о других применяв-шихся нами алгоритмах фильтрации.

Стек с открытым кодом отлично подходит для экспериментов, однако проблема в том, что, по нашим наблюдениям, Hadoop вовсе не Google, это всего лишь попытка группы умных парней повто-рить технологии Google. Они проделали хорошую работу, но, как и большинство программ с откры-тым кодом, их система доработана только на 80%. А недостающие 20% и есть самое сложное.

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

Мы обнаружили ряд проблем с использованием стека данных HDFS/Hadoop/HBase для выполне-ния задач, которые по имеющейся документации должны были решаться. Однако на практике за-ложенные в коде ограничения привели к отказу задолго до того, что мы сочли бы подходящим тео-ретическим пределом. Конечно, доступность ис-ходного кода является положительным аспектом. Однако это в то же время и отрицательный аспект. Для работы с таким программным продуктом ис-ходный код необходим, но это совсем не то, чем мы хотели бы заниматься в своей повседневной деятельности. У меня есть немало хороших инже-

Проблемы работы со сверхбольшими массивами данных 26


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

PwC: За последние пару лет цены на оборудо-вание для хранения данных значительно снизи-лись. Если речь не идет о критически важных данных, то как компания может убедиться, что она не тратит на их хранение больше, чем необ-ходимо?ДП: Пожалуй, мы не слишком типичный пример, поскольку наша работа заключается как раз в анализе данных. Мы готовы заплатить любую цену за возможность получить более точные и быстрые ответы, поскольку мы закладываем эти расходы в стоимость наших услуг. Проблема сегодня в том, что новейшие инструменты не всегда работают как надо. Эта проблема акту-альна как для аппаратного, так и для программ-ного обеспечения. Многие поставщики заканчи-вают тестирование своих приложений на уровне 80 или 85% их теоретической готовности. В рабо-чем режиме мы загружаем их на 110% теоретиче-ских возможностей, и они отказывают. Меня не беспокоят тактические затраты на технологии, которые я рассчитываю быстро заменить. Такие расходы возникают постоянно. Но если уж я пла-чу деньги, я рассчитываю, что эта штука будет работать. И слишком часто оказывается, что она не работает.

PwC: Вы вынуждены использовать только про-веренные технологии из-за опасения выйти за границы надежности?ДП: Дилемма для меня заключается в том, что технологии, которые уже проверены в работе, обычно не могут поддерживать необходимые нам масштабы с точки зрения скорости или объемов обработки данных. Я вынужден вкладывать время, энергию и доллары в технологии, которые еще не проверены, но которые с архитектурной точки зрения могут обеспечить достаточную степень эффективности. Если вариант, который я выберу, не заработает или откажет, я могу от-носительно легко заменить его чем-то другим. Вот почему мы предпочитаем приложения. Пока они хорошо работают на сетевом уровне и имеют стандартный и понятный интерфейс, не так уж

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

PwC: Вы что-то используете вместо Hadoop?ДП: В сущности мы применяем метод перебора. Мы используем Ab Initio, это очень удачная си-стема распараллеливания задач по перебору. Я имею в виду определенные свойства в Ab Initio распараллеливании — извлекая, трансформируя и выполняя — таким путем я могу раздробить задачу.

PwC: Большая часть данных, с которыми вы работаете, относится к транзакциям. Это только структурированные данные или вам также при-ходится разбирать тексты?ДП: По сути, мы имеем дело с тремя типами данных. Есть данные по дебиторской задолжен-ности от организаций, предоставляющих креди-ты. Это данные о личных тратах клиентов. Есть открытые данные государственных организаций, например данные о банкротствах, судебные материалы, данные о залогах, которые представ-ляют собой частично структурированный текст. И, кроме того, есть данные, которые включают любую дополнительную информацию, и кото-рые, как правило, объединены вокруг хорошо известных наборов идентификаторов. При этом себестоимость таких данных практически нуле-вая — мы за них не платим. Эти данные сильно зашумлены. Поэтому мы тратим вычислительные мощности на то, чтобы понять, подходят ли нам эти данные, и найти для них место в рабочих массивах, которые мы ведем.

У меня есть немало хороших инженеров, но я вовсе не хочу, чтобы они тратили все свое время на техническую поддержку продукта, который должен был бы войти в нашу архитектуру в готовом виде


TransUnion ежегодно получает 100 млн обновле-ний кредитных файлов. Мы обновляем большое хранилище данных, содержащее всю финансо-вую и сопутствующую информацию. Кроме того, ежедневно мы генерируем от 1 до 20 временных хранилищ, на использовании которых факти-чески и строится наша работа. Наши продукты объединяют то, что мы называем индикативные данные, — ту информацию, которая идентифици-рует конкретного человека; структурированные данные, которые мы получаем из транзакционных записей, и неструктурированные данные, при-вязанные к дескрипторам. Мы складируем эти информационные продукты в процессе работы, поскольку данные могут меняться каждый день, иногда в день по нескольку раз.

Одна из стоящих перед нами задач заключа-ется в том, чтобы точно определить место для каждого фрагмента данных. Например, у нас есть Джо Смит, проживающий по адресу Мэйн-стрит, дом 13, и есть Джо Смит, проживающий на Мэйн-стрит, дом 31. Это два разных Джона Смита или это просто опечатка? Нам приходит-ся принимать такие решения по 100 миллионов раз на дню с помощью ряда специальных ал-горитмов поиска по шаблону и вероятностных алгоритмов.

PwC: С каким из этих трех типов данных труд-нее всего работать?ДП: Перед нами встают два типа трудностей. Первый тип возникает исключительно из-за масштабов нашей работы. Мы добавляем в файл кредитных данных примерно по половине терабайта за месяц. Все, что мы делаем, сопря-жено с трудностями из-за объемов, частоты об-новления, скорости или производительности баз данных. Для производителей оборудования и программного обеспечения мы и подарок, и про-клятие. Мы сейчас находимся там, куда идет вся отрасль, — к чему придут все компании через два года или пять лет. Мы хороший индикатор направления развития отрасли, но при этом мы постоянно доводим до сбоев их оборудование и программы. А вторая трудность — постоян-но растущая доля неструктурированной части данных.

PwC: Работать с неструктурированными данны-ми труднее потому, что они поступают из мно-жества различных источников и во множестве различных стандартов, не так ли?ДП: Да. У нас 83 тыс. источников данных. Не все они поставляют нам данные каждый день. Данные поступают примерно в 4 тыс. стандар-тов, невзирая на то, что у нас есть собственные стандарты обмена информацией. Чтобы иметь возможность обрабатывать данные достаточно быстро, мы должны перевести их все в единый формат обмена данными, соответствующий тому, который мы используем внутри компании.

Все это сопряжено со сложными вычислитель-ными проблемами.

PwC: Это и есть те проблемы обработки данных, с которыми компании в других отраслях стол-кнутся через три-пять лет?ДП: Я думаю, да.

PwC: Какие еще проблемы, по вашему мнению, получат широкое распространение?ДП: Вот несколько простых практических при-меров. В целом по нашим контролем находится 8,5 петабайт данных. Когда ваши объемы данных значительно превышают 100 терабайт, накопи-тели данных приходится менять каждые четыре-пять лет. Перенос 100 терабайт данных — это огромная физическая задача, занимающая много времени. Ее немного облегчает рост скорости со-единения, но массивы могут перемещаться толь-ко с той скоростью, с какой происходит чтение и запись, и увеличить эту скорость обмена не-возможно. А компании, находящиеся ниже нас по уровню сложности задач, не могут себе предста-вить, что цикл обновления данных может занять месяц. Положим, цикл обновления компьютеров может занимать месяцы, но каждый отдельный его фрагмент занимает всего пару часов. Когда я перемещаю данные из одного массива в другой, я могу остановиться только тогда, когда про-цесс будет полностью закончен. И к тому же мне приходится иметь дело с багами и проблемами стабильности.

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

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

Проблемы работы со сверхбольшими массивами данных 28


PwC: Компания Cloudera [разработчик решений на базе Hadoop] предложила бы перенести вы-числения к данным.ДП: Это годится только для определенных ти-пов данных. Мы уже осуществляем все большие распределенные вычисления на основе системы файлов, а не баз данных. Кроме того, мы преду-сматриваем вычислительные циклы для архива-ции данных, чтобы перемещать меньше бит ин-формации, затем разархивируем данные, считаем и снова архивируем их, чтобы экономить место на хранении данных.

Оперируя четвертым по величине коммерче-ским кластером GPFS [общая параллельная файловая система, файловая система распре-деленных вычислений, разработанная IBM] в мире, мы обнаружили, что, когда вы выходите за пределы определенных размеров, средства управления параллелизацией попросту пере-стают работать. Именно поэтому я утверждаю, что Google работает не на Hadoop. Возможно, команда Google и решила эту проблему, но если это и так, они не собираются рассказывать, как они это сделали.

Мы хотели бы видеть более эффективные с точки зрения вычислений алгоритмы сжатия, поскольку две основные группы моих затрат — это затраты на хранение и перемещение данных


Использование распределенных вычислений в банковской сфереСергей Рябов и Андрей Кувалдин (Сбербанк России) обсуждают особенности применения технологий параллельных вычислений и распределенного хранения данных в банковской сфереИнтервью провели: Виктор Лавренко, Виталий Лазорин

Сергей Рябов является главным ИТ-архитектором Сбер-банка России, возглавляя Отдел архитектуры и пер-спективных разработок. Андрей Кувалдин — руководи-тель проектов в Отделе архитектуры и перспективных разработок, отвечает за направление технической архитектуры.

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

В этом интервью Сергей Рябов и Андрей Кувалдин рассказывают о своем опыте развития двух проек-тов по внедрению централизованного хранилища данных на базе СУБД Teradata и решения Hitachi HCAP для задач хранения и обработки клиентских данных.

PwC: Современные технологии работы с боль-шими данными еще достаточно молоды, поэтому в основном применяются в молодых компаниях. Но потребность в работе с большими данными растет и со стороны организаций, которые тра-диционно принято было считать late follower’ами. PC: В Сбербанке каждый день обрабатываются большие объемы данных. Ежедневно клиенты осу-ществляют около 8 млн транзакций только по пла-стиковым картам, количество которых уже пре-вышает 47 млн. Каждый день выпускается от 50 тыс. до 100 тыс. новых пластиковых карт. Одними из ключевых аспектов при выборе технологий для автоматизации процессов работы с финансовыми данными является надежность и масштабируе-мость. Поэтому основное направление банков-ского бизнеса находится в рамках классической вертикально интегрированной парадигмы. В то же время технологии массово-параллельных систем имеют хорошие перспективы в финансовом секто-ре и в перспективе нескольких лет могут стать базовыми для ряда задач в банках.

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

PwC: Тем не менее Сбербанк не ждет, пока технологии массового параллелизма перестанут быть новыми и станут классикой. Уже сейчас в банке работают над тем, чтобы применить их для хранения и анализа данных, не связанных непосредственно с текущими транзакциями клиентов.

Использование распределенных вычислений в банковской сфере 30


СР: В Сбербанке сейчас идет работа более чем над 140 крупными ИТ-проектами. По сути, это одна из крупнейших ИТ-трансформаций в России, и мы максимальное внимание уделяем перспективным технологиям, что должно обе-спечить банку конкурентные преимущества в долгосрочной перспективе. Среди данных про-ектов есть два, которые связаны с обработ-кой больших данных массово-параллельными системами.

Анализ данныхPwC: В Сбербанке постоянно проводятся иссле-дования клиентской базы. Необходимо иметь информацию обо всех клиентах, корректно их идентифицировать по всей России и сегменти-ровать клиентов для повышения эффективно-сти обслуживания клиентов.АК: Традиционно банки не являются пионера-ми внедрения новых технологий. В этом плане она в хорошем смысле слова консервативная отрасль. Это означает, что все наиболее кри-тичные транзакционные системы построены по классическим принципам. Но вот исторические данные, которые накоплены, обрабатываются,

агрегируются и анализируются, — к ним начина-ют применяться другие подходы.

СР: Основой для принятия управленческих решений является консолидированная, обрабо-танная и непротиворечивая информация. Ядром соответствующего технологического решения является хранилище данных. В банке выбрано решение Teradata, которое достаточно уникально и является одним из лидеров на рынке храни-лищ данных. Главным преимуществом является то, что это решение может позволить обеспе-чить практически линейную масштабируемость (добавление программно-аппаратных ресурсов позволяет соответствующим образом увеличить объем обрабатываемых данных в единицу време-ни). Сейчас данное решение развернуто. За-вершаются первые проекты, запускаются новые этапы программы и тиражирование технологии по всей структуре банка.

СР: Teradata позволяет распределенно не только хранить данные, но и обрабатывать. С определен-ной периодичностью данные из основных бан-ковских систем c использованием ETL-средств

СУБД Teradata разработана специально для обработки больших объемов данных в ар-хитектуре shared nothing, т.е. «разделяемых ресурсов нет». Основная цель такой архитекту-ры — убрать «бутылочные горлышки» и создать хорошо масштабируемую систему, которая мо-жет расти без практических ограничений и без падения производительности.

Экземпляр БД состоит из нескольких «вир-туальных процессов». Teradata поддерживает процессы двух типов: PE (parse engine) — про-цесс, отвечающий за взаимодействие с пользо-вателем и разбор SQL-запросов, и AMP (access module process) — процесс, занимающийся собственно обработкой данных.

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

ного коммутатора BYNET, поддерживающего до 1024 узлов. При добавлении новых узлов вирту-альные процессы мигрируют между узлами, что обеспечивает практически линейный рост про-изводительности. Физический узел представ-ляет собой сервер с двумя четырехъядерными процессорами Intel Xeon и 48 Гбайт памяти.

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

Узел 1 Узел 3 Узел 5Узел 2

Дисковый массив Дисковый массив

Уровень передачи сообщений

Узел 4 Узел 6

Рис. 1. Принципиальная схема работы СУБД Teradata

РЕ

AMP

РЕ

AMP

РЕ

AMP

РЕ

AMP

РЕ

AMP

РЕ

AMP

РЕ

AMP

РЕ

AMP

РЕ

AMP

РЕ

AMP

РЕ

AMP

РЕ

AMP


(Extract, Transform, Load) загружаются в храни-лище данных. И там на каждом узле рассчиты-ваются необходимые агрегаты. На основе агре-гированных данных строится управленческая отчетность.

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

Хранение архивных данныхPwC: Для хранения первичных клиентских данных в Сбербанке реализуется проект на базе системы Hitachi HCAP, которая яв-ляется кластерным решением корпоратив-ного класса для систем архивного хранения информации.СР: Перед банком стоит задача минимизации бумажного документооборота. В рамках соот-ветствующих бизнес-процессов в отделени-ях осуществляется сканирование первичных клиентских документов (документы, удостове-ряющие личность, заявления на обслуживание, договора и т.д.). Соответственно, есть инфор-мационная система, куда эта неструктуриро-ванная информация попадает, а затем обраба-тывается.

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

АК: У решения Hitachi есть некоторое количество узлов, кластеров, которые представляют из себя небольшие промышленные сервера, с подсоеди-ненными к ним дисковыми подсистемами. Для нас существенно, чтобы у тех решений, которые мы выбираем, ориентируясь на долгосрочную пер-спективу, по возможности не было ограничений по масштабируемости. Именно по этому признаку было выбрано решение Hitachi HCAP. Сейчас реа-лизуется первая фаза проекта в Москве и Санкт-Петербурге. В следующем году запланировано тиражирование по всей территории страны.

Прогнозы

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

СР, АК: Ключевыми областями, где уже использу-ются и будут использоваться технологии массивно-параллельной обработки данных, являются ана-

Продакшн и архивное хранилище

Неструктурированный контент

Кросс-платформенный поиск и извлечение информации с использованием индекса

Комплекс Hitachi Data Discovery Suite

индексирование

Поиск

Идентиф

икация

Сбор

Сохранение

Среда для файлов и контента

Дополнитель-ная емкость и производи-тельность

HDDS серверы Cетевое хранилище Hitachi High Perfomance

NAS

Платформа Hitachi Content Archive Platform

Рис. 2. Общий принцип работы системы Hitachi HCAPHCAP состоит из узлов хранения, узлов поиска (x86-серверы с ПО HDS) и дисковых массивов (midrange-класса HDS AMS), обеспечивает масштабирование за счет наращивания числа узлов хранения, узлов поиска, количества и характеристик (емкость/производитель-ность) дисковых массивов, имеются функции удален-ной репликации данных.

Рис. 3. Архитектура решения Hitachi HCAP обеспечивает неограниченную масштабируемость

Использование распределенных вычислений в банковской сфере 32


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

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

Главная проблема на пути использования массивно-параллельных систем в банковской сфере — отсутствие на рынке проверенных ком-мерческих решений. Классическому вертикально масштабируемому подходу много лет. Его пределы ясны. Он развивался эволюционно. Параллельные системы развивались взрывным образом на протя-жении последних лет. Они развивались в пределах тех компаний, которых не могли удовлетворить классические вертикально масштабируемые систе-мы. Классические примеры: Ebay, Google, Amazon.

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


PwC: Компания Disney занимается широким спектром направлений бизнеса и имеет огром-ный потенциал для синергии и взаимного пере-крестного «опыления» между отдельными подразделениями. Как вы смотрите это с точки зрения обработки данных?БА: Мы пытаемся выработать и освоить наилучшие (с точки зрения долгосрочной перспективы) спосо-бы работы с клиентом предоставления услуг. Ряд наших подразделений обрабатывает значительные объемы данных, объемы обработки данных в дру-гих подразделениях меньше — в зависимости от клиентской аудитории. Одна из стоящих перед нами задач — найти способ рационально и эффективно обслуживать оба типа подразделений. Расширяются коммерческие связи студии с дистрибьюторами и с сетями кинотеатров. Если вы продаете свою про-дукцию миллионам, вам необходимо понимать раз-личные клиентские аудитории и связи между ними.

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

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

Оптимизация затрат по обработке больших данныхБад Алберс, Скотт Томпсон и Мэтт Эстес (Disney) делятся опытом эффективного применения технологий с открытым кодом и облачных вычисленийИнтервью провели: Гален Груман, Алан Моррисон

Бад Алберс поступил на работу в подразделение, сегодня носящее на-звание Технологической группы стандартных сервисов компании Disney, два года назад в качестве исполнительного вице-президента и директора по технологиям. Скотт Томпсон, вице-президент по архитектуре, и Мэтт Эстес, ведущий специалист по архитектуре данных, входят в его управ-ленческую команду. Группа была создана в конце 1990-х годов, когда ком-пания Disney приобрела компании Starwave и Infoseek. Сейчас базируется в Сиэтле. Группа обеспечивает поддержку всех коммерческих подразделений Disney (общий годовой доход компании 38 млрд долларов) и управляет портфе-лем ее интернет-проектов. В него входят сайты студий, магазинов и тема-тических парков Disney, сети телевизионного вещания ESPN и ABC, а также ряд местных телевизионных станций в крупных городах. В своем интервью Алберс, Томпсон и Эстес рассказывают о том, как можно существенно расши-рить возможности анализа интернет-данных без дополнительных затрат посредством встраи-вания кластера Hadoop. Алберс и его команда высвободили средства на этот кластер за счет виртуализации серверов и сокращения непроизводственных затрат.

Оптимизация затрат по обработке больших данных 34


Надеюсь, мы сумеем добиться и в других об-ластях того, чего добились на рынке сетей рас-пространения контента за счет стандартизации, сохранения центральной позиции, а не исполь-зования решений Akamai,а также за счет созда-ния динамичного рынка. Получив новую серию «Остаться в живых», мы можем начать выгружать ее в интернет, при этом я могу организовать по-ток 80% через Akamai и 20% по каналам Level 3. При этом мы можем все изменить и пустить 80% Limelight и 20% через Level 3. Мы можем работать настолько динамично.

PwC: В чем заключаются другие сильные сторо-ны технологической группы стандартных серви-сов компании Disney?БА: Когда я начал работать здесь пару лет назад, у нас была линейка хороших централи-зованных базовых сервисов. У нас был создан прообраз облака в его истинном значении. На-пример, общие централизованные сервисы на базе регистрации. Если вы зарегистрированы на сайтах Disney, ABC или ESPN, эта регистра-ция будет работать на всех интернет-ресурсах компании Disney. Имея регистрацию на ESPN, можно войти на сайт KGO в Сан-Франциско, и ваша регистрация будет работать. Это общая система регистрации. Созданные нами марке-тинговые системы обслуживают все подраз-деления — сбор аналитической информации и аналогичные сервисы. Функции, общие для всех подразделений, обслуживаются общими серви-сами для всех сайтов.Те сервисы, которые специфичны для каждого бренда, разрабатываются соответствующими подразделениями, которые контролируют поль-зовательский интерфейс. В каждом из подраз-делений есть главный разработчик интернет-сайта, который подчиняется мне. Наш директор по информационным технологиям занимается всеми вопросами до фаервола; я же занимаюсь вопросами от фаервола до гостиной или мобиль-

ного устройства клиента. Вот так поделен наш мир, если я понятно объясняю.

PwC: Как вы сочетаете потребности в данных централизованных сервисов и специфических сервисов бизнес-подразделений?БА: Это скорее искусство, чем наука. Бизнес-подразделения генерируют доходы, а мы обеспе-чиваем их базовыми сервисами. Как выбрать пра-вильный баланс? Сегодня можно договариваться передаче ответственности за гораздо большее количество сервисов. Мы собираем всю анали-тику, добавляем к ней новые опции и постоянно думаем, все ли у нас есть. Мы приходим к концеп-ции, при которой один элемент данных обрабаты-вается за один цикл, затем эти элементы агреги-руются и размещаются в стеке. Такая процедура может оказаться неэффективной, поскольку все данные надо подвергнуть полному циклу обработ-ки, но они могут не иметь какой-либо длительной ценности.

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

PwC: Hadoop, кажется, дает возможность про-водить эффективный анализ данных, имеющих только краткосрочное значение. Как вы пришли к тому, чтобы попробовать технологии типа кла-стера Hadoop?БА: Специалистов вроде меня никогда не позо-вут туда, где все в порядке. Безусловно, подраз-деление компании Disney, куда я пришел, имело множество преимуществ, но, когда я подключился

«Это скорее искусство, чем наука. Коммерческие подразделения генерируют доходы, а мы обеспечиваем для них базовые сервисы. Как выбрать правильный баланс? Право собственности на некоторые вещи вызывает сегодня массу нареканий». — Бад Алберс


к работе, затраты постоянно росли. Рост сово-купного объема обработки данных составлял 17% в год. В то же время рост мощности серверов составлял 30%. Мы наращивали вычислительные мощности информационных центров, но при этом заполняли их процессорами, которые полностью не использовались. Я задался вопросом: как можно обращаться к финансовому директору за бюджетом на оборудование для информационно-го центра, которое вы собираетесь использовать только на 5%?

Коэффициент загруженности процессора показа-тель не единственный, но самый очевидный. Что-бы изучить ситуацию и разобраться, что происхо-дит, мы оборудовали наши серверы контрольными устройствами, показывающими пиковую загрузку процессоров по всему пулу серверов с пятиминут-ными интервалами. Мы обнаружили, что примерно 80% серверов никогда не использовались более чем на 10% в месяц.

Первым шагом к решению этой проблемы стала виртуализация. На сегодня около 49% нашего информационного центра расположено на вирту-альных серверах. Проект виртуализации оказал заметное влияние на размер затрат. Прекратив наращивать мощности информационных центров и выполнять ненужные перемещения содержи-мого памяти, мы высвободили значительные средства. Мы никого не увольняли. Мы просто изменили некоторые процессы, в результате чего добились сокращения кривой роста затрат с плюс 27% до минус 3% по стандартным централизован-ным сервисам.

Мы дали этому проекту название D-Cloud. Следу-ющим элементом программы модернизации стал переход на стандартные протоколы обмена на Java-скриптах для разработки некоторых общих прикладных программных интерфейсов в рамках нашей сети. Одной из первых решенных нами за-дач стало внедрение централизованной службы регистрации всех событий. Журналы регистра-ции событий затем загружаются в один большой массив данных. И затем уже мы можем работать с этими данными при помощи технологий Hadoop и MapReduce.

PwC: Как централизованная служба регистра-ции событий вписывается в вашу общую стра-тегию?СТ: Изучая этот вопрос, мы поняли, что дело не только в виртуализации. Чтобы иметь возмож-ность переносить вычисления на внешние ресур-сы и для других целей, необходимо подготовить целый набор базовых сервисов. Сейчас мы рабо-таем над созданием ряда таких базовых серви-сов для управления конфигурацией. Мы приняли за основу виртуализацию и внедренные про-токолы обмена информацией, добавляем такие базовые сервисы, которые позволят реагировать

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

PwC: Как вам удалось организовать работу таким образом, чтобы стратегия вашего разви-тия была в определенном смысле управляема данными?МЭ: С одной стороны, у вас есть мир, жестко ориентированный на транзакции, мир онлайновой обработки транзакций в системах управления ре-ляционными базами данных и программ, предлага-емых нашими основными поставщиками. С другой стороны, у вас есть традиционные методы анализа и хранения данных. Hadoop мы поместили между ними вместе с другими операционными данными. Часть их вы получаете из данных по транзакци-ям, часть формируете из аналитических данных. Комбинация двух видов данных дает нам опреде-ленную степень свободы.

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

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

PwC: Такая информация не вписывается в формат кубов. Это не значит, что кубы данных выйдут из употребления, но сегодня они рас-пространены достаточно широко. Ценность, которую вы можете создать, заключается, как вы сказали, в понимании концепции этапов ис-следования информации. СТ: Мы полагаем, что технологией будущего яв-ляется хранение неструктурированных данных в необработанном формате. В среде Hadoop, вместо того чтобы поместить данные в хранилище, вы решаете, на какой вопрос вы хотите получить ответ. Затем вы обрабатываете вводную информа-цию с помощью MapReduce, и эту информацию вы можете направить в кубы, в такое место, где с ней можно работать, но вы оставляете данные в необ-работанном формате и выбираете из них только то, что вам нужно.

Оптимизация затрат по обработке больших данных 36


БА: Главное достоинство нашего нынешнего пути развития состоит в том, что анализ данных рань-ше требовал гигантских вложений средств, кото-рые нужно было аккумулировать в самом начале работы, верно? Теперь это не так. Теперь я ска-чиваю инструментарий Hadoop через Интернет, убедившись, что мы удовлетворяем юридическим требованиям на предмет лицензирования и тому подобных вопросов. Когда это сделано, можно начинать прототипирование. Вы начинаете рабо-тать со стандартным оборудованием, которое вы в противном случае просто выкинули бы. Сколько бы я потратил на Teradata в противном случае? Мы применяем базовые принципы облачной техно-логии и методы стандартизации интерфейса для

виртуализации и сокращения затрат. Я получаю экономию затрат и возвращаю часть их в бизнес, а часть реинвестирую в развитие, и все это при стабилизации кривой затрат.

МЭ: Реинвестирование части сэкономленных средств в развитие не обязательно оказывается в традиционной категории «миллионных проек-тов», о которых привыкли думать компании. Мож-но добиться значительного усовершенствования, инвестировав 200 тыс. долларов или даже всего 50 тыс. долларов.

БА: Все дело в том, как вы перераспределяете уже совершенные вашей компанией инвестиции в ресурсы, как вы расставляете приоритеты своей работы и в том, чтобы не оказывать отри-цательного влияния на итоговую прибыльность, делая инвестиции, которые могут не окупиться. Я могу попробовать реализовать такой проект, и мне не нужно для этого высших согласований, поскольку речь не идет о глобальных вещах. Это не страшно, мы можем начать работу, мы мо-жем задействовать конкретное подразделение, мы можем запустить в эксплуатацию пилотную версию, мы можем применить ее там, где, как мы знаем, в этом существует потребность, мы мо-жем проверить ее для удовлетворения этой по-требности и убедиться, что она работает. И для этого мне не надо проходить процедуру запроса на представление предложений и стандартные процедуры закупок. Я могу действовать очень быстро.

«Мы полагаем, что технологией будущего является хранение неструктурированных данных в необработанном формате. В среде Hadoop, вместо того чтобы поместить данные в хранилище, вы решаете, на какой вопрос вы хотите получить ответ». — Скотт Томпсон


PwC: Какого рода информация о вашей кли-ентской аудитории необходима вам в текущей работе и откуда вы ее сегодня получаете?ГК: Как говорила одна актриса, «когда я готовлю роль, я хочу знать о своем персонаже абсолютно все: как он ест, спит, смотрится в зеркало». Это, конечно, максимализм. Но в идеале маркетолог действительно хочет знать о своем объекте влия-ния абсолютно все.

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

Далее — мне жизненно важно знать, на что стоит пытаться воздействовать. Какие у клиента суще-ствуют актуальные и стратегические проблемы, на нашем сленге — pain points.

Получить эту информацию маркетер может из нескольких потоков. Первый — прямое общение

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

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

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

Большие данные — волшебная палочка маркетологаТатьяна Чернова («КАРО Фильм») и Гамид Костоев (IBS Group) обсуждают перспективы развития маркетинговых инструментов анализа сверхбольших массивов неструктурированных данных.Интервью провели: Виталий Лазорин, Андрей Шелудяков

Гамид Костоев является директором по корпоративным коммуникациям IBS Group и имеет за плеча-ми большой опыт управления маркетинговой функцией в ИТ-секторе в таких компаниях, как Avaya, SAP AG и Microsoft. Татьяна Чернова организовала и возглавляет рекламное агентство «Кино Медиа» и также является директором по рекламе и маркетингу сети кинотеатров «КАРО Фильм». В этом интервью Гамид Костоев и Татьяна Чернова предлагают свой взгляд на развитие новых подходов к ис-пользованию сверхбольших массивов неструктурированных данных в B2B- и B2C-маркетинге, обсуж-дают перспективы создания CRM нового поколения.

Большие данные — волшебная палочка маркетолога 38


Начинаешь строить кинотеатр — ты должен до-сконально знать аудиторию района. Будут сюда приходить только в кино, или захотят совмещать просмотр фильма с покупками и походами в кафе и рестораны. Нужны ли тут кожаные кресла, или на этом нужно сэкономить, чтобы цена билета не превышала 200 руб. Нужно досконально знать кон-курентов, работающих в этом же районе, сколько здесь школ, институтов и т.д.

Но также необходимо следить за фильмом еще на этапе его производства и тестирования. Почему нам голливудский продукт проще продвигать в России, чем отечественное кино? Потому что он изначально маркетингово просчитан. Потому что это коммерческий продукт. Развлечение — это бизнес. И надо предлагать продукт, рассчитанный на определенную аудиторию. Иначе зачем он, этот продукт. Голливуд весь построен на точном расче-те. Они мониторят идею, мониторят сценарий ку-сками, показывают фокус-группам предмонтажи, перестраивают сюжет, приспосабливают его. На этапе создания фильма продукт проходит огром-ное количество исследований. Кстати, сегодня и в России уже есть исследовательские компании, которые работают вместе с создателем фильма с самого начала.

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

Мы используем информацию из билетной системы, баров, с сайта. Это немало. Это основа бизнеса в настоящий момент. Мы имеем ответы на большое количество вопросов о предпочтениях аудитории, о ее портрете. На рынке также существует много исследований — экзит-полы, «тайные покупатели». Но это фиксация фактов. Билет — это статистика. Он не идентифицирует зрителя как персону. Нужна обратная связь и возможность взаимодействия в более короткое время, даже, может быть, в тече-ние срока проката фильма. Сегодня нам некому задать вопрос в режиме онлайн. Мы сейчас все работаем «на опыте». Делается все максимально возможное исходя из информации бокс-офиса. Мы смотрим, как «помочь» фильму, как лучше до-нести информацию — это все рекламные задачи, чтобы заинтересовать аудиторию прийти на кон-кретный фильм или в конкретный кинотеатр.

PwC: Какие бы вы определили направления развития существующих CRM-систем с учетом появления новых инструментов анализа боль-ших данных, о которых рассказывается в этом номере «Технологического прогноза»?ГК: Для боевого маркетера правильная CRM — прежде всего система, а не комбинация трудного софтверного продукта, корпоративной сетки и несчастной девочки в отделе продаж, делающей это из-под палки и задним числом. Это, во-первых, система, которая комплексна. То есть, она состоит из учета всех потоков информации, людей, регла-ментов их работы и только потом софта и железа. (Кстати, парадокс еще и в том, что софт здесь, на мой взгляд, не должен быть излишне наво-роченным — а то люди не будут с ним работать). Во-вторых, это система, которая используется каж-дый день. В-третьих, что самое главное, она каж-дый день используется менеджерами по продажам.

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

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


по техподдержке и результатов анализа огромного массива «серых» данных из медиапространства (что говорил клиент в интервью год назад о про-блемах своего предприятия).

Все это позволит мне всегда правильно оценить сте-пень готовности клиента к новому предложению.

У такой CRM появляется еще одно важное преи-мущество: информация становится отчуждаемой. Ведь классный продавец — он, как красивая женщина, всегда может встать и уйти, потому что в дефиците и всегда востребован на рынке.

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

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

ТЧ: В будущем мы хотим создать собственную базу, нашу собственную CRM, чтобы понимать ядро аудитории и иметь ее постоянный портрет. Мы хотим использовать собственную маркетинговую систему, а не обращаться каждый раз к исследо-вательским агентствам, чтобы иметь постоянные исследования на собственной территории. Систе-ма должна заложить способность фильтровать и таргетировать аудиторию, следить за малейшими изменениями ее портрета. Самое главное — нуж-на возможность общения. Сейчас оно опосре-дованно всевозможным рекламным носителем. Администратор, кассир в кинотеатре общаются со зрителем непосредственно. А маркетолог — нет, хотя ему необходимо понимать, за какие ниточки дергать. И вот сегодня, имея достаточный опыт и понимая основное, уже очень хочется разбираться в нюансах. Ведь чем бизнес старше, тем большее значение приобретают нюансы. Хотя бы в том же самом портрете аудитории. Например, зная, ка-кая часть нашей аудитории в данном кинотеатре «совы», а какая «жаворонки», можно было бы бо-лее грамотно строить сетку показов.

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

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

Но главное — нужно иметь быструю обратную связь с потребителем, вплоть до вопроса, понра-вился фильм или нет.

PwC: Если бы в вашем распоряжении оказались все данные, которые вы могли бы только пред-ставить, какие вы видите в связи с этим новые перспективы?ГК: В этом случае ситуация и проще, и сложнее од-новременно. С одной стороны, информацию не надо искать. С другой — необходимо из этого «сырья» сделать «пригодный к готовке полуфабрикат». А для этого сначала надо все структурировать. Например, связать финансовые данные о продажах с продук-товыми. К этому надо привязать контакт репорты менеджеров по продажам (о чем клиент плакался и обязательно то, на что он ругался). Я бы это все структурировал, связал одно с другим и поднял бы наверх в удобоваримой для анализа форме. И глав-ное, сделать это механизмом не только для себя. Надо, чтобы любой менеджер по продажам мог зайти в мой маркетинговый CRM, набрать название клиента и увидеть, что продали, сколько, историю контактов и заявленные проблемы.

Что для этого нужно? Доступ — раз. Удобная си-стема (удобство использования и преобразования данных) — два. И умение связать все со всем (что, почем и по какой причине/задаче/проблеме было продано) — три.

Сегодня в распоряжении многих предприятий уже есть 90% данных, которые могут реализовать мечту маркетолога знать о клиенте все. Мощные системы обработки и анализа этих огромных массивов данных могли бы принести большую пользу. Возьмем сотовых операторов. Вы живете в Москве, вы деловой человек, сотовый телефон у вас включен почти все время бодрствования. Он каждую минуту связан с какой-то вышкой, каждая вышка где-то стоит. Сопоставляя данные, например социальных сетей, ваши высказывания в открытом пространстве с маршрутом пере-мещения вашего телефона по городу, я бы очень много о вас узнал. Во сколько вы встаете, где вы обедаете, работаете, живете, какую-то эвристику, с кем вы дружите и даже есть ли у вас подруга. Это открывает широчайшие возможности — на-пример, для геотаргетинга, о котором сегодня так много говорят. Как только я получаю информацию о вашем образе жизни, я довольно четко могу

Большие данные — волшебная палочка маркетолога 40


определиться с информационными каналами для связи с вами. Представим, что вы все время в онлайне, у вас включен location service, и вы, такой прогрессивный, сообщили о себе некие данные о ваших предпочтениях. Когда вы будете идти по конкретной улице, вам будет приходить SMS: за углом булочная, куда только что привезли ваши любимые булочки.

Сегодня ситуация часто выглядит так: мы стоим в центре круга диаметром в сто километров. И точно знаем, что под нами, в этом кругу — золото. Во-прос — где копать и как доставать, по какому закону.

Теоретически здесь большое будущее. Но про-блема вот в чем: или у маркетеров руки не доходят до таких данных, или данные часто на-ходятся в распоряжении у тех, кому они для мар-кетинга не очень нужны. Поскольку на его рынке реально превалирует масс-маркетинг. Я, кстати, пока ни разу не замечал, чтобы мой сотовый оператор маркетировал меня как индивидуаль-ного потребителя.

ТЧ: Когда система информационного оповещения потребителя уже создана, результатом всех по-гружений в аудиторию должно быть возникнове-ние новых подходов, более осознанных в деталях, и выбор индивидуального канала донесения ин-формации. Главная перспектива — это не только более четкое обобщение, но и налаживание ин-дивидуального контакта с каждым нашим клиен-том. Закрепление аудитории без индивидуальной работы становится все более сложным. Эта тен-денция сейчас начинает приобретать все большее значение на B2С- и B2В-рынках.

PwC: Давайте посмотрим на перспективу бли-жайших трех-пяти лет. Как, на ваш взгляд, изме-нятся информационные потребности маркетоло-гов и их отношения с большими данными?ГК: Если говорить о маркетинге в сегменте FMCG, то здесь ничего принципиально нового, на мой взгляд, не произойдет. Инструментарий и харак-тер работы останутся теми же. Слишком большая целевая аудитория. Но к маркетинговым иссле-дованиям, к работе с фокус-группами добавится отчаянная попытка маркетологов отобрать не-формальные данные, в том числе из блогосферы и социальных сетей.

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

Меняется понятие целевой аудитории. Вторичная ранее аудитория мгновенно становится первичной за счет Интернета: один человек классно пошутил у себя в блоге, его друзья мгновенно тиражируют это у себя в блогах, в Facebook, Twitter и т.д.

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

В киберпространстве появляются новые opinion leaders (лидеры мнений). Данные об их реаль-ном влиянии на аудиторию будут жадно собирать маркетеры. Но это уже будут данные не о клиенте, а о канале информации.

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

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

ТЧ: В ближайшее время будет расти внимание маркетологов к деталям. Сеансные сетки будут разглядываться под микроскопом. Будет прово-диться более скрупулезный анализ данных, чтобы понять, показывать или не показывать определен-ное кино в определенном кинотеатре. Мы наде-емся перейти на новый уровень работы, чтобы, например, ответить на вопрос, почему какой-то фильм нигде не пошел, а здесь пошел. Но когда я говорю о детализации, в том числе я преследую цель не делать лишних движений и не тратить лишних денег. Это оптимизирует твое управление и твое воздействие. После того как ты знаешь бизнес очень хорошо, у тебя возникают неочевид-ные вопросы. И аудитория скоро нам сообщит то, о чем мы даже и не догадываемся.

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


Поиск эффективных инструментов работы с большими данными

Применение компаниями кластерных технологий с открытым кодом для анализа данныхАвтор: Алан Моррисон

Поиск эффективных инструментов работы с большими данными 42


Всего два года назад в программе Международной суперкомпьютерной конференции (ISC) не под-нималась тема распределенных вычислений для больших данных, как будто такие проекты, как Google Cluster Architecture, эффективно и за счет малых затрат обеспечивающие обработку больших объемов слабоструктурированных данных, вообще не существовали. В своем блоге за май 2008 года Бро Тернер отметил этот пробел, указав, что Google достиг уровня вычислительной мощности в 100 петафлопов1 по сравнению с весьма скромным 1 пе-тафлопом нового суперкомпьютера IBM Roadrunner, представленного в журнале EE Times за тот же месяц. «Неужели ребят с суперкомпьютерами кто-то обошел, а они этого даже не заметили?» — удив-лялся Тернер2.

Тернер, сооснователь и директор по технологиям портала Ashtonbrooke.com, многие годы читает материалы исследований Google и комментирует их в своем блоге. Хотя эта новость не привлекла внимания широкой деловой общественности, ряд компаний последовал по стопам Google. Многие из них работают в сфере Интернет и сталкиваются с теми же проблемами расширения обработки дан-ных, что и Google.

Так, компания Yahoo! отказалась от собственной архи-тектуры данных и начала внедрять другую на основе принципов, предложенных Google. Компания перешла на Apache Hadoop, которая представляет собой рас-пределенную файловую систему с открытым кодом на основе Java, созданную организацией Apache Software Foundation на базе файловой системы Google File System. Кроме того, Yahoo! внедряет и MapReduce — представленный Google программный фреймворк для параллельных вычислений. Yahoo! применяет эти и другие разработанные уже ею самой инстру-менты с открытым кодом для кролинга и индексации интернет-страниц. После внедрения такой архитекту-ры компания нашла дополнительные области при-менения этим технологиям и на сегодня увеличила размеры своего Hadoop-кластера до 4 тыс. узлов.

К началу 2010 года Hadoop, MapReduce и ассоцииро-ванные с ними технологии с открытым кодом стали движущей силой целого нового явления, которое O'Reilly Media, The Economist и другие издания

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

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

Hadoop-кластерыХотя кластерные вычисления существуют не один десяток лет, кластеры на основе стандартных компьютеров возникли не так давно. Первыми в середине 1990-х появились Beowulf-кластеры, работавшие на UNIX и Linux. Эти массивы, со-

К началу 2010 года Hadoop, MapReduce и ассоциированные с ними технологии с открытым кодом стали движущей силой целого нового явления, которое O’Reilly Media, The Economist и другие издания окрестили большими данными, а поставщики ПО именуют «облачными хранилищами»

1 FLOPS является аббревиатурой выражения «floating point operations per second» («число операций с плавающей запятой в секунду»). Процес-соры для вычислений с плавающей запятой используют большее число бит для хранения каждого значения, что обеспечивает более высокую точность вычислений и простоту программирования, чем процессоры данных с фиксированной запятой. Один петафлоп соответствует быстро-действию более чем в один квадриллион операций с плавающей запятой в секунду.

2 Brough Turner. Google Surpasses Supercomputer Community, Unnoticed, May 20, 2008, http://blogs.broughturner.com/communications/2008/05/google-surpasses-supercomputer-community-unnoticed.html (ссылка проверена 8 апреля 2010 г.)


стоящие из недорогих серверов, объединенных в единую сеть, были альтернативой дорогостоящим суперкомьпьютерам Cray и других производите-лей, которые поставлялись в правительственные агентства, такие как Национальное управление по аэронавтике и исследованию космического про-странства (НАСА). Неслучайно, что именно НАСА стало пионером в развитии Beowulf-кластеров3.

Система Hadoop дает возможность на основе обычных компьютеров создать первоклассный вычислительный кластер с минимальными затрата-ми. Основное допущение, лежащее в основе такой архитектуры, состоит в том, что при распределении вычислительной задачи между сотнями и тысячами узлов некоторые из них обязательно дадут сбой. Поэтому одним из непременных условий обеспе-чения работоспособности всей системы является возможность предвидеть отказ отдельных узлов и восстанавливаться, когда такой отказ имеет место4. К другим характеристикам кластерной архитектуры Google (Google Cluster Architecture) и ее реализации с применением технологий Hadoop относятся:

• Соотношение цена/производительность при пиковой нагрузке. Главной задачей является оптимизация агрегированной производитель-ности. Например, производительности функции сортировки, определяющей рейтинг интернет-страницы по частоте употребления ключевых слов. Общая производительность сортировки высока. В последние три года кластеры Hadoop компании Yahoo! ежегодно выигрывали сравни-тельные тесты по сортировке данных Gray5.

• Устойчивость программного обеспечения к аппаратным отказам. В случае отказа обо-рудования система переносит обработку за-дачи на другой узел. Эта способность имеет жизненно важное значение для любых больших распределенных систем. Как отмечает Роджер Магулас, директор по исследованиям O'Reilly, «если у вас четыре десятка или сотня машин, вы можете полагаться на надежность систе-мы, но если вы управляете системой в тысячу узлов, что-нибудь будет ломаться постоянно».

• Высокая удельная вычислительная мощность на запрос. Если размер системы может быть увеличен до тысяч узлов, это означает, что для

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

• Модульность и расширяемость. Hadoop-кластеры могут горизонтально масштабиро-ваться благодаря унифицированной модульной архитектуре.

Система Hadoop не рассчитана на универсальное применение. Например, она особенно неэффек-тивна при решении задач, требующих большое количество операций записи. Она показывает себя наилучшим образом при обработке задач с боль-шим количеством операций по чтению. Кластеры скорее дополняют, чем заменяют собой технологии высокопроизводительных вычислений и другие си-стемы обработки реляционных данных. Они также не очень подходят для работы с транзакционными данными или записями, требующими постоянного обновления. «Hadoop обрабатывает один массив данных и выдает другой, не меняя исходный мас-сив», — отмечает Амр Авадалла, вице-президент по инжинирингу и технический директор компании Cloudera, разрабатывающей одну из версий Hadoop.

Высокое соотношение цена/производительность Hadoop-кластеров обеспечивается за счет соот-ветствующей архитектуры данных и программного обеспечения, позволяющей экономно использовать ресурсы Сети и дисковое пространство. «Процесс обработки данных переносится к их местонахожде-нию», — отмечает Авадалла. Каждый узел имеет собственные ресурсы обработки и хранения, дан-ные делятся на блоки подходящего размера и обра-батываются локально. Эта концепция локализации предполагает использование недорогих жестких дисков SATA (применяются в большинстве компью-теров и серверов) и Gigabit Ethernet для большин-ства сетевых подключений (см. Рис. 1 на стр. 44).

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

«Hadoop меняет пространство представления данных, не меняя их физического местоположения». — Амр Авадалла, Cloudera

3 См. например, Tim Kientzle. Beowulf: Linux clustering. Dr. Dobb's Journal, November 1, 1998, Factiva Document dobb000020010916dub100045 (ссылка проверена 9 апреля 2010 г.)

4 Luis Barroso, Jeffrey Dean, and Urs Hoelzle, «Web Search for a Planet: The Google Cluster Architecture,» Google Research Publications, http://research.google.com/archive/googlecluster.html (ссылка проверена 10 апреля 2010 г.)

5 См. http://sortbenchmark.org/ and http://developer.yahoo.net/blog/ (ссылка проверена 9 апреля 2010 г.)6 Tom White, Hadoop: The Definitive Guide (Sebastopol, CA: O'Reilly Media, 2009), 4.



Цена этих возможностей вполне доступна, и создание Hadoop-кластера может быть профи-нансировано из имеющегося бюджета ИТ. Когда Технологическая группа стандартных сервисов компании Disney приняла решение начать рабо-тать с Hadoop, средства для этого были найдены за счет повышения коэффициента использова-ния серверов благодаря виртуализации. По со-стоянию на март 2010 года при виртуализации почти 50% серверов рост серверной мощности компании Disney составил 30% в год, при этом физический рост серверной мощности сокра-тился на 30%. За счет этого компания смогла создать многотерабайтный Hadoop-кластер на серверах, которые ранее планировала списать. По оценкам группы, на весь проект было по-трачено менее 500 тыс. долларов (см. статью «Информационный потенциал больших данных» на стр. 15).

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

ний, например Amazon или Cloudera, на платфор-мы Amazon Elastic Compute Cloud (EC2).

Платформа EC2 была ключевым технологическим элементом в известном проекте по применению об-лачных вычислений применительно к большим дан-ным, реализованном в 2007 году изданием The New York Times. На этом проекте также применялись технологии Hadoop и другие системы с открытым кодом. Задача состояла в том, чтобы оперативно создать PDF-файлы 11 млн статей из 4 терабайт сканированных изображений. Сервис EC2 компа-нии Amazon справился с задачей за 24 часа после соответствующей настройки и запуска, что явля-лось явным достижением и получило широкое осве-щение в блогах и профессиональных изданиях.

Но при этом был абсолютно обойден вниманием факт использования на этом проекте распределен-ной файловой системы Hadoop (HDFS) и программ-ной среды MapReduce. Изучив посты с экспертны-ми рекомендациями в различных блогах, главный специалист по архитектуре ПО Times Дерек Готт-фрид разработал и применил код параллельного вычисления на множестве машин Amazon7.

Рис. 1. Конфигурация и характеристики кластера Hadoop

Источник: IBM, 2008, and Cloudera, 2010

Стойка

Диспетчер задач / Узел данных

Диспетчер работ

Именной узел

Стойка

Коммутатор Коммутатор

Коммутатор

Клиент

1000Mbps

100Mbps 100Mbps

Стандартный состав узла

2 четырехъядерных процессора Intel Nehalem

RAM 24 ГБ

12 дисков SATA (non-RAID) по 1 ТБ

1 карта Gigabit Ethernet

Стоимость узла — 5 тыс. долларов США

Эффективное файловое пространство узла — 20 ТБ

Преимущества

Линейное расширение по цене 250 долларов на пользовательский ТБ данных (против 5—100 тыс. долларов для альтернативных решений).

Вычисления производятся по месту нахождения данных, сокращается число записей, что снижает затраты на сетевой трафик и хранение данных.

Модульность и расширяемость.










7 См. Derek Gottfrid, «Self-service, Prorated Super Computing Fun!» The New York Times Open Blog, November 1, 2007, http://open.blogs.nytimes.com/2007/11/01/self-service-prorated-super-computing-fun/ (ссылка проверена 4 июня 2010 г.) и Bill Snyder, «Cloud Computing: Not Just Pie in the Sky», CIO, March 5, 2008, Factiva Document CIO0000020080402e4350000 (ссылка проверена 28 марта 2010 г.)


«Amazon поддерживает Hadoop непосредствен-но через прикладные программные интерфейсы Elastic MapReduce», — отмечает Крис Венсел, основатель компании Concurrent, разработавшей Cascading (про Cascading см. далее в настоящей статье). «Я постоянно выполняю заказы клиентов: собрать кластер из 200 узлов и обработать 3 тера-байта данных за пять-шесть часов, а затем ликви-дировать всю систему. Это исключительно мощная система», — рассказывает он.

Распределенная файловая система Hadoop Распределенная файловая система Hadoop (HDFS) и среда параллельного программиро-вания MapReduce составляют основу системы Apache Hadoop. Сравнивая HDFS и MapReduce с Linux, Авадалла отмечает, что это настоящие «операционные системы данных». Возможно, эта характеристика несколько преувеличена, однако Hadoop имеет черты сходства с любой операци-онной системой. Операционные системы плани-руют выполнение задач, распределяют ресурсы

и управляют потоком файлов и данных для вы-полнения поставленных задач. HDFS делает то же самое в условиях распределенных вычисле-ний. «Система обеспечивает связь всех узлов в единое целое, как большой общий файл, а также поддерживает планирование выполнения задач для работающих под ней приложений», — отме-чает Авадалла.

HDFS, как и все инструменты Hadoop, работает под Java. HDFS включает два типа узлов:• единый NameNode (узел работы с метаданны-

ми), который регистрирует и поддерживает в па-мяти необходимые метаданные для выполнения распределенных задач;

• множественные DataNodes (узлы данных), кото-рые создают, управляют и обрабатывают блоки размером 64 МБ, содержащие фрагменты задач, в соответствии с инструкциями из NameNode.

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

Не меньшее значение имеет отказоустойчивость при тех же пределах загрузки диска и каналов пе-редачи данных. Чтобы обеспечить устойчивость к отказам, система HDFS создает три копии каждого блока данных, при этом обычно две копии хранят-ся в пределах одной стойки. Система переходит на другую стойку, только если ей нужно создать тре-тью копию. На рис. 2 приведена упрощенная схема HDFS и метода копирования блоков данных.

HDFS не может выполнять такие операции, как замена конкретного числа из списка или другие изменения в рамках фрагментов баз данных. Исходя из этого некоторые считают, что HDFS не пригодна для работы со структурированными

Рис. 2. Распределенная файловая система Hadoop (HDFS)

Источник: Apache Software Foundation, IBM, and PwC, 2008

1

1

Исходные данные

Приложения ввода Центральная система обработки данных Hadoop

Приложения вывода

M1

3

3MM

3

2

2

MR

R

2

Информация с низким уровнем структуризации,такая как:

файлы системных протоколов

сообщения

изображения

CascadingThriftZookeeperPig

Системы анализа неоднородного контента

Приложения RDBMS

Системы бизнес-аналитикиЗадачи

Резуль-таты

Разметка

Свертка

Блоки по 64 МБ

Файлы БлокиФайл A 1, 2, 4Файл A 3, 5

Узел данных

1 2 4


5 2 3


4 3 1


5 2 5

Узел указателей (метаданные)

Клиент

Рис. 3. Обзор экосистемы Hadoop

Источник: PwC, derived from Apache Software Foundation and Dion Hinchcliffe, 2010



данными. «Система HDFS никогда не предна-значалась для работы со структурированными данными, поэтому она не является оптимальной для обработки запросов по ним», — утверждает Дэниел Абади, доцент факультета информати-ки Йельского университета. Абади и другие его коллеги из Йельского университета проводили тестирование производительности таких задач и создали версию HDFS для работы с реляцион-ными базами данных под названием HadoopDB, в которой устранены выявленные проблемы8.

Некоторые разработчики структурируют данные таким образом, чтобы сделать их пригодными для HDFS. Это просто другое структурирование, чем в случае реляционных данных. Натан Марц, ведущий инженер компании BackType, разраба-тывающей поисковые встроенные системы для социальных сетей, использует схемы, позволяю-щие обеспечить согласованность и целостность данных. «Многие думают, что система Hadoop предназначена только для неструктурирован-ных данных, таких как файлы системных про-токолов, — говорит Марц. — Hadoop не только отлично работает с лог-файлами, но и блестяще справляется с четко систематизированными структурированными данными». Для этой цели Марц применяет инструментарий Thrift, разра-ботанный Facebook для конвертации и деления данных9 (характеристику Thrift см. ниже в настоя-щей статье). На рис. 3 изображен типичный при-мер обработки данных с использованием Hadoop, Thrift и MapReduce.

MapReduceПрограммный фреймворк MapReduce является базовой средой программирования для Hadoop. Он часто также выступает в качестве моста между HDFS и более привычными для большинства про-граммистов средствами. По словам разработчиков MapReduce из Google, «MapReduce прячет детали распараллеливания» и прочую механику HDFS10.

Фреймворк MapReduce является средством абстрагирования от управления огромным мно-жеством деталей посредством создания допол-нительного уровня обработки, на котором проис-ходит выявление и обобщение сущностей. Это не означает, что MapReduce прост в использовании. Многие разработчики предпочитают работать с другими инструментами, которые предоставляют собой еще один уровень абстрагирования над MapReduce. «Я всеми силами стараюсь избегать непосредственной работы с MapReduce, — го-ворит Марц. — Фактически я всегда работаю с MapReduce с помощью библиотеки Cascading».

Термины «Map» (разметить) и «Reduce» (свер-нуть) относятся к шагам, которые MapReduce предпринимает, чтобы подготовить или разме-тить исходные данные для параллельной об-работки, а затем свернуть или обобщить об-работанные данные в выходном файле (Рис. 4). MapReduce работает с парами ключ-значение. Для интернет-данных ключ — это адрес URL, а значение — это контент интернет-страницы, в частности, Hypertext Markup Language (HTML).

Рис. 4. Этапы работы MapReduce

Источник: Google, 2004, and Cloudera, 2009

Разметка

Свертка Свертка Свертка

Хранилище данных 1

Исходные пары ключ-значение

Разметка

Хранилище данных n

Исходные пары ключ-значение

Барьер ... Агрегация текущих значений выходным ключом ... Барьер

конечный ключ 1 значения

ключ 2 значенияключ 1 значения ключ 3 значения

конечный ключ 2 значения конечный ключ 3 3начения

ключ 2 значенияключ 1 значения ключ 3 значения

ключ 3 Промежуточные значенияключ 2 Промежуточные значенияключ 1 Промежуточные значения

8 См. «HadoopDB» at http://db.cs.yale.edu/hadoopdb/hadoopdb.html (ссылка проверена 11 апреля 2010 г.)9 Nathan Marz, «Thrift + Graphs = Strong, flexible schemas on Hadoop,» http://nathanmarz.com/blog/schemas-on-hadoop/ (ссылка проверена 11 апреля 2010 г.)

10 Jeffrey Dean and Sanjay Ghemawat, «MapReduce: Simplified Data Processing on Large Clusters,» Google Research Publications, декабрь 2004 г., http://labs.google.com/papers/mapreduce.html (ссылка проверена 22 апреля 2010 г.)


Главная ценность MapReduce заключается в том, что это платформа с набором интерфейсов про-граммирования. До появления MapReduce мало кто из программистов мог использовать возмож-ности распределенных вычислений. После того как были разработаны пользовательские инстру-менты, программирование для систем с активным использованием распараллеливания стало проще и больше не требует существенной адаптации про-грамм. Мы рассмотрим ряд таких инструментов в следующем разделе.

CascadingСоздатель библиотеки Cascading Крис Венсел называет ее альтернативным API для MapReduce. Это единая библиотека операций, которые может использовать разработчик. Библиотека обеспечи-вает дополнительный уровень абстрагирования, позволяющий программистам переносить методы, которые они обычно применяют в нераспреде-ленных средах, на распределенные вычисления.

С помощью Cascading, по словам Венсела, «вы мо-жете написать программу на том языке на базе виртуальной машины Java, который вам нравится, а потом просто поместить ее в кластер».

Создавая Cascading, Венсел стремился избавить разработчика от необходимости «думать в катего-риях MapReduce». При ее применении разработчику не обязательно опираться на пары ключ-значение, можно думать в категориях полей и списков, так называемых кортежей. Кортеж Cascading проще, чем запись в базе данных, но работает аналогично. Каждый кортеж проходит через каскад сборок, похожих на классы Java. Поток данных начинается от «источника» — файла ввода и заканчивается в «стоке» — директории вывода (Рис. 5).

Вместо того чтобы производить операции раз-метки и свертки больших файлов, разработчик группирует потоки операций с помощью функций, фильтров, агрегаторов и буферов. Эти потоки со-ставляют каскады, которые, по выражению Мар-ца, «компилируются в MapReduce». В определен-ном смысле Cascading сглаживает шероховатости MapReduce, позволяя работать с ним большему числу разработчиков, включая и тех, кто в основ-ном работает на скриптовых языках (Рис. 6).

Некоторые полезные инструменты аналитического программирования в стиле MapReduceКоличество открытых инструментов для работы с Hadoop-кластерами через MapReduce все уве-личивается. По всей видимости, пользователей и разработчиков не сдерживает тот факт, что в янва-ре 2010 года компания Google получила патент на MapReduce. Вообще-то Google, IBM и другие компа-нии поощряют разработку и применение открытых версий своих инструментов в различных исследова-тельских учреждениях11. В этом разделе мы приве-дем ряд наиболее известных инструментов, использу-емых для аналитических задач, а также упомянутых разработчиками, с которыми мы беседовали.

ClojureСоздатель Clojure Рич Хики хотел объединить в своей системе элементы C или C#, LISP (язык обработки списков, применяемый для систем ис-кусственного интеллекта и включающий множе-ство математических функций) и Java. Название составлено из букв C, L и J и произносится как английское слово «closure». Clojure сочетает в себе библиотеку LISP и библиотеки Java. Возможности Clojure по обработке формальных и естественных языков [ЕЯ], а также то, что в его основе лежит библиотека JVM, позволяют применять его для выполнения статистического анализа на Hadoop-кластерах. В сервисе прогнозирования задержки

Рис. 6. Группа и поток данных в Cascading

Источник: Concurrent, 2010

Рис. 5. Группа Cascading

Источник: Concurrent, 2010

A

A

A

A A

A A

A A

Конвейер групп

Операции Hadoop (переведенные в MapReduce)

Задачи MapReduce

Assembly

Клиент

Кластер

Flow

ЗадачаЗадача

MR MR

MR MR

MR

P P P P P P

So Si

[f1, f2, ...]

[f1, f2, ...] [f1, f2, ...]

[f1, f2, ...]

[f1, f2, ...] Кортежи с именами полейSo ИсточникSi СтокP Конвейер

[f1, f2, ...] [f1, f2, ...] [f1, f2, ...]

Разметка Свертка Разметка Свертка

11 См. Dean, et al., US Patent No. 7,650,331, 19 января 2010 г., на сайте http:// www.uspto.gov. Пример участия Google и IBM в разработке Hadoop см. в «Google and IBM Announce University Initiative to Address Internet-Scale Computing Challenges», пресс-релиз Google, 8 октября 2007 г., http://www.google.com/intl/en/ press/pressrel/20071008_ibm_univ.html (ссылка проверена 28 марта 2010 г.)



рейсов на коммерческих авиалиниях FlightCaster используется Clojure, стоящий над Cascading, который, в свою очередь, стоит над MapReduce и Hadoop для того, чтобы «обеспечить правиль-ное представление неструктурированных данных из различных источников», поясняет Бредфорд Кросс, один из основателей FlightCaster.

Ряд атрибутов языка LISP хорошо подходит для работы с ЕЯ, что делает Clojure незаменимым для различных приложений в этой области. Марк Уотсон, консультант и автор работ по вопросам искусственного интеллекта, говорит, что большая часть написанных им программ на LISP предна-значена для работы с ЕЯ. По его мнению, произво-дительность программирования на LISP в четыре раза выше, чем на C++, и вдвое выше, чем на Java. Его код для работы с ЕЯ «использует огромное ко-личество резидентных данных», таких как списки имен собственных, категорий текста, распростра-ненных фамилий и национальностей.

LISP, как говорит Уотсон, позволяет загрузить дан-ные один раз и тестировать их многократно. Про-граммируя на C++, он был бы вынужден использо-вать реляционную базу данных и перезагружать ее при каждом тестировании. Применение LISP дает возможность создавать и тестировать небольшие фрагменты кода итеративно, что является одним из основных источников роста производительности.

Такое реализованное в Clojure итеративное взаимо-действие между программистом и программой по образцу LISP позволяет, по выражению Хики, осу-ществлять «динамическое развитие». Любой код, введенный через консольный интерфейс, отмечает он, компилируется в потоке автоматически.

ThriftПриложение Thrift, впервые созданное на Facebook в 2007 году и затем выпущенное с открытым ко-дом, помогает разработчикам создавать сервисы, обеспечивающие коммуникативные связи между различными языками программирования, включая C++, C#, Java, Perl, Python, PHP, Erlang и Ruby. По информации Facebook, c помощью Thrift пользова-тель может «определить все необходимые струк-туры и интерфейсы данных для комплексного сервиса в одном коротком файле».

Более важным аспектом Thrift, по мнению Марца (BackType), является его способность формиро-вать данные со строгой типизацией и гибкими взаимосвязями. Оппонируя представителям так называемого NoSQL-сообщества, придающим большое значение неструктурированным данным, Марц утверждает, что при анализе с использова-нием Hadoop-технологий существуют эффектив-ные способы некоторого упорядочивания данных.

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

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

Марц применяет Thrift для моделирования соци-альных графов, таких как на рис. 7, демонстрируя гибкость схемы для вычислений с использованеи-ем Hadoop. В сущности Thrift обеспечивает модуль-ность приведенных в схеме социальных графов. Например, чтобы выбрать значение возраста для каждого отдельного человека, BackType может рассмотреть все значения показателя возраста, производя вычисления на базе всего массива дан-ных или вычисления только для объектов, в отно-шении которых получены новые данные.

BackType не только работает с исходными дан-ными. Он выполняет задачи, которые постоянно нормализуют и анализируют поступающие новые данные, а также и другие задачи, которые запи-сывают обработанные данные в масштабируемую базу данных с произвольным доступом, например HBase или Cassandra12.

Рис. 7. Пример социального графа, смоделированного при помощи схемы Thrift

Источник: Nathan Marz, 2010

Алиса

Боб

ЧарлиПол женский

Возраст 25

Пол мужской

Возраст 39

Пол мужской

Возраст 22

Язык: C++

ПриложениеApacheThrift

12 См. описания других инструментов, использующих MapReduce и/или HDFS, не упомянутых в настоящей статье, на сайте компании Apache по адресу http://apache.org/


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

• Хранилища многомерных таблиц. Каждая запись содержит имя ряда, имя столбца и вре-менную метку значения. Многомерные таблицы берут свое начало от базы данных Bigtable ком-пании Google.

• Key-value хранилища. Каждая запись состоит из ключа, или уникального идентификатора, со-ответствующего одному или более значениям.

• Хранилища графов. Каждая запись состоит из элементов, которые в совокупности образуют граф. Графы отображают отношения. Например, социальный граф отражает связи между людь-ми. Другие графы описывают отношения между объектами, связями или тем и другим.

• Хранилища документов. Каждая запись состо-ит из элементов, которые в совокупности обра-зуют граф. Графы отображают отношения. На-пример, социальный граф отражает связи между людьми. Другие графы описывают отношения между объектами, связями или тем и другим.

Благодаря своей простоте хранилища многомер-ных таблиц и key-value хранилища могут иметь ряд преимуществ в плане масштабируемости перед большинством типов реляционных баз данных. (HadoopDB, гибридная система, разработанная специалистами Йельского университета, призвана преодолеть проблемы масштабируемости, харак-терные для реляционных баз данных.) В Таблице 1 приведен ряд примеров существующих нереляци-онных хранилищ данных с открытым кодом.

Другие актуальные технологии и поставщикиПолный обзор разнообразных инструментов, предназначенных для работы с Hadoop, выходит за рамки данной статьи. Мы приведем здесь толь-

ко некоторые из них, поскольку они упоминаются в других материалах настоящего выпуска:• Pig — скриптовый язык под названием Pig Latin,

главный элемент платформы Apache Pig, дает возможность, по мнению его разработчика Тома Уайта, формировать более четкие по сравнению с MapReduce запросы к массивам данных «не-посредственно с консоли».

• Hive — Hive, по мнению Криса Венсела, пред-ставляет собой «главным образом систему из-влечения, преобразования и загрузки данных» для использования в Facebook.

• Zookeeper — Zookeeper, по информации Apache, обеспечивает интерфейс для создания распре-деленных приложений.

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

ВыводыИнтерес к Hadoop-кластерам стремительно рас-тет, и сфера их внедрения расширяется. К причи-нам популярности Hadoop можно отнести следую-щие факторы.• Открытая и динамичная разработка. Среда

Hadoop / MapReduce обеспечивает экономи-чески эффективные решения по организации распределенных вычислений для сообщества программистов, работающих с открытым ко-дом и воспитанных на Linux и Java, а также на скриптовых языках, таких как Perl и Python. Некоторые из них пользуются возможностями функциональных диалектов языков програм-мирования, например Clojure. Открытость и взаимодействие между разработчиками могут значительно ускорить сам цикл разработки.

• Экономически эффективное масштабирова-ние. Горизонтальное масштабирование на базе архитектур с низкой себестоимостью означает в долгосрочной перспективе рациональную структуру затрат для большего спектра типов данных. Скотт Томпсон, вице-президент по инфраструктуре Группы общих сервисов Disney, говорит: «Мы убедились, что Hadoop поддает-ся горизонтальному масштабированию. В этом и состоит его привлекательность. Например,

Таблицы Key-value Документы Графы

HBase Tokyo Cabinet/Tyrant MongoDB Resource Description Framework (RDF)

Hypertable Project Voldemort CouchDB Neo4j

Cassandra Redis Xindice InfoGrid

Таблица 1. Примеры нереляционных хранилищ данных с открытым кодом

Источник: PwC, Daniel Abadi of Yale University, and organization Web sites, 2010



Выборочные поставщики инструментария больших данных

Amazon Amazon предлагает среду вычислений в для Hadoop в рамках своего сервиса облачных вычислений Elastic Compute Cloud (EC2) и службы хранения данных S3 Elastic MapReduce.

Appistry Платформа CloudIQ Storage компании Appistry предлагает альтернативу HDFS, целью которой является устра-нение единственного уязвимого звена системы — NameNode.

Cloudera Cloudera следует в отношении Hadoop подходам Red Hat, предлагая собственный дистрибутив на базе EC2/S3, а также средства управления, услуги по подготовке персонала, технической поддержке и консультированию.

Cloudscale В первом продукте компании Cloudscale, Cloudcel, интерфейс на базе Excel сочетается с системой, параллель-ной потоковой обработки данных. Продукт предназначен для обработки имеющихся и поступающих в реаль-ном времени данных.

Concurrent Компания Concurrent является разработчиком библиотеки Cascading и предлагает услуги по ее лицензирова-нию, обучению и технической поддержке.

Drawn to Scale Drawn to Scale предлагает аналитические и транзакционные базы данных на основе Hadoop и HBase, а также периодически оказывает консультационные услуги.

IBMВ мае 2010 года IBM предложила версию Hadoop под названием BigInsights. Команда jStart компании IBM предлагает проведение брифингов и семинаров по пилотным релизам Hadoop. IBM BigSheets осуществляет обобщение, анализ и визуализацию для больших объемов интернет-данных.

Microsoft Microsoft Pivot использует технологию Deep Zoom собственной разработки для реализации функций визуального просмотра данных для файлов XML. Сервис Azure Table в некотором смысле сравним с Bigtable или Hbase (см. интервью с Марком Тейлором и Рэем Велесом на стр. 65).

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

я всегда работал с СУРБД, так? Я работал в этой сфере многие годы, и могу сказать, что, как ни старайся, с СУРБД добиться такой устой-чивой масштабируемости просто невозможно».

• Отказоустойчивость. В масштабируемых систе-мах отказ отдельных узлов является базовой рабо-чей предпосылкой. Системы Hadoop и MapReduce устойчивы к таким отказам, и это еще одна при-чина, позволяющая использовать их в системах, составленных из стандартного оборудования.

• Приспособленность для работы с данными с низким уровнем структуризации. Пожалуй, наиболее важной характеристикой методов, внедренных Google и расширенных Yahoo! и другими компаниями, является их поддерж-ка, по выражению Амра Авадаллы (Cloudera), «комплексных» данных. Хотя разработчики, например Марц, осознают ценность структури-рования данных, большинство разработчиков под Hadoop/MapReduce не мыслят в категориях

СУРБД. Они настроены на обработку есте-ственных языков и ориентируются на методи-ки, оптимизированные для больших объемов информации с низким уровнем структуризации, например, огромных объемов информации, раз-мещенной в сети Интернет.

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


Hadoop принимается в эксплуатациюАмр Авадалла (Cloudera) рассказывает, как и почему различные компании стремятся освоить новые технологии на основе HadoopИнтервью провели: Алан Моррисон, Бо Паркер, Винод Байя

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

PwC: До Cloudera вы работали в Yahoo!?АА: Да. Я продал Yahoo! свою компанию VivaSmart и после этого работал в Yahoo! с середины 2000 года до середины 2008-го, работал сначала в ко-манде Yahoo Shopping. Начиная с 2003-го моя дея-тельность была сосредоточена на сборе, обработ-ке и анализе информации в ориентированных на пользователя сервисах Yahoo News, Mail, Finance, Messenger и Search.

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

Именно к этому времени относится мой первый опыт использования Hadoop. Лежащая в ее основе модель «сначала исследовать, а потом управлять» отлично укладывается в схему управления инфра-структуры хранилища данных. Стандарты управ-ления очень важны с точки зрения обеспечения общей управляемости в рамках всей организации. В то же время они ограничивают гибкость, поэто-му оптимальное решение — дополнить управляе-мое хранилище данных более гибкой системой обработки сложных данных типа Hadoop.

PwC: Почему Yahoo! стала использовать Hadoop?АА: В 2005 году Yahoo! столкнулась с бизнес-задачей. Себестоимость создания поискового индекса сети Интернет приближалась к размеру доходов от контекстной рекламы на страницах поиска. Поэтому подразделение Yahoo Search при-няло Hadoop в качестве экономичного масштабиру-емого решения и начало работу над ним в сотруд-ничестве с сообществом открытого кода Apache Hadoop. Компания Yahoo! сыграла значительную роль в эволюции системы Hadoop до ее нынешнего

уровня развития. Вскоре после того как команда Yahoo Search начала применять Hadoop, мощность и гибкость этой системы оценили и другие под-разделения компании. Сегодня Yahoo! применяет Hadoop для хранения данных, идентификации спа-ма, обработки лент новостей и целевого подбора контента и рекламных объявлений.

PwC: В чем заключаются преимущества Hadoop по сравнению с системами управления реляци-онными базами данных (СУРБД)?АА: В Oracle, Teradata и других СУРБД вы сначала создаете схему таблиц данных. Вы говорите: вот, что я буду загружать в базу данных, вот такие типы столбцов, и только потом загружаете сами данные. Этот процесс может ограничить скорость развития вашей модели и схем данных, а также ограничить ваши возможности по регистрации и отслеживанию событий.

В Hadoop все происходит наоборот. Вы загружае-те все свои данные. Это могут быть файлы XML (Extensible Markup Language), неструктурирован-ные файлы разделенные табуляторами, протоколы Apache, файлы JSON (JavaScript Object Notation) или другие форматы. Затем с помощью Hive или Pig (инструменты для выполнения запросов данных в системе Hadoop) вы задаете набор метаданных, соотносите его с файлом и разбираете данные непосредственно в процессе чтения. Этот метод позволяет извлекать столбцы, которые указвают на интересующие вас структуры данных.

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

Hadoop принимается в эксплуатацию 52


онные системы не слишком хорошо подходят для быстро эволюционирующих сложных типов данных.

Еще одно преимущество Hadoop — схемы с положи-тельной обратной связью. Например, инженер запу-скает новую функцию продукта и предусматривает ее протоколирование. Новые данные начинают по-ступать непосредственно в систему Hadoop. Спустя несколько недель или месяцев информационный аналитик может обновить схему парсинга этих но-вых данных. После этого он сразу же получит воз-можность составлять запросы по этим данным за прошлые периоды с самого начала их поступления [в то время как в СУРБД ему пришлось бы сначала ждать, пока схема обновится и процессы ETL (разо-брать, преобразовать и загрузить) перезагрузят все прошлые значения данного показателя].

PwC: А что вы скажете об стоимостных преиму-ществах?АА: Базовая стоимость такого решения в 10-100 раз ниже стоимости других решений. Но дело не только в цене. Реляционные базы данных отлично подходят для тех задач, для которых они предна-значены, а именно для выполнения интерактивных запросов SQL на хорошо структурированных дан-ных. Мы тут не говорим о полной замене техноло-гий хранения данных, это надо четко понимать.

Никто из наших клиентов не рассматривает Hadoop в таком качестве. Клиенты понимают, что меняется сам характер данных. Объем каких типов данных растет сегодня? Растут прежде всего комплексные типы данных. Является ли реляционный массив наилучшим объектом для запросов и по комплекс-ным, и по реляционным данным? Едва ли, хотя ор-ганизациям по-прежнему необходимо использовать, собирать и представлять реляционные данные для ответов на стандартные вопросы, требующие в ряде случаев реагирования в реальном времени.

PwC: Какие преимущества получают компании благодаря возможности выполнения запросов сразу к структурированным и комплексным ви-дам данных?

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

PwC: Компании, с которыми вы работаете, по-нимают, что вы предлагаете им принципиально другую парадигму?АА: И да и нет. Наши технологии в первую очередь предназначены для компаний, где требуется об-работка запросов по комплексным и структуриро-ванным данным одновременно. Ряд финансовых учреждений, с которыми мы контактируем, имеют десять, двадцать, даже сотни систем Oracle — это просто поразительно! У них есть все это множе-ство файловых серверов, на которых хранятся файлы XML или файлы протоколов, и они хотят консолидировать все эти таблицы и файлы на одной платформе, которая могла бы работать с обоими типами данных, давая возможность об-рабатывать комплексные запросы. Именно здесь Hadoop проявляет себя с наилучшей стороны — эта система позволяет компаниям запускать зада-чи по работе сразу с двумя типами данных.

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


PWC: На каком объеме данных компании стоит задумываться о том, чтобы переходить от стан-дартных решений хранения данных, таких как RAID-массивы, SAN-хранилища и прочее, к спе-циализированным решениям?PK: Есть два основных критерия необходимости перехода на специализированные решения. Это либо объем оперируемых данных, либо рост коли-чества или сложности операций с ними.

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

Сложнее с нагрузкой. Здесь нельзя дать точную рекомендацию. Я бы советовал отслеживать падение производительности с ростом нагрузки и принимать решение о начале проектирования и внедрения в соответствии с ним.

ВГ: По моему мнению, RAID-массивы и SAN-хранилища не являются заменителем специали-зированных систем обработки данных, напротив, они являются как бы фундаментом (низким уров-

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

АО: Основной критерий перехода — стоимость. Это не только стоимость оборудования, но и стоимость работы системных администраторов и стоимость простоя каких-либо систем. Получает-ся эффективней — переходим. По нашему опыту RAID-системы, конечно, обязательны, но недоста-точны (это защищает только от поломки дисков). SAN-хранилища мы, конечно, тестировали и не-много использовали, но, во-первых, они не совсем такие волшебные, как обещают их производители, во-вторых, имеют принципиальные недостатки. В огромном количестве случаев удобней не пере-мещать петабайты данных по Сети, а доставлять программы, обрабатывающие данные, к самим данным, т.к. программы значительно меньше, и производить вычисления по месту хранения. SAN-хранилища это, конечно же, не позволяют, а вот у Map/Reduce это сильная сторона.

Большие данные в интернетеВладимир Габрелян (технический директор Mail.ru), Анатолий Орлов (руководитель разработки поиска, «Яндекс») и Роман Козлов (руководитель инфраструктурного отдела, «Нигма.РФ/itim.vn») рассказывают о способах хранения, обработки и извлечения больших данных в Интернете.Интервью провел Виктор Лавренко

Российские интернет-проекты доросли до работы с гигантскими объемами данных, которые смело можно называть не просто большими, а сверхбольши-ми. Сегодня ведущие разработчики наших интернет-компаний могут рассказать о реальном положении дел с большими данными исходя из своего практического опыта, а не из информации, почерпнутой из маркетинговых буклетов. Данный материал наверняка будет интересен ИТ-директорам всех крупных компаний

Большие данные в интернете 54


PWC: Парадигма вычислений Map/Reduce — для кого она? Каков критический объем серве-ров, при котором имеет смысл использовать эту технологию?ВГ: Парадигма Map/Reduce необходима в тех местах, где объем обрабатываемой информации или количество запросов таковы, что стандартные средства хранения и обработки данных не по-зволяют обработать эти объемы за приемлемое время.

Говоря о том, с какого объема стоит разрабатывать собственные (или использовать готовые) решения, могу сказать, что при принятии решения следует полагаться на банальный экономический расчет. Иными словами, я бы рекомендовал внедрение программных решений на основе Map/Reduce в том случае, если их стоимость ниже, чем стоимость аппаратного решения, которое позволит обрабо-тать тот же объем данных за приемлемое время. А кластеризация данных методом шардинга или параллельных хранилищ невозможна по причинам необходимости агрегированных результатов.

АО: Не существует четких критериев «после такого-то количества серверов переходите на Map/Reduce», все зависит от характера данных. Напри-мер, для поискового кластера, на котором дан-ные в краткосрочном промежутке read-only, Map/Reduce вообще не нужен, полная реплика сервера работает отлично. Для почтового кластера, где до-ступ read-write, но есть очень жесткое разделение данных (данные пользователя лежат на одной ма-шине), тоже не нужен, все вычисления с данными легко делаются на той же машине, где находятся сами данные.

Обычно системы типа Map/Reduce применяются в тех местах, где нужно обрабатывать данные read-write, у которых нет жесткого разделения по серверам. Очень грубо Map/Reduce можно воспри-нимать как специального вида RAID5 над серве-рами. RAID из дисков позволяет вам в течение разумного времени игнорировать потерю дисков, Map/Reduce позволяет игнорировать потерю сер-веров целиком.

Для крупных компаний это безумно важная функ-циональность. Попробую объяснить почему. У вас наверняка есть дома компьютер, и он, например, был сломан два дня в течение года. Если бы у вас было 10 000 компьютеров, это бы значило, что в среднем 50 из них будут сломаны постоянно. Для компаний с большими дата-центрами это очень серьезная проблема, для того чтобы быстро раз-бираться с проблемами на каждом конкретном сервере, требуется большое количество квалифи-цированных высокооплачиваемых людей с воз-можностью задействовать их круглосуточно, тогда как позиция «сервер сдох, ну и фиг с ним, админ через неделю посмотрит, как руки дойдут» позво-ляет жить гораздо комфортней.

PWC: Стоит ли каскадировать решения, пы-таясь установить системы обработки больших данных поверх более мелких, таких как RAID-массивы и прочее?ВГ: По моему мнению, в 99% случаев каскадирова-ние — это единственный экономически оправдан-ный вариант решения, т.к. RAID-массивы и прочие решения являются довольно низкоуровневыми. Они позволяют решить огромное количество обобщенных задач, оставаясь при этом абсолютно неспецифичными к какому-либо типу данных.

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

АО: Зависит от того, готовы ли вы потерять для кластера всю машинку, на которой сломался диск. Диски обычно летят более часто, чем машины, и стоят дешево, поэтому уменьшение числа отказов путем несильного увеличения затрат на дополни-тельные диски почти всегда имеет смысл.

PWC: Тестировали ли вы и используете ли такие технологии, как Hadoop, GlusterFS, GPFS и др.?ВГ: Мы тестировали Hadoop и применяем его в наших production-разработках. Из положительных сторон могу отметить высокую гибкость данного решения и применимость в широком круге задач. Основным минусом я бы назвал невысокую произ-водительность.

АО: Мы тестировали все эти технологии и даже некоторое время использовали в production, но в конечном итоге ничего из этого не прижилось и было заменено (или будет заменено в ближай-шее время) на технологии, разработанные внутри компании.

PWC: Когда имеет смысл разрабатывать свои технологии работы с большими данными?ВГ: Я бы выделил несколько вопросов, утверди-тельно ответив на которые, можно разрабаты-вать собственную технологию работы с большими объемами данных.• Технологии работы с данными являются основным

направлением деятельности вашей компании.• Ваша компания обладает уже сформированным

опытным отделом разработки.


• Отдел разработки вашей компании уже доказал способность реализовывать крупные и сложные проекты.

• На рынке не существует готовых решений, срав-нимых по стоимости и обеспечивающих должную производительность\работу с должным объемом данных.

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

АО: Когда у вас есть разработчики, которые могут это сделать, и/или есть необходимость затачивать решения под себя.

Часто покупные технологии хранения «из короб-ки» — это те же самые PC со специально зато-ченным софтом, при этом продающиеся намного дороже, чем сервера с подобной конфигурацией.

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

А если у вас отстроенная разработка и огромное количество классных программистов, как правило, потратить 5 человеко-лет на разработку систе-мы и сэкономить несколько миллионов долларов на железе более чем осмысленно.

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

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

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

АО: Да, есть. Как правило, приемы работы с Map/Reduce сильно отличаются от приемов обычного написания кода, и почти в любом случае придется потратить время на перепроектирование системы.

PWC: От каких ошибок вы могли бы предосте-речь тех, кто хочет попробовать применить распределенные технологии работы с большими данными?ВГ: Очевидная ошибка — это решение о раз-работке собственной технологии работы с боль-шим объемом данных. На рынке представлено огромное количество как аппаратных, так и программных средств, которые позволяют не менее эффективно, но с большей экономией сил и времени решать ваши бизнес-задачи. К наибо-лее распространенным ошибкам я могу отнести следующие:• недооценка сроков и сложности разработки;• недооценка затрат на перенос данных;• недооценка затрат на поддержание одновремен-

ной работы со старой и новой системой хране-ния данных;

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

• случаи, когда временной цикл разработки про-граммного решения по хранению данных превы-шает цикл появления новых бизнес-требований к хранилищу.

АО: Очевидная ошибка считать технологии типа Map/Reduce универсальным ответом на все про-блемы, не имеющим никаких недостатков — это ведет к использованию таких технологий в тех случаях, когда это не нужно и даже вредно. Как правило, эти технологии имеют высокие накладные расходы на обработку информации (т.е. требуют больше железа, иногда на десятки процентов), но существенно удешевляют раз-работку и эксплуатацию. Поэтому некоторые (обычно очень крупные) системы, где стои-мость железа достигает десятков миллионов долларов, бывает эффективней реализовать на специально разработанной технологии хра-нения. Если вы не можете в деньгах показать эффективность решения, возможно, вам стоит подумать еще.

Большие данные в интернете 56


PWC: Как оценивать успешность внедрения?ВГ: Для этого необходимо ответить на три следую-щих вопроса. Достигнут ли поставленный резуль-тат? Оправдалась ли экономическая эффектив-ность принятого решения? Подходит ли созданный программный продукт для использования в после-дующих проектах?

РК: Тремя словами по решенной задаче. Это могут быть как улучшение скорости обработки, появле-ние возможности увеличения объема данных, так и более сложные параметры. Например, возмож-ность увеличения сложности обработки без по-тери производительности, возможность обойтись меньшим количеством серверов и т.п.

АО: Критерии — система должна быть работо-способна и должна быть дешевле альтернатив по суммарной стоимости (железо, эксплуатация, раз-работка, стоимость простоев системы).

PWC: Какие тенденции, на ваш взгляд, будут до-минировать в области работы с большими дан-ными через три-пять лет?ВГ: Я вижу следующие тенденции в этой области: • технологии MapReduce становятся все более по-

пулярными, переходя из раздела экзотики в раз-дел понятных и общеупотребимых архитектур;

• появляется все большее количество open source решений, которые при грамотном использовании позволяют драматически снизить стоимость раз-работки систем хранения данных;

• системы хранения развиваются от блоков и файлов к объектным системам хранения;

• системы хранения данных становятся все ме-нее специфичными, исключаются специальные

протоколы передачи данных в пользу хоть и не таких быстрых, но значительно более рас-пространенных (поддерживаемых аппаратными средствами);

• уменьшение как стоимости, так и влияния аппа-ратной части комплекса, в пользу программной.

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

АО: Скорее всего, «облака» (имеются в виду реше-ния, где вам все равно, на каком сервере выполня-ется код, Map/Reduce в том числе) перестанут быть экзотикой и технологиями больших компаний и ста-нут повсеместно применяемыми и готовыми реше-ниями на хостингах. Это предполагает, что появятся некоторые «стандартные», готовые к использова-нию, чисто софтверные и бесплатные решения.

Твердотельные накопители (SSD) вытеснят обыч-ные жесткие диски как базовые системы хранения, что может оказать влияние на архитектуру многих систем хранения и обработки данных. Почти все они рассчитаны на batch-обработку данных, т.к. это серьезно увеличивает скорость работы с диском — эта особенность может стать не нужна.


Новые задачи для ИТ-директора по организации работы с данными

Переключитесь на новый стиль мышления, вырастите новые таланты, освойте новые инструменты — и вы окажетесь на гребне следующей инновационной волны Автор: Джимми Гутерман

Новые задачи для ИТ-директора по организации работы с данными 58


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

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

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

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

В свете этого PwC рекомендует директорам по ИТ предпринять следующие шаги:

• Начинайте расширять компетенцию своих под-разделений за счет знаний и навыков, необходи-мых для работы с большими данными; возможно, вы найдете нужных вам специалистов среди уже работающего у вас персонала.

• Организуйте изолированные программные среды (соответствующее оборудование можно арен-довать или приобрести) для экспериментов с технологиями обработки больших данных.

• Изучите особенности инструментов с открытым кодом и способы управления связанными с ними рисками.

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

Уроки работы с большими данными от интернет-компанийСегодня литература для ИТ-директоров изо-билует примерами таких компаний, как Google.

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


Эти аналогии не всегда обоснованны, поскольку большинство компаний не сталкивается с такими сложностями в области обработки данных, какие встают перед интернет-компаниями и побуждают их заниматься разработкой инноваций в сфере работы с большими данными. Однако ни в одной другом сегменте бизнеса разработка инструмен-тов и методик, формирование образа мыслей и манеры работы с большими данными не имеют такого значения, чем в таких компаниях, как Google, Yahoo!, Facebook, Twitter и LinkedIn. Дирек-тора по ИТ могут многому научиться на примере этих компаний. Каждый серьезный сервис, кото-рый эти компании создают, основан на концепции извлечения все большей ценности из все больше-го объема данных.

Так, сервис 1-800-GOOG-411, с помощью которого пользователи могут получить телефоны и адреса местных компаний, не просто поставил под угрозу существование высокодоходного бизнеса спра-вочных служб крупных телефонных компаний (хотя это и стало одним из результатов его появ-ления). Это только побочный результат. Гораздо важнее, что реализация этого сервиса позволила Google собрать базу данных устной речи, которая сейчас считается крупнейшей в мире. С помо-щью собранных данных Google совершенствует качество распознавания голоса в сервисе Google Voice, прочих своих приложениях для мобильных телефонов, а также в других сервисах, находя-щихся на этапе разработки. Некоторые способы сбора данных, применяемые такими компаниями, как Google, приведены в таблице 1.

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

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

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

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

Потребности со стороны бизнесаКроме Google, Yahoo! и других Интернет-компаний, работающих с большими данными, существуют примеры компаний, работающих в традиционных сферах бизнеса, однако также использующих воз-можности больших данных. Так, директор по ИТ компании Wal-Mart Роллин Форд заявил в своем ин-тервью журналу The Economist в начале этого года: «Каждый день я задаю себе вопрос, как я могу луч-ше научиться работать с данными: собирать, управ-

Сервис Данные, собираемые интернет-компаниями

Самостоятельный просмотр рекламы Поведение при просмотре рекламных объявлений

Аналитические данные Обобщенные данные о пользовании интернет-сайтом

Социальные сети Разнообразные действия онлайн

Браузеры Ограниченный спектр действий при работе с браузером

Электронная почта Лексика, используемая в электронных сообщениях

Поисковые движки Данные поисков и просмотра результатов

Ленты RSS Подробная информация о читательских привычках

Дополнительные функции браузера Все действия при работе с браузером

Просмотр видео Все действия на сайте

Бесплатные справочные службы База данных произнесенных слов

Таблица 1. Стратегия интернет-порталов по работе с большими данными




лять и анализировать?» Сегодня ответ на этот вопрос подразумевает перераспределение бюдже-тов и перевод большей части нагрузки на менее до-рогостоящие аппаратные и программные средства. «Источником вдохновения для меня служит модель Google и концепция перехода на обработку огром-ных объемов данных с использованием большого количества обычных компьютеров. На мой взгляд, это составляет резкий контраст с исторической мо-делью вложения огромных средств в действитель-но специализированное оборудование», — говорит Фил Бакл, директор по технологиям Националь-ного агентства по совершенствованию сил охраны правопорядка Великобритании (NPIA), осуществля-ющего надзор за инфраструктурой охраны правопо-рядка в масштабах всей страны. Для директора по ИТ, чья задача обычно состоит в том, чтобы обеспе-чивать безопасность, охрану, конфиденциальность и функциональность внутренней компьютерной сети и хранящейся в ней информации, такой образ мыслей принципиально нов.

Развитие инициативы по работе с большими данны-ми дает возможность упрочить свое положение в компании как директору по ИТ, так и всему ИТ под-разделению. Но готов ли ИТ-директор взять на себя такую инициативу? «Хорошо, если подразделение ИТ сумеет обеспечить эффективное использование неструктурированных данных, — отмечает быв-ший аналитик Gartner Говард Дреснер, президент и основатель компании Dresner Advisory Services. — Однако в прошлом им не всегда удавалось успешно работать даже со структурированными данными, а неструктурированные данные гораздо сложнее, расположены по большей части по другую сторону фаервола и вне зоны их контроля».

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

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

Хэл Вериан, профессор Университета Калифорнии в Беркли и главный экономист Google, считает: «Самой привлекательной работой в ближайшие десять лет станет профессия статистика». И он, и другие специалисты, например профессор инфор-мационных технологий и менеджмента Массачу-

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

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

В Силиконовой долине и не только, где такие ком-пании, как Google, Facebook и Twitter, опираются в своей работе на тщательный и оперативный ана-лиз данных, растет популярность таких программ-ных сред, как MapReduce (для работы с Hadoop) и NoSQL (база данных для организации нереляцион-ных хранилищ данных).

Крис Венсел, создатель Cascading (альтерна-тивный прикладной программный интерфейс [API] для MapReduce), имеет опыт работы как со стартапами, так и с крупными компаниями. Он рассказывает: «Общаясь с директорами по ИТ, я говорю им: «У вас есть сотрудники, которые умеют работать с данными, и вы их знаете. Воз-можно, вы не достаточно используете их потен-циал. Но как только вы это сделаете, вы получи-те все преимущества от внедрения этих новых технологий». Рост внимания к анализу данных не означает, что специалисты по количественному

«Источником вдохновения для меня служит модель Google и концепция перехода на обработку огромных объемов данных с использованием большого количества обычных компьютеров.» — Фил Бакл, Национальное агентство по совершенствованию сил охраны правопорядка Великобритании


анализу или хранению данных вытеснят тради-ционных программистов. «Есть спрос не сколь-ко на Java-разработчиков или статистиков как таковых, а на специалистов, умеющих работать с денормализованными данными, — замечает Рэй Велес, технический директор компании Razorfish, предлагающей услуги по интерактивному марке-тингу и технологическому консалтингу и активно участвующей во многих инициативах в области больших данных. — Весь вопрос в том, как пере-вести данные в формат, незнакомый большинству специалистов. Большинство специалистов раз-бираются в SQL и реляционных форматах, так что реальные изменения требований к квалификации не имеют отношения к тому, умеете ли вы рабо-тать с Java, Python или другими технологиями».

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

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

«В нашей команде аналитиков Razorfish есть ребята вроде Джеймса, которые помогают внедрять новый образ мышления и умеют видеть новые возможно-сти в области обработки данных. Нам нужно гораз-до больше таких людей. А найти их не так просто. Одна из особенностей относительно Джеймса — это дерзость и смелость, готовность бросить вызов тем, кто привык пользоваться методиками и показателя-ми многолетней давности», — говорит Велес.

Директору по ИТ необходимо, чтобы во всех подраз-делениях организации были специалисты, обла-дающие разнообразными актуальными навыками анализа и программирования, понимающие цен-ность данных и не боящиеся пуститься в свободный поиск. Это не означает исчезновение характерных для большинства ИТ подразделений организацион-ных схем, ориентированных на технологии и при-ложения. Скорее это означает появление нового направления по исследованию данных, где будут за-няты больше, чем один-два сотрудника. Эти специа-листы будут пользоваться различными инструмента-ми в зависимости от необходимости, как показано в таблице 2. И среди них будет большее количество инструментов с открытым кодом, чем раньше.

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

Навыки Инструменты (пример комбинации) Комментарии

Обработка естествен-ных языков и интеллек-туальный анализ текста

Clojure, Redis, Scala, Crane, другие библиотеки функциональных языков программирования на основе Java, Python Natural Language ToolKit

В определенной степени каждый из этих инструмен-тов выступает в качестве дополнительного уровня абстрагирования над Hadoop. Компетентные специа-листы используют несколько вертикальных уровней. Например, FlightCaster использует стек, включающий Amazon S3 -> Amazon EC2 -> Cloudera -> HDFS -> Hadoop -> Cascading -> Clojure1

Сбор и интеллектуаль-ный анализ данных

R, Mathlab R больше подходит для финансов и статистики, Mathlab в большей степени ориентирован на инже-нерные задачи2

Создание скриптов и программирование для базы данных NoSQL

Python и соответствующие среды, HBase, Cassandra, CouchDB, Tokyo Cabinet

Эти инструменты совместимы с функциональными языками, такими как LISP или его аналоги, или осно-ваны на них. Например, система CouchDB написана на Erlang3 (см. обзор Clojure и LISP на стр. 30)

Таблица 2. Новые навыки и инструменты для подразделения ИТ

Источник: Cited online postings and PwC, 2008–2010

1 Pete Skomoroch. How FlightCaster Squeezes Predictions from Flight Data. Блог Data Wrangling, 24 августа 2009 г., http://www.datawrangling.com/how-flightcaster-squeezes-predictions-from-flight-data (ссылка проверена 14 мая 2010 г.).

2 Brendan O’Connor. Comparison of data analysis packages. Блог AI and Social Science, 23 февраля 2009 г., http://anyall.org/blog/2009/02/comparison-of-data-analysis-packages-r-matlab-scipy-excel-sas-spss-stata/ (ссылка проверена 25 мая 2010 г.).

3 Программы на описательных языках, таких как Python, исполняются медленнее, чем Java, однако иногда разработчики идут на такой компро-мисс, чтобы повысить собственную производительность. Ряд компаний создали собственные программные среды и выпустили их в качестве открытого кода. См. Klaas Bosteels. Python + Hadoop = Flying Circus Elephant. Блог Last.HQ Last.fm, 29 мая 2008 г., http://blog.last.fm/2008/05/29/python-hadoop-flying-circus-elephant (ссылка проверена 14 мая 2010 г.).



и вниманием, повышать в должности, и принимать на работу преимущественно в ИТ подразделение, где они смогут приносить пользу всей организации, а не только отделу маркетинга.

Создайте лабораторию для экспериментовХотя директор по ИТ может убедительно обосно-вать необходимость работы с большими данными с позиции бизнеса, даже убедительные проекты связаны с определенным риском. Многие директо-ра по ИТ, анализируя риски, связанные с большими данными, сразу же увидят знакомое пугало. Многие технологии обработки больших данных, прежде всего Hadoop, имеют открытый код, что традицион-но считается источником дополнительных рисков. Спор между сторонниками открытого кода и лицен-зионного ПО имеет долгую историю. Директора по ИТ, пытающиеся внедрить программы с открытым кодом, от веб-сервера Apache до системы управле-ния контентом Drupal, сталкиваются с обычными аргументами против кода, доступного всем же-лающим. Некоторые из этих аргументов, особенно опасения по поводу безопасности и надежности, бывают достаточно поверхностны. Внутренние веб-серверы Google построены на основе Apache, однако едва ли найдется другой столь же надеж-ный сайт больших данных, как Google. Очевидно, что одна из трудностей, с которыми сталкивается директор по ИТ, никак не связана с данными или компетенцией персонала. Проекты с открытым кодом поступают в открытый доступ на более ран-них стадиях своего развития, чем их коммерческие альтернативы. В этом отношении инструменты об-работки больших данных менее стабильны и закон-чены, чем наборы инструментов с открытым кодом Apache или Linux.

Внедрение технологий с открытым кодом, таких как Hadoop, в среде, в основном использующей ли-цензионные программы, не обязательно означает, что нужно перевернуть с ног на голову всю органи-зацию. Директор по ИТ небольшой компании в шта-те Массачусетс отмечает: «В каждой организации ИТ есть экспериментальная лаборатория, неважно, насколько формально она организована, — изо-лированная среда, где можно тестировать и про-верять новые технологии. Именно так программы с открытым кодом впервые попали в нашу компа-нию. Эксперименты с Hadoop откроют дверь для других открытых программ. Или, быть может, это все останется маленьким аккуратным проектом с открытым кодом, который существует сам по себе и никому не мешает. Годится любой из этих вариан-тов, смотря по тому, что нужно вашей компании».

Исполнительный вице-президент и директор по тех-нологиям Технологической группы стандартных сер-висов компании Disney Бад Алберс согласен с такой точкой зрения. «Все зависит от образа мышления вашей организации, — считает он. — Все зависит от ваших организационных способностей. На техноло-гии типа Hadoop обычно распространяется этакое

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

PwC поддерживает эти мнения и настоятельно ре-комендует организовать такую экспериментальную среду для работы с большими данными с помощью Hadoop/ MapReduce. В 2010 году это должно стать нормой для крупных компаний, так же как и выде-ление нескольких специалистов и бюджета под за-дачу исследовательской работы с данными. Более подробно о том, как создать такую эксперимен-тальную среду для работы с данными, рассказыва-ется в статье «Поиск эффективных инструментов работы с большими данными» на стр. 41.

Возможные варианты, как такое эксперименталь-ное подразделение может вписываться в организа-ционную структуру компании, приведены на рис. 1.

Вице-президент по ИТ

Директор по разработке приложений

Директор по анализу данных

Команда по анализу

данных

Команда по перспективным исследованиям данных

Заведующий финансовым отделом

Заведующий операционным отделом

Заведующий отделом продаж

Заведующий отделом интернет-сайтов

Заведующий отделом маркетинга

Рис. 1. Место группы перспективных исследований данных в организационной структуре


Разные компании будут экспериментировать с Hadoop по разному и предпочтут более или менее плотную изоляцию этих экспериментов от осталь-ной ИТ инфраструктуры. Задача же директора по ИТ — решить, как стимулировать начало таких экспериментов.

Понимание рисков и управление рискамиС большими данными связан ряд вполне обосно-ванных рисков, и директор по ИТ должен уметь с ними работать. В случае кластеров Hadoop ак-туальным вопросом является обеспечение безо-пасности. Эта функция была добавлена в проект в процессе разработки, а не заложена в нем изначально. Она еще весьма далека от идеала. Многие проекты с открытым кодом стартуют как попытки доказать ту или иную концепцию или


решить ту или иную частную задачу. Некоторые из них, например Linux или Mozilla, добиваются значительных успехов, однако они редко исходят из того набора требований, с которым сталки-вается директор по ИТ, пытаясь внедрить новую систему в корпоративную инфраструктуру.

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

Чтобы такие ошибки не повторялись необходим соответствующий риск-ориентированный под-ход, считает Ларри Бест, специалист по управ-лению рисками в сфере ИТ PwC: «Вам нужно тщательно продумать, что может пойти не так, провести количественный анализ вероятности возникновения такой ошибки и оценить возмож-ные последствия ее возникновения».

Бест отмечает, что для реализации каждого кон-кретного сценария крайне важен правильный выбор средств управления рисками. Единственный

способ сделать правильный выбор заключается в том, чтобы сфокусироваться на наиболее ключе-вых инструментах управления рисками, считает он. Предприятиям просто не хватит ресурсов, чтобы обеспечить всесторонний контроль. Набор стан-дартов «Задачи по управлению в информационных и смежных технологиях» (COBIT), широко исполь-зуемый справочник для оценки рисков в сфере ИТ, «это список тысяч механизмов контроля», отмеча-ет он. Жонглировать множеством шариков — это еще не риск. «Риск в том, чтобы знать, какие шарики сделаны из резины, а какие — из стекла».

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

«Ключевой вопрос заключается в том, готов ли специалист по ИТ отказаться от имеющегося статуса-кво, скажем, от использования СУРБД [систем управления реляционными базами дан-ных], в пользу более мощных технологий, — счи-тает Дреснер. — Это означает грандиозные перемены, а директор по ИТ далеко не всегда рад переменам». Наиболее прогрессивно мыслящие ИТ-организации постоянно пересматривают свой портфель программных продуктов и корректиру-ют его по мере необходимости.

В данном случае настоятельная необходимость об-работки все больших объемов собираемых компа-нией данных налицо. Даже не склонные к риску ди-ректора по ИТ изучают возможности применения больших данных в своей компании. Бад Матайсел,

В таблице 3 приведен ряд рисков, связанных с анализом больших данных и перечислены способы их снижения.

Риск Тактика снижения риска

Чрезмерное доверие к наблюдениям, сделанным на основании анализа данных, ведет к потерям

Тестирование

Недостоверные или устаревшие данные Организуйте строгий контроль метаданных; непроверенная информация должна снабжаться соответствующими метками

Анализ ведет к утрате способности действовать Ориентируйте экспериментальную среду на конкретные проблемы или возможности бизнеса

Безопасность Разместите кластеры Hadoop за пределами фаервола; сохраняйте бдительность; обратитесь за содействием к директору по безопасности

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

Негативная реакция других подразделений организации Управляйте процессом изменений, чтобы ускорить процесс внедрения, демонстрируйте быстрые достижения

Таблица 3. Как снизить риски, связанные с анализом больших данных

Source: PwC, 2010



директор по ИТ компании Achievo, предоставляю-щей услуги по аутсорсингу, выделяет три группы рисков и решений в сфере больших данных:

• Доступность — управление доступом к хранили-щам данных, применяемых для анализа.

• Классификация — «серые даты» должны быть маркированы.

• Управление — кто это использует и для чего?

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

ВыводыДля многих компаний большие данные являются одновременно новой возможностью (какие по-лезные иголки можно отыскать в терабайтном стогу данных?) и источником стресса (имеющиеся в нашем распоряжении инструменты и методы не справляются с большими данными, мы не можем масштабировать их в достаточной мере, чтобы решить проблему). Как-никак, префикс «тера» в слове «терабайт» происходит от греческого слова, означающего «чудовище». Директор по ИТ, намеревающийся использовать большие данные, чтобы принести дополнительную ценность своей компании, выходит на битву с чудовищем. Сегодня ИТ-директор управляет не только аппаратными и программными средствами, он также должен управлять и самими данными, которые хранятся на этих аппаратных устройствах и применяются в программных продуктах, кроме того, он должен создавать среду, позволяющую извлекать из этих данных новые знания.

Самые разные компании, от Amazon.com до «Бо-стон Ред Сокс», обеспечивают свою конкуренто-способность в том числе основываясь на данных, которые они собирают, и выводах, которые они делают из их изучения. Задача директора по ИТ — обеспечить простой, надежный и безопас-ный доступ к этим данным и выработать логичные и надежные способы их изучения. Необходимости спешно внедрять новые технологии пока нет, но директор по ИТ должен быть готов к новым зада-чам по работе с большими данными.

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

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

Интернет-компании уже подняли планку весьма высоко. Один из партнеров Sungard Consulting Services Джон Авери приводит в пример портал YouTube: «Способность YouTube индексировать такой огромный банк данных, а потом еще и про-водить его дополнительный анализ, причем прово-дить постоянно, не имея возможности предвидеть, каков будет этот анализ, на этапе, когда данные помещаются на хранение, производит очень, очень внушительное впечатление. Над этой задачей спе-циалисты в сфере финансовых технологий бьются уже многие годы».

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

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


Новые подходы к анализу клиентской статистикиМарк Тейлор и Рэй Велес (Razorfish) обсуждают, каким образом новые технологии способны сделать анализ петабайт веб-данных более эффективнымИнтервью провели: Алан Моррисон и Бо Паркер

Марк Тейлор занимает должность директора по глобальным решениям, а Рэй Велес является дирек-тором по технологиям в компании Razorfish, в настоящее время входящей в Publicis Groupe и предла-гающей консультации по интерактивному маркетингу и технологиям. В своем интервью Тейлор и Велес рассказывают о своем тесном знакомстве с сервисами Amazon Elastic Compute Cloud (EC2), Elastic MapReduce, а также Microsoft Azure Table для массовой сегментации клиентов и других задач интеллек-туального анализа данных.

PwC: Какие коммерческие задачи вы пытаетесь решить с помощью сервисов Amazon?МТ: Нам необходимо объединять большие объемы разрозненных данных, к которым имеем доступ и мы, и конкретный клиент. Раньше у нас не было возможности объединять эти данные при том уровне мощности, который мы могли достичь, ис-пользуя облачные ресурсы.

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

Эта стратегия хорошо работала до тех пор, пока мы не захотели объединить и увязать применение SQL- серверов с онлайновым анализом массивов данных в рамках фиксированной инфраструктуры. Исполь-зуя облачные ресурсы, мы сумели объединить мил-лиарды фрагментов данных и начать настоящую категоризацию этой информации, позволяющую отделить данные без персональной идентифика-ции с конкретным пользователем от персональных данных сеансов работы в Интернете и конкретных способов сегментации поведения клиентов.

Такая возможность позволяет нам гораздо эффек-тивнее оптимизировать мерчендайзинг наших кли-ентов и осуществлять контекстный анализ данных. Мы можем использовать данные не только для

подготовки отчетности, но также и для целей тар-гетинга и лучшего понимания реальной ситуации.

РВ: Это несколько отличается от традиционного подхода к работе с базами данных. Традиционный подход просто не работает для таких объемов данных, которые приходится перерабатывать сер-веру рекламных объявлений Atlas [разработанный Razorfish сервер рекламных объявлений, в настоя-щее время принадлежащий Microsoft и предлагае-мый в рамках сервиса Microsoft Advertising].

PwC: Аспект масштабируемости здесь понятен. Но разве характер собираемых вами данных не позволяет их обрабатывать с помощью реляци-онных подходов?РВ: Проблема здесь не в характере данных как таковых, а в тех задачах, которые приходится решать, имея дело с реляционными данными. Реляционные данные позволяют добиться значи-тельной гибкости, поскольку их формат нормали-зован, их можно делить и группировать вдоль и поперек, анализировать множеством различных способов. Но пока вы не приведете их к формату, используемому в хранилищах данных, или к денор-мализованному формату EMR [Elastic MapReduce], или формату Bigtable, производительность их об-работки будет совсем не такой, какая необходима при обработке больших объемов данных.

«Мы можем использовать данные не только для подготовки отчетности, но также и для целей тар-гетинга и лучшего понимания реальной ситуации» (Марк Тейлор)

Новые подходы к анализу клиентской статистики 66


Так что, в сущности, это классический компромисс: данные редко бывают идеально пригодны для любого из этих методов. Но с точки зрения произ-водительности и объема, все данные, поступаю-щие к нам из множества источников, не возможно переработать даже с помощью технологий приме-няемых в хранилищах данных.

PwC: Что побудило вас попробовать новую тех-нологию для решения старой проблемы?РВ: Вот похожий случай, когда мы применили несколько иную технологию. Мы работали с крупной компанией по предоставлению финан-совых услуг, и нам нужно было обрабатывать значительные объемы данных по структуре расходов и анонимных данных. Мы знали, что нам придется иметь дело с данными интерне-товских масштабов, и собирались использовать колоночные базы данных. Вопрос состоял в том, можно ли добиться достаточной мощности с помощью реляционной структуры с достаточ-ным числом индексов. Мы провели ряд экспери-ментов с реляционной структурой, но ничего не получилось.

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

Нам удалось сделать что-то, что мы никогда не предполагали бы кому-то предложить, потому что не верили бы в его эффективность. Но эта исто-рия положила начало радикально новой коммер-ческой идее. Мы сумели сделать продукт, который в обычной ситуации был бы реализован в виде приложения BusinessObjects или Cognos, но был бы не способен работать с данными интернетов-ских масштабов.

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

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

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

Ничтожный процент этих совокупностей данных оказывает наиболее существенное влияние на наше взаимодействие с клиентами. Мы уже раз-рабатываем новые стратегии измерения данных и применения ключевых показателей эффектив-ности [KPI], и мы начинаем задавать себе вопрос: «Действительно ли нашим клиентам необходимы все эти данные и контрольные точки для решения их бизнес-задач?»

PwC: Как меняется набор навыков и умений, ко-торый необходим вам в Razorfish, с появлением этих новых технологий?РВ: Для большинства людей проблему составляет понимание того, как перевести данные в опреде-ленный формат. Большинство специалистов разби-

«Мы можем использовать данные не только для подготовки отчетности, но также и для целей таргетинга и лучшего понимания реальной ситуации». — Марк Тейлор


раются в SQL и реляционных форматах, так что, на мой взгляд, изменение набора необходимых навы-ков определяется не столько выбором Java, Python или другой технологии как основного инструмента, сколько пониманием различий между нормализо-ванными и денормализованными структурами.

МТ: С коммерческой точки зрения все меньшее значение имеет умение работать с каким-либо конкретным продуктом в рамках присущих ему функциональности и ограничений, и все большее значение приобретает развитие новых возмож-ностей в нашей работе. Это действительно все меняет — не только в технологической сфере, но также и в других областях.

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

Благодаря использованию Elastic MapReduce вместе с Cascading наши решения могут повысить эффективность также всех нетехнических бизнес-процессов и проектов различных подразделений компании. Так, типовая задача по сегментации рынка предполагает работу нескольких команд аналитиков с разнообразными массивами данных на различных этапах их обработки, а также работу других аналитиков, которые решают, как компания должна рассматривать выявленные группы клиен-тов. Использование технологии Hadoop вместе с Cascading позволяет выявлять нетипичные взаи-мосвязи между разнородными данных с меньшим количеством усилий, что делает возможным соз-давать новые типы сегментации и лучше разби-раться в общей картине.

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

PwC: Вы знакомы с методикой Билла Джейм-са — статистика в Высшей лиге бейсбольных команд, который по-новому подошел к изуче-нию статистических показателей бейсбола? Джеймс разработал ряд показателей, которые оказались более эффективны, чем те, которые использовались всеми командами на протяже-нии многих лет. Наверное, именно таким людям вы даете возможность вырабатывать гипотезы, пожалуй, даже использовать технологии машин-ного обучения для выработки гипотез.РВ: Безусловно! В нашей команде аналитиков Razorfish есть ребята вроде Джеймса, которые по-могают внедрять новый образ мышления и умеют видеть новые возможности в области обработки данных. Нам нужно гораздо больше таких людей. А найти их не так просто. А ведь у нас работет ряд ведущих специалистов в отрасли.

Знаете, давным-давно мы разрабатывали сайт и платформу для Высшей лиги бейсбольных команд. Раздел статистики всегда был самой сложной частью сайта, но он был необходим. Очень немногие действительно хотели возить-ся со всеми этими данными. Тогда мы работали на Oracle. Мы применили концепцию временных таблиц, позволяющую денормализовать множе-ство разнообразных реляционных таблиц с целью повышения производительности, и это оказа-лось очень непросто. Если бы тогда, в 1999 или 2000 годах, у меня была кластерная технология, которая есть у нас сейчас, мы могли бы добиться значительно большего масштаба роста, вместо того чтобы ограничиться кластером из двух жал-ких серверов.

PwC: В примере с Биллом Джеймсом речь идет не только о среднем проценте отбитых мечей, который много лет использовался для измере-ния вклада хиттера в игру, он начал измерять показатели, которые никогда не исследовались до него.РВ: И даже совершенно, казалось бы, абсурдные вещи. Нам приходилось обрабатывать и такие запросы, как, скажем, показать все хиты Дерека Джетера в играх, проходивших поздно вечером на травяном поле.

PwC: Вот-вот. Именно.РВ: Я всегда использую именно этот пример, пото-му что это было труднее всего реализовать в необ-ходимом масштабе, но раздел статистики на сайте позволял выполнить множество таких непредусмо-тренных расчетов. Но если бы к разделу подключи-лись слишком много пользователей, сайт бы просто рухнул, поскольку Oracle не смог бы справиться с такой задачей. Если бы мне пришлось снова делать такой сайт сегодня, я мог бы применить EMR или Bigtable, и все было бы намного проще.

PwC: Учитывая размеры баз данных Bigtable, которые можно вести, не применяя операторов

«Раздел статистики всегда был самой сложной частью сайта [Высшей лиги бейсбольных команд], но он был необходим». — Рэй Велес

Новые подходы к анализу клиентской статистики 68


соединения, вы, видимо, получаете возмож-ность проводить фильтрацию более эффек-тивно, может быть, даже в несколько этапов, чтобы получить полезные данные. Вы можете применять циклический подход в своем анали-зе, не так ли?РВ: Да, вы как будто снимаете шелуху с луковицы, слой за слоем. Но перевод данных в денормали-зованный формат заметно ограничивает гибкость, поскольку единственный оператор where дает вам больше мощности, чем целый стандартный меха-низм доступа EMR или Bigtable.

Это как разница между инструментом, сделанным для выполнения одной конкретной задачи, и ин-струментом, рассчитанным на выполнение задач, о которых я даже еще не задумывался. Если снять первый слой шелухи, вы можете подумать: «Супер! Какие интересные данные, мы идем в очень интересном направлении». Что дальше? Возможно, вам не удастся сразу поделить данные именно таким образом. Возможно, вам придется отступить на шаг назад и поискать другую струк-туру разбиения данных.

PwC: Социальные сети способствуют росту ак-тивности и вовлеченности потребителей. С точ-ки зрения маркетингового анализа, это то же

самое, что реклама во время финального матча Супербоул, только в масштабе социальной сети. Если вы собираетесь размещать такую рекламу регулярно, вам необходимо знать, каково ее воздействие, кто ее смотрит и какое влияние она оказывает на зрителей. Если представить себе последствия таких исследований в плане объемов обработки данных, это просто потряса-ет воображение. РВ: Если подумать о популярности Hadoop и Bigtable, что, по сути, означает заглянуть за ку-лисы механизма поиска Google, и если подумать собственно о поиске, то в итоге поиск — это ре-комендации. Это способность выдать актуальную информацию.

Что открывает возможность разрабатывать новые способы поиска и конкурировать с поисковыми системами за счет предоставления более сфо-кусированной информации? Если посмотреть на перспективы развития в ближайшие три-пять лет, они просто поразительны. Раньше мы говорили, что никогда не сможем воспроизвести инфраструк-туру, созданную Google. Google является вторым по величине производителем серверов в мире. Но сейчас у нас появился способ воспроизвести в не-больших масштабах и для целевого применения то, что делает Google. По-моему, это потрясающе.

«Что открывает возможность разрабатывать новые способы поиска и конкурировать с поисковыми системами за счет предоставления более сфокусированной информации? Если посмотреть на перспективы развития в ближайшие три-пять лет, они просто поразительны». — Рэй Велес


Там, где кончается асфальт(послесловие научного рецензента)

Методы работы с большими данными предполагают широкую вариативность мышления и недюжинную изобретательностьАвтор: Андрей Шелудяков

Там, где кончается асфальт 70


Настоящий выпуск журнала «Технологический про-гноз» предваряет пример из мира бейсбола. Речь идет о выборе ракурса рассмотрения некоторых факторов, оказавшихся результативными при ана-лизе игр конкретной бейсбольной команды. Такой в основе своей комбинаторный подход далеко не нов. Он применялся, например, в ХIII веке фран-цисканским монахом Раймундом Луллием1. Луллий комбинировал сочетания смысловых символов, размещенных на полосах центрированных окруж-ностей, вращая их друг относительно друга. Если складываемая таким образом «фраза» была тривиальна по возникающим тропам или фигурам речи, то она пропускалась. Нетривиальные «фра-зы» тщательно фиксировались и осмысливались.

Такая смысловая комбинаторика, или, как назвал сам Луллий свою машину, Ars magna («Великое ис-кусство»), подверглась резкой критике современ-ников. Позднее Джонатан Свифт в «Путешествиях Гулливера»2 нарисовал карикатурный образ лул-листа. Однако метод Луллия отнюдь не бессмыс-ленен, как может показаться с первого взгляда. Он тесно связан с мнемоникой — искусством запоминания, широко применявшимся древними греками. Их наследие активно развивалось сред-невековыми монахами и во времена Ренессанса. В частности, Джордано Бруно предлагал индекси-ровать некоторый набор образов, привязывая их к определенной «координатной» сетке3.

Мысленная раскладка запоминаемых образов по системе до «боли знакомых» для запоминаю-щего мест — это классический прием ритори-ки — науки, входящей в необходимый научный тривиум во времена Аристотеля. Тогда основной движущей силой являлось неодолимое желание мыслителей составить целостное или герменев-тическое мировоззрение, или, переформулируя в более знакомые нам термины, — выработать адекватные методы работы с массивами плохо структурированных больших данных. Американ-ский языковед и этнограф Бенджамин Уорф выдвинул в одном из своих выступлений сле-дующую тираду: «Мир предстает перед нами как калейдоскопический поток впечатлений, кото-рый должен быть организован нашим сознанием, а это значит, в основном языковой системой,

хранящейся в нашем сознании. Мы расчленяем мир и распределяем значения так, а не иначе в основном потому, что мы участники некое-го соглашения, предписывающего подобную систематизацию. Это соглашение имеет силу для определенного коллектива и закреплено в системе моделей нашего языка, но оно, тем не менее, никак и никем не сформулировано и лишь подразумевается. Мы вообще не сможем гово-рить, если не подпишемся под систематизацией и классификацией материала, обусловленной указанным соглашением»4.

Крупнейший специалист в области психолингви-стики канадско-американский ученый Стивен Пинкер оппонирует Уорфу: «Образы, лежащие в основе мышления, с одной стороны и предложения в языке с другой стороны действуют во многом друг другу наперекор. Любая определенная мысль в нашей голове заключает в себе огромный объем информации. Чтобы донести до слушателя инфор-мацию за разумный отрезок времени, говорящий может облекать в слова только часть своего со-общения, рассчитывая на то, что слушатель вос-полнит пробелы сам. Люди думают не на англий-ском, китайском или языке апачей; они думают на мыслекоде. Этот мыслекод, вероятно, немного похож на все вышеупомянутые языки. Предпо-ложительно, он располагает символами и комби-нациями символов для выражения. Получается, что носители английского языка думают на неком упрощенном и снабженным примечаниями квази-английском, а носители языка апачей думают на упрощенном и снабженным примечаниями квазиа-пачей. Чтобы заставить эти мыслекоды должным

«Мы расчленяем мир и распределяем значения так, а не иначе в основном потому, что мы участники некоего соглашения, предписывающего подобную систематизацию». —Бенджамин Уорф

1 Френсис Йейтс. Искусство памяти (F.Yates. The Art of Memory. L.: Routledge and Kegan Paul, 1966, СПб.: Университетская книга, 1997).2 Свифт Д. Сказка бочки. Путешествия Гулливера. М.: Правда, 1987.3 Кстати, такая «технология» по умолчанию предполагает наличие множества допустимых опорных систем координат, что практически тут же при-водит к многомировой концепции мироздания. За такую крамольную мысль, в основном, и был сожжен Бруно. (Прим. автора)

4 Пинкер С. Язык как инстинкт. М.: Книжный дом «Либроком», 2009.


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

Схожую мысль высказал известный психолог Лев Выготский6. Несколько вольно перефразируя его замечание, можно сказать, что мысли конденсиру-ются в виде слов, а слова испаряются в мысли.

А причем тут, собственно говоря, ИТ? И в том числе алгоритмы обработки больших данных? Речь, конечно, идет о смысловом поиске.

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

и автор новой теории описания Вселенной посред-ством клеточных автоматов8, опирается на индек-сацию закрытого, но хорошо освоенного, то есть провязанного десятками тысяч «нервных» связей, пространства террабайтов больших данных в сво-ем «банке знаний» Wolfram Alpha9.

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

Нас всех интересует знание, и более того, знание сегодняшнего дня, а не дня вчерашнего. Пер-вейшее условие успешности любого бизнеса —

это «здесь и сейчас», а не «где-то и когда-то». При этом у каждого человека или компании есть потребность выявить смысл происходящего в дан-ный момент, соотнося это с опытом, накопленным человечеством. В таком аспекте и тактика откры-того поиска Google, и тактика закрытого освоения найденного Wolfram Alpha становятся необходимы-ми во взаимном ИТ-дополнении друг друга.

Лев Толстой, полемизируя с многочисленными критиками, говорил: «Если же бы я хотел ска-зать словами все то, что имел в виду выразить романом, то я должен бы был написать роман тот самый, который я написал, сначала. И если близорукие критики думают, что я хотел опи-сывать только то, что мне нравится, как обе-дает Облонский и какие плечи у Карениной, то они ошибаются. Во всем, почти во всем, что я писал, мною руководила потребность собра-ния мыслей, сцепленных между собою, ждя выражения себя, но каждая мысль, выраженная словами особо, теряет свой смысл, страшно понижается, когда берется одна из того сцепле-ния, в котором она находится. Само же сцепле-ние составлено не мыслью (я думаю), а чем-то другим, и выразить основу этого сцепления непосредственно словами никак нельзя; а мож-но только посредственно — словами описывая образы, действия, положения»10.

Выходит, что когда мы обрабатываем большие информационные массивы и получаем резуль-тат в виде наборов битов и байтов конкретной отфильтрованной информации, наш мозг занят совершенно другой проблемой — извлечением смысла их этих информационных полей данных или их смысловой реконструкцией. Известный французский математик Александр Гротендик в своей автобиографической книге «Урожаи и посевы»11 замечает, что литература — это та же математика. А согласно схеме знаменитого геоме-тра Феликса Клейна, каждое пространство, в том числе и смысловое, может характеризоваться своей «группой симметрий» — совокупностью

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

5 Пинкер С. Язык как инстинкт. М.: Книжный дом «Либроком», 2009.6 Выготский Л. С. Мышление и речь. М.: Гнозис, 1983.7 http://www.stephenwolfram.com/publications/books/mbooks/8 http://www.wolframscience.com/nksonline/toc.html9 http://www.wolframalpha.com/ (Ссылка проверена 01.11.2010)10 Лотман Ю. Непредсказуемые механизмы истории. TLU Press. Таллин, 2010.11 Alexandre Grothendieck. Recoltes et Semailles. Fatuité et Renouvellement, 1984.

Там, где кончается асфальт 72


преобразований, сохраняющих без изменения определенные свойства выбранных фигур.

Немецкий математик Герман Вейль, завершая свою программную книгу «Симметрия», подводит общий итог: «Вывод, ставший руководящим принципом современной математики, состоит в следующем: всякий раз, когда приходится иметь дело с неко-торым объектом, наделенным структурой, надо попытаться определить группу его симметрий, то есть группу, элементами которой являются преоб-разования, оставляющие без изменения все струк-турные соотношения. После этого целесообразно изучить подгруппы группы, например подгруппу преобразований, оставляющих неподвижным один элемент или оставляющих неподвижными два эле-мента. У истоков симметрии лежит математика»12.

Чтобы составить с различной степенью подроб-ностей общее мнение о мире бейсбольных игр, выделив основные факторы и определив систему ключевых показателей, то есть определив группу тех технических параметров, которые попадают в смысловое поле значимого статистического про-гноза, необходимо предварительно это смысловое поле тщательно очертить и разметить в категори-ях некоторого метаязыка. Насколько далеко мож-но зайти в этом направлении, поясняет Умберто Эко в своей книге «Отсутствующая структура»13: «В одном итальянском интервью Леви-Стросс14 за-метил, что нет смысла ставить вопрос о структуре произведения искусства: произведение можно рассматривать как некий кристалл, отталкиваясь от спровоцированных им ответов адресата. Если Последняя структура существует, то она не может быть определена: не существует такого метаязы-ка, который мог бы ее охватить. А если она как-то выявляется — то она не последняя. Последняя структура — это та, что, оставаясь скрытой и неструктурируемой порождает все новые свои ипостаси. И если прежде всяких определений на нее есть прямое указание, то тут-то и внедряется в изучение языка та аффективная составляющая, что неотъемлема от всякого герменевтичного вопрошания. И тогда структура становится не объективна и не нейтральна: она уже наделена смыслом. Отправляться на поиски Последнего основания коммуникации — значит, искать его там, где оно не может быть более определено в структурных терминах. Структурные модели име-ют смысл, только если не ставится вопрос о про-исхождении самой коммуникации».

Новые методы для работы с большими данными возникают на пограничном слое — там, где уже заканчивается чисто теоретическое рассмотре-ние и активно применяются различные эври-стические модели, и прежде всего заявленный в текущем номере «Технологического прогноза» инструментарий ИТ. В частности, одно из пря-мых следствий этого факта — отсутствие по-нятия «теоретической биологии», несмотря на достигнутые в последнее время потрясающие успехи физико-химических методов в расшиф-ровке генома и воссоздании объемных функ-циональных моделей жизненно важных бел-ков многоклеточного организма. Чтобы яснее очертить проблему, можно также сослаться на известную теорему Абеля-Руффини о нераз-решимости уравнения пятой степени и выше в радикалах. Если в условиях теоремы для многочленов второй, третьей и четвертой сте-пени мы можем алгоритмически точно расписать каждое решение, то уже для пятой степени и выше такая процедура, вообще говоря, принци-пиально неосуществима. Причиной неопреде-ленности, на какой конкретно из пяти корней уравнения мы натолкнемся в поисках решения, является неразрешимость группы икосаэдра15. А поскольку именно группа икосаэдра обеспечи-вает возможность существования автономных систем организмов в нашем трехмерном жиз-ненном пространстве, то дальше, мне кажется, можно не говорить.

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

«Последняя структура — это та, что, оставаясь скрытой и неструктурируемой, порождает все новые свои ипостаси». —Умберто Эко

12 Вейль Г. Симметрия. М.: Наука, 1968.13 Эко У. Отсутствующая структура. Введение в семиологию. ТОО ТК «Петрополис», 1998.14 Клод Леви-Стросс (фр. Claude Lévi-Strauss [klod levi stros]); — французский этнограф, социолог и культуролог, создатель школы структурализма

в этнологии, теории «инцеста» (одной из теорий происхождения права и государства), исследователь систем родства, мифологии и фольклора.15 Клейн Ф. Лекции об икосаэдре и решении уравнений пятой степени. М., 2004.


Благодарности

Американское изданиеОбщее руководство проектом в СШАРуководитель направления технологийТом ДеГармо

Управляющий партнерТом Крарен

Центр технологий и инноваций в СШАГлавный редакторБо Паркер

РедакторыВинод Байя, Алан Моррисон

АвторыЛарри Бест, Гален Груман, Джимми Гутерман, Ларри Мэрион, Билл Робертс

Редакторы-консультантыМаркус Андерле, Стивен Бэй, Брайан Бут, Том Джонсон, Кришна Кумарасвами, Бад Матайсел, Шон МакКлоури, Раджеш Мунавалли, Луис Орама, Дейв Паттон, Джонатан Рейченталь, Терри Рет-тер, Дипак Сахи, Картер Шок, Дэвид Стейер, Джо Таглиаферро, Димпси Текчандани, Синди Томпсон, Том Уркхарт, Кристина Вендин, Дин Воткивич

Графический дизайнХудожественный директорЖаклин Корлисс

ДизайнерыЖаклин Корлисс, Сюзанна Лау

ИллюстрацииДональд Бренхардт, Сюзанна Лау, Татьяна Печеник

ФотографыТим Шумовски, Дэвид Типлинг (Getty Images), Марина Вальц

Консультанты-рецензентыДейв Стуки, Крис Венсел

Особая благодарностьРэй Джордж, Page One Рейчел Лавингер, Razorfish Мэриам Сугхайер, Disney

Редакция выражает благодарность перечис-ленным ниже представителям компаний и организаций и отраслевым аналитикам, мате-риалы интервью и бесед с которыми были ис-пользованы при подготовке этого выпуска:

Бад Алберс, исполнительный вице-президент и технический директор группы распределенных технологических сервисов компании Disney

Мэтт Аслетт, аналитик по корпоративному программному обеспечению, the451

Джон Авери, партнер, Sungard Consulting Services

Амр Авадалла, вице-президент по инжинирингу и технический директор компании Cloudera

Фил Бакл, технический директор, Национальное агентство по совершенствованию сил охраны правопорядка

Говард Дреснер, президент и основатель, Dresner Advisory Services

Брайан Донелли, основатель и исполнительный директор, InSilico Discovery

Мэтт Эстес, главный архитектор данных Техноло-гической группы стандартных сервисов, Disney

Джим Кобелиус, старший аналитик, Forrester Research

Дуг Ленат, основатель и исполнительный директор, Cycorp

Роджер Магулас, директор по исследованиям, O’Reilly Media

Натан Марц, ведущий инженер, BackType

Билл МакКолл, основатель и исполнительный директор, Cloudscale

Джон Паркинсон, исполняющий обязанности директора по технологиям, TransUnion

Дэвид Смоли, директор по информационным технологиям, Flextronics

Марк Тейлор, директор по глобальным решениям, Razorfish

Скотт Томпсон, вице-президент по архитектуре, Технологическая группа стандартных сервисов, Disney

Рэй Велес, технический директор, Razorfish


Благодарности 74

Российское изданиеОбщее руководство проектом в России: Партнер, консультационные услуги в области информационных технологий Дуглас Даунинг

Старший менеджер отдела маркетинга, Центр технологий и инноваций Вера Тоцкая

Младший менеджер отдела маркетинга Анна Нечаева

Центр технологий и инноваций в РоссииКоординатор центра, Партнер, руководитель практики по оказанию налоговых услуг компаниям сферы высоких технологий, коммуникаций, индустрии развлечений и СМИНаталья Мильчакова

Главный редакторВиталий Лазорин

Выпускающий редакторЮлия Гринева

АвторыВиктор Лавренко, Владимир Рубанов

Научный рецензентАндрей Шелудяков

Графический дизайнКонстантин Кузниченко, Татьяна Козаревская

Редактор-корректорЕлена Рудакова

Вэб-дизайнМаксим Хохлов

Особая благодарностьАнастасия Тенько (NovStream)

Редакция выражает благодарность перечис-ленным ниже представителям компаний и организаций, материалы интервью и бесед с которыми были использованы при подготов-ке этого номера:

Сергей Рябов, начальник Отдела архитектуры и перспективных разработок Сберканка России

Андрей Кувалдин, руководитель проектов Отдела архитектуры и перспективных разработок Сбербанка России

Георгий Быстров, заместитель начальника управ-ления технических средств и телекоммуникаций Департамента сопровождения ИТ Сбербанка России

Гамид Костоев, директор по корпоративным ком-муникациям IBS Group

Татьяна Чернова, директор по рекламе и марке-тингу сети кинотеатров «КАРО Фильм»

Владимир Габрелян, технический директор Mail.ru

Анатолий Орлов, заместитель руководителя де-партамента разработки «Яндекс»

Роман Козлов, руководитель инфраструктурного отдела, «Нигма.РФ/itim.vn»

Алексей Царегородцев, директор по проблемам развития информационного общества Института современного развития


Словарь терминовБольшие данные Совокупности данных, размеры которых варьируются от нескольких

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

Hadoop-кластер Масштабируемый компьютерный кластер, созданный по образцу кла-стерной архитектуры Google (Google Cluster Architecture) и предназна-ченный для низкозатратной обработки слабоструктурированной инфор-мации.

Apache Hadoop Ядро семейства программных продуктов с открытым кодом, реализую-щих более эффективные методы анализа больших данных благодаря использованию кластеров, составленных из компьютеров массового использования.

Cascading Интерфейс между Hadoop и общепринятыми методами программирова-ния на основе Java, которые до этого не могли применяться в кластер-ных вычислениях.

NoSQL Класс нереляционных хранилищ данных и методик анализа этих данных, предназначенных для разнообразных типов слабоструктурированных данных. Многие из этих методик применяются в Hadoop-кластерах.

«Серые данные» Данные из многочисленных источников, не подвергавшиеся предвари-тельному форматированию или отбору для конкретных задач, но ко-торые, тем не менее, целесообразно исследовать с помощью методик анализа на основе Hadoop-кластеров.


Контакты 76

pwc.ru

Для получения дополнительнойинформации вы можете обратитьсяк следующим сотрудникамPwC в России*:

Наталья Мильчакова Партнер, руководитель практики по оказанию налоговых услуг компаниям сферы высоких технологий, коммуникаций, индустрии развлечений и СМИ Координатор Центра технологий и инноваций +7 (495) 967-6251 [email protected]

Дуглас Даунинг Партнер, консультационные услуги в области информационных технологий +7 (495) 967-6210 [email protected]

Вера Тоцкая Старший менеджер отдела маркетинга, Центр технологий и инноваций +7 (495) 967-6179 [email protected]

Анна Нечаева Младший менеджер отдела маркетинга +7 (495) 967-6062 [email protected]

Виталий ЛазоринЭксперт Центра технологий и инноваций+7 (985) [email protected]

Этот и другие номера российского издания «Технологического прогноза» вы можете найти на сайте www.pwc.ru/techforecast. На сайте из-дания вы также можете подписаться на элек-тронную рассылку журнала.

* «PwC в России» означает фирмы сети PwCIL, осуществляющие деятельность в России.

Комментарии, предложения?Посетите сайт издания www.pwc.ru/technologyforecast или отправьте письмо на электронный адрес [email protected].

Сеть фирм PwC предоставляет услуги аудита, налоговые и консалтинговые услуги, которые направ-лены на увеличение стоимости бизнеса клиентов. Более 161 000 человек в 154 странах мира объеди-няют свои идеи, опыт и решения, чтобы разработать новые подходы и дать клиентам практические советы. Более подробная информация — на www.pwc.ru.

© 2010 PwC. Все права защищены. Дальнейшее распространение допускается только с письменного разрешения PwC. Под «PricewaterhouseCoopers» и «PwC» понимаются фирмы, входящие в глобальную сеть фирм PricewaterhouseCoopers International Limited (PwCIL). Каждая фирма сети является самосто-ятельным юридическим лицом и не выступает в качестве агента PwCIL или любой другой фирмы сети. PwCIL не оказывает услуги клиентам. PwCIL не несет ответственность за действия или бездействие любой фирмы сети, не может контролировать профессиональные суждения, высказываемые фирмами сети, и не может никаким образом связать их каким-либо обязательством. Ни одна из фирм сети не несет ответственность за действия или бездействие любой другой фирмы сети, не может контролиро-вать профессиональные суждения другой фирмы и не может никаким образом связать другую фирму сети или PwCIL каким-либо обязательством.

Documents

Технологический прогноз. БОЛЬШИЕ ДАННЫЕ: как извлечь из них информацию