Концепция big data, возможно, породит новую технологическую революцию, подобную той, что была произведена около двадцати лет назад с появлением баз данных в архитектуре «клиент — сервер». Примерно так можно выразить основную мысль записи в блоге Максима Смирнова, руководителя департамента IT-архитектуры компании «Вымпелком».

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

Именно на этих принципах построена концепция «больших данных», изначально зародившаяся в недрах лабораторий Google и описанная специалистами этой компании в 2004 году. Чуть позже эти принципы облекли форму в проекте Hadoop — наборе инструментальных сред, создаваемых на базе свободного ПО в рамках Apache Software Foundation. Логотип Hadoop — желтый слон — стал настоящим символом больших перемен в «больших данных». Как пишет Максим Смирнов, на первой в России тематической конференции Big data 2012 слово Hadoop упоминали все вендоры. «Одни говорили о том, как развернуть Hadoop на своем оборудовании, другие намекали, что портируют Hadoop в свою операционку, третьи рассказывали, как «прислонить» их продукты к Hadoop сбоку, сверху, снизу, в общем — со всех сторон», — иронизирует он.

Сами вендоры пока больше говорят о применимости big data для анализа соцсетей, однако есть и более радикальные мнения. Так, Люк Лонерган (Luke Lonergan), CTO и основатель компании Greenplum, вошедшей теперь в состав EMC, рассказал в интервью порталу FutureBanking.ru, что благодаря big data речь идет о возможности не внедрять и не осваивать CRM-системы. «Есть возможность перешагнуть через этот этап. Наши системы хранения и обработки сверхбольших данных не требуют такого уровня структурирования. Многие системы CRM стоят очень дорого, а внедрение их может продолжаться до 3–5 лет. Я бы категорически настаивал на том, чтобы вы не внедряли такие системы, если, конечно, они у вас еще не установлены», — говорит он.

«БО» провел опрос основных вендоров, представивших на данный момент решения для работы с big data (SAP, IBM, Oracle, Teradata, EMC). HP и Microsoft на запрос «БО» не ответили.

Оптимисты говорят, что big data может помочь не только в решении несколько абстрактных пока задач обработки огромных объемов внешних данных, но и в выстраивании новой архитектуры для работы с уже имеющимися корпоративными данными. Есть даже мнение, что с появлением этой технологии отпадает необходимость в CRM-системах, классических хранилищах данных и т.д. Каков взгляд вашей компании на применимость технологий big data, как они вписываются в стандартную архитектуру банка и заменят ли со временем классические системы сбора и обработки данных? Учитывая, что big data реализуется на простых серверах, снимая зависимость от дорогих hi-end-решений, не наступают ли вендоры себе же на хвост, развивая инструменты на основе этой концепции?

Технологии big data не могут заменить традиционные реляционные базы данных (СУБД) для задач, которые решают CRM или АБС. Но они могут служить хорошим дополнением для хранилищ данных. Например, Hadoop отлично подходит для задач хранения и первичной обработки (фильтрации, агрегации) огромных объемов исторических, неструктурированных и других данных, позволяя решить их во много раз дешевле, чем при использовании обычных СУБД. Но это не отменяет необходимости в традиционных хранилищах, так как реляционные СУБД обгоняют Hadoop, например, по аналитическим возможностям, возможностям обеспечения быстрого отклика на запросы пользователей и т.д. Таким образом, предварительная обработка данных может производиться в Hadoop, а отфильтрованные и агрегированные данные могут передаваться в традиционное хранилище, где с ними будут работать пользователи.

Технологии big data решают многие сложности: объем данных «перерастает» возможности масштабирования имеющегося решения; часто возникают новые бизнес–задачи или ужесточаются требования к этапам обработки данных: не только к аналитике, но и загрузке, хранению, поиску, обмену данными или их визуализации. Например, нужно пересчитывать кредитоспособность заемщика в зависимости от активности в социальных сетях и других событий.

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

Что касается влияния big data на hi-end решения... Прогресс не остановить, и в таких условиях для вендора наиболее важно представить целостное видение своего предложения. В данном случае mid- и high-end решения EMC дополняют открытые решения big data, такие как Hadoop или Greenplum Community Edition, в части Enterprise-функций, где важны надежность, катастрофоустойчивость, интеграция.

Новые системы для решения задач анализа больших объемов данных — это все же не «убийцы» существующих хранилищ данных или CRM-систем, а их логическое продолжение. Если мы говорим про решение SAP HANA, в основе которого лежит концепция хранения и обработки данных в памяти (in-memory), то это просто глоток свежего воздуха для существующих систем, который поможет им заработать с новой силой и скоростью.

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

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

Для работы с большими объемами данных нужны решения, основанные на принципе распределенных вычислений и параллельной обработки данных. Помимо привычной формы представления данных в виде таблиц появилась потребность в работе с полуструктурированными данными: логи и контент интернет-ресурсов, текст и т.п. Реляционные СУБД и SQL для этого малоэффективны.

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

Teradata видит перспективы в анализе полуструктурированных данных. У нас есть решение, позволяющее совмещать работу как с таблицами, так и с данными произвольного формата. Мы предоставляем пользователям оба подхода с одним названием SQL-MapReduce. Любая обработка подразумевает параллелизм и использование архитектуры shared-nothing.

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

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

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

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

На практике крупнейшие банки США и Европы применяют технологии big data, и в частности, Hadoop для решения таких задач как: анализ рисков (кредитных, рыночных), построение системы противодействия фроду, анализ совершенных сделок, анализ web-логов, фрод-аналитика, построение системы внутренней безопасности.

Пожалуй, наиболее востребованный для российских банков сценарий — это создание или оптимизация работы хранилищ и витрин данных. Наверняка многие испытывают с этим проблемы: загрузка данных в хранилище не выполняется в срок, вовремя не формируется отчетность, нет возможности анализировать данные в реальном времени либо данные еще не загрузились в витрины; или нужно согласовывать доработки, чтобы нужные данные стали доступны для BI инструментов. В таких обстоятельствах и может помочь СУБД Greenplum.

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

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

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

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

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

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

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

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

Концепцию big data вполне можно реализовать с помощью свободного СПО — собирать данные с помощью Hadoop, помещать их в СУБД Cassandra или HBase, а для упрощения работы использовать фреймворки вроде Apache Hive или Apache Pig. Требования к оборудованию тоже невысоки — достаточно серверов начального уровня, даже старых. То есть, по сути, любой банк может начать реализовывать big data с минимумом затрат. Если это так, то «зачем платить больше»? Какую функциональность добавляют ваши решения, в чем они лучше свободных аналогов и решений конкурентов?

Действительно, в основе big data решений чаще всего лежит СПО. Однако стоимость лицензий – это только одна из составляющих цены решения. В случае big data необходимы очень хорошие и дорогие навыки для того, чтобы построенная система, состоящая из десятков и сотен узлов, была эффективна. Ведь когда речь идет о сотнях терабайт или даже петабайтах данных, неэффективность системы может выливаться в лишние часы обработки данных во время запросов. Именно поэтому Oracle предлагает готовый программно-аппаратный комплекс Oracle Big Data Appliance , который уже оптимизирован для максимальной эффективности работы Hadoop и ориентирован на получение заказчиком максимальных преимуществ от использования «больших данных» для бизнеса. Приобретая наше решение, заказчик экономит, например, на том, что ему не нужно держать в штате экспертов по построению и обслуживанию кластера. Оптимизированный программно-аппаратный комплекс сразу готов к работе.

Не все требования можно удовлетворить с помощью СПО. Например, СУБД Greenplum обеспечивает высочайшую скорость загрузки и обработки данных, система хранения Isilon — масштабируемые и надежные файловые системы петабайтных масштабов.

Подход EMC позволяет максимально использовать существующие наработки и квалификацию персонала. Например, если в организации существует обширный опыт использования реляционных баз, то задачи big data можно решать с использованием технологии Greenplum DCA, предоставляющей интегрированный функционал реляционной СУБД и Hadoop. Существующие хранилища и витрины данных, которые «переросли себя», можно мигрировать на СУБД Greenplum. При этом SQL-приложения, такие как BI и отчетность, будут работать с минимальными изменениями.

EMC предлагает не только ПО и сервера. В компании существует услуга Analytics Lab. Заказчик, работая с исследователями данных EMC, получает необходимые знания по методам и технологиям big data, общее понимание, какие бизнес–ценности можно извлечь из имеющихся данных, как сделать их доступными для продуктивной работы.

Выбор между использованием промышленных решений (пусть даже на базе open source) и СПО во многом зависит от критичности, ответственности и масштаба решаемой бизнес-задачи. Если речь идет о хранении клиентской информации крупного банка, то на первый план встают такие факторы, как надежность решения, поставщика, гарантия соблюдения SLA, безопасность и т.п. Для решения таких задач банки, как правило, используют промышленную поддерживаемую и развивающуюся платформу. Именно поэтому решения Teradata успешны в этом сегменте. С одной стороны, это инновационные технологии. С другой — стабильная компания и решения, доказавшие свою эффективность в ходе многочисленных внедрений и имеющие минимальные риски.

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

В IBM работа над технологиями в концепции big data началась еще в 2002 году. Сегодня мы находимся на высоком уровне понимания этой задачи, обладаем архитектурами и технологиями, которые позволяют исполнить «мечту руководителя» — обеспечивать поддержку принятия решений на основе всех цифровых данных, доступных компании, в любых объемах и любого типа, в режиме реального времени и в результате глубокого исследования данных. Ключевая линейка решений IBM big data — технологии IBM Infosphere Streams (потоковая аналитическая in-memory обработка данных в режиме реального времени) и хранилище сверхбольших наборов данных IBM BigInsights.

На Западе есть множество стартапов-интеграторов, таких как Cloudera, занимающихся адаптацией концепции «больших данных» для решения конкретных задач бизнеса. Как строить проект внедрения решений big data, есть ли в России интеграторы, которые умеют это делать и не будет ли слишком высока стоимость владения с учетом дефицита экспертизы на рынке?

Oracle big data Appliance поставляется с дистрибутивом Hadoop как раз от компании Cloudera. Трудности внедрения проектов по big data, конечно, связаны с тем, что у заказчиков с опытом работы с реляционными СУБД обычно нет опыта работы с Hadoop и необходимо обучать специалистов. Однако в данном случае затраты на обучение не будут сильно отличаться от затрат на изучение любой другой технологии, например, СУБД, а если задача заказчика позволяет использовать, например, Hive — «эмулятор» реляционной СУБД над Hadoop , то может оказаться, что освоение новой технологии произойдет очень быстро, так как позволяет использовать существующий опыт и наработки. Hive позволяет писать SQL запросы к данным, лежащих в кластере Hadoop. Для России тема big data еще довольно нова, но мы ожидаем появления множества интеграторов с опытом работы с big data-техно­ло­ги­ями уже в ближайшем будущем.

Внедрение технологий big data может происходить на разных уровнях. Например, CIO может вести проект по консолидации файловых хранилищ на базе Isilon, в то же время бизнес может спонсировать решение по анализу имиджа компании в социальных сетях на базе Hadoop.

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

Что касается стартапов и интеграторов на российском рынке, то сейчас ведутся проекты по внедрению решений big data. Такие решения встречают заметный интерес со стороны заказчиков, многие выполняют пробные проекты. Как следствие, будет расти компетенция на стороне системных интеграторов, стартапы будут находить свои ниши, и в ближайшие 1–3 года портфель предложений на рынке станет масштабным.

Заключение

Как видно, большинство вендоров действительно пришли к выводу, что «прогресс не остановить», и стараются предложить свои решения класса Enterprise, конкурирующие с проектом Hadoop или дополняющие его. В то же время большинство из них не видит в big data «прорыва» в части архитектуры корпоративных IT. Правы они или нет — время покажет.

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

Для big data достаточно отечественных специалистов хорошего среднего уровня без степени MBA и обычных компьютеров по 150 долларов за системный блок

Александр Витязь, руководитель Центра электронного бизнеса и заместитель председателя правления ПриватБанка рассказал «БО», что банк активно работает с инструментами big data, основанными на открытом ПО, что позволяет экономить миллионы долларов и десятки тысяч человекочасов, которые иначе пришлось бы потратить на приобретение и обслуживание решений крупных вендоров. «Чтобы внедрять тяжелые решения, нужны сверхдорогие люди, желание платить много денег поставщикам решений и делать все это годами, — говорит Александр Витязь. — С теми инструментами, которые мы используем, достаточно отечественных специалистов хорошего среднего уровня без степени MBA, а в качестве серверов задействовать обычные компьютеры условно по 150 долларов за системный блок. Источником вдохновения для нас служат архитектурные решения Google и Facebook».

ПриватБанк использует частное облако на основе свободного ПО OpenStack Swift для формирования «облачных» выписок, собирая в нем всю информацию о действиях клиента и анализируя ее в режиме реального времени. Также банк анализирует общение специалистов с клиентами в чате, используя для этого СУБД MongoDB, расположенную в «облаке» Amazon S3, и язык Erlang. Банк пытается анализировать и звуковые записи разговоров, но, по словам Александра Витязя, это пока получается плохо, поскольку технологии преобразования речи в текст для русского языка еще недостаточно развиты. Это одна из причин, почему банк уже 11 лет использует для общения с клиентами чат. Однако глава центра электронного бизнеса надеется, что через год-два технологии дозреют и можно будет столь же легко анализировать голосовые разговоры операторов. В итоге все собираемые из разных источников данные помогают банку более эффективно бороться с фродом, улучшать CRM и usability.