Анализировать данные в реальном времени можно разными способами. В ВТБ мы используем технологию Change Data Capture (CDC), реализованную в инструменте Golden Gate Oracle: для нас очень важна скорость, при этом хотелось бы уменьшить объем передаваемых данных и снизить нагрузку на источник. И хотя основная сфера применения этого инструмента — репликации из Oracle и MS SQL, за несколько лет работы с CDC у нас накопилось несколько интересных кейсов, наподобие миграции данных между платформами или разными типами СУБД. Под катом мы поделимся нашим опытом работы с Golden Gate.
Повседневное применение банковских карт давно стало привычным, и люди, как правило, не задумываются, что каждое использование платежного терминала — это оперативная передача в банк определенной информации. Объемы данных растут, при этом обрабатывать их хотелось бы как можно быстрее, в том числе чтобы отправлять спецпредложения в реальном времени, ведь, как говорится, хороша ложка к обеду. И совсем не так хороши для обработки данных на лету традиционные инструменты ETL (extract, transform, load — извлечение, преобразование, загрузка). Вот одно из слабых звеньев: когда данные забираются из таблиц системы источника, необходимо выбрать только новые строки или строки с изменениями. Такой подход дополнительно нагружает систему-источник и увеличивает объем передаваемых данных.
CDC же в режиме реального времени захватывает изменения из журналов базы данных. Так источник нагружается гораздо меньше, да и объем передаваемых данных сокращается. С этой технологией мы снизили потребность в вычислительных ресурсах для систем с большим объемом транзакционных изменений: ведь для захвата данных даже для самых высоконагруженных банковских систем достаточно 1–2 ядер процессора на источнике. А если бы мы внедряли ETL, то потребовалось бы докупать процессорные емкости, чтобы вычитывать данные в параллели.
В ВТБ мы уже несколько лет используем технологии Oracle GoldenGate — инструмент CDC от Oracle. С его помощью мы наполняем оперативное хранилище данных и разносим функции информационных систем на «теплые» и «горячие» зоны. 90% применения OGG в ИТ-ландшафте банка — загрузка данных из Oracle и MS SQL, но, кроме репликации, он отлично справляется с другими задачами. Давайте рассмотрим несколько примеров из нашей практики.
Мы познакомились с GoldenGate в 2013 году. Тогда на нашем комплексе карточного процессинга одновременно обрабатывались транзакции и готовились отчеты. OLTP-нагрузка смешивалась с DWH/DSS-нагрузкой, и большие тяжелые выборки «вымывали» кэш из памяти базы данных. В результате быстрым транзакциям приходилось обращаться к жесткому диску, скорость работы критичных бизнес-сервисов падала. Чтобы разгрузить ядро процессинга, мы вынесли все разработанные нами процедуры и отчеты на «теплую» реплику на Oracle Exadata.
Как реплицировать данные с помощью GoldenGate, мы подробно рассказывали здесь. В двух словах: для высоконагруженных систем, где есть микширование разных типов нагрузки, мы разносим по разным серверам OLTP и DWH/DSS, а для синхронизации между ними используем GoldenGate. Эта схема выделения «теплой» реплики пригодилась нам во многих других кейсах. Например, тот же подход применили в нашей системе противодействия мошенничеству — всю подготовку отчетности выносим на интегрированные системы Oracle Exadata, данные реплицируем на них с помощью GoldenGate.
Систем без сбоев не бывает. Например, если разработчик изменит данные на приемнике, то может возникнуть ошибка применения данных, и процессы GoldenGate остановятся. Чтобы исключить рассинхронизацию данных, в качестве независимого арбитра мы используем Oracle GoldenGate Veridata. Этот инструмент не просто верифицирует данные между источниками и приемниками — главное, что Veridata устраняет возникшие расхождения. Важно, что когда мы имеем дело с репликацией, Veridata гарантирует точное сравнение данных и выявление потерянных записей. Мы получаем полный отчет с результатами сравнения, который можно предъявить недоверчивым коллегам.
Отдельный кейс связан со строительством оперативного хранилища. Сложность состоит в том, что, помимо оперативной отчетности, у нас готовятся данные для корпоративного хранилища (staging). Бывает, что надо сформировать оперативную отчетность на основании данных, которые собираются из ряда различных систем. И удобнее всего делать это на уровне оперативного хранилища. Для получения данных на большой скорости и с минимальной нагрузкой на ресурсы мы в очередной раз применили GoldenGate.
Для сравнения поясним, как мы находили дельту изменений в некоторых наших системах раньше. Если система сама не позволяла выделять дельту или меняла данные задним числом, то таблица из источника в 10 ТБ сравнивалась с таблицей 10 ТБ на приемнике за предыдущий день. Эти 10 ТБ надо было сначала захватить на источнике, и нагрузка ложилась не только на систему-источник, ЦПУ, память, но и на сети передачи данных, а также на систему, занимающуюся сравнением. И все это ради того, чтобы найти дельту новых данных в 0,01%!
GoldenGate не создает практически никакой нагрузки на источник: CDC просто читает журналы и выдает готовую дельту. Это позволяет серьезно сэкономить на инфраструктуре. При этом не имеет значения, кто является приемником — традиционное хранилище на базе продуктов Oracle, MSSQL, Teradata или просто Hadoop.
Отметим, что в этом кейсе в качестве источника и приемника применялись базы данных Oracle. Решение показало свою эффективность, так что сейчас мы подключаем все новые системы к общему оперативному хранилищу данных, и теперь это не только Oracle. Еще один плюс GoldenGate в том, что он подходит для загрузки данных из большинства используемых баз данных в ИТ-ландшафте банка.
Мы уже упоминали о потоковой аналитике, то есть о предложениях клиентам в реальном времени — Real-Time Offering (RTO). Старшие товарищи говорят, что успех в банковском бизнесе напрямую зависит от того, как хорошо вы знаете своего клиента и насколько актуальное предложение можете ему сделать. Другими словами, вероятность того, что клиент воспользуется предложением банка, обратно пропорциональна скорости реакции банка на потребности клиента.
Как это работает? Например, история транзакций показывает, что клиент каждую пятницу закупается в винном магазине. Геопозиционирование засекает его в торговом центре, где есть магазин этой сети, и мы через мобильное приложение направляем ему персональное предложение на скидку в магазин деликатесов в том же ТЦ. Для банка такой кейс наиболее интересен, он позволяет создавать ко-бренды и совместные предложения. Клиентами могут быть физические лица и организации.
Здесь есть офлайн- и онлайн-части. В первой клиентов предварительно сегментируют, используя данные всех систем. Аналитики и data-сайентисты изучают поведение, исторические данные и создают так называемые ловушки. Главное — поймать значимое событие, которое может быть отслежено по транзакции эквайера, мобильному приложению или другим доступным источникам. И уже это событие обрабатывается средствами потоковой аналитики, а решение принимается в моменте на основании заготовленных ловушек.
Задача CDC GoldenGate — обеспечить поток данных о событиях в реальном времени из систем-источников на аналитическую платформу. Кроме того, в состав лицензии GoldenGate for Big Data входит Oracle Stream Analytics. С его помощью data-сайентисты могут самостоятельно обрабатывать поток данных на Spark Streaming, разрабатывая приложение в визуальной среде.
Антифрод-системы достаточно закрыты, и это правильно: чем меньше людей посвящено в детали, тем выше безопасность. Они отлично справляются с обработкой стандартных кейсов, но иногда возникают ситуации, которые в стандартные скрипты не вписываются. Поэтому важно дополнять эти модели нестандартными сценариями. Мы постоянно разрабатываем новые модели, базирующиеся на корреляции событий различных систем: карточных и валютных операций, местоположения, операций платежных систем, действий в мобильных приложениях, мониторинга социальных сетей. Для изменения модели приходится следовать принятым процессам: business request, постановка задач, прохождение заявки через все внутренние этапы реализации.
В прошлом году мы протестировали заливку данных с использованием Oracle GoldenGate for Big Data из наиболее загруженных традиционных систем, где было очень много мелких транзакций, и из нашей системы антифрода в основной кластер на Oracle Big Data Appliance. И Hadoop, и GoldenGate справились с объемом передаваемых данных — нас это несколько удивило.
За последние два года с GoldenGate мы удвоили объемы передаваемых логов — почти до 1 ТБ в час. Это практически закрывает наши потребности на текущий момент. К сожалению, есть физика, в которую мы упираемся. Но по увеличению пропускной способности ведется активная работа с командой разработчиков GoldenGate, так что это далеко не предел. Параллельно мы смотрим и пилотируем решения CDC других вендоров, однако поводов для миграции с Oracle GoldenGate не обнаружили. На данный момент эта технология показала себя как наиболее зрелая из представленных на рынке.
Зачем нам понадобилась CDC (Change Data Capture)
Повседневное применение банковских карт давно стало привычным, и люди, как правило, не задумываются, что каждое использование платежного терминала — это оперативная передача в банк определенной информации. Объемы данных растут, при этом обрабатывать их хотелось бы как можно быстрее, в том числе чтобы отправлять спецпредложения в реальном времени, ведь, как говорится, хороша ложка к обеду. И совсем не так хороши для обработки данных на лету традиционные инструменты ETL (extract, transform, load — извлечение, преобразование, загрузка). Вот одно из слабых звеньев: когда данные забираются из таблиц системы источника, необходимо выбрать только новые строки или строки с изменениями. Такой подход дополнительно нагружает систему-источник и увеличивает объем передаваемых данных.
CDC же в режиме реального времени захватывает изменения из журналов базы данных. Так источник нагружается гораздо меньше, да и объем передаваемых данных сокращается. С этой технологией мы снизили потребность в вычислительных ресурсах для систем с большим объемом транзакционных изменений: ведь для захвата данных даже для самых высоконагруженных банковских систем достаточно 1–2 ядер процессора на источнике. А если бы мы внедряли ETL, то потребовалось бы докупать процессорные емкости, чтобы вычитывать данные в параллели.
В ВТБ мы уже несколько лет используем технологии Oracle GoldenGate — инструмент CDC от Oracle. С его помощью мы наполняем оперативное хранилище данных и разносим функции информационных систем на «теплые» и «горячие» зоны. 90% применения OGG в ИТ-ландшафте банка — загрузка данных из Oracle и MS SQL, но, кроме репликации, он отлично справляется с другими задачами. Давайте рассмотрим несколько примеров из нашей практики.
Кейс 1. Подготовка оперативной отчетности онлайн
Мы познакомились с GoldenGate в 2013 году. Тогда на нашем комплексе карточного процессинга одновременно обрабатывались транзакции и готовились отчеты. OLTP-нагрузка смешивалась с DWH/DSS-нагрузкой, и большие тяжелые выборки «вымывали» кэш из памяти базы данных. В результате быстрым транзакциям приходилось обращаться к жесткому диску, скорость работы критичных бизнес-сервисов падала. Чтобы разгрузить ядро процессинга, мы вынесли все разработанные нами процедуры и отчеты на «теплую» реплику на Oracle Exadata.
Как реплицировать данные с помощью GoldenGate, мы подробно рассказывали здесь. В двух словах: для высоконагруженных систем, где есть микширование разных типов нагрузки, мы разносим по разным серверам OLTP и DWH/DSS, а для синхронизации между ними используем GoldenGate. Эта схема выделения «теплой» реплики пригодилась нам во многих других кейсах. Например, тот же подход применили в нашей системе противодействия мошенничеству — всю подготовку отчетности выносим на интегрированные системы Oracle Exadata, данные реплицируем на них с помощью GoldenGate.
Систем без сбоев не бывает. Например, если разработчик изменит данные на приемнике, то может возникнуть ошибка применения данных, и процессы GoldenGate остановятся. Чтобы исключить рассинхронизацию данных, в качестве независимого арбитра мы используем Oracle GoldenGate Veridata. Этот инструмент не просто верифицирует данные между источниками и приемниками — главное, что Veridata устраняет возникшие расхождения. Важно, что когда мы имеем дело с репликацией, Veridata гарантирует точное сравнение данных и выявление потерянных записей. Мы получаем полный отчет с результатами сравнения, который можно предъявить недоверчивым коллегам.
Кейс 2. Консолидированная отчетность и staging в оперативном хранилище
Отдельный кейс связан со строительством оперативного хранилища. Сложность состоит в том, что, помимо оперативной отчетности, у нас готовятся данные для корпоративного хранилища (staging). Бывает, что надо сформировать оперативную отчетность на основании данных, которые собираются из ряда различных систем. И удобнее всего делать это на уровне оперативного хранилища. Для получения данных на большой скорости и с минимальной нагрузкой на ресурсы мы в очередной раз применили GoldenGate.
Для сравнения поясним, как мы находили дельту изменений в некоторых наших системах раньше. Если система сама не позволяла выделять дельту или меняла данные задним числом, то таблица из источника в 10 ТБ сравнивалась с таблицей 10 ТБ на приемнике за предыдущий день. Эти 10 ТБ надо было сначала захватить на источнике, и нагрузка ложилась не только на систему-источник, ЦПУ, память, но и на сети передачи данных, а также на систему, занимающуюся сравнением. И все это ради того, чтобы найти дельту новых данных в 0,01%!
GoldenGate не создает практически никакой нагрузки на источник: CDC просто читает журналы и выдает готовую дельту. Это позволяет серьезно сэкономить на инфраструктуре. При этом не имеет значения, кто является приемником — традиционное хранилище на базе продуктов Oracle, MSSQL, Teradata или просто Hadoop.
Отметим, что в этом кейсе в качестве источника и приемника применялись базы данных Oracle. Решение показало свою эффективность, так что сейчас мы подключаем все новые системы к общему оперативному хранилищу данных, и теперь это не только Oracle. Еще один плюс GoldenGate в том, что он подходит для загрузки данных из большинства используемых баз данных в ИТ-ландшафте банка.
Кейс 3. Персональные предложения клиентам в реальном времени
Мы уже упоминали о потоковой аналитике, то есть о предложениях клиентам в реальном времени — Real-Time Offering (RTO). Старшие товарищи говорят, что успех в банковском бизнесе напрямую зависит от того, как хорошо вы знаете своего клиента и насколько актуальное предложение можете ему сделать. Другими словами, вероятность того, что клиент воспользуется предложением банка, обратно пропорциональна скорости реакции банка на потребности клиента.
Как это работает? Например, история транзакций показывает, что клиент каждую пятницу закупается в винном магазине. Геопозиционирование засекает его в торговом центре, где есть магазин этой сети, и мы через мобильное приложение направляем ему персональное предложение на скидку в магазин деликатесов в том же ТЦ. Для банка такой кейс наиболее интересен, он позволяет создавать ко-бренды и совместные предложения. Клиентами могут быть физические лица и организации.
Здесь есть офлайн- и онлайн-части. В первой клиентов предварительно сегментируют, используя данные всех систем. Аналитики и data-сайентисты изучают поведение, исторические данные и создают так называемые ловушки. Главное — поймать значимое событие, которое может быть отслежено по транзакции эквайера, мобильному приложению или другим доступным источникам. И уже это событие обрабатывается средствами потоковой аналитики, а решение принимается в моменте на основании заготовленных ловушек.
Задача CDC GoldenGate — обеспечить поток данных о событиях в реальном времени из систем-источников на аналитическую платформу. Кроме того, в состав лицензии GoldenGate for Big Data входит Oracle Stream Analytics. С его помощью data-сайентисты могут самостоятельно обрабатывать поток данных на Spark Streaming, разрабатывая приложение в визуальной среде.
Кейс 4. Оперативное противодействие новым видам мошенничества
Антифрод-системы достаточно закрыты, и это правильно: чем меньше людей посвящено в детали, тем выше безопасность. Они отлично справляются с обработкой стандартных кейсов, но иногда возникают ситуации, которые в стандартные скрипты не вписываются. Поэтому важно дополнять эти модели нестандартными сценариями. Мы постоянно разрабатываем новые модели, базирующиеся на корреляции событий различных систем: карточных и валютных операций, местоположения, операций платежных систем, действий в мобильных приложениях, мониторинга социальных сетей. Для изменения модели приходится следовать принятым процессам: business request, постановка задач, прохождение заявки через все внутренние этапы реализации.
В прошлом году мы протестировали заливку данных с использованием Oracle GoldenGate for Big Data из наиболее загруженных традиционных систем, где было очень много мелких транзакций, и из нашей системы антифрода в основной кластер на Oracle Big Data Appliance. И Hadoop, и GoldenGate справились с объемом передаваемых данных — нас это несколько удивило.
Терабайт в час и другие выводы
За последние два года с GoldenGate мы удвоили объемы передаваемых логов — почти до 1 ТБ в час. Это практически закрывает наши потребности на текущий момент. К сожалению, есть физика, в которую мы упираемся. Но по увеличению пропускной способности ведется активная работа с командой разработчиков GoldenGate, так что это далеко не предел. Параллельно мы смотрим и пилотируем решения CDC других вендоров, однако поводов для миграции с Oracle GoldenGate не обнаружили. На данный момент эта технология показала себя как наиболее зрелая из представленных на рынке.
