В данной статье мне хотелось бы продолжить описание технологий, используемых в Банке ТКС при построении DWH. Статья может быть интересна тем, кто планирует использовать LogMining Change Data Capture (CDC) для репликации данных из операционных источников в онлайн-стэйджинг Хранилища, построенного на основе СУБД GreenPlum.
Вместо вступления.
Во всех современных ИТ и финансовых организациях существует множество различных операционных учетных систем, которые предназначены для хранения и обработки операционных данных. Так как нагрузка на эти источники с целью построения отчетности не допустима (она может повлиять на производительность business-critical процессов), организации строят DWH, при этом загрузка данных в Хранилище в большинстве случаев производится по ночам в период наименьшей нагрузки на операционные системы.
Технология CDC LogMining позволяет решить сразу несколько задач:
— снижение нагрузки на операционные источники в момент загрузки данных в DWH. Продукты, реализующие данную технологию, в большинстве случаев читают транзакционные лог-файлы систем-источников, разбирают их и применяют в систему-приемник. Именно за счет того, что происходит разбор транзакционных логов средствами стороннего ПО и уменьшается нагрузки на системы-источники;
— онлайн (или близкая к онлайн) реплика данных системы-источника в системе-приемнике, что позволяет строить близкую к онлайн отчетность;
— возможность ETL-разработчикам обращаться к репликам таблиц источников в любое время (не только в те промежутки, которые выделены для чтения систем-источников);
— большинство продуктов параллельно с репликами позволяют создавать т.н. change-таблицы, в которых отображается вся история изменения в исходных таблицах-источниках.
Сводные показатели по системам-источникам Банка, необходимым для репликации
DWH в Банке построено на базе СУБД GreenPlum, все необходимые для репликации источники данных — под управлением СУБД Oracle. Сводные показатели реплицируемых источников приведены в таблице:
| Параметр | Значение |
|---|---|
| Количество систем-источников для репликации | 5 |
| Количество реплицируемых таблиц | ~ 200 |
| Объемы транзакционных логов (Гбайт/час) | |
|
10 |
|
160 |
|
~ 40 |
| Суммарное количество операций в сутки | ~ 50 млн. |
Поиск готовых решений.
В качестве CDC-решения нами рассматривались следующие продукты:
- Oracle Golden Gate. Продукт, в настоящее время разрабатываемый и поддерживаемый Oracle. Замечательный, как нам показалось, продукт по части стабильности и производительности чтения изменений из систем-источников. Однако к недостаткам Golden Gate можно отнести то, что он не поддерживает GreenPlum из коробки, нет встроенных средств первоначальной загрузки данных
- Informatica Data Replicator. Продукт, поддерживающий Oracle как источник и Greenplum как приемник, имеет инструменты первоначальной загрузки данных. Продукт гарантирует целостность данных между источником и приемником, однако, для этого требует наличие транзакционных логов на все открытые в момент старта репликации транзакции, что не всегда является допустимо в виду ограничения объема дисковых систем хранения транзакционных логов
- Attunity Replicate. Новый продукт, поддерживающий Oracle как источник и Greenplum как приемник, так же как и Informatica Data Replicator имеет инструменты первоначальной загрузки данных. Решение имеет простую систему управления, нацелено на работу «out-of-the-box»
Механизмы применения изменений в приемник у различных CDC решений свои и во многом зависят от уровня supplemental logging на источнике (о supplemental logging рекомендую прочесть замечательную статью Александра Рындина ). Oracle Golden Gate — система, которая замечательно может быть применена при полном supplemental logging (последовательно применяя на приемник в виде батча все INSERT, последний UPDATE по ключу и все DELETE). Особенностью одного из наших источников является то, что количество колонок в его таблицах — велико, количество обновлений строк в источнике — также велико, но при этом количество обновляемых полей в рамках одного update на источнике — мало. Включение полного supplemental logging на всех полях в источнике приводило к невероятному росту объемов транзакционных логов, и было принято решение о включении supplemental logging только на первичные ключи. В связи с этим пришлось писать сложные скрипты агрегации и применения изменений.
Старт проекта в production
Итак, нами был выбран продукт Attunity Replicate. Он оказался единственным продуктом, удовлетворяющим всем требованиям нашего пилотного проекта. На момент начала внедрения актуальной была версия 2.0.
В этой версии был реализован единственный метод применения изменений — row-by-row, в котором каждое изменение на источнике применялось в приемник в виде самостоятельного SQL-запроса:
update target set f1=’a’, f2=’b’, f3=’c’ where key=’key1’Недостатки этого подхода в Greenplum выявились сразу после включения в репликацию данных, объемы которых (как по количеству строк, так и по количеству операций) превышали те, которые мы использовали в пилотном проекте. Очевидно, что Greenplum не может переварить суммарное количество транзакций из баз-источников. С одной стороны, это аналитическая СУБД, не предназначенная для высокой транзакционной нагрузки, а с другой, суммарное количество транзакций всех баз-источников настолько велико, что будет проблемой для любой СУБД. Для такого рода CDC системы, на наш взгляд, оптимальным является режим мини-батчей, при котором на базе-приемнике изменения применяются в виде предварительно агрегированных детальных транзакций. Изменения копятся в CDC-системе, а затем раз, например, в минуту, применяются на приемнике. Такой режим мы применяли, ранее исследуя применимость GoldenGate. Были разработаны скрипты агрегации и применения изменений. Эти скрипты были переданы в Attunity для изучения. Детально изучив скрипты, Attunity выпускает новую версию replicate 2.1, в которой появляется режим мини-батчей. Теперь обновления могут применяться следующим образом:
update target
set f1 = decode(net.f1, null, target.f1, '<ATT_NULL>', null, net.f1)
,f2 = decode(net.f2, null, target.f2, '<ATT_NULL>', null, net.f2)
,...
from net
where target.key=net.key
Здесь net — это таблица, в которую изменения «предрасчитываются» самим Attunity Replicate. В результате внедрения этой доработки количество запросов к базе-приемнику резко сократилось и мы теперь способны обрабатывать полный объем изменений, которые производят наши источники. Данную технологию Attunity назвали turbo stream CDC и она полностью себя оправдывает: при средней нагрузке на источнике данные реплицируются в GreenPlum с задержкой в среднем 60-80 секунд. Есть, конечно, проблемы. При пиковой нагрузке на источнике (например, при закрытии операционного дня) задержка возрастает, иногда значительно, вплоть до 1,5 часов. Причина кроется в том, что Attunity Replicate работает через LogMiner, который не всегда успевает обработать логи базы при пиковых нагрузках.
В процессе применения изменений возможны так называемые apply conflicts — конфликты применения изменений в приемник. К наиболее часто встречающимся можно отнести: 0 rows affected (на приемнике не обновилось ни одной записи) и duplicate keys (вставка в приемник записи, которая уже существует). При нормальной работе системы данные конфликты возможны при первоначальной загрузке, так как с целью обеспечения согласованности данных в приемнике, Replicate начинает захватывать изменения в данных немного раньше, чем полную выгрузку. Attuity Replicate обнаруживает такие конфликты и переходит в режим row-by-row, сохраняя их в специальную системную таблицу для дальнейшего разбора.
Работа на LogMiner.
CDC – решения могут использовать два различных механизма для чтения транзакционных логов источника: свой собственный механизм (binary reader) и механизм самой СУБД – источника. В случае Oracle – это Oracle LogMiner, который может возвращать данные в двух режимах:
- commited data (возвращает DML только для commited-транзакций)
- raw data (возвращает данные обо всех транзакциях)
В режиме commited data производительность Oracle LogMiner ужасна и требует дополнительных ресурсов на источнике. В случае raw data производительность гораздо лучше, ресурсов требуется меньше, но в этом случае приложение должно взять на себя функции по дополнительному разбору возвращаемых LogMiner-ом результатов и формирования на этой основе SQL-statements, которые будут применены в приемник.
На данном этапе Attunity Replicate работает с использованием raw-режима Oracle LogMiner, но в их планах — стабилизировать собственный Binary Reader, который можно будет настроить на чтение транзакционных логов напрямую со стойки, где они хранятся, и даже незначительная нагрузка на систему-источник в момент захвата изменений исчезнет полностью.
Текущий статус по проекту
В настоящий момент в production успешно работает версия 2.2, и параллельно тестируется версия 3.0 Attunity Replicate. Нагрузка на системы — источники (вне периодов первоначальной загрузки) оказалась не значительной — благодаря тому, что при вызове методов LogMiner’а используется режим raw data. Что касается GreenPlum, то здесь тоже все в порядке. Хоть число транзакций, выполняемых Attunity Replicate и велико, оно гораздо меньше того числа транзакций, которые выполняются на системах-источниках и в виду небольшого объема изменений, производимых каждой транзакцией, нагрузка на приемник так же не значительна.
Вместо заключения
Эта статья — уже второй шаг на пути освещения технологий DWH в нашем Банке. Впереди рассказ об online-warehouse (основой которого, как не трудно догадаться, стал CDC Log mining) и много чего еще интересного.