Опыт использования решения Oracle GoldenGate

Немного практики, или с чего все начиналось?

До момента запуска решения процесс обеспечения данными бизнес-аналитиков заказчика выглядел приблизительно так:

• из учетных систем делались ночные выгрузки, загружаемые затем в отчетные базы;
• пользователям предоставлялся доступ к репликам.

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

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

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

Ниже мы расскажем о принципах работы GoldenGate и нашем опыте его настройки.

Принцип работы GoldenGate

Рисунок 1. Схема работы GoldenGate

В рамках работ мы должны были установить GoldenGate и на источники, и на приемник данных (в случае невозможности прямой связи источника и приемника обычно выделяется дополнительный промежуточный сервер, после чего проводится настройка нескольких параметров баз систем источников – все!). GoldenGate был быстро установлен и готов к настройке и запуску в эксплуатацию.

После запуска программного обеспечения на источнике стали собираться изменения из redo-log- или archive redo-log-файлов, пересылаться посредством так называемых передаточных trail-файлов на сервер-приемник и применяться в базе аналитической системы.

Вся прелесть GoldenGate заключается в том, что для получения данных он использует журналы повторного выполнения. Никаких запросов к базе, никаких триггеров и т.д. Нагрузка на источники минимальна! Для особо требовательных систем есть режим downstream, снижающий нагрузку на исходную систему практически до нуля.

Этапы использования GoldenGate

Отчетность

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

Несмотря на то что GoldenGate отлично реплицирует данные, когда структуры источника и приемника различаются, нужно учитывать, что это все же не ETL/ELT-инструмент, хотя на нем можно решать некоторые подобные задачи. И здесь нам на помощь пришла интеграция с полноценным и мощным ELT-инструментом все того же производителя – Oracle Data Integrator. Связка этих двух «монстров» позволила нам решить задачи по формированию любых форматов отчетности.

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

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

Хранилище данных

Следующая потребность, сформулированная представителями заказчика, заключалась в обеспечении возможности выполнения анализа данных во временном разрезе. И тут перед нами встал вопрос построения хранилища данных.

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

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

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

В нашем случае после внедрения GoldenGate бизнес-заказчик получил хранилище данных с детальным ведением истории изменений, без доработки систем-источников. Созданное хранилище данных позволяет отслеживать историю поведения клиентов – заинтересованность в разных продуктах компании и т.д.

Хранилище данных есть, онлайн-отчетность есть!

Данные времени выполнения

Но как быть, спросите вы, если представители заказчика хотят получать данные о времени выполнения определенных действий? В нашем случае это касалось, в частности, заявок на кредиты. Сотрудник заказчика работал с информацией по заявке на кредиты, момент работы фиксировался в одном из полей USER_ID, но информации о дате начала и окончании работы не было. Иногда поле USER_ID дополнялось полем «дата модификации» UPD_DT. Но данная ситуация приводила к тому, что нельзя было однозначно рассчитать KPI работы сотрудников и выявить причины зависания заявок на определенных шагах и/или этапах прохождения заявки.

Рисунок 2. Прием работы с заявкой

Кроме этого, заявки время от времени передавались другим сотрудникам. Значения полей USER_ID, UPD_DT менялось на нового сотрудника и дату изменения, без сохранения истории о предыдущем сотруднике. Казалось бы, дата изменения была, сотрудник тоже был указан, все можно получить. Дело в том, что между интервалами загрузки данных в BI может происходить несколько изменений, и тогда промежуточные изменения будут потеряны. Уменьшение интервалов загрузки тоже не помогало, так как заявка могла переходить от сотрудника к сотруднику несколько раз в течение нескольких секунд.

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

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

Бывалые знатоки репликации вспомнят еще один инструмент от Oracle – Oracle Streams. Конечно, определенный функционал GoldenGate можно повторить на Oracle Streams, но Oracle перестал развивать этот продукт, сделав ставку на GoldenGate, перенеся наработки Streams в ядро GoldenGate.

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

Рисунок 3.Работа сотрудников с заявками через GoldenGate

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

С помощью решения GoldenGate мы смогли не только решить технологическую задачу онлайн-репликации, но и обеспечили реализацию крайне актуальной потребности для бизнеса – предоставили быстрый и мощный инструмент для обработки данных и дополнительной аналитики. Конкурирующих продуктов по производительности, особенно при работе с базами данных Oracle, у него практически нет.