Блог компании ВТБ

Как в ВТБ меняли парадигму доступа к данным

Big Data-мания имеет под собой реальное основание. Объемы данных, которые собирают компании, стремительно растут, и бизнес при их грамотном анализе может получить большое конкурентное преимущество. Как «причесать» систему, в которой распределенные по разным хранилищам данные соседствуют с зоопарком малофункциональных инструментов для их обработки? Мы в банке ВТБ перешли на Hadoop, внедрив единую экосистему от Teradata по технологии QueryGrid. Нашей болью, муками, собственно интеграцией и результатами мы хотим с вами поделиться.

Big Data — Big Problem
Большие данные приобретают все большее значение для бизнеса банка. Аналитики могут использовать их для повышения качества оказания услуг, поддержания лояльности существующих клиентов и привлечения новых. Огромные массивы разнородных данных - это огромный пласт полезной информации. Если суметь ее достать.
Без аналитики больших данных компании слепые и глухие, они блуждают по сети как олень по автостраде
Джеффри Мур (Geoffrey Moore), автор бестселлера «Пересечение пропасти»
В крупных компаниях данные хранятся в разнообразных по скорости доступа и уровню безопасности хранилищах. Аналитики данных, подобно алхимикам, колдуют над результатом, используя максимально возможный набор инструментов. Но современные инструменты далеки от совершенства и выдают ответы только на простые и конкретные запросы. В итоге данные дают огромные возможности, а аналитики не могут воспользоваться ими.
Эволюция интеграции данных
С этой проблемой столкнулись и мы. И в качестве решения нам подошел бы не просто хороший инструмент для обработки данных - а тот, который бы соответствовал всем нашим - непростым и в некоторых случаях специфическим - требованиям. Например, нам нужно было, чтобы он мог обрабатывать любой запрос в режиме «одного окна», отображая информацию из разных источников в едином и понятном виде. Аналитику требовалась возможность легко залезать в дебри данных на любом источнике. Сам инструмент при этом не должен был перегружать системы хранения данных своими алгоритмами. Банк нуждался в интеграции с корпоративным хранилищем данных, с основной функцией — хранением холодных данных за прошлые периоды. Интеграция при этом должна была пройти безболезненно и без информационных потерь.
Еще момент. В сегодняшних реалиях BigData любое жизнеспособное решение должно сводить к минимуму перемещение данных. Важно, чтобы инструмент обработки данных был как можно более эффективным — для этого можно использовать параллелизм, сжимать трафик, настраивать буферы пакетной передачи данных. При этом нужно организовать все так, чтобы передача данных между системами с разными контурами доступа была безопасной.
Хранилище данных в ВТБ: что есть сейчас
Теперь о том, с чем мы подошли к проекту. Корпоративное хранилище данных розничного бизнеса ВТБ построено на платформе Teradata, которая служит центром консолидации данных и обеспечивает все системы единой аналитикой.
Платформа Teradata поставляет данные для онлайн-конвейера кредитов и предоставляет информацию о клиентах для аналитической CRM (Teradata Customer Interaction Manager). Другими словами, это важное звено инфраструктуры банка, и оно не должно было пострадать от новых инструментов аналитиков.
Как мы выбирали инструменты по анализу данных
Итак, нам нужно было осуществить внедрение новых инструментов обработки данных в общую экосистему банка: связать Teradata с другими платформами, наделить аналитиков новыми возможностями запросов и не потерять уже имеющиеся данные. В принципе, есть несколько общих вопросов, на которые ориентируется бизнес при выборе инструментов для работы с данными:
  • Стабильность — требования к данным известны и меняются довольно редко?
  • Конкуренция — сколько одновременных сессий/запросов должно поддерживать решение?
  • SLA's — какое время отклика ожидается по сформулированным задачам?
  • Каков объем анализируемых данных?
  • Нужно ли перемещение данных?
Ответы на эти вопросы помогут сузить круг поисков - но универсальной таблетки нет: в каждом случае есть определенные требования к глубине запросов и ограничения безопасности по обработке данных.
Как и у большинства крупных организаций, лучшим вариантом стал Hadoop — это набор вычислительных средств для надежных, масштабируемых и распределенных вычислений, который может применяться и как хранилище файлов общего назначения, способное вместить петабайты данных.
Чтобы объединить имеющуюся платформу Teradata с Hadoop, мы использовали технологию Teradata QueryGrid 2.0. Она позволяет бесшовно объединять инструменты аналитики в единую систему. Технологию демонстрировали на различных докладах Teradata Universe и Teradata Partners, приводя кейсы других компаний — Ebay и PayPal. Для примера приведем график исследования компании Third Nature, показывающий, когда лучше использовать виртуализацию данных, федерацию данных и Teratada QueryGrid. Как видите, чем больше объем данных, тем выгоднее использовать QueryGrid.
До полноценного внедрения Hadoop был разработан тестовый стенд, на котором проходили испытания по интеграции. Результаты тестов по скорости и удобству решения нас полностью удовлетворили: трансформация инфраструктуры хранилища прошла максимально комфортно для пользователей. Многие даже не заметили, что информация хранится в разных системах. Для нас это был идеальный вариант — хоть внешне ничего и не изменилось, Hadoop успешно подключился и использовался вместе с Teradata.
Разбираем инструменты: Teradata QueryGrid 2.0 и Execution Engine
Технология Teradata QueryGrid 2.0 позволяет организовать множество разнородных систем в так называемую фабрику данных, где они могут выступать как удаленным источником, так и инициатором запросов к любой или ко всем системам фабрики сразу.
QueryGrid имеет множество настроек безопасности, несколько ролевых моделей, позволяет шифровать и сжимать трафик, автоматически делать Push Down простых предикатов и более сложных конструкций, используя особенности удаленной системы, вручную пробрасывать синтаксис, выполнять DDL операции, вызов процедур.
Однако технология не претендует на роль средства виртуализации данных общего назначения, это все-таки средство высокопроизводительной мультисистемой аналитики.
Teradata QueryGrid имеет модульную архитектуру, которая позволяет изменять, обновлять и добавлять компоненты фабрики данных, не затрагивая при этом всю систему в целом.
У Teradata QueryGrid есть несколько компонентов.
QGM — QueryGrid Manager — осуществляет централизованное администрирование и мониторинг.
Он отвечает за установку и обновление всех компонентов фабрики, мониторинг и уведомление о возникающих проблемах. QGM позволяет управлять ключами защищенного доступа по сетям фабрики, захватывает метрики производительности запросов (время его выполнения на серверной и клиентской стороне), а также всех логов, генерируемых компонентами фабрики.
QGM работает на Cassandra, а для анализа логов использует связку Elastic Search и Kibana. Предоставляет REST API для встраивания в интерфейс Teradata Viewpoint. QGM требует для себя отдельного сервера, а будучи кластеризованным (High Availability решение), — сводит к нулю время даунтайма при обновлении любого компонента системы.
Коротко о других компонентах QueryGrid:
  • Watch Dog — управляет процессами на каждом из узлов систем, а также пересылает QGM логи и отчеты о статусе работы узлов QG;
  • Fabric — объединяет в себе системы, коннекторы и линки;
  • QGC — QueryGrid Connector — коннектор к источнику данных;
  • QGL — QueryGrid Link — пара коннекторов (инициатор запроса и удаленная система);
  • Viewpoint — единый инструмент мониторинга Teradata.
Следующий шаг — выбор движка обработки Hadoop. Для этого нам нужно было подобрать подходящий по производительности и совместимости с версией Teradata у ВТБ. Было три варианта: MapReduce, TEZ и Presto.
TEZ отпал сразу, поскольку не поддерживал выбранный нами дистрибутив Hadoop от компании Cloudera (5.9 A MR). На бенчмарках отличную производительность как в изолированных тестах, так и в условиях конкурентной нагрузки показал Presto. И поскольку высокая производительность имеет большое значение для мультисистемной аналитики, мы остановились на Presto.
Еще один плюс Presto — полная совместимость с QueryGrid 2.0: с 2015 года его разработку и поддержку ведет Teradata. Teradata, как говорится, born to be parallel. Presto — тоже parrallel, MPP (massive parallel processing) движок, QueryGrid умеет использовать эти преимущества.
Для нашего проекта нужно было два вида коннекторов:
  • коннектор к СУБД Teradata для включения в фабрику любой из систем Teradata;
  • коннектор к Presto, позволяющий включить в фабрику любую инсталляцию Presto.
Ниже представлена схема взаимодействия между Teradata и Presto.
Наиболее полное тестирование инструментов проводила компания AtScale, ниже приведем их результаты. С подробностями и методикой тестирования можно ознакомиться по ссылке.
Стоит взглянуть на графики - и выбор компонентов станет понятен.
Физическая реализация системы
Корпоративное хранилище данных в ВТБ состоит из двух промышленных stand-by контуров Teradata, одинаковых по содержанию.
На PROD1 работает ETL и регламентные процессы банка. PROD2 служит системой для работы пользователей и запуска маркетинговых кампаний. В основе системы PROD1/PROD2 — концепция частного облака. Данные между системами PROD1 и PROD2 постоянно реплицируются на основе разработанного фреймворка, в том числе и с помощью QueryGrid.
Обратите внимание на то, как соединен Hadoop с системой PROD2. Во-первых, это шесть Infiniband-линков по 56 Гбит/с (по три на каждый IB свитч). Во-вторых, системы скоммутированы как единое целое — свитч в свитч (Multi System Configuration). А это значит — широчайший канал и минимальные задержки.
Еще один момент, который не отражен на картинке, — кластер Presto, установленный прямо на узлах Hadoop: 4 worker-ноды Presto на 4 data-нодах Hadoop. Это значит, что для Presto данные Hadoop локальны, лишней передачи данных по сети не происходит.
Теперь нам остается настроить QueryGrid и попробовать сначала загрузить через него информацию в Hadoop, а потом использовать ее в запросах. Доступ ко всем настройкам и функциям, в том числе, установке пакетов на узлы системы, делается через веб-интерфейс.
Выглядит это вот так:
После того как коннекторы и линки настроены, можно переходить к написанию запросов. Продемонстрируем, как объединить две системы. Для этого напишем несколько запросов: создадим объект, через который обращаемся к данным Hadoop; зальем данные с нашего хранилища Teradata в Hadoop и запросами продемонстрируем бесшовный доступ к обоим хранилищам и общей их обработке.
Первым делом создаем в базе объект, через который будем обращаться к Hadoop:
CREATE FOREIGN SERVER TD_SERVER_DB.presto USING 
LINK  ('presto')
version  ('active')
DO IMPORT WITH TD_SYSFNLIB.QGINITIATORIMPORT ,
DO EXPORT WITH TD_SYSFNLIB.QGINITIATOREXPORT ;
Все, можно заливать данные из Teradata в Hadoop.
INSERT INTO DEMO.SOME_HISTORY_DATA@PRESTO
SELECT    REPORT_DT
            , ACCOUNT_RK                    
            , ACCOUNT_NUM                   
            , CURRENCY_RK                   
            , CURRENCY_ISO_CD               
            , BALANCE        
FROM    DEMO.SOME_DATA
WHERE    REPORT_DT BETWEEN DATE '2014-01-31'  AND    DATE '2014-12-31' 
Создаем слой представлений
Просмотр данных Hadoop
REPLACE    VIEW SYSDBA.v_SOME_HISTORY_DATA AS
SELECT    REPORT_DT
            , ACCOUNT_RK                    
            , ACCOUNT_NUM                   
            , CURRENCY_RK                   
            , CURRENCY_ISO_CD               
            , BALANCE        
FROM    DEMO.SOME_HISTORY_DATA@PRESTO
WHERE    REPORT_DT BETWEEN DATE '2014-01-31'  AND    DATE '2014-12-31' 
          AND REPORT_YEAR = 2014;
Просмотр данных Teradata
REPLACE    VIEW SYSDBA.v_SOME_HOT_DATA AS 
LOCK    ROW FOR ACCESS
SELECT    REPORT_DT
            , ACCOUNT_RK                    
            , ACCOUNT_NUM                   
            , CURRENCY_RK                   
            , CURRENCY_ISO_CD               
            , BALANCE                       
 FROM SYSDBA.SOME_HOT_DATA
WHERE    REPORT_DT >  DATE '2014-12-31';
А вот и он – бесшовный доступ к данным: итоговая выдача, которую получает пользователь.
REPLACE    VIEW SYSDBA.v_UNITED_DATA  AS
SELECT    * 
    FROM    SYSDBA.v_SOME_HOT_DATA 
UNION ALL
SELECT    * 
    FROM    SYSDBA.v_SOME_HISTORY_DATA
;
Теперь данные можно брать из итоговой, объединенной выдачи, а QueryGrid разберется, как и откуда их достать.
SELECT    * 
    FROM    SYSDBA.v_UNITED_DATA
WHERE    report_dt =  DATE '2014-01-31'; --данные только из Hadoop, Teradata не задействуется
SELECT    * 
    FROM    SYSDBA.v_UNITED_DATA
WHERE    report_dt =  DATE '2016-01-31'; --данные только из Teradata, Hadoop не задействуется
SELECT    * 
    FROM    SYSDBA.v_UNITED_DATA	--данные берутся из обеих систем
WHERE    report_dt BETWEEN  DATE '2014-11-30'     AND    DATE'2015-01-31';
Что в итоге
С помощью Teradata QueryGrid удалось построить логическое хранилище данных, где все разрозненные источники данных собраны в единую экосистему.
Новый инструмент позволил аналитикам получать максимально подробные ответы на «глубокие» запросы, не используя, как раньше, целый зоопарк приложений.
В планах по развитию — использование исторических данных, вынесенных в Hadoop и регламентные ETL-процессы, и подключение новых источников данных к фабрике через технологию QueryGrid.
Комментарии 12
    +1

    Сама по себе Presto, без QueryGrid, имеет схожую функциональность и изначально разрабатывалась в Facebook для тех же целей и, рискну, предположить, еще больших объемов и производительности. Что забавно, Presto умеет использовать Teradata как источник данных, пробрасывать туда предикаты и распараллеливать вычисления.


    Можете разъяснить подробнее, какие преимущества привносит Teradata QueryGrid?

      0
      fediq Teradata QueryGrid — выступает межсистемной шиной для связки различных SQL Engine (Teradata и Presto/Hadoop, Presto/Hadoop и Oracle, Teradata и Oracle и т.д.) и их интеграции в единую аналитическую экосистему.
      Так как компания Teradata является одним из основных контрибьютеров в OpenSource код Presto, то это даёт возможность интеграции движков Presto и Teradata на низком уровне.

      Teradata QueryGrid привнес следующие преимущества:

      • простоту установки и настройки компонент;
      • процесс обновления и подключения новых систем к экосистеме банка без даунтайма;
      • администрирование и сопровождение всех компонент из единого портала Teradata Viewpoint.


      Павел Ермаков, Терадата.
        0

        А пользователи уже получили доступ к кросс запросам из двух систем?
        Просто сталкиваемся с тем что простейшие запросы ввиду особенностей висят в очереди минутами, интересно если сделать запрос только к hadoop, запрос будет ждать в общей очереди teradata?
        p.s. может немного сумбурно сформулировал, основной инструмент работ Oracle.

          0
          Да, доступ у пользователей есть и они его используют.
          В TASM (Teradata Active System Management) есть возможность классификации запроса по типу используемого объекта, что в свою очередь позволит направить его выполнение в отдельный пул задач (как ваш пример — разделение по платформам, между Teradata и Hadoop). В TASM-е довольно обширный список по возможным типам классификации нагрузки и, как пример, для бизнес-пользователей используется подход классификаци по коротким/средним/долгим аналитическим запросам.

          Павел Ермаков, Терадата.
        0
        Думаю, что такой подход коллег обусловлен направлением потока обработки данных. Посредством Hadoop можно подключить большое количество сырых источников данных и после их очистки и подготовки к дальнейшей обработке перевести их (данные) в специализированные системы учета…
        0
        Немного не понял в чем преимущество?
        Сколько я работал в розничных банках, обычно данные из всех систем аккумулировались в хранилище oracle/sas из которых все необходимые отчеты достаточно быстро выгружались автоматически или по запросу
          0
          Хотелось бы заметить, что SAS всё-таки больше про приложения, а не ХД :) И да, под данными приложениями (SAS из Вашего примера) есть СУБД.

          Прежние подходы остаются — сбор данных в централизованное транзакционное хранилище, где понятны виды нагрузок (batch, ad-hoc, reporting), но появляются и новые — различная аналитика над данными там, где они располагаются, без необходимости их перемещения, используя максимальные возможности того движка, под которым хранятся эти данные (Presto, Spark, Kafka и др.).

          Новой подход расширяет возможности для пользователей/IT, которые получают доступ к данным и последующей аналитики над ними без ожидания их загрузки в централизованное ХД (загрузка в ХД обычно идёт по установленному расписанию, то есть регламенту).

          Павел Ермаков, Терадата.
            0
            поддержания лояльности существующих клиентов и привлечения новых.
            Клиенты банка бегают по офисам вместо курьеров, а они что-то там внедряют )
            Курьеров себе внедрите для начала и обслуживание полностью онлайн.
              0
              Не знаю как насчет высоких технологий в ВТБ, но на днях обнаружил, что все мои шаблоны исчезли. На законный вопрос «э?» получил от саппорта замечательный ответ «мы перешли на новую систему и последние два года в новостях писали, что надо перенести шаблоны на мастер счета, в итоге мы перевели всех принудительно и все старое потерли». Шаблон это всего лишь набор реквизитов, причем здесь какие-то мастер счета? Зато у нас есть Hadoop, Teradata, QueryGrid…
              Извините, что не по теме, но накипело.
                +1
                Вы меня, конечно, извините… понимаю, что, наверное, «это просто по времени совпало с внедрением чего-то там большого» у вас…

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

                потому что пока вы там «прокачатете смс по очередям» — я сделаю ещё пяток операций и в итоге мне уже около полугода периодически приходят замечательные сообщения типа «поступление 20 000.00 рублей, баланс 10.00 рублей» ))

                поправьте сначала это, а уже потом хвалитесь «большими данными». ну серьезно. <_<
                  0
                  Так вот почему мне СМС только третьи сутки приходят. Это все продвинутые современные технологии. Понятно. Буду знать.
                    0
                    так у нормальных банков есть push-уведомления, а не древние sms.

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