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



Как быстро сосчитать сумму чисел от 1 до 100? Согласно легенде, первым эту задачку решил великий немецкий математик Карл Фридрих Гаусс, еще будучи школьником. Он заметил, что попарные суммы с противоположных концов одинаковы: 1+100=101, 2+99=101 и т. д., и мгновенно получил результат 50х101=5050, продемонстрировав замечательные аналитические способности.

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

Строить финансовые прогнозы, создавать аналитические отчеты, анализировать тренды и риски без внедрения решений Big Data – это то же самое, что считать сумму чисел от 1 до 100, поочередно складывая числа. Пилотный проект ГАУСС (GAUSS, Global Transaction Business Analytic Union Source & System), запущенный в Департаменте транзакционного бизнеса ВТБ в начале этого года, помогает собрать воедино всю информацию из различных базы данных банка и автоматизировать работу с ней.

Что такое ГАУСС XXI века?

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

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

Дальше планируется развивать проект, расширяя базу данных за счет добавления статистической информации из всех возможных источников. ГАУСС должен стать основой для построения единого корпоративного «озера данных» (Data Lake), куда всякий раз можно будет «нырять» за информацией, которая важна в данный момент.

Однако сфера применения проекта ГАУСС гораздо шире, чем простое создание отчетов. Мы надеемся, что очень скоро с его помощью можно будет:

· оценивать различные риски (кредитные, клиентские, партнерские);
· выявлять мошеннические схемы;
· моделировать целевые коммерческие предложения;
· работать с аналитической системой Microsoft Business intelligence и пр.

Как работает ГАУСС?

Работая над проектом, мы сознательно отказались от использования коммерческих решений. Гаусс построен на стеке Hadoop / Hive / Ambari / Oozie / Spark / ORC / YARN, а для построения витрин данных мы используем реляционную базу данных PostgreSQL, которую мы считаем ведущей «открытой» реляционной СУБД в мире. Впрочем, вместо PostgreSQL можно использовать любую другую БД без ущерба для работы системы.

Из-за огромного количества постоянно поступающей информации и появления новых способов ее анализа любые проекты Big Data не могут быть решены с применением типовых шаблонов, это всегда новая комплексная задача. Поэтому мы построили стройную многоступенчатую архитектуру загрузки RAW информации от всех источников, далее агрегации, обработки и обогащения этих данных, а уже после подготовки финальных OLAP-кубов данных и витрин представления информации. Для решения задачи по корректному представлению данных были разработаны гибкие механизмы по маппированию исходных данных с целевой информацией, системы по проверке качества (Data Governance) сформированной информации, а также механизмы по получению детальной информации по агрегатам (data drilldown). Это позволяет безболезненно менять направление работы по ходу реализации проекта, адаптироваться к изменениям. Система ГАУСС разрабатывается по Agile/Scrum методологии, которая позволяет принимать во внимание новые требования бизнес-заказчиков, полученные отзывы, поступающие данные и при этом нацеливать каждого члена команды на достижение результата. Ведь когда работаешь с Big Data, все время возникают новые гипотезы относительно того, как можно использовать спрятанную в петабайтах «озера данных» информацию.

Комментарии (17)


  1. lexnekr
    27.09.2017 12:11
    +12

    Бли-бла-бла. Где техническое мясо?
    Понятно что Костину и Дергуновой показали крутые скрам-доски ребята, приехавшие в офис на гироскутерах. Но это Хабра, а не корпоративный портал Группы.


    1. SLASH_CyberPunk
      27.09.2017 12:20
      +5

      Нет там подробностей, у группы компаний ВТБ почти все, что касается данных, сидит на аутсорсе…


    1. VTB Автор
      27.09.2017 21:41

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


      1. VTB Автор
        27.09.2017 22:07

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

        Прикладная архитектура чётко разделена на view и service слои, причём view делали на 2-м Angular. Отдельно была построена схема по интеграции с AD Банка.
        Основная сложность была в том, что нужно было сделать интеграцию почти со всем банковским контуром для загрузки RAW данных для проведения нужной аналитики.

        Интеграцию с источниками пришлось делать делать, обойдя все legacy грабли, так как помимо интеграции с JMS, пришлось делать интеграцию и по файлам.

        В итоге загрузку данных распределили по четырём слоям: Staging, Historical (храним предыдущие версии + историю по справочникам), отдельно выделен слой по Data Quality. Для того, чтобы оперспечить подготовку витрин данных и отчётов логично сделаны Presentation (на Hive) и Access layer (на Postgres). Это позволило решить пробблемы с доступом большого количества пользователей к системе отчётов.

        По движку pipline отдельно делали интерйесы для мобильных устройств и Web на Ангуляре. Здесь реаллизован микросервисный подход. По сути ничего нового и прорывного здесь не было реализоывано, основная фишка в том, что это вывело систему из стантартного DWH в ПО, где мы не только получаем отчёты, но и можно делать процессы, связанные с жизненным циклом сделок, обогащая данные по отчётам (добавили ещё дополнительного прикладного смысла).

        Основные проблемы и вопросы, конечно, были связаны с обеспечением качества данных и контролем их чистоты. Для этого и делали 4 уровня загрузки / агрегации / обогащения данных.


        1. Yo1
          28.09.2017 10:26

          да, было бы интересно по структурам данных, RAW в какие-нибудь star схемы грузятся, vault 2.0? OLAP это реально какой-то OLAP?

          подготовку витрин данных и отчётов логично сделаны Presentation (на Hive)

          а движок у Hive какой, Tez?


          1. VTB Автор
            28.09.2017 14:19

            Да, Tez, плюс для управления кластером используем YARN и Spark для управления обработкой данных.


  1. Yo1
    27.09.2017 12:47
    +1

    как вы субмитите Spark джобы, в режиме yarn-cleint? через spark-submit скрипт или как-то по другому? типа RETS сервисы аля apache livy?
    кластер это Oracle BigData Appliance, что был упомянут в прошлой статье? разве там есть Ambari? я понял там cloudera manager должен быть взамен, раз дистр от клоудеры.


    1. volek
      27.09.2017 17:00

      Вызываем через REST oozie jobs в них вызов spark-submit в режиме cluster.
      Дистр — Hortonworks, соответственно есть Ambari.


      1. Yo1
        27.09.2017 17:21

        интересно, тут значит другое озеро? у вас под разные задачи разные озера/кластера?


  1. x666x
    27.09.2017 13:27
    -5

    Интересно, спасибо


  1. mephistopheies
    27.09.2017 14:51
    +3

    увольте маркетолога


  1. knagaev
    27.09.2017 15:28

    Как работает ГАУСС?

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


  1. ratatosk
    27.09.2017 16:19
    +2

    А причем здесь математика? Или она упомянута только из-за слова "Гаусс" в названии?


  1. arthur_veber
    27.09.2017 18:06

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


  1. speshuric
    27.09.2017 19:32
    +3

    Как быстро сосчитать сумму чисел от 1 до 100? Согласно легенде, первым эту задачку решил великий немецкий математик Карл Фридрих Гаусс, еще будучи школьником.

    Выкиньте на помойку свой сборник легенд.
    Арифметические и геометрические прогрессии известны человечеству на несколько тысяч лет больше, чем прошло от рождения Гаусса. И формулы их сумм тоже. "По легенде" единственное в чем отличился в данном случае юный Карл Гаусс — это то что он а) решил это в то ли в 6, то ли в 7, то ли в 10 лет, б) нашёл закономерность быстрее одноклассников и неожиданно для учителя.
    Этот пример мне лично не говорит о том, что "чтобы быстрее получить результат и повысить его точность, нужно автоматизировать процессы", а скорее говорит о том, что над большой задачей нужно немного подумать, и если вам повезёт, или вы гений (Гаусс, например), то может быть вы сможете найти решение не за O(N), а за O(1). А автоматизировать — это если написать программу, которая тупо складывает от 1 до 100.


    Если уже привязывать Гаусса к BigData, то лучше вспомнить нормальное распределение, которое часто называют распределением Гаусса или Гаусса-Лапласа. Да, конечно, не Гаусс его придумал, но он вывел его роль в многократном измерении. Это распределение играет фундаментальнейшую роль в теории вероятностей (центральная предельная теорема). Теория вероятностей — это база для матстатистики, фактически матстатистика — задача обратная теорверу: по набору данных найти распределение. А что есть BigData, как не решение статистических задач? Так что название GAUSS для системы обработки больших данных весьма обоснованное.


    Кстати, Гауссу приписывают особую внимательность к точности деталей и формулировок и к качеству своих работ. А вот если к фактам относиться, как автор этой статьи, то точность прогнозов в ВТБ будет примерно сравнима с гаданием на картах (КДПВ намекает), а обоснованность с прогнозами осминога Пауля.


    PS: для выигрыша в bullshit-bingo в статье не хватает слов "Devops" и "blockchain"


    1. speshuric
      27.09.2017 20:48
      +1

      PPS: будущий «король математики» в конце VIII века — Гаусс жил на тысячу лет позднее.


    1. lexnekr
      27.09.2017 23:00

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