Все мы любим посмеяться над дремучим legacy на Java, которое якобы живёт в банках. После прочтения этой статьи у вас появится понимание другой грани этой истории. Оказывается, конкретно в Сбербанк-Технологиях есть целые большие отделы, занимающиеся прорывными технологиями и направлениями, включая Big Data и Machine Learning. Более того, скоро мы можем оказаться в мире, где Machine Learning встроен чуть ли не в каждую кофеварку. К добру или к худу, но Internet of Things, следящий за нами тысячью глаз из каждого банкомата, — куда более актуальное прочтение этой старой шутки.

Как вы, наверное, заметили, я пишу на Хабре про виртуальные машины, внутренности OpenJDK, JVM и другую системную разработку. Почему эта статья — о банковском софте? Потому что это актуально как никогда. Вот представьте, вы такой весь в белом, дважды Data Scientist и четырежды важный гуру JIT-компиляции. Что дальше? Кому всё это может быть нужно прямо здесь и сейчас? Часто слышу рассуждения на тему: «Вот сейчас ты ковыряешься в своей любимой Java, а завтра никто тебя на работу не возьмёт». Это очень забавное и опасное заблуждение. Благодаря таким товарищам, о которых пойдёт речь в этой статье, работа у нас будет всегда.

Конечно, на слово мне никто верить не должен, поэтому специально для Хабра я сорвался на самолёт в Москву, чтобы пообщаться с начальником отдела разработки спецпроектов в Сбербанк-Технологиях. Вадим Сурпин потратил на меня чуть больше часа, а в этом интервью будут только самые важные мысли из нашего разговора. Кроме того, удалось уговорить Вадима подать заявку на участие в нашей конференции JBreak. Более того, Вадим — первый человек, который показался мне достойным инвайта на Хабр: vadsu (инвайт был честно заработан статьей про хакинг ChromeDriver).


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

— У нас центр компетенции по большим данным. Соответственно, занимаемся мы Hadoop, всем, что около него, и всем, что позволяет обрабатывать большие данные. Кроме Hadoop, это key-value хранилища, распределённые текстовые индексы, вспомогательные координаторы Zookeeper, MPP-решения из орбиты Hadoop, вроде Impala (если это можно назвать полноценным MPP — но, тем не менее, она на это претендует). Это, конечно же, Spark, Kafka и прочие популярные вещи. Это технологически.
Идейно же, Hadoop для банка— платформа, позволяющая обрабатывать большие объемы внутренних и внешних банковских данных. На конференциях часто рассказывают о ППРБ, и это транзакционная система. Hadoop — система аналитическая. ППРБ обрабатывает более оперативную информацию, а Hadoop — накапливает весь исторический объем информации. Это и данные о транзакциях, и какие-то клиентские данные, счета, операции. Это касается и физлиц, и юрлиц. Существует и ряд внешних данных, например, Spark Interfax для корпоративного применения, какие-то источники кредитной истории и так далее. Все эти данные агрегируются в Hadoop, чтобы строить профили клиентов, принимать решения для розницы о маркетинговых акциях, вычислять вероятность оттока клиентов. Чтобы интеллектуальным образом строить разные графики, например, графики работы подразделений. Недавно мы построили модель, позволяющую определять сбои в мобильном приложении Сбербанка по отзывам на Google Play — то есть стали делать анализ произвольного текста. Экспериментировали с анализом изображений — это нужно, чтобы лучше определять клиента банка по видео или по фото с камер. У банка много таких направлений.

Кроме того, есть инфраструктурный хардкор, когда нам нужно интегрироваться с другими банковскими системами. Когда нужно в WAY4, SmartVista или ЕКС закачать огромный объем данных в realtime-режиме. То есть это некая комбинация Big Data и high load. Здесь возникают интересные чисто технологические вопросы. Если обычно на всех конференциях говорят, что Big Data и машинное обучение — это одно и то же, то тут — нет. По пути построения enterprise-платформы мы поняли, что есть множество чисто технических задач, которые из коробки не решены в мире Big Data. В частности, это простая задача — получить поток реальных данных на Hadoop. Но на потоках размерами всего лишь единицы терабайтов в час она из простой превращается в отдельную большую задачу. Обеспечить realtime-доступ к данным на Hadoop — еще одно направление, которое не очень покрыто готовыми решениями.

— Подожди. Hadoop же изначально не был предназначен для realtime. Это разве не batch processing?

— Большие данные развивались очень интересно. Вначале это было просто распределение данных по большому количеству серверов. И аналитические системы — построение профилей и т.п. Всё это началось с поиска, индексации сайтов, и это действительно оффлайн. Сейчас же, и это видно по многим публикациям, всё больше движется в сторону потоковой обработки информации. Это ближе к realtime. Когда говорили про Big Data, всегда маячила тема обработки логов — то есть текстовой информации. Есть распределенные индексы типа Elastic, Solr и так далее. Это тоже Big Data, но она риалтаймовая. То есть я бы не сказал, что Big Data — это обязательно batch.

— Ага. И как вы справляетесь с realtime в Hadoop?

— Делим realtime на потоковую обработку и на realtime-доступ. Что имеется в виду под realtime-доступом? Мы можем батчем обработать данные, затем — обеспечить к ним точечный доступ. В основном, это key-value хранилища и вышеприведенные текстовые индексы типа Elastic. Они служат как финальные витрины. Понятно, что доступ к таким витринам может осуществляться только по заранее выбранному ключу либо набору ключей в случае полнотекстового поиска. Как известно, в enterprise-среде многие заказчики хотят именно SQL-доступ к данным.

— /*тяжело вздыхает/*

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

— А в результате получаются какие-то фреймворки или это ad-hoc решения, просто по месту возникновения проблемы?

— В том-то и дело, что мы стараемся делать фреймворки. Когда мы смотрим на рынок, что вообще в мире делается — в целом, по крупным конференциям вроде Strata, видно, что люди делают решения «по месту». В банке же, при наличии ДКА…

— Департамента Корпоративной Архитектуры?

— Да. При наличии ДКА всегда есть желание сделать на века, высечь в камне. Поэтому нам приходится находить способы сделать более-менее общее решение. Не всегда получается скрестить два разных мира SQL и NoSQL, но какие-то более-менее общие решения стараемся делать.

— Сколько это будет примерно жить? Год, два, три, десять? Какие планы?

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

— А какой фронт больше всего движется вперед, переделывается, еще что-то?

— Сейчас мы работаем для платформы, для «Облака Данных» — так называется Hadoop в банке. Надо сказать, что название «облако» вначале нам самим казалось странным. Потому что «облако» — это известные облачные платформы: OpenStack, Amazon и так далее. Поэтому казалось, что Hadoop — это не «облако». Тем более, Hadoop у нас на железе сделан. Само название «АС Облако Данных» надо понимать так: «данные как сервис». Не сама инфраструктура облачная, а скорее данные живут в облаке и могут быть предоставлены заказчику как сервис. Сейчас самая востребованная часть со стороны бизнес-заказчика — наличие всех банковских данных на одной платформе, чтобы была возможность проводить эксперименты, иметь лабораторию по работе с данными и иметь возможность данные интегрировать. То есть сопоставлять данные об одном клиенте, об одном событии из разных источников. Это для нас сейчас самый тяжелый фронт работ. Заполучить данные и интегрировать их вместе — это классическая задача хранилищ, но и на Hadoop она тоже возникает.

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

— А про matching данных — это Лабиринт?

— Нет, Лабиринт — это графовая платформа. Она в себя впитывает графовое представление заранее проматченных данных. То есть matching является только частью Лабиринта. Частью подготовки данных для укладки в граф. Я даже не знаю, как сказать… Это не весь Лабиринт, но это очень важная его часть. Граф полезен для того, чтобы между различными объектами, субъектами, явлениями выявить связи.

— Давай по порядку. «Лабиринт» — это название проекта, так?

— Вообще, проект начинался под кодовым названием У1.

— У1? Звучит как название самолёта.

— Изначально заказчиком этого проекта было подразделение УРПА — Управление по Работе с Проблемными Активами, то есть — поиск людей, которые не хотят платить по кредитам. Отсюда буква «У» и «1» — первый проект для УРПА. Дальше мы поняли, что это применимо не только для этого заказчика. Через какое-то время в среде наших заказчиков родилось название «Лабиринт». Почему именно «Лабиринт»? Сейчас уже сказать сложно, но, наверное, потому что по графу связей людей и организаций можно было в графическом интерфейсе ходить, перемещаться, открывать новые взаимосвязи, и это было похоже на нахождение пути в лабиринте.

— А ещё это круто звучит.

— Да. Еще были и другие названия у этой системы, но прижилось именно «Лабиринт».

— Расскажи подробней, какие бизнес-сценарии она решает?

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

— Скрытый холдинг? Я помню твои слайды из Иннополиса.

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

— Как это происходит с точки зрения компании? Тебе однажды утром звонит сотрудник Сбера и говорит: «А знаете, мы обнаружили, что вы работаете в одной цепочке!» Звучит шокирующе.

— Вот как это происходит, к сожалению, не могу сказать. Как это бизнес по факту применяет, скрипты разговора — к сожалению, не знаю. Могу лишь предположить.

— То есть вы бизнесу просто предоставляете информацию.

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

— С точки зрения пользователя этой системы, как выглядит результат ответа при обнаружении такой цепочки? Какой-то текстовый файл просто генерируется с перечислением элементов цепочки?

— Нет. Это графическое изображение. Обычно изображается некая компания и вокруг неё — облако взаимосвязанных клиентов. Если аналогичную задачу рассматриваем для крупных корпоративных клиентов, то там сразу понятно — откуда зайти, с каких компаний. Берем самых крупных клиентов, ищем их контрагентов, с кем они работают. Зная род деятельности крупного клиента, можно легко додумать направление каждой производственной цепочки. Кто ему что поставляет, кому они какие услуги оказывают. Графически это выглядит как клиент, и вокруг него — такие расходящиеся лучи, и это — контрагенты. Соответственно, обычно заходят по фильтру, начиная с крупных клиентов. И от них дальше разворачивают все цепочки.

— Это именно снапшот или можно во времени что-то отследить? Рост компании или, наоборот, — её крах?

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

— Получается, у вас есть большое количество прототипов и экспериментов?

— Да. Действительно, сейчас платформа Big Data развивается таким образом, что на ней делается много экспериментов. Классический enterprise, банковское программное обеспечение, развивается так: покупаем коробку, она выполняет функции, и всё это просто отдается клиенту. Big Data работает немного по-другому. Здесь мы пытаемся найти в лаборатории те функции, на основе которых потом можно сделать некую коробку для внутреннего использования. Само по себе изготовление коробки — это процесс более долгий, но зачастую, на основании результатов экспериментов, бизнес может получать выгоды прямо сейчас.

— Кто этим занимается? Этот штат состоит из исследователей, разработчиков? Или наоборот, две трети — аналитики, и при них два программиста? Как это выглядит?

— Что касается именно экспериментов, то здесь большая часть народа — это аналитики и data scientists, и немного меньше — программисты. То есть разработчики в процессе экспериментов привлекаются, когда, например, нужно обработать чрезвычайно большой объем данных, с чем аналитик или data scientist самостоятельно справиться не может. А вот исследования и взаимосвязи — это аналитики и data scientists. И это не обязательно сотрудники нашего подразделения. Зачастую это сотрудники бизнес-блоков и так далее.

— Какими инструментами пользуются data scientists в ходе своих работ?

— Они, как правило, предпочитают Python, Jupyter Notebook, многочисленные питонячьи библиотеки, которые все data scientists используют по всему миру. Что касается Big Data — это PySpark (API питона к Apache Spark), Hive (для того, чтобы подготовить данные), иногда это бывают очень кастомные интересные решения. Например, однажды мы внутрь Spark встроили xgboost и запускали его распределённо. Из коробки спарковские библиотеки машинного обучения давали неплохие результаты, но xgboost на небольших данных работал лучше. Пришлось взять лучшее из двух миров.

— То есть вы можете пользоваться любыми инструментами? У вас нет некоего установленного набора тулов?

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

— А с точки зрения архитектуры, кто её определяет? Вот, например, архитектуру Big Data-решений?

— Здесь есть традиционная организационная структура, когда есть корпоративные архитекторы, которые рисуют архитектуру, которую вроде как дальше нужно реализовывать. На практике, конечно, учитывая, что в Big Data постоянно что-то меняется, постоянно меняются тренды, что-то уходит на второй план, это не всегда так. Если совсем уж закопаться, map-reduce в какой-то момент практически полностью ушел с радаров как технология непосредственного использования программистами. По факту получается, что корпоративные архитекторы плотно работают с архитекторами, которые у нас в центре компетенций, и с тимлидами. По большому счету, многие решения принимаются на уровне тимлида. Изначально инициируются тимлидом, затем с заинтересованными людьми всесторонне обсуждаются.

— А что такое Центр Компетенций?

— Это оргструктура, которая фокусируется на определенных технологиях. Например, у нас это большие данные. В ППРБ есть всё, что вокруг Grid Gain. Есть ЦК, занимающиеся процессингом, CRM и так далее. Есть сосед наш — центр компетенций по BI, это классическая такая SQL-аналитика. ЦК — это некое направление деятельности: или по сути этой деятельности, или по технологической платформе.

— Кстати, если уж затронули вопрос оргструктуры, вас как-нибудь коснулась Agile-трансформация?

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

— В обычном аджайле есть идея о кроссфункциональных командах. Смогли ли вы её воплотить?

— Уточни, о каком именно воплощении идет речь?

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

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

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

— Думаю, да.

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

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

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

— Какой размер спринта?

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

— Тестирование входит внутрь спринта или это отдельная фаза?

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

— Мы немного отвлеклись — обсуждали Лабиринт и переключились на процессную часть. Расскажи, у Лабиринта как устроена архитектура?



— Лабиринт — это один из первых наших проектов, и на нём мы прошли по целому полю граблей. Вначале у нас была уверенность, что среди огромного количества Big Data-решений должна быть зрелая графовая база данных, раз уж мы разрабатываем граф. Мы начали с изучения, что есть на рынке. В первую очередь, open source, но и ряд закрытых коммерческих решений тоже посмотрели. Поняли, что большинство графовых баз данных отваливается уже на этапе заливки в них необходимого объема данных. Если берем объемы данных размером с клиентскую базу Сбербанка, сколько это? Примерно вся Россия. По порядку величины, если учесть счета иностранных граждан, приезжающих из дружественных стран, и какие-то счета, оставшиеся с давнего времени, и добавить юрлиц с их контрагентами — получается всё равно целая страна. Сотни миллионов узлов. Если берем более-менее среднюю статистику по количеству социальных связей человека… По людям проще оценить. Можно посмотреть примерно, сколько у человека в соцсети друзей. Когда мы стали проводить исследование, поняли — в среднем сотня точно есть. Количество связей на два порядка больше количества узлов. Если мы не берем ещё финансовые транзакционные связи между организациями, там денежных переводов между некоторыми организациями и физлицами происходит намного больше. Взять, например, коммунальные платежи. Такие объемы данных ни одна из существующих баз данных (или, по крайней мере, существовавших на тот момент, два года назад) не могла переварить.

— Не могла. В прошедшем времени. То есть сейчас уже кто-то может?

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

— Ты про что сейчас?

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

— Понятно, у создателей совершенно не такие масштабы и задачи, как у Сбербанка.

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

— При этом оно не просто ищет по графу, а еще и пытается матчить данные?

— Матчинг данных мы делаем предварительно. Сначала данные из разных источников проматчиваем, причем матчинг в нашей терминологии — это поиск одинаковых сущностей в разных источниках данных. Есть ещё поиск скрытых связей. Эта функция также выполняется перед построением графа. Что такое «скрытые связи»? Например, такая ситуация зачастую неочевидна: если два человека в одно и то же время в одном ресторане расплатились картами, то с некой вероятностью они друг друга знают — они вместе ужинали. Конечно, в нашей стране это больше касается бизнесовых связей. Поскольку в случае связей вне бизнеса, как правило, всё оплачивается с одной карты :-) Если это произошло один раз — это случайность, если два раза — уже закономерность.

— И такие совпадения уже прямо сейчас можно отслеживать? Или это был просто пример?

— Это можно отслеживать. В торговых организациях у каждого терминала есть ID, и можно понять, что за транзакция происходила. Но это вычислительно очень непросто.

— Давай добьем вопрос про архитектуру. Значит, мы собираем все данные, предварительно матчим, и дальше что мы делаем?

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

— И где мы это храним, если нет графовой базы данных?

— Есть три хранилища. Текстовый индекс, Elastic или Solr (сейчас мы больше используем Elastic, но для наших задач разница небольшая — начинка примерно одинаковая), key-value хранилище (Сassandra или HBase, в зависимости от инсталляции) и своё собственное решение, которое в памяти выполняет графовые алгоритмы.

— После этого по этим данным можно с помощью какого-то Java API бегать и делать запросы, да?

— Есть API, и есть пользовательский интерфейс. Достаточно красивый сам по себе. Достаточно много копий было сломано на том, как графы показывать пользователю, учитывая их объём. Положим, мы приходим на какой-то узел-организацию, и у неё десять тысяч контрагентов. Пользователь хочет посмотреть контрагентов и жмёт кнопку «раскрыть». Понятно, показать десять тысяч организаций вокруг этой на экране — решение не очень правильное. И всё равно бесполезное, забьет весь экран. Соответственно, пытаемся при движении по графу использовать интеллектуальные подходы. Например, показывать первые 10-20-50-100 организаций, с которыми самые большие финансовые потоки с той организацией, от которой мы идём. То есть разработка самого UI — это тоже такой большой интересный кусок работы.



— Этот UI сделан на JavaScript или это десктопное приложение?

— Это JavaScript, браузерное приложение.

— А графики на чём делаете?

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

— Кто это делает? Это просто Java-разработчики или есть специальные продакт-менеджеры, дизайнеры?

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

— Насколько помню, у вас был ещё один проект, связанный с отрисовкой — Геомаркетинг.

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

— Давай по порядку. Что такое «Геомаркетинг 2.0»?

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

— Ты начал рассказывать про интернет вещей. При чём тут он?

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

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

— Но поскольку вы — Сбербанк, у вас эти данные всегда есть.

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

— В качестве датчиков используются только терминалы или ещё что-то?

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

— Не знаешь, те терминалы, которые в Московском Метро и Единые — это не Сбербанк?

— Сейчас терминалы в метро — это ВТБ, кажется.

— Жаль, ещё можно было бы с метро собирать графики наплыва людей.

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

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

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

— И это даже более важно.

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

— Расскажи, какой путь проходят данные от датчика?

— Я полезу немножко в те сферы, которые выходят за рамки Big Data, поэтому что-то могу сказать поверхностно. Есть терминал. Терминал может осуществлять операции онлайн и оффлайн. Соответственно, в какой-то момент времени информация о том, что человек воспользовался карточкой, с терминала или с банкомата передается в Банк. Эта информация передается в такую фронт-систему, из которой переходит в учётную систему. Из этой системы информацию получаем уже у нас в Hadoop. Соответствующим образом порезанную — никаких номеров карт и так далее здесь нет, здесь информация с некоторыми абстрактными идентификаторами.

— То есть она полностью обезличенная?

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

— Как это выглядит для пользователя?

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

— Как это сделано в плане архитектуры, технологий, что там используется?

— Ну, на бэкенде — Hadoop, огромная часть обработки данных — Spark с кастомными алгоритмами. Фронт, картография — это Leaflet, плюс геосервер на бэкенде (чтобы отдавать сами слои карты). Это облегченная версия, а есть еще более тяжелая, целевая, идеологически выдержанная.

— Кроме данных о клиенте, нужно сопоставить все это с географическими объектами, это тоже делается?

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

— Эти данные об адресах и прочем — собираете вы сами или какие-то подрядчики?

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

— Можно на этой карте как-нибудь разметить, что вот тут — железная дорога? Увеличить вес рёбер…

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

— Наверное, нам нужно сворачиваться, поэтому пару слов напоследок. Как в дальнейшем будут развиваться большие данные, направление супермассивов данных и так далее?

— Ну, я расскажу своё видение о развитии до сих пор, и, как мне кажется, это будет развиваться дальше. Технология больших данных чем интересна? В большой степени это open source. Соответственно, для крупных enterprise, которым, несомненно, является Сбер, такое массивное внедрение open source-технологий — это качественное изменение подхода к IT.

— К лучшему, худшему?

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

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

После наполнения Hadoop данными, думаю, опять всё переключится на продвинутую аналитику. Суть перехода от традиционных SQL-хранилищ к Hadoop, в том числе, и в том, чтобы можно было применять и более продвинутые методы анализа данных. Не просто SELECT сделать, а всё-таки подключить машинное обучение, применять нереляционные способы поиска, хотя бы те же полнотекстовые индексы, которые позволяют проще найти информацию во всём этом объёме. Это всё пойдет в сторону более глубокой аналитики — раз. И второе, то, где технологический процесс интересный — это realtime-обработка на Hadoop. Которая, думаю, будет развиваться просто в силу того, что с точки зрения банка есть потребность в ускорении процессов и в ускорении выдачи кредитов. Сейчас идут соответствующие инициативы, и они закатывают все IT-системы, в том числе — наш Hadoop. Это и мировая тенденция — на Big Data делать потоковые и более быстрые решения. Первой была техническая масштабируемость, а сейчас уже идут в сторону скорости. Мне кажется, как-то так.

— Насчёт тех проектов, о которых мы поговорили — о Лабиринте и Геомаркетинге. Какое у них будущее?

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

— Есть еще какие-нибудь интересные внутренние стартапы, какие-то новые начинания?

— Сейчас есть несколько интересных технических начинаний. Это realtime-обработка данных на Hadoop — каким образом можно к заранее подготовленным данным дать быстрый доступ? Пробуем различные способы инкрементальной обработки данных. Hadoop — да, это batch, но на больших объемах, оказывается, нецелесообразно пересчитывать все данные. Думаем, какие можно выработать паттерны, чтобы делать инкрементальный анализ данных.

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

Из проектов, которые в технологических трендах — проект по построению инфраструктуры выкатывания моделей машинного обучения на Hadoop. Сейчас как делается в других компаниях — кто-то написал конкретный код, выложил его, задеплоил на HDFS, запустил спарковскую джобу — ура, работает! Чем это отличается от Сбера? Если модель влияет на извлечение финансовой прибыли, прежде чем запускать её на регулярной основе, её кто-то ревьюит. Она может существовать в нескольких версиях. Мы пытаемся для всей этой темы моделирования создать некий source control и devops stack.

— Если внезапно нашим читателям с Хабра захочется поучаствовать во всём этом хайтеке, о котором ты рассказал, кто нужен вашим командам (если кто-то вообще нужен)?

— Сейчас, как всегда, нужны опытные Java-разработчики, поскольку мы создаем много инфраструктурных продуктов. Нужны аналитики данных и аналитики супермассивов. Спрос на них не такой большой, как на разработчиков, но, тем не менее — да, это тоже очень востребованная специальность. Это те, кто занимаются машинным обучением и анализом данных. Хочу сразу сказать, что нам нужны люди, которые умеют работать и просто с SQL, и строить модели. То есть такой гибрид — аналитик плюс data scientist. Очень часто приходят люди, которые берут заранее подготовленные данные (как на многих конкурсах делается) и на них строят модель. Но сами не умеют извлечь данные из промышленных систем, почистить их. Это — проблема. Когда для человека модельку построить интересно, а подготовить для неё данные — считает, что кто-то другой должен делать. Наша особенность в том, что извлекать данные нужно уметь самостоятельно.

— Вообще неплохо быть самостоятельным и уметь достигать реального бизнес-результата.

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

— А джавистам что нужно знать-уметь?

— В идеале, конечно, экосистему Hadoop, Spark, Hive, те решения, что мы только что обсуждали — HBase, Cassandra, Solr, Elastic и много всего, что есть в любом дистрибутиве Hadoop. Если человек всего этого на входе не знает, но хочет обучиться и при этом имеет хороший опыт коммерческой разработки на Java — это нормально. Люди с опытом достаточно быстро осваивают новые технологии и вливаются в команду. Взаимодействие с опытными коллегами мы обеспечим — у нас сейчас уже достаточно много опытных людей (большинство из которых когда-то пришло с нулевыми знаниями по Hadoop на входе).

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